Bug 1143066

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 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