Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #112393 > unrolled thread

Re: ifupdown maintenance

Back to article view | Back to linux.debian.devel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: ifupdown maintenance Daniel Gröber <dxld@darkboxed.org> - 2024-07-07 16:20 +0200
    Re: ifupdown maintenance Martin-Éric Racine <martin-eric.racine@iki.fi> - 2024-07-07 17:30 +0200
      Re: ifupdown maintenance Santiago Ruano Rincón <santiagorr@riseup.net> - 2024-07-08 17:30 +0200
        Re: ifupdown maintenance Martin-Éric Racine <martin-eric.racine@iki.fi> - 2024-07-08 20:20 +0200
        Re: ifupdown maintenance Daniel Gröber <dxld@darkboxed.org> - 2024-07-09 11:30 +0200
          Re: ifupdown maintenance Santiago Ruano Rincón <santiagorr@riseup.net> - 2024-07-11 14:10 +0200
        Re: ifupdown maintenance Sean Whitton <spwhitton@spwhitton.name> - 2024-09-13 11:20 +0200
          Re: ifupdown maintenance Martin-Éric Racine <martin-eric.racine@iki.fi> - 2024-09-13 12:00 +0200
            Re: ifupdown maintenance Santiago Ruano Rincón <santiagorr@riseup.net> - 2024-09-14 00:20 +0200
              Re: ifupdown maintenance Martin-Éric Racine <martin-eric.racine@iki.fi> - 2024-09-14 07:50 +0200
                Replacing isc-dhcp-client with dhcpcd-base (Was: ifupdown  maintenance) Daniel Gröber <dxld@darkboxed.org> - 2024-09-14 14:40 +0200
                  Re: Replacing isc-dhcp-client with dhcpcd-base (Was: ifupdown  maintenance) Colin Watson <cjwatson@debian.org> - 2024-09-14 20:20 +0200
                  Re: Replacing isc-dhcp-client with dhcpcd-base (Was: ifupdown maintenance) "Henrique de Moraes Holschuh" <hmh@debian.org> - 2024-09-15 17:40 +0200
                  Re: Replacing isc-dhcp-client with dhcpcd-base (Was: ifupdown  maintenance) Daniel Gröber <dxld@darkboxed.org> - 2024-09-23 16:00 +0200
              Re: ifupdown maintenance Sean Whitton <spwhitton@spwhitton.name> - 2024-09-15 19:00 +0200
    Re: ifupdown maintenance Martin-Éric Racine <martin-eric.racine@iki.fi> - 2024-07-09 08:50 +0200
      Re: ifupdown maintenance Marco d'Itri <md@Linux.IT> - 2024-07-09 10:10 +0200
        Re: ifupdown maintenance Matthias Urlichs <matthias@urlichs.de> - 2024-07-09 12:00 +0200
          Re: default network management tools (was: ifupdown maintenance) Simon McVittie <smcv@debian.org> - 2024-07-09 12:50 +0200
            Re: default network management tools (was: ifupdown maintenance) Bernd Zeimetz <bernd@bzed.de> - 2024-07-10 18:40 +0200
              Re: default network management tools (was: ifupdown maintenance) Marc Haber <mh+debian-devel@zugschlus.de> - 2024-07-11 08:20 +0200
                Re: default network management tools Matthias Urlichs <matthias@urlichs.de> - 2024-07-11 12:00 +0200
                  Re: default network management tools Marco d'Itri <md@Linux.IT> - 2024-07-11 13:50 +0200
                    Re: default network management tools Marc Haber <mh+debian-devel@zugschlus.de> - 2024-07-11 14:20 +0200
              Re: default network management tools Lukas Märdian <slyon@debian.org> - 2024-07-11 11:20 +0200
            Re: default network management tools (was: ifupdown maintenance) Santiago Ruano Rincón <santiagorr@riseup.net> - 2024-07-11 14:20 +0200
          Re: ifupdown maintenance Bjørn Mork <bjorn@mork.no> - 2024-07-09 13:00 +0200
            Re: ifupdown maintenance Simon McVittie <smcv@debian.org> - 2024-07-09 13:40 +0200
            Re: ifupdown maintenance Matthias Urlichs <matthias@urlichs.de> - 2024-07-09 20:30 +0200
              Re: ifupdown maintenance Bjørn Mork <bjorn@mork.no> - 2024-07-09 22:20 +0200
                Re: ifupdown maintenance Marco d'Itri <md@Linux.IT> - 2024-07-09 22:40 +0200
              Re: ifupdown maintenance Stephan Seitz <stse+debian@rootsland.net> - 2024-07-11 11:40 +0200
          Re: ifupdown maintenance Simon Richter <sjr@debian.org> - 2024-07-09 15:50 +0200
            Re: ifupdown maintenance Luca Boccassi <bluca@debian.org> - 2024-07-09 16:10 +0200
              Re: ifupdown maintenance Simon Richter <sjr@debian.org> - 2024-07-09 22:00 +0200
                Re: ifupdown maintenance Marco d'Itri <md@Linux.IT> - 2024-07-09 22:40 +0200
                  Re: ifupdown maintenance Simon Richter <sjr@debian.org> - 2024-07-10 22:20 +0200
                    Re: ifupdown maintenance Ansgar 🙀 <ansgar@43-1.org> - 2024-07-10 23:20 +0200
                      Re: ifupdown maintenance Marc Haber <mh+debian-devel@zugschlus.de> - 2024-07-11 08:20 +0200
                        Re: ifupdown maintenance Jose Luis Tallon <jltallon@adv-solutions.net> - 2024-07-11 16:40 +0200
                      Re: ifupdown maintenance Simon Richter <sjr@debian.org> - 2024-07-11 08:50 +0200
                        Re: ifupdown maintenance "Andrej Shadura" <andrew@shadura.me> - 2024-07-12 13:40 +0200
                    Re: ifupdown maintenance Marco d'Itri <md@Linux.IT> - 2024-07-11 11:30 +0200
                    Re: ifupdown maintenance Matthias Urlichs <matthias@urlichs.de> - 2024-07-11 14:30 +0200
            Re: ifupdown maintenance Ansgar 🙀 <ansgar@43-1.org> - 2024-07-09 16:30 +0200
              Re: ifupdown maintenance Simon McVittie <smcv@debian.org> - 2024-07-09 19:10 +0200
                what about Netplan? Philip Hands <phil@hands.com> - 2024-07-11 09:20 +0200
                  Re: what about Netplan? Lukas Märdian <slyon@debian.org> - 2024-07-11 11:20 +0200
                    Re: what about Netplan? Cyril Brulebois <kibi@debian.org> - 2024-07-15 03:00 +0200
                      Re: what about Netplan? Noah Meyerhans <noahm@debian.org> - 2024-07-16 23:50 +0200
                  Re: what about Netplan? Marco d'Itri <md@Linux.IT> - 2024-07-11 11:20 +0200
                    Re: what about Netplan? Lukas Märdian <slyon@debian.org> - 2024-07-11 13:20 +0200
                      Re: what about Netplan? Luca Boccassi <bluca@debian.org> - 2024-07-13 17:50 +0200
                        Re: what about Netplan? Lukas Märdian <slyon@debian.org> - 2024-07-13 21:50 +0200
                          Re: what about Netplan? Andrey Rakhmatullin <wrar@debian.org> - 2024-07-14 11:30 +0200
                            Re: what about Netplan? Luca Boccassi <bluca@debian.org> - 2024-07-14 14:20 +0200
                              Re: what about Netplan? Philip Hands <phil@hands.com> - 2024-07-14 21:10 +0200
                                Re: what about Netplan? Luca Boccassi <bluca@debian.org> - 2024-07-15 00:20 +0200
                            Re: what about Netplan? Steve McIntyre <steve@einval.com> - 2024-07-14 18:50 +0200
                              Re: what about Netplan? Simon McVittie <smcv@debian.org> - 2024-07-14 20:30 +0200
                                Re: what about Netplan? Luca Boccassi <bluca@debian.org> - 2024-07-15 00:30 +0200
                                Re: what about Netplan? Cyril Brulebois <kibi@debian.org> - 2024-07-15 03:30 +0200
                                Re: what about Netplan? Lukas Märdian <slyon@debian.org> - 2024-07-15 15:40 +0200
                                  Re: what about Netplan? Marvin Renich <mrvn@renich.org> - 2024-07-15 16:20 +0200
                                    Re: what about Netplan? Lukas Märdian <slyon@debian.org> - 2024-07-15 16:40 +0200
                                      Re: what about Netplan? Marvin Renich <mrvn@renich.org> - 2024-07-16 15:40 +0200
                                  Re: what about Netplan? Luca Boccassi <bluca@debian.org> - 2024-07-15 16:50 +0200
                                    Re: what about Netplan? Steve Langasek <vorlon@debian.org> - 2024-07-16 01:30 +0200
                                      Re: what about Netplan? Luca Boccassi <bluca@debian.org> - 2024-07-16 02:00 +0200
                                    Re: what about Netplan? thomas@goirand.fr - 2024-07-16 01:50 +0200
                                  Re: what about Netplan? Marc Haber <mh+debian-devel@zugschlus.de> - 2024-07-16 08:10 +0200
                                    Re: what about Netplan? Lukas Märdian <slyon@debian.org> - 2024-07-16 11:00 +0200
                                      Re: what about Netplan? thomas@goirand.fr - 2024-07-16 11:10 +0200
                                        Re: what about Netplan? Lukas Märdian <slyon@debian.org> - 2024-07-16 12:50 +0200
                                      Re: what about Netplan? Jose Luis Tallon <jltallon@adv-solutions.net> - 2024-07-16 11:30 +0200
                                        Re: what about Netplan? Lukas Märdian <slyon@debian.org> - 2024-07-16 12:40 +0200
                                      Re: what about Netplan? Stephan Seitz <stse+debian@rootsland.net> - 2024-07-16 11:30 +0200
                                        Re: what about Netplan? Colin Watson <cjwatson@debian.org> - 2024-07-16 12:20 +0200
                                        Re: what about Netplan? Lukas Märdian <slyon@debian.org> - 2024-07-16 13:20 +0200
                                          Re: what about Netplan? Stephan Seitz <stse+debian@rootsland.net> - 2024-07-16 14:30 +0200
                                        Re: what about Netplan? Philip Hands <phil@hands.com> - 2024-07-16 13:20 +0200
                                          Re: what about Netplan? gregor herrmann <gregoa@debian.org> - 2024-07-16 15:10 +0200
                                            Re: what about Netplan? Philip Hands <phil@hands.com> - 2024-07-16 15:20 +0200
                                            Re: what about Netplan? Lukas Märdian <slyon@debian.org> - 2024-07-16 15:30 +0200
                                              Re: what about Netplan? Ansgar 🙀 <ansgar@43-1.org> - 2024-07-16 18:40 +0200
                                                Re: what about Netplan? Matthias Urlichs <matthias@urlichs.de> - 2024-07-17 09:20 +0200
                                                  Re: what about Netplan? Arne Pisch <old_man999@freenet.de> - 2024-07-20 08:20 +0200
                                            Re: what about Netplan? Luca Boccassi <luca.boccassi@gmail.com> - 2024-07-16 15:40 +0200
                                Re: what about Netplan? Luca Boccassi <bluca@debian.org> - 2024-07-15 16:00 +0200
                                  Re: what about Netplan? Lukas Märdian <slyon@debian.org> - 2024-07-15 16:20 +0200
                                  Size measuring contest (Was: what about Netplan?) Daniel Gröber <dxld@darkboxed.org> - 2024-07-16 15:50 +0200
                                    Re: Size measuring contest (Was: what about Netplan?) Luca Boccassi <bluca@debian.org> - 2024-07-16 16:20 +0200
                              Re: what about Netplan? Guus Sliepen <guus@debian.org> - 2024-07-16 09:30 +0200
                Re: ifupdown maintenance Luca Boccassi <bluca@debian.org> - 2024-07-13 17:40 +0200
          Re: ifupdown maintenance Michael Stone <mstone@debian.org> - 2024-09-16 05:10 +0200
            Re: ifupdown maintenance Chris Hofstaedtler <zeha@debian.org> - 2024-09-16 10:30 +0200
      Re: ifupdown maintenance Daniel Gröber <dxld@darkboxed.org> - 2024-07-09 11:00 +0200
        Re: ifupdown maintenance Martin-Éric Racine <martin-eric.racine@iki.fi> - 2024-07-09 13:50 +0200
          Re: ifupdown maintenance Daniel Gröber <dxld@darkboxed.org> - 2024-07-09 14:20 +0200
            Re: ifupdown maintenance Martin-Éric Racine <martin-eric.racine@iki.fi> - 2024-07-11 10:40 +0200
              Re: ifupdown maintenance Jose Luis Tallon <jltallon@adv-solutions.net> - 2024-07-11 16:40 +0200
            Re: ifupdown maintenance Michael Stone <mstone@debian.org> - 2024-09-16 05:10 +0200
              Re: ifupdown maintenance Ansgar 🙀 <ansgar@43-1.org> - 2024-09-16 10:10 +0200
                Re: ifupdown maintenance Michael Stone <mstone@debian.org> - 2024-09-17 05:20 +0200
    Re: ifupdown maintenance Marco d'Itri <md@Linux.IT> - 2024-07-11 11:20 +0200

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#112393 — Re: ifupdown maintenance

