[-- Attachment #1: Type: text/plain, Size: 3075 bytes --] Hi, The Guix manual recommends running nscd: https://guix.gnu.org/manual/en/html_node/Application-Setup.html However, Fedora intends to remove it: https://fedoraproject.org/wiki/Changes/RemoveNSCD The document says: "The hosts cache will automatically be replaced by the one provided by systemd-resolved. However, in order to restore caching functionality for other caches provided by nscd, the system administrator will need to install and/or configure sssd (by enabling sssd with authconfig, and editing /etc/sssd/sssd.conf to enable it to work with nss)." This poses a problem for people who use Fedora, like myself. I tried to set up sssd on my Fedora machine, but I couldn't get it to work. Let's take a step back. Why does the Guix manual recommend using nscd? The Guix manual explains why in the link above. To rephrase the manual, my understanding is that if nscd is available, then a program using glibc will "try to use nscd" first. However, if nscd is not available, then the program will attempt to dlopen shared objects, and in some cases the program might dlopen an incompatible shared object from the foreign distro (e.g., libnss_*.so files on Fedora, which may be incompatible with the glibc used by a program that Guix built). The Fedora document explains that at least the hosts cache will be handled by systemd-resolved. Can I expect Guix-built programs to "try to use systemd" when resolving host names, or is additional configuration likely to be required? Regarding sssd specifically, how can I arrange for a Guix-built program to "try to use sssd" first? I know that the specific steps for how to do this on Fedora might be different from other systems. For example, maybe on Fedora there is some fancy authselect/authconfig thing you can do to configure everything more easily. That's fine, and I will figure out what to do at a higher level as needed. However, for now I just want to know the very basics: fundamentally, what configuration needs to exist in order to ensure that Guix-built programs will "use" sssd, in the same way that they would "use" nscd? I want to avoid the kind of problems that the manual discusses, but I want to do it with sssd. I believe this will require changes to /etc/nsswitch.conf, as well as configuration for sssd. Anything else? I have never written sssd configuration files, and the sssd manual was not very approachable for me, so I'm starting from essentially zero knowledge about sssd. It seems rather complex. Has anyone tried setting up sssd and configuring nsswitch to use it, in order to avoid the kinds of issues that the Guix manual discusses? Any tips would be welcome. Maybe I should just switch back to Guix System and avoid this headache, but I think there are lots of people out there who use Fedora, so it would be good for Guix adoption if we can have a recommended solution ready for people who are curious to try Guix on Fedora. -- Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 861 bytes --]
Hi Chris, > The Fedora document explains that at least the hosts cache will be > handled by systemd-resolved. Can I expect Guix-built programs to "try > to use systemd" when resolving host names, or is additional > configuration likely to be required? as far as I know systemd also plugs into the nss mechanism, i.e. it’s a shared library libnss_systemd.so from the host system, which would be dlopen’ed. > Regarding sssd specifically, how can I arrange for a Guix-built program > to "try to use sssd" first? I believe nscd is a glibc internal mechanism, which – if enabled – will be queried before using the nsswitch mechanism. Thus it works to circumvent the shared library dilemma on foreign systems. Programs do not use sssd directly (that’s the whole point of nss/sssd). It plugs into nsswitch just like systemd and therefore does nothing for our use case. nixOS seems to have the same problem, with suggestions for solutions like [1]. So in conclusion I don’t think sssd is an appropriate replacement for our use-case. Cheers, Lars [1] https://github.com/NixOS/nixpkgs/pull/155655
Hello, Chris Marusich <cmmarusich@gmail.com> skribis: > The Guix manual recommends running nscd: > > https://guix.gnu.org/manual/en/html_node/Application-Setup.html > > However, Fedora intends to remove it: > > https://fedoraproject.org/wiki/Changes/RemoveNSCD D’oh! This is bad. It might suggest that nscd will vanish from glibc as well, given it’s partly developed by the same group of people. AFAIK, nscd is the only way to allow glibc’s name service switch (NSS) to be used on a system where multiple glibc versions might coexist. This is a problem Fedora doesn’t have: there’s always a single glibc package installed. [...] > The Fedora document explains that at least the hosts cache will be > handled by systemd-resolved. Can I expect Guix-built programs to "try > to use systemd" when resolving host names, or is additional > configuration likely to be required? I suppose there’s a systemd-resolved NSS module, and /etc/nsswitch.conf points to it. > Regarding sssd specifically, how can I arrange for a Guix-built program > to "try to use sssd" first? The relevant glibc functions always check nsswitch.conf and use the methods prescribed there. When nscd is not running, they might end up trying to dlopen libnss_sssd.so, which will usually fail. One way to work around it is described here: https://lists.gnu.org/archive/html/guix-devel/2020-08/msg00168.html But this is pretty much a last resort and not something we’d recommend for general use. HTH! Ludo’.
Hi, Ludovic Courtès <ludo@gnu.org> skribis: > Chris Marusich <cmmarusich@gmail.com> skribis: > >> The Guix manual recommends running nscd: >> >> https://guix.gnu.org/manual/en/html_node/Application-Setup.html >> >> However, Fedora intends to remove it: >> >> https://fedoraproject.org/wiki/Changes/RemoveNSCD > > D’oh! This is bad. It might suggest that nscd will vanish from glibc > as well, given it’s partly developed by the same group of people. Carlos O’Donell (of glibc) was kind enough to start a discussion explaining why this is a concern for Guix (and Nix and others) and proposing possible ways forward: https://sourceware.org/pipermail/libc-alpha/2022-February/136741.html continued: https://sourceware.org/pipermail/libc-alpha/2022-March/thread.html#136745 Ludo’.
Hi,
On Tue, 01 Mar 2022 at 18:24, Ludovic Courtès <ludo@gnu.org> wrote:
> Ludovic Courtès <ludo@gnu.org> skribis:
>> Chris Marusich <cmmarusich@gmail.com> skribis:
>>
>>> The Guix manual recommends running nscd:
>>>
>>> https://guix.gnu.org/manual/en/html_node/Application-Setup.html
>>>
>>> However, Fedora intends to remove it:
>>>
>>> https://fedoraproject.org/wiki/Changes/RemoveNSCD
>>
>> D’oh! This is bad. It might suggest that nscd will vanish from glibc
>> as well, given it’s partly developed by the same group of people.
>
> Carlos O’Donell (of glibc) was kind enough to start a discussion
> explaining why this is a concern for Guix (and Nix and others) and
> proposing possible ways forward:
>
> https://sourceware.org/pipermail/libc-alpha/2022-February/136741.html
>
> continued:
>
> https://sourceware.org/pipermail/libc-alpha/2022-March/thread.html#136745
What is the status of this? Can it be blocking for the next release?
Cheers,
simon
Hi, zimoun <zimon.toutoune@gmail.com> skribis: > On Tue, 01 Mar 2022 at 18:24, Ludovic Courtès <ludo@gnu.org> wrote: >> Ludovic Courtès <ludo@gnu.org> skribis: >>> Chris Marusich <cmmarusich@gmail.com> skribis: >>> >>>> The Guix manual recommends running nscd: >>>> >>>> https://guix.gnu.org/manual/en/html_node/Application-Setup.html >>>> >>>> However, Fedora intends to remove it: >>>> >>>> https://fedoraproject.org/wiki/Changes/RemoveNSCD >>> >>> D’oh! This is bad. It might suggest that nscd will vanish from glibc >>> as well, given it’s partly developed by the same group of people. >> >> Carlos O’Donell (of glibc) was kind enough to start a discussion >> explaining why this is a concern for Guix (and Nix and others) and >> proposing possible ways forward: >> >> https://sourceware.org/pipermail/libc-alpha/2022-February/136741.html >> >> continued: >> >> https://sourceware.org/pipermail/libc-alpha/2022-March/thread.html#136745 > > What is the status of this? Nothing has changed; we have too little weight in the upstream discussion, so the most likely outcome is that we’ll have to adapt somehow. > Can it be blocking for the next release? No, because it’s not implemented yet, but it’ll have to be addressed soon enough. Thanks, Ludo’.