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 chris'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 ssh: Could not resolve hostname flap.local: Name or service not known [chris@fmac ~]$ sudo systemctl stop systemd-resolved.service [chris@fmac ~]$ ssh chris chris'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.
At the time of the failed ssh connection, nothing is reported in the journal on either the host or the client.
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
"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.
(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
(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.
(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.
(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?
(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.
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.
(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.
(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.
(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.
(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.
(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....
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.
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.
Lesson: never manually change /etc/nsswitch.conf :)
Ha no kidding. I ended up having to do a rollback on both computers. (yay btrfs)
(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.
(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.
(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.
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....
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.
Curiously, it does resolve itself. i.e. while on the fmac.local computer I can successfully: ssh chris
(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 ~]#
(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 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.
(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' 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.
(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' 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.
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. :)
(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
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
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.
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.
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.
FEDORA-2020-2255b438a2 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2255b438a2
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
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?
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.
FEDORA-EPEL-2020-21311a703e has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-21311a703e
FEDORA-2020-f6aa7fb2e7 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-f6aa7fb2e7
FEDORA-2020-9bd5ae0ee6 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-9bd5ae0ee6
FEDORA-2020-6af113d6b8 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6af113d6b8
FEDORA-EPEL-2020-1965d16d87 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1965d16d87
(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.
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.
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.
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?
(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.
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.
(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.
(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.
(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.
(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!
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.
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.
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.
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.
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.
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.
(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
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. 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.
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?
(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.
(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 > >
(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.
(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
(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.
@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.
(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
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.
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....
Yeah, that seems like a bad idea. Shouldn't this all be routed through authselect somehow or other?
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.
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.
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.
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.
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.
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?
(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.
(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.
20200909 images should have it (on media)
I'll try tomorrow and see if it's working (a) for fresh installs, then (b) for updates from F32.
Fresh install from 20200909 works for me.
(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.
For anyone finding this bug, it would be nice to say how people can fix their systems.
Please see https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/QN5VHS5SRUG2ZXADMNPYN25Q5QYACBR4/
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.
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.
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.
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.
(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.
(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.
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!
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?
(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.
Same problem here.
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
I ran into this on fedora 36. I fixed it by adding 'MulticastDNS=resolve' to /etc/systemd/resolved.conf, and [connection] connection.mdns=1 to /etc/NetworkManager/NetworkManager.conf, then restarting NetworkManager and systemd-resolved