[Multipart message — attachments visible in raw view] — view raw

Hi Martin & all,

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.

I'm sure it has it's niche thought and that brings my back to my initial
concern: why exactly does it make sense to converge on a single
implementation at this point? Cause I don't see it.

DHCP on the other hand affects us all. I'd be very much on board with
pooling resources around that.

--Daniel

[toc] | [next] | [standalone]

#112396

su 7. heinäk. 2024 klo 16.56 Daniel Gröber (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.

> 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.

Indeed.

> > 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.

Martin-Éric

[toc] | [prev] | [next] | [standalone]

#112413

[Multipart message — attachments visible in raw view] — view raw

El 07/07/24 a las 18:02, Martin-Éric Racine escribió:
> su 7. heinäk. 2024 klo 16.56 Daniel Gröber (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.

Thanks Martin-Éric for initiating the discussion, and Daniel for making
it public. The topic should have had to be discussed openly at some
point.

> 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***

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.

> > 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.

And we would need to the change in the override first, isn't it?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038882

Cheers,

 -- Santiago

[toc] | [prev] | [next] | [standalone]

#112423

ma 8. heinäk. 2024 klo 18.23 Santiago Ruano Rincón
(santiagorr@riseup.net) kirjoitti:

> > 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

No, ifupdown can already change its search path to put dhcpcd first
and its Recommends from dhclient to dhcpcd-base. Changing priority and
the override to match merely is needed to migrate what
debian-installer will pull.

Martin-Éric

[toc] | [prev] | [next] | [standalone]

#112429

[Multipart message — attachments visible in raw view] — view raw

Hi Santiago,

On Mon, Jul 08, 2024 at 12:23:16PM -0300, Santiago Ruano Rincón 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.

> > > 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.

Right, glad we're on the same page here.

--Daniel

[toc] | [prev] | [next] | [standalone]

#112470

[Multipart message — attachments visible in raw view] — view raw

El 09/07/24 a las 11:25, Daniel Gröber escribió:
> Hi Santiago,
> 
> On Mon, Jul 08, 2024 at 12:23:16PM -0300, Santiago Ruano Rincón 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.

For example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804396.
Fixing it is not trivial.

> > 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?

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!

> > > > 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?

Yes, I am aware there are users of the rename stanza.

> 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.

ACK.

[snip]

Cheers,

 -- Santiago

[toc] | [prev] | [next] | [standalone]

#113371

Hello Santiago,

What are your current intentions in this area?  Do you want to make the
change for trixie?  If not, I'd like to close the override change bug
for now.  Thanks.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#113372

pe 13. syysk. 2024 klo 12.16 Sean Whitton (spwhitton@spwhitton.name) kirjoitti:
> Hello Santiago,
>
> What are your current intentions in this area?  Do you want to make the
> change for trixie?  If not, I'd like to close the override change bug
> for now.  Thanks.

I am wondering the same. However, neither Santiago or Josue have
followed up on this and other pending ifupdown issues that I have
brought up. Santiago already indicated elsewhere that his spare time
is sparse, which might explain why, but Josue is essentially MIA.

Personally, I'm ready to raise the Priority of dhcpcd-base to
important, to match the override, and I think that it should be done
now, because isc-dhcp has been mothballed upstream, while dhcpcd still
sees regular releases and it transparently handles IPv4 and IPv6
without requiring separate inet and inet6 lines in
/etc/network/interfaces.

Martin-Éric

[toc] | [prev] | [next] | [standalone]

#113374

[Multipart message — attachments visible in raw view] — view raw

Adding team+networking@tracker.debian.org to the loop.

El 13/09/24 a las 12:31, Martin-Éric Racine escribió:
> pe 13. syysk. 2024 klo 12.16 Sean Whitton (spwhitton@spwhitton.name) kirjoitti:
> > Hello Santiago,
> >
> > What are your current intentions in this area?  Do you want to make the
> > change for trixie?  If not, I'd like to close the override change bug
> > for now.  Thanks.
> 
> I am wondering the same. However, neither Santiago or Josue have
> followed up on this and other pending ifupdown issues that I have
> brought up. Santiago already indicated elsewhere that his spare time
> is sparse, which might explain why, but Josue is essentially MIA.
> 
> Personally, I'm ready to raise the Priority of dhcpcd-base to
> important, to match the override, ...

Regarding this particular issue, I have said somewhere that I preferred
to sync the override with the Recommends update in ifupdown. So Sean, if
you are willing to apply the override, we can go ahead with the
ifupdown-related change.

However, keep in mind that there is a current discussion about what will
be the default networking stack for trixie.

Thank you!

 -- Santiago

[toc] | [prev] | [next] | [standalone]

#113375

la 14. syysk. 2024 klo 1.17 Santiago Ruano Rincón
(santiagorr@riseup.net) kirjoitti:
>
> Adding team+networking@tracker.debian.org to the loop.
>
> El 13/09/24 a las 12:31, Martin-Éric Racine escribió:
> > pe 13. syysk. 2024 klo 12.16 Sean Whitton (spwhitton@spwhitton.name) kirjoitti:
> > > Hello Santiago,
> > >
> > > What are your current intentions in this area?  Do you want to make the
> > > change for trixie?  If not, I'd like to close the override change bug
> > > for now.  Thanks.
> >
> > I am wondering the same. However, neither Santiago or Josue have
> > followed up on this and other pending ifupdown issues that I have
> > brought up. Santiago already indicated elsewhere that his spare time
> > is sparse, which might explain why, but Josue is essentially MIA.
> >
> > Personally, I'm ready to raise the Priority of dhcpcd-base to
> > important, to match the override, ...
>
> Regarding this particular issue, I have said somewhere that I preferred
> to sync the override with the Recommends update in ifupdown. So Sean, if
> you are willing to apply the override, we can go ahead with the
> ifupdown-related change.

Let's start with changing the ifupdown dependencies and DHCP stack
search order to effectively deprecate ISC.

If Sean agrees with the override, we can do that one separately. It's
just a one word change in 2 packages' control file.

> However, keep in mind that there is a current discussion about what will
> be the default networking stack for trixie.

Where? I haven't seen any discussion about this in a while. All I saw
was netplan, systemd and network-manager maintainers each pushing for
their package to become the default.

Martin-Éric

[toc] | [prev] | [next] | [standalone]

#113380 — Replacing isc-dhcp-client with dhcpcd-base (Was: ifupdown maintenance)

[Multipart message — attachments visible in raw view] — view raw

Hi Martin,

On Sat, Sep 14, 2024 at 08:31:06AM +0300, Martin-Éric Racine wrote:
> Let's start with changing the ifupdown dependencies and DHCP stack
> search order to effectively deprecate ISC.

I don't think we're ready yet. I have some concerns:

 1) How do you deal with the mismatch between dhcpd being a system daemon
    vs. ifudown wanting a per-interface process?
 2) I'm worried about the behavioural change regarding inet/inet6 stanzas
    outlined in #1065085 with a patch by ktetzlaff pending.
 3) dhcpcd-base enables IPv6 privacy addressess by default.


