Bug 1867830 - can't connect using mDNS addressing when systemd-resolved is running
Summary: can't connect using mDNS addressing when systemd-resolved is running
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException
Depends On:
Blocks: F33BetaFreezeException 1834846
TreeView+ depends on / blocked
 
Reported: 2020-08-10 22:59 UTC by Chris Murphy
Modified: 2021-07-18 12:42 UTC (History)
19 users (show)

Fixed In Version: systemd-246.4-1.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-09 18:55:08 UTC
Type: Bug


Attachments (Terms of Use)

Description Chris Murphy 2020-08-10 22:59:42 UTC
Description of problem:

When systemd-resolved is running, I'm unable to resolve mDNS computer names for ssh (and gvfs-smb mounts).


Version-Release number of selected component (if applicable):
avahi-0.8-3.fc33.x86_64
systemd-246-1.fc33.x86_64


How reproducible:
Always


Steps to Reproduce:
[chris@fmac ~]$ ssh chris@flap.local
chris@flap.local's password: 
Last login: Mon Aug 10 16:52:33 2020 from 10.0.0.249
[chris@flap ~]$ exit
logout
Connection to flap.local closed.
[chris@fmac ~]$ sudo systemctl start systemd-resolved.service 
[chris@fmac ~]$ ssh chris@flap.local
ssh: Could not resolve hostname flap.local: Name or service not known
[chris@fmac ~]$ sudo systemctl stop systemd-resolved.service 
[chris@fmac ~]$ ssh chris@flap.local
chris@flap.local's password: 
Last login: Mon Aug 10 16:54:14 2020 from 10.0.0.219
[chris@flap ~]$ exit
logout
Connection to flap.local closed.
[chris@fmac ~]$ 


Actual results:

I can't connect to flap.local when resolved is running.


Expected results:

I should be able to connect to flap.local.


Additional info:

Workstation F32 to Workstation F32, this works.
Workstation F33 to Workstation F33, does not work. It's a regression.

Comment 1 Chris Murphy 2020-08-10 23:08:37 UTC
At the time of the failed ssh connection, nothing is reported in the journal on either the host or the client.

Comment 2 Ben Cotton 2020-08-11 15:18:51 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

Comment 3 Villy Kruse 2020-08-13 13:27:19 UTC
"mdns4_minimal" must come before "resolve" in /etc/nsswitch.  Otherwise systemd-resolved claims any mDNF names does not exist and that will then be considered the final result.

systemd-resolved can be configured to resolve mDNF names if you wish.  That tends to clash a little bit with the avahi daemon.

