Bug 1965723

Note: "https://support.brother.com/g/b/downloadlist.aspx?c=us&lang=en&prod=hl2170w_all&os=127" worked fin in Fedora 33, but doesn't work in Fedora 34. Same as "http://localhost:631".

Following steps for mDNS with systemd-resolved resolved this bug for "network: dnssd", This feature introduced in Fedora 33 (but I never enabled in F33, and worked fine for 'network: dnssd') and Fedora 34 upgrade following steps needed itseems.

systemd-resolved is enabled and running by default since F33 and can be setup to work with Avahi on mDNS support which CUPS needs - Avahi does the advertising, registering and sharing devices, and resolved will handle '.local' address resolution. It will work with following steps:

put 'MulticastDNS=resolve' into /etc/systemd/resolved.conf

# systemctl restart systemd-resolved
# nmcli connection modify "SKY" connection.mdns yes connection.llmnr yes
# systemctl restart NetworkManager

Restarting cups service

# systemctl restart cups.service

Please feel free to close this bug.

Hi Sathiyamoorthy,

thank you for reporting the issue!

What you found out is one way how to solve the issue (if you set your system to use Avahi+resolved and configure networkmanager properly), however I set a weak dependency in cups to bring in nss-mdns, which makes mdns work without additional networkmanager setup.

So IMHO nss-mdns still should work.

Would you mind checking if you have nss-mdns installed?

And would you mind pasting 'hosts:' lines from your /etc/nsswitch.conf and /etc/authselect/user-nsswitch.conf files?

1) nss-mdns already installed

[root@toshiba SKY]# rpm -q nss-mdns
nss-mdns-0.14.1-11.fc34.x86_64

2) 'hosts' lines from /etc/nsswitch.conf 

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

3) 'hosts' lines from /etc/authselect/user-nsswitch.conf

#hosts:     db files nisplus nis dns
hosts:      files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

Please let me know if you need any other info, I suspect it could be related to old 'wi-fi/wireless card', I didn't have these issue on different 'wi-fi/wireless card' which is relatively newer and different vendor where I don't have to set this info listed in the bug to make it work (little insight).

Thank you for the data!

Would you mind reverting systemd-resolved+nm setup?

Otherwise we will not be able to find out whether mdns works via nss-mdns (because it will be served by resolved, if you don't revert).

The core of the issue with printing was that glibc wasn't able to resolved mdns name (which is in printer uri) to anything usable and printing failed due connection error because of that.
We can easily verify whether mdns resolution works by pinging any .local address (you can find your printer .local address by 'avahi-browse -avrt'), so I will ask to try pings further down.

(In reply to Sathiyamoorthy Kothandan from comment #4)
> I suspect it could be related
> to old 'wi-fi/wireless card', I didn't have these issue on different
> 'wi-fi/wireless card' which is relatively newer and different vendor where I
> don't have to set this info listed in the bug to make it work (little
> insight).

Do you mean you have another F34 machine, where mdns works without resolved+nm set up for mdns?

Because IMHO it is related to two issues (I suspect resolved was running at the start):
- the string sequence in 'hosts:' which now has 'myhostname' right after 'files'. 'myhostname' is the service specification connected to resolved.
- resolved here seems to return 'success' when the returned resolved name is either empty or bad, which prevents running other services in the 'host:'

=========================================================================================
So to sum it up - I would like to ask you to try 3 scenarios to see if they help.

But before all that - I see your /etc/nsswitch.conf and /etc/authselect/user-nsswitch.conf don't have the same 'hosts:' lines. I'm not an authselect maintainer, so I'm not completely sure whether it is okay to have those lines different, but IMO it can be an other source of issue..

So please check whether your /etc/nsswitch.conf is a symlink (it should be a symlink to /etc/authselect/nsswitch.conf).
If it is, please do:

$ sudo authselect apply-changes

It should update nsswitch.conf internally (I'm not sure whether) and ensure that user-nsswitch.conf is taken into account.

Otherwise, please update 'hosts:' line in /etc/nsswitch.conf to be the same as in /etc/authselect/user-nsswitch.conf.

Then, finally to the scenarios:

A) revert resolved+nm setup you've done, and try to ping some .local address - if it works now, then the issue was in your nsswitch.conf. IIUC that can happen in the following cases:
- if your nsswitch.conf isn't a symlink - nss-mdns update script didn't work properly
- if nsswitch.conf is a symlink, then:
  - 'authselect check' fails for you, or
  - authselect encountered a bug during applying changes

B) revert resolved+nm setup you've done and disable resolved completely (glibc should get 'UNAVAIL', which has a default action 'continue' according 'man nsswitch.conf') and see whether glibc can follow up further in 'hosts:' line in /etc/nsswitch.conf - if it can, then you should be able ping any .local address, because the resolving happens in nss-mdns

C) revert resolved+nm setup you've done, let resolved running, but disable its mdns support (and in nm too) and update the corresponding nsswitch.conf (if /etc/nsswitch.conf is a symlink, update /etc/authselect/user-nsswitch.conf and do 'authselect apply-changes'. If it is not a symlink, update /etc/nsswitch.conf) to have the 'hosts:' line:

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

This should do resolving via nss-mdns before systemd-resolved. If ping works, then we know nss-mdns works correctly.

1) Another Fedora 34 setup where I don't have to set mDNS/systemd-resolved changes and "network: dnssd" printer works fine.

> I suspect it could be related
> to old 'wi-fi/wireless card', I didn't have these issue on different
> 'wi-fi/wireless card' which is relatively newer and different vendor where I
> don't have to set this info listed in the bug to make it work (little
> insight).

Do you mean you have another F34 machine, where mdns works without resolved+nm set up for mdns?

