Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
nixos/nsswitch cleanup nss modules #87016
This moves the remaining NSS modules to their corresponding modules, and contains some follow-up fixes, where we missed adding to the
It also removes the conditional loading of systemd nss modules, as requested in #86940 (comment).
Motivation for this change
A disabled nscd breaks nss module loading on NixOS, and systemd without its nss modules doesn't really work either - instead of silently disabling its nss modules if nscd is disabled, let the assertion in nsswitch handle this.
The current error message is not very helpful, I still had to look at the source code, look up the commit and this PR to understand what is going on:
I'd suggest a more actionable error message:
(I guess that those who have already disabled nscd would rather keep it disabled and do not need this assertion at all. However, the new users might like to be warned when they disable nscd for the first time…)
@orivej the problem was that people disabling
Most code adding to nss modules only did this "optionally" when nscd was enabled (and by doing this, never triggering the assertion). However, there's a lot of places in NixOS where we rely on a functional NSS system, so alerting in these cases by actually triggering the assertion is preferrable.
The suggested error message isn't that clear either on what's preferred now. If we want to avoid people having to read the source, we probably need to be a bit more verbose. What about this?
Can you elaborate on usecases to disable nscd? When would one explicitly want to opt in to have broken NSS lookups?
I have disabled nscd because I do not want to erase the boundary between Linux network namespaces when it comes to DNS — otherwise the requests from nscd-aware applications originate from the nscd namespace rather than the application namespace. (Here are the relevant bits of my config: #52411 (comment).) I know that this disables some systemd-based name resolution and I'm OK with that since I never encounter such names.
I'd suggest this edit:
@orivej thanks for the pointer! That's an interesting usecase. I wonder if you could just make nscd unavailable from these namespaced units, via
I don't remember exactly how the breakages looked (need to check), but "systemd dynamic user lookup and container hostname resolution" are only examples on a basic installation - with disabled nscd, all custom nss modules will break.