From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12931 invoked from network); 26 Oct 2020 12:20:48 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 26 Oct 2020 12:20:48 -0000 Received: (qmail 24528 invoked by uid 550); 26 Oct 2020 12:20:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 24510 invoked from network); 26 Oct 2020 12:20:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603714833; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LTJqaEOH8u3hTcoSwmbHfTspFSt7TX+AqA4BTr/qjrU=; b=E+6lIglHn0GLovwhf9Spq5KXzfrZFOwiVDFm4Wvv+iUzW+gzIsB7JPP3//2RpmLRn2rIkh 2qm52NUYDNNnERW8mv2hcgnjIxzi6LG8HCuQQFmn1y71jdQQA+kMwQH0LAHdDOcJKeU6GO Bs72mjE4aNOhC7GfFXmDOG4EA7nB8iQ= X-MC-Unique: smDJKbsyMWeWBb_HrZBYNg-1 From: Florian Weimer To: Jesse Hathaway Cc: musl@lists.openwall.com, Rich Felker , Arjun Shankar References: <1924902939.18027073.1603105167534.JavaMail.zimbra@redhat.com> <805098991.18032044.1603106011330.JavaMail.zimbra@redhat.com> <20201020010855.GE17637@brightrain.aerifal.cx> Date: Mon, 26 Oct 2020 13:20:23 +0100 In-Reply-To: (Jesse Hathaway's message of "Fri, 23 Oct 2020 09:14:01 -0500") Message-ID: <874kmhdvqw.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=fweimer@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Plans to remove nscd in Fedora * Jesse Hathaway: > On Fri, Oct 23, 2020 at 8:29 AM Carlos O'Donell 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 wou= ld >> 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 solv= ed >> and maintained by other daemons that implement a split NSS module approa= ch >> (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 =E2=80=9Cdns=E2=80=9D = and =E2=80=9Cfiles=E2=80=9D 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 --=20 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'N= eill