1) Looking at the packaging I see that `dhcpcd-base`, unlike `dhcpcd`
(which was renamed from dhcpcd5), does not ship the daemon part of dhcpcd,
which takes over dhcp duties on all interfaces by default as soon as it's
installed. This may be problematic because on upgrade dhcpcd may take over
an interface dhclient is still running on, causing havoc. Perhaps the
sockets are bound such that this wouldn't succeed but I'm not sure.

Looking at ifupdown's inet.defn I see dhcpcd being operated in per-iface
mode, like `dhcpcd [-h,-i,-I,-l options...] $IFACE`. In my experience
dhcpcd is very finicky when you try to use it in a dhclient style
one-per-interface mode. When I played with this a while back and found that
the logic is such that dhcpcd will always connect to the system-wide daemon
if one is running even if you ask it to operate on just one
interface. Martin, Santiago: how have you done testing in this dark corner?
My upstream issue is here:
https://github.com/NetworkConfiguration/dhcpcd/issues/241 oh and
one-process-per-interface is going away in v11 does it make sense to rely
on it in the first place?
https://github.com/NetworkConfiguration/dhcpcd/discussions/271

So even with the dhcpcd-base approach of not shipping the daemon, I am
concerned that as soon as a user installs the daemon part ifupdown will
stop working properly because we're not prepared for the daemon taking
over. I just did a quick test and if a per-interface dhcpcd is running and
indeed -k will stop working as soon as the system-wide daemon is started.


