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

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

proposal: Hybrid network stack for Trixie

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

Contents

  proposal: Hybrid network stack for Trixie Lukas Märdian <slyon@debian.org> - 2024-09-20 13:20 +0200
    Re: proposal: Hybrid network stack for Trixie Marco d'Itri <md@Linux.IT> - 2024-09-20 15:50 +0200
      Re: proposal: Hybrid network stack for Trixie Bill MacAllister <bill@ca-zephyr.org> - 2024-09-20 22:20 +0200
    Re: proposal: Hybrid network stack for Trixie Chris Hofstaedtler <zeha@debian.org> - 2024-09-22 12:30 +0200
      Re: proposal: Hybrid network stack for Trixie Marc Haber <mh+debian-devel@zugschlus.de> - 2024-09-22 13:10 +0200
        Re: proposal: Hybrid network stack for Trixie Chris Hofstaedtler <zeha@debian.org> - 2024-09-22 13:50 +0200
          Re: proposal: Hybrid network stack for Trixie "Jonathan Dowland" <jmtd@debian.org> - 2024-09-22 16:50 +0200
            Re: proposal: Hybrid network stack for Trixie "Andrew M.A. Cater" <amacater@einval.com> - 2024-09-22 17:20 +0200
          Re: proposal: Hybrid network stack for Trixie Hakan Bayındır <hakan@bayindir.org> - 2024-09-22 23:30 +0200
      Re: proposal: Hybrid network stack for Trixie Simon McVittie <smcv@debian.org> - 2024-09-22 13:10 +0200
        Re: proposal: Hybrid network stack for Trixie Josh Triplett <josh@joshtriplett.org> - 2024-09-22 20:10 +0200
          Re: proposal: Hybrid network stack for Trixie "Andrea Pappacoda" <andrea@pappacoda.it> - 2024-09-22 22:40 +0200
            Re: proposal: Hybrid network stack for Trixie Josh Triplett <josh@joshtriplett.org> - 2024-09-23 00:10 +0200
              Re: proposal: Hybrid network stack for Trixie Lukas Märdian <slyon@debian.org> - 2024-09-23 12:40 +0200
      Re: proposal: Hybrid network stack for Trixie Lukas Märdian <slyon@debian.org> - 2024-09-23 13:10 +0200
        Re: proposal: Hybrid network stack for Trixie Marco d'Itri <md@Linux.IT> - 2024-09-23 14:10 +0200
        Re: proposal: Hybrid network stack for Trixie Marvin Renich <mrvn@renich.org> - 2024-09-23 14:50 +0200
        Re: proposal: Hybrid network stack for Trixie Didier 'OdyX' Raboud <odyx@debian.org> - 2024-09-23 15:00 +0200
        Re: proposal: Hybrid network stack for Trixie Daniel Baumann <daniel@debian.org> - 2024-09-24 08:10 +0200
      Re: proposal: Hybrid network stack for Trixie Simon Richter <sjr@debian.org> - 2024-09-24 14:20 +0200
    Re: proposal: Hybrid network stack for Trixie Ansgar 🙀 <ansgar@debian.org> - 2024-09-22 16:30 +0200
      Re: proposal: Hybrid network stack for Trixie Lukas Märdian <slyon@debian.org> - 2024-09-23 12:30 +0200
        Re: proposal: Hybrid network stack for Trixie Ansgar 🙀 <ansgar@debian.org> - 2024-09-23 12:50 +0200
          Re: proposal: Hybrid network stack for Trixie Lukas Märdian <slyon@debian.org> - 2024-09-23 13:20 +0200
            Re: proposal: Hybrid network stack for Trixie Richard Lewis <richard.lewis.debian@googlemail.com> - 2024-09-23 13:40 +0200
              Re: proposal: Hybrid network stack for Trixie Lukas Märdian <slyon@debian.org> - 2024-09-24 15:40 +0200
                Re: proposal: Hybrid network stack for Trixie Ansgar 🙀 <ansgar@debian.org> - 2024-09-27 10:10 +0200
            Re: proposal: Hybrid network stack for Trixie Bjørn Mork <bjorn@mork.no> - 2024-09-23 14:20 +0200
          Re: proposal: Hybrid network stack for Trixie Steve Langasek <vorlon@debian.org> - 2024-09-27 20:20 +0200
            Re: proposal: Hybrid network stack for Trixie Ansgar 🙀 <ansgar@debian.org> - 2024-09-27 21:10 +0200
    Re: proposal: Hybrid network stack for Trixie Sirius <sirius@trudheim.com> - 2024-09-22 17:50 +0200
      Re: proposal: Hybrid network stack for Trixie Jonas Smedegaard <jonas@jones.dk> - 2024-09-22 23:50 +0200
        Re: proposal: Hybrid network stack for Trixie Sirius <sirius@trudheim.com> - 2024-09-23 08:30 +0200
          ifupdown-ng source stanza (Was: proposal: Hybrid network stack for  Trixie) Daniel Gröber <dxld@darkboxed.org> - 2024-09-23 11:00 +0200
            Re: ifupdown-ng source stanza (Was: proposal: Hybrid network stack  for Trixie) Sirius <sirius@trudheim.com> - 2024-09-24 13:40 +0200
    Re: proposal: Hybrid network stack for Trixie Holger Levsen <holger@layer-acht.org> - 2024-09-23 10:10 +0200
      Re: proposal: Hybrid network stack for Trixie Chris Hofstaedtler <zeha@debian.org> - 2024-09-23 10:20 +0200
        Re: proposal: Hybrid network stack for Trixie Holger Levsen <holger@layer-acht.org> - 2024-09-23 10:30 +0200
          Re: proposal: Hybrid network stack for Trixie Marco d'Itri <md@Linux.IT> - 2024-09-23 11:10 +0200
            Re: proposal: Hybrid network stack for Trixie Lukas Märdian <slyon@debian.org> - 2024-09-23 12:10 +0200
            Re: proposal: Hybrid network stack for Trixie Holger Levsen <holger@layer-acht.org> - 2024-09-23 12:10 +0200
              Re: proposal: Hybrid network stack for Trixie Chris Hofstaedtler <zeha@debian.org> - 2024-09-23 12:30 +0200
    Re: proposal: Hybrid network stack for Trixie Pierre-Elliott Bécue <peb@debian.org> - 2024-09-23 11:40 +0200
      Re: proposal: Hybrid network stack for Trixie Chris Hofstaedtler <zeha@debian.org> - 2024-09-23 12:30 +0200
        ifupdown behaviour with IPv6 DAD failure (Was: proposal: Hybrid  network stack for Trixie) Daniel Gröber <dxld@darkboxed.org> - 2024-09-23 13:50 +0200
          Re: ifupdown behaviour with IPv6 DAD failure (Was: proposal: Hybrid  network stack for Trixie) Philipp Kern <pkern@debian.org> - 2024-09-23 17:50 +0200
            Re: ifupdown behaviour with IPv6 DAD failure (Was: proposal: Hybrid  network stack for Trixie) Noah Meyerhans <noahm@debian.org> - 2024-09-24 00:20 +0200
        Re: proposal: Hybrid network stack for Trixie Pierre-Elliott Bécue <peb@debian.org> - 2024-09-24 10:50 +0200
    Re: proposal: Hybrid network stack for Trixie Antoine Beaupré <anarcat@debian.org> - 2024-10-07 18:30 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#113468

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

