Install package with alternate UID using YUM?
I figured this would have been simple, but I can't figure this out.
I would like to install Jenkins which attempts to add a user/group using 499. In my environment 499 is already in use. I would rather not fallback to using RPM.
Anyone know how to provide the UID/GID for a single package install?
Responses
Guru
6643 points
James,
I would be surprised if this was simple because the way users/groups are created in rpms isn't as well defined as say.. files/directory ownership. I am not sure how a generic override for UID/GID of created users would function unless all packages followed the same convention (checking for override)?
Depending on the package, it may check to see if the user is created before attempting to create the user.. so creating the userid with the UID/GID you want before installing the RPM might be enough to resolve it.
What does "rpm -q--scripts" give up from the jenkins rpm in regards to the logic that is used to create the user?
Guru
6863 points
Good call. This particular package has a poorly executed user management section
# rpm --scripts -qp ./jenkins-1.586-1.1.noarch.rpm
warning: ./jenkins-1.586-1.1.noarch.rpm: Header V4 DSA/SHA1 Signature, key ID d50582e6: NOKEY
preinstall scriptlet (using /bin/sh):
/usr/sbin/groupadd -r jenkins &>/dev/null || :
# SUSE version had -o here, but in Fedora -o isn't allowed without -u
/usr/sbin/useradd -g jenkins -s /bin/false -r -c "Jenkins Continuous Build server" \
-d "/var/lib/jenkins" jenkins &>/dev/null || :
postinstall scriptlet (using /bin/sh):
/sbin/chkconfig --add jenkins
NOTE: I don't see where it selected 499 for a UID though - now I'm confused again. Either way - poor execution step there.
I think it should be something more like...
getent group jenkins || /usr/sbin/groupadd -r jenkins
getent passwd jenkins || /usr/sbin/useradd -g jenkins -s /bin/false -r -c "Jenkins Continuous Build server" \
-d "/var/lib/jenkins" jenkins
Seeing as this is literally the first time in my career that I have run in to this issue... I'll probably just move on ;-) Thanks for pointing me down that path though.
I actually figured this was likely not easy because packages that install dependencies (which presumably have UID/GID setups of their own). I just really dislike managing RPMs outside of yum.
Guru
6863 points
Ugg - I meant GID... Anyhow - This is pretty interesting. GID 499 is happenstance - I tried on another host... and I got the following:
Nov 7 10:10:17 pdgllpusgtst91 groupadd[8446]: group added to /etc/group: name=jenkins, GID=498
Nov 7 10:10:17 pdgllpusgtst91 groupadd[8446]: group added to /etc/gshadow: name=jenkins
Nov 7 10:10:17 pdgllpusgtst91 groupadd[8446]: new group: name=jenkins, GID=498
Nov 7 10:10:17 pdgllpusgtst91 useradd[8451]: failed adding user 'jenkins', data deleted
If I look at my host... (post install, of course)
[root@pdgllpusgtst91 ~]# getent group | grep :49
cgred:x:499:
jenkins:x:498:
So - I thought perhaps my GID_MIN was in play...
[root@pdgllpusgtst91 ~]# grep GID /etc/login.defs
GID_MIN 500
GID_MAX 60000
Very.. very.. perplexing?
Guru
6435 points
Some RPMs will allow the use of environmental variables to influence the installation. If you're able to set appropriate, behavior-modifying environmentals in your shell, they should pass from your invoking shell, into yum and down to the RPM installation process. ...But that's only helpful for some RPMs and you'd have to pick through the vendor documentation (or the RPM itself) to find what behavior-modifiers are available. Unfortunately, even when available, they're often not well-documented.