Bug#1091864: tech-ctte: Avahi and systemd-resolved cannot a run mDNS responder at the same time

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