On Mon, Sep 23, 2024 at 11:04:06AM +0200, Marco d'Itri wrote:
> > ifupdown2 is like ifupdown, just rewritten in python.
> Yes, that's the problem: there was a consensus that it is not an 
> appropriate dependency for the base system.

ah! thanks for pointing this out.

> ifupdown2 will still be around for anybody who wants to install it.

sure.


-- 
cheers,
	Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Just today, over 800 women will have died due to preventable pregnancy and
birth complications, over 130 due to femicide.
https://www.who.int/news-room/fact-sheets/detail/maternal-mortality
https://en.wikipedia.org/wiki/Femicide#Worldwide

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

#113469

* Holger Levsen <holger@layer-acht.org> [240923 12:05]:
> > ifupdown2 will still be around for anybody who wants to install it.
> 
> sure.

Except that right now it has an open r-c bug since June 25, and is
missing from testing since August 6th.

If people want to continue having it, somebody who wants to work on
it needs to be found.

https://bugs.debian.org/1074250
Upstream has applied the trivial fix, but somehow that needs to flow
into Debian too.

Chris

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

#113466

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

Lukas Märdian <slyon@debian.org> wrote on 20/09/2024 at 13:12:36+0200:
> # Why
> The ifupdown package is a Debian only solution that is becoming a maintenance
> burden. We've had plenty of discussions over the years and consensus is that we
> want to get rid of it.

