=== 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 | ||
pytorch | anyone can help me improve my boot time -> https://paste.debian.net/1198810/ | 05:19 |
---|---|---|
=== blueeagle is now known as BlueEagle | ||
ikonia | pytorch: probably worth moving to libera chat | 07:14 |
ikonia | where people are active | 07:14 |
=== gpiccoli_ is now known as gpiccoli | ||
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:31 |
* rick_h waves to the server crew | 13:47 | |
athos | o/ | 13:47 |
Ussat | O/ | 13:48 |
maswan | ah, it's probably the broken systemd deps, we'll try waiting for nework-online.target (and chrony just to be sure). | 14:15 |
=== 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 | ||
bittin_ | good afternoon | 15:27 |
=== pizzaiolo is now known as pizza | ||
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:16 |
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:21 |
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:23 |
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:25 |
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:26 |
sarnold | genkgo: oh hmm. this is well beyond my familiarity :( | 19:27 |
genkgo | sarnold: mine too, I am already happy I came this far. This is the final step. | 19:28 |
genkgo | But, let's give it a try without gateway4 | 19:31 |
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:43 |
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:44 |
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:45 |
genkgo | so I have one application using ens19 and ens20, everything works totally fine for that application | 19:46 |
genkgo | but other applications cannot connect to any IP inside the subnet of ens19 and ens20 | 19:47 |
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:48 |
genkgo | sarnold: otherwise I was not able to get ens19 and ens20 working anyhow | 19:49 |
genkgo | sarnold: it already took me hours to reach this point, via multiple routing policies and tables | 19:50 |
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:52 |
genkgo | Ussat: what would you suggest to do? | 19:56 |
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:08 |
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:19 |
maret | I run echo 2 | sudo tee /sys/class/hwmon/hwmon4/pwm2_enable but the fan is still going hard :/ | 20:28 |
genkgo | sarnold: since you were also eager on this topic, here is the explanation | 20:39 |
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:40 |
genkgo | unless you noprefixroute to the ip addr add command | 20:41 |
sarnold | genkgo: hey!! excellent :D :D | 21:07 |
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:08 |
ddstreet | genkgo you want to use the systemd.network config param AddPrefixRoute=false | 21:10 |
ddstreet | however, if you really don't want the prefix route, you probably actually want to use a /32 netmask instead of /24 | 21:11 |
=== ember_ is now known as ember | ||
genkgo | ddstreet: I found that config, thanks | 21:39 |
genkgo | For me /32 was not working | 21:40 |
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:46 |
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:48 |
genkgo | should look into that | 21:49 |
genkgo | but it is already late here, is for tomorrow | 21:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!