Re: Supporting sssd, preparing for nscd sunset

[Picnoir <picnoir@alternativebit.fr>]

Hi Ludo, Guix,

> Can you confirm nsncd can load and run popular NSS plugins like
> nss-mdns and sss?

Nss-mdns works fine on IPv4. It won't work on IPv6 link-local addresses,
but that's due to the Nscd protocol issue I was talking about in the
previous email.

I did not test sss but I'd assume it to be working. Maybe Flokli did
test that?

The only known regression we're aware of is related to the Google
OSLogin PAM module, a module used by gcloud guests to retrieve the user
account accounts metadata. See
https://github.com/NixOS/nixpkgs/issues/218813. I **think** it comes
from the fact we're not "crasing" Nsncd properly when a PAM module is
segfaulting. I personally do not use google cloud, so I confess I did
dig too deep into that issue.

Aside from that, we're not aware of any other regressions. We migrated
from Nscd to Nsncd 2 NixOS stable versions ago, meaning Nsncd has been
already quite battletested in the wild by now.

> One option that could also be considered, instead of changing the nscd
> protocol, would be to have the glibc client stubs implement the sssd
> protocol directly, given that sssd seems to have taken the role of
> nscd-without-caching.
>
> It’s certainly more work but a possibility to keep in mind while
> discussing with upstream.

I had a look at the sssd protocol, it seems to be string-based, which
from my perspective is a better approach than the Nscd one. The protocol
also properly supports IPv6 link-local addresses scope ids.

As you said, it's quite some effort. I personally can't commit doing
such a re-implementation in the near future.

+1 about sending a summary to the glibc ML.

Picnoir