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

From	Daniel Gröber <dxld@darkboxed.org>
Newsgroups	linux.debian.devel, linux.debian.bugs.dist
Subject	Re: Replacing isc-dhcp-client with dhcpcd-base (Was: ifupdown maintenance)
Date	2024-09-23 16:00 +0200
Message-ID	<JpRLz-eial-5@gated-at.bofh.it> (permalink)
References	(5 earlier) <JmbfP-bXqW-17@gated-at.bofh.it> <JmmNX-c4za-3@gated-at.bofh.it> <JmtPr-c8Ko-1@gated-at.bofh.it> <JmAed-ccCn-13@gated-at.bofh.it> <JpRLz-eial-7@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Cross-posted to 2 groups.

Show all headers | View raw

[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

Thread

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

csiph-web