Supporting sssd, preparing for nscd sunset

["Ludovic Courtès" <ludovic.courtes@inria.fr>]

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

So it sounds like we’ll have to do something about it.

In <https://lists.gnu.org/archive/html/guix-devel/2020-08/msg00168.html>
I showed a workaround in cases where you cannot install nscd on the
machine, but we’ll need something that works out of the box.

Fellow NixOS hackers have been developing an nscd replacement
(implementing the same protocol, just not caching lookups):

  https://alternativebit.fr/posts/nixos/nsncd-some-updates/

The solution would be interesting for use on Guix System if and when
nscd is removed from glibc, but I don’t see it helpful on other distros,
at least not until/unless it becomes widespread.  (We can’t really ship
ourselves because it has to be linked against the host libc.)

For the record, glibc maintainer Carlos O’Donell brought up our use case
a while back on the glibc mailing list but it wasn’t particularly well
received:

  https://sourceware.org/pipermail/libc-alpha/2022-February/136741.html

I’m not sure where to go from here.  Long-term we probably need to
ensure a (non-caching) nscd remains part of glibc, and that glibc’s
client stubs can still talk that protocol; or perhaps nsncd will
gradually replace nscd, which is fine too.  If sssd becomes dominant, we
might just as well arrange to have NSS always load libnss_sss.so.

Thoughts?

Ludo’.