mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Jesse Hathaway <jesse@mbuki-mvuki.org>
Cc: musl@lists.openwall.com,  Rich Felker <dalias@libc.org>,
	 Arjun Shankar <arjun@redhat.com>
Subject: Re: [musl] Plans to remove nscd in Fedora
Date: Mon, 26 Oct 2020 13:20:23 +0100	[thread overview]
Message-ID: <874kmhdvqw.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <CANSNSoXvHSN6fBo6oAdZzC7OFrrekAxSiFCY9XZ-tp5wTCTCJA@mail.gmail.com> (Jesse Hathaway's message of "Fri, 23 Oct 2020 09:14:01 -0500")

* Jesse Hathaway:

> On Fri, Oct 23, 2020 at 8:29 AM Carlos O'Donell <carlos@redhat.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.

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.

An added complication is that a model involving a separate daemon does
not work well for containers.

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


  parent reply	other threads:[~2020-10-26 12:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1924902939.18027073.1603105167534.JavaMail.zimbra@redhat.com>
2020-10-19 11:13 ` Arjun Shankar
2020-10-20  1:08   ` Rich Felker
2020-10-23 11:35     ` Florian Weimer
2020-10-23 12:01       ` Tim Tassonis
2020-10-23 12:09         ` Florian Weimer
2020-10-23 13:29     ` Carlos O'Donell
2020-10-23 13:37       ` Laurent Bercot
2020-10-23 14:14       ` Jesse Hathaway
2020-10-23 16:58         ` Rich Felker
2020-10-26 12:20         ` Florian Weimer [this message]
2020-10-26 13:12           ` Rich Felker
2020-11-02 13:54             ` Florian Weimer
2020-11-02 14:50               ` Rich Felker
2020-11-03  9:07                 ` Florian Weimer
2020-11-03 15:41                   ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874kmhdvqw.fsf@oldenburg2.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=arjun@redhat.com \
    --cc=dalias@libc.org \
    --cc=jesse@mbuki-mvuki.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).