Description of problem: On update to authselect 1.0-1 packages on a system which had previously had 'authselect select sssd with-sudo' run after a FreeIPA client install, the following errors occur: Running scriptlet: authselect-libs-1.0-1.fc28.x86_64 118/118 [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. Unable to enable feature [17]: File exists Version-Release number of selected component (if applicable): authselect-1.0-1.fc28.x86_64 authselect-libs-1.0-1.fc28.x86_64 How reproducible: 100% (3 for 3 FreeIPA clients thus far) Steps to Reproduce: 1. Update to authselect-1.0-1 Actual results: authselect abandons /etc/nsswitch.conf Expected results: authselect updates its own nsswitch.conf to fit its current expectations Additional info: ╶➤ cat /etc/nsswitch.conf # Generated by authselect on Tue Jul 3 01:39:04 2018 # Do not modify this file manually. passwd: sss files systemd group: sss files systemd netgroup: sss files automount: sss files services: sss files sudoers: files sss shadow: files ethers: files netmasks: files networks: files protocols: files rpc: files hosts: files dns myhostname aliases: files nisplus bootparams: nisplus [NOTFOUND=return] files publickey: nisplus
Can you please provide output of `ls -l /etc/nsswitch.conf` and `cat /etc/authselect/nsswitch.conf`?
Upstream ticket: https://github.com/pbrezina/authselect/issues/80
╶➤ ls -l /etc/nsswitch.conf* /etc/authselect/nsswitch.conf -rw-r--r--. 1 root root 456 Jul 3 01:39 /etc/authselect/nsswitch.conf -rw-r--r--. 1 root root 474 Jul 22 15:18 /etc/nsswitch.conf -rw-r--r--. 1 root root 456 Jul 22 15:18 /etc/nsswitch.conf.bak -rw-r--r--. 1 root root 1548 Jul 3 01:31 /etc/nsswitch.conf.ipabkp ╶➤ cat /etc/authselect/nsswitch.conf # Generated by authselect on Tue Jul 3 01:39:04 2018 # Do not modify this file manually. passwd: sss files group: sss files netgroup: sss files automount: sss files services: sss files sudoers: files sss shadow: files ethers: files netmasks: files networks: files protocols: files rpc: files hosts: files dns myhostname aliases: files nisplus bootparams: nisplus [NOTFOUND=return] files publickey: nisplus ╶➤ diff -u /etc/authselect/nsswitch.conf /etc/nsswitch.conf --- /etc/authselect/nsswitch.conf 2018-07-03 01:39:04.688011070 -0400 +++ /etc/nsswitch.conf 2018-07-22 15:18:56.016211530 -0400 @@ -1,8 +1,8 @@ # Generated by authselect on Tue Jul 3 01:39:04 2018 # Do not modify this file manually. -passwd: sss files -group: sss files +passwd: sss files systemd +group: sss files systemd netgroup: sss files automount: sss files services: sss files Looks like whatever script(let) tried to repair systemd user enumeration broke the link? I can confirm that four machines installed prior to August have the same problem, and a recently installed VM doesn't. Per the upstream ticket... It's not at all clear how suppressing error output fixes this.
During the upgrade, authselect detected that existing configuration was not created by authselect and it correctly refused to apply any changes. This can be seen from timestamps as the original authselect configuration was created Jul 3 but /etc/nsswitch.conf was created outside authselect on Jul 22. Maybe systemd module added itself there. Therefore the problem from authselect side is that it printed an error during the upgrade instead of being silent.
authselect-1.0-3.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-502563d217
authselect-1.0-3.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-502563d217
So, by that reasoning, authselect omitting critical configuration from and subsequently losing control over its sole raison d'être is "correct", and the solution is to silently abandon the mess it's created? I don't think this qualifies as a fix.
> -rw-r--r--. 1 root root 456 Jul 3 01:39 /etc/authselect/nsswitch.conf > -rw-r--r--. 1 root root 474 Jul 22 15:18 /etc/nsswitch.conf > -rw-r--r--. 1 root root 456 Jul 22 15:18 /etc/nsswitch.conf.bak Something deleted the link, write into /etc/nsswitch.conf and created /etc/nsswitch.conf.bak. My guess is that it was systemd that wanted to enable systemd module for passwd and group which was previously missing in authselect. Authselect will not modify existing user configuration that was modified without authselect, so user changes are not overwritten without his/her knowledge. Authselect did not broke the link, authselect did not create /etc/nsswitch.conf.bak, the upgrade process correctly refused to touch configuration it does not know. We will provide a way for packages to use authselect for nsswitch modification [1] so this problem will be avoided in future. However this is in F30 scope as it will be a system wide change. [1] https://github.com/pbrezina/authselect/issues/77
Please, provide contents of /etc/nsswitch.conf and /etc/nsswitch.conf.bak so we can confirm it was the systemd module. I will then check with systemd developers about the options how to modify nsswitch.conf without breaking authselect configuration.
authselect-1.0-3.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Pavel Březina from comment #8) > Something deleted the link, write into /etc/nsswitch.conf and created > /etc/nsswitch.conf.bak. My guess is that it was systemd ... FYI: nss-mdns scriptlets also munge /etc/nsswitch.conf and create /etc/nsswitch.conf.bak .
Both the original nsswitch.conf and the .bak version from this system on July 22 were already posted; the /etc/authselect/nsswitch.conf and /etc/nsswitch.conf.bak were identical in content. It's also already known that the systemd package did it, but here's further proof: 2018-07-22T19:18:56Z INFO Upgraded: systemd-libs-238-9.git0e0aa59.fc28.x86_64 2018-07-22T19:19:05Z INFO Upgraded: systemd-pam-238-9.git0e0aa59.fc28.x86_64 2018-07-22T19:19:07Z INFO Upgraded: systemd-238-9.git0e0aa59.fc28.x86_64 2018-07-22T19:19:07Z INFO Upgraded: systemd-udev-238-9.git0e0aa59.fc28.x86_64 That's all rather beside the point, though. systemd, nss-mdns, and undoubtedly numerous other packages modify /etc/nsswitch.conf directly. authselect shipping without any of this included in its profiles (thus provoking the modifications), without any cooperative method for other packages to make these changes, and without any steps taken to modify these packages prior to shipping authselect in the distribution is a regression. Following that up by refusing to accept any responsibility for the mess, especially silently, is abysmal behavior. If fixing these mistakes isn't in scope prior to Fedora 30, why is authselect still shipping in F28/F29?
YOU SEE WHAT HAPPENS WHEN YOU REFUSE TO FIX A PROBLEM PROPERLY IN FEDORA? IT ENDS UP IN YOUR "Enterprise" OS, EL8: [error] [/etc/authselect/password-auth] has unexpected content! [error] Unexpected changes to the configuration were detected. [error] Refusing to activate profile unless those changes are removed or overwrite is requested. I very much doubt /etc/authselect/password-auth has been modified by *ANYTHING* besides authselect, as it doesn't look like something systemd would bother with. Just ridiculous.