Re: Supporting sssd, preparing for nscd sunset

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

Hi Picnoir!

Picnoir <picnoir@alternativebit.fr> skribis:

> Nsncd is already available in Debian[1] and Arch[2] (AUR). In reality,
> some dowstreams, like Arch, are not distributing nscd anymore[3].
> Meaning the only way to run Nix/Guix binaries on Arch without breaking
> PAM is to go through Nsncd at the moment.
>
> So, on the daemon side, on the long run, for us, the solution would be
> to package Nsncd to Ubuntu and Fedora. We'd love to share that effort
> with the Guix community.

Excellent; I just saw Adam’s reply, let’s hope the Fedora bit can be
sorted out soon enough.  (I was afraid use of Rust will make packaging
harder, but apparently it’s not been a roadblock so far.)

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

In terms of next actions for Guix, it means we can already update the
“Application Setup” section to recommend nsncd on platforms where nscd
is unavailable.

> Let's address the elephant in the room: Nsncd is written in Rust. I know
> that language is not the most loved among the Guix crowd due to its
> bootstrapping story. But looking at the amazing work Efraim put into the
> toolchain, I don't think this should be a show stopper for Guix. We're
> likely to get more Rust in core system parts in the future anyways.

Heheh.  Beyond preferences, most of us are also pragmatic at times :-).
If nsncd does the job, can be packaged without too much hassle, and can
be shared between Nix and Guix, then so be it!

> Client-side. There's two aspects to it:
>
> 1. keep the nscd stubs, hopefully without any patches in Glibc.
> 2. improve the current protocol.
>
> For the stubs, let's take the worst-case scenario for us: upstream
> decides to remove them. It seems like Carlos O'Donell[5] is up to
> provide some guidance and support into hiding them behind a feature flag
> and keep them in Glibc instead. So, even in our worst-case scenario, it
> seems like we'll be okay-ish. We'll still need to put some people-hours
> into it though.

Right.  We might need to resume the discussion on libc-alpha at some
point, to make sure our use case is known and understood.

> From my perspective, the current protocol is not entirely satisfactory.
> Implementing it in Nsncd was clearly no fun. But even besides this
> aspect, it's currently not good enough for IPv6.

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.

Thanks for your feedback!

Ludo’.