The dirsrv bugzilla is bug 1143066.

The issue here is that the user/group creation needs to happen as a part of the RPM installation, not during execution of pkispawn.  This is necessary for the effort to run IPA (and a Dogtag CA) in a container.  The fact that we already have uid/gid 17 reserved is good, but we need to move the user/group creation logic to %post.

(In reply to Nathan Kinder from comment #6)
> The issue here is that the user/group creation needs to happen as a part of
> the RPM installation, not during execution of pkispawn.  This is necessary
> for the effort to run IPA (and a Dogtag CA) in a container.  The fact that
> we already have uid/gid 17 reserved is good, but we need to move the
> user/group creation logic to %post.

Right. And even if we don't they they are only created by pkispawn (as part of ipa-server-install, maybe), the assigned 17/17 values should be used, which does not seem to happen now.

(In reply to Jan Pazdziora from comment #8)
> 
> Right. And even if we don't they they are only created by pkispawn (as part
> of ipa-server-install, maybe), the assigned 17/17 values should be used,
> which does not seem to happen now.

I've now filed bug 1145584 against ipa for the mismatch.

For the record, the guidelines for creating the system users are at https://fedoraproject.org/wiki/Packaging:UsersAndGroups#Soft_static_allocation

(In reply to Jan Pazdziora from comment #10)
> For the record, the guidelines for creating the system users are at
> https://fedoraproject.org/wiki/Packaging:
> UsersAndGroups#Soft_static_allocation

A few comments:

Note that this article refers to storing this in the %pre directive, not the %post directive; you may want to change the title of this bug.

We used to have very similar code in a '%pre' directive (RHEL 4/RHEL 5):

    %pre
    if [ `grep -c pkiuser /etc/group` -eq 0 ] ; then
	echo "Adding default PKI group \"pkiuser\" (gid=17) to /etc/group."
	groupadd -g 17 -r pkiuser
	if [ $? -ne 0 ]; then
		echo "Adding default PKI group \"pkiuser\" (gid=random) to /etc/group."
		groupadd pkiuser
	fi
    fi
    if [ `grep -c pkiuser /etc/passwd` -eq 0 ] ; then
	echo "Adding default PKI user \"pkiuser\" (uid=17) to /etc/passwd."
	useradd -g pkiuser -d %{_datadir}/pki -s /sbin/nologin -c "Red Hat Certificate System" -u 17 -r -m pkiuser
	if [ $? -ne 0 ]; then
            echo "Adding default PKI user \"pkiuser\" (uid=random) to /etc/passwd."
            useradd -g pkiuser -d %{_datadir}/pki -s /sbin/nologin -c "Red Hat Certificate System" -m pkiuser
	fi
    fi

The 'rpmdiff' tests failed (and were always waived):

    Invocation of useradd without specifying a UID on noarch:

        useradd -g pkiuser -d /usr/share/pki -s /sbin/nologin -c "Red Hat Certificate System" -m pkiuser

Although it is understood that we would not need to add the offending code any longer since we now have a reserved uid:gid, with the implementation of 'Bugzilla Bug #512234 - Move pkiuser:pkiuser check from spec file into pkicreate . . .', we introduced the ability to name the default username:groupname of pkiuser:pkiuser to be easily overridden by the end-user.  This feature would need to be documented that this username:groupname is now 'hard-coded'.

Additionally, as was being attempted by the original %pre code, if the uid:gid of 17:17 had previously been specified by another application, we attempt to generate a random uid/gid associated with the user chosen username/groupname in the 'pkicreate' and 'pkispawn' code.  Although it is my understanding that this revised code will not be implemented for RHEL 6 (and thus no changes will be needed for 'pkicreate'), I believe that we will need to determine failure conditions in 'pkispawn' for Fedora and RHEL 7 in the event that 'pkiuser:pkiuser' has failed to be defined during package installation. However, since this bug seeks to establish these values upon package installation without the need for 'pkispawn', it will need to be established what happens if the packages are installed without successfully creating a pkiuser:pkiuser.

Finally, although the uid:gid values of 17:17 (which are less than the system account uid:gid ranges of 201-999) are reserved for both RHEL and Fedora as pkiuser:pkiuser, I am not certain that other platforms (e. g. - Debian) honor these values.  Therefore, we may need some additional error checking within the confines of the 'pkispawn' executable.

(In reply to Matthew Harmsen from comment #11)
> (In reply to Jan Pazdziora from comment #10)
> > For the record, the guidelines for creating the system users are at
> > https://fedoraproject.org/wiki/Packaging:
> > UsersAndGroups#Soft_static_allocation
> 
> A few comments:
> 
> Note that this article refers to storing this in the %pre directive, not the
> %post directive; you may want to change the title of this bug.

Soft static allocation policy uses %pre, as otherwise files owned by the group/user will be owned by root (as the id is not in place at the time of the package installation). This is the main reason for %pre. 

> The 'rpmdiff' tests failed (and were always waived):
> 
>     Invocation of useradd without specifying a UID on noarch:
> 
>         useradd -g pkiuser -d /usr/share/pki -s /sbin/nologin -c "Red Hat
> Certificate System" -m pkiuser
> 

Yes, because rpmdiff prefers static ids. I think the check should be revisited, in many times, dynamic system user id allocation is just fine. 

> Finally, although the uid:gid values of 17:17 (which are less than the
> system account uid:gid ranges of 201-999) are reserved for both RHEL and
> Fedora as pkiuser:pkiuser, I am not certain that other platforms (e. g. -
> Debian) honor these values.  Therefore, we may need some additional error
> checking within the confines of the 'pkispawn' executable.

No, unfortunately not. Many of the uid/gids reservations are the same between Debian and Fedora - in Debian, they even have two ranges of reserved ids - see https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2.2 ... this was similar in Fedora, but I don't think the second range of static allocation is maintained by anyone nowadays (and in any case it was different range than Debian one). 
Primary range in debian is maintained in base-passwd - when assigning new id, I try to sync with the Debian list, however most of the times it is not possible - as we don't use 60000+ range for static allocations. Uid/Gid pkiuser is not in the "default ones - lower than 100" in Debian - https://www.debian.org/doc/manuals/securing-debian-howto/ch12.en.html#s-faq-os-users .

(In reply to Matthew Harmsen from comment #11)
> 
> Note that this article refers to storing this in the %pre directive, not the
> %post directive; you may want to change the title of this bug.

Done. If the pki* packages don't ship any pkiuser-owned files/directories, %post would work as well but being consistent with the guidelines would certainly be nice.

> The 'rpmdiff' tests failed (and were always waived):
> 
>     Invocation of useradd without specifying a UID on noarch:
> 
>         useradd -g pkiuser -d /usr/share/pki -s /sbin/nologin -c "Red Hat
> Certificate System" -m pkiuser

Since the guidelines snippet example has the useradd invocation without uid in the else branch, I'd assume the test either catches that situation and not complain, or will need to be changed to comply with the guidelines.

> Although it is understood that we would not need to add the offending code
> any longer since we now have a reserved uid:gid, with the implementation of

You still have to assume that the admin has the uid used for some other user and fall back.

> 'Bugzilla Bug #512234 - Move pkiuser:pkiuser check from spec file into
> pkicreate . . .', we introduced the ability to name the default
> username:groupname of pkiuser:pkiuser to be easily overridden by the

I think the situation is further complicated by the fact that IPA does not seem to use pkicreate (which if I understand it correctly would use 17/17) and manually runs adduser without uid (bug 1145584), effectively killing any effort that went into the standardization of the uid/gid, for deployments of dogtag with IPA (which there might be quite a lot of them). Yes, not dogtag's problem per se, but the change leading to allocation of 17/17 probably was not communicated to and reflected by IPA.

> end-user.  This feature would need to be documented that this
> username:groupname is now 'hard-coded'.

Yes. The admin can still precreate the pkiuser user/group before installing pki* packages (or even change the uid/gid afterwards).

> Additionally, as was being attempted by the original %pre code, if the
> uid:gid of 17:17 had previously been specified by another application, we
> attempt to generate a random uid/gid associated with the user chosen
> username/groupname in the 'pkicreate' and 'pkispawn' code.  Although it is
> my understanding that this revised code will not be implemented for RHEL 6
> (and thus no changes will be needed for 'pkicreate'), I believe that we will
> need to determine failure conditions in 'pkispawn' for Fedora and RHEL 7 in
> the event that 'pkiuser:pkiuser' has failed to be defined during package
> installation. However, since this bug seeks to establish these values upon
> package installation without the need for 'pkispawn', it will need to be
> established what happens if the packages are installed without successfully
> creating a pkiuser:pkiuser.

IMHO, the application setup code should still check for the user/group and create them if they don't exist for whatever reason. You might have installations right from git or otherwise outside of the rpm packaging system and you probably want to fallback gracefully.

> Finally, although the uid:gid values of 17:17 (which are less than the
> system account uid:gid ranges of 201-999) are reserved for both RHEL and
> Fedora as pkiuser:pkiuser, I am not certain that other platforms (e. g. -
> Debian) honor these values.  Therefore, we may need some additional error
> checking within the confines of the 'pkispawn' executable.

That's very possible.

Upstream ticket:
https://fedorahosted.org/pki/ticket/1468

Cheimes fix for this bug was checked into the 'master':

commit 417adee8bc0607ccf43f1dd80fc08b870088937b
Author: Christian Heimes <cheimes>
Date:   Wed Jul 15 21:49:16 2015 +0200

    Create pkiuser user and group during installation
    
    The group 'pkiuser' and user 'pkiuser' are now created during the
    installation of the pki-server package.
    
    https://fedorahosted.org/pki/ticket/1468

Does this mean the UID:GID are created with the "hard-coded" values, 17:17? I have 

`pkiuser:x:991:989:DS System User:/var/lib:/sbin/nologin` in the /etc/passwd file.  Granted, this was created BEFORE the fix was released.

Verified using both the following versions:

[root@cloud-qe-7 SPECS]# rpm -qi pki-server
Name        : pki-server
Version     : 10.2.5
Release     : 5.el7
Architecture: noarch
Install Date: Thu 27 Aug 2015 03:13:08 PM EDT
Group       : System Environment/Base
Size        : 4645306
License     : GPLv2
Signature   : RSA/SHA256, Mon 17 Aug 2015 10:24:39 AM EDT, Key ID 938a80caf21541eb
Source RPM  : pki-core-10.2.5-5.el7.src.rpm
Build Date  : Wed 12 Aug 2015 09:51:40 PM EDT
Build Host  : ppc-034.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://pki.fedoraproject.org/
Summary     : Certificate System - PKI Server Framework

[root@ipaqavmd ~]# rpm -qi pki-server
Name        : pki-server
Version     : 10.2.6
Release     : 8.el7pki
Architecture: noarch
Install Date: Thu 27 Aug 2015 03:53:44 PM EDT
Group       : System Environment/Base
Size        : 4612851
License     : GPLv2
Signature   : (none)
Source RPM  : pki-core-10.2.6-8.el7pki.src.rpm
Build Date  : Tue 25 Aug 2015 01:18:45 AM EDT
Build Host  : x86-025.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://pki.fedoraproject.org/
Summary     : Certificate System - PKI Server Framework

Verification steps:

[root@ipaqavmd ~]# getent passwd pkiuser
[root@ipaqavmd ~]# getent group pkiuser
[root@ipaqavmd ~]# yum install pki-server
Loaded plugins: product-id, search-disabled-repos, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Resolving Dependencies
--> Running transaction check
---> Package pki-server.noarch 0:10.2.5-5.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package           Arch          Version             Repository            Size
================================================================================
Installing:
 pki-server        noarch        10.2.5-5.el7        beaker-Server        2.9 M

Transaction Summary
================================================================================
Install  1 Package

Total download size: 2.9 M
Installed size: 4.4 M
Is this ok [y/d/N]: y
Downloading packages:
pki-server-10.2.5-5.el7.noarch.rpm                         | 2.9 MB   00:00     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : pki-server-10.2.5-5.el7.noarch                               1/1 
  Verifying  : pki-server-10.2.5-5.el7.noarch                               1/1 

Installed:
  pki-server.noarch 0:10.2.5-5.el7                                              

Complete!
[root@ipaqavmd ~]# getent group pkiuser
pkiuser:x:17:
[root@ipaqavmd ~]# getent passwd pkiuser
pkiuser:x:17:17:Certificate System:/usr/share/pki:/sbin/nologin

Also verifified spec file has the following

%pre -n pki-server
getent group %{pki_groupname} >/dev/null || groupadd -f -g %{pki_gid} -r %{pki_groupname}
if ! getent passwd %{pki_username} >/dev/null ; then
    if ! getent passwd %{pki_uid} >/dev/null ; then
      useradd -r -u %{pki_uid} -g %{pki_groupname} -d %{pki_homedir} -s /sbin/nologin -c "Certificate System" %{pki_username}
    else
      useradd -r -g %{pki_groupname} -d %{pki_homedir} -s /sbin/nologin -c "Certificate System" %{pki_username}
    fi
fi
exit 0

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/RHBA-2015-2276.html