While discussing pending issues with Santiago (ifupdown's de-facto maintainer), we came to the conclusion that team maintenance of just
one ifupdown implementation would be a better way to go than having 3 different implementations of the same.
This e-mail is meant to launch discussion over which of the 3
implementations would be the best candidate for this.
On Sun, Jul 07, 2024 at 12:38:34PM +0300, Martin-Éric Racine wrote:
While discussing pending issues with Santiago (ifupdown's de-facto maintainer), we came to the conclusion that team maintenance of just
one ifupdown implementation would be a better way to go than having 3 different implementations of the same.
Is that discussion public? What's the reasoning of that conclusion?
Frankly I don't think we should be having this/these discussions in
private. So I'm CC'ing d-devel for lack of a better suited ML.
This e-mail is meant to launch discussion over which of the 3 implementations would be the best candidate for this.
Santiago, how do you feel about ifupdown's future maintainability and
feature development? I honestly never looked into why people started
writing ifupdown replacements. I had my own gripes with it so I never questioned it but I'm happy to hear why we should all rally around it.
For me the reason to work on ifupdown-ng is that it has a better core
design, clean&modern code, an active upstream community, a ***test suite*** and the potential to fully replace ifupdown without breaking anyone's
system doing it. Full compatibility is not there yet. I'm working on it,
see [1] but I'm optimistic so far.
[1]: https://github.com/ifupdown-ng/ifupdown-ng/issues/247
From where I'm sitting ifupdown2 is completely out of the question as *the* Debian ifupdown since it doesn't even support *basic* IPv6 use-cases like DHCPv6. Upstream community seems nonexistant since this is software by a
corp for a corp where community building was probably never the
goal. Admittedly I didn't look very hard, this is just my impression currently.
DHCP on the other hand affects us all. I'd be very much on board with
pooling resources around that.
su 7. heink. 2024 klo 16.56 Daniel Grber (dxld@darkboxed.org) kirjoitti:
On Sun, Jul 07, 2024 at 12:38:34PM +0300, Martin-ric Racine wrote:
While discussing pending issues with Santiago (ifupdown's de-facto maintainer), we came to the conclusion that team maintenance of just
one ifupdown implementation would be a better way to go than having 3 different implementations of the same.
Is that discussion public? What's the reasoning of that conclusion?
Not until now.
Basically, there's pending issues involving ifupdown and DHCP clients
that I've randomly discussed with Santiago.
One of these is to swap the default DHCP client (isc-dhcp-client
i.e.dhclient to dhcpcd-base).
Another is the plethora of unresolved issues with ifupdown and
Santiago's limited time to devote to its maintenance. He initially
asked if I'd be interested in maintaining it, then pondered whether
having 3 implementations even makes sense to begin with. I suggested contacting the maintainers of all 3 implementation to discuss this.
This e-mail is meant to launch discussion over which of the 3 implementations would be the best candidate for this.
Santiago, how do you feel about ifupdown's future maintainability and feature development? I honestly never looked into why people started writing ifupdown replacements. I had my own gripes with it so I never questioned it but I'm happy to hear why we should all rally around it.
I've long wondered how we ended up with so many implementations. Team maintenance of just one implementation would make more sense.
For me the reason to work on ifupdown-ng is that it has a better core design, clean&modern code, an active upstream community, a ***test suite***
and the potential to fully replace ifupdown without breaking anyone's system doing it. Full compatibility is not there yet. I'm working on it, see [1] but I'm optimistic so far.
[1]: https://github.com/ifupdown-ng/ifupdown-ng/issues/247
Noted.
From where I'm sitting ifupdown2 is completely out of the question as *the* Debian ifupdown since it doesn't even support *basic* IPv6 use-cases like DHCPv6. Upstream community seems nonexistant since this is software by a corp for a corp where community building was probably never the
goal. Admittedly I didn't look very hard, this is just my impression currently.
That's also my impression.
DHCP on the other hand affects us all. I'd be very much on board with pooling resources around that.
dhcpcd covers both v4 and v6 transparently and also provides IPv6-PD.
The current plan is to swap ifupdown's default to prefer it to
dhclient and to swap Priority between dhclient and dhcpcd-base.
dhcpcd covers both v4 and v6 transparently and also provides IPv6-PD.
The current plan is to swap ifupdown's default to prefer it to
dhclient and to swap Priority between dhclient and dhcpcd-base.
And we would need to the change in the override first, isn't it? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038882
For me the reason to work on ifupdown-ng is that it has a better core
design, clean&modern code, an active upstream community, a ***test suite*** and the potential to fully replace ifupdown without breaking anyone's
system doing it. Full compatibility is not there yet. I'm working on it,
see [1] but I'm optimistic so far.
[1]: https://github.com/ifupdown-ng/ifupdown-ng/issues/247
I just had a look at ifupdown-ng. The /etc/network/interface syntaxAgreed: either it's drop-in compatible or we may as well switch the
is not a drop-in replacement for ifupdown. That's a big no-no. Those
"use dhcp" have to go.
su 7. heinäk. 2024 klo 16.56 Daniel Gröber (dxld@darkboxed.org) kirjoitti:
For me the reason to work on ifupdown-ng is that it has a better core design, clean&modern code, an active upstream community, a ***test suite*** and the potential to fully replace ifupdown without breaking anyone's system doing it. Full compatibility is not there yet. I'm working on it, see [1] but I'm optimistic so far.
[1]: https://github.com/ifupdown-ng/ifupdown-ng/issues/247
I just had a look at ifupdown-ng. The /etc/network/interface syntax
is not a drop-in replacement for ifupdown. That's a big no-no. Those
"use dhcp" have to go.
If the auto_executor_selection ifupdown-ng.conf option is enabled, use
statements will automatically be added for executors when their config‐
uration statements are present in the interfaces file.
Santiago, how do you feel about ifupdown's future maintainability and feature development? I honestly never looked into why people started writing ifupdown replacements. I had my own gripes with it so I never questioned it but I'm happy to hear why we should all rally around it.
I've long wondered how we ended up with so many implementations. Team maintenance of just one implementation would make more sense.
For me the reason to work on ifupdown-ng is that it has a better core design, clean&modern code, an active upstream community, a ***test suite***
I fully acknowledge this. After trying to fix some of the ifupdown bugs
but hitting some design issues,
I think it makes more sense to focus all
the efforts in just one of the implementations, and since ifupdown-ng
has all the above mentioned advantages, I'd would be in favor of
replacing ifupdown by ifupdown-ng...
and the potential to fully replace ifupdown without breaking anyone's system doing it. Full compatibility is not there yet. I'm working on it, see [1] but I'm optimistic so far.
[1]: https://github.com/ifupdown-ng/ifupdown-ng/issues/247
Noted.
... but it would be *great* to make ifupdown-ng a drop-in replacement
first.
From where I'm sitting ifupdown2 is completely out of the question as *the* Debian ifupdown since it doesn't even support *basic* IPv6 use-cases like DHCPv6. Upstream community seems nonexistant since
this is software by a corp for a corp where community building was probably never the goal. Admittedly I didn't look very hard, this is
just my impression currently.
That's also my impression.
and the python dependency makes me consider ifupdown2 as not an option.
Agreed: either it's drop-in compatible or we may as well switch the
default to NM and/or systemd-networkd.
Well, here's a heretical thought: why don't we do that anyway, at
least for new installations?
Somebody could even write a converter. Shouldn't be that difficult,
AFAIK there's nothing ifupdown can do that systemd[-networkd] can't.
On Tue, Jul 09, 2024 at 09:26:50AM +0300, Martin-Éric Racine wrote:
su 7. heinäk. 2024 klo 16.56 Daniel Gröber (dxld@darkboxed.org) kirjoitti:
For me the reason to work on ifupdown-ng is that it has a better core design, clean&modern code, an active upstream community, a ***test suite***
and the potential to fully replace ifupdown without breaking anyone's system doing it. Full compatibility is not there yet. I'm working on it, see [1] but I'm optimistic so far.
[1]: https://github.com/ifupdown-ng/ifupdown-ng/issues/247
I just had a look at ifupdown-ng. The /etc/network/interface syntax
is not a drop-in replacement for ifupdown. That's a big no-no. Those
"use dhcp" have to go.
Not reading the documentation carefully is a bigger no-no :)
For legacy configurations statements "use" is optional:
If the auto_executor_selection ifupdown-ng.conf option is enabled, use
statements will automatically be added for executors when their config‐
uration statements are present in the interfaces file.
The idea being that your config should declare the "executor" scripts it needs, a good thing IMO.
That being said I'm sure there are a couple of dark corners where
ifupdown-ng is not yet compatible that I haven't noticed yet, but this
isn't one of them.
Please note that the examples in the manpages are in what upstream
considers the "proper new way" of doing things, they don't show the legacy way (also a good thing), you may have to read the code to get the full picture. Do let me know if any legacy-format behavioural reference-documentation is missing though.
Since I only just realised people may now actually want to try out ifupdown-ng: You can co-install it with traditional ifupdown with --no-install-recommends, the ifupdown-ng-compat package is the one that conflicts: ifupdown. ifupdown-ng itself doesn't.
Use ifup-ng/ifdown-ng, check dpkg -L for manpages some are named *-ng some aren't. Executors have their own interfaces-* manpage eg. interfaces-bridge(5).
Matthias Urlichs <matthias@urlichs.de> writes:
Somebody could even write a converter. Shouldn't be that difficult,
AFAIK there's nothing ifupdown can do that systemd[-networkd] can't.
Run user scripts on up/down events. That's a huge blank spot in systemd-networkd. And by design, so it's really not fixable.
I just had a look at ifupdown-ng. The /etc/network/interface syntax
is not a drop-in replacement for ifupdown. That's a big no-no. Those
"use dhcp" have to go.
Not reading the documentation carefully is a bigger no-no :)
For legacy configurations statements "use" is optional:
If the auto_executor_selection ifupdown-ng.conf option is
enabled, use statements will automatically be added for
executors when their config‐ uration statements are present in
the interfaces file.
Which is not a drop-in substitute. It depends upon a configuratiomn option.
Please note that the examples in the manpages are in what upstream considers the "proper new way" of doing things, they don't show the legacy way (also a good thing), you may have to read the code to get the full picture. Do let me know if any legacy-format behavioural reference-documentation is missing though.
Claiming to offer a drop-in substitute all while nudging people
towards a new paradigm is not welcome.
Since I only just realised people may now actually want to try out ifupdown-ng: You can co-install it with traditional ifupdown with --no-install-recommends, the ifupdown-ng-compat package is the one that conflicts: ifupdown. ifupdown-ng itself doesn't.
Use ifup-ng/ifdown-ng, check dpkg -L for manpages some are named *-ng some aren't. Executors have their own interfaces-* manpage eg. interfaces-bridge(5).
Which again shows that this is not a drop-in substitute.
Hi,
On 7/9/24 17:57, Matthias Urlichs wrote:
Agreed: either it's drop-in compatible or we may as well switch the
default to NM and/or systemd-networkd.
Well, here's a heretical thought: why don't we do that anyway, at least
for new installations?
Both are overly complex for a static-IP-only server installation, where
there is no requirement for an unprivileged user to modify the network configuration, or any background process at all, really. At least in
expert mode I would expect a way to generate a static,
unmanaged-by-anything configuration.
What would be needed for new installations is d-i support, mainly, and
the difficulty there is saving the configuration.
I believe NM does not have a fixed configuration format, but only a dbus
API. Our best bet there would be a firstboot unit, but I have no idea
whether accessing NM from a unit attached to firstboot is safe or leads
to a dependency loop[1].
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.
Agreed: either it's drop-in compatible or we may as well switch the
default to NM and/or systemd-networkd.
Well, here's a heretical thought: why don't we do that anyway, at least
for new installations?
I believe NM does not have a fixed configuration format, but only a dbus API.
Our best bet there would be a firstboot unit, but I have no idea
whether accessing NM from a unit attached to firstboot is safe or leads
to a dependency loop[1].
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.
On Tue, 2024-07-09 at 22:44 +0900, Simon Richter wrote:
I believe NM does not have a fixed configuration format, but only a dbus API.
It's perfectly fine to edit configuration files for NM manually, see man:nm-settings-keyfile(5).
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"
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.
On 09.07.24 12:27, Bjørn Mork wrote:
Run user scripts on up/down events. That's a huge blank spot in
systemd-networkd. And by design, so it's really not fixable.
Well, I've been apt-purging ifupdown for almost a decade by now and
didn't yet miss any of it.
You can think whether that script is still required; maybe
systemd-networkd / -resolved can do it for you.
Or you can monitor systemd's and systemd-networkd's dbus for network
devices appearing (or vanishing) and run the requisite script.
Or you can use udev rules.
Or you can tell a unit to run only when a specific network interface
is present.
Or you can use NM and its script dispatcher instead.
Or, well, you can of course continue to use ifupdown if none of the
above work for you. But that doesn't mean ifupdown should be the
default IMHO.
Just tried to point out that automatic conversion will be hard. AndAnd I believe that nobody argued to do that.
For a server installation, I absolutely need the option to configure aI do not understand why you are explaining this as if it were some
static IP from d-i text mode interface or a preseed file, and this configuration to be taken over into the installed system.
That's my question, essentially: is this an interface with full support from upstream, or something that may change in an incompatible way later thatMultiple people, one of the systemd upstream maintainers among them,
will require us to deploy additional infrastructure to support?
The key feature of both sysvinit and ifupdown, from Debian's perspective,What you mean is that it has always been that they were basically
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
So we need to weigh all the benefits of switching to systemd-networkdBut we switched to NM for Wi-Fi enabled systems and the sky has not
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
It is supported *now*, but the roadmap is unclear -- that support could
be discontinued at any moment, and it would not be the first time a
feature Debian relied on was removed.
On Thu, 2024-07-11 at 05:14 +0900, Simon Richter wrote:
It is supported *now*, but the roadmap is unclear -- that support could
be discontinued at any moment, and it would not be the first time a
feature Debian relied on was removed.
I understand your fears about the uncertainty of future developments.
After all ifupdown is without doubt in a bit problematic state due to >isc-dhcp-client no longer being supported, a feature Debian relied on,
and as far as we know the support for alternatives like dhcpcd-base
could end at any time as well.
It is supported *now*, but the roadmap is unclear -- that support could
be discontinued at any moment, and it would not be the first time a
feature Debian relied on was removed.
I understand your fears about the uncertainty of future developments.
After all ifupdown is without doubt in a bit problematic state due to isc-dhcp-client no longer being supported, a feature Debian relied on,
and as far as we know the support for alternatives like dhcpcd-base
could end at any time as well.
Debian already relies on a fairly large set of base software like gcc,
linux, glibc, systemd, ... So it seems reasonable to try to not grow
that list much further to address your concerns.
Users may choose to opt-in to the more declarative "use" stanzas if they
wish and I'd expect any new upstream executors like vrf will need them (haven't tried) but not traditional stanzas or if-*.d based extensions.
I wish ifupdown-ng upstream hadn't chosen to introduce an additional set of global config options in /etc/network/ifupdown-ng.conf and I am still
mulling getting rid of that somehow but so far I don't see a real problem there.
Please note that the examples in the manpages are in what upstream considers the "proper new way" of doing things, they don't show the legacy
way (also a good thing), you may have to read the code to get the full picture. Do let me know if any legacy-format behavioural reference-documentation is missing though.
Claiming to offer a drop-in substitute all while nudging people
towards a new paradigm is not welcome.
If ifupdown's paradigm were working for people we wouldn't be having this conversation.
How else would you move /etc/network/interfaces forward without breaking anything?
This is quite unfair. Cumulus tried very hard to make ifupdown2 a community projects, with notably a presentation at Debconf 14 and Debconf 16. One of its killer feature is the ability to go from the running state to the target state with one command (ifreload). It never took as we prefer old broken software over something not 100% compatible and also because it is writtenI agree, but I think that the dependency on Python has legitimately been
in Python and we didn't want Python in the base installation.
Since Cumulus has been bought by Nvidia, things have changed and development of ifupdown2 is now done behind closed doors. See https://github.com/CumulusNetworks/ifupdown2/pull/271#issuecomment-1706260260And this pretty much closes the question.
It is supported *now*, but the roadmap is unclear -- that support could be discontinued at any moment, and it would not be the first time a feature Debian relied on was removed.You have manufactured a non-existing issue and then decided to get
Well, I've been apt-purging ifupdown for almost a decade by now and
didn't yet miss any of it.
From where I'm sitting ifupdown2 is completely out of the question as *the*
Debian ifupdown since it doesn't even support *basic* IPv6 use-cases like DHCPv6. Upstream community seems nonexistant since this is software by a corp for a corp where community building was probably never the
goal. Admittedly I didn't look very hard, this is just my impression currently.
This is quite unfair. Cumulus tried very hard to make ifupdown2 a
community projects, with notably a presentation at Debconf 14 and Debconf
16. [...] It never took as we prefer old broken software over something
not 100% compatible and also because it is written in Python and we
didn't want Python in the base installation.
Since Cumulus has been bought by Nvidia, things have changed and development of ifupdown2 is now done behind closed doors. See https://github.com/CumulusNetworks/ifupdown2/pull/271#issuecomment-1706260260
One of its killer feature is the ability to go from the running state to
the target state with one command (ifreload).
Claiming to offer a drop-in substitute all while nudging people
towards a new paradigm is not welcome.
If ifupdown's paradigm were working for people we wouldn't be having this conversation.
The paradigm is working.
How else would you move /etc/network/interfaces forward without breaking anything?
I would really like to hear what is wrong with the current format.
For my perspective, the main issues with ifupdown are:
1) ifupdown doesn't handle bridges and vlans without external
packages, yet it already depends upon iproute2, which provides 'ip'
i.e. a command that can handle these quite nicely.
2) ifupdown doesn't include a way to handle DHCPv6-PD for all
supported DHCP clients.
3) Since the introduction of systemd units, one can no longer rely on interfaces being brought up sequentially following the order in which
they appear in /etc/network/interfaces.
4) That systemd unit generation blissfully ignores anything else that physical interfaces in /etc/network/interfaces which introduces yet
more reproducibility problems.
On Thu, Jul 11, 2024 at 11:23:38AM +0300, Martin-Éric Racine wrote:
Claiming to offer a drop-in substitute all while nudging people
towards a new paradigm is not welcome.
If ifupdown's paradigm were working for people we wouldn't be having this conversation.
The paradigm is working.
I mean looking at the other half of this thread, clearly the ifupdown* paradigm isn't working at all for some people which I think is
unfortunate. I just want to point out that -ng comes as a library too
(which I haven't packaged separately yet) so integrating with /etc/network/interfaces and even the interface state should very much be possible for any other network managment tool that would want to.
I still think you're making too much of this `use` feature. I had a conversation with upstream about it and took another look at the code and it's basically just an optimization to *only* run the delcared executors as opposed to all of them (in case any of their config stanzas are used).
How else would you move /etc/network/interfaces forward without breaking anything?
I would really like to hear what is wrong with the current format.
I'd like to hear what is wrong with making the current format more
extensible with full legacy compatibility?
The format is fine, but ofc. ifupdown-ng is going to extend it where it
makes sense.
For my perspective, the main issues with ifupdown are:
1) ifupdown doesn't handle bridges and vlans without external
packages, yet it already depends upon iproute2, which provides 'ip'
i.e. a command that can handle these quite nicely.
Not quite true, vlan support is now internal AFAIK, or at least I haven't installed `vlan` in ages and things seem to work :)
4) That systemd unit generation blissfully ignores anything else that physical interfaces in /etc/network/interfaces which introduces yet
more reproducibility problems.
Not sure what you're talking about here?
Hi Santiago,
On Mon, Jul 08, 2024 at 12:23:16PM -0300, Santiago Ruano Rincn wrote:
Santiago, how do you feel about ifupdown's future maintainability and feature development? I honestly never looked into why people started writing ifupdown replacements. I had my own gripes with it so I never questioned it but I'm happy to hear why we should all rally around it.
I've long wondered how we ended up with so many implementations. Team maintenance of just one implementation would make more sense.
For me the reason to work on ifupdown-ng is that it has a better core design, clean&modern code, an active upstream community, a ***test suite***
I fully acknowledge this. After trying to fix some of the ifupdown bugs
but hitting some design issues,
Can you elaborate on that point? What are the sort of issues you run into with the traditional ifupdown design and/or it's maintenance.
I think it makes more sense to focus all
the efforts in just one of the implementations, and since ifupdown-ng
has all the above mentioned advantages, I'd would be in favor of
replacing ifupdown by ifupdown-ng...
Good to hear.
From the looks of the BTS page I feel like part of the burdon of
maintaining ifupdown is that people just default to reporting any
networking issues there, is that something you see a lot?
Perhaps we should have a debian-networking mailing list as Maintainer to be able to load-share the user-support better?
and the potential to fully replace ifupdown without breaking anyone's system doing it. Full compatibility is not there yet. I'm working on it,
see [1] but I'm optimistic so far.
[1]: https://github.com/ifupdown-ng/ifupdown-ng/issues/247
Noted.
... but it would be *great* to make ifupdown-ng a drop-in replacement first.
Naturally.
It is pretty close though. The remaining issues I know about are documented in the GH issue: the locking protocol is sligtly suboptimal (and more importantly for interop: different), ifstate file is separate and interface renaming ("rename" statanza) isn't supported. I didn't even know that last one existed, does anyone use those?
If you're on-board with transitioning to -ng that should make the ifstate compat pretty easy since we can freeze the old format and behaviour.
I haven't thrown -ng at a large legacy setup in anger yet (since I don't
have any), but for regular desktop usage with some mildly custom stuff in /etc/network/interfaces I hardly notice which ifupdown* I have installed.
Note: For testing you have to keep in mind to (tranditional) ifdown the ifaces you want to test first since the ifstate is still disjoint
currently.
[snip]Claiming to offer a drop-in substitute all while nudging people
towards a new paradigm is not welcome.
If ifupdown's paradigm were working for people we wouldn't be having this >>> conversation.
For my perspective, the main issues with ifupdown are:
1) ifupdown doesn't handle bridges and vlans without external
packages, yet it already depends upon iproute2, which provides 'ip'
i.e. a command that can handle these quite nicely.
2) ifupdown doesn't include a way to handle DHCPv6-PD for all
supported DHCP clients.
3) Since the introduction of systemd units, one can no longer rely on interfaces being brought up sequentially following the order in which
they appear in /etc/network/interfaces.
4) That systemd unit generation blissfully ignores anything else that physical interfaces in /etc/network/interfaces which introduces yet
more reproducibility problems.
On Wed, 10 Jul 2024 23:15:24 +0200, Ansgar ? <ansgar@43-1.org> wrote:Are there any specific requirements --- such as "must be written in extra-portable C" --- that any alternative implementation should fulfil ?
While there are numerous alternative implementations of DHCP client,
the Linux world seems to be without a working DHCP relay
implementation in those days. That's REALLY bad for an installation
with Linux routers.
I understand your fears about the uncertainty of future developments.
No, you don't.
What I'm concerned about is not packages as a whole being discontinued.
This is highly unlikely for systemd, and for simpler packages, it is not
a problem as long as we are able to react to security issues.
My concern is *interfaces* and *features* being discontinued in new versions, requiring adaptation on our end before we can update a package that we want to upgrade. Specifically I'm looking at the interface for passing in system-wide network configuration, because that interface
will likely stand in the way of future systemd-networkd development:
I mean looking at the other half of this thread, clearly the ifupdown* paradigm isn't working at all for some people which I think is
unfortunate.
I haven't see anyone answer the question of what doesn't work with ifupdown.
I still think you're making too much of this `use` feature. I had a conversation with upstream about it and took another look at the code and it's basically just an optimization to *only* run the delcared executors as opposed to all of them (in case any of their config stanzas are used).
Whcih still could be accomplished using the 3rd item of the
traditional ifdown line.
Not quite true, vlan support is now internal AFAIK, or at least I haven't installed `vlan` in ages and things seem to work :)
I said ifupdown, not ifupdown-ng.
4) That systemd unit generation blissfully ignores anything else that physical interfaces in /etc/network/interfaces which introduces yet
more reproducibility problems.
Not sure what you're talking about here?
ifupdown has helpers that dynamically generate systemd service units
upon bootup. It only generates them for en* and wl* interfaces, which
are then started at random according to systemd preferences. Later in
the boot process, a generic networking.service unit is run to bring up everything else found in /etc/network/interfaces e.g. vlan, bridges.
¹ ifupdown-scripts-zg2 cached commands needed for the takedown of the interface when it was brought up and didnt need the interface
configuration to take it down.
I eventually decided to drop that easy-of-use for networkd, lowering my workload significantly.
... See my recent mail about how we should probably not be inventing Debian-specific container frameworks that will end up with one overworked maintainer being a single point of failure for the distribution, but replace "container framework" with "network management tool" and the
same ideas are equally valid. Like Podman in the containers space, NM
and systemd-networkd both have the advantage of being used outside the Debian bubble, sharing the responsibility for their continued existence among *considerably* more people.
ACK. This is a sound argument. Thanks.
Can you elaborate on that point? What are the sort of issues you run into with the traditional ifupdown design and/or it's maintenance.
For example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804396.
Fixing it is not trivial.
From the looks of the BTS page I feel like part of the burdon of maintaining ifupdown is that people just default to reporting any networking issues there, is that something you see a lot?
No, not really.
Perhaps we should have a debian-networking mailing list as Maintainer to be able to load-share the user-support better?
I'd happy with that!
It is pretty close though. The remaining issues I know about are documented in the GH issue: the locking protocol is sligtly suboptimal (and more importantly for interop: different), ifstate file is separate and interface renaming ("rename" statanza) isn't supported. I didn't even know that last one existed, does anyone use those?
Yes, I am aware there are users of the rename stanza.
On Tue, 09 Jul 2024 at 16:21:16 +0200, Ansgar 🙀 wrote:
On Tue, 2024-07-09 at 22:44 +0900, Simon Richter wrote:
I believe NM does not have a fixed configuration format, but only a dbus API.
It's perfectly fine to edit configuration files for NM manually, see man:nm-settings-keyfile(5).
... and debian-installer already knows how to write out these files,
and has done so for more than a decade if I'm reading correctly. This is
not a recent innovation, and anyone who has installed our default desktop environment in the last few years - especially if they used wifi during installation - has been relying on this code path.
<https://salsa.debian.org/installer-team/netcfg/> is responsible
for converting the network configuration that was used temporarily in
the d-i environment into a NM configuration file if NM is installed,
or an ifupdown configuration otherwise. Writing the equivalents into /etc/systemd/network for systemd-networkd would presumably not be rocket science, it's a simple .ini-like syntax similar to the one NM uses.
On Thu, Jul 11, 2024 at 12:57:52PM +0300, Martin-Éric Racine wrote:
What I'd like to know is why is removing all traces of ifupdown* from a minimal Debian install important? Clearly Desktop/Cloud image maintainers think a different tool is more well suited for their users. That's fine.
The question is: What problems does ifupdown* cause that make its removal from the base system worthwhile?
Not quite true, vlan support is now internal AFAIK, or at least I haven't installed `vlan` in ages and things seem to work :)
I said ifupdown, not ifupdown-ng.
I was talking about *ifupdown*. Sorry for not being clear. See `VLAN INTERFACES` interfaces.5 and/or grep for `type vlan` in
ifudown/link.defn.
4) That systemd unit generation blissfully ignores anything else that physical interfaces in /etc/network/interfaces which introduces yet more reproducibility problems.
Not sure what you're talking about here?
ifupdown has helpers that dynamically generate systemd service units
upon bootup. It only generates them for en* and wl* interfaces, which
are then started at random according to systemd preferences. Later in
the boot process, a generic networking.service unit is run to bring up everything else found in /etc/network/interfaces e.g. vlan, bridges.
I'm not aware of any such component. I don't see any systemd-*-generators packaged as part of ifupdown. systemd-network-generator.8, part of systemd mind you, doesn't look relevant.
On Thu, Jul 11, 2024 at 08:13:38AM +0200, Marc Haber wrote:
I eventually decided to drop that easy-of-use for networkd, lowering my workload significantly.
Since we're still lacking technical arguments for why ifupdown is problematic, could you elaborate on how it was causing an increase in your workload?
la 13. heink. 2024 klo 2.02 Daniel Grber (dxld@darkboxed.org) kirjoitti:
On Thu, Jul 11, 2024 at 12:57:52PM +0300, Martin-ric Racine wrote:
What I'd like to know is why is removing all traces of ifupdown* from a minimal Debian install important? Clearly Desktop/Cloud image maintainers think a different tool is more well suited for their users. That's fine.
The question is: What problems does ifupdown* cause that make its removal from the base system worthwhile?
I haven't seen any answer to this one either.
Similarly, I have yet to hear any compelling reason for dropping all
DHCP clients and ifupdown implementations from the default install and instead using networkd or for using netplan instead of ifupdown.
Not quite true, vlan support is now internal AFAIK, or at least I haven't
installed `vlan` in ages and things seem to work :)
I said ifupdown, not ifupdown-ng.
I was talking about *ifupdown*. Sorry for not being clear. See `VLAN
INTERFACES` interfaces.5 and/or grep for `type vlan` in
ifudown/link.defn.
Interesting. Thanks for the heads up. Yet we still have this package:
vlan - ifupdown integration for vlan configuration
If ifupdown's paradigm were working for people we wouldn't be having this >conversation.
How else would you move /etc/network/interfaces forward without breaking >anything?
Agreed: either it's drop-in compatible or we may as well switch the
default to NM and/or systemd-networkd.
Well, here's a heretical thought: why don't we do that anyway, at least for new
installations?
On Tue, Jul 09, 2024 at 02:13:26PM +0200, Daniel Gröber wrote:
If ifupdown's paradigm were working for people we wouldn't be having this conversation.
How else would you move /etc/network/interfaces forward without breaking anything?
Just don't. If someone needs to do something new that's supported by a
new tool and not ifupdown, they should just use the new tool.
Freeze
ifupdown functionality, mark feature requests as wontfix, and update the documentation.
On Tue, Jul 09, 2024 at 10:57:39AM +0200, Matthias Urlichs wrote:
Agreed: either it's drop-in compatible or we may as well switch the
default to NM and/or systemd-networkd.
Well, here's a heretical thought: why don't we do that anyway, at least for new
installations?
Frankly the default is a completely uninteresting issue.
The major concern
IMO is that the zeal to have Yet Another New Thing doesn't break all of the existing systems that are running perfectly well with ifupdown and which clearly don't need a new thing.
Hi,
On Sun, 2024-09-15 at 23:07 -0400, Michael Stone wrote:
On Tue, Jul 09, 2024 at 02:13:26PM +0200, Daniel Gröber wrote:
If ifupdown's paradigm were working for people we wouldn't be having this >> > conversation.
How else would you move /etc/network/interfaces forward without breaking >> > anything?
Just don't. If someone needs to do something new that's supported by a
new tool and not ifupdown, they should just use the new tool.
Hmm, ifupdown has problems assigning addresses for the internet
protocol to interfaces. Is that something "new"? :)
(And AFAIR that includes assigning static addresses to a static
interface due to race conditions.)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 06:12:22 |
| Calls: | 10,386 |
| Calls today: | 1 |
| Files: | 14,058 |
| Messages: | 6,416,633 |