Well.. maybe…
These could be systems that have seen continual upgrades across the Fedora 40 boundary…that didnt take the additional manual step to migrate to the local profile introduced in F40. To know for sure we’d have to have to see what the which profile the impacted systems are actually using.
Article Reference:
The relevant chage was done to the “sssd” profile in 2018
$ git log f7aee4dcf2163dacccb74ccf4314fa3cbec11c52~..f7aee4dcf2163dacccb74ccf4314fa3cbec11c52
commit f7aee4dcf2163dacccb74ccf4314fa3cbec11c52
Author: Pavel Březina <pbrezina@redhat.com>
Date: Fri Jul 13 10:53:28 2018 +0200
profiles: add systemd module to nsswitch
This module is needed to resolve dynamic systemd users and groups.
It is automatically enabled when installing systemd and we should
have it enabled in authselect profiles.
Resolves:
https://github.com/pbrezina/authselect/issues/64
For this issue, it doesn’t matter if the user is using the “local” profiles or the “sssd” profile. Both provides
passwd: sss files systemd
group: sss files systemd
Some feedback from my side.
I did create a custom authselect profile several years ago. It was a copy of the sssd profile as far as I can trace back. I have never realized that I should have kept an eye on changes of that sssd profile.
To be honest, I don’t remember why I created a custom profile. Today I switched to the standard sssd profile, so it won’t bite me again.
Hmm,
that tracks with my intution. This is a bit of a configuration drift corner case.
The question now is what can actually be done to mitigate this in the future. It feels like a pre-flight checklist item that a pre-flight script could warn about…at best.
I do not know who you are or why you bother helping lost people like me and the others in this thread, Jeff V, but I genuinely thank you for doing so!
Helping others solve problems is a rewarding passtime.