Open mathomp4 opened 10 months ago
eza's using uzers, a derivative of users which is what exa was using. Doesn't look like it's changed much since I last poked at it.
It's just calling getpwuid_r
- there shouldn't be that much for it to break. Do you have any other (non-Rust) musl binaries that can map uids? Have you tried running the binary under strace to see what it's actually doing?
I note you have rather high user and group ids - are they identified by anything more complex than just /etc/passwd
?
@Freaky I'm...not sure. It's on a NASA supercomputer cluster, so it's possible things are more complex. Indeed, if I look, my name is not in /etc/passwd
.
But, I used the power of ChatGPT to make a C code that uses getpwuid_r
(I am a Fortran programmer so even simple C code like this is hard for me 😄):
#include <stdio.h>
#include <stdlib.h>
#include <pwd.h>
#include <string.h>
int main(int argc, char *argv[]) {
if (argc != 2) {
fprintf(stderr, "Usage: %s <UID>\n", argv[0]);
return 1;
}
// Convert the user input (UID) to an integer
uid_t uid = atoi(argv[1]);
struct passwd pwd;
struct passwd *result;
char buffer[1024]; // A buffer to store the user information
// Call getpwuid_r to retrieve the user information
if (getpwuid_r(uid, &pwd, buffer, sizeof(buffer), &result) == 0) {
if (result != NULL) {
printf("User Information:\n");
printf("Username: %s\n", pwd.pw_name);
printf("User ID: %d\n", pwd.pw_uid);
printf("Group ID: %d\n", pwd.pw_gid);
printf("Home directory: %s\n", pwd.pw_dir);
printf("Shell: %s\n", pwd.pw_shell);
} else {
fprintf(stderr, "User with UID %d not found.\n", uid);
return 1;
}
} else {
perror("getpwuid_r");
return 1;
}
return 0;
}
and when I run it:
$ gcc test.c
$ ./a.out 31128555
User Information:
Username: mathomp4
User ID: 31128555
Group ID: 20620
Home directory: /home/mathomp4
Shell: /usr/local/bin/bash
So, it looks like getpwuid_r
is doing its thing.
Also, I asked ChatGPT about getting the group name, it added a call to getgrgid
and that test code shows the right group.
gcc test.c
is probably giving you a glibc build - can you try with musl-gcc -static
?
I’ve seen that maybe you need the musl to also be installed for that to work, could you try installing it on your computer and see if it works?
I'll try it out next week when I'm on the cluster again. Never tried building musl
so it might take me a few tries.
Is there any progress with this issue?
Alternatively, is it possible to add CentOS build to the list of artefacts, something that would use glibc and run on older versions of linux?
I'd forgotten all about this as my job got...busy. I was never able to build/install musl-gcc
back then but maybe I can now? Does anyone have a primer on how to build that?
That said, can still confirm I see this with eza musl v0.17.1
https://github.com/eza-community/eza/issues/616#issuecomment-1964004518
I think mixing musl and glibc with PAM does not work. If the system PAM binaries and eza use the same "type", it should work.
I don't have a musl system with PAM to test this hypothesis, does anyone use Alpine Linux and PAM with sss
?
@j-xella is right, if the binaries were build on an older glibc, they could work on CentOS 7, which is still supported for a couple months. It's easy to build your own version, just install https://rustup.rs, get a release tarball and run cargo build --release
, the binaries will be in target/release
.
I poked around a bit in context of rustadopt/uzers-rs#20 and can confirm that a MUSL build of uzers fails to retrieve SSS usernames.
The core of the matter seems to be that retrieving information from SSSD requires NSS plugins which GLIBC sideloads after consulting /etc/nssswitch.conf
. MUSL however does not support NSS, see: https://github.com/SSSD/sssd/issues/6586 or citing from the MUSL wiki: "musl does not have (or want) NSS.", see https://wiki.musl-libc.org/future-ideas.html.
As I said in the uzers issue I see two options, either building the SSS support into uzers which doesn't seem like a feasible thing, though, or avoiding MUSL builds when SSS is a requirement.
Very often, the reason users have to use MUSL build is because they are stuck with old versions of Linux, where installed glibc is too old for the glibc version of eza. For those users, another solution could be an eza build for centOS. My understanding is those builds use older version of glibc.
Is it very difficult to add CentOS artefact to the list of artefacts produced for every eza release? Wezterm does something similar.
Very often, the reason users have to use MUSL build is because they are stuck with old versions of Linux, where installed glibc is too old for the glibc version of eza. For those users, another solution could be an eza build for centOS. My understanding is those builds use older version of glibc.
Is it very difficult to add CentOS artefact to the list of artefacts produced for every eza release? Wezterm does something similar.
How hard is it to produce them? If we can automate it for free somehow that's great, if someone wants to try and figure out some solution, that's welcome. It should just seek to avoid creating more work for maintainers.
Boilerplate:
and the OS is SLES 15SP4.
I am seeing an issue with
eza
that I also see inlsd
(see https://github.com/lsd-rs/lsd/issues/374) and I saw in the past. I'm not a rust expert, but I'm guessing some underlying crate is the issue? 🤷🏼To wit, if I use plain
ls
:I see
mathomp4
andg0620
as I'd expect. Now if I use a GNUeza
:Okay. Now MUSL
eza
:MUSL
eza
is showing the numeric UID and GID, but not the "human-readable" version. Now, it's possible GNU has the wrong behavior (maybe I'm missing flags?) but in any case, the GNU and MUSL builds have different behavior.