Hi Martin, Marc, and Santiago, On Thu, Jul 11, 2024 at 12:57:52PM +0300, Martin-Éric Racine wrote: > > 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.
Indeed. That part of the thread currently feels more like a popularity contest than a technical discussion. Let's try to do better. Actual technical arguments for a change I've seen so far: - ifreload functionality would improve usability. In favor of ifupdown2/sd-networkd and maybe NM? not sure. - Better maintainability and test coverage. In favor of all except ifupdown. AFAICT 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 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. Well, this is what we have now. Working code is more valuable than the code you seem to not have written down yet. Get busy if you think you can do better. My guess is this ended up being like this for some backwards compat concern or other and I don't think this particular bike-shed is worth fussing over, but feel free to get involved upstream and/or figure out the *why* on your own. FYI #ifupdown-ng is on OFTC :) > > 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. You aren't thinking of `hotplug` stanza integration with systemd, right? On Thu, Jul 11, 2024 at 08:13:38AM +0200, Marc Haber wrote: > ¹ 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. Thanks for bringing this up Marc. I've been mulling doing something about this precise problem in ifupdown-ng. I didn't know we used to have a working implementation of this idea. I might revive it since I don't think changing the default behaviour of ifupdown* is a good idea, but suggest/recommending a package fixing it is an easy sell. > 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? On Thu, Jul 11, 2024 at 09:16:55AM -0300, Santiago Ruano Rincón wrote: > > ... 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. Santiago, I'd like to point out the argument doesn't apply to ifupdown-ng, which was developed for use in Alpine where they'd been using our ifupdown until they switched. So there's nothing "Debian-specific" about it. I'd call it a model of serendipitous cross-distributon collaboration :D On Thu, Jul 11, 2024 at 09:08:23AM -0300, Santiago Ruano Rincón wrote: > > 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. It's not clear to me this particular issue is worth fixing. I do tend to question whether bailing out if anything fails during ifup is a good idea and I don't have a complete picture of the tradeoffs involved yet. My preference would be to carry on upping no matter what, but record what happend during up. Certainly something to discuss in more depth. > > 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. OK, good :) > > 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! I'll talk to listmaster, but I'm not sure lists.debian.org is the right place for this. > > 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. ACK. It is on my TODO list but anyone interested is welcome to submit a design (issue) and code upstream. --Daniel
signature.asc
Description: PGP signature