I like ifupdown. It's simple and just works.

IDK what consensus you're talking about, but I'm clearly not part of it.

-- 
PEB

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

#113471

* Pierre-Elliott Bécue <peb@debian.org> [240923 11:34]:
> Lukas Märdian <slyon@debian.org> wrote on 20/09/2024 at 13:12:36+0200:
> > # Why
> > The ifupdown package is a Debian only solution that is becoming a maintenance
> > burden. We've had plenty of discussions over the years and consensus is that we
> > want to get rid of it.
> 
> I like ifupdown. It's simple and just works.

I find this quite funny, given a recent discussion about IPv6 dad
issues with ifupdown on #debian-admin.

It's certainly limited in what it can do within reasonable
configuration effort, and it often works. I think both are true for
almost all of the discussed options :-)

Chris

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

#113477 — ifupdown behaviour with IPv6 DAD failure (Was: proposal: Hybrid network stack for Trixie)

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

On Mon, Sep 23, 2024 at 12:25:15PM +0200, Chris Hofstaedtler wrote:
> * Pierre-Elliott Bécue <peb@debian.org> [240923 11:34]:
> > I like ifupdown. It's simple and just works.
> 
> I find this quite funny, given a recent discussion about IPv6 dad
> issues with ifupdown on #debian-admin.

The "discussion" was about ifup@eth0 being in a failed state on a
particular server due to a DAD failure and someone having to manually
intervene.

Chris, what behaviour do you expect here? Below I'm going to assume what
you're getting at is that we should continue to retry DAD.

To me going to a stable failure state seems desirable. Continuing to re-try
for IPs could cause instability in the face of legitimate address
conflicts: when the owning machine reboots the conflicting machine would
now win the IP due to continous retrying. The change in owner would cause
disruption to services entirely unrelated to the machine that was just
rebooted.

Sounds like the setup for a very drawn out and frustrating debugging story
to me.

--Daniel

PS: I was wondering if the RFCs have anything to say on the matter:
[ADDRCONF] says:

> 5.4.5.  When Duplicate Address Detection Fails
> 
>    [...] If the address is a link-local address formed from an interface
>    identifier, the interface SHOULD be disabled.

[Enhanced DAD] while not directly applicable seems to be under the
impression that manual intervention is the "current behaviour":

> 3.3.  Operational Considerations
> 
>    [...]the noncompliant device would
>    follow current behavior and disable IPv6 on that interface due to DAD
>    until manual intervention restores it.
 
[ADDRCONF]: RFC 2462 - IPv6 Stateless Address Autoconfiguration
[Enhanced DAD]: RFC 7527 - Enhanced Duplicate Address Detection

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

#113484 — Re: ifupdown behaviour with IPv6 DAD failure (Was: proposal: Hybrid network stack for Trixie)

On 23.09.24 13:39, Daniel Gröber wrote:
> On Mon, Sep 23, 2024 at 12:25:15PM +0200, Chris Hofstaedtler wrote:
>> * Pierre-Elliott Bécue <peb@debian.org> [240923 11:34]:
>>> I like ifupdown. It's simple and just works.
>>
>> I find this quite funny, given a recent discussion about IPv6 dad
>> issues with ifupdown on #debian-admin.
> 
> The "discussion" was about ifup@eth0 being in a failed state on a
> particular server due to a DAD failure and someone having to manually
> intervene.

