IRC chat logs for #ltsp on irc.libera.chat (webchat)


Channel log from 6 November 2019   (all times are UTC)

00:00
<vagrantc>
crossgrading is definitely possible with debian (and presumably debian derivatives), but it involves a lot of manual effort and is not likely a way to save time, certainly not with something as simple as an LTSP environment
00:15vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
00:48
<robert45>
is there any way to clone a client image? Because Im getting different results when a new amd64 image. i386 image is working fine
00:48
Sorry, I meant to say: "when a new amd64 image is used"
00:51
nevermind, its good no!
00:51
now*
02:00jgee has left IRC (jgee!~jgee@190.159.118.121, Quit: The Lounge - https://thelounge.chat)
02:10jgee has joined IRC (jgee!~jgee@190.159.118.121)
04:03robert45 has left IRC (robert45!~robert45@r167-57-51-13.dialup.adsl.anteldata.net.uy, )
04:41Ark74 has left IRC (Ark74!~Luis@177.238.145.140, Quit: Leaving)
05:39kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:18f7:8bb3:207c:e001)
05:40vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
05:45kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:2889:a70e:6ea0:d288)
06:47ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
07:30
<enoch85>
good morning!
07:32
so I have two issues left: dual screens, and to be able to boot iPXE over NAT
07:35
<alkisg>
enoch85: ipxe over nat requires local media, e.g. floppy, cd etc
07:36
dual screen should already be working out of the box, vnc to me to see why it's not
07:36
finally, there's lightdm-autologin-greeter if "2 seconds timeout for login" isn't good enough; I haven't tested it though
07:37
(09:35:56 AM) alkisg: enoch85: ipxe over nat requires local media, e.g. floppy, cd etc ==> or a local dhcp server
07:48
<enoch85>
I just tested the dual screen thing and added 2 monitors in the VM by specifying 2 screens in the settings of the VM
07:48
it didn't help
07:48
also when booting a client with only DP connected, it boots up correctly then the screen dies after the kernels have been loaded
07:49
I'll send VNC soon
07:49
!vnc
07:49
<ltsp>
I do not know about 'vnc', but I do know about these similar topics: 'x11vnc', 'kvm-vnc', 'vnc-plinet', 'vnc-dide', 'vnc-edide', 'vnc-alkisg', 'uvnc-dide'
07:53
<enoch85>
alkisg could you please send me the terminal command for vnc?
07:53
forgot :/
07:54
<alkisg>
enoch85: x11vnc -connect srv1-dide.ioa.sch.gr
07:56
<enoch85>
it's booting now
07:56
<alkisg>
enoch85: eh, vnc stopped; and boot the client too
07:57
Rerun the vnc command
07:57
x11vnc has a bug in 18.04; I solved it in the greek schools ppa, maybe I should upload it to the ltsp ppa too
07:58
<enoch85>
this is on a single screen btw
07:58
<alkisg>
enoch85: are both screens connected?
07:59
<enoch85>
no, will boot a client with duial screens
07:59
sec
07:59
<alkisg>
Right, we want to see the problem, not a working one :)
08:00
<enoch85>
haha sure, sory
08:00
sorry*
08:00
booting one now
08:00
should come online soon
08:01
<alkisg>
And which outputs are connected, vga and dp?
08:02
<enoch85>
correct
08:02
<alkisg>
Are you using an adaptor or something?
08:02
<enoch85>
no
08:02
<alkisg>
It doesn't detect it as connected
08:03
<enoch85>
it first boot one the DP screen then "reverts" to the VGA screen
08:03
I can show you in a video
08:03
sec
08:03
<alkisg>
No need
08:03
<enoch85>
ok
08:03
<alkisg>
It's a kernel/xorg issue, not an ltsp issue,
08:03
let's see...
08:05kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:2889:a70e:6ea0:d288, Ping timeout: 246 seconds)
08:07
<meo>
same adapter or separate? you may want to force xrandr initialization
08:09
<enoch85>
adapter? it's seperate adapters if you mean the connetion
08:09
sec
08:10
<meo>
no I mean is this the same GPU or separate? i.e. 1 display connected to the motherboard another to a PCI card? xrandr does get confused on configurations like this with older chips, and you sometimes need to manually map the outputs
08:10
<enoch85>
https://cloud.danielhansson.nu/s/tMnrgp5zAZbGSga
08:10
aah, it's on the same card
08:11
afaik
08:11
<meo>
yeah looks that way
08:11
what does xrandr output show
08:13vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
08:15
<enoch85>
I'll go and check sec
08:17
it's working!
08:18
<alkisg>
Great
08:18
The kernel doesn't autodetect that the display is on
08:18
So it needs to be forced
08:18
<enoch85>
I didn't follow quite, but is this a change in the OS itself, or is it fixable with an LTSP command?
08:19
<alkisg>
This command in ltsp.conf fixes it: POST_INIT_ENABLE_DP1="echo on > /sys/class/drm/card0-DP-1/status"
08:19
<enoch85>
so you didn't change anything in the "backend"?
08:19
<alkisg>
MAYBE this would fix it too, but no need to test: KERNEL_PARAMETERS="video=DP1:e"
08:20
<enoch85>
yeah OK, I will fiddle with it later
08:20
<alkisg>
No; this isn't an ltsp issue, it's a kernel issue, and that command was the workaround
08:20
Maybe with a newer or older kernel it wouldn't even be needed
08:21
<enoch85>
ok, so that LTSP command is the only thing required to fix it? no changes in the actual code itself?
08:21
command/parameter
08:22
just so that I get it, sorry for my ignorance here :)
08:23
<alkisg>
Exactly
08:23
<enoch85>
ok perfect!
08:24
thanks again for your awesome help!
08:24
<alkisg>
np
08:25
<enoch85>
and with IPXE over NAT I would need to boot from USB containing the iPXE boot files?
08:26
I wouldn't work with firewall rules? e.g. allow all traffic to the iPXE server?
08:26
<alkisg>
Which side is the client?
08:26
<enoch85>
the scenario is this:
08:27
<alkisg>
If the server is behind NAT, you'd also need port forwarding for all the involved ports
08:27
<enoch85>
Server in one city ----> Site to Site tunnel ----> Client connecting to the server
08:27
<alkisg>
ssh, nfs, tftp etc
08:27
<enoch85>
yeah, that's nno problem
08:27
client in another city
08:27
<alkisg>
If you're using VPN, then you shouldn't need NAT, right?
08:27
<enoch85>
I'm not 100% sure
08:28
but yeah you may be right
08:28
<alkisg>
How would the client join the VPN on boot?
08:28
<enoch85>
it's very locked down though so we only allow certain ports on the other side
08:28
it's a site to site tunnel with a VPN FW on the other side
08:29
so everything behind the VPN FW is on our network
08:29
no need to manually connect
08:29
<alkisg>
What is the other site dhcp server?
08:29
Is it configurable?
08:29
<enoch85>
The other site uses it's own IP and have DHCP from the VPN FW
08:29
its*
08:30
<alkisg>
Is that configurable?
08:30
<enoch85>
yes
08:30
<alkisg>
OK, then you'd just need to put the correct next-server there
08:30
<enoch85>
I mean you can lock down IP adresses and such
08:30
<alkisg>
and boot filename
08:30
<enoch85>
as with any DHCP
08:30
hmm, let me check
08:31
<alkisg>
Which software the DHCP server is? E.g. pfsense? plain isc-dhcp? windows dhcpd?
08:31
<enoch85>
pfsense
08:31
and yes, everything is configurable
08:31
<alkisg>
pfsense doesn't support conditional boot filenames
08:31
<enoch85>
bummer
08:32
<alkisg>
So you'd need a custom-compiled undionly.kpxe to bypass that
08:32
<enoch85>
okok
08:32
out of my league :)
08:32kjackal has joined IRC (kjackal!~quassel@ppp079166021071.access.hol.gr)
08:32
<alkisg>
Do your research, and if you end up needing what I just said, you can just hire me to do that
08:33
<enoch85>
sure, will do!
08:33
thanks again
08:33
<alkisg>
np
08:34
So to sum up, you won't need local media, just a custom undionly.kpxe on your ltsp server, not on pfsense; and a boot-filename=undionly.kpxe setting in pfsense.
08:35
Another way would be to deploy a small boot server there, that would also host the image, and save you all the nfs bandiwidth
08:40
<enoch85>
yeah ok, good to know. I'll continue on my end here and let you know down the road.
08:41enoch85 has left IRC (enoch85!25f71ea4@37-247-30-164.customers.ownit.se, Remote host closed the connection)
09:06georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213)
09:15georgeneophytou1 has joined IRC (georgeneophytou1!~georgeneo@217.27.33.213)
09:16georgeneophytou1 has left IRC (georgeneophytou1!~georgeneo@217.27.33.213, Client Quit)
09:16georgeneophytou1 has joined IRC (georgeneophytou1!~georgeneo@217.27.33.213)
09:19georgeneophytou1 has left IRC (georgeneophytou1!~georgeneo@217.27.33.213, Client Quit)
09:20statler has joined IRC (statler!~Georg@gwrz3.lohn24.de)
09:21neo has joined IRC (neo!~georgeneo@217.27.33.213)
09:21neo is now known as Guest45350
09:22Guest45350 has left IRC (Guest45350!~georgeneo@217.27.33.213)
09:25georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Quit: Textual IRC Client: www.textualapp.com)
09:27georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213)
09:28
<georgeneophytou>
good morning, is it possible to set user quotas for storage? alkisg
09:29
<alkisg>
georgeneophytou: good morning, this is unrelated to ltsp, google for "user quotas linux"
09:29
<georgeneophytou>
okay thanks
09:57
<alkisg>
georgeneophytou: are you using guest sessions or block device homes or something that is ltsp specific? i.e. other than plain sshfs/nfs home?
09:59
<georgeneophytou>
I am just using the standard LTSP install but I was wondering about quotas
10:00kjackal has left IRC (kjackal!~quassel@ppp079166021071.access.hol.gr, Ping timeout: 250 seconds)
10:00
<alkisg>
OK then yeah not ltsp specific
10:02
<meo>
wonder if sshfs will behave funny under quotas
10:05
<alkisg>
:q
10:05
<uumas>
meo: I don't see why it would. I know we've had zfs quotas in the past with ltsp and there were no problems.
10:07
<meo>
uumas: dunno, there's fuse in the middle, so how well it handles error conditions depends on both fuse and sshfs implementation
10:08
<alkisg>
I imagine quotas would work, but the user might not get any warnings about remaining space before the quotas are exhausted
10:14kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:2889:a70e:6ea0:d288)
10:18Da-Geek has joined IRC (Da-Geek!~Da-Geek@5.154.189.38)
10:37alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 240 seconds)
10:45alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
10:55pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv)
11:04
<pavars>
Hi, does anyone here know why ltsp5 would randomly disconnect users? So far only one user gets disconnected, bet sometimes other users get disconnected too. In .xsession-errors I see got Disconnected from D-Bus
11:13
<alkisg>
pavars: graphics or networking issues
11:13
If you're using thin clients, it's a big worse, as opengl doesn't behave well over the network
11:13
If you're using ltsp fat clients, then it's the same as standalone workstations, some apps or drivers can crash xorg
11:14
*a bit worse
11:18
<pavars>
we tried different cables and different thin client so it could be graphics
11:18
<alkisg>
You would see a /var/crash entry then
11:18
Or messages in /var/log/Xorg.7.log.old
11:18
<pavars>
can it be that it works normally and then at some random point it disconnects the user
11:19enoch85 has joined IRC (enoch85!25f71ea4@37-247-30-164.customers.ownit.se)
11:19
<alkisg>
You mean like an ltsp internal reason? No
11:19
There's no code in ltsp to randomly disconnect users
11:21
<pavars>
there are some files in /var/crash
11:21
I will investigate when the next crash happens
11:21
<alkisg>
Yup, that's the correct path
11:37pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Remote host closed the connection)
11:38pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv)
11:53Faith has joined IRC (Faith!~Paty_@2001:12d0:2080::231:49)
11:53Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:07section1 has joined IRC (section1!~section1@178.33.109.106)
12:10vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
12:40
<enoch85>
alkisg 3 clients testing now :) ended up with using rdesktop as I din't get xfreerdp to work with desktop shortcuts
12:40
they are experiancing lag when moving windows, do you happen to know if I can make it quicker in LTSP?
12:42
<alkisg>
enoch85: nah, the speed of rdp isn't related to ltsp, it's only configurable by its options
12:43
rdp is like thin clients, remote desktop = slow
12:43
That's why when we need windows here, we're using VMs instead
12:44
Windows VMs are like fat clients, remote disk, not remote screen
12:45
<enoch85>
So what you're saying is that we shold setup small VMs instead and then connect directly to the VMs from the clients? I'm not following here...
12:48
also my boss was asking (and I just want to make sure) are the guest sesssions run from the server, or on the client hardware as if everything was loaded onto the client RAM and DISK?
12:49
i.e are the RDP sessions run from the server, or from the clients?
12:49
I noticed that if I reboot the server, the connections to the clients die, so that means to me that everything is run from the server
12:50
watching "nload" I can see that there are about 30 kbp/s on three clients
12:50
not any load though, and only 600 MB RAM consumed on the server
12:54
<alkisg>
they run on the clients
12:55
<enoch85>
ok
12:55
<alkisg>
the clients root is nfs, so if you stop the server, they hang
12:56
it's remote disk, not remote screen
12:58
You may also test rdp performance by booting clients from a usb disk, it'll be the same
13:01
<enoch85>
what would it cost for us if you fixed iPXE over WAN?
13:01
alkisg
13:02
<alkisg>
You mean to compile undionly? I charge 30 euros per hour, I guess that would take 1 or 2 hours
13:04
<enoch85>
ok, thanks I wil talk to my boss
13:04
<alkisg>
np
13:04
<enoch85>
could we deploy that file on every single location, or does it need to be specific on each location?
13:05
<alkisg>
I think it can be the same in all locations
13:05pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Remote host closed the connection)
13:05
<enoch85>
ok, and everytime iPXE updates we would need to compile a new file?
13:05
<alkisg>
As long as clients boot, there's no reason to update ipxe
13:05
<enoch85>
ok
13:05
I mean new versions
13:05
<alkisg>
Its code is replaced by the kernel, so there are no "left over" security holes etc
13:06
<enoch85>
so iPXE 1.1, 1.2 and so on
13:06
<alkisg>
We have schools here with 10 years old gpxe
13:06
And no reason to change it
13:06
<enoch85>
hehe ok
13:06
<alkisg>
(gpxe was the old ipxe)
13:06
<enoch85>
ok
13:07
btw, could we choose to skip the iPXE menu? I saw that you can set timeout, but is it possible to set that to 0?
13:07
<alkisg>
yes
13:07
<enoch85>
ok
13:07
perfect
13:07
<alkisg>
see the man page
13:07
*the ltsp.ipxe notes
13:09
<enoch85>
MENU_TIMEOUT=“0" ?
13:18
<alkisg>
# To completely hide the menu, set menu-timeout to -1
13:21
<enoch85>
thanks!
13:27pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv)
14:25spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut)
14:33pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Remote host closed the connection)
14:37pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv)
14:49pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Remote host closed the connection)
15:11
<alkisg>
What sounds better, SESSION_SCRIPT, LTSP_SESSION or something else? It's a new ltsp.conf parameter, similar in functionality to .xsession.
15:11
https://github.com/ltsp/ltsp/issues/18#issuecomment-550353273
15:21eddytv has joined IRC (eddytv!~eddy@2620:11e:1000:6:3c68:bc19:6453:337a)
15:29
<eddytv>
Greetings! I was looking at the new LTSP wiki and was curious if there was any support for using LXC container images as iPXE boot images. It would be great to be able to use something like distrobuilder (https://linuxcontainers.org/distrobuilder/introduction/) to create images for fat-clients.
15:41
<||cw>
eddytv: isn't that what ltsp-build-client already does?
15:41
<eddytv>
That is no longer a thing in the new LTSP.
15:45
I'd like to be able to build client images from a reproducible "recipe", whether it be a Dockerfile or a YAML definition for distrobuilder or whatever. I don't want to manually install a random VM where a bunch of commands have been run, making it a challenge to reproduce. And since I'm already using Docker and LXC, I'd prefer that over dealing with another virtualization solution, hence my question.
15:46
<||cw>
ah, right. so distrobuilder says it can output a chroot, and ltsp image can point to a chroot, so give it a shot?
15:46
https://ltsp.github.io/man/ltsp-image/ basically just says "manage the chroot or vm image however you like using whatever tools"
15:47
<eddytv>
Part of the reason I ask is because of https://github.com/ltsp/community/issues/27
15:48
The person gave up and switched to using "a full VM"
15:48
<||cw>
that's for running the server in one, totally different
15:49
<alkisg>
eddytv: why do you need help from ltsp to create a chroot?
15:50
There are lots of methods nowadays, ltsp-build-client isn't relevant anymore
15:50
!chroot
15:50
<ltsp>
chroot: To manage chroots with the new LTSP, see https://github.com/ltsp/community/wiki/chroots
15:50
<eddytv>
Well, that was going to be the next thing I wanted to ask about. I already have DHCP infrastructure, NFS infrastructure, etc. and don't want to run a VM just for LTSP and duplicate those services.
15:50
<||cw>
that issues specifically is in getting a bind mount to work in a container, which running a client doesn't need
15:51
<alkisg>
eddytv: there's no "ltsp server" package. So you just install the ltsp package, and run as many services as you want, or none at all
15:51
But you do need `ltsp image` or `ltsp ipxe` to configure things for you
15:51
<eddytv>
But could I run those in a Docker container that is running `nbd`?
15:51
<||cw>
you don't need a 2nd dhcp server, just dhcp proxy
15:51
<alkisg>
The new ltsp doesn't use nbd
15:52
<eddytv>
Ah, good to know.
15:52
<alkisg>
What would the docker container do?
15:53
<eddytv>
So let's say I can generate my own chroot which contains the new `ltsp` PPA. And I have DHCP and NFS services available already. Do I need "an LTSP server"?
15:53pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv)
15:53
<alkisg>
Will you run mksquashfs yourself?
15:53
Will you configure ipxe yourself?
15:53
And dhcp and nfs and all?
15:54
If you do *all* server side things, then sure you don't need an ltsp "server"
15:54
But note that the ltsp server is primarily just a client template; so you can use a client to maintain the image even if the image is in an nfs server
15:55
Where are your users? Where's /home?
15:56
<eddytv>
/home is NFS
15:56
<alkisg>
And user accounts?
15:57
<eddytv>
For my use case, they can be local, in the client image.
15:57
<alkisg>
Which software runs dhcpd?
15:57
<eddytv>
dnsmasq
15:58
<alkisg>
all fine then
15:58
<eddytv>
For reference, I'm trying to update an existing, but very old, LTSP deployment that is running on a 14.04 server
15:59
I'd like to migrate to the new LTSP, and am hoping to avoid dedicated VMs if possible
15:59
Since the preference is for Docker/LXC containers for everything
16:01
<alkisg>
moment, phone
16:03eddytv_ has joined IRC (eddytv_!~eddy@2620:11e:1000:220:d45:ebba:82c4:cb64)
16:04
<eddytv_>
(sorry, got disconnected). It sounds like the new LTSP may "just work", I will give it a shot. Thanks very much ||cw and alkisg.
16:05eddytv has left IRC (eddytv!~eddy@2620:11e:1000:6:3c68:bc19:6453:337a, Ping timeout: 264 seconds)
16:06eddytv_ is now known as eddytv
16:07
<alkisg>
(06:01:13 PM) alkisg: moment, phone
16:08pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Remote host closed the connection)
16:08woernie has joined IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de)
16:15
<alkisg>
Back
16:17
Btw ltsp19 requires systemd, so it won't run on 14.04. It needs 16.04+
16:19
`ltsp image` does some mount/tmpfs/overlay magic, so I'm not sure if it'll run on containers out of the box or if it'll need a bit of fixing
16:20
If you replace it with just mksquashfs, then it'll surely work
16:22Da-Geek has left IRC (Da-Geek!~Da-Geek@5.154.189.38, Quit: Leaving)
16:23
<eddytv>
We are retiring the 14.04 server, so no issues there! The mksquashfs solution seems like a useable alternative, although it would be *great* if I could use `ltsp image` in a container.
16:26
<alkisg>
You may try it, I think it'll need a few apport exceptions or however they're called; I gave a link in the issue
16:27
It's `ltsp image container` :D so you'll looking to run a container in a container :D
16:27
The new ltsp isn't intrusive, you may even put it in the hypervisor if it's compatible
16:28
And just run `ltsp image container` outside of the container
16:42statler has left IRC (statler!~Georg@gwrz3.lohn24.de, Remote host closed the connection)
16:42pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv)
16:55
<eddytv>
Thanks Alkis, especially for all your work on "LTSP19". I plan to play around with the new implementation and see how it goes for my use case.
16:55pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Ping timeout: 246 seconds)
17:20vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
17:56
<alkisg>
vagrantc: heya, which one sounds better? SESSION, LTSP_SESSION, SESSION_SCRIPT... https://github.com/ltsp/ltsp/issues/18#issuecomment-550353273
17:57
LTSP will prefix it to the Exec lines of xsession.desktop and wayland sessions
17:57
(when set)
18:00
SESSION_WRAPPER, PREFIX_SESSION...
18:10enoch85 has left IRC (enoch85!25f71ea4@37-247-30-164.customers.ownit.se, Ping timeout: 260 seconds)
18:15
<vagrantc>
hmmmm...
18:16
i naturally am inclined towards LTSP_SESSION ... but then everything's prefixed with LTSP_ ... which seems silly.
18:17
<alkisg>
Yeah I tried to avoid it except for the most common words where it wasn't nice to have them alone
18:17
<vagrantc>
SESSION_WRAPPER seems pretty good
18:17
though i think i lean towards LTSP_SESSION, if you don't mind the LTSP_ prefix
18:17
although was that variable used in ltsp 5.x ?
18:18
don't see it... ok.
18:37
<alkisg>
Ty; will use one of those 2
19:23Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
19:28
<eddytv>
alkisg: at 10:51:56 you said "The new ltsp doesn't use nbd" and I just noticed that "NBD" is still prominently listed on the https://ltsp.github.io home page, which is probably why I thought it was still an option.
19:33robert45 has joined IRC (robert45!~robert45@r190-135-251-229.dialup.adsl.anteldata.net.uy)
19:34
<robert45>
hey guys! I have removed my old 32bit image and built a new 64bit image, however, Im presenting with all this kind of errors. I have INIT_COMMAND_RM_NETPLAN already on my lts.conf. Any ideas? https://imgur.com/a/nhwaNzj
19:40
<alkisg>
eddytv: if you set it up yourself...
19:41
robert45: ppa in the chroot?
19:43
robert45: or, wrong syntax/place of lts.conf
19:43
<eddytv>
ah, so if I wanted to use `nbd` you're saying technically you could...
19:43
<alkisg>
yeah; we might also write some support in the future
19:43
maybe for swap...
19:44
<eddytv>
any idea if there's a performance benefit for serving the squashfs via nbd vs. nfs?
19:44
<alkisg>
performance is about the same, nfs has better caching, and a LOT MORE stability
19:44
Like 1000% more
19:45
<eddytv>
Good to know. Sounds like NFS is the way to go.
19:45
<alkisg>
You can even reboot the server and have the clients continue afterwards
19:45
Yeah, we made those decisions for you when designing ltsp19 ;)
19:46
<eddytv>
Fantastic. That's what I like to hear! Thanks again (to everyone) for all the work on the new version.
19:46
<alkisg>
np
19:47
isc-dhcp, tftpd-hpa, ldap etc are also mentioned there, and also manual...
19:53section1 has left IRC (section1!~section1@178.33.109.106, Quit: Leaving)
20:27Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
20:28dgroos has joined IRC (dgroos!~dgroos@205.215.175.117)
20:29Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Client Quit)
20:41woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Remote host closed the connection)
20:45
<dgroos>
Using ltsp19 on ubuntu 18.04 (gdk). Having issues with screens timing out then trouble logging out a student through epoptes.
20:46
Sometimes logout will work but it can take a minute or longer.
20:46
<alkisg>
what does "timing out" mean?
20:46
<dgroos>
Sometimes a dialog box will be shown on the login screen at the client.
20:47
If a student is not interacting with a computer for a while, it will lock (what I was calling timeout)
20:48
And if they leave class, I can't log them out via epoptes or it may work or it might take a minute or more.
20:50
I've checked the syslogs of a few clients but didn't know what to look for.
20:51
<alkisg>
suspend? screensaver?
20:52
<dgroos>
for example, not sure if it's a problem: "rfkill: input handler disabled" and a while later it will give the message that it's enabled.
20:52
screensaver
20:52
<alkisg>
dgroos: rfkill is about wifi, do your clients try to connect with wifi?
20:52
<dgroos>
maybe?
20:52
<alkisg>
Were you using the same clients in ltsp5 without issues?
20:53
<dgroos>
I wasn't but other teachers were, I think. I can test as I've got both systems.
20:54
<alkisg>
How often does that happen? Can you ping me right after it happens so that we check logs?
20:54
<dgroos>
(oops, meant to say that other teachers were using these, not myself, and I don't know if there were problems)
20:54
<alkisg>
nfs has very good recovery, so you may go offline for a while and it'll continue working when it comes back,
20:55
but the question is, if it's networking, where exactly is the issue...
20:55
<dgroos>
OK, I've got a few that I left that have gone into lock mode so I can try shutting them down and see what happens.
20:55
<alkisg>
Check also output of dmesg
20:55
Can you see them via epoptes when they're "locked"?
20:56
<dgroos>
ok, I'll check that first, then try the logout and ping if I see problem.
20:56
yes
20:56
<alkisg>
right click, open terminal, dmesg
20:56
The most important information
20:56
No need to logout it doesn't provide useful info
20:56
<dgroos>
ok
20:56
<alkisg>
Just logs stuff that we don't want to see and will confuse us
20:57lchaos has joined IRC (lchaos!8a3300bf@138.51.0.191)
20:59
<dgroos>
the last message in the dmesg log at the client I'm looking at is rfkill: input handler disabled.
20:59
(colors, I like that!)
20:59
<alkisg>
dmesg | tail -n 50 | nc termbin.com 9999
20:59
Give us more info, not just the last line
21:00
<dgroos>
termbin, that's new to me!
21:00
<alkisg>
It avoids the need to copy/paste :)
21:00
<dgroos>
k
21:01
very cool :-)
21:01
9999 is the id of this paste?
21:01
<alkisg>
No, it's the port that termbin listens to
21:01
The output of the command is the url
21:01
That you're supposed to give us
21:02
<dgroos>
oh :P
21:02
https://termbin.com/eyzo
21:02
<alkisg>
The last message there is when the client boots
21:02
If this client is hanged, it's not related to the kernel... hmm...
21:02
(52 seconds after boot)
21:03
loop17... I guess those are snaps
21:03
<dgroos>
(not saying it is hanged, I've not tried to log it out yet)
21:03
let me try...
21:04
<robert45>
alkisg yeah that was it! thanks!
21:04
have a good one guys
21:04robert45 has left IRC (robert45!~robert45@r190-135-251-229.dialup.adsl.anteldata.net.uy, )
21:05
<alkisg>
dgroos: edit this file: /usr/share/ltsp/ltsp/server/image/image.excludes => remove the snap/* line, then run ltsp image /
21:05
<lchaos>
Hello All, I'm hoping to get some direction to further troubleshoot an issue I've come across in my LTSP setup. The problem is that the ltsp clients fail to boot after receiving an ipaddress and the tftpboot image. The client then proceeds to boot as normal until it starts spitting out 3 errors and goes into squashfs and freezes. if I remember
21:05
correctly the errors related to system network, and I've noticed that the lan interface on the server goes down momentarily as well.
21:05
<alkisg>
There was a bug with snaps, so they may lag, I don't use them and I don't know
21:05
netplan | echo lchaos:
21:05
!netplan | echo lchaos:
21:05
<ltsp>
lchaos: netplan: To work around https://bugs.launchpad.net/netplan/+bug/1763608/comments/47, either update to a new LTSP version, or put this in lts.conf: INIT_COMMAND_RM_NETPLAN="rm -rf /lib/systemd/system-generators/netplan /run/netplan"
21:06
<dgroos>
will do, thanks!
21:06eddytv has left IRC (eddytv!~eddy@2620:11e:1000:220:d45:ebba:82c4:cb64, Quit: My computer has gone to sleep. ZZZzzz…)
21:08
<dgroos>
Also, should I be able to broadcast to a screen where no one has net logged into the client?
21:08
I know that this would work w/ltsp5
21:08
<alkisg>
Yes
21:08
<dgroos>
OH
21:08
<alkisg>
There was a bug with epoptes but I thought it was only in 16.04
21:08
Can you vnc?
21:08
<dgroos>
sure, thanks! just a sec
21:08
<alkisg>
(debhelper compatibility made the epoptes service not start)
21:10
<lchaos>
@ltsp; Thanks for a quick reply, and guidance. I'm excited to start follow up on your advice. Thanks again!1
21:10
<alkisg>
lchaos: ltsp is a bot
21:10
We invoke it to mention our notes to other users here :)
21:10
I.e. it saves us typing :)
21:11
<lchaos>
@alkisg; Thanks for clarifying. :) (slightly embarrassed). Thank you.
21:13
<alkisg>
dgroos: you're on wayland again
21:13
lchaos: no worries man
21:14
dgroos: vnc doesn't work on wayland
21:14
Hrm... although... how am I watching your screen... hm...
21:16lchaos has left IRC (lchaos!8a3300bf@138.51.0.191)
21:18dgroos_ has joined IRC (dgroos_!~dagro001@205.215.175.117)
21:23
<dgroos_>
alkisg: interesting, broadcasting worked on the client but not shown in epoptes
21:24
(don't know if you can see from the access you have)
21:24
<alkisg>
dgroos_: I think broadcasting works fine, but it's not "on top", it goes under gdm because of gnome-shell
21:26
Yeah that's it
21:26
By killing gnome-shell, I can see e.g. the remote terminal
21:26
<dgroos_>
on a vnc session into the client you are saying?
21:26
<alkisg>
So I guess epoptes will need to find a workaround in order to be able to show stuff in front of gdm, not behind it
21:27
We start with client reboot,
21:27
then, right click from epoptes, open root terminal
21:27
This was supposed to show on TOP of gdm
21:27
But it's under it; it's not shown at all (like screen broadcasting)
21:27
<dgroos_>
oh
21:28
<alkisg>
Then,`killall gnome-shell` kills the compositor, and one can properly see the terminal
21:28
So the problem is gnome-shell, it's doing fancy things and hides "on-top" windows beneath
21:28
Just switch to MATE :P
21:29
File a bug in epoptes so that we don't forget about it, and I may have a look ...next year or so; this isn't very important
21:29
<dgroos_>
MATE is cool but I had a lot of issues with it last year.
21:30
Will do, thanks for checking into it!
21:30
<alkisg>
np
21:31
<dgroos_>
Shall I do the work with the snap drive or is the logout issue related to this layer issue?
21:31
<alkisg>
Try the snap, it might be related
21:32
<dgroos_>
k thanks again, will try now.
21:33dgroos has left IRC (dgroos!~dgroos@205.215.175.117, Quit: Leaving)
21:33dgroos_ is now known as dgroos
21:33ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:56eddytv has joined IRC (eddytv!~eddy@2601:402:4500:4670:c954:cfa4:b07f:bd36)
22:33kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:2889:a70e:6ea0:d288, Ping timeout: 246 seconds)
22:43spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Quit: Leaving)
23:11eddytv has left IRC (eddytv!~eddy@2601:402:4500:4670:c954:cfa4:b07f:bd36, Quit: My computer has gone to sleep. ZZZzzz…)
23:11dgroos has left IRC (dgroos!~dagro001@205.215.175.117, Quit: dgroos)
23:34dgroos has joined IRC (dgroos!~dagro001@205.215.175.117)
23:40dgroos has left IRC (dgroos!~dagro001@205.215.175.117, Quit: dgroos)