01:56 | vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:50) | |
02:38 | vagrantc has left IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:50, Quit: leaving) | |
04:48 | mcgwrath 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:26 | sunweaver is back | |
07:15 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
07:57 | mcgwrath has left IRC (mcgwrath!~mcgwrath@2607:fa49:d53c:eb00:a1a3:421e:492e:38d3, Quit: Client closed) | |
09:44 | Vercas has left IRC (Vercas!~Vercas@gateway/tor-sasl/vercas, Remote host closed the connection) | |
09:44 | Vercas has joined IRC (Vercas!~Vercas@gateway/tor-sasl/vercas) | |
11:01 | Vercas1 has joined IRC (Vercas1!~Vercas@gateway/tor-sasl/vercas) | |
11:02 | Vercas has left IRC (Vercas!~Vercas@gateway/tor-sasl/vercas, Quit: Ping timeout (120 seconds)) | |
11:02 | Vercas1 is now known as Vercas | |
12:17 | Vercas has left IRC (Vercas!~Vercas@gateway/tor-sasl/vercas, Write error: Connection reset by peer) | |
12:18 | Vercas has joined IRC (Vercas!~Vercas@gateway/tor-sasl/vercas) | |
14:44 | sunweaver is now away: not here ... | |
14:45 | Trendzetter has left IRC (Trendzetter!~trendzett@mail.sbat.be, Read error: Connection reset by peer) | |
14:45 | Trendzetter has joined IRC (Trendzetter!~trendzett@mail.sbat.be) | |
15:36 | sugarbeet has left IRC (sugarbeet!~barbas@81.4.123.134, Ping timeout: 250 seconds) | |
15:38 | sugarbeet has joined IRC (sugarbeet!~barbas@81.4.123.134) | |
15:44 | vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:50) | |
16:17 | XYZ has left IRC (XYZ!~XYZ@89-24-41-33.nat.epc.tmcz.cz, Remote host closed the connection) | |
16:26 | XYZ has joined IRC (XYZ!~XYZ@89-24-41-33.nat.epc.tmcz.cz) | |
20:30 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |