profiles: Do not modify preexisting users

[krnowak]

Add an ebuild phase hook that runs when pkg_postinst is about to be executed. The hook sets up the environment for acct-user packages to avoid modifications of the preexisting users - these are provided by our baselayout and usermod can't change anything there anyway (it complains that the user is not in /etc/passwd).

Should be merged together with flatcar-archive/portage-stable#404.

CI passed: http://jenkins.infra.kinvolk.io:8080/job/container/job/sdk/529/cldsv/

[pothos]

I think this sounds like an upstream problem as in flatcar/Flatcar#799

Does this prevent adding new users with acct-user? We wanted to rely on systemd-sysusers to create new users from it.

[krnowak]

I think this sounds like an upstream problem as in flatcar/Flatcar#799

This whole thing is weird. useradd and usermod seem to be very dumb as they know only about passwd and group in /etc, whereas groupadd seems to be more sophisticated and able to notice that some group is defined in group in /usr/share/baselayout. As if useradd and usermod were directly grepping files in /etc while groupadd uses some libc functionality that uses our nss-files plugin. Of course, I did not check the source of the utilities to be sure - these are just my observations.

So in case of this PR, the eclasses were using their own solution to find out info about users or groups (which was smart enough to detect that we have some users defined in $ROOT/usr/share/baselayout), but were still using usermod to modify the user information. Of course, it worked fine for new users, but failed for users already defined in baselayout.

Before updating the eclasses, the failure wasn't fatal. Just some warnings were printed and the build chugged along (as you can see in the CI for the stage1 build, which is using the old versions of eclasses):

 * Messages for package acct-user/portage-0 merged to /tmp/stage1root/:
 * Log file: /mnt/host/source/src/build/catalyst/log/acct-user:portage-0:20230112-153144.log
 * Updating home for user 'portage' ...
 *  - Home: /var/lib/portage/home
 * portage is in use, cannot update home
 * There was an error when attempting to update the home directory for portage
 * Please update it manually on your system (as root):
 * 	 usermod -d "/var/lib/portage/home" "portage"
 * Unable to identify the shell to use, proceeding with userland default.
 * Updating shell for user 'portage' ...
 *  - Shell: /bin/false
 * There was an error when attempting to update the shell for portage
 * Please update it manually on your system (as root):
 * 	 usermod -s "/bin/false" "portage"
 * Updating comment for user 'portage' ...
 *  - Comment: System user; portage
 * There was an error when attempting to update the comment for portage
 * Please update it manually on your system (as root):
 * 	 usermod -c "System user; portage" "portage"

But after update, failure to modify of the existing users was fatal. The acct-user eclass is giving us a possibility to skip modifying the already existing users, which is what we do in this PR.

Does this prevent adding new users with acct-user? We wanted to rely on systemd-sysusers to create new users from it.

No, it shouldn't. These packages are still installing files to sysusers.d, so this does not prevent us from using systemd-sysusers.

[pothos]

Yes, the inconsistent behavior in useradd vs groupadd is a regression.
Thanks for the detailed response, all good then!

[krnowak]

Thanks for the review, could you also have a look at flatcar-archive/portage-stable#404 (as those PRs need to go together)? Thanks.