Hi, On 7/9/24 23:01, Luca Boccassi wrote:
As per smcv's point, if you need to manually write a static configuration then you can also install your favourite tool to use it. This is not the default case - the default case is "I have ethernet and/or wifi and I want DHCP v4+v6 on anything that can talk to a router kkthxbye"
For a server installation, I absolutely need the option to configure a static IP from d-i text mode interface or a preseed file, and this configuration to be taken over into the installed system.
The last three machines I've installed I've used the IPMI console to set up the IP address, then used the "continue installation via ssh" function to do the main installation.
On one of these networks was a rogue DHCP server. :P
I'm not sure if systemd-networkd is much happier long-term if we write its configuration from a shell script, we'd need to get some commitment from upstream that this is an interface, not an implementation detail, at least.
I'm not sure what this means, you can write networkd configuration files from wherever you like, the tool doesn't care, it wouldn't even be able to tell the difference anyway, just drop them in the appropriate location in /etc/ and off you go.
That's my question, essentially: is this an interface with full support from upstream, or something that may change in an incompatible way later that will require us to deploy additional infrastructure to support?
The key feature of both sysvinit and ifupdown, from Debian's perspective, has always been control: with sysvinit, there were no "upstream" definitions, it was all defined by us as part of Debian Policy, and if we needed to change anything, we could do that without introducing an incompatibility; with ifupdown, we are also upstream, and therefore upstream is aware that if they want to change the configuration file format, they have to talk to all the other stakeholders inside the project and coordinate that change.
With systemd, we no longer have that level of control and large parts of Policy are now defined externally, and on an external schedule that does not match our release schedule. That is not necessarily a bad thing, but it is a huge deviation from our slow but reliable processes of the past where we could delay a change until it was ready for release.
So we need to weigh all the benefits of switching to systemd-networkd against the drawback that we are again tying part of our system to an externally defined release schedule, so we will need to nominate someone who will be responsible for integrating any changes that will be required as a result of upstream changes in a timely manner, and in a way that does not introduce any more technical debt.
The issue is not whether we can hack together a perl script *now*, but how big of a commitment that change can potentially be. If we can get a guarantee that any changes to that interface will be communicated two years in advance, that calculation is entirely different than when it can change with any upstream release and we need to provide an upgrade path with the next backport package or risk breaking "stable" systems that for some reason have backports of core system packages installed.
I fully expect some breaking changes, as we are storing the WiFi credentials into a configuration file, when they should be stored in some secrets manager -- so this is already "legacy", and I'm not sure if it is a "legacy interface" or a "legacy implementation detail."
Simon
