Le 2/01/25 à 11:01, Helmut Grohne a écrit :
Hi Laurent,
Hello Helmut,
as per
https://salsa.debian.org/debian/tech-ctte/-/blob/master/procedures/moderation.md,
I am volunteering as moderator for this issue and thus setting myself as
owner.
On Wed, Jan 01, 2025 at 07:04:24PM +0100, Laurent Bigonville wrote:
In debian we have currently (at least?) two implementations of a mDNS
responder, avahi-daemon (the historical one) and systemd-resolved.
mDNS is used for automatic network discovery of services or machines.
Having both running at the same times, seems to cause issues, both avahi
and resolved are complaining that an other instance or a different mDNS
stack is running and fight with each others.
Seeing these errors/warings, I opened bug #1077937 asking to find a
solution but it seems that we cannot arrive at an agreement between the
maintainers of src:systemd and src:avahi.
Avahi is still wildly used today in the ecosystem to search for or
publish services. On the other hand it's not clear to me what other
applications are using this feature of resolved.
If that matters, on Fedora[0][1] they choose to disable by default the
mDNS feature of resolved.
The bug report that I opened contains multiple proposals to tackle this,
but one needs to be implemented.
Could you please have a look at that matter and see how we could made
avahi and resolved cohabit in Debian?
I read most of the referenced bug and try to summarize it here for the
benefit of other CTTE members and for confirmation from you.
Both systemd-resolved and avahi-daemon can provide mDNS functionality.
mDNS can mean resolving and/or publishing. Both implementations can be
configured for either or both. Concurrent publishing causes practical
issues (that lead to the filing of the bug) whereas concurrent resolving
causes warnings that may or may not be harmless.
There seems to be implied consensus on combing both being bad while the
disagreement is rooted in the mechanism used to avoid concurrent use.
One proposed solution is to default-disable mDNS functionality in
resolved by a build-time option in the systemd package. This is what
Fedora is doing and Laurent Bigonville, Michel Biebl, and Simon McVittie
have expressed themselves in favour of this option. Luca Boccassi
disagrees.
Another proposed solution is to have avahi-daemon disable mDNS
functionality in resolved by dropping a configuration file for resolved
containing MulticastDNS=no. Luca Bocassi is in favour of this approach
whereas Michael Biebl expressed concern.
Preventing coinstallation of avahi-daemon and systemd-resolved has not
been considered as an option. A fair number of other packages recommend
either, so they are practically combined fairly often.
Luca Boccassi argues that systemd-resolved should support mDNS in its
default configuration as that matches the upstream default and mDNS
resolution should just work on a system where systemd-resolved is
installed. Instead he proposes the other mechanism.
Laurent, do you consider this summary accurate?
Thanks for your summary, yes that looks accurate.
Michael argues against the second mechanism:
| I would prefer the solution Fedora has chosen, i.e. build systemd
| with -Ddefault-mdns=no. This will provide a more predictable behaviour
| for systemd-resolved and is imho a cleaner solution. Users that want the
| mdns functionality can easily opt-in via a config snippet.
This is the main counter-argument I found in the bug log. I have
questions.
* Why is more predictable behaviour for systemd-resolved desirable?
Would I not prefer having mDNS resolution just work?
* Why do you consider default-disabling mDNS support in
systemd-resolved a cleaner solution than disabling mDNS support once
avahi-daemon gets installed?
* Why do you favour users having to configure systemd-resolved over
having it just work? With the drop-in we'd get the following matrix:
| SR installed | SR removed
-------------+--------------+-----------
AD installed | AD used | AD used
AD removed | SR used | no mDNS
At this time, I do not have a good understanding of the arguments
brought forward and appreciate feedback from Michael and Laurent for
clarification.
I'm not opposed on resolved having mDNS features enabled by default
(well modulo privacy questions), it's more the fact that my
understanding until now was that having one package configure default
features of an other package like was not really allowed.
Regarding the predictability, I guess that can be two fold:
1) Linked to the previous point, an unrelated package changes the
configuration of an other package
2) Should the resolved configuration snippets be installed in /etc (as a
conffile) or in /usr. With the former there is a risk that the conffile
is not purged leading to user confusion. But a conffile is maybe not
necessary as configuration in /etc should override the one in /usr
If we are going with using the configuration snippet, one renaming
question would be about the value of the "MulticastDNS=" option, should
we keep the mDNS resolving part of resolved or disable it completely?
That would probably require to check whether the nsswitch.conf file is
OK to avoid duplication (mdns4_minimal nss plugin is installed
(Recommends) by default by task-desktop, like avahi).
Bottom line, on my side it's more a policy question
Kind regards,
Laurent