I find my ghost being invoked here.

> Chris, what behaviour do you expect here? Below I'm going to assume what
> you're getting at is that we should continue to retry DAD.
> 
> To me going to a stable failure state seems desirable. Continuing to re-try
> for IPs could cause instability in the face of legitimate address
> conflicts: when the owning machine reboots the conflicting machine would
> now win the IP due to continous retrying. The change in owner would cause
> disruption to services entirely unrelated to the machine that was just
> rebooted.

DAD did not fail, it timed out after 60 sleeps of 0.1, aka 6s. The 
kernel subsequently succeeded to configure the network. The script in 
question was added in response to [1] and [2] to have a pause during 
boot to give the kernel time to resolve the situation before continuing 
the bootup. So it left the race around because there's not that much it 
can do better as a script-based setup without much state.

Unfortunately there's zero information from ifup@eth0 in the process as 
to when that happened. Which adds to the frustrating debugging stories 
when you can't get enough intel about what happened after the fact. 
(Which to be fair, also probably needs env vars to be set with 
systemd-networkd to increase the debug level.) As far as I can see 
processes started listening on the IP in question (that... again... 
wasn't logged because it's eaten by the script) a second afterwards.

So no, it did not enter a stable state. It let the kernel do its thing, 
which was to actually enable the address. I don't know why it takes 
Linux to run DAD for that long and what the assumptions around that are. 
But if you listen on netlink you learn when that happens and don't need 
to poll and could send events once that happens.

To be ultimately fair to ifupdown: There was probably not much of a 
winning move here. The annoying bit was the systemd service that was 
still in a failed state even though the failure condition resolved 
itself <1s later.

Kind regards
Philipp Kern

[1] https://www.agwa.name/blog/post/beware_the_ipv6_dad_race_condition
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705996

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

#113485 — Re: ifupdown behaviour with IPv6 DAD failure (Was: proposal: Hybrid network stack for Trixie)

On Mon, Sep 23, 2024 at 05:48:53PM +0200, Philipp Kern wrote:
> > > > I like ifupdown. It's simple and just works.
> > > 
> > > I find this quite funny, given a recent discussion about IPv6 dad
> > > issues with ifupdown on #debian-admin.
> > 
> > The "discussion" was about ifup@eth0 being in a failed state on a
> > particular server due to a DAD failure and someone having to manually
> > intervene.
> 
> I find my ghost being invoked here.
> 
> > Chris, what behaviour do you expect here? Below I'm going to assume what
> > you're getting at is that we should continue to retry DAD.
> > 
> > To me going to a stable failure state seems desirable. Continuing to re-try
> > for IPs could cause instability in the face of legitimate address
> > conflicts: when the owning machine reboots the conflicting machine would
> > now win the IP due to continous retrying. The change in owner would cause
> > disruption to services entirely unrelated to the machine that was just
> > rebooted.
> 
> DAD did not fail, it timed out after 60 sleeps of 0.1, aka 6s. The kernel
> subsequently succeeded to configure the network. The script in question was
> added in response to [1] and [2] to have a pause during boot to give the
> kernel time to resolve the situation before continuing the bootup. So it
> left the race around because there's not that much it can do better as a
> script-based setup without much state.

I'm not familiar with the discussion on #debian-admin, so the details
may be different, but I can point to a specific use case where we want
DAD/SLAAC failure handled without marking the interface as failed.  The
cloud team wanted to produce working images that would support both
IPv4-only and dualstack environments transparently, without knowing the
type of environment in advance or requiring admin intervention. [1]

We ended up coming up with something that worked, but it would have been
nice if ifupdown could have handled this more gracefully. [2]