[SKY] yes and it doesn't even allow to make nm changes where it fails.
# nmcli connection modify "SKY" connection.mdns yes connection.llmnr yes (this one fails)

2) no symlinks and authselect apply-changes reports "no existing configuration detected" for root & other id

[SKY@toshiba ~]$ ls -l /etc/nsswitch.conf /etc/authselect/user-nsswitch.conf
-rw-r--r-- 1 root root 1789 May 26 21:40 /etc/authselect/user-nsswitch.conf
-rw-r--r-- 1 root root 2150 May 26 21:40 /etc/nsswitch.conf

[SKY@toshiba ~]$ sudo authselect apply-changes

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for SKY: 
No existing configuration detected.

[root@toshiba SKY]# authselect apply-changes
No existing configuration detected.

3) No setting to mDNS/systemd-resolved, local ping doens't work and remote ping doesn't work

updated put 'MulticastDNS=no' into /etc/systemd/resolved.conf

# systemctl restart systemd-resolved
# nmcli connection modify "SKY" connection.mdns no connection.llmnr no
# systemctl restart NetworkManager

Restarting cups service

# systemctl restart cups.service

[root@toshiba SKY]# ping toshiba
PING toshiba(toshiba (fe80::e56:9d63:752d:adf7%wlp8s0)) 56 data bytes
64 bytes from toshiba (fe80::e56:9d63:752d:adf7%wlp8s0): icmp_seq=1 ttl=64 time=0.116 ms
64 bytes from toshiba (fe80::e56:9d63:752d:adf7%wlp8s0): icmp_seq=2 ttl=64 time=0.094 ms
64 bytes from toshiba (fe80::e56:9d63:752d:adf7%wlp8s0): icmp_seq=3 ttl=64 time=0.103 ms

[root@toshiba SKY]# ping BRN001BA918AF2B.local
ping: BRN001BA918AF2B.local: Name or service not known


[root@toshiba SKY]# nslookup BRN001BA918AF2B.local
Server:         127.0.0.53
Address:        127.0.0.53#53

** server can't find BRN001BA918AF2B.local: SERVFAIL

[root@toshiba SKY]# nslookup toshiba
Server:         127.0.0.53
Address:        127.0.0.53#53

Name:   toshiba
Address: 192.168.1.5
Name:   toshiba
Address: 192.168.122.1
Name:   toshiba
Address: fe80::e56:9d63:752d:adf7


[root@toshiba SKY]# nslookup 192.168.1.1
1.1.168.192.in-addr.arpa        name = _gateway.

4) enable resolved only and no changes to nm

updated put 'MulticastDNS=no' into /etc/systemd/resolved.conf

# systemctl restart systemd-resolved

[root@toshiba SKY]# nslookup BRN001BA918AF2B.local
Server:         127.0.0.53
Address:        127.0.0.53#53

** server can't find BRN001BA918AF2B.local: SERVFAIL

[root@toshiba SKY]# ping BRN001BA918AF2B.local
ping: BRN001BA918AF2B.local: Name or service not known

5) enable mDNS with systemd-resolved

put 'MulticastDNS=resolve' into /etc/systemd/resolved.conf

# systemctl restart systemd-resolved
# nmcli connection modify "SKY" connection.mdns yes connection.llmnr yes
# systemctl restart NetworkManager

Restarting cups service

# systemctl restart cups.service

[root@toshiba SKY]# ping BRN001BA918AF2B.local
PING BRN001BA918AF2B.local(BRN001BA918AF2B.local (fe80::224:2cff:fe57:5281%wlp8s0)) 56 data bytes
64 bytes from BRN001BA918AF2B.local (fe80::224:2cff:fe57:5281%wlp8s0): icmp_seq=1 ttl=64 time=3.07 ms
64 bytes from BRN001BA918AF2B.local (fe80::224:2cff:fe57:5281%wlp8s0): icmp_seq=2 ttl=64 time=2.67 ms
64 bytes from BRN001BA918AF2B.local (fe80::224:2cff:fe57:5281%wlp8s0): icmp_seq=3 ttl=64 time=4.72 ms
^C
--- BRN001BA918AF2B.local ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 2.673/3.486/4.718/0.885 ms
[root@toshiba SKY]# nslookup BRN001BA918AF2B.local
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   BRN001BA918AF2B.local
Address: 192.168.1.2
Name:   BRN001BA918AF2B.local
Address: fe80::224:2cff:fe57:5281

Let me know if you need any other addtional info or data.

(In reply to Sathiyamoorthy Kothandan from comment #6)
> 1) Another Fedora 34 setup where I don't have to set mDNS/systemd-resolved
> changes and "network: dnssd" printer works fine.
> 

Aha, isn't there a 'newer' Fedora installed there? Meaning it like there is a clean new install of Fedora 34 or it is upgraded from Fedora 30+.

The machine where you have the issue doesn't have nsswitch.conf as a symlink - which means the machine has installed Fedora 25 (approximately - I'm not authselect maintainer, so I'm not sure, but around that time authselect replaced nsswitch.conf with symlink) or older and then you have been upgrading the machine till F34.

Do let me know if my assumptions are incorrect.


> 2) no symlinks and authselect apply-changes reports "no existing
> configuration detected" for root & other id
> 
> [SKY@toshiba ~]$ ls -l /etc/nsswitch.conf /etc/authselect/user-nsswitch.conf
> -rw-r--r-- 1 root root 1789 May 26 21:40 /etc/authselect/user-nsswitch.conf
> -rw-r--r-- 1 root root 2150 May 26 21:40 /etc/nsswitch.conf
> 
> [SKY@toshiba ~]$ sudo authselect apply-changes
> 
> We trust you have received the usual lecture from the local System
> Administrator. It usually boils down to these three things:
> 
>     #1) Respect the privacy of others.
>     #2) Think before you type.
>     #3) With great power comes great responsibility.
> 
> [sudo] password for SKY: 
> No existing configuration detected.
> 
> [root@toshiba SKY]# authselect apply-changes
> No existing configuration detected.

