I have come across a use case where I need to ensure that particular system accounts have predictable UIDs across multiple installations. Basically, I am booting between several rootfs partitions, but they all have access to the same shared secondary disk/partition where select service configurations are stored. I want the permissions on that shared partition to be consistent across the different rootfs. What I have found is that the users and groups will change based upon the assigned UIDs of the users (/etc/passwd) and groups (/etc/group).
I found this interesting note in the RHEL kickstart documentation:
The %pre-install scripts can be used to modify the installation, and to add users and groups with guaranteed IDs before package installation.
However I haven't been able to find an example of it. Does anyone know how this is "correctly" accomplished? Do I create the /etc/passwd and /etc/group files manually?
My fallback plan is to change the UIDs and GIDs in the post-install script, like so:
One "tried and true" way to do this is to just keep a master copy of the group file and push that master copy out (rsync, sftp, etc.) to all the servers where you want to sync GIDs.
there is a user option for creating a user, which can take --uid= and --gid= flags for specifying the UID and GID for the user in question. Likewise there is a group option, which has --name= and --gid= flags to it. I've not used kickstart in a very long time (and even then, only a handful of times), but it looks to me like this is what you're after.
Hope this helps ! If not, or if you have any further questions, please let us know what about the above information doesn't quite meet your needs, and we can take things from there.
Certain users and groups are created by pre-install scripts in a +1 fashion.
If software packages are installed in different order then the uids/gids differ. And the distribution of whole passwd and group files would break the file ownership.
This was my first try, and it works great for interactive accounts, but I am interested in system accounts created by RPMs. Even when the exact same RPM list is installed by Anaconda, there appears to be some volatility in the resulting UIDs and GIDs.
This approach actually did appear to work in my circumstance because my entire environment is greenfield. Essentially, I am inserting a known /etc/passwd and /etc/group under /mnt/sysimage/ during the "%pre-install" section. The users that would normally be created by the RPMs are skipped because they already exist.
I still need to do further testing and log file review, but I think this approach will meet my needs. Still annoying that RedHat added a note in their documentation without any context or example.
For anyone else who finds this in the future, you also need to run the "pwconv" and "grpconv" commands in a chroot'd post-install script. The contents of /etc/shadow and /etc/gshadow are not fully populated. Running those commands will synchronize the shadow files with the primary files.
Otherwise, I haven't found any negative consequences of this approach. The post-installation user permissions and SELinux context of /etc/passwd and /etc/group match another system where this change was not made. I didn't see any signs of issues in /var/log/messages or /var/log/audit/audit.log.
Hi Drkwood,
I'm glad to see your solution, it helps!
Did you only insert the account you needed or all the known users(UID<100) to /mnt/sysimage/etc/passwd file?
I meet this issue either, but when I only insert the account I needed, the iso installation failed, the failure is:
