00:51 | vagrantc has left IRC (vagrantc!~vagrant@2600:3c01:e000:21:21:21:0:100e, Quit: leaving) | |
01:00 | vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:21:21:0:100e) | |
05:14 | vagrantc has left IRC (vagrantc!~vagrant@2600:3c01:e000:21:21:21:0:100e, Quit: leaving) | |
06:22 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
15:20 | sunweaver 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:45 | lucascastro 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:00 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585682-65.dhcp.inet.fi, Ping timeout: 240 seconds) | |
19:42 | vagrantc 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:54 | woernie 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:57 | ricotz 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!!!!
| |