2) I see two problems with the "you only need the inet stanza" change:
Firstly users are loosing control over whether v4/v6 is enabled on dhcp
interfaces. IMO that's not just a break in backwards-compatibility but also
loss of an important feature needed by network operators in complex
environments. Secondly, IPv4 is legacy and will go away eventually so if
anything starting the DHCP client should be attached to the inet6 stanza ;)
Since remaining IPv4 users are going to disagree vehemently here I would
suggest that either choice is utterly broken. We must support dhcp
enablement seperately for each address family.


3) Since ifupdown is mainly used in the server/embedded sorts of
enviornments I'm not sure privacy addressing is the right default.
(cf. /etc/dhcpcd.conf having `slaac private` thus enabling RFC 7217
addressing). We can assume NM will be in use for most Desktop users so I
believe it's safe in principle to retain the current MAC based SLAAC
address behaviour we used to get from the kernel RA implementation.
Thoughts?



That all being said I've also lost track of how exaclty we intend to do the
transition once we are ready, so let's break it down:

I think we're in agreement that isc-dhcp-client needs to be replaced for
the purposes of ifupdown at the very least. As I understand it raising the
priority of dhcpcd-base (as requested by Santiago and Martin) to important
would have the effect of it being installed by default by d-i, but what's
not clear to me is whether it will also cause dhcpcd-base to be installed
on upgrade from stable?