I don't see from this log whether you manually updated nsswitch.conf (not via authselect, because you have nsswitch.conf from older Fedoras, which isn't symlink, so authselect commands don't work) as I mentioned in my comment to do in the case of 'nsswitch.conf is not symlink'.

If nsswitch.conf isn't a symlink, nss-mdns has a %posttrans scriptlet, which should do the manual update of nsswitch.conf for you, but it seems to fail in your case for some reason.

To verify that it is the core of the issue, I would be grateful if you changed nsswitch.conf in a text editor, so it will have the same 'hosts:' line as /etc/authselect/user-nsswitch.conf.

And then try those scenarios again (if you haven't changed /etc/nsswitch.conf based on my previous comment).

1)I tried both fresh install of Fedora 34 and install Fedora 33 and upgrade to Fedora 34, both same results. It should be part of upgrade process to create symlink from version X to version Y, there is no need for manual. 

Aha, isn't there a 'newer' Fedora installed there? Meaning it like there is a clean new install of Fedora 34 or it is upgraded from Fedora 30+.

The machine where you have the issue doesn't have nsswitch.conf as a symlink - which means the machine has installed Fedora 25 (approximately - I'm not authselect maintainer, so I'm not sure, but around that time authselect replaced nsswitch.conf with symlink) or older and then you have been upgrading the machine till F34.

Do let me know if my assumptions are incorrect.

[SKY] I tried all this option before filing this bug which is I tried both fresh install of Fedora 34 and install Fedora 33 and upgrade to Fedora 34, both same results. here /etc/nsswitch.conf is symlink points to /etc/authselect/user-nsswitch.conf

2) I have created symlink using ln without manually updating which is not needed, printer works, ping works, nslookup fails.

I don't see from this log whether you manually updated nsswitch.conf (not via authselect, because you have nsswitch.conf from older Fedoras, which isn't symlink, so authselect commands don't work) as I mentioned in my comment to do in the case of 'nsswitch.conf is not symlink'.

If nsswitch.conf isn't a symlink, nss-mdns has a %posttrans scriptlet, which should do the manual update of nsswitch.conf for you, but it seems to fail in your case for some reason.

To verify that it is the core of the issue, I would be grateful if you changed nsswitch.conf in a text editor, so it will have the same 'hosts:' line as /etc/authselect/user-nsswitch.conf.

