Proposed as a Blocker for 36-final by Fedora user chrismurphy using the blocker tracking app because:

 mDNS needs to work for IPP Everywhere printing to discover and setup printers
https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Printing

The PRs were merged, but it wasn't yet build.

Discussed during the 2022-02-28 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion:

"Printing must work in release-blocking desktops on at least one printer using...The generic IPP driver"

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-02-28/f36-blocker-review.2022-02-28-17.00.txt

Hi Adam, can you please rebuild nss-mdns package in F36 and rawhide? Thank you.

Yes I will do this tonight.

Building now:

https://koji.fedoraproject.org/koji/taskinfo?taskID=83535293
https://koji.fedoraproject.org/koji/taskinfo?taskID=83535291

FEDORA-2022-09f077aa3a has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-09f077aa3a

FEDORA-2022-09f077aa3a has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-09f077aa3a`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-09f077aa3a

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

After upgrading from f35 to f36, the nss-mdns module was not enabled in /etc/nsswitch.

It is difficult to tell why that is as long as the autselect calls in the post transaction script is redirecting stdout and stderr to /dev/null.

In theory, when running the post transaction script, the authselect package should already be fully installed and functional, even when the post transaction for authselect-libs is run after the post transaction for nss-mdns.

FEDORA-2022-09f077aa3a has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.

Can anyone confirm whether the update did the trick here? Is the bug fixed?

It is both fixed and broken.

It is fixed for F36 images which I installed in the past and then I upgraded to nss-mdns-0.15.1-5.fc36. It is also working for F35 upgrades:

[kparal@f35 ~]$ grep hosts /etc/nsswitch.conf
hosts:      files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

However, it is broken for F36 Workstation Live images, which were created with nss-mdns-0.15.1-5.fc36 already included [1]!

[kparal@f36 ~]$ grep hosts /etc/nsswitch.conf 
hosts:      files myhostname resolve [!UNAVAIL=return] dns

Reinstalling the same package fixes the problem:

[kparal@f36 ~]$ sudo dnf reinstall nss-mdns
...
Reinstalled:
  nss-mdns-0.15.1-5.fc36.x86_64                                                                                               

Complete!
[kparal@f36 ~]$ grep hosts /etc/nsswitch.conf 
hosts:      files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns


So, we need to figure out why Live composes are still broken.


[1] https://kojipkgs.fedoraproject.org/compose/branched/Fedora-36-20220328.n.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-36-20220328.n.0.iso

authselect works now correctly, nss-mdns now requires it so it first installs authselect, then calls authselect enable-feature which is correct.

I don't see nss-mdns being installed in the logs:
https://kojipkgs.fedoraproject.org/compose/branched/Fedora-36-20220328.n.0/logs/x86_64/buildinstall-Everything-logs/dnf.log

However, I don't know if this is correct log file or how to debug it further. This needs to be reported to whomever is responsible for the compose.

I think the logs for Fedora-Workstation-Live-x86_64-36-20220328.n.0 are here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=84830915

I don't know precisely how live media compose works, there might be two places that comes to my mind:
- kickstart allows you to call authselect and it is called from livecd-tools https://src.fedoraproject.org/rpms/livecd-tools/blob/rawhide/f/0001-switch-from-authconfig-to-authselect.patch
- anaconda calls authselect on installation

Perhaps one or the other is involved here?

I think it's more likely the latter. The former patch is about handling authconfig/select directives in kickstart files. The actual kickstarts we use for live image builds are here:

https://pagure.io/fedora-kickstarts

AFAICS, none of them have such lines, so I don't think that's relevant here. But yes, anaconda does have internal code for doing authselect stuff, and we log that it happens:

10:23:24,214 INF installation: Task started: Authselect configuration (15/37)
10:23:24,218 INF progress: Authselect configuration
10:23:24,218 DBG installation: Task completed: Authselect configuration (15/37) (0.0 s)

unfortunately, anaconda doesn't log what *happens* in any detail. This also wouldn't necessarily differ between creation of live images and regular installs, so it might be interesting to check how things are after an Everything or Server netinst/dvd install too.

Hm. Poking into this more, it looks like we're always going to log that task, but it doesn't necessarily do anything. By the looks of program.log, in this case, it didn't - it did not call authselect.

OK, so this breaks during live install, not live image generation. The live image itself has a correct hosts line, but a system installed from the live image does not.

From a quick look, I suspect the culprit is fingerprint authentication enablement:

journal.log:Mar 29 19:18:50 localhost-live org.fedoraproject.Anaconda.Modules.Security[2479]: DEBUG:anaconda.modules.security.installation:Enabling fingerprint authentication.
journal.log:Mar 29 19:18:50 localhost-live org.fedoraproject.Anaconda.Modules.Security[2479]: DEBUG:anaconda.modules.security.installation:Configuring authentication: /usr/bin/authselect ['select', 'sssd', 'with-fingerprint', 'with-silent-lastlog', '--force']
journal.log:Mar 29 19:18:50 localhost-live org.fedoraproject.Anaconda.Modules.Security[2479]: INFO:program:Running in chroot '/mnt/sysroot'... /usr/bin/authselect select sssd with-fingerprint with-silent-lastlog --force
journal.log:Mar 29 19:18:51 localhost-live org.fedoraproject.Anaconda.Modules.Security[2479]: INFO:program:Backup stored at /var/lib/authselect/backups/2022-03-29-23-18-50.dyBru6

And indeed:

[root@localhost-live tmp]# grep hosts /mnt/sysroot/var/lib/authselect/backups/2022-03-29-23-18-50.dyBru6/nsswitch.conf 
hosts:      files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

so, the fingerprint auth enablement code in anaconda:

https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/modules/security/installation.py#L415-L421

seems like it doesn't just enable a feature (like we do for nss_mdns), it rewrites the whole config. Maybe we should change it to do `authselect enable-feature with-fingerprint`?

Sounds good to me. Authselect installation now calls 'authselect select sssd with-silent-last-log --force' therefore Anaconda does not have to call it anymore and it can just enable fingerprint with enable-feature.

The suggested change in Anaconda is implemented in the following pull request: https://github.com/rhinstaller/anaconda/pull/3991

I see that Adam already reported bug 2069899 regarding anaconda, so I'm going to close this one.