From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 856F41F910 for ; Sun, 20 Nov 2022 18:35:03 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=flokli.de header.i=@flokli.de header.b="ERAllCxQ"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 81D983858C30 for ; Sun, 20 Nov 2022 18:35:02 +0000 (GMT) Received: from mail.flokli.de (mail.flokli.de [116.203.226.116]) by sourceware.org (Postfix) with ESMTPS id 3B2FA3858D20; Sun, 20 Nov 2022 18:34:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3B2FA3858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=flokli.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=flokli.de Date: Sun, 20 Nov 2022 18:34:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=flokli.de; s=mail; t=1668969287; bh=ehSG0CC6ZpWHnx8eB7xq+uZpUtZB8gJ+9r0kyLHKr2s=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=ERAllCxQlNE+gzTZnIs8RpC8jDVpa6xPsOiziFqLzObkt1sQjxOWfz3h2fa5FsYji v7j5LCbgcg2lphoTTZaQfKyukgaHVdgx0y7QKbnWY5NWI1pX3Qi94/8i03+y6OyBLo dy4rteKdPd3kUKGFpGK8yIskzJl16SXokwVjgMqY= From: Florian Klink To: libc-alpha@sourceware.org Cc: ludo@gnu.org, felix@alternativebit.fr, John Ericson , Siddhesh Poyarekar Subject: Re: On the removal of nscd from Fedora, and the future of nscd. Message-ID: <20221120183443.7ox53zxaqanm37da@tp> References: <87h78fxigq.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" >>> NSCD certainly could act as that gateway, but I'd hate to rely on it >>> without an RFC defining the protocol, and such an RFC would enable it to >>> solve the problem in a wider context too. >>> > >Stepping back, we can ask: "What makes a de facto standard?" > >I would say a) stability and b) multiple implementations. > >> Yes. In practice, I haven?t seen nscd protocol changes in 10 years of >> Guix. > >That's one, and a quick search turned up: > >https://github.com/pikhq/musl-nscd > >whose read-me says: > >> musl-nscd is an implementation of the NSCD protocol. It makes use of NSS >> modules, just like with glibc. This permits alternative backends for the user >> and group databases for musl libc. The protocol it uses is a subset of that >> used by glibc. > >That's the other. Both criteria for "de facto standard" met! > >>> Doing so, however, means that nscd (or some other equivalent) MUST be >>> present and running on all systems... >>> >> Yes, exactly. > >If I may push back on this slightly, a libc could should ship with the sssd and >systemd-resolved clients too. For sake of argument, one could imagine they are >even statically linked, so there is no dlopen to be suspicious of. The binary could >try those protocols first before falling back on the nscd protocol. > >The goal here, I think, is to support the existing NSCD protocol as the "lingua >franca" we have *today*. It's not to hinder the uptake of anything else, or even a >value judgement on whether the NSCD protocol is "good" in any deep sense, >just acknowledging its what we've got. I recently took a closer look at the protocol, while adding host lookup support to [nsncd][nsncd-pr], so there's plenty of implementations of this protocol. [nsncd-blog] describes the reasons why Nix/GUIX needs this *as a pure request dispatcher* in a bit more detail, too. There's currently some scary request types to pass around FDs to internal nscd cache structures (GETFD*). But client code already falls back gracefully to querying records manually, if you don't actually hand over a FD. If there's plans to drop nscd from glibc codebase, what about keeping the client code, but simplified, without all client-side cache peeking? That way, Nix, GUIX and other peoples usecases would still keep working, while the amount of code in glibc on that can be reduced. Regards, flokli [nsncd-pr]: https://github.com/twosigma/nsncd/pull/49 [nsncd-blog]: https://flokli.de/posts/2022-11-18-nsncd/