Support sssd to enable nix-channel --update working

[drupol]

Hello,

I'm currently trying this installer on Amazon Workspace. We have issues with the official installer because the usernames we use on it contains backslashes.
It looks like the installer is working fine, but when I try to install home-manager, it's failing.

WDYT ?

[drupol]

The solution for this thing:

cd /nix/var/nix/profiles/per-user
sudo ln -s $(id -u) $USER
cd /nix/var/nix/gcroots/per-user
sudo ln -s $(id -u) $USER

Props to @gmacon for providing the solution on Matrix:

This looks like it might be very similar to a problem I have on machines set up by my org's IT department, which is that my account exists in sssd, but the Nix tooling doesn't natively support it, resulting in some tools using my username and others using my user ID.

Maybe this is something that should be handled by this installer?

[Hoverbear]

Oh! Great catch! I'll have to read what sssd is, but I think this is absolutely something we should support.

[drupol]

Excellent news!

[drupol]

As a complement of information... I just checked on my Amazon Workspace machine and I can't find any trace of sssd. Maybe there are some other tools that are doing the same.
I also noticed that my username is not in /etc/passwd so I guess it's managed somewhere else, but I have no clue where it could be.

[bbenne10]

Hi! Co-worker of @gmacon here. We have this problem specifically with sssd as that is what our IT team uses for centralized auth, but I expect that it will rear its head in other scenarios where your user is not in /etc/passwd if you've not set up the machine's nix infrastructure to be aware of your authentication scheme. So if you're using some other ldap setup, I think you MAY run into this problem if you've not properly set up the "nix part" of your machine to integrate to that ldap infrastructure. I have shied away from doing that thus far because I am afraid of getting locked out of my IT-supplied work machines.

There are problems with sssd (specifically that nix/nixos does not handle the bootstrapping problem in a way that either glibc or sssd really support and end up abusing nscd. Read more at the nixpkgs issue), but sssd is likely not the only culprit that can cause this behavior.

[gmacon]

It occurred to me this morning (while talking to @bbenne10) that I realized straight away yesterday, but didn't say out loud, that this situation has nothing to do with nix-installer, to the best of my knowledge.

[Hoverbear]

Thanks for all this insight! We're currently relying on https://docs.rs/nix/latest/nix/unistd/struct.User.html for users and groups, which I don't think is very comprehensive.

I wonder if there is some more robust option...

[bbenne10]

I think that nix::unistd::User is the right answer. The problem (as stated by @gmacon) is not rooted in this repo.

Any piece of software that wants information regarding a particular user (including nix::unistd::User) will end up calling getent. getent jumps through some hoops to...well, get the user entry. The problem herein is that getent cannot find the right data. Say you have a piece of software that wants to get the username. The right way to do this is to call glibc's getent function. This forwards the request to the nss subsystem, which normally then reads /etc/nsswitch.conf and loads a bunch of .so files from disk and queries those .sos for information in an order defined in nsswitch.conf. The issue occurs when you are attempting to do this from the nix side. Nix's glibc only has the most basic plugins available (those bundled with glibc itself) and is notably missing nss_sssd.so, which provides definitions on how to query sssd.

The accepted answer via nix is to use nscd, but that has other issues. There is some noise regarding instead using a new program called nsncd, but there's some issues there too. Long story short: Determinate Systems' nix-installer has no way to handle this issue. It is a configuration problem that cannot be solved by switching libraries or similar steps. This issue is unrelated to this repository and can, in my not-at-all official opinion, absolutely be closed.

[Hoverbear]

While it may be this isn't something we can resolve in the installer, I would like to see if we can improve the current situation or offer a better message.

[Hoverbear]

We no longer provision .nix-channels so I'm closing this. It should "just work" now!

[drupol]

Cool ! I'll try asap.

[drupol]

Is it already available in 0.6.0 ?

[Hoverbear]

Should be! If you're using Mac you may want to wait for our 0.7.0 (coming by Friday) to fix some odd issues with Mac volumes and fsync timings.

[drupol]

Thanks, I'll test on Amazon Workspaces tomorrow and report back.