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


Channel log from 20 December 2021   (all times are UTC)

00:51vagrantc has left IRC (vagrantc!~vagrant@2600:3c01:e000:21:21:21:0:100e, Quit: leaving)
01:00vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:21:21:0:100e)
05:14vagrantc has left IRC (vagrantc!~vagrant@2600:3c01:e000:21:21:21:0:100e, Quit: leaving)
06:22ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
15:20sunweaver has joined IRC (sunweaver!~sunweaver@fylgja.das-netzwerkteam.de)
15:20
<sunweaver>
alkisg: heyho!
15:21
we use LTSP for a Debian Edu customer and generate squashfs images from chroot folders below /srv/ltsp/<some-system-chroot>
15:21
when we run ltsp image /srv/ltsp/<some-system-chroot>, the squashfs image gets created all fine.
15:22
Then we want to create ltsp.img. Ideally, we would like to create ltsp.img from the LTSP setup in /srv/ltsp/<some-system-chroot>.
15:22
However, ltsp.img always seems to be generated from the config on the LTSP host.
15:23
That is counter-intuitive to some respect. Esp. because of the <some-system-chroot> not being the same distro / version as the LTSP host itself.
15:24
Is there a way to generate chroot-specific ltsp.img files and also deploy them automatically to /srv/tftp/ltsp/<some-system>/ltsp.img rather than to /srv/tftp/ltsp/ltsp.img?
15:45lucascastro has left IRC (lucascastro!~lucascast@192-140-51-187.static.oncabo.net.br, Quit: Leaving)
15:49
<alkisg>
Hi sunweaver , back, reading...
15:51
The ltsp.img file corresponds to the server. It contains ltsp.conf, which contains [mac] entries per client, not per distro/chroot. It also contains the server's /etc/passwd, and the server's ssh keys, and the server's /etc/epoptes/epoptes.crt certificate etc
15:52
So it's supposed to be common for all chroots/images. You can even just put a stock debian.iso or ubuntu.iso in /srv/ltsp/images and boot it and and it'll work
16:00vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585682-65.dhcp.inet.fi, Ping timeout: 240 seconds)
19:42vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:21:21:0:100e)
19:51
<sunweaver>
alkisg: thanks for getting back to me on this.
19:51
we currently need to work around this exact behaviour.
19:52
we have four different chroots (three variants of an X2Go thinclient, and a Debian Edu 11 fat client chroot).
19:52
for each chroot we need a slightly different configuation in ltsp.img and we hack around this central solution you describe above
19:54woernie has left IRC (woernie!~werner@p5b296789.dip0.t-ipconnect.de, Remote host closed the connection)
19:54
<sunweaver>
ah, it is three variants, one for thin clients, one for LTSP fat clients, one for LTSP images that have been derived from the main server (the two others have been derived from chroots).
19:54
https://salsa.debian.org/debian-edu/debian-edu-config/-/blob/master/sbin/debian-edu-ltsp-initrd
19:55
what we do in there is create a temp ltsp.conf, create ltsp.img and move that into /srv/tftp/ltsp/<system>/ltsp.img.
19:55
<vagrantc>
there are too many differences to use a shared image?
19:56
<sunweaver>
so, I might assume that your solution is not 100% generic and in fact, I'd like to propose a patch to amend this, so that we don't have to fiddle with temp ltsp.conf files and moving ltsp.img files around.
19:56
vagrantc: I am thinking really generically here.
19:56
One issue for example is that we need to be able to manage LTSP chroots based on Debian 10, 11 and also soonish 12.
19:57
(all of them with different LTSP versions, probably)
19:57
<vagrantc>
ah. yes, if the OS needs to be different, yes, you'll need different images :)
19:57
<sunweaver>
also, we maintain chroots that are specialized for MATE, some for GNOME.
19:57
We maintain those chroot on a central server and deploy the chroots on an individual basis to different customers.
19:58
vagrantc: also, I am expecting customers soon, that might want a non-Debian system to be usable as diskless workstations (LTSP fat client).
19:58
so, Ubuntu / Debian mix, but all driven by an ltsp.img from one host.
19:58
That promises to become painful.
19:58
and: btw.: Hi Vagrant, good to read you!!!
19:59
<vagrantc>
i recently did some consulting in which they needed multiple images (turned out by the end, we narrowed it down to two) for differing hardware support
19:59
sunweaver: likewise!
19:59
<sunweaver>
in fact, there is another customers who wants to the deploy Raspis via LTSP...
19:59
different architecture... wholy heaven.
19:59
s/wholy/holy/g
20:00
alkisg: let me know if I explained the challenge well enough now. Do you still think all chroots shall be deployed via one host config?
20:00
<vagrantc>
i missed what you needed to workaround with the current infrastructure ... LTSP definitely supports multiple images
20:00
<sunweaver>
Please note that the preferred strategy here is let the LTSP host/server be LTSP host/server and ignore that system entirely.
20:01
instead we create chroots and use those as LTSP client systems.
20:01
Ah, you missed my original problem description.
20:01* sunweaver will nastily copy paste what I wrote earlier...
20:01
<vagrantc>
yeah, just joined
20:02
<sunweaver>
16:20 < sunweaver> alkisg: heyho!
20:02
16:21 < sunweaver> we use LTSP for a Debian Edu customer and generate squashfs images from chroot folders below /srv/ltsp/<some-system-chroot>
20:02
16:21 < sunweaver> when we run ltsp image /srv/ltsp/<some-system-chroot>, the squashfs image gets created all fine.
20:02
16:22 < sunweaver> Then we want to create ltsp.img. Ideally, we would like to create ltsp.img from the LTSP setup in /srv/ltsp/<some-system-chroot>.
20:02
16:22 < sunweaver> However, ltsp.img always seems to be generated from the config on the LTSP host.
20:02
16:23 < sunweaver> That is counter-intuitive to some respect. Esp. because of the <some-system-chroot> not being the same distro / version as the LTSP host itself.
20:02
16:24 < sunweaver> Is there a way to generate chroot-specific ltsp.img files and also deploy them automatically to /srv/tftp/ltsp/<some-system>/ltsp.img rather than to /srv/tftp/ltsp/ltsp.img?
20:02* alkisg waves to vagrantc too :)
20:02
<sunweaver>
alkisg: \o/
20:02
<alkisg>
sunweaver: so what's different in ltsp.conf, that can't be scripted inside ltsp.conf or any other script of the many that ltsp supports?
20:03
<vagrantc>
ah! i see the issue now
20:03
<sunweaver>
good to read that you folks are all still here!
20:03* sunweaver and his family have just recovered from Covid-19...
20:03
<alkisg>
All these 3 chroots connect to the same server, right? So the same ltsp.img should be used
20:03
If you need a different ltsp.conf, you can include or source one based on the chroot
20:04
<sunweaver>
alkisg: you would I do that (source another ltsp.conf)
20:04
?
20:04
ah...
20:04
how would I do that... I mean...
20:04* alkisg is glad that he hasn't had any interaction with covid19 at all :D
20:04
<alkisg>
It's just a shell file. For example, you can put an "if i'm in this chroot, . /etc/ltsp/ltsp-that.conf"
20:04
<vagrantc>
there isn't a lot in the ltsp.img ... passwd/group and soem ltsp initialization scripts run from the initramfs ... if i recall correctly
20:05
<alkisg>
Server ssh and epoptes keys, yeah, that's about it
20:05
<sunweaver>
isn't the whole /usr/share/ltsp also put into ltsp.img?
20:05
<alkisg>
It's not at all "chroot specific"
20:05
Yes, to be able to add script that do like what you want to do now; or to be able to boot images that don't have ltsp installed at all
20:06
<sunweaver>
alkisg: so the host LTSP always overrides the LTSP in the chroot? Do I get that right?
20:06
And: the chroot need not have LTSP at all installed?
20:06
<alkisg>
Yes
20:06
Yes
20:06
<sunweaver>
Ok, you are making a point here, then.
20:06
<alkisg>
As long as it has overlayfs and sshfs etc
20:07
<sunweaver>
yeah. Ok.
20:07
then my last question for tonight: How do I do the "if i'm in this chroot, . /etc/ltsp/ltsp-that.conf"?
20:07
I run "ltsp initrd" on the host and it creates ltsp.img
20:08
<alkisg>
For example: grep ubuntu /etc/os-release && . /etc/ltsp/ltsp-ubuntu.conf
20:08
Under [clients]
20:08
<sunweaver>
in ltsp.img I then have /etc/ltsp/ltsp.conf which basically is a shell script.
20:08
Ah, ok.
20:08
So I need to be able to detect my chroot from inside.
20:08
<alkisg>
Right; the only difference is that it makes [sections] into section_functions
20:08
You can even just drop a file in /usr/share/ltsp
20:08
And it'll be automatically sourced
20:09
<sunweaver>
So, we could also do a if [ -e /etc/ltsp/ltsp-ubuntu.conf ]; then . /etc/ltsp/ltsp-ubuntu.conf; fi...
20:09
<alkisg>
Yes but not that /etc/ltsp/ltsp-ubuntu is shipped by the server
20:09
Ah, ok, in your example it isn't
20:09
<sunweaver>
yeah, it must be uniqe to the chroot.
20:09
<alkisg>
So, /usr/share/ltsp and /etc/ltsp are inside ltsp.img, and they overwrite the existing content,
20:09
<sunweaver>
ok.
20:09
<alkisg>
but if you already have that file there, then you don't even need to test for it,
20:10
you can just . /etc/ltsp/chroot.conf
20:10
<sunweaver>
So, what exactly do you mean by this?: < alkisg> Right; the only difference is that it makes [sections] into section_functions
20:10
Re: 21:10 < alkisg> you can just . /etc/ltsp/chroot.conf
20:10
-> Nice!
20:10
<alkisg>
sunweaver: see the last line of: https://ltsp.org/man/ltsp.conf/
20:11
Btw, great work on ayatana-indicators! (except that the printer applet for some reason is always crashing on ubuntu 22.04 :))
20:11
Thanks for them!
20:12
And if you drop the file in the chroot /usr/share/ltsp/client/init/here.sh, it'll get sourced automatically, without doing ". /etc/ltsp/chroot.conf" at all
20:13
<sunweaver>
but /usr/share/ltsp/ gets overridden by ltsp.img...
20:13
<alkisg>
But not deleted
20:13
<sunweaver>
then my here.sh file would be lost again, wouldn't it?
20:13
<alkisg>
No
20:13
It's like cp, not like rsync --delete
20:13
<sunweaver>
ah, so additional files are visible when placed in /usr/share/ltsp?
20:13
<alkisg>
Right
20:14
<sunweaver>
ok, are you ok if I forward our backlog here to debian-edu mailing list?
20:14
Wolfgang Schweer would be dearly interested in these bits if information
20:14
<alkisg>
No problem at all, you can even point to the irclogs if you prefer
20:14
<sunweaver>
(URL?)
20:14
(of the logs)
20:14
<alkisg>
irclogs.ltsp.org, then select this date
20:15
I.e. https://irclogs.ltsp.org/?d=2021-12-20
20:15
Btw, if you ever have any chat in any mailing list where you think I can help wrt ltsp, just cc me...
20:15
I don't mind
20:20
<sunweaver>
alkisg: thanks! much appreciated!
20:20
<alkisg>
👍️
20:21
<sunweaver>
we are currently discussing a more generic, but Debian Edu specific approach for LTSP chroot creation via Debian bug #1002024 (https://bugs.debian.org/1002024).
20:42
<vagrantc>
feels like LTSP19+ did a great job of making the LTSP infrastructure pretty generic
20:51
<alkisg>
sunweaver: btw if you ever need it, the latest ltsp has remoteapps support again; so one can just put REMOTEAPPS=mate-session and have the whole session in thin client mode
20:52
It's currently using ssh -X to do that, so no LDM_DIRECTX equivalent, but if people need it, it's easy to add it
20:57ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:01
<vagrantc>
alkisg: oh!
21:01
alkisg: that would've been useful a couple months ago :)
21:01
will see if it still is in a few years when i hear back again :)
21:03
<alkisg>
Hehe
21:04
<vagrantc>
alkisg: i had the impression you were determined not to add thin client functionality
21:13
<alkisg>
Yeah I only added it for epoptes, so then it made sense to make it as generic as possible
21:17
<vagrantc>
heh
21:46
<alkisg>
Starting from bullseye, I ended up in https://wiki.debian.org/DebianEdu/Documentation/Etch/HowTo/NetworkClients?action=info
21:46
These guys support debian edu for a loooooong time, very nice!!!!