From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id CJhLN1Tq5mXzVwEAqHPOHw:P1 (envelope-from ) for ; Tue, 05 Mar 2024 10:48:05 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id CJhLN1Tq5mXzVwEAqHPOHw (envelope-from ) for ; Tue, 05 Mar 2024 10:48:05 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=inria.fr header.s=dc header.b=rZzVePnZ; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=inria.fr ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1709632084; h=from:from:sender:sender: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:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=SexE89jfHIRR2RzBxbRV1mep1HV47zhuOF8l+cpNYAU=; b=bXj9a665wN+erVP0Q14uYrC4WjuD4mlR5CUjCmLkwLCMTOY1Fe4XmKFFNwnQ0N6TS/V4Vw HOWQYDywJZV3/4JtbYvKUzra3sIN7w13/ahfUpiWMb+0t+Q48TmitK5l74ITwLkVOAQRBN TFA65dExLDjMb8m1FOKuSntCoVf05ZG6ZeBgDDL6gV19TGAaO6TUzQr/pQRUWlEtCsWRw1 +sHzaw4sjkaSpIuq7ums9Pp140SZe+Z0lTblRFl+hNG2R6Uf4XC4UPagTyX0cVlE/38cmI LNXUUee/qws08w6tu3ZVnJtG4E0CUWye0U1R6Isks3mqufcJTR8Q9FvxnCwjRQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=inria.fr header.s=dc header.b=rZzVePnZ; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=inria.fr ARC-Seal: i=1; s=key1; d=yhetil.org; t=1709632084; a=rsa-sha256; cv=none; b=pKEUtMXvXvOStQ//+SxlwXFczpFiy7UrQfYeKEbrMqamgzix4ffhKKrcImqFk112TWuAkP ICUIYixfmfe1cLsyGOc4muyImL/m4LFXoklhoDn1smWP3YW3Gfn9qk2pgEjs6tGWSqrmLO Aa2Gz9bNtOlcl7QkytpdGrJwAc+tTJMlkWL8StqX/P8vbWgmtj+1XUwS0yPjIcwBWRRL/0 +/8I/VeCm3+m7Y/TcC8maiXFliAsrx/3MsHnVtQz5m/L6n1PvVOt6AZWk/noIvoyCSaGK8 +1Q3Ke/ReDEoZqHjiEVrnJu4+krArlwVYkhmrVnGVQZF8uq+n3/AeyqXvC0cvg== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id BF7DE1FD96 for ; Tue, 5 Mar 2024 10:48:04 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rhROT-0006a6-Rp; Tue, 05 Mar 2024 04:47:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rhRO0-0006Us-PN for guix-devel@gnu.org; Tue, 05 Mar 2024 04:47:11 -0500 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rhRNy-0003yx-2l for guix-devel@gnu.org; Tue, 05 Mar 2024 04:47:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=SexE89jfHIRR2RzBxbRV1mep1HV47zhuOF8l+cpNYAU=; b=rZzVePnZovgheenIZvGABOhg1nn7jsgQ1xPwQJW0oA98mH4n/I12gNif T1Agr8YXFHHj62qru3lk0r1nD3pLsnx8MKqG1xjSkzCcRkPhOnSsrF11Z 50kK/HQdMCBnIDpq2FZc9Nn1rBp3Tgq2p7liM8IveMkEk/BIdOpmuEca8 Y=; X-IronPort-AV: E=Sophos;i="6.06,205,1705359600"; d="scan'208";a="81309915" Received: from unknown (HELO ribbon) ([193.50.110.89]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Mar 2024 10:46:54 +0100 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Picnoir Cc: guix-devel@gnu.org, flokli@flokli.de Subject: Re: Supporting sssd, preparing for nscd sunset In-Reply-To: <8734tie09a.fsf@alternativebit.fr> (picnoir@alternativebit.fr's message of "Sat, 24 Feb 2024 09:26:25 +0100") References: <87sf1jh8gq.fsf@inria.fr> <8734tie09a.fsf@alternativebit.fr> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Sextidi 16 =?utf-8?Q?Vent=C3=B4se?= an 232 de la =?utf-8?Q?R=C3=A9volution=2C?= jour de =?utf-8?Q?l'=C3=89pinard?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Tue, 05 Mar 2024 10:46:53 +0100 Message-ID: <874jdldn8y.fsf@inria.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=192.134.164.104; envelope-from=ludovic.courtes@inria.fr; helo=mail3-relais-sop.national.inria.fr X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -10.76 X-Spam-Score: -10.76 X-Migadu-Queue-Id: BF7DE1FD96 X-TUID: 4SPVBlE+uqoZ Hi Picnoir! Picnoir skribis: > Nsncd is already available in Debian[1] and Arch[2] (AUR). In reality, > some dowstreams, like Arch, are not distributing nscd anymore[3]. > Meaning the only way to run Nix/Guix binaries on Arch without breaking > PAM is to go through Nsncd at the moment. > > So, on the daemon side, on the long run, for us, the solution would be > to package Nsncd to Ubuntu and Fedora. We'd love to share that effort > with the Guix community. Excellent; I just saw Adam=E2=80=99s reply, let=E2=80=99s hope the Fedora b= it can be sorted out soon enough. (I was afraid use of Rust will make packaging harder, but apparently it=E2=80=99s not been a roadblock so far.) Can you confirm nsncd can load and run popular NSS plugins like nss-mdns and sss? In terms of next actions for Guix, it means we can already update the =E2=80=9CApplication Setup=E2=80=9D section to recommend nsncd on platforms= where nscd is unavailable. > Let's address the elephant in the room: Nsncd is written in Rust. I know > that language is not the most loved among the Guix crowd due to its > bootstrapping story. But looking at the amazing work Efraim put into the > toolchain, I don't think this should be a show stopper for Guix. We're > likely to get more Rust in core system parts in the future anyways. Heheh. Beyond preferences, most of us are also pragmatic at times :-). If nsncd does the job, can be packaged without too much hassle, and can be shared between Nix and Guix, then so be it! > Client-side. There's two aspects to it: > > 1. keep the nscd stubs, hopefully without any patches in Glibc. > 2. improve the current protocol. > > For the stubs, let's take the worst-case scenario for us: upstream > decides to remove them. It seems like Carlos O'Donell[5] is up to > provide some guidance and support into hiding them behind a feature flag > and keep them in Glibc instead. So, even in our worst-case scenario, it > seems like we'll be okay-ish. We'll still need to put some people-hours > into it though. Right. We might need to resume the discussion on libc-alpha at some point, to make sure our use case is known and understood. > From my perspective, the current protocol is not entirely satisfactory. > Implementing it in Nsncd was clearly no fun. But even besides this > aspect, it's currently not good enough for IPv6. One option that could also be considered, instead of changing the nscd protocol, would be to have the glibc client stubs implement the sssd protocol directly, given that sssd seems to have taken the role of nscd-without-caching. It=E2=80=99s certainly more work but a possibility to keep in mind while discussing with upstream. Thanks for your feedback! Ludo=E2=80=99.