Closed jeffrollin closed 1 year ago
Likely an issue with https://github.com/ogham/rust-users
Relevant code: https://github.com/ogham/rust-users/blob/07bf842751d7f7ce1e9e342535d837c0e503e4f2/src/base.rs#L420-L445
Could just be the buffer is too small for your system?
This is still an issue with MOST RECENT VERSION: v0.9.0, released on July 15th
$ exa --version
exa v0.9.0
Any solution for that yet?
I just discovered exa
and really like it, but this issue would be a real game stopper for me, .. working in a multi-server/multi-user linux environment ...
lsdeluxe
has the same issues for using rust as well ..
If anyone wants to try with my fix, you can replace the users =
line in Cargo.toml with:
users = { git = "https://github.com/Freaky/rust-users.git", branch = "handle-erange" }
@Freaky Can you open a PR on the ogham/rust-users repository?
Sorry, I didn’t check. ^^’
So your fix has been merged and is in rust-users 0.11.0, and exa started using rust-users 0.11.0 in 04e2d4c69295f6990023955d0e930e702e691553, so exa 0.10.0 has the fixed version of rust-users.
Can you try exa 0.10.0 and tell if it’s fixed for you?
@sklages and @jeffrollin - can you give it another go? I only speculated that this was the issue, I didn't experience it myself.
I'm still seeing UIDs/GIDs rather than names in exa v0.10.0 on CentOS Linux 7...is there any helpful info I can provide?
@Freaky .. cargo
still installs v0.9.0
.. cargo
with the master branch installs v0.11.0-pre
.. anyway, with latest exo v0.11.0-pre
it seems to work just as expected, I do not see any IDs anymore when using --long --group
. I'd say problem bug fixed :+1:
System: in-house made Linux, 64bit
But I must admit that I switched to lsd
a while ago...
@sklages Thanks for the report! The crates.io issue is tracked here: #834
@overdodactyl I tried to compile exa on both CentOS 7 and OpenBSD 6.8 and it works, so I’m not sure how to diagnostic your problem…
Thanks for checking @ariasuni. I just tried building it myself and things are working, but not if I use the release exa-linux-x86_64-musl-v0.10.0.zip
. I was using that one due to #298
I have no problem using exa-linux-x86_64-musl-v0.10.0.zip
either, but it’s interesting to know that this problem may be happening only with musl builds.
Does anyone here is using Active Directory with the users/groups only appearing as UID/GID not in /etc/passwd
or /etc/groups
? Someone opened #900 and hinted that it may be the reason.
Also, could you try to compile and test code from this Gist? https://gist.github.com/ariasuni/0fda1d3fda4df9946e55d70038275a8a
rustup default stable
main.rs
in a src
foldercargo run user
followed by an UID that’s shown in exa, same with respectively cargo run group
and a GIDI created a dynamic user with systemd, so it wasn’t in /etc/passwd
, and it used a relatively high uid (64642), and it worked perfectly fine.
I tried to look at how ls
is doing, and it uses getuser
defined here, so both ls and exa uses {get,set,end}pwent
. Maybe something’s wrong in how the user cache is implement in rust-users.
In my case, #900, it was definitely a musl/rust-users issue. I fixed the issue by making a glibc build in a CentOS 7 VM and moving those binaries to the network in question.
After investigating, the musl issues page has an entry for NIS/LDAP/other user databases - LDAP is used to talk to Active Directory - which notes that
Up through 1.1.6, only the passwd/group files were supported for user and group database functionality. musl 1.1.7 added support for alternative backends via the NSCD protocol.
and links to a github repo for a library that lets musl use glibc's "name service switch" modules. I don't have the know-how to try making the necessary changes to rust-users.
After investigating, the musl issues page has an entry for NIS/LDAP/other user databases - LDAP is used to talk to Active Directory - which notes that
Up through 1.1.6, only the passwd/group files were supported for user and group database functionality. musl 1.1.7 added support for alternative backends via the NSCD protocol.
and links to a github repo for a library that lets musl use glibc's "name service switch" modules. I don't have the know-how to try making the necessary changes to rust-users.
I don’t think rust-users
needs fixing. If I understand correctly, this is something to install and configure locally. If not, then maybe it’s possible to build exa with a different musl, but I’ll leave it to people who know this kind of stuff, because it seem like two very rare things to do with almost no information about on the web (building a Rust program with a different musl, and using something like musl-ncsd).
Does anyone here is using Active Directory with the users/groups only appearing as UID/GID not in
/etc/passwd
or/etc/groups
? Someone opened #900 and hinted that it may be the reason.Also, could you try to compile and test code from this Gist? https://gist.github.com/ariasuni/0fda1d3fda4df9946e55d70038275a8a
1. Download [rustup](https://rustup.rs/) and run `rustup default stable` 2. Download files from Gist, put `main.rs` in a `src` folder 3. Run `cargo run user` followed by an UID that’s shown in exa, same with respectively `cargo run group` and a GID
I created a dynamic user with systemd, so it wasn’t in
/etc/passwd
, and it used a relatively high uid (64642), and it worked perfectly fine.I tried to look at how
ls
is doing, and it usesgetuser
defined here, so both ls and exa uses{get,set,end}pwent
. Maybe something’s wrong in how the user cache is implement in rust-users.
@ariasuni I just installed exa v0.10.1 (the musl release) on a CentOS 7 system, and ran into the same numeric UID/GID issue. I just gave this snippet a shot, and it correctly printed out valid user/group names given a UID/GID printed out by exa. Hooray! I also gave it some garbage UID/GID values, and it printed "result is null". Any other testing I could do?
Strangely enough, if I clone and build the v0.9.0 release, then the user/group names show up as expected (no UID/GIDs). I also tried the v0.10.0 musl release for good measure, and it also displayed UID/GIDs rather than names.
Another data point: I cloned the repo and built it myself with the default x86_64-unknown-linux-gnu
target, and it works properly (user/group names, no UID/GIDs). Note that I wasn't able to use the x86_64-unknown-linux-gnu
release binary as it required a glibc version not present on my system. So, this could come down to a bad interaction with musl libc.
Unfortunately I wasn't able to build the x86_64-unknown-linux-musl
target myself due to linker errors.
If you want to build x86_64-unknown-linux-musl
, then you need to install e.g. must-tools
on Ubuntu (you want the package of your distribution that has the musl-gcc
executable).
lsd seems to have the same issue as us (but it uses rust-users too): https://github.com/Peltoche/lsd/issues/374
There’s also an issue about musl on the rust-users GitHub: https://github.com/ogham/rust-users/issues/14#issuecomment-826973476
I don’t really time to make sense of all of these versions/musl or not/binary or compiled/OS combinations… The issue just seem very nebulous.
The thing I’d like to know is: is there a version of exa 0.10.1 or master, built from source, that fails to give names instead of UID/GID when it’s in /etc/passwd
.
exea version 0.10.1 OS: Ubuntu 22.04
exa -l only shows user, not group
@ARehmanMahi - please read https://the.exa.website/features/long-view
exa is unmaintained, see https://github.com/ogham/exa/issues/1243.
Anyone still having this problem, do you have it with the active fork eza?
Closing this in favor of https://github.com/eza-community/eza/issues/541
When using the long listing format (--long or -l) with the --group or -g option, the group identifiers displayed are the numeric GIDs, not the group names. The user names display as expected. The issue is the same whether running exa as a regular user or as root. /etc/group permissions, and group and user details in /etc/group and /etc/passwd, have been checked and are correct.