This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 991505 - Documented OpenStack reserved uids/gids
Documented OpenStack reserved uids/gids
Status: CLOSED CURRENTRELEASE
Product: Red Hat OpenStack
Classification: Red Hat
Component: doc-Configuration_Reference_Guide (Show other bugs)
unspecified
Unspecified Unspecified
low Severity low
: ---
: 4.0
Assigned To: Summer Long
ecs-bugs
: Documentation, Triaged
Depends On: 991508
Blocks: 1011085
  Show dependency treegraph
 
Reported: 2013-08-02 11:11 EDT by Dave Sullivan
Modified: 2014-09-22 09:49 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-05 22:40:06 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dave Sullivan 2013-08-02 11:11:00 EDT
Document URL: 

Section Number and Name: 

Describe the issue: 

The following BZ was created to have openstack uids/gids documented.

https://bugzilla.redhat.com/show_bug.cgi?id=991502

It would be nice to have the Installation and Configuration Guide reference/document the reserved uids/gids used by openstack.

For example openstack uid/gids are not documented in setup rpm

mysql:x:27:27:MySQL Server:/var/lib/mysql:/bin/bash
qpidd:x:498:499:Owner of Qpidd Daemons:/var/lib/qpidd:/sbin/nologin
keystone:x:163:163:OpenStack Keystone Daemons:/var/lib/keystone:/sbin/nologin
glance:x:161:161:OpenStack Glance Daemons:/var/lib/glance:/sbin/nologin
cinder:x:165:165:OpenStack Cinder Daemons:/var/lib/cinder:/sbin/nologin
nova:x:162:162:OpenStack Nova Daemons:/var/lib/nova:/sbin/nologin
memcached:x:497:496:Memcached daemon:/var/run/memcached:/sbin/nologin
nagios:x:496:495::/var/spool/nagios:/sbin/nologin


Suggestions for improvement: 

Additional information: 

I'm not sure how well this process is exposed to RHEL Product PMs or third party vendors

Another RFE will be filed to document the setup rpm and document this material as well

https://fedoraproject.org/wiki/Packaging:UsersAndGroups

Specifically the allocation strategies.  If you look at those scripts you can sort of see how you prevent yourself from running into problems with uid/gid relative to using the dynamic allocation strategy.  

So it does look like setup rpm is the right spot, it's just a matter of folks following the FCP process for obtaining a soft static uid/gid.

we need to expose this to the RHEL Product PMs to ensure they are following this process.  As well as exposing this to third party/hardware partner vendors as well.

Because as we have seen from the setup rpm we are missing documented uid/gid for openstack, and I suspect there are others.

The other thing is that we will have to work on is migrating the above documentation into RHEL documentation.

On another note, it looks like there will be some movement of the reserved space going up to 1000.

So probably best to start non reserved gids at something higher then 1000, maybe 5000 is a good best practice strategy.
Comment 2 Stephen Gordon 2013-08-02 12:00:25 EDT
Summer this looks like configuration reference material to me, perhaps raise a launchpad bug and discuss with Tom? I suspect concerns might be:

1) Ubuntu etc. may have different values so the upstream guide may need multiple table. Worth checking though as there is a good chance they are actually using the same values for most of these.

2) These two are actually coming from base-RHEL, so I'm not sure we really need/want them in the RHOS configuration material (though follow up is likely required to determine where, if anywhere, this is covered for RHEL and reference it):

mysql:x:27:27:MySQL Server:/var/lib/mysql:/bin/bash
qpidd:x:498:499:Owner of Qpidd Daemons:/var/lib/qpidd:/sbin/nologin

Not sure if memcached falls into that category as well.

3) Upstream probably wont include this one as it's something we "bolt on" in our distribution (I also wonder if, related to this, there are users for puppet, foreman, etc. that we are adding):

nagios:x:496:495::/var/spool/nagios:/sbin/nologin

At the least though the guide should included a reference table of the core daemons which would leave:

