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 18185 invoked from network); 2 Nov 2020 13:54:59 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 2 Nov 2020 13:54:59 -0000 Received: (qmail 24139 invoked by uid 550); 2 Nov 2020 13:54:57 -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 24112 invoked from network); 2 Nov 2020 13:54:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1604325285; 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: references:references; bh=+wtW6NPFA/+TJDfTwvrVBae38DuIg+wZAEsWIPawD6M=; b=UQmLRQDgXP97ymHQt/HjIg0Ohw8ux3IAVsHLxnAkrs7ik2qFaXIW//t6s2zFewEcLTfL6u 3rz4tWLJLYM1lQ2N7YNVua/9L6OrP/dzSw2xZVRaXPSsenjrPG4J7aTflWSdFXyESyetRX yy/LMs97cLvFWeHEAFliuAyrdatf0+8= X-MC-Unique: vLanlV5kOfO9_YKInheEuA-1 From: Florian Weimer To: Rich Felker Cc: Jesse Hathaway , musl@lists.openwall.com, Arjun Shankar , Carlos O'Donell References: <1924902939.18027073.1603105167534.JavaMail.zimbra@redhat.com> <805098991.18032044.1603106011330.JavaMail.zimbra@redhat.com> <20201020010855.GE17637@brightrain.aerifal.cx> <874kmhdvqw.fsf@oldenburg2.str.redhat.com> <20201026131254.GL534@brightrain.aerifal.cx> Date: Mon, 02 Nov 2020 14:54:31 +0100 Message-ID: <87zh3zg8yw.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.13 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 Subject: Re: [musl] 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): SUSE also recommends disabling parts of nscd: | - Modify /etc/nscd.conf | | enable-cache passwd no | enable-cache group no 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