Further Martin raised the issue that "an upgrade would result in both
remaining installed" while also noting this can be mitigated by changing
ifupdown's dhcp client search order. Fair enough, but I'd like us to at
least make an attempt at removing isc-dhcp-client from user systems that
haven't manually installed it, unless there is simply no viable mechanism
for us to do that? Martin notes a Conflicts against isc-dhcp-client (from
dhcpcd-base I assume?) was tried but this was deemed the "incorrect
approach" (by who, why?).

Lastly I don't quite understand how the ftp-master priority override
mechanism plays into this and indeed why we're using it over just uploading
new revisions with the changes?

Checking the current state of things since I read some messages as
suggesting that an override is already in effect:

    $ wget -q -O- https://ftp.debian.org/debian/indices/override.sid.main.gz | zgrep '^isc-dhcp-client\|^dhcpcd' 
    isc-dhcp-client	important	net	
    dhcpcd	optional	net	
    dhcpcd-base	optional	net	
    dhcpcd-gtk	optional	net	
    isc-dhcp-client-ddns	optional	net	
    dhcpcd5	optional	oldlibs

So isc-dhcp-client has a Priority: important override currently. Why?

--Daniel

PS: Previous dhcpcd-base discussion (I've had no time to re-read just now ;)
"proposal: dhcpcd-base as standard DHCP client starting with Trixie"
started by Martin:
  https://lists.debian.org/debian-devel/2023/06/msg00184.html

[toc] | [prev] | [next] | [standalone]

#113384 — Re: Replacing isc-dhcp-client with dhcpcd-base (Was: ifupdown maintenance)

I haven't been following the rest of this discussion, but one small
point since this is a common source of confusion:

On Sat, Sep 14, 2024 at 02:30:08PM +0200, Daniel Gröber wrote:
> Lastly I don't quite understand how the ftp-master priority override
> mechanism plays into this and indeed why we're using it over just uploading
> new revisions with the changes?

dak's architecture is that every package in the archive has overrides
setting its priority and section; an upload that doesn't match existing
overrides goes to NEW.  In many (most?) cases those will be equal to the
values in the packages themselves, but those values are nevertheless
overridden.  This means that uploading a new version of a package to
attempt to change its priority or section has no effect; if you need to
change those, you _must_ get ftpmaster to change the override, and
otherwise it just won't work.

-- 
Colin Watson (he/him)                              [cjwatson@debian.org]

[toc] | [prev] | [next] | [standalone]

#113390 — Re: Replacing isc-dhcp-client with dhcpcd-base (Was: ifupdown maintenance)

On Sat, Sep 14, 2024, at 09:30, Daniel Gröber wrote:
>  3) dhcpcd-base enables IPv6 privacy addressess by default.

