Control: owner -1 !
Control: tags -1 + confirmed
Hi Laurent,
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?
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.
Helmut
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)