|
Message-ID: <514e3157-f82b-8417-e748-16e9539ecacd@decentral.ch> Date: Fri, 23 Oct 2020 14:01:00 +0200 From: Tim Tassonis <stuff@...entral.ch> To: musl@...ts.openwall.com Subject: Re: Plans to remove nscd in Fedora On 10/23/20 1:35 PM, Florian Weimer wrote: > * Rich Felker: > >> The only capacity in which musl uses nscd is to access custom >> user/group backends provided through it. > > And that's the only way to get this data into musl programs. > >> musl specifically does not use nss itself because it's not compatible >> with static linking and because loading arbitrary module libraries >> into the calling process's core is not safe and goes against best >> practices. I believe the glibc folks were starting to realize this >> too, so it was kinda my hope that nscd would become the main/only way >> nss modules are accessed on glibc too. > > This requirement has largely been pushed into the NSS modules > themselves. If they do more than just opening a files or sockets, they > need to offload part of the functionality (actually most of it) into a > separate daemon. This is the difference between nss_ldap and nss_ldapd. > > SSSD has largely assumed this role for the non-hosts maps. It looks > like that systemd-resolved will cover the hosts maps. So it's unclear > what's left for nscd to handle. You might not know about this, but there is actually a world beyond Redhat/Fedora/Systemd. Not that I am advocating for nscd to remain, but I'm not sure this is the right list to place advertisement for your great RedHat products. Bye Tim
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.