[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Supporting sssd, preparing for nscd sunset
From: |
Ludovic Courtès |
Subject: |
Re: Supporting sssd, preparing for nscd sunset |
Date: |
Tue, 05 Mar 2024 10:55:25 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Hi,
Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
> Ludovic Courtès <ludovic.courtes@inria.fr> writes:
>
>> Hello Guix!
>>
>> Distros are increasingly relying on sssd, in particular Fedora and
>> derivatives, as a replacement for nscd, which is either unavailable or
>> deprecated. The documented interface of Guix binaries to the host’s
>> name service switch (NSS) is currently nscd:
>>
>>
>> https://guix.gnu.org/manual/en/html_node/Application-Setup.html#Name-Service-Switch
>>
>> If sssd becomes dominant, we
>> might just as well arrange to have NSS always load libnss_sss.so.
>>
>> Thoughts?
>
> With nscd removed from glibc, can't we assume foreign distributions will
> rely on sssd instead? Do I understand correctly that the above
> (configuring NSS to always load libnss_sss.so) would be a fine
> replacement for our use of nscd? If so, that seems the simplest/best
> option to pursue to me.
It depends on what we mean by “configuring NSS to always load
libnss_sss.so”.
We could change the default NSS config, the one that’s used when
/etc/nsswitch.conf is missing, but that won’t help because in practice
distros do ship that file.
So what we would need to do is hack the NSS such that, when it sees
“nss_sss”, it kinda expands it to
/gnu/store/…-sssd-1.2.3/lib/libnss_sss.so.
That would complicate bootstrapping (as in: building ‘glibc-final’), but
may be worth considering.
Ludo’.