=== Napsterbater is now known as Guest21382 === Napsterbater_ is now known as Napsterbater === Napsterbater is now known as Guest32646 === Napsterbater_ is now known as Napsterbater === Napsterbater_ is now known as Napsterbater [05:19] anyone can help me improve my boot time -> https://paste.debian.net/1198810/ === blueeagle is now known as BlueEagle [07:14] pytorch: probably worth moving to libera chat [07:14] where people are active === gpiccoli_ is now known as gpiccoli [13:31] 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] o/ [13:48] O/ [14:15] ah, it's probably the broken systemd deps, we'll try waiting for nework-online.target (and chrony just to be sure). === pizza is now known as pizzaiolo === fjmorazan is now known as help === help is now known as fjmorazan === 038AAATSO is now known as mastablasta === mastablasta is now known as gregor3000 [15:27] good afternoon === pizzaiolo is now known as pizza [19:16] 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] I have published my netplan config: https://gist.github.com/frederikbosch/10a27b897b5ea8eb685370d8c0084fdf [19:21] 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] 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] my guess is the 0.0.0.0/0 route on ens19 [19:25] okay, what if I want ens18 to be the default, then I should add manual route for ens18 as well [19:26] 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] genkgo: and probably set the metric for it so it's preferred, no? [19:26] sarnold: but they are already using different routing tables, then metric makes no difference, or does it? [19:27] genkgo: oh hmm. this is well beyond my familiarity :( [19:28] sarnold: mine too, I am already happy I came this far. This is the final step. [19:31] But, let's give it a try without gateway4 [19:43] 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] ^^^ [19:44] Everything can not (nor should be ) done in netplan [19:44] genkgo: how do you get each applicatioon to know which routing table it ought to be using? [19:45] sarnold: the application that needs the external IPs, knows this, it binds directly to those IPs [19:45] but the problem arises for the other applications [19:45] which may not use the external IPs, but must use the internal IP [19:46] so I have one application using ens19 and ens20, everything works totally fine for that application [19:47] but other applications cannot connect to any IP inside the subnet of ens19 and ens20 [19:48] 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] 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] sarnold: otherwise I was not able to get ens19 and ens20 working anyhow [19:50] sarnold: it already took me hours to reach this point, via multiple routing policies and tables [19:52] 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] Ussat: what would you suggest to do? [20:08] 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] sarnold: I found the solution, ip route del 46.0.0.0/24 dev ens19 proto kernel scope link src [20:19] now the question becomes how to prevent netplan from adding it [20:28] I run echo 2 | sudo tee /sys/class/hwmon/hwmon4/pwm2_enable but the fan is still going hard :/ [20:39] sarnold: since you were also eager on this topic, here is the explanation [20:40] 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] this cannot be prevented [20:41] unless you noprefixroute to the ip addr add command [21:07] genkgo: hey!! excellent :D :D [21:08] genkgo: could you file a bug report about that? it feels like something netplan ought to expose for cases like yours [21:08] 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] genkgo you want to use the systemd.network config param AddPrefixRoute=false [21:11] however, if you really don't want the prefix route, you probably actually want to use a /32 netmask instead of /24 === ember_ is now known as ember [21:39] ddstreet: I found that config, thanks [21:40] For me /32 was not working [21:46] 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] but if I can make /32 working, I think that should resolve that [21:48] When changed the addresses in netplan into a /32 address, netplan failed [21:49] should look into that [21:49] but it is already late here, is for tomorrow