We have since transitioned to systemd-networkd and netplan; bullseye is
the last generation of cloud images to use ifupdown.  Although the above
issue certainly contributed to this decision, the primary driver for the
netplan change was the cloud-init integration.

noah

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804396#17
2. https://salsa.debian.org/cloud-team/debian-cloud-images/-/tree/master/config_space/bullseye/files/etc/network

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

#113489

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

Chris Hofstaedtler <zeha@debian.org> wrote on 23/09/2024 at 12:25:15+0200:

> * Pierre-Elliott Bécue <peb@debian.org> [240923 11:34]:
>> Lukas Märdian <slyon@debian.org> wrote on 20/09/2024 at 13:12:36+0200:
>> > # Why
>> > The ifupdown package is a Debian only solution that is becoming a maintenance
>> > burden. We've had plenty of discussions over the years and consensus is that we
>> > want to get rid of it.
>> 
>> I like ifupdown. It's simple and just works.
>
> I find this quite funny, given a recent discussion about IPv6 dad
> issues with ifupdown on #debian-admin.

Still looking for the funny bit, except if you're implying that as a DSA
member, I should dislike ifupdown because Philipp had to manually
intervene on a server managed by it. In that case it'd indeed be really
funny, but probably not for the reason you'd think it is.

> It's certainly limited in what it can do within reasonable
> configuration effort, and it often works. I think both are true for
> almost all of the discussed options :-)

Well, netplan has no added value in my environments, contrary to some
big changes we had in the past (systemd, journald - which still forwards
logs to rsyslog, …), so I'd rather not being force-fed this tool. I'd
react the same if someone were to try making me adopt resolved or
timesyncd.

But in the whole, I don't care that much, I'm perfectly fine with apt
purge netplan.io after bootstrapping a server if the "consensus" is to
force-feed it.

-- 
PEB

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

#113626

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

It seems to me this proposal is just a *tad* too ambitious.

I haven't followed the entirety of all threads about this topic (has
anyone?) but it seems to me we're proposing to do two major changes at
once:

 1. replace ifupdown with systemd-networkd
 2. unify configuration of networkd and NetworkManager with netplan

*Either* of those seems somewhat controversial to me, and after reading
a few messages in this thread, seems that neither has reached consensus.

For example, in my personal opinion, even if netplan could work with an
ifupdown backend (and it can't!) I wouldn't support #2 here. I don't see
why I would need a unified configuration layer between ifupdown (or
systemd-networkd) and NM, it basically never has been a use case for
me. I either configure servers (in which case i use ifupdown or
networkd) or desktops (in which case I use NM).

And then, of course, there's the "systemd question". I've been slowly
converting my personal servers over to systemd-networkd, because I've
been having similar issues than DSA with IPv6 contention issues.

It generally works! And, yeah, it's a couple of config files to
manage, but it's nothing that puppet (or ansible) can't easily handle,
so that's not a problem for me at all.

Yet, that change is a big deal in Debian. ifupdown is one of those
Debian-specific things that has been around since basically
forever. It's in numerous guides and manuals, so lots of documentation
would need to be updated to reflect such a huge change. And that's not
counting all the people who have expressed here and elsewhere that they
just don't *want* to change away from ifupdown.

I happen to think it's the right way to go, personally, but I think the
way to do this would be to first add support for systemd-networkd in d-i
and cloud images, rather than netplan, because that would be far less
controversial. It would still allow people who want to to stick to
ifupdown, for example, it would "just" change defaults.

Either way, coming from the bits from the DPL here, I was hoping to see
a unified proposal that would try to approach consensus, but I don't
feel this is it. netplan is yet another controversial idea, and I don't
think it's consensual.

I would focus on trying to reach consensus to replace ifupdown with
networkd in d-i/images first, in any case. If we *must* use netplan to
do this, as an implementation, then okay, so be it. But just deciding
this is a huge step, and we should focus on that, if that's the
direction we want to go.

Just a thought.
-- 
Computer science is no more about computers
than astronomy is about telescopes
                        - E. Dijkstra

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web