[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87zh3zg8yw.fsf@oldenburg2.str.redhat.com>
Date: Mon, 02 Nov 2020 14:54:31 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Rich Felker <dalias@...c.org>
Cc: Jesse Hathaway <jesse@...ki-mvuki.org>, musl@...ts.openwall.com, Arjun
Shankar <arjun@...hat.com>, Carlos O'Donell <carlos@...hat.com>
Subject: Re: Plans to remove nscd in Fedora
* Rich Felker:
> It's not mandatory on glibc, but it's a widely deployed existing
> interface on most "big" systems, and it's easy to add with a quick
> apt-get or whatever on others if you find you need it for integration
> with non-glibc binaries.
This has not been true for quite a few years because using nscd along
with sssd for the same databases is not supported (sssd is where all the
domain integration work happens these days):
<https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/usingnscd-sssd>
SUSE also recommends disabling parts of nscd:
| - Modify /etc/nscd.conf
|
| enable-cache passwd no
| enable-cache group no
<https://www.suse.com/support/kb/doc/?id=000019039>
I think SUSE has largely switched to SSSD as well for the most recent
product releases, but I do not have much insight into their work
unfortunately.
> If it remains easy to add, having it not installed by default is
> really not a big deal,
(we have been in this situation for many, many years)
> but I kinda worry about bitrot/breakage from suddenly having far fewer
> users.
nscd is already very broken and has issues with workloads that trigger
many cache misses.
>> I suspect it's just that users that have large databases under /etc or
>> require on remote integration have little interest in static linking and
>> vice versa.
>
> It's not that they have interest in static linking. It's that
> providers of applications who want a binary that "runs anywhere" do.
In my world, they tend to either not integrate NSS at all (if they are
written in Go) or dynamically link against glibc 2.12 or even older.
> FWIW its presence would also let you fix the issue of lookups from
> (truely-, not mostly-) static-linked glibc programs not working right,
> just by goind to nscd first when it's present.
It would still require changes to nscd: support for all databases,
pass-through of uncached lookups that cannot be switched off (at present
caching cannot be controlled independently), and of course tons of bug
fixes.
>> An added complication is that a model involving a separate daemon does
>> not work well for containers.
>
> Sure it does. The daemon containerizes just like everything else.
> Whether the host outside the container is using nscd is irrelevant to
> the guest inside, and vice versa. Typically inside containers you
> *don't* want to integrate with big shared user identities somewhere
> outside, but you can if you want.
The problem are images which have just one application in them and lack
full init running as PID 1 in the container. For such images, you can't
simply add a configuration file that causes nscd to launch, you'd
actually have to patch the application to do that.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
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.