Comment 4 Michael Catanzaro 2020-08-13 14:03:37 UTC
(In reply to Villy Kruse from comment #3)
> "mdns4_minimal" must come before "resolve" in /etc/nsswitch.  Otherwise
> systemd-resolved claims any mDNF names does not exist and that will then be
> considered the final result.

The order on a freshly-installed F33 system should be:

resolve [!UNAVAIL=return] myhostname files mdns4_minimal [NOTFOUND=return] dns

(Testing to confirm that's working properly would be great, since it's built up by scriptlets.)

> systemd-resolved can be configured to resolve mDNF names if you wish.  That
> tends to clash a little bit with the avahi daemon.

It should be resolving mdns because in F33 it's built with -Ddefault-mdns=resolve. Something is wrong.

In F32 you should be able to get the F33 behavior by setting MulticastDNS=resolve in /etc/systemd/resolved.conf

Comment 5 Villy Kruse 2020-08-13 14:24:29 UTC
(In reply to Michael Catanzaro from comment #4)
> (In reply to Villy Kruse from comment #3)
> > "mdns4_minimal" must come before "resolve" in /etc/nsswitch.  Otherwise
> > systemd-resolved claims any mDNF names does not exist and that will then be
> > considered the final result.
> 
> The order on a freshly-installed F33 system should be:
> 
> resolve [!UNAVAIL=return] myhostname files mdns4_minimal [NOTFOUND=return]
> dns
> 
> (Testing to confirm that's working properly would be great, since it's built
> up by scriptlets.)
> 

Yes that is how it was, and mDNS resolution didn't work.  Moving "mdns4_minimal [NOTFOUND=return]" to the front makes it work.  If mdns4-minimal comes after resolve, the you might just as well remove the mdns package.


> > systemd-resolved can be configured to resolve mDNF names if you wish.  That
> > tends to clash a little bit with the avahi daemon.
> 
> It should be resolving mdns because in F33 it's built with
> -Ddefault-mdns=resolve. Something is wrong.
> 
> In F32 you should be able to get the F33 behavior by setting
> MulticastDNS=resolve in /etc/systemd/resolved.conf


If I remember correctly, you also need to enable mDNS for each link configuration.  It test this about a year ago.
Use resolvedctl to check what it actually is.

What is not clear is if the cups printer browsing will still work without the avahi daemon.  mDNS resolution by systemd-resolved works best when avahi is removed.

Comment 6 Chris Murphy 2020-08-13 14:47:32 UTC
(In reply to Michael Catanzaro from comment #4)
> The order on a freshly-installed F33 system should be:
> 
> resolve [!UNAVAIL=return] myhostname files mdns4_minimal [NOTFOUND=return]
> dns

It is.

(In reply to Villy Kruse from comment #5)
> Moving "mdns4_minimal [NOTFOUND=return]" to the front makes it work.

Confirmed.

Comment 7 Michael Catanzaro 2020-08-13 15:04:49 UTC
(In reply to Villy Kruse from comment #5)
> Yes that is how it was, and mDNS resolution didn't work.  Moving
> "mdns4_minimal [NOTFOUND=return]" to the front makes it work.  If
> mdns4-minimal comes after resolve, the you might just as well remove the
> mdns package.

I don't think so, it's still needed for broadcasting right?

And the point of keeping it in the Hosts: line is so that mdns continues to work even if resolved is disabled.

> What is not clear is if the cups printer browsing will still work without
> the avahi daemon.  mDNS resolution by systemd-resolved works best when avahi
> is removed.

Really, why?

Comment 8 Michael Catanzaro 2020-08-13 15:06:07 UTC
(In reply to Villy Kruse from comment #5)
> Yes that is how it was, and mDNS resolution didn't work.  Moving
> "mdns4_minimal [NOTFOUND=return]" to the front makes it work.  If
> mdns4-minimal comes after resolve, the you might just as well remove the
> mdns package.

Anyway, that confirms it's a systemd bug. mdns is supposed to work without moving these around.

Comment 9 Chris Murphy 2020-08-13 15:11:43 UTC
If I use the same nsswitch.conf 'hosts' line from F33, on F32, using systemd-245.6-2.fc32.x86_64, then start up systemd-resolved - name resolution fails. So it's not a systemd-246 regression from 245.

Comment 10 Villy Kruse 2020-08-13 17:36:42 UTC
(In reply to Michael Catanzaro from comment #8)
> (In reply to Villy Kruse from comment #5)
> > Yes that is how it was, and mDNS resolution didn't work.  Moving
> > "mdns4_minimal [NOTFOUND=return]" to the front makes it work.  If
> > mdns4-minimal comes after resolve, the you might just as well remove the
> > mdns package.
> 
> Anyway, that confirms it's a systemd bug. mdns is supposed to work without
> moving these around.

IMHO Not a bug.  But you are welcome to file a bug report upstreams.

Notice the entry "resolve [!UNAVAIL=return]".  It means that if resolved replies at all, that reply is final.  No further atempts of resolving the name is attempted.  That is by design.

Comment 11 Villy Kruse 2020-08-13 17:41:08 UTC
(In reply to Chris Murphy from comment #9)
> If I use the same nsswitch.conf 'hosts' line from F33, on F32, using
> systemd-245.6-2.fc32.x86_64, then start up systemd-resolved - name
> resolution fails. So it's not a systemd-246 regression from 245.

Fedora  31 as well.

Comment 12 Villy Kruse 2020-08-13 18:16:42 UTC
(In reply to Michael Catanzaro from comment #7)
> (In reply to Villy Kruse from comment #5)
> > Yes that is how it was, and mDNS resolution didn't work.  Moving
> > "mdns4_minimal [NOTFOUND=return]" to the front makes it work.  If
> > mdns4-minimal comes after resolve, the you might just as well remove the
> > mdns package.
> 
> I don't think so, it's still needed for broadcasting right?

Explain.

> 
> And the point of keeping it in the Hosts: line is so that mdns continues to
> work even if resolved is disabled.
> 

systemd-resolved is hard to get rid of.  If you stop it, it might be re-activated by dbus.
And with the default /etc/resolv.conf you have to talk to systemd-resolved anyway for regular dns queries through the socket 127.0.0.35:35.  That is, unless you disable the stub resolver, and specify real dns servers in /etc/resolv.conf.

> > What is not clear is if the cups printer browsing will still work without
> > the avahi daemon.  mDNS resolution by systemd-resolved works best when avahi
> > is removed.
> 
> Really, why?

Aug 13 19:59:14 secondbux systemd-resolved[1748]: mDNS-IPv4: There appears to be another mDNS responder running, or previously systemd-resolved crashed with some outstanding transfers.
Aug 13 19:59:14 secondbux systemd-resolved[1748]: mDNS-IPv6: There appears to be another mDNS responder running, or previously systemd-resolved crashed with some outstanding transfers.

systemd-resolved and avahi server both tries to listen to the same mDNS socket.

Comment 13 Michael Catanzaro 2020-08-13 18:28:02 UTC
(In reply to Villy Kruse from comment #10)
> > Anyway, that confirms it's a systemd bug. mdns is supposed to work without
> > moving these around.
> 
> IMHO Not a bug.  But you are welcome to file a bug report upstreams.

Why do you think it's not a bug? resolved is supposed to resolve mdns and it's failing to do so.

We need to track it here because it implicates our contingency plan in https://fedoraproject.org/wiki/Changes/systemd-resolved.

> Notice the entry "resolve [!UNAVAIL=return]".  It means that if resolved
> replies at all, that reply is final.  No further atempts of resolving the
> name is attempted.  That is by design.

Yes. There's no point in continuing on to the other modules if resolved is running.

Comment 14 Michael Catanzaro 2020-08-13 18:31:12 UTC
(In reply to Villy Kruse from comment #12)
> Aug 13 19:59:14 secondbux systemd-resolved[1748]: mDNS-IPv4: There appears
> to be another mDNS responder running, or previously systemd-resolved crashed
> with some outstanding transfers.
> Aug 13 19:59:14 secondbux systemd-resolved[1748]: mDNS-IPv6: There appears
> to be another mDNS responder running, or previously systemd-resolved crashed
> with some outstanding transfers.
> 
> systemd-resolved and avahi server both tries to listen to the same mDNS
> socket.

OK, looks like our plan to use -Ddefault-mdns=resolve failed. I guess we need to move mdns4_minimal in front of resolve in nsswitch.conf (which entails updating both systemd.spec and authselect), and build systemd with -Ddefault-mdns=no so it doesn't interfere. Zbigniew will need to approve this change....

Comment 15 Chris Murphy 2020-08-13 18:53:20 UTC
I don't know why but even after reverting the nsswitch.conf, disabling systemd-resolved, and rebooting - both F32 and F33 Workstations are now cranky and will not resolve mDNS hostnames.

Also on both systems:

$ sudo authselect apply-changes
[error] [/etc/nsswitch.conf] is not a symbolic link!
[error] [/etc/nsswitch.conf] was not created by authselect!
[error] Unexpected changes to the configuration were detected.
[error] Refusing to activate profile unless those changes are removed or overwrite is requested.
Some unexpected changes to the configuration were detected. Use 'select' command instead.

Ick.

Comment 16 Chris Murphy 2020-08-13 19:13:25 UTC
Reverted to a snapshot copy from 10 days ago..

# authselect apply-changes
[error] [/etc/authselect/nsswitch.conf] has unexpected content!
[error] [/etc/nsswitch.conf] is not a symbolic link!
[error] [/etc/nsswitch.conf] was not created by authselect!
[error] Unexpected changes to the configuration were detected.
[error] Refusing to activate profile unless those changes are removed or overwrite is requested.
Some unexpected changes to the configuration were detected. Use 'select' command instead.


At the very top of the configuration file it says it was created by authselect. Lovely.

Comment 17 Michael Catanzaro 2020-08-13 20:07:45 UTC
Lesson: never manually change /etc/nsswitch.conf :)

Comment 18 Chris Murphy 2020-08-13 21:11:03 UTC
Ha no kidding. I ended up having to do a rollback on both computers. (yay btrfs)

Comment 19 Villy Kruse 2020-08-14 05:34:33 UTC
(In reply to Michael Catanzaro from comment #13)
> (In reply to Villy Kruse from comment #10)
> > > Anyway, that confirms it's a systemd bug. mdns is supposed to work without
> > > moving these around.
> > 
> > IMHO Not a bug.  But you are welcome to file a bug report upstreams.
> 
> Why do you think it's not a bug? resolved is supposed to resolve mdns and
> it's failing to do so.
> 

It does resolve mDNS names; if you configure it to do so.  You have to enable it both globally and per link.

Comment 20 Michael Catanzaro 2020-08-24 16:16:13 UTC
(In reply to Villy Kruse from comment #19)
> It does resolve mDNS names; if you configure it to do so.  You have to
> enable it both globally and per link.

Villy, this is supposed to be working by default. Is there some problem with Fedora's configuration?

Zbigniew, if we can't fix this, then I suggest we place mdns4_minimal first as a fallback plan:

(In reply to Michael Catanzaro from comment #14)
> OK, looks like our plan to use -Ddefault-mdns=resolve failed. I guess we
> need to move mdns4_minimal in front of resolve in nsswitch.conf (which
> entails updating both systemd.spec and authselect), and build systemd with
> -Ddefault-mdns=no so it doesn't interfere. Zbigniew will need to approve
> this change....

Actually we don't need to change how systemd is built, we only need to ensure mdns4_minimal comes first. Then if systemd is failing to properly resolve mdns, that's harmless.

Comment 21 Villy Kruse 2020-08-25 05:49:00 UTC
(In reply to Michael Catanzaro from comment #20)
> (In reply to Villy Kruse from comment #19)
> > It does resolve mDNS names; if you configure it to do so.  You have to
> > enable it both globally and per link.
> 
> Villy, this is supposed to be working by default. Is there some problem with
> Fedora's configuration?
> 

You know.  Theory and practice is the same -- in theory.  In practice it never is.

From  "man resolved.conf"

       MulticastDNS=
           Takes a boolean argument or "resolve". Controls Multicast DNS support (RFC 6762[2]) on the local
           host. If true, enables full Multicast DNS responder and resolver support. If false, disables
           both. If set to "resolve", only resolution support is enabled, but responding is disabled. Note
           that systemd-networkd.service(8) also maintains per-link Multicast DNS settings. Multicast DNS
           will be enabled on a link only if the per-link and the global setting is on.

It works with this configurations:


[root@fc33 ~]# resolvectl
Global
       LLMNR setting: no
MulticastDNS setting: yes    <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 2 (eth0)
      Current Scopes: DNS mDNS/IPv4 mDNS/IPv6
DefaultRoute setting: yes
       LLMNR setting: no
MulticastDNS setting: yes    <<<<<<<<<<<<<<<<<<<<<<<<<<
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
  Current DNS Server: 192.168.100.1
         DNS Servers: 192.168.100.1
[root@fc33 ~]#


[root@fc33 ~]# cat /etc/systemd/resolved.conf
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details

[Resolve]
#DNS=
FallbackDNS=
#Domains=
#DNSSEC=no
#DNSOverTLS=no
MulticastDNS=yes       <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
LLMNR=no
#Cache=yes
#DNSStubListener=yes
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no
[root@fc33 ~]#


[root@fc33 ~]# cat /etc/systemd/network/80-dhcp.network
# /etc/systemd/network/80-dhcp.network
[Match]
Name=e*

[Network]
DHCP=yes
MulticastDNS=yes     <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
LLMNR=no
[root@fc33 ~]#

But only if you ditch NetworkManager and use systemd-networkd  Also avahi is removed.

Comment 22 Michael Catanzaro 2020-08-25 16:56:23 UTC
Well we are using MulticastDNS setting: resolve to ensure that resolved doesn't interfere with avahi and allow avahi to handle DNS responding. And that ought to work....

Comment 23 Chris Murphy 2020-08-29 20:26:13 UTC
Following clean installs of the following:
Fedora-Workstation-Live-x86_64-33-20200821.n.0.iso
Fedora-Workstation-Live-x86_64-33-20200828.n.0.iso

From the installation, other systems are not resolved. But other systems can resolve this installation. So the problem isn't bidirectional. The Fedora 33 system is responding, but not resolving.

Comment 24 Chris Murphy 2020-08-29 20:32:52 UTC
Curiously, it does resolve itself. i.e. while on the fmac.local computer I can successfully:

ssh chris@fmac.local

Comment 25 Villy Kruse 2020-08-30 05:41:33 UTC
(In reply to Chris Murphy from comment #23)
> Following clean installs of the following:
> Fedora-Workstation-Live-x86_64-33-20200821.n.0.iso
> Fedora-Workstation-Live-x86_64-33-20200828.n.0.iso
> 
> From the installation, other systems are not resolved. But other systems can
> resolve this installation. So the problem isn't bidirectional. The Fedora 33
> system is responding, but not resolving.

The name is resolved by the avahi server.

Try (replacing the name enxxx with the actual name of your network interface name)

  resolvectl mdns enxxx resolve

This setting is temporary.  To enable it permanently you need to enable it in the configuration of the network device as well as in /etc/systemd/resolved.conf.

If you had been using systemd-networkd instead of NetworkManager is done in this file:

[root@fc33 ~]# cat /etc/systemd/network/80-dhcp.network
# /etc/systemd/network/80-dhcp.network
[Match]
Name=e*

[Network]
DHCP=yes
MulticastDNS=yes     <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
LLMNR=no
[root@fc33 ~]#

Comment 26 Villy Kruse 2020-08-30 05:44:19 UTC
(In reply to Chris Murphy from comment #24)
> Curiously, it does resolve itself. i.e. while on the fmac.local computer I
> can successfully:
> 
> ssh chris@fmac.local

systemd-resolved will synthesize all local names as documented in the mane page for systemd-resolved.  It does this without the help of mdns, llmnr or dns.

Comment 27 Chris Murphy 2020-08-30 05:57:28 UTC
(In reply to Villy Kruse from comment #25)
> Try (replacing the name enxxx with the actual name of your network interface
> name)
> 
>   resolvectl mdns enxxx resolve
> 
> This setting is temporary.

Yep, now the F33 system can connect using e.g. 'ssh chris@flap.local' so I guess now it's resolving.


>To enable it permanently you need to enable it
> in the configuration of the network device as well as in
> /etc/systemd/resolved.conf.

I don't understand. The distribution needs to do this so it works out of the box, as it has been before systemd-resolved was enabled by default.


> If you had been using systemd-networkd instead of NetworkManager is done in
> this file:

F32 and F33 use NetworkManager by default. I'm only particularly concerned about the default behaviors working correctly.

Comment 28 Villy Kruse 2020-08-30 07:06:14 UTC
(In reply to Chris Murphy from comment #27)
> (In reply to Villy Kruse from comment #25)
> > Try (replacing the name enxxx with the actual name of your network interface
> > name)
> > 
> >   resolvectl mdns enxxx resolve
> > 
> > This setting is temporary.
> 
> Yep, now the F33 system can connect using e.g. 'ssh chris@flap.local' so I
> guess now it's resolving.
> 
> 
> >To enable it permanently you need to enable it
> > in the configuration of the network device as well as in
> > /etc/systemd/resolved.conf.
> 
> I don't understand. The distribution needs to do this so it works out of the
> box, as it has been before systemd-resolved was enabled by default.
> 

It is a bit complicated and not very well documented.  That is why moving mdns-minimal is by far the simplest way to fix this.

> 
> > If you had been using systemd-networkd instead of NetworkManager is done in
> > this file:
> 
> F32 and F33 use NetworkManager by default. I'm only particularly concerned
> about the default behaviors working correctly.

And there are very good reasons to keep on using NetworkManager, not least of which is the network configuration utility.

Comment 29 Michael Catanzaro 2020-08-30 14:10:18 UTC
Anyway we know it's broken and the simplest solution is to move mdns-minimal first. We need Zbigniew to fix this, since he can touch the systemd package scriptlets where this is set up. Maybe he's on holiday. :)

Comment 30 Villy Kruse 2020-08-30 17:14:32 UTC
(In reply to Michael Catanzaro from comment #29)
> Anyway we know it's broken and the simplest solution is to move mdns-minimal
> first. We need Zbigniew to fix this, since he can touch the systemd package
> scriptlets where this is set up. Maybe he's on holiday. :)

It also involves the authselect package; more specifically the patch file 0002-profiles-add-support-for-resolved.patch

Comment 31 Geoffrey Marr 2020-08-31 17:27:17 UTC
Discussed during the 2020-08-31 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedFreezeException" was made as it is a noticeable issue that cannot be fixed with an update.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-08-31/f33-blocker-review.2020-08-31-16.00.txt

Comment 32 Zdenek Dohnal 2020-09-01 05:41:27 UTC
Hi all,

please note that fixing this issue is critical for any modern (driverless) printing and scanning in Fedora 34+ too.

Till F33 (F33 included) printing stack uses nss-mdns for resolving .local addresses and Avahi for more complex stuff (discovering services, registering them).
Since F34 I switched the stack to systemd-resolved for resolving .local addresses and Avahi remains as it is (or that's how I understood Michael's response to my email when the change proposal was introduced).

To sum it up, as long systemd-resolved is capable of working with Avahi (side by side or by cooperation) and only will replace nss-mdns (where printing stack is concerned), it will be okay for printing and scanning stack.

Comment 33 Andreas Tunek 2020-09-01 17:40:09 UTC
I am also affected by this bug. If I type in http://nas-name.local in Firefox or Gnome Web it does not connect to my NAS, but it works in F32.

Comment 34 Zbigniew Jędrzejewski-Szmek 2020-09-02 08:52:32 UTC
I changed the scriptlet to move files and mdns before resolve. (Files has to be moved
to maintain its higher priority. This means resolved's caching of files is made meaningless.)
I also changed -Default-mdns=resolve to -Default-mdns=no. IIUC, this is necessary to avoid
the two daemons fighting over the port.

Comment 35 Fedora Update System 2020-09-02 11:07:10 UTC
FEDORA-2020-2255b438a2 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2255b438a2

Comment 36 Zbigniew Jędrzejewski-Szmek 2020-09-02 12:03:03 UTC
When testing this, I realized that the scriptlet in nss-mdns needs to be adjusted too, so that we get
the same order when nss-mdns is installed before systemd or after:
https://src.fedoraproject.org/rpms/nss-mdns/pull-request/3

Comment 37 Michael Catanzaro 2020-09-02 13:04:39 UTC
And we also have to update authselect as well. So in addition to the systemd update, we also need nss-mdns and authselect updates as part of this freeze exception. And maybe an update for the printing stack?

(In reply to Zdenek Dohnal from comment #32)
> Till F33 (F33 included) printing stack uses nss-mdns for resolving .local
> addresses and Avahi for more complex stuff (discovering services,
> registering them).
> Since F34 I switched the stack to systemd-resolved for resolving .local
> addresses and Avahi remains as it is (or that's how I understood Michael's
> response to my email when the change proposal was introduced).
> 
> To sum it up, as long systemd-resolved is capable of working with Avahi
> (side by side or by cooperation) and only will replace nss-mdns (where
> printing stack is concerned), it will be okay for printing and scanning
> stack.

Do we need to revert the printing stack back to using nss-mdns and avahi as well?

Comment 38 Zbigniew Jędrzejewski-Szmek 2020-09-02 13:16:27 UTC
How does the printing stack resolve names? I assumed that it simply uses normal
nss calls to resolve it. I wasn't aware of any special adjustments there, so if
we make mdns have higher priority again, it would get used automatically by the
printing stack.

Comment 39 Fedora Update System 2020-09-02 13:57:15 UTC
FEDORA-EPEL-2020-21311a703e has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-21311a703e

Comment 40 Fedora Update System 2020-09-02 13:57:40 UTC
FEDORA-2020-f6aa7fb2e7 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-f6aa7fb2e7

Comment 41 Fedora Update System 2020-09-02 13:57:48 UTC
FEDORA-2020-9bd5ae0ee6 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-9bd5ae0ee6

Comment 42 Fedora Update System 2020-09-02 13:57:55 UTC
FEDORA-2020-6af113d6b8 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6af113d6b8

Comment 43 Fedora Update System 2020-09-02 13:58:04 UTC
FEDORA-EPEL-2020-1965d16d87 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1965d16d87

Comment 44 Villy Kruse 2020-09-02 14:44:18 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #38)
> How does the printing stack resolve names? I assumed that it simply uses
> normal
> nss calls to resolve it. I wasn't aware of any special adjustments there, so
> if
> we make mdns have higher priority again, it would get used automatically by
> the
> printing stack.


For most part, cups talk via dbus directly with avahi.  It needs to register the printer names and configurations with avahi, so remote computer can discover these names.  avahi also stores printer parameters and printer capabilities.  Modern printer often publishes printer names and capabilities which also will be stored by the avahi server.

A lot of details is given in this debian site:  https://wiki.debian.org/Printing

For simple name look-up it doesn't matter if nss-mdns or systemd-resolved provides the answer via the normal mdns protocol.

Comment 45 Fedora Update System 2020-09-02 16:20:17 UTC
FEDORA-2020-2255b438a2 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-2255b438a2`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-2255b438a2

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 46 Fedora Update System 2020-09-02 16:20:58 UTC
FEDORA-2020-f6aa7fb2e7 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-f6aa7fb2e7`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-f6aa7fb2e7

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 47 Zdenek Dohnal 2020-09-03 05:35:02 UTC
Hi Zbyszek,

it is like Villy wrote - most mDNS related stuff in printing stack is done by Avahi (registering, discovering, sharing), but cupsd daemon should be capable of working with printer device uris like:

ipp://printer.local:631/ipp/print

then mDNS hostname is resolved in httpAddrGetList(). It uses getaddrinfo() from glibc, which doesn't work if nss-mdns or other mDNS names resolver is installed.

Michael, just to be sure, do I understand correctly I need to revert the change in F34 because systemd-resolved is not able to substitute for nss-mdns and work alongside with Avahi?

Comment 48 Villy Kruse 2020-09-03 07:43:04 UTC
(In reply to Zdenek Dohnal from comment #47)
> Hi Zbyszek,
> 
> it is like Villy wrote - most mDNS related stuff in printing stack is done
> by Avahi (registering, discovering, sharing), but cupsd daemon should be
> capable of working with printer device uris like:
> 
> ipp://printer.local:631/ipp/print
> 
> then mDNS hostname is resolved in httpAddrGetList(). It uses getaddrinfo()
> from glibc, which doesn't work if nss-mdns or other mDNS names resolver is
> installed.
> 

A lot of programs uses getaddrinfo and they all resolve mDNS names find via nss-mdns, and also via systemd.resolved as long as the per link setting for mDNS is set.

What is missing is a feature in the NetworkManager configuration utility (and the Gnome equivalent) to enable and disable mDNS for each managed links.  Same for llmnr.

> Michael, just to be sure, do I understand correctly I need to revert the
> change in F34 because systemd-resolved is not able to substitute for
> nss-mdns and work alongside with Avahi?

systemd-resolved can work alongside avahi as long as NetworkManager tells it to do so.  You just get two daemons keeping track of mDNS names.

Comment 49 Andreas Tunek 2020-09-03 09:03:41 UTC
I did `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-2255b438a2` and rebooted, but I can't see any difference, I still get the same errors.

Comment 50 Villy Kruse 2020-09-03 09:18:35 UTC
(In reply to Andreas Tunek from comment #49)
> I did `sudo dnf upgrade --enablerepo=updates-testing
> --advisory=FEDORA-2020-2255b438a2` and rebooted, but I can't see any
> difference, I still get the same errors.

The edit scriptlet does not work if "resolve" has already been added to nsswitch.  You will need to hand-edit the file /etc/authselect/user-nsswitch.conf and run "authselect apply-changes".

This should be acceptable as this is not yet the final release.

Comment 51 Michael Catanzaro 2020-09-03 15:31:45 UTC
(In reply to Andreas Tunek from comment #49)
> I did `sudo dnf upgrade --enablerepo=updates-testing
> --advisory=FEDORA-2020-2255b438a2` and rebooted, but I can't see any
> difference, I still get the same errors.

This update configures systemd-resolved to no longer handle mDNS responses.

It's not expected that it would fix this your system if you installed F33 prerelease prior to this point. You'll need to manually change the hosts line in /etc/authselect/user-nsswitch.conf as discussed in comment #34, then run 'sudo authselect apply-changes'. Users installing F33 beta and users upgrading from F32 should not have this problem.

Comment 52 Michael Catanzaro 2020-09-03 15:33:04 UTC
(In reply to Michael Catanzaro from comment #51)
> This update configures systemd-resolved to no longer handle mDNS responses.

I don't understand the changes to the printing stack, but we're just reverting back to F32 status quo with respect to mDNS: only avahi handles mDNS.

Comment 53 Michael Catanzaro 2020-09-03 15:34:17 UTC
(In reply to Michael Catanzaro from comment #51)
> It's not expected that it would fix this your system if you installed F33
> prerelease prior to this point. You'll need to manually change the hosts
> line in /etc/authselect/user-nsswitch.conf as discussed in comment #34, then
> run 'sudo authselect apply-changes'. Users installing F33 beta and users
> upgrading from F32 should not have this problem.

Sorry, I'm bad at reading... I see Villy said exactly this one comment above. Anyway, I agree. :P Thanks Villy!

Comment 54 Fedora Update System 2020-09-03 16:30:26 UTC
FEDORA-2020-9bd5ae0ee6 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-9bd5ae0ee6`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-9bd5ae0ee6

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 55 Fedora Update System 2020-09-03 16:41:13 UTC
FEDORA-EPEL-2020-1965d16d87 has been pushed to the Fedora EPEL 8 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1965d16d87

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 56 Fedora Update System 2020-09-03 16:51:06 UTC
FEDORA-EPEL-2020-21311a703e has been pushed to the Fedora EPEL 7 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-21311a703e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 57 Fedora Update System 2020-09-03 17:12:43 UTC
FEDORA-2020-6af113d6b8 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-6af113d6b8`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6af113d6b8

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 58 Adam Williamson 2020-09-03 22:20:24 UTC
Can affected folks please test the two updates intended to address this (to systemd and nss-mdns) and give them karma, especially nss-mdns which is sitting at 0? It will help make sure they get in Beta, assuming they work well.

Comment 59 Chris Murphy 2020-09-04 06:53:01 UTC
Updating systemd-246.4-1.fc33.x86_64 nss-mdns-0.14.1-9.fc33.x86_64 and doing sudo authselect apply-changes isn't enough to fix it (bug remains for me anyway). I think we have to clean install to be sure. That's my understanding of Michael's comment in 51.

Fedora-Workstation-Live-x86_64-33-20200903.n.0.iso has
systemd-246.1-1.fc33.x86_64
nss-mdns-0.14.1-8.fc33.x86_64

I'm not sure how to test this.

Comment 60 Villy Kruse 2020-09-04 08:23:51 UTC
(In reply to Chris Murphy from comment #59)
> Updating systemd-246.4-1.fc33.x86_64 nss-mdns-0.14.1-9.fc33.x86_64 and doing
> sudo authselect apply-changes isn't enough to fix it (bug remains for me
> anyway). I think we have to clean install to be sure. That's my
> understanding of Michael's comment in 51.
> 
> Fedora-Workstation-Live-x86_64-33-20200903.n.0.iso has
> systemd-246.1-1.fc33.x86_64
> nss-mdns-0.14.1-8.fc33.x86_64
> 
> I'm not sure how to test this.

It should be nss-mdns-0.14.1-9.fc33.x86_64 and systemd-246.4-1.fc33.x86_64 from updates-testing

First remove nss-mdns

dnf remove --noautoremove nss-mdns

Edit /etc/authselect/user-nsswitch.conf so this line starting with hosts: read like this

hosts:      files myhostname dns

and the run 

authselect apply-changes

Then update to the new version

dnf update --enablerepo=updates-testing systemd-246.4-1.fc33.x86_64

dnf install --enablerepo=updates-testing nss-mdns-0.14.1-9.fc33.x86_64

grep '^hosts' /etc/nsswitch and check the contents

hosts:      files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] myhostname dns

Comment 61 Chris Murphy 2020-09-04 14:41:39 UTC
I already had systemd-246.4-1.fc33.x86_64 and nss-mdns-0.14.1-9.fc33.x86_64 so I modified the instructions:

dnf remove --noautoremove nss-mdns
Edit /etc/authselect/user-nsswitch.conf  as described
authselect apply-changes
dnf reinstall --enablerepo=updates-testing systemd-246.4-1.fc33.x86_64
dnf install --enablerepo=updates-testing nss-mdns-0.14.1-9.fc33.x86_64

And now /etc/nsswitch.conf contains:

hosts:      files mdns4_minimal [NOTFOUND=return] myhostname dns


systemd-resolved.service is active (running), and I am able to connect to other machines using their mdns hostnames, e.g. ssh chris@flap.local. And connecting to this machine from other machines continues to work. So functionally it appears fixed, but the hosts line is not correct I guess since it's missing the 'resolve [!UNAVAIL=return]' section.


The compose log for Fedora-Workstation-Live-x86_64-33-20200904.n.0.iso still shows
systemd-246.1-1.fc33.x86_64
nss-mdns-0.14.1-8.fc33.x86_64
which is because we're in freeze, and their newer versions aren't yet released for inclusion in compose pending testing. It's something of a catch-22. Same with the /etc/resolv.conf not being a symlink issue.

Comment 62 Michael Catanzaro 2020-09-04 15:44:06 UTC
m, the systemd scriptlet that inserts nss-resolve into the hosts line is a little fragile:
	
function mod_nss() {
    if [ -f "$1" ] ; then
        # Add nss-systemd to passwd and group
        grep -E -q '^(passwd|group):.* systemd' "$1" ||
        sed -i.bak -r -e '
                s/^(passwd|group):(.*)/\1:\2 systemd/
                ' "$1" &>/dev/null || :
 
        # Add nss-resolve to hosts
        grep -E -q '^hosts:.* resolve' "$1" ||
        sed -i.bak -r -e '
                s/^(hosts):(.*) files( mdns4_minimal .NOTFOUND=return.)? dns myhostname/\1:\2 files\3 resolve [!UNAVAIL=return] myhostname dns/
                ' "$1" &>/dev/null || :
    fi
}

If user-nsswitch doesn't list the nss modules in the order that the scriptlet is expecting -- first files, then optionally mdns4_minimal, then dns, then myhostname -- it won't work properly. I haven't actually attempted to learn enough sed to be confident of how exactly that script works, but I assume that's how it is. Anyway, if you installed F33 prior to this update, you have myhostname before files before nss-mdns, so the scriptlet won't work and you'll probably have to add resolve manually.

What's important is to make sure this works properly for fresh installs of F33 where these updates are included in the live image, and for upgrades from F32. I wouldn't be confident this is fixed until we have tested both cases. I think it ought to work for upgrades from F32, but we should test to be sure. We should also test a fresh install of F33 after we have live media that includes this update to be confident it's good. Previous installs of F33 are going to require manual intervention, but this is only a problem for testers who installed prior to beta, so I can live with that.

WARNING WARNING WARNING: Zbigniew, won't https://github.com/authselect/authselect/pull/222 break this scriptlet? It expects dns to come before myhostname, and switches them itself. But if they are already switched, the sed line won't work at all, right? So the scriptlet will need to be updated again at the same time as the forthcoming authselect update?

Comment 63 Michael Catanzaro 2020-09-04 15:49:44 UTC
(In reply to Adam Williamson from comment #58)
> Can affected folks please test the two updates intended to address this (to
> systemd and nss-mdns) and give them karma, especially nss-mdns which is
> sitting at 0? It will help make sure they get in Beta, assuming they work
> well.

We really need the updates included in live media before we can test them. There's too much manual intervention required to test before they are included. I think blindly giving karma is entirely appropriate in this case.

Comment 64 Villy Kruse 2020-09-04 16:45:10 UTC
(In reply to Chris Murphy from comment #61)
> I already had systemd-246.4-1.fc33.x86_64 and nss-mdns-0.14.1-9.fc33.x86_64
> so I modified the instructions:
> 
> dnf remove --noautoremove nss-mdns
> Edit /etc/authselect/user-nsswitch.conf  as described
> authselect apply-changes
> dnf reinstall --enablerepo=updates-testing systemd-246.4-1.fc33.x86_64
> dnf install --enablerepo=updates-testing nss-mdns-0.14.1-9.fc33.x86_64
> 

The scriptlet is in systemd-libs, so you need to re-install that one as well.


> And now /etc/nsswitch.conf contains:
> 
> hosts:      files mdns4_minimal [NOTFOUND=return] myhostname dns
> 
>

Comment 65 Villy Kruse 2020-09-04 16:51:31 UTC
(In reply to Michael Catanzaro from comment #62)


> 
> WARNING WARNING WARNING: Zbigniew, won't
> https://github.com/authselect/authselect/pull/222 break this scriptlet? It
> expects dns to come before myhostname, and switches them itself. But if they
> are already switched, the sed line won't work at all, right? So the
> scriptlet will need to be updated again at the same time as the forthcoming
> authselect update?

myhostname only resolves your local hostnames, "localhost" and "_gateway", so unless your DNS provides these names it makes no difference.  Besides, if I am not mistaken, resolved will resolved these local names as well.  And furthermore, if resolved is running, it will provide the final answer, and neither dns, nor myhostname will be considered.

Comment 66 Chris Murphy 2020-09-04 17:01:58 UTC
(In reply to Villy Kruse from comment #64)
> The scriptlet is in systemd-libs, so you need to re-install that one as well.

dnf reinstall --enablerepo=updates-testing systemd-libs-246.4-1.fc33.x86_64

No change in /etc/nsswitch.conf

Comment 67 Michael Catanzaro 2020-09-04 17:21:46 UTC
(In reply to Villy Kruse from comment #65)
> myhostname only resolves your local hostnames, "localhost" and "_gateway",
> so unless your DNS provides these names it makes no difference.  Besides, if
> I am not mistaken, resolved will resolved these local names as well.  And
> furthermore, if resolved is running, it will provide the final answer, and
> neither dns, nor myhostname will be considered.

But nss-resolve is not going to be included in the hosts line at all if systemd-libs doesn't add it there because its sed script depends on the ordering between nss-myhostname and nss-dns.

Comment 68 Adam Williamson 2020-09-04 18:52:59 UTC
@mcatanzaro if they'd both been included in the same update as opposed to being separate, openQA would have built a live image suitable for testing already :/ I can probably hack one up, though.

Comment 69 Villy Kruse 2020-09-04 19:33:27 UTC
(In reply to Chris Murphy from comment #66)
> (In reply to Villy Kruse from comment #64)
> > The scriptlet is in systemd-libs, so you need to re-install that one as well.
> 
> dnf reinstall --enablerepo=updates-testing systemd-libs-246.4-1.fc33.x86_64
> 
> No change in /etc/nsswitch.conf

Sorry, I made a mistake.  The original line as freshly installed by glibc is

hosts:      files dns myhostname

Notice: "dns" before "myhostname".  I don't know if the systemd script swaps those two for a reason, or if it was a mistake.

So before reinstalling the systemd modules the line should read

hosts:      files mdns4_minimal [NOTFOUND=return] dns myhostname

Comment 70 Chris Murphy 2020-09-04 19:42:06 UTC
nano /etc/authselect/user-nsswitch.conf and modify such that

hosts:      files dns myhostname

authselect apply-changes
dnf reinstall --enablerepo=updates-testing systemd-libs-246.4-1.fc33.x86_64 
dnf reinstall --enablerepo=updates-testing nss-mdns-0.14.1-9.fc33.x86_64
cat /etc/nsswitch.conf

hosts:      files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] myhostname dns

bidirectional ssh/scp with mdns hostname is working.

Comment 71 Michael Catanzaro 2020-09-04 23:17:08 UTC
Zbigniew says we want files before myhostname: https://github.com/authselect/authselect/pull/222#issuecomment-686394671

Anyway, this all just indicates how unmaintainable it is to split configuration between glibc, authselect, systemd scriptlet and nss-mdns scriptlet. Now we want files at the very front, but only if nss-mdns is installed, otherwise it goes after resolved. It's too hard for me to keep track of it all, and we have to get maintainers in four different places to agree....

Comment 72 Adam Williamson 2020-09-05 01:18:18 UTC
Yeah, that seems like a bad idea. Shouldn't this all be routed through authselect somehow or other?

Comment 73 Villy Kruse 2020-09-05 07:04:29 UTC
With the line

hosts:      files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] myhostname dns

it will work even if nss-mdns is not installed.  So autselect could define it that way.

Comment 74 Andreas Tunek 2020-09-06 08:14:26 UTC
I don't have the skills to test this in current F33, so I will wait until it is included in a F33 live image and do a fresh install.

Comment 75 Fedora Update System 2020-09-08 17:04:17 UTC
FEDORA-2020-2255b438a2 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 76 Fedora Update System 2020-09-08 17:04:34 UTC
FEDORA-2020-f6aa7fb2e7 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 77 Adam Williamson 2020-09-08 17:10:22 UTC
I'm not sure we should consider this closed given all the issues discussed above. Setting back to ON_QA for now. At least with it pushed stable the changes will show up in new live images for testing. It would also be good if folks can test upgrades from F32 to F33 and see how they behave.

Comment 78 Kamil Páral 2020-09-08 17:51:12 UTC
I just installed a fresh F33 (with an older systemd) and then updated everything from updates-testing (including systemd-246.4-1.fc33). "$machine.local" resolution doesn't work. My /etc/nsswitch.conf contains:
hosts:      resolve [!UNAVAIL=return] myhostname files mdns4_minimal [NOTFOUND=return] dns

Should the systemd update only fix it for fresh installations, or even for system updates?

Comment 79 Villy Kruse 2020-09-08 18:19:09 UTC
(In reply to Kamil Páral from comment #78)
> I just installed a fresh F33 (with an older systemd) and then updated
> everything from updates-testing (including systemd-246.4-1.fc33).
> "$machine.local" resolution doesn't work. My /etc/nsswitch.conf contains:
> hosts:      resolve [!UNAVAIL=return] myhostname files mdns4_minimal
> [NOTFOUND=return] dns
> 
> Should the systemd update only fix it for fresh installations, or even for
> system updates?

It would not fix that.  Once it find the "reolve" entry, it wont' touch it further.

The edit scripts is meant for the upgrade from Fedora32 to Fedora33.  The install image will eventually be released with the correct contents of the hosts line.

Comment 80 Michael Catanzaro 2020-09-08 19:05:17 UTC
(In reply to Kamil Páral from comment #78)
> Should the systemd update only fix it for fresh installations, or even for
> system updates?

It's expected to work for updates from freshly-installed F32. Updates from F33 like you did will require manual intervention to fix.

Comment 81 Chris Murphy 2020-09-08 19:39:20 UTC
20200909 images should have it (on media)

Comment 82 Michael Catanzaro 2020-09-08 20:10:36 UTC
I'll try tomorrow and see if it's working (a) for fresh installs, then (b) for updates from F32.

Comment 83 Andreas Tunek 2020-09-09 18:34:05 UTC
Fresh install from 20200909 works for me.

Comment 84 Michael Catanzaro 2020-09-09 18:54:55 UTC
(In reply to Michael Catanzaro from comment #82)
> I'll try tomorrow and see if it's working (a) for fresh installs, then (b)
> for updates from F32.

I've verified that the hosts line is configured correctly in both (a) and (b) scenarios.

I haven't actually tested mDNS, since I don't have anything that uses it, but the original bug here is definitely fixed so it should be working.

Comment 85 Kamil Páral 2020-09-10 13:45:59 UTC
For anyone finding this bug, it would be nice to say how people can fix their systems.

Comment 87 Fedora Update System 2020-09-10 17:31:28 UTC
FEDORA-2020-6af113d6b8 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 88 Fedora Update System 2020-09-11 15:14:07 UTC
FEDORA-2020-9bd5ae0ee6 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 89 Fedora Update System 2020-09-18 15:27:00 UTC
FEDORA-EPEL-2020-1965d16d87 has been pushed to the Fedora EPEL 8 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 90 Fedora Update System 2020-09-18 15:30:21 UTC
FEDORA-EPEL-2020-21311a703e has been pushed to the Fedora EPEL 7 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 91 Thomas Haller 2021-01-14 15:59:32 UTC
(In reply to Villy Kruse from comment #48)]
>
> What is missing is a feature in the NetworkManager configuration utility
> (and the Gnome equivalent) to enable and disable mDNS for each managed
> links.  Same for llmnr.

This is wrong. They can be configured in NetworkManager per-profile:

   nmcli connection modify "$PROFILE" connection.mdns yes connection.llmnr yes

https://developer.gnome.org/NetworkManager/stable/nm-settings-nmcli.html

And -- since you quote how to edit systemd .network files -- of course you can edit NetworkManager profile files (which are also ini-files) with these values (followed by `nmcli connection reload`).

The defaults of the per-profile settings can also be configure systemwide in NetworkManager.conf (see `man NetworkManager.conf`).

What is correct is that the GUIs currently don't support these options. Which in this case is because nobody implemented them, or (less likely) that they are omitted intentional as being out of scope for the GUI.

Comment 92 Villy Kruse 2021-01-15 07:13:46 UTC
(In reply to Thomas Haller from comment #91)
> (In reply to Villy Kruse from comment #48)]
> >
> > What is missing is a feature in the NetworkManager configuration utility
> > (and the Gnome equivalent) to enable and disable mDNS for each managed
> > links.  Same for llmnr.
> 
> This is wrong. They can be configured in NetworkManager per-profile:
> 
>    nmcli connection modify "$PROFILE" connection.mdns yes connection.llmnr
> yes
> 
> https://developer.gnome.org/NetworkManager/stable/nm-settings-nmcli.html
> 

You are right, you could do that.  By the way, llmnr is enabled by default.

> And -- since you quote how to edit systemd .network files -- of course you
> can edit NetworkManager profile files (which are also ini-files) with these
> values (followed by `nmcli connection reload`).
> 

It gets a bit more complicated on upgraded system where the configuration files are /etc/sysconfig/network-scripts/ifcfg-*.

Editing systemd-networkd configuration files is also something you should not ask end users do do.

> The defaults of the per-profile settings can also be configure systemwide in
> NetworkManager.conf (see `man NetworkManager.conf`).
> 
> What is correct is that the GUIs currently don't support these options.
> Which in this case is because nobody implemented them, or (less likely) that
> they are omitted intentional as being out of scope for the GUI.

If you are on a public wifi network, it is not a good idea to have llmnr and/or mDNS enabled for security reasons.
Thus, it would be nice if end users can easily enable it at home and disable it elsewhere.

Comment 93 Zdenek Dohnal 2021-01-18 10:48:40 UTC
Hi Villy,

so the current issue is no GUI provides a way to set up the profile as Tom did in comment #91 via CLI?

I'm trying to understand what needs to be done to enable Avahi and systemd-resolved working together and file tickets to the correct components.

Thank you in advance!

Comment 94 Zdenek Dohnal 2021-01-18 12:17:46 UTC
If I understand it correctly - systemd-resolved can be used alongside Avahi if:

1) resolved.conf has 'MulticastDNS=resolve' set

2) NetworkManager enables MDNS and LLMNR per-profile (can be done via nmcli command now, doing it via GUI is missing) and globally (via NetworkManager.conf?)

Do I understand it correctly?

Comment 95 Villy Kruse 2021-01-18 14:20:35 UTC
(In reply to Zdenek Dohnal from comment #93)
> Hi Villy,
> 
> so the current issue is no GUI provides a way to set up the profile as Tom
> did in comment #91 via CLI?
> 
> I'm trying to understand what needs to be done to enable Avahi and
> systemd-resolved working together and file tickets to the correct components.
> 
> Thank you in advance!

I think the best thing is to try it out for yourself;  that usually improves understanding.

Certainly, if you want a gui method to enable and disable mDNS, you will have to talk to the NetworkManager project, and the Gnome project as well.  Then it might also need to be co-ordinated with the avahi project and the authselect project.

Also, consider that different people have different needs for the networking set-up.  If you don't have cups printer sharing, there is little need to run that avahi daemon, for example.  If your network doesn't have devices using mDNS, there is no need to enable it.  If your device is connected to a public wifi network you should probably desiable both mDNS and llmnr, and also don't run avahi.  You would not want to announce your services in that environment.

Comment 96 Alan Altmann 2021-04-13 15:05:35 UTC
Same problem here.

Comment 97 Richard Kennedy 2021-07-18 12:42:45 UTC
I have this problem on fedora 34 -- avahi-browse can see the other devices on the network , but resolve can't see them. 

changing the host line in nsswitch.conf fixed it for me.

hosts:      files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] myhostname dns


Note You need to log in before you can comment on or make changes to this bug.