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
Attachment:
signature.asc
Description: PGP signature