|01:52||vagrantc has left IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:20, Quit: leaving)|
|07:12||Vercas has left IRC (Vercas!~Vercas@gateway/tor-sasl/vercas, Remote host closed the connection)|
|07:12||ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)|
|07:14||Vercas has joined IRC (Vercas!~Vercas@gateway/tor-sasl/vercas)|
|07:39||woernie has joined IRC (firstname.lastname@example.org)|
|08:09||woernie has left IRC (email@example.com, Ping timeout: 252 seconds)|
|08:10||woernie has joined IRC (firstname.lastname@example.org)|
|09:01||woernie has left IRC (email@example.com, Remote host closed the connection)|
|09:56||shored1 has joined IRC (shored1!~shored@user/shored)|
|09:56||shored has left IRC (shored!~shored@user/shored, Ping timeout: 240 seconds)|
|12:22||eu^245red-213-96 has joined IRC (firstname.lastname@example.org)|
|12:30||woernie has joined IRC (email@example.com)|
|12:37||woernie has left IRC (firstname.lastname@example.org, Quit: No Ping reply in 180 seconds.)|
|12:38||woernie has joined IRC (email@example.com)|
|12:44||eu^245red-213-96 has left IRC (firstname.lastname@example.org, Quit: Client closed)|
|13:23||lucascastro has left IRC (email@example.com, Read error: Connection reset by peer)|
|13:24||lucascastro has joined IRC (firstname.lastname@example.org)|
|14:21||lucascastro has left IRC (email@example.com, Ping timeout: 268 seconds)|
|14:46||woernie has left IRC (firstname.lastname@example.org, Remote host closed the connection)|
|15:54||woernie has joined IRC (email@example.com)|
|16:00||vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:20)|
|16:24||woernie has left IRC (firstname.lastname@example.org, Remote host closed the connection)|
|17:05||lucascastro has joined IRC (email@example.com)|
|17:10||lucascastro has left IRC (firstname.lastname@example.org, Ping timeout: 240 seconds)|
|17:45||ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)|
|18:19||lucascastro has joined IRC (email@example.com)|
|19:28||woernie has joined IRC (firstname.lastname@example.org)|
|19:39||j_sh has joined IRC (email@example.com)|
Hello, all. I'm looking for advice on using multiple NICs on the clients. Anyone have any experience with this? Thanks.
first question would be why do you need that? :)
what's your use-case?
Redundancy in network architecture and cabling.
One cable from each of two NICs on the client going to different network switches
You can lose a cable or a switch and maintain connectivity to the LTSP server and other network resources.
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.
Haha. Industrial application. everything is redundant
you can run your own scripts on startup with POST_INIT_x
and so all network interfaces have the same ip address?
not sure if any of the network backends support changing ip addresses ...
for the rootfs
AoE, maybe ...
They can have different IPs. They can both be DHCP, too
As long as they can reach the server and that subnet in general
surely that breaks anything like an ssh session no?
Depends on how that stuff is configured :)
I've (happily) been using mosh, but it's not real SSH and comes with a lot of limitations
j_sh: the default rootfs these days is NFS, which does not handle changing ip addresses very well at all
j_sh: so you might have to explore alternatives to actually make that work
amoung other stateful protocols in use
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
notably sshfs, which is used for the homedirs by default
But, I don't see a way to do that here.
Next best thing is to put both MAC addresses in the config file and reboot the client if one goes down.
there's no out of the box way, but you can create that however you like :)
Not truly fault tolerant, but probably good enough.
:) I might try....
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
i seem to recall there's some support for that
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:32||quinox has left IRC (firstname.lastname@example.org, Quit: WeeChat 3.4)|
|20:34||quinox has joined IRC (email@example.com)|
|20:47||woernie has left IRC (firstname.lastname@example.org, Remote host closed the connection)|
|20:49||woernie has joined IRC (email@example.com)|
j_sh: you just need to set up the bond before the nfs mount, at the initramfs
LTSP doesn't provide a "premount" hook, but you can easily add one using initramfs-tools
NFS and SSHFS work fine with one bonded IP using two NICs
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! :)|
vagrantc: have you seen this one? I'm not sure how to handle it: https://github.com/epoptes/epoptes/pull/152
oh yeah, bonded interfaces :)
In one setup, my servers have 2*40Gbps bonds, I'm finally able to broadcast HD youtube to multiple clients via epoptes :D
alkisg: looks fine from a debian perspective, but if you're backporting to ancient distros which lack those features ...
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...
Essentially they're removing dpkg-deb, right?
a versioned requirement on dpkg-dev, and removing files present in older versions of epoptes
the versioned dpkg-dev is required for the rm_conffile feature that's dropped
So only people *upgrading* epoptes from <= buster would see a difference, right? Not clean installations...
(btw why is rm_conffile removed? it's handled automatically now?)
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
alkisg: i think it may be off-by-one release ... the conffiles are still present in buster
alkisg: so they would be needed to upgrade from buster to bullseye
So we should wait until bookworm?
but to upgrade from bullseye to bookworm, it shouldn't be needed ... although your PPA might introduce some oddities
I'm OK with "PPA == clean installations, no upgrade support"
If they upgrade from vanilla buster to vanilla bullseye, they'll get the existing epoptes, which does have the rm_conffiles
ok, then it should be fine to update in bookworm, but we shouldn't try to get it into bullseye
Sounds good to me
alkisg: at least, that's assuming i'm understanding why the rm_conffiles is proposed to be removed
it's also harmless to leave it in a little while, too :)
Let's postpone it for right before bookworm then :)
which, apparently we have soft dates for ...
e.g. freezing early 2023
|21:47||j_sh has left IRC (firstname.lastname@example.org, Ping timeout: 256 seconds)|
|22:15||Vercas5 has joined IRC (Vercas5!~Vercas@gateway/tor-sasl/vercas)|
|22:17||Vercas has left IRC (Vercas!~Vercas@gateway/tor-sasl/vercas, Remote host closed the connection)|
|22:17||Vercas5 is now known as Vercas|
|23:27||jgee636 has left IRC (email@example.com, Quit: Ping timeout (120 seconds))|
|23:27||jgee636 has joined IRC (firstname.lastname@example.org)|