| 16 Jan 2025 |
Arian | No we didn't change anything afaik | 09:09:02 |
Arian | This used to work | 09:09:05 |
@adam:robins.wtf | I used a runtime override two data ago on 24.11 | 12:09:45 |
gdamjan | seems to work here BUILD_ID="24.11.20250112.635e887" | 12:20:51 |
eliasp | weird - need to double check... it didn't on several attempts here yesterday | 17:00:20 |
@elvishjerricco:matrix.org | That's... interesting. I think they're unsatisfied with how not-like-a-directed-acyclic-graph the networking targets are. Like, my understanding is that reaching network.target indicates that the interfaces exist, network-online.target indicates protocols like IP addresses are established, and network-pre.target indicates that preparations for networking (e.g. firewalls) have been made. Unfortunately this seems like it breaks down when you get intermingling of these purposes. So if something belongs to multiple of these categories you're kind of screwed. Now, I'm not familiar with the software they're referencing (ndppd, bird), but it seems like they kind of fit within the domains of both network-online.target and network.target? I might be misunderstanding but it seems like they require interfaces to already exist and be set up for e.g. IP, and also create virtual interfaces? Or something? i.e. What we actually want is to have a service that depends on the physical interfaces that it needs; ordering around the networking targets seems ill-fit for this. | 23:40:46 |
@elvishjerricco:matrix.org | Which is an obscure use case | 23:41:17 |
@elvishjerricco:matrix.org | But it's exactly the sort of thing systemd was originally designed to improve. The ordering of units is a directed acyclic graph precisely because runlevels were a bad idea | 23:42:11 |
@elvishjerricco:matrix.org | and the networking targets are kind of like runlevels | 23:42:22 |
emily | bird is a BGP daemon fwiw | 23:45:07 |
@elvishjerricco:matrix.org | then I'm still confused about what it does :P Mainly because I don't know how BGP daemons work | 23:48:17 |
@elvishjerricco:matrix.org | like I know it's the main protocol for routing IP traffic but I don't understand what they require and provide at a systemd level. Like do they just need interfaces to exist? And then it provides some kind of routing services? | 23:49:38 |
@elvishjerricco:matrix.org | (routing IP traffic at like an ISP level I think, right?) | 23:50:14 |
gdamjan | bird supports bgp, ospf, rip(v2) | 23:52:57 |
gdamjan |
my understanding is that reaching network.target indicates that the interfaces exist
no, network.target means localhost works
| 23:54:26 |
gdamjan |
It must emphasized that at start-up there's no guarantee that hardware-based devices have shown up by the time this target is reached
| 23:55:43 |
@elvishjerricco:matrix.org | huh | 23:57:06 |
@elvishjerricco:matrix.org | TIL | 23:57:08 |
@elvishjerricco:matrix.org | I have apparently misunderstood that target for a long time | 23:57:17 |
@elvishjerricco:matrix.org | gdamjan: so then where should bird sit in this hierarchy? Ignoring the runlevel-like targets, what ought it be ordered before and after? | 23:59:12 |
gdamjan | I would probably set it similar to NetworkManager | 23:59:52 |
| 17 Jan 2025 |
gdamjan | there's an additional complexity (if I remember correctly) - you can have bird configure your interfaces too (static ips) but OTOH it might also depend on ip addresses being setup by your NM or networkd … so that would complicate strict ordering/dependencies
the good thing is, IIRC, bird actually does work properly on kernel netlink events and doesn't depend on preconfigured interfaces
| 00:02:13 |
gdamjan | so in short: WantedBy=multi-user.target After=network-pre.target and probably Before=network.target but not necessary this last thing | 00:02:48 |
@elvishjerricco:matrix.org | Ok interesting. Then I'm not sure what that person is complaining about because I think that's already how it is :P | 00:05:47 |
gdamjan | it was a really not-that-coherent rant imho :/ | 00:06:13 |
gdamjan | it's probably better if they take it here on the channel | 00:06:26 |
@elvishjerricco:matrix.org | hm, actually it looks like we don't have the After ordering. Huh. | 00:08:17 |
@elvishjerricco:matrix.org | I wonder if that's their real problem | 00:08:36 |
| chintuchamar joined the room. | 04:40:17 |
phaer | I am trying to get a public key into a systemd credential via kernel cmdline, but seem to hold it wrong. In my kernel params i got systemd.set_credential=login.motd:hello and see it in /proc/cmdline in the target machine. But systemd-creds --system doesn't show anything. Is there a hint what it might be or how to effectively debug this? | 15:17:04 |