[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201026131254.GL534@brightrain.aerifal.cx>
Date: Mon, 26 Oct 2020 09:12:55 -0400
From: Rich Felker <dalias@...c.org>
To: Florian Weimer <fweimer@...hat.com>
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
On Mon, Oct 26, 2020 at 01:20:23PM +0100, Florian Weimer wrote:
> * Jesse Hathaway:
>
> > On Fri, Oct 23, 2020 at 8:29 AM Carlos O'Donell <carlos@...hat.com> wrote:
> >> My opinion is that we want something much thinner than nscd to provide
> >> NSS for statically linked applications, and that such an interface
> >> should not provide caching. If we really wanted we could keep the nscd
> >> socket interface but implement an NSS daemon for this e.g. nssd that would
> >> just run all the time and could be depended upon by static applications.
> >> It would have to be well audited and very simple.
> >>
> >> The caching that nscd does has many legacy problems that are better solved
> >> and maintained by other daemons that implement a split NSS module approach
> >> (as Florian notes).
> >
> > Given the increasing prevalence of statically deployed programs from
> > languages such as C, Go, Rust, and even Haskell. I would love to see
> > continued distribution support for querying NSS from these
> > programs. An nscd variant without caching seems like a good approach,
> > but I think it would be unfortunate to remove nscd from distributions
> > before an alternative approach was available.
>
> But Go and Haskell are really old by now, and nscd support hasn't landed
> in those language run-times (and their de-facto default
> implementations). After ten to thrity years of waiting, is it still
> reasonable to expect that this might happen.
>
> Even for C, there is no push to make nscd a mandatory installation
> requirement once the system uses services beyond the “dns” and “files”
> modules. I would have expected to see a development in this direction
> by now there as well. It's not just that we have turned down such
> requests, they did not even happen.
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. If it remains easy to add, having it not
installed by default is really not a big deal, but I kinda worry about
bitrot/breakage from suddenly having far fewer users.
> 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.
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.
> 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.
Rich
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.
