Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace nscd caching with systemd-resolved #51911

Closed
arianvp opened this issue Dec 12, 2018 · 8 comments
Closed

Replace nscd caching with systemd-resolved #51911

arianvp opened this issue Dec 12, 2018 · 8 comments

Comments

@arianvp
Copy link
Member

arianvp commented Dec 12, 2018

Feature description

We now use nscd caching only for host lookups since #50316 was merged. However, we would want to get rid of any mentions of nscd caching as manual
cach invalidation is error prone. We can use systemd-resolved, which is already loaded by default as an nss_module to do Host lookup caching for us instead, automatically invalidating based on /etc/resolv.conf and the TTLs given by the DNS records.

Once this is done, we can get rid of a lot of places in NixOS where we manually invalidate nscd caches, as nscd is then not used for caching anymore, but purely for delegating nss requests to the appropriate nss_module

@arianvp arianvp mentioned this issue Dec 12, 2018
9 tasks
@flokli
Copy link
Contributor

flokli commented Dec 12, 2018

I basically agree - just want to add that there of course other nss modules providing hosts, passwd etc too, so a dive into the priorities there shouldn't hurt :-)

@arianvp
Copy link
Member Author

arianvp commented Dec 12, 2018

That is already supported. You can add nss modules as you please by modifying the nssModules nixos option. For examples sssd is loaded when sssd is enabled.

@flokli
Copy link
Contributor

flokli commented Dec 14, 2018

Sure, what I meant was the /order/ of the nss modules being queried.

@andir
Copy link
Member

andir commented May 28, 2019

Would using systemd-resolved for all the host caching also imply that we use it for all DNS queries that leave the host? If so, I do not think it is a viable option. It should still be possible for someone to use a local (recursive) resolver that isn't systemd-resolved

@flokli
Copy link
Contributor

flokli commented May 17, 2020

These days, nscd doesn't cache most things anymore, it just acts as a proxy to expose nss modules system-wide.
The only thing that's still cached by it is hosts (and only in the positive case).
We do much less manual invalidation (only in update-users-groups.pl and in nixos/modules/config/resolvconf.nix).

The PRs mentioned in #86350 made the configuration and order of NSS modules much cleaner.

In case people enable systemd-resolved, we set resolve [!UNAVAIL=return] - otherwise, it's just hosts: files mymachines dns myhostname.

IMHO, by now, we could just disable the positive hosts caching too:

  • systems with systemd-resolved will get caching via it
  • systems without it, but another local resolver configured (likely via the dns module and a matching /etc/resolv.conf) will use its local cache
  • users without resolved and without their own custom local resolver and without any custom config will use whatever dns server the DHCP server told them to use - which is the same behaviour as on non-networkd distros.

@arianvp could you file a PR disabling the remaining caching in nscd? Then, we could also remove the invalidation in nixos/modules/config/resolvconf.nix. I'd keep the one in update-users-groups.pl, as another safety net against users who did enable user/group caching.

@xaverdh
Copy link
Contributor

xaverdh commented Jul 9, 2020

Can this be closed, now that #89274 was merged?

@arianvp
Copy link
Member Author

arianvp commented Jul 9, 2020

I think so yes. @flokli ?

@flokli
Copy link
Contributor

flokli commented Jul 11, 2020

👍

@flokli flokli closed this as completed Jul 11, 2020
@JohnRTitor JohnRTitor moved this to Done in systemd Jun 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

4 participants