Use chroot when manipulating users and use go to check users

[n0rad]

I don't know exactly why but useradd using --root still rely on things from the current filesystem and could crash in some situation (I'm wondering if it's linked to the glibc version):

CRITICAL : files: ensureUsers: op(1): [failed]   creating or modifying user "n0rad": exit status 6: Cmd: "useradd" "--root" "/mnt" "--create-home" "--password" "*" "--uid" "20003" "--gid" "users" "--groups" "wheel" "n0rad" Stdout: "" Stderr: "configuration error - unknown item 'FAIL_DELAY' (notify administrator)\nconfiguration error - unknown item 'NONEXISTENT' (notify administrator)\nuseradd: group 'users' does not exist\nuseradd: the GROUP= configuration in /etc/default/useradd will be ignored\nuseradd: group 'users' does not exist\n"
CRITICAL : Ignition failed: failed to create users/groups: failed to configure users: failed to create user "n0rad": exit status 6: Cmd: "useradd" "--root" "/mnt" "--create-home" "--password" "*" "--uid" "20003" "--gid" "users" "--groups" "wheel" "n0rad" Stdout: "" Stderr: "configuration error - unknown item 'FAIL_DELAY' (notify administrator)\nconfiguration error - unknown item 'NONEXISTENT' (notify administrator)\nuseradd: group 'users' does not exist\nuseradd: the GROUP= configuration in /etc/default/useradd will be ignored\nuseradd: group 'users' does not exist\n"

But it exists. This is not happening when using chroot:

$ cat /mnt/etc/group | grep users 
users:x:984:
$ useradd --root /mnt --create-home --password "*" --uid 20003 --gid users --groups wheel n0rad
configuration error - unknown item 'FAIL_DELAY' (notify administrator)
configuration error - unknown item 'NONEXISTENT' (notify administrator)
useradd: group 'users' does not exist
useradd: the GROUP= configuration in /etc/default/useradd will be ignored
useradd: group 'users' does not exist
$ chroot /mnt useradd --create-home --password "*" --uid 20003 --gid users --groups wheel n0rad
$

[n0rad]

The problem is the same on userLookup using the C code in this situation. So I added support of lookup using go like the os/user do

[jlebon]

The cost here of carrying our own /etc/group and /etc/passwd parsers is quite high. I think it'd be better to try to get to the bottom of your issue.

Can you provide more information about your environment? What's the Ignition config you're providing? Are you using e.g. FCOS or Flatcar?

[n0rad]

I'm using ignition for installation of multiple distro from liveCD.

In this setup you cannot ensure the libc version (I think the issue lives here) from the liveCD matches the version from the system in installation and it look like useradd and C's lookup are mixing up between the libc from the liveCD and the version from the rootfs.

Go is providing a pure go lookup lib working well in this situation except that you cannot change the root location, hence the lookup_unix.go that is the same as os/user, except for the root param.

[jlebon]

I'm using ignition for installation of multiple distro from liveCD.

In this setup you cannot ensure the libc version (I think the issue lives here) from the liveCD matches the version from the system in installation and it look like useradd and C's lookup are mixing up between the libc from the liveCD and the version from the rootfs.

Yeah, that sounds likely. That's a neat use of Ignition but I don't think we can scope this into its supported use cases. Ignition is intended to be run from an initramfs that matches its target real root.

One massive hack that could work for you is to use LD_LIBRARY_PATH when running Ignition to ensure that the glibc used is always the one from the target system. You'd have to build Ignition against the oldest distro you support. Apologies for turning this down, and hope that hack works!