Please never do this *by silent default* when DHCPv6 is being used for stateful address assignment, privacy addresses are a big issue on non-home networks and even on home networks depending on firewall rules...

Although I suppose a relevant note on NEWS.Debian *and* the Release Notes might be enough if.we consider it is desirable for most installs.

> 3) Since ifupdown is mainly used in the server/embedded sorts of
> enviornments I'm not sure privacy addressing is the right default.
> (cf. /etc/dhcpcd.conf having `slaac private` thus enabling RFC 7217
> addressing). We can assume NM will be in use for most Desktop users so I
> believe it's safe in principle to retain the current MAC based SLAAC
> address behaviour we used to get from the kernel RA implementation.
> Thoughts?

Agreed, the less surprises here, the better.

-- 
  Henrique de Moraes Holschuh <hmh@debian.org>

[toc] | [prev] | [next] | [standalone]

#113483 — Re: Replacing isc-dhcp-client with dhcpcd-base (Was: ifupdown maintenance)

[Multipart message — attachments visible in raw view] — view raw

Hi Martin,

On Sat, Sep 14, 2024 at 06:28:36PM +0300, Martin-Éric Racine wrote:
> la 14. syysk. 2024 klo 15.30 Daniel Gröber (dxld@darkboxed.org) kirjoitti:
> >  2) I'm worried about the behavioural change regarding inet/inet6 stanzas
> >     outlined in #1065085 with a patch by ktetzlaff pending.
> 
> That's largely a non-issue. The separate stanzas largely is the result
> of IPv6 being an afterthought that had to be incorporated into
> ifupdown later on.

I'm sorry, but were you involved in ifupdown's development at the time to
be speaking with authority here? I get the impression you just don't want
to think about different use-cases, associated tradeoffs and edge-cases so
you dismiss the concern(s) out of hand.

It's also clearly an issue for users as we have an ifupdown bug about it
and it's enough of a pain that it even came with a patch:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065085 (thanks
ktetzlaff).

