From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id SHnZKHph2mXP8AAA62LTzQ:P1 (envelope-from ) for ; Sat, 24 Feb 2024 22:36:58 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id SHnZKHph2mXP8AAA62LTzQ (envelope-from ) for ; Sat, 24 Feb 2024 22:36:58 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=alternativebit.fr header.s=gm1 header.b=NCyFbtPO; dmarc=none; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1708810618; 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=FZ+6UbGMiq334izIfi7p2MgM5mVZ73T6GaLHA++260U=; b=knEIbeLB9gzwQPtUkjOTeCxdo1ptYiw3BnNwQ+hNrUxqiKOy28k099duxlT8NzNWh4GCnN aAMwg4Ok+rwqPzUi6VX2qK2zZAHr92i3HRLDDpJz2K30x33InqL1epAm55pve/2x7M5JoL mAobFUT1P9x846IueJ5Tv51CgivixhHPxfkGL86rR9oEf553w0gyVWV/gLeVoNdZdJSXBi P/utH9JabXuCNRGkI61/zzJgIRUgY1vlzeyePR6Rig0COt6XOho+ntkhQqBK7DMZjNdECX xrm8Qwag3aKAUFYXhuLqLR6TTcdRfvTmca/UC4zTEic0zAayYBDGmnhMyGLCLQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=alternativebit.fr header.s=gm1 header.b=NCyFbtPO; dmarc=none; 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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1708810618; a=rsa-sha256; cv=none; b=Vlw5zLoqwHCbUgmDjkib/tEe96HQRV+k4qjlywN3BmM/9nPCVS6uenWaLSKczF5HT/mE5v 3In5j94VPYDNe5evUxdX2/fl/AWZFQGj5giDf9VXfdA9wIZ+C8AU1R1M/HxSBTEm/vztC7 fdfC1qTL23+BkfyOpqtaaahuATqxIbv5K/qxjBCY6XFHb7oeOF9NyRR/sj2sqE/0SpcboY eOP1mnt+c207bErrVYl3fHpsRkZhyHgN4JRZGy3HJDW1JLIOrlaGAghokQ8gnw+HV7C+R7 064OUUUO//ZzNu96CiEHPVEfo+LG9Y+D8wrX+0nxyWiWlxyd7AkLAKlqo0GEIA== 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 635D93F217 for ; Sat, 24 Feb 2024 22:36:58 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rdyw2-0006BI-KI; Sat, 24 Feb 2024 15:47:50 -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 1rdnMe-0004gi-HR for guix-devel@gnu.org; Sat, 24 Feb 2024 03:26:32 -0500 Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rdnMb-0006ek-Vd for guix-devel@gnu.org; Sat, 24 Feb 2024 03:26:32 -0500 Received: by mail.gandi.net (Postfix) with ESMTPSA id 171171C0002; Sat, 24 Feb 2024 08:26:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alternativebit.fr; s=gm1; t=1708763186; 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=FZ+6UbGMiq334izIfi7p2MgM5mVZ73T6GaLHA++260U=; b=NCyFbtPONEyVsUL6jozAlOnArQpU564K/kqDkJInoUyPb4B62b50lLrraFHYBH0ViDAoLd NMs6aNqCsA8an/fDaFgbKPKgN7GAHn5N6M3+JBR3FjUyiACrJN/wPCytm9zMt18X7k4Wxa 5icqp8emLrJFe++0WOBtomDRJxyPK1Ez0oeJxlMfNFBBI7+UAhEr+K4kiaRh5/rG/FOA+R oEwj+4aOIcUPGew2Df+XkGhfK7uj+QTgPCs5theIZsy0lnVswV+QfPScdfb3jJWzzn5Err oQmM+I28pa14uXBx7Q5PUWftMJ0TxEUvshDCvdzkS8wgP+QxWH3Ezjt7R89ZCg== From: Picnoir To: Ludovic =?utf-8?Q?Court=C3=A8s?= , guix-devel@gnu.org Cc: flokli@flokli.de Subject: Re: Supporting sssd, preparing for nscd sunset In-Reply-To: <87sf1jh8gq.fsf@inria.fr> References: <87sf1jh8gq.fsf@inria.fr> Date: Sat, 24 Feb 2024 09:26:25 +0100 Message-ID: <8734tie09a.fsf@alternativebit.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-GND-Sasl: felix@alternativebit.fr Received-SPF: pass client-ip=217.70.183.197; envelope-from=picnoir@alternativebit.fr; helo=relay5-d.mail.gandi.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sat, 24 Feb 2024 15:47:48 -0500 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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -7.07 X-Spam-Score: -7.07 X-Migadu-Queue-Id: 635D93F217 X-Migadu-Scanner: mx13.migadu.com X-TUID: c8H+dpswzS6F Hey Guix, Ludovic, Some context: Flokli (CCd) and I are fighting the same issue on the NixOS side. There's two aspects in this migration story: 1. the daemon-side. IE. how to make sure a daemon is available on most distros to respond to the nscd socket 2. the client-side. IE. how to make sure we'll still have access to the glibc stubs sending queries to the daemon socket on the foreseeable future. Let's talk about the daemon side first. As I was mentionning in the blog post linked above, NixOS moved to Nsncd, a non caching re-implementation of Nscd. > I don=E2=80=99t see it helpful on other distros, at least not until/unles= s it > becomes widespread. (We can=E2=80=99t really ship ourselves because it ha= s to > be linked against the host libc.) 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. 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. Now, if you folks decide to part ways (sad), unscd[4] would likely be a better starting point to implement a uncaching nscd daemon than the current nscd implementation. ------ 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. >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. >From the nscd protocol perspective, an IPv6 address is a serie of 16 octets. This is a fine representation for global and ULA addresses. However, it's not good enough to fully qualify a link-local addresses: you also need the scopeid (ie. interface id/interface name) that comes with it . This means that IPv6 local link-local addresses resolution is currently broken for Guix/Nix programs. Such a resolution is sadly heavily used in IPv6 mdns setups. My point being: if we plan to keep using this nscd trick on the long run (we currently do), and we end up doing a massive refactoring on the Glibc side to hide the stubs, then it might be a good occasion to make some improvements to the protocol itself at the same time. And who knows, maybe we could make the bold move of redisiging altogether this protocol. For these protocol improvements, I definitely think our two communities should sync and share notes. Wow, that was long, sorry for the wall of text :) Don't hesitate to Cc me and flokli for these Nscd discussions in the future! Picnoir [1]: https://packages.debian.org/search?keywords=3Dnsncd [2]: https://aur.archlinux.org/packages/nsncd-git [3]: https://gitlab.archlinux.org/archlinux/packaging/packages/glibc/-/blob= /main/PKGBUILD?ref_type=3Dheads#L53 [4]: https://github.com/bytedance/unscd [5]: https://fosstodon.org/@codonell/111981707970893154