Control: tags 1148069 - patch
On Sat, 26 Sep 2026 13:02:27 +0000 Mike Gabriel <[email protected]>
wrote:
People start asking about when sssd is fixed (because autofs is also
impacted by sssd not being in testing).
For the background story and how this all is related:
* autofs is not in testing, because sssd is not in testing
* sssd is not in testing because of #1129522
* to get sssd fixed (#1129522) it needs sudo bug #1147179 getting fixed
* to get the approach suggested in #1147179 fully functional dh-nss needs
love (#1148069)
* this also impact the Debian Edu 14 development, but this is not so
pressing at the moment, because we are still busy with fine-polishing
the Debian Edu 13 release
Hi, long story short: I improved the testsuite with quite a few tests
focused on upgrades and it turns out, as it always the case, that a
simple fix like the one proposed here does not properly cover all the
possible upgrade paths (for arbitrary changes to .nss files). Upgrades
are hard.
I'll try now a different strategy: making the maintscript snippets go
back to a clean state before each upgrade. On paper it works, but I'm
afraid it may cause intermittent issues because there will be a window
of time in which the service will not be enabled in /etc/nsswitch.conf.
In case of a failed upgrade that window may be arbitrarily long and if
that service is something needed to log in, the admin may end up locked
out of their accounts.
Another option, more in line with what sssd and autofs need at the
moment, would be to state something along the lines of ".nss files can
only be added to or removed from a package; changing the content of .nss
files between package versions is not allowed without additional ad-hoc
code in maintscripts".
Both options are unsatisfactory. Option 2 is perhaps the best to unblock
the current sssd situation.
I'll do some other testing and play with these two options during the
weekend, then release a version that will at least unblock sssd.
Ideas and comments are welcome!
--
Gioele Barabucci