> > 1) Looking at the packaging I see that `dhcpcd-base`, unlike `dhcpcd`
> > (which was renamed from dhcpcd5), does not ship the daemon part of dhcpcd,
> > which takes over dhcp duties on all interfaces by default as soon as it's
> > installed. This may be problematic because on upgrade dhcpcd may take over
> > an interface dhclient is still running on, causing havoc. Perhaps the
> > sockets are bound such that this wouldn't succeed but I'm not sure.
> 
> It's not problematic. Someone who wants to use it as a daemon would
> not keep ifupdown anyhow.
>
> > So even with the dhcpcd-base approach of not shipping the daemon, I am
> > concerned that as soon as a user installs the daemon part ifupdown will
> > stop working properly because we're not prepared for the daemon taking
> > over. I just did a quick test and if a per-interface dhcpcd is running and
> > indeed -k will stop working as soon as the system-wide daemon is started.
> 
> That's already the case. That's why ifupdown should Conflicts with the
> package providing the init script and systemd unit (dhcpcd).

That is one solution. The other would be to patch dhcpcd to give
per-interface daemons precendence when the client is looking for a socket
to connect to.

If there's a running per-interface process, clearly that's what it should
be talking to so long as there's no potential for the global daemon to
interfere. I was unsuccessful in convincing Roy but my gut says it's
because his intent was still to remove the pre-interface dhcpcd mode
entirely at the time.

> > Looking at ifupdown's inet.defn I see dhcpcd being operated in per-iface
> > mode, like `dhcpcd [-h,-i,-I,-l options...] $IFACE`. In my experience
> > dhcpcd is very finicky when you try to use it in a dhclient style
> > one-per-interface mode. When I played with this a while back and found that
> > the logic is such that dhcpcd will always connect to the system-wide daemon
> > if one is running even if you ask it to operate on just one
> > interface. Martin, Santiago: how have you done testing in this dark corner?
> > My upstream issue is here:
> > https://github.com/NetworkConfiguration/dhcpcd/issues/241
> 
> It works fine here on my laptop. I have separate lines for Ethernet
> and wireless (with a known SSID and PSK), both of which get activated
> if Ethernet happens to be plugged in.

Erm, that doesn't sound like the right behaviour to me. Why should an
unrelated interface bring down dhcp on another ifa?

> > one-process-per-interface is going away in v11 does it make sense to rely
> > on it in the first place?
> 
> v11 is unlikely to happen. Too many people explicitely told Roy that
> it's not desirable.

I'm not so sure. Roy seems stubborn and I don't think there was another
public statement on the matter after the discussion.

> > 2) I see two problems with the "you only need the inet stanza" change:
> > Firstly users are loosing control over whether v4/v6 is enabled on dhcp
> > interfaces. IMO that's not just a break in backwards-compatibility but also
> > loss of an important feature needed by network operators in complex
> > environments. Secondly, IPv4 is legacy and will go away eventually so if
> > anything starting the DHCP client should be attached to the inet6 stanza ;)
> > Since remaining IPv4 users are going to disagree vehemently here I would
> > suggest that either choice is utterly broken. We must support dhcp
> > enablement seperately for each address family.
> 
> Control over which one currently works fine via dhcpcd.conf. It could
> also be implemented via command options passed by ifupdown.

I'm tending towards fixing this in ifupdown. I don't think users should
have to do this via dhcpcd.conf now.

> As for the day IPv4 becomes obsolete, dhcpcd will simply fork once it has
> reached its timeout and presume an IPv6-only conenction.

Have a look at IPv6-mostly (DHCP option 108/v6-only-preferred) that's the
preferred mechanism to disable IPv4 going forward ATM.

> > 3) Since ifupdown is mainly used in the server/embedded sorts of
> > enviornments I'm not sure privacy addressing is the right default.
> > (cf. /etc/dhcpcd.conf having `slaac private` thus enabling RFC 7217
> > addressing). We can assume NM will be in use for most Desktop users so I
> > believe it's safe in principle to retain the current MAC based SLAAC
> > address behaviour we used to get from the kernel RA implementation.
> > Thoughts?
> 
> Privacy by default is desirable. Globally traceable hosts is not.

For machines closely associated with humans, sure. Privacy is
desirable. For one among thousands of servers in an organization, not so
much. Operatability becomes more important then.

