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


Channel log from 5 June 2023   (all times are UTC)

01:56vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:50)
02:38vagrantc has left IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:50, Quit: leaving)
04:48mcgwrath has joined IRC (mcgwrath!~mcgwrath@2607:fa49:d53c:eb00:a1a3:421e:492e:38d3)
04:53
<mcgwrath>
Greetings all..  I'm looking for a way that when I perform updates to the server, reboot the server, and recompile my ltsp image for the clients (running chrootless) all of the clients are essentially broken as the various paths are removed once the server reboots.  I tried a shutdown -r 00:30 but as the paths were missing, the clients didn't
04:53
reboot at that time.  Is there some sort of proper process flow for upgrades in a chrootless environment to work?  (Currently, I have to manually reboot the clients after an update like that.)  Thank you in advance for any hints, tips or tricks!
04:55
<alkisg1>
mcgwrath: update your server, reboot your clients, then reboot your server
04:55
*update your server, run ltsp image, reboot your clients, then reboot your server
04:58
mcgwrath: actually what you mention should also work. For the rootfs that is; while sshfs (for home) can't survive server reboots
05:00
In general keep in mind that nfs can survive a reboot as long as the ltsp image is the same after rebooting.
05:00
While if you run `ltsp image` then a single backup is kept; booted clients can still access the now "old" image; but they need to be rebooted to the new image before the server is rebooted
05:01
<mcgwrath>
:/ Okay, I'll check it out, but it's like every time I reboot the server I lose the clients, even if the ltsp image is the same...  I'll issue a reboot now and prove myself wrong... ;)
05:02
<alkisg1>
mcgwrath: we're talking about new ltsp with nfs, not old ltsp with nbd, right?
05:02
And how do you access the clients, via epoptes?
05:02
<mcgwrath>
Epoptes, yes
05:02
Erm, not sure what nbd is!
05:02
<alkisg1>
Older ltsp 5 technology
05:03
Which distro/version are you using?
05:03
Finally note that clients can't survive two ltsp image. They can only survive one; then they need to be rebooted to load the new image.
05:04
<mcgwrath>
22.04.2
05:04
Ubuntu
05:04
<alkisg1>
OK, then what I said stands
05:05
<mcgwrath>
Can the clients detect a server that has been rebooted and reconnect paths, etc, in nonchroot?
05:05
(provided that the image is the same?)
05:09
<alkisg1>
The method that you use to create the image is irrelevant
05:09
The result always goes to /srv/ltsp/images/x86_64.img, and is served over NFS
05:10
When the server is rebooted, the clients still see the same image, you haven't modified it yet
05:10
<mcgwrath>
Well, I'll be damned.  It's like you wrote the code for this. ;)
05:10
<alkisg1>
:D
05:11
<mcgwrath>
yeah, the clients that were online came back after a server reboot and all is good.
05:11
(with those ones.)
05:11
erm, 2nd question, (If I may)..
05:14
I have a client with a Nvidia card in it and the display gets all weird.  I don't want to be using the closed source gfx drivers, but if I change the 'automatic' color profile in Settings -> Device Colour Profiles -> <displayname> and delete the old automatic colour calibration profile and use "Standard Space sRGB", the display is fine.  *But* I
05:14
can't for the life of me get that change / modification to stay for the users on that fat client!
05:15
<alkisg1>
Nvidia asked you for a password and created an /etc/X11/xorg.conf file. Put it in the image
05:15
<mcgwrath>
I have a couple of shell commands for that, but it was really gross and convoluted to perform...  The GUI is _much_ easier.
05:16
Right on.  Thanks again for all your help and support Alkis!
05:16
<alkisg1>
And if you want to selectively install it only for some clients, see the one-before-last example in https://ltsp.org/man/ltsp.conf/
05:17
<mcgwrath>
K, I'll dig into that.. When I can remote into that client! :D
05:17
<alkisg1>
👍️
05:17
<mcgwrath>
But yeah, I got clients identified by MAC address, pass the username and base64 password...  It's all pretty nifty!
05:18
So thank you.
05:19
(I guess I missed the nvidia part right after the mac addresses!) :D ;)
05:19
k, again, thanks so much!  Night! (1:20AM here.)
06:26sunweaver is back
07:15ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
07:57mcgwrath has left IRC (mcgwrath!~mcgwrath@2607:fa49:d53c:eb00:a1a3:421e:492e:38d3, Quit: Client closed)
09:44Vercas has left IRC (Vercas!~Vercas@gateway/tor-sasl/vercas, Remote host closed the connection)
09:44Vercas has joined IRC (Vercas!~Vercas@gateway/tor-sasl/vercas)
11:01Vercas1 has joined IRC (Vercas1!~Vercas@gateway/tor-sasl/vercas)
11:02Vercas has left IRC (Vercas!~Vercas@gateway/tor-sasl/vercas, Quit: Ping timeout (120 seconds))
11:02Vercas1 is now known as Vercas
12:17Vercas has left IRC (Vercas!~Vercas@gateway/tor-sasl/vercas, Write error: Connection reset by peer)
12:18Vercas has joined IRC (Vercas!~Vercas@gateway/tor-sasl/vercas)
14:44sunweaver is now away: not here ...
14:45Trendzetter has left IRC (Trendzetter!~trendzett@mail.sbat.be, Read error: Connection reset by peer)
14:45Trendzetter has joined IRC (Trendzetter!~trendzett@mail.sbat.be)
15:36sugarbeet has left IRC (sugarbeet!~barbas@81.4.123.134, Ping timeout: 250 seconds)
15:38sugarbeet has joined IRC (sugarbeet!~barbas@81.4.123.134)
15:44vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:50)
16:17XYZ has left IRC (XYZ!~XYZ@89-24-41-33.nat.epc.tmcz.cz, Remote host closed the connection)
16:26XYZ has joined IRC (XYZ!~XYZ@89-24-41-33.nat.epc.tmcz.cz)
20:30ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)