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


Channel log from 16 March 2022   (all times are UTC)

01:52vagrantc has left IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:20, Quit: leaving)
07:12Vercas has left IRC (Vercas!~Vercas@gateway/tor-sasl/vercas, Remote host closed the connection)
07:12ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
07:14Vercas has joined IRC (Vercas!~Vercas@gateway/tor-sasl/vercas)
07:39woernie has joined IRC (woernie!~werner@p5b2964a6.dip0.t-ipconnect.de)
08:09woernie has left IRC (woernie!~werner@p5b2964a6.dip0.t-ipconnect.de, Ping timeout: 252 seconds)
08:10woernie has joined IRC (woernie!~werner@p5b2964a6.dip0.t-ipconnect.de)
09:01woernie has left IRC (woernie!~werner@p5b2964a6.dip0.t-ipconnect.de, Remote host closed the connection)
09:56shored1 has joined IRC (shored1!~shored@user/shored)
09:56shored has left IRC (shored!~shored@user/shored, Ping timeout: 240 seconds)
12:22eu^245red-213-96 has joined IRC (eu^245red-213-96!~eu^245red@245.red-213-96-172.staticip.rima-tde.net)
12:30woernie has joined IRC (woernie!~werner@p200300cf071987008de2e8b9c10e04cd.dip0.t-ipconnect.de)
12:37woernie has left IRC (woernie!~werner@p200300cf071987008de2e8b9c10e04cd.dip0.t-ipconnect.de, Quit: No Ping reply in 180 seconds.)
12:38woernie has joined IRC (woernie!~werner@p200300cf071987008de2e8b9c10e04cd.dip0.t-ipconnect.de)
12:44eu^245red-213-96 has left IRC (eu^245red-213-96!~eu^245red@245.red-213-96-172.staticip.rima-tde.net, Quit: Client closed)
13:23lucascastro has left IRC (lucascastro!~lucascast@192-140-51-239.static.oncabo.net.br, Read error: Connection reset by peer)
13:24lucascastro has joined IRC (lucascastro!~lucascast@192-140-51-239.static.oncabo.net.br)
14:21lucascastro has left IRC (lucascastro!~lucascast@192-140-51-239.static.oncabo.net.br, Ping timeout: 268 seconds)
14:46woernie has left IRC (woernie!~werner@p200300cf071987008de2e8b9c10e04cd.dip0.t-ipconnect.de, Remote host closed the connection)
15:54woernie has joined IRC (woernie!~werner@p5ddec5e9.dip0.t-ipconnect.de)
16:00vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:20)
16:24woernie has left IRC (woernie!~werner@p5ddec5e9.dip0.t-ipconnect.de, Remote host closed the connection)
17:05lucascastro has joined IRC (lucascastro!~lucascast@45-167-143-10.netfacil.inf.br)
17:10lucascastro has left IRC (lucascastro!~lucascast@45-167-143-10.netfacil.inf.br, Ping timeout: 240 seconds)
17:45ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
18:19lucascastro has joined IRC (lucascastro!~lucascast@192-140-51-239.static.oncabo.net.br)
19:28woernie has joined IRC (woernie!~werner@p5ddec5e9.dip0.t-ipconnect.de)
19:39j_sh has joined IRC (j_sh!~j_sh@ip-209-124-249-106.static.eatel.net)
19:43
<j_sh>
Hello, all. I'm looking for advice on using multiple NICs on the clients. Anyone have any experience with this? Thanks.
19:53
<vagrantc>
first question would be why do you need that? :)
19:53
what's your use-case?
20:00
<j_sh>
Redundancy in network architecture and cabling.
20:00
One cable from each of two NICs on the client going to different network switches
20:01
You can lose a cable or a switch and maintain connectivity to the LTSP server and other network resources.
20:02
In a non-LTSP environment, you can do this with bridging and routing. But, I don't see a way to define networking for a secondary NIC in the LTSP config.
20:05
<quinox>
fancy
20:06
<j_sh>
Haha. Industrial application. everything is redundant
20:09
<quinox>
you can run your own scripts on startup with POST_INIT_x
20:09
<vagrantc>
and so all network interfaces have the same ip address?
20:10
not sure if any of the network backends support changing ip addresses ...
20:10
for the rootfs
20:10
AoE, maybe ...
20:13
<j_sh>
They can have different IPs. They can both be DHCP, too
20:14
As long as they can reach the server and that subnet in general
20:14
<quinox>
surely that breaks anything like an ssh session no?
20:15
<j_sh>
Depends on how that stuff is configured :)
20:20
<quinox>
I've (happily) been using mosh, but it's not real SSH and comes with a lot of limitations
20:20
<vagrantc>
j_sh: the default rootfs these days is NFS, which does not handle changing ip addresses very well at all
20:20
j_sh: so you might have to explore alternatives to actually make that work
20:21
amoung other stateful protocols in use
20:21
<j_sh>
OK. Thanks. The way I've done this in non-LTSP environments is to use a virtual IP that's bridged to both physical interfaces
20:21
<vagrantc>
notably sshfs, which is used for the homedirs by default
20:21
<j_sh>
But, I don't see a way to do that here.
20:22
Next best thing is to put both MAC addresses in the config file and reboot the client if one goes down.
20:22
<vagrantc>
there's no out of the box way, but you can create that however you like :)
20:22
<j_sh>
Not truly fault tolerant, but probably good enough.
20:22
:) I might try....
20:24
<vagrantc>
another option would be a system where you load the whole OS into ram at boot and don't use network-based homedirs ... then the ip address changing wouldn't matter much ... i think
20:25
i seem to recall there's some support for that
20:25
<quinox>
https://github.com/ltsp/ltsp/issues/74 might be of interest perhaps: just load everything into RAM then you don't need the rootfs anymore
20:25
<vagrantc>
hah
20:32quinox has left IRC (quinox!~quinox@ghost.qtea.nl, Quit: WeeChat 3.4)
20:34quinox has joined IRC (quinox!~quinox@ghost.qtea.nl)
20:47woernie has left IRC (woernie!~werner@p5ddec5e9.dip0.t-ipconnect.de, Remote host closed the connection)
20:49woernie has joined IRC (woernie!~werner@p5ddec5e9.dip0.t-ipconnect.de)
20:56
<alkisg>
j_sh: you just need to set up the bond before the nfs mount, at the initramfs
20:56
LTSP doesn't provide a "premount" hook, but you can easily add one using initramfs-tools
20:57
NFS and SSHFS work fine with one bonded IP using two NICs
20:58
You could probably even do it at PRE_INITRD_BOTTOM, if you're willing to unmount the nfs which initramfs-tools has mounted, do the bond, then mount it once more
21:00* alkisg forgot to wave... /me waves! :)
21:01
<alkisg>
vagrantc: have you seen this one? I'm not sure how to handle it: https://github.com/epoptes/epoptes/pull/152
21:03
<vagrantc>
oh yeah, bonded interfaces :)
21:04
<alkisg>
In one setup, my servers have 2*40Gbps bonds, I'm finally able to broadcast HD youtube to multiple clients via epoptes :D
21:05
<vagrantc>
alkisg: looks fine from a debian perspective, but if you're backporting to ancient distros which lack those features ...
21:06
<alkisg>
I think we can scratch Jessie and Ubuntu 16.04, but I'd like to keep Stretch and Ubuntu 18.04 until they're EOLed...
21:07
Essentially they're removing dpkg-deb, right?
21:08
<vagrantc>
a versioned requirement on dpkg-dev, and removing files present in older versions of epoptes
21:08
the versioned dpkg-dev is required for the rm_conffile feature that's dropped
21:09
<alkisg>
So only people *upgrading* epoptes from <= buster would see a difference, right? Not clean installations...
21:10
(btw why is rm_conffile removed? it's handled automatically now?)
21:10
<vagrantc>
yes
21:11
<alkisg>
Ah so essentially only people upgrading from stock buster to buster + ppa would see the problem... no harm done then, I can just auto-merge that
21:11
<vagrantc>
alkisg: i think it may be off-by-one release ... the conffiles are still present in buster
21:12
alkisg: so they would be needed to upgrade from buster to bullseye
21:12
<alkisg>
So we should wait until bookworm?
21:12
<vagrantc>
but to upgrade from bullseye to bookworm, it shouldn't be needed ... although your PPA might introduce some oddities
21:12
<alkisg>
I'm OK with "PPA == clean installations, no upgrade support"
21:13
If they upgrade from vanilla buster to vanilla bullseye, they'll get the existing epoptes, which does have the rm_conffiles
21:13
<vagrantc>
ok, then it should be fine to update in bookworm, but we shouldn't try to get it into bullseye
21:13
yeah
21:13
<alkisg>
Sounds good to me
21:14
Thanks!
21:14
<vagrantc>
alkisg: at least, that's assuming i'm understanding why the rm_conffiles is proposed to be removed
21:15
it's also harmless to leave it in a little while, too :)
21:15
<alkisg>
Let's postpone it for right before bookworm then :)
21:15
<vagrantc>
heh
21:16
which, apparently we have soft dates for ...
21:16
e.g. freezing early 2023
21:47j_sh has left IRC (j_sh!~j_sh@ip-209-124-249-106.static.eatel.net, Ping timeout: 256 seconds)
22:15Vercas5 has joined IRC (Vercas5!~Vercas@gateway/tor-sasl/vercas)
22:17Vercas has left IRC (Vercas!~Vercas@gateway/tor-sasl/vercas, Remote host closed the connection)
22:17Vercas5 is now known as Vercas
23:27jgee636 has left IRC (jgee636!~jgee@186.80.49.20, Quit: Ping timeout (120 seconds))
23:27jgee636 has joined IRC (jgee636!~jgee@186.80.49.20)