Personally I wish there was a RA flag to indicate what the network prefers,
but since an RFC for that never ended up materializing (see
https://datatracker.ietf.org/doc/html/draft-yhb-6man-ra-privacy-flag-02) we
have to define some default instead.

I think we're doing a disservice to our users by giving more weight to our
personal use-case for dhcpcd/ifupdown. Expert users are always going to be
able to figure whether they have privacy addressess enabled. We have to
consider whats best for the majority of our users. IMO that's server
operators.

What I'd like to try to resolve the conflicting use-cases is to add drop-in
support to dhcpcd.conf and add a new dhcpcd-privacy package that activates
`slaac private`. We can then Suggest it from ifudown and document in
release notes etc. to make users aware of it.

> > Further Martin raised the issue that "an upgrade would result in both
> > remaining installed" while also noting this can be mitigated by changing
> > ifupdown's dhcp client search order. Fair enough, but I'd like us to at
> > least make an attempt at removing isc-dhcp-client from user systems that
> > haven't manually installed it, unless there is simply no viable mechanism
> > for us to do that? Martin notes a Conflicts against isc-dhcp-client (from
> > dhcpcd-base I assume?) was tried but this was deemed the "incorrect
> > approach" (by who, why?).
> 
> Leaving the previous binary on upgrade is not a problem. Besides, if
> apt-get is used with --auto-remove, ISC would be removed once
> dhcpcd-base has been pulled in.

Oh that's true, I forgot about auto-remove. So switching the dependencies
in ifupdown around should do the trick for existing installs.

--Daniel

[toc] | [prev] | [next] | [standalone]

#113392

[Multipart message — attachments visible in raw view] — view raw

Hello,

I've gone ahead with the override switch.

I think it is appropriate to use an override change to try to get some
momentum behind this transition.  And we are at a point in the release
cycle where it is not a big deal to switch it back if it turns out there
is unsolveable breakage.

(by the way, after reading the package description, I lowered the
priority of isc-dhcp-common too)

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#112426

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.

Martin-Éric

[toc] | [prev] | [next] | [standalone]

#112427

[Multipart message — attachments visible in raw view] — view raw

On Jul 09, Martin-Éric Racine <martin-eric.racine@iki.fi> wrote:

> 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.
Agreed: either it's drop-in compatible or we may as well switch the 
default to NM and/or systemd-networkd.

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#112431

[Multipart message — attachments visible in raw view] — view raw

Hello,
> 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.

-- 
-- regards
-- 
-- Matthias Urlichs

[toc] | [prev] | [next] | [standalone]

#112432 — Re: default network management tools (was: ifupdown maintenance)

On Tue, 09 Jul 2024 at 10:57:39 +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?

To some extent, we are already there: for new laptop/desktop
installations, NM is already the default (certainly true for GNOME,
and hopefully for most/all of the other tasksel-supported desktops).

For new server/embedded installations, I think networkd would be a
better default than ifupdown (I switched my servers from ifupdown to
networkd sometime between Debian 9 and 10, according to the etckeeper
logs). 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.

networkd seems like an entirely reasonable implementation of "make the
easy things easy" (/lib/systemd/network/80-ethernet.network.example
shows how to bring up DHCPv4 and DHCPv6 on every Ethernet device in 4
non-comment lines, without having to hard-code the name of any specific
device), which is the main thing we want from a default - I continue to
believe that defaults should be chosen to be appropriate for new users
without specialized requirements, because experienced users already
know how to apply different configuration if they want to, and users
with specialized requirements will have to apply special configuration
to achieve what they require whatever we do.

At the same time, networkd also has "make the hard things possible"
available in its configuration language (see man pages for details).

I'm sure that when ifupdown was written, having our own network management
tool was seen as a necessary part of providing an OS distribution
(in the same way that the Red Hat family historically had its own
framework based on /etc/sysconfig, and so on), but thankfully things
have changed since then, and we now have non-distro-specific network
management components that can do just as good a job (if not better). It
used to be the case that ifupdown could bring up many network interfaces
"statically" with no extraneous background processes, but available RAM
has grown by several orders of magnitude, and DHCP and modern wifi both
require long-running processes to supervise them *anyway*, making that
much less of an advantage.

Of course, there is nothing to stop anyone who is interested in it from
keeping non-default frameworks available, either Debian-specific or not -
if nothing else, users of non-systemd init systems are going to want an
alternative to networkd - but if those frameworks aren't load-bearing for
the distribution as a whole, then that will give their maintainers less
support burden and more freedom to experiment.

    smcv

[toc] | [prev] | [next] | [standalone]

#112450 — Re: default network management tools (was: ifupdown maintenance)

On Tue, 2024-07-09 at 11:45 +0100, Simon McVittie wrote:
> On Tue, 09 Jul 2024 at 10:57:39 +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?
> 
> To some extent, we are already there: for new laptop/desktop
> installations, NM is already the default (certainly true for GNOME,
> and hopefully for most/all of the other tasksel-supported desktops).
> 
> For new server/embedded installations, I think networkd would be a
> better default than ifupdown  [....]

yes please, I would love to see Debian switch from ifupdown to
NM/networkd. ifupdown was the perfect tool for the time it was created
in, but things have advanced, and imho now is a good time to switch.


Bernd

-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

[toc] | [prev] | [next] | [standalone]

Page 1 of 6  [1] 2 3 4 5 6  Next page →

Back to top | Article view | linux.debian.devel

csiph-web