Re: On the removal of nscd from Fedora, and the future of nscd.

[Florian Klink <flokli@flokli.de>]

>>> NSCD certainly could act as that gateway, but I'd hate to rely on it
>>> without an RFC defining the protocol, and such an RFC would enable it to
>>> solve the problem in a wider context too.
>>>
>
>Stepping back, we can ask: "What makes a de facto standard?"
>
>I would say a) stability and b) multiple implementations.
>
>> Yes.  In practice, I haven?t seen nscd protocol changes in 10 years of
>> Guix.
>
>That's one, and a quick search turned up:
>
>https://github.com/pikhq/musl-nscd
>
>whose read-me says:
>
>> musl-nscd is an implementation of the NSCD protocol. It makes use of NSS
>> modules, just like with glibc. This permits alternative backends for the user
>> and group databases for musl libc. The protocol it uses is a subset of that
>> used by glibc.
>
>That's the other. Both criteria for "de facto standard" met!
>
>>> Doing so, however, means that nscd (or some other equivalent) MUST be
>>> present and running on all systems...
>>>
>> Yes, exactly.
>
>If I may push back on this slightly, a libc could should ship with the sssd and
>systemd-resolved clients too. For sake of argument, one could imagine they are
>even statically linked, so there is no dlopen to be suspicious of. The binary could
>try those protocols first before falling back on the nscd protocol.
>
>The goal here, I think, is to support the existing NSCD protocol as the "lingua
>franca" we have *today*. It's not to hinder the uptake of anything else, or even a
>value judgement on whether the NSCD protocol is "good" in any deep sense,
>just acknowledging its what we've got.

I recently took a closer look at the protocol, while adding host lookup
support to [nsncd][nsncd-pr], so there's plenty of implementations of
this protocol.

[nsncd-blog] describes the reasons why Nix/GUIX needs this *as a pure
request dispatcher* in a bit more detail, too.

There's currently some scary request types to pass around FDs to
internal nscd cache structures (GETFD*). But client code already falls
back gracefully to querying records manually, if you don't actually hand
over a FD.

If there's plans to drop nscd from glibc codebase, what about keeping
the client code, but simplified, without all client-side cache peeking?

That way, Nix, GUIX and other peoples usecases would still keep working,
while the amount of code in glibc on that can be reduced.

Regards,
flokli

[nsncd-pr]: https://github.com/twosigma/nsncd/pull/49
[nsncd-blog]: https://flokli.de/posts/2022-11-18-nsncd/