[05:19] <pytorch> anyone can help me improve my boot time -> https://paste.debian.net/1198810/
[07:14] <ikonia> pytorch: probably worth moving to libera chat
[07:14] <ikonia> where people are active
[13:31] <maswan> Hey, so, this is the second time this has happened. After we restart our resolver cluster, bind9 fails to resolve anything with "broken trust chain resolving" .. logged. if we do a bind9 restart everything starts working fine. anyone seen that before (we're on focal)?
[13:47]  * rick_h waves to the server crew
[13:47] <athos> o/
[13:48] <Ussat> O/
[14:15] <maswan> ah, it's probably the broken systemd deps, we'll try waiting for nework-online.target (and chrony just to be sure).
[15:27] <bittin_> good afternoon
[19:16] <genkgo> Hello, I am looking for some help with multiple interface networking via netplan. I have one local IP, and two external. I want my local interface to be able to connect to addresses inside the subnet of the external IPs, which fails at the moment.
[19:16] <genkgo> I have published my netplan config: https://gist.github.com/frederikbosch/10a27b897b5ea8eb685370d8c0084fdf
[19:21] <sarnold> genkgo: that's way more advanced than I've ever done, so this is a *guess*, but that 'gateway4' line feels out of place -- afterall you've got a 0.0.0.0/0 route declared later on
[19:23] <genkgo> hmm, maybe I should not include gateway4, but then the question is, if there is no gateway4, then what will the default route be?
[19:25] <sarnold> my guess is the 0.0.0.0/0 route on ens19
[19:25] <genkgo> okay, what if I want ens18 to be the default, then I should add manual route for ens18 as well
[19:26] <genkgo> sarnold: basically I want it configured as this: only use ens19 and ens20 when there is a direct bind on it, otherwise use ens18.
[19:26] <sarnold> genkgo: and probably set the metric for it so it's preferred, no?
[19:26] <genkgo> sarnold: but they are already using different routing tables, then metric makes no difference, or does it?
[19:27] <sarnold> genkgo: oh hmm. this is well beyond my familiarity :(
[19:28] <genkgo> sarnold: mine too, I am already happy I came this far. This is the final step.
[19:31] <genkgo> But, let's give it a try without gateway4
[19:43] <genkgo> sarnold: disabling gateway4 and adding a manual 0.0.0.0/0 route for ens18 is not the solution, maybe it should be done with a routing-policy
[19:43] <Ussat> ^^^
[19:44] <Ussat> Everything can not (nor should be ) done in netplan
[19:44] <sarnold> genkgo: how do you get each applicatioon to know which routing table it ought to be using?
[19:45] <genkgo> sarnold: the application that needs the external IPs, knows this, it binds directly to those IPs
[19:45] <genkgo> but the problem arises for the other applications
[19:45] <genkgo> which may not use the external IPs, but must use the internal IP
[19:46] <genkgo> so I have one application using ens19 and ens20, everything works totally fine for that application
[19:47] <genkgo> but other applications cannot connect to any IP inside the subnet of ens19 and ens20
[19:48] <sarnold> genkgo: oh sure when they know enough to bind to a specific source address, but very few do that, they just let the kernel pick whichever address is 'best' given their destination..
[19:48] <sarnold> genkgo: but, and this is where I get real shaky real fast, what's the point of having multiple routing tables? it's to put different groups of processes onto different 'networks' entirely, no?
[19:49] <genkgo> sarnold: otherwise I was not able to get ens19 and ens20 working anyhow
[19:50] <genkgo> sarnold: it already took me hours to reach this point, via multiple routing policies and tables
[19:52] <genkgo> sarnold: so may main goal is to use ens19 and ens20 only when a certain application explicitly requests its usage, otherwise use ens18.
[19:56] <genkgo> Ussat: what would you suggest to do?
[20:08] <maret> hi, i run pwmconfig just to try it and now  my fan on motherboard is spinning . What should I do ? this is the ouput -> https://paste.debian.net/1198906/
[20:19] <genkgo> sarnold: I found the solution, ip route del 46.0.0.0/24 dev ens19 proto kernel scope link src
[20:19] <genkgo> now the question becomes how to prevent netplan from adding it
[20:28] <maret> I run echo 2 | sudo tee /sys/class/hwmon/hwmon4/pwm2_enable  but the fan is still going hard :/ 
[20:39] <genkgo> sarnold: since you were also eager on this topic, here is the explanation
[20:40] <genkgo> if you add an ip address the kernel will automatically add a direct route (proto kernel scope link) automatically to the routing table
[20:40] <genkgo> this cannot be prevented
[20:41] <genkgo> unless you noprefixroute to the ip addr add command
[21:07] <sarnold> genkgo: hey!! excellent :D :D
[21:08] <sarnold> genkgo: could you file a bug report about that? it feels like something netplan ought to expose for cases like yours
[21:08] <sarnold> genkgo: I don't know for sure if systemd-networkd has syntax for that, or not, but if not having a bug report somewhere about it would be a good start
[21:10] <ddstreet> genkgo you want to use the systemd.network config param AddPrefixRoute=false
[21:11] <ddstreet> however, if you really don't want the prefix route, you probably actually want to use a /32 netmask instead of /24
[21:39] <genkgo> ddstreet: I found that config, thanks
[21:40] <genkgo> For me /32 was not working
[21:46] <genkgo> ddstreet: if I remove the prefix route, I now find out that containers using my fan overlay network are still failing to connect to the externals IP addresses
[21:48] <genkgo> but if I can make /32 working, I think that should resolve that
[21:48] <genkgo> When changed the addresses in netplan into a /32 address, netplan failed
[21:49] <genkgo> should look into that
[21:49] <genkgo> but it is already late here, is for tomorrow