Re: Supporting sssd, preparing for nscd sunset

[Picnoir <picnoir@alternativebit.fr>]

Hey Guix, Ludovic,

Some context: Flokli (CCd) and I are fighting the same issue on the
NixOS side.

There's two aspects in this migration story:

1. the daemon-side. IE. how to make sure a daemon is available on most
   distros to respond to the nscd socket
2. the client-side. IE. how to make sure we'll still have access to the
   glibc stubs sending queries to the daemon socket on the foreseeable
   future.

Let's talk about the daemon side first. As I was mentionning in the blog
post linked above, NixOS moved to Nsncd, a non caching re-implementation
of Nscd.

> 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.)

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.

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.

Now, if you folks decide to part ways (sad), unscd[4] would likely be a
better starting point to implement a uncaching nscd daemon than the
current nscd implementation.

------

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.

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.

From the nscd protocol perspective, an IPv6 address is a serie of 16
octets. This is a fine representation for global and ULA addresses.
However, it's not good enough to fully qualify a link-local addresses:
you also need the scopeid (ie. interface id/interface name) that comes
with it .

This means that IPv6 local link-local addresses resolution is currently
broken for Guix/Nix programs. Such a resolution is sadly heavily used
in IPv6 mdns setups.

My point being: if we plan to keep using this nscd trick on the long run
(we currently do), and we end up doing a massive refactoring on the
Glibc side to hide the stubs, then it might be a good occasion to make
some improvements to the protocol itself at the same time. And who
knows, maybe we could make the bold move of redisiging altogether this
protocol.

For these protocol improvements, I definitely think our two communities
should sync and share notes.

Wow, that was long, sorry for the wall of text :)
Don't hesitate to Cc me and flokli for these Nscd discussions in the
future!

Picnoir

[1]: https://packages.debian.org/search?keywords=nsncd
[2]: https://aur.archlinux.org/packages/nsncd-git
[3]: https://gitlab.archlinux.org/archlinux/packaging/packages/glibc/-/blob/main/PKGBUILD?ref_type=heads#L53
[4]: https://github.com/bytedance/unscd
[5]: https://fosstodon.org/@codonell/111981707970893154