keystone:x:163:163:OpenStack Keystone Daemons:/var/lib/keystone:/sbin/nologin
glance:x:161:161:OpenStack Glance Daemons:/var/lib/glance:/sbin/nologin
cinder:x:165:165:OpenStack Cinder Daemons:/var/lib/cinder:/sbin/nologin
nova:x:162:162:OpenStack Nova Daemons:/var/lib/nova:/sbin/nologin

Plus neutron, swift, ceilometer, heat? Though I don't know what their IDs are.
Comment 3 Summer Long 2013-08-04 21:29:33 EDT
Depends on how exactly gids/uids would be used in OpenStack configuration. If they're really only needed in creating packages, then perhaps not. I couldn't see anything in current OS config. All OS created config already takes reserved bits into account. Have sent Steve an email with usage question.
Comment 4 Stephen Gordon 2013-08-05 20:19:02 EDT
Sometimes organizations assign UIDs/GIDs in the reserved range (currently 0-500 in RHEL) to other third party software or systems. As a result when installing software that requires one or more UIDs/GIDs administrators are interested in knowing what they are so they can change them (or those of existing systems if necessary. It may also come up via a security audit.

Given OpenStack appears to reserve a number of UIDs/GIDs in a typical deployment (theoretically increasing the chances of clashing with something else installed at a specific site) I think the request has merit.
Comment 5 Dave Sullivan 2013-08-07 14:18:08 EDT
Also from a security standpoint, folks like to know which uids/gids are valid.

e.g. "These are known to valid/required uid/gids"
Comment 6 Dave Sullivan 2013-08-07 14:59:58 EDT
In reference to comment #2 

Based on my partial openstack install, these appear to be auxiliary uid/gids.

mysql:x:27:27:MySQL Server:/var/lib/mysql:/bin/bash
qpidd:x:498:499:Owner of Qpidd Daemons:/var/lib/qpidd:/sbin/nologin
memcached:x:497:496:Memcached daemon:/var/run/memcached:/sbin/nologin
nagios:x:496:495::/var/spool/nagios:/sbin/nologin

So just because they don't belong to a core daemon I'm not sure that we should exclude them from being pulled in based on the openstack installation.
Comment 7 Stephen Gordon 2013-08-07 15:16:49 EDT
(In reply to Dave Sullivan from comment #6)
> In reference to comment #2 
> 
> Based on my partial openstack install, these appear to be auxiliary uid/gids.
> 
> mysql:x:27:27:MySQL Server:/var/lib/mysql:/bin/bash
> qpidd:x:498:499:Owner of Qpidd Daemons:/var/lib/qpidd:/sbin/nologin
> memcached:x:497:496:Memcached daemon:/var/run/memcached:/sbin/nologin
> nagios:x:496:495::/var/spool/nagios:/sbin/nologin
> 
> So just because they don't belong to a core daemon I'm not sure that we
> should exclude them from being pulled in based on the openstack installation.

In comment # 2 I indicated that as mysql, qpidd, and memcached(?) are shipped in base-RHEL their UID/GID reservations should be documented in the platform documentation so that it can be referenced by all layered products that use them, not just OpenStack.

I also specifically singled out the nagios reference as something we would have to carry downstream, not as something being excluded.
Comment 14 Summer Long 2013-08-07 19:23:34 EDT
Have sent off a request to Tom Fifield, to see whether we can put these in the Config Guide.
Comment 16 Summer Long 2013-10-11 02:44:58 EDT
Nermina was going to put this in (Aug.9), have emailed her to see where it ended up. Can't find it myself.
Comment 17 Summer Long 2013-10-14 20:36:32 EDT
Raised with explicit info: https://bugs.launchpad.net/openstack-manuals/+bug/1239879
Nermina will be putting in getstart.xml, included in both the admin and end user guides.
Comment 24 Summer Long 2013-12-17 00:24:29 EST
Thx, good catch. Fixed. Waiting for package on test server to move to QE.
Comment 25 Dave Sullivan 2014-09-22 09:49:09 EDT
looks good clearing needinfo

Note You need to log in before you can comment on or make changes to this bug.