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
