Hide Forgot
Description of problem: The dirsrv user/group is only created when ipa-server-install is run. That makes it hard to move IPA's data from container to a data volume as in vanilla container the records won't be there and the directory server will refuse to start: Unknown user 'dirsrv'. And if we do this, we could just as well hardcode some reasonable uid. For example, httpd does /usr/sbin/useradd -c "Apache" -u 48 \ -s /sbin/nologin -r -d /usr/share/httpd apache 2> /dev/null || : For dirsrv user, uid 389 could be used (but we'd need to verify if it's not used by someone else). Version-Release number of selected component (if applicable): 389-ds-base-1.3.1.6-26.el7_0.x86_64 How reproducible: Deterministic. Steps to Reproduce: 1. Install 389-ds-base. 2. Check /etc/group and /etc/passwd for dirsrv. Actual results: It's not there. Expected results: It should be there. Additional info:
The pkiuser bugzilla is bug 1143067.
For the record, the guidelines for allocating uids/gids and creating the system users are at https://fedoraproject.org/wiki/Packaging:UsersAndGroups#Soft_static_allocation
Per the guidelines, changing the summary/proposal to %pre.
If we are going to do this, it would be good to negotiate some uid/gid values with setup maintainers. Do we want to open some bugzillas for that? I'd like to know if the uid 389 I mention above and which I plan to use for FreeIPA in containers is likely to be used.
(In reply to Jan Pazdziora from comment #5) > If we are going to do this, it would be good to negotiate some uid/gid > values with setup maintainers. Do we want to open some bugzillas for that? Yes. > I'd like to know if the uid 389 I mention above and which I plan to use for > FreeIPA in containers is likely to be used. I don't know. We'll have to to some research to find out of uidnumber/gidnumber 389 is reserved.
(In reply to Rich Megginson from comment #6) > > > I'd like to know if the uid 389 I mention above and which I plan to use for > > FreeIPA in containers is likely to be used. > > I don't know. We'll have to to some research to find out of > uidnumber/gidnumber 389 is reserved. It does not seem to be reserved: # grep 389 /usr/share/doc/setup/uidgid | wc -l 0 # rpm -qf /usr/share/doc/setup/uidgid setup-2.9.0-2.fc21.noarch #
(In reply to Rich Megginson from comment #6) > (In reply to Jan Pazdziora from comment #5) > > If we are going to do this, it would be good to negotiate some uid/gid > > values with setup maintainers. Do we want to open some bugzillas for that? > > Yes. Filed https://fedorahosted.org/fpc/ticket/474.
(In reply to Jan Pazdziora from comment #8) > (In reply to Rich Megginson from comment #6) > > (In reply to Jan Pazdziora from comment #5) > > > If we are going to do this, it would be good to negotiate some uid/gid > > > values with setup maintainers. Do we want to open some bugzillas for that? > > > > Yes. > > Filed https://fedorahosted.org/fpc/ticket/474. Since the ticket was closed with "nothing to do", there's no much we can do in 389? > Status changed from meeting to closed > Resolution set to nothingtodo > We discussed this at today's meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-01-22/fpc.2015-01-22-17.01.txt), and we didn't feel that we should manage the image UID list:
(In reply to Noriko Hosoi from comment #10) > > Since the ticket was closed with "nothing to do", there's no much we can do > in 389? Not really. I'd still like that addressed, albeit without the fpc group assigning a particular value.
(In reply to Jan Pazdziora from comment #11) > (In reply to Noriko Hosoi from comment #10) > > > > Since the ticket was closed with "nothing to do", there's no much we can do > > in 389? > > Not really. I'd still like that addressed, albeit without the fpc group > assigning a particular value. Then what exactly can we do in 389? Change our spec files to do the useradd/groupadd with the value "389"?
(In reply to Rich Megginson from comment #12) > > Then what exactly can we do in 389? Change our spec files to do the > useradd/groupadd with the value "389"? Right, that's how I'd address it.
(In reply to Jan Pazdziora from comment #13) > (In reply to Rich Megginson from comment #12) > > > > Then what exactly can we do in 389? Change our spec files to do the > > useradd/groupadd with the value "389"? > > Right, that's how I'd address it. Ok, but what do we do when 389 is already in use by another user/group?
(In reply to Rich Megginson from comment #14) > > Ok, but what do we do when 389 is already in use by another user/group? I can see two options: 1) just use the 389 value anyway; 2) invoke useradd without the -u 389.
Upstream ticket: https://fedorahosted.org/389/ticket/48285
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
*** Bug 1227533 has been marked as a duplicate of this bug. ***
Build tested: 389-ds-base-1.3.5.8-1.el7.x86_64 [1] Before the install: # grep '389\|dirsrv' /etc/passwd /etc/group -c /etc/passwd:0 /etc/group:0 [2] After the install: # grep '389\|dirsrv' /etc/passwd /etc/group /etc/passwd:dirsrv:x:389:389:389-ds-base:/usr/share/dirsrv:/sbin/nologin /etc/group:dirsrv:x:389: [3] If dirsrv user already exists with different UID: # grep '389\|dirsrv' /etc/passwd /etc/group /etc/passwd:dirsrv:x:636:636:389-ds-base:/usr/share/dirsrv:/sbin/nologin /etc/group:dirsrv:x:636: 389-ds-base installs and setup-ds.pl correctly uses disrv user by default: # setup-ds.pl ... ============================================================================== The server must run as a specific user in a specific group. It is strongly recommended that this user should have no privileges on the computer (i.e. a non-root user). The setup procedure will give this user/group some permissions in specific paths/files to perform server-specific operations. If you have not yet created a user and group for the server, create this user and group using your native operating system utilities. System User [dirsrv]: System Group [dirsrv]: ============================================================================== ... [4] If UID is already taken by different user: # grep '389\|dirsrv' /etc/passwd /etc/group /etc/passwd:dirsrv1:x:389:389:389-ds-base:/usr/share/dirsrv:/sbin/nologin /etc/passwd:xdirsrv:x:390:390:389-ds-base:/usr/share/dirsrv:/sbin/nologin /etc/passwd:dirsrv:x:391:391:389-ds-base:/usr/share/dirsrv:/sbin/nologin /etc/group:dirsrv1:x:389: /etc/group:xdirsrv:x:390: /etc/group:dirsrv:x:391: Marking as VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2016-2594.html