And then try those scenarios again (if you haven't changed /etc/nsswitch.conf based on my previous comment).

[root@toshiba SKY]#ln -s /etc/authselect/user-nsswitch.conf /etc/nsswitch.conf
[root@toshiba SKY]# ls -l /etc/nsswitch.conf /etc/authselect/user-nsswitch.conf
-rw-r--r-- 1 root root 1789 May 26 21:40 /etc/authselect/user-nsswitch.conf
lrwxrwxrwx 1 root root   34 Jun  3 09:20 /etc/nsswitch.conf -> /etc/authselect/user-nsswitch.conf

[root@toshiba SKY]# ping BRN001BA918AF2B.local
PING BRN001BA918AF2B.local (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2 (192.168.1.2): icmp_seq=1 ttl=255 time=2.57 ms
64 bytes from 192.168.1.2 (192.168.1.2): icmp_seq=2 ttl=255 time=2.21 ms
^C
--- BRN001BA918AF2B.local ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 2.214/2.392/2.571/0.178 ms

[root@toshiba SKY]# nslookup BRN001BA918AF2B.local
Server:         127.0.0.53
Address:        127.0.0.53#53

** server can't find BRN001BA918AF2B.local: SERVFAIL

updated put 'MulticastDNS=no' into /etc/systemd/resolved.conf

# systemctl restart systemd-resolved
# nmcli connection modify "SKY" connection.mdns no connection.llmnr no
# systemctl restart NetworkManager

Restarting cups service

# systemctl restart cups.service

now able to print document.

nsswitch.conf is default profile and user-nsswitch.conf is user preferred profile where you have multiple profile and modify user-nsswitch.conf profile and use authselect to update in nsswich.conf default profile and review both profile to changes takes place. Please refer the below redhat documentation just in case.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_authentication_and_authorization_in_rhel/index

 Modifying a ready-made authselect profile
As a system administrator, you can modify one of the default profiles to suit your needs.

You can modify any of the items in the /etc/authselect/user-nsswitch.conf file with the exception of:

passwd
group
netgroup
automount
services
Running authselect select profile_name afterwards will result in transferring permissible changes from /etc/authselect/user-nsswitch.conf to the /etc/nsswitch.conf file. Unacceptable changes are overwritten by the default profile configuration.

IMPORTANT
Do not modify the /etc/nsswitch.conf file directly.

Procedure

Select an authselect profile, for example:

# authselect select sssd
Edit the /etc/authselect/user-nsswitch.conf file with your desired changes.
Apply the changes from the /etc/authselect/user-nsswitch.conf file:

# authselect apply-changes
Verification steps

Review the /etc/nsswitch.conf file to verify that the changes from /etc/authselect/user-nsswitch.conf have been propagated there.

It would be great if you used 'reply' (the left oriented arrow at the top right corner of comment). Otherwise your comment is hard to read and understand.

(In reply to Sathiyamoorthy Kothandan from comment #8)
> 1)I tried both fresh install of Fedora 34 and install Fedora 33 and upgrade
> to Fedora 34, both same results. It should be part of upgrade process to
> create symlink from version X to version Y, there is no need for manual. 

This is a question for the authselect maintainer and not myself. Maybe the upgrade path to make nsswitch.conf as a symlink is difficult to implement without any breakages.

> [SKY] I tried all this option before filing this bug which is I tried both
> fresh install of Fedora 34 and install Fedora 33 and upgrade to Fedora 34,
> both same results. here /etc/nsswitch.conf is symlink points to
> /etc/authselect/user-nsswitch.conf

F33 is too new. nsswitch.conf was turned into a symlink several years ago (Fedora 25 or so), so that's where my assumption (the fresh install of Fedora on the machine where you have nsswitch.conf as a regular file was done several years ago and then it has been upgraded to newer Fedoras through time) came from.

> 
> 2) I have created symlink using ln without manually updating which is not
> needed, printer works, ping works, nslookup fails.

Hmm, nslookup actually fails for me too, but I'm able to print.

(In reply to Sathiyamoorthy Kothandan from comment #8)
> [root@toshiba SKY]#ln -s /etc/authselect/user-nsswitch.conf
> /etc/nsswitch.conf
> [root@toshiba SKY]# ls -l /etc/nsswitch.conf
> /etc/authselect/user-nsswitch.conf
> -rw-r--r-- 1 root root 1789 May 26 21:40 /etc/authselect/user-nsswitch.conf
> lrwxrwxrwx 1 root root   34 Jun  3 09:20 /etc/nsswitch.conf ->
> /etc/authselect/user-nsswitch.conf
> 
> [root@toshiba SKY]# ping BRN001BA918AF2B.local
> PING BRN001BA918AF2B.local (192.168.1.2) 56(84) bytes of data.
> 64 bytes from 192.168.1.2 (192.168.1.2): icmp_seq=1 ttl=255 time=2.57 ms
> 64 bytes from 192.168.1.2 (192.168.1.2): icmp_seq=2 ttl=255 time=2.21 ms
> ^C
> --- BRN001BA918AF2B.local ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1002ms
> rtt min/avg/max/mdev = 2.214/2.392/2.571/0.178 ms
> 
> [root@toshiba SKY]# nslookup BRN001BA918AF2B.local
> Server:         127.0.0.53
> Address:        127.0.0.53#53
> 
> ** server can't find BRN001BA918AF2B.local: SERVFAIL
> 
> updated put 'MulticastDNS=no' into /etc/systemd/resolved.conf
> 
> # systemctl restart systemd-resolved
> # nmcli connection modify "SKY" connection.mdns no connection.llmnr no
> # systemctl restart NetworkManager
> 
> Restarting cups service
> 
> # systemctl restart cups.service
> 
> now able to print document.

MulticastDNS='no' is a default for resolved, so I guess you forgot to revert it before you did the testing. The same with nm changes.

So the issue is that %posttrans script didn't work for you.

(In reply to Sathiyamoorthy Kothandan from comment #9)
> nsswitch.conf is default profile and user-nsswitch.conf is user preferred
> profile where you have multiple profile and modify user-nsswitch.conf
> profile and use authselect to update in nsswich.conf default profile and
...
> 
> Review the /etc/nsswitch.conf file to verify that the changes from
> /etc/authselect/user-nsswitch.conf have been propagated there.

This looks like a copy from RHEL manual, but it doesn't count with possibility that nsswitch.conf can be a regular file.

===================================================================================


The issue is that sed-fu in nss-mdns %posttrans scriptlet didn't work for the user, reassigning to nss-mdns and to Zbyszek, who updated the sed-fu last time.

(In reply to Zdenek Dohnal from comment #11)
> (In reply to Sathiyamoorthy Kothandan from comment #8)
> > 1)I tried both fresh install of Fedora 34 and install Fedora 33 and upgrade
> > to Fedora 34, both same results. It should be part of upgrade process to
> > create symlink from version X to version Y, there is no need for manual. 
> 
> This is a question for the authselect maintainer and not myself. Maybe the
> upgrade path to make nsswitch.conf as a symlink is difficult to implement
> without any breakages.

[SKY] It's simple one line change like this "ln -f -s /etc/authselect/user-nsswitch.conf /etc/nsswitch.conf", this "-f" flag will forefully set the link if the one already exists without errors

> 
> > [SKY] I tried all this option before filing this bug which is I tried both
> > fresh install of Fedora 34 and install Fedora 33 and upgrade to Fedora 34,
> > both same results. here /etc/nsswitch.conf is symlink points to
> > /etc/authselect/user-nsswitch.conf
> 
> F33 is too new. nsswitch.conf was turned into a symlink several years ago
> (Fedora 25 or so), so that's where my assumption (the fresh install of
> Fedora on the machine where you have nsswitch.conf as a regular file was
> done several years ago and then it has been upgraded to newer Fedoras
> through time) came from.

[SKY] Your assumption is correct, but here the reality is different.

> 
> > 
> > 2) I have created symlink using ln without manually updating which is not
> > needed, printer works, ping works, nslookup fails.
> 
> Hmm, nslookup actually fails for me too, but I'm able to print.

[SKY]If I use this following one, nslookup, printer..etc works.

put 'MulticastDNS=resolve' into /etc/systemd/resolved.conf

# systemctl restart systemd-resolved
# nmcli connection modify "SKY" connection.mdns yes connection.llmnr yes
# systemctl restart NetworkManager

Restarting cups service

# systemctl restart cups.service

> 
> (In reply to Sathiyamoorthy Kothandan from comment #8)
> > [root@toshiba SKY]#ln -s /etc/authselect/user-nsswitch.conf
> > /etc/nsswitch.conf
> > [root@toshiba SKY]# ls -l /etc/nsswitch.conf
> > /etc/authselect/user-nsswitch.conf
> > -rw-r--r-- 1 root root 1789 May 26 21:40 /etc/authselect/user-nsswitch.conf
> > lrwxrwxrwx 1 root root   34 Jun  3 09:20 /etc/nsswitch.conf ->
> > /etc/authselect/user-nsswitch.conf
> > 
> > [root@toshiba SKY]# ping BRN001BA918AF2B.local
> > PING BRN001BA918AF2B.local (192.168.1.2) 56(84) bytes of data.
> > 64 bytes from 192.168.1.2 (192.168.1.2): icmp_seq=1 ttl=255 time=2.57 ms
> > 64 bytes from 192.168.1.2 (192.168.1.2): icmp_seq=2 ttl=255 time=2.21 ms
> > ^C
> > --- BRN001BA918AF2B.local ping statistics ---
> > 2 packets transmitted, 2 received, 0% packet loss, time 1002ms
> > rtt min/avg/max/mdev = 2.214/2.392/2.571/0.178 ms
> > 
> > [root@toshiba SKY]# nslookup BRN001BA918AF2B.local
> > Server:         127.0.0.53
> > Address:        127.0.0.53#53
> > 
> > ** server can't find BRN001BA918AF2B.local: SERVFAIL
> > 
> > updated put 'MulticastDNS=no' into /etc/systemd/resolved.conf
> > 
> > # systemctl restart systemd-resolved
> > # nmcli connection modify "SKY" connection.mdns no connection.llmnr no
> > # systemctl restart NetworkManager
> > 
> > Restarting cups service
> > 
> > # systemctl restart cups.service
> > 
> > now able to print document.
> 
> MulticastDNS='no' is a default for resolved, so I guess you forgot to revert
> it before you did the testing. The same with nm changes.
> 
> So the issue is that %posttrans script didn't work for you.

[SKY] I was following the redhat documentation "do not edit /etc/nsswitch.conf" file manually and just do "authselect apply-changes" only

> 
> (In reply to Sathiyamoorthy Kothandan from comment #9)
> > nsswitch.conf is default profile and user-nsswitch.conf is user preferred
> > profile where you have multiple profile and modify user-nsswitch.conf
> > profile and use authselect to update in nsswich.conf default profile and
> ...
> > 
> > Review the /etc/nsswitch.conf file to verify that the changes from
> > /etc/authselect/user-nsswitch.conf have been propagated there.
> 
> This looks like a copy from RHEL manual, but it doesn't count with
> possibility that nsswitch.conf can be a regular file.

[SKY] It counts only for regular file to verify /etc/nsswitch.conf updated after "authselect apply-changes" as same as "/etc/authselect/user-nsswitch.conf", this is void of symlink which is not a regular file.

> 
> =============================================================================
> ======
> 
> 
> The issue is that sed-fu in nss-mdns %posttrans scriptlet didn't work for
> the user, reassigning to nss-mdns and to Zbyszek, who updated the sed-fu
> last time.

[SKY]sounds good.

Another set of data where /etc/nsswitch.conf and /etc/authselect/user-nsswitch.conf two different files and not a symlink just in case.

1) updated /etc/nsswitch.conf to set "hosts:      files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

2)updated 'MulticastDNS=no' into /etc/systemd/resolved.conf

# systemctl restart systemd-resolved
# nmcli connection modify "SKY" connection.mdns no connection.llmnr no
# systemctl restart NetworkManager

3) ping & printer works 
[root@toshiba SKY]# ping BRN001BA918AF2B.local
PING BRN001BA918AF2B.local (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2 (192.168.1.2): icmp_seq=1 ttl=255 time=3.28 ms
64 bytes from 192.168.1.2 (192.168.1.2): icmp_seq=2 ttl=255 time=2.09 ms
64 bytes from 192.168.1.2 (192.168.1.2): icmp_seq=3 ttl=255 time=2.44 ms

(In reply to Sathiyamoorthy Kothandan from comment #12)
> (In reply to Zdenek Dohnal from comment #11)
> > (In reply to Sathiyamoorthy Kothandan from comment #8)
> > > 1)I tried both fresh install of Fedora 34 and install Fedora 33 and upgrade
> > > to Fedora 34, both same results. It should be part of upgrade process to
> > > create symlink from version X to version Y, there is no need for manual. 
> > 
> > This is a question for the authselect maintainer and not myself. Maybe the
> > upgrade path to make nsswitch.conf as a symlink is difficult to implement
> > without any breakages.
> 
> [SKY] It's simple one line change like this "ln -f -s
> /etc/authselect/user-nsswitch.conf /etc/nsswitch.conf", this "-f" flag will
> forefully set the link if the one already exists without errors

Unfortunately, I beg to differ for following reasons:

1) /etc/nsswitch.conf symlink must point to /etc/authselect/nsswitch.conf, not /etc/authselect/user-nsswitch.conf

2) your solution works only if user-nsswitch.conf and /etc/nsswitch.conf contains the same data or if you know that user-nsswitch.conf will work for your use cases.

But that's not a case for all setups - user can put a different settings into /etc/nsswitch.conf and authselect can put a different settings into user-nsswitch.conf too, so migration script would need to first merge those two settings (/etc/nsswitch.conf and /etc/authselect/user-nsswitch.conf), update /etc/authselect/nsswitch.conf and then create /etc/nsswitch.conf symlink. Otherwise you can lose some functionality if you just forcefully replace /etc/nsswitch.conf with symlink.

And an automatic merging isn't a simple task - you can encounter merge conflicts and then you need to know which file has a priority for a specific conflict, so its change will be applied in the merged file... and the priority can vary conflict by conflict, user by user etc., so IMHO it is near to impossible to have such a automatic merge which will work without any user input...

IMO sed-fu which Pavel and Zbyszek introduced in nss-mdns is mainly a best effort to deal with the situation - probably a manual intervention is still needed for some use cases, such was yours.



> > > 2) I have created symlink using ln without manually updating which is not
> > > needed, printer works, ping works, nslookup fails.
> > 
> > Hmm, nslookup actually fails for me too, but I'm able to print.
> 
> [SKY]If I use this following one, nslookup, printer..etc works.

IMO it is because of behavior described here https://serverfault.com/questions/607908/dig-nslookup-cant-resolve-local-hosts-unless-i-specify-the-local-dns-server .

Without resolved, nslookup looks for hostnames in name servers specified in /etc/resolv.conf, which are name servers on the WAN, so it logically cannot find hostnames which are defined only on LAN.

But once you enable resolved+nm, nslookup sees only IP which corresponds with local systemd-resolved instance, so the query goes to systemd-resolved. And systemd-resolved handles queries for local and wide known hostnames, so then it is able to provide an answer.

Regardless, whether nslookup works or not doesn't influence printing at all, so testing nslookup regarding printing is bogus.

> > MulticastDNS='no' is a default for resolved, so I guess you forgot to revert
> > it before you did the testing. The same with nm changes.
> > 
> > So the issue is that %posttrans script didn't work for you.
> 
> [SKY] I was following the redhat documentation "do not edit
> /etc/nsswitch.conf" file manually and just do "authselect apply-changes" only
> 

As I wrote before, the doc thinks you have /etc/nsswitch.conf as a symlink and the whole manual is based on it. If you don't have /etc/nsswitch.conf as a symlink, 'authselect apply-changes' does nothing and you need to manually change /etc/nsswitch.conf or apply your changes from /etc/nsswitch.conf to /etc/authselect/user-nsswitch.conf, remove /etc/nsswitch.conf, create symlink /etc/nsswitch.conf->/etc/authselect/user-nsswitch.conf and use 'authselect apply-changes'.

(In reply to Zdenek Dohnal from comment #14)
> (In reply to Sathiyamoorthy Kothandan from comment #12)
> > (In reply to Zdenek Dohnal from comment #11)
> > > (In reply to Sathiyamoorthy Kothandan from comment #8)
> > > > 1)I tried both fresh install of Fedora 34 and install Fedora 33 and upgrade
> > > > to Fedora 34, both same results. It should be part of upgrade process to
> > > > create symlink from version X to version Y, there is no need for manual. 
> > > 
> > > This is a question for the authselect maintainer and not myself. Maybe the
> > > upgrade path to make nsswitch.conf as a symlink is difficult to implement
> > > without any breakages.
> > 
> > [SKY] It's simple one line change like this "ln -f -s
> > /etc/authselect/user-nsswitch.conf /etc/nsswitch.conf", this "-f" flag will
> > forefully set the link if the one already exists without errors
> 
> Unfortunately, I beg to differ for following reasons:
> 
> 1) /etc/nsswitch.conf symlink must point to /etc/authselect/nsswitch.conf,
> not /etc/authselect/user-nsswitch.conf

[SKY] There is no /etc/authselect/nsswitch.conf file

[root@toshiba SKY]# ls -l /etc/nsswitch.conf /etc/authselect/nsswitch.conf
ls: cannot access '/etc/authselect/nsswitch.conf': No such file or directory
-rw-r--r-- 1 root root 2242 Jun  5 22:54 /etc/nsswitch.conf

[root@toshiba SKY]# ls -l /etc/authselect/*nsswitch.conf
-rw-r--r-- 1 root root 1789 May 26 21:40 /etc/authselect/user-nsswitch.conf
[root@toshiba SKY]# 


> 
> 2) your solution works only if user-nsswitch.conf and /etc/nsswitch.conf
> contains the same data or if you know that user-nsswitch.conf will work for
> your use cases.
> 
> But that's not a case for all setups - user can put a different settings
> into /etc/nsswitch.conf and authselect can put a different settings into
> user-nsswitch.conf too, so migration script would need to first merge those
> two settings (/etc/nsswitch.conf and /etc/authselect/user-nsswitch.conf),
> update /etc/authselect/nsswitch.conf and then create /etc/nsswitch.conf
> symlink. Otherwise you can lose some functionality if you just forcefully
> replace /etc/nsswitch.conf with symlink.
> 
> And an automatic merging isn't a simple task - you can encounter merge
> conflicts and then you need to know which file has a priority for a specific
> conflict, so its change will be applied in the merged file... and the
> priority can vary conflict by conflict, user by user etc., so IMHO it is
> near to impossible to have such a automatic merge which will work without
> any user input...
> 
> IMO sed-fu which Pavel and Zbyszek introduced in nss-mdns is mainly a best
> effort to deal with the situation - probably a manual intervention is still
> needed for some use cases, such was yours.
> 
> 
> 
> > > > 2) I have created symlink using ln without manually updating which is not
> > > > needed, printer works, ping works, nslookup fails.
> > > 
> > > Hmm, nslookup actually fails for me too, but I'm able to print.
> > 
> > [SKY]If I use this following one, nslookup, printer..etc works.
> 
> IMO it is because of behavior described here
> https://serverfault.com/questions/607908/dig-nslookup-cant-resolve-local-
> hosts-unless-i-specify-the-local-dns-server .
> 
> Without resolved, nslookup looks for hostnames in name servers specified in
> /etc/resolv.conf, which are name servers on the WAN, so it logically cannot
> find hostnames which are defined only on LAN.
> 
> But once you enable resolved+nm, nslookup sees only IP which corresponds
> with local systemd-resolved instance, so the query goes to systemd-resolved.
> And systemd-resolved handles queries for local and wide known hostnames, so
> then it is able to provide an answer.
> 
> Regardless, whether nslookup works or not doesn't influence printing at all,
> so testing nslookup regarding printing is bogus.
> 
> > > MulticastDNS='no' is a default for resolved, so I guess you forgot to revert
> > > it before you did the testing. The same with nm changes.
> > > 
> > > So the issue is that %posttrans script didn't work for you.
> > 
> > [SKY] I was following the redhat documentation "do not edit
> > /etc/nsswitch.conf" file manually and just do "authselect apply-changes" only
> > 
> 
> As I wrote before, the doc thinks you have /etc/nsswitch.conf as a symlink
> and the whole manual is based on it. If you don't have /etc/nsswitch.conf as
> a symlink, 'authselect apply-changes' does nothing and you need to manually
> change /etc/nsswitch.conf or apply your changes from /etc/nsswitch.conf to
> /etc/authselect/user-nsswitch.conf, remove /etc/nsswitch.conf, create
> symlink /etc/nsswitch.conf->/etc/authselect/user-nsswitch.conf and use
> 'authselect apply-changes'.

(In reply to Sathiyamoorthy Kothandan from comment #15)
> [SKY] There is no /etc/authselect/nsswitch.conf file
> 
> [root@toshiba SKY]# ls -l /etc/nsswitch.conf /etc/authselect/nsswitch.conf
> ls: cannot access '/etc/authselect/nsswitch.conf': No such file or directory
> -rw-r--r-- 1 root root 2242 Jun  5 22:54 /etc/nsswitch.conf
> 
> [root@toshiba SKY]# ls -l /etc/authselect/*nsswitch.conf
> -rw-r--r-- 1 root root 1789 May 26 21:40 /etc/authselect/user-nsswitch.conf
> [root@toshiba SKY]# 
> 
> 

The default F34 image:

[root@fedora ~]# ls -lah /etc/nsswitch.conf
lrwxrwxrwx. 1 root root 29 Apr 27 11:07 /etc/nsswitch.conf -> /etc/authselect/nsswitch.conf

[root@fedora ~]# dnf repoquery --whatprovides /etc/authselect/nsswitch.conf
authselect-libs-0:1.2.3-1.fc34.i686
authselect-libs-0:1.2.3-1.fc34.x86_64

Then you maybe removed the file. Because if you haven't installed authselect-libs, then you shouldn't have authselect at all.

P.S. You can delete the rest of message, if you respond only a part of previous message.

(In reply to Zdenek Dohnal from comment #16)
> (In reply to Sathiyamoorthy Kothandan from comment #15)
> > [SKY] There is no /etc/authselect/nsswitch.conf file
> > 
> > [root@toshiba SKY]# ls -l /etc/nsswitch.conf /etc/authselect/nsswitch.conf
> > ls: cannot access '/etc/authselect/nsswitch.conf': No such file or directory
> > -rw-r--r-- 1 root root 2242 Jun  5 22:54 /etc/nsswitch.conf
> > 
> > [root@toshiba SKY]# ls -l /etc/authselect/*nsswitch.conf
> > -rw-r--r-- 1 root root 1789 May 26 21:40 /etc/authselect/user-nsswitch.conf
> > [root@toshiba SKY]# 
> > 
> > 
> 
> The default F34 image:
> 
> [root@fedora ~]# ls -lah /etc/nsswitch.conf
> lrwxrwxrwx. 1 root root 29 Apr 27 11:07 /etc/nsswitch.conf ->
> /etc/authselect/nsswitch.conf
> 
> [root@fedora ~]# dnf repoquery --whatprovides /etc/authselect/nsswitch.conf
> authselect-libs-0:1.2.3-1.fc34.i686
> authselect-libs-0:1.2.3-1.fc34.x86_64
> 
> Then you maybe removed the file. Because if you haven't installed
> authselect-libs, then you shouldn't have authselect at all.
> 
> P.S. You can delete the rest of message, if you respond only a part of
> previous message.

[SKY] historically nsswitch.conf file resides in /etc directory, not sure which version of fedora moved to location from /etc to /etc/authselect and /etc/nsswitch.conf symlinks to /etc/authselect/nsswitch.conf file. In any case whether nsswitch.conf is in /etc or in /etc/authselect directory, "hosts:      files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns" info in /etc/nsswitch.conf should have correct info just like one exists in /etc/authselect/user-nsswitch.conf

> Then you maybe removed the file. Because if you haven't installed
> authselect-libs, then you shouldn't have authselect at all.

Fedora 34 has authselect-libs installed but it doesn't have /etc/authselect/nsswitch.conf file. The question in why it is not installed /etc/authselect/nsswitch.conf file becuase there is one already in /etc/nsswitch.conf?

[root@toshiba SKY]# rpm -q authselect-libs
authselect-libs-1.2.3-1.fc34.x86_64

I have reinstalled authselect-libs which doesn't install /etc/authselect/nsswitch.conf file either, see below.

[root@toshiba SKY]# dnf reinstall authselect-libs
Last metadata expiration check: 0:45:04 ago on Mon 07 Jun 2021 10:03:07 AM EDT.
Dependencies resolved.
================================================================================================================================
 Package                            Architecture              Version                           Repository                 Size
================================================================================================================================
Reinstalling:
 authselect-libs                    x86_64                    1.2.3-1.fc34                      fedora                    223 k

Transaction Summary
================================================================================================================================

Total download size: 223 k
Installed size: 884 k
Is this ok [y/N]: y
Downloading Packages:
authselect-libs-1.2.3-1.fc34.x86_64.rpm                                                         657 kB/s | 223 kB     00:00    
--------------------------------------------------------------------------------------------------------------------------------
Total                                                                                           412 kB/s | 223 kB     00:00     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                        1/1 
  Running scriptlet: authselect-libs-1.2.3-1.fc34.x86_64                                                                    1/2 
  Reinstalling     : authselect-libs-1.2.3-1.fc34.x86_64                                                                    1/2 
  Cleanup          : authselect-libs-1.2.3-1.fc34.x86_64                                                                    2/2 
  Running scriptlet: authselect-libs-1.2.3-1.fc34.x86_64                                                                    2/2 
  Verifying        : authselect-libs-1.2.3-1.fc34.x86_64                                                                    1/2 
  Verifying        : authselect-libs-1.2.3-1.fc34.x86_64                                                                    2/2 

Reinstalled:
  authselect-libs-1.2.3-1.fc34.x86_64                                                                                           

Complete!
[root@toshiba SKY]# rpm -q authselect-libs
authselect-libs-1.2.3-1.fc34.x86_64

[root@toshiba SKY]# ls -l /etc/authselect/
total 12
drwxr-xr-x. 2 root root 4096 Mar 31 07:36 custom
-rw-r--r--  1 root root 1789 May 26 21:40 user-nsswitch.conf
-rw-r--r--  1 root root 1789 May 26 21:21 user-nsswitch.conf.bak
[root@toshiba SKY]#

In your 2021-05-31 06:42:54 UTC reply, not mentioned anything about /etc/authselect/nsswitch.conf? what happend here?

>And would you mind pasting 'hosts:' lines from your /etc/nsswitch.conf and /etc/authselect/user-nsswitch.conf files?

(In reply to Zdenek Dohnal from comment #11)
> reassigning to nss-mdns and to Zbyszek, who updated the sed-fu
> last time.

Interesting, bugzilla cleared assignee box to a default assignee, I'll update it.

(In reply to Sathiyamoorthy Kothandan from comment #19)
> [root@toshiba SKY]# ls -l /etc/authselect/
> total 12
> drwxr-xr-x. 2 root root 4096 Mar 31 07:36 custom
> -rw-r--r--  1 root root 1789 May 26 21:40 user-nsswitch.conf
> -rw-r--r--  1 root root 1789 May 26 21:21 user-nsswitch.conf.bak
> [root@toshiba SKY]#

I'm sorry, then I don't know - please file a new bug against authselect.

(In reply to Sathiyamoorthy Kothandan from comment #20)
> In your 2021-05-31 06:42:54 UTC reply, not mentioned anything about
> /etc/authselect/nsswitch.conf? what happend here?
> 

I didn't ask for /etc/authselect/nsswitch.conf because nss-mdns scriptlet doesn't change that file directly.
On the top of that - if /etc/nsswitch.conf is a symlink, it has the same contents as /etc/authselect/nsswitch.conf and it contains the data from /etc/authselect/user-nsswitch.conf. If /etc/nsswitch.conf isn't a symlink, then the /etc/nsswitch.conf file is the one which is used.

So in both cases /etc/authselect/nsswitch.conf wasn't needed to provide here in the ticket.

(In reply to Zdenek Dohnal from comment #22)
> (In reply to Sathiyamoorthy Kothandan from comment #19)
> > [root@toshiba SKY]# ls -l /etc/authselect/
> > total 12
> > drwxr-xr-x. 2 root root 4096 Mar 31 07:36 custom
> > -rw-r--r--  1 root root 1789 May 26 21:40 user-nsswitch.conf
> > -rw-r--r--  1 root root 1789 May 26 21:21 user-nsswitch.conf.bak
> > [root@toshiba SKY]#
> 
> I'm sorry, then I don't know - please file a new bug against authselect.

[SKY] new bug against authselect as per above info - 1969421

> 
> (In reply to Sathiyamoorthy Kothandan from comment #20)
> > In your 2021-05-31 06:42:54 UTC reply, not mentioned anything about
> > /etc/authselect/nsswitch.conf? what happend here?
> > 
> 
> I didn't ask for /etc/authselect/nsswitch.conf because nss-mdns scriptlet
> doesn't change that file directly.
> On the top of that - if /etc/nsswitch.conf is a symlink, it has the same
> contents as /etc/authselect/nsswitch.conf and it contains the data from
> /etc/authselect/user-nsswitch.conf. If /etc/nsswitch.conf isn't a symlink,
> then the /etc/nsswitch.conf file is the one which is used.
> 
> So in both cases /etc/authselect/nsswitch.conf wasn't needed to provide here
> in the ticket.

/etc/authselect/nsswitch.conf is not an installed file, it is a generated file that is generated by "authselect select" command. Authselect is the preferred way of configuring identity and authentication sources since F28. If the file does not exist, it simply means that authselect was never used to create the configuration.

Either run "authselect select sssd --force" to switch to authselect or update /etc/nsswitch.conf with the suggestions form mdns maintainer.

Since mdns should update both /etc/nsswitch.conf and /etc/authselect/user-nsswitch.conf from the scriptlet, but only the latter one is updated in this BZ then either something override the change (systemd?) or the scriptlet does not work correctly (perhaps it can't cope with resolve?).

Simple question why do have duplications nsswitch.conf all over ths system, if so why it is not maininted same every where? This reminds me of following famous proverb "can't have two swords into the same sheath?".

"Two swords cannot fit into the same sheath - A sheath is a protective cover for the sword and is designed for only one sword. Now, if someone tries to put two swords into the same sheath the second one will not go inside the cover in any way."

Unfortunately, this is required as long as users will be able to opt-out from authselect.

I have system which is from F27 (before authselect - identity and authentication) and been upgraded to F28...F33 & F34. It was working fine till F33, only after upgrade from F33 to F34 this issue started show up. In this use case it's not been tested itseems without authselect (identity and authentication).

This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07.

Fedora Linux 34 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release.

Thank you for reporting this bug and we are sorry it could not be fixed.