Hi,
As part of 1, we want to add a new GID for all openstack-neutron installations. Openstack is constructed of several projects like Nova, Glance, Keystone - all of which have GIDs assigned to them in the 160-170 range.
Having a set GID across computers will help our clients set up LDAP for their setups.
Best Regards, John Schwarz.
We discussed this at today's meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-03-12/fpc.2015-03-12-17.00.txt):
We've requested further information from our client. He says:
First is consistency with the rest of openstack components (see description above). But on a more technical aspect, the main need is to provide consistency among installations and even among systems of the same deployment. The resulting GID depends on the installation. So either you create it beforehand or risk having a different GID if you happen to install something that creates a user/group. This makes things more complicated if you have centralized file systems such as authentication or NFS. Having a predefined GID results on more predictable systems.
First is consistency with the rest of openstack components (see description above).
But on a more technical aspect, the main need is to provide consistency among installations and even among systems of the same deployment. The resulting GID depends on the installation. So either you create it beforehand or risk having a different GID if you happen to install something that creates a user/group. This makes things more complicated if you have centralized file systems such as authentication or NFS.
Having a predefined GID results on more predictable systems.
The reason this is important for us is that OpenStack is a cloud project, meaning clients can choose to install it on many machines as part of a single deployment. In case one of the machines have a slightly different configuration and the GID other machines assigned 'neutron' is taken, this will create the aforementioned problems.
We hope you'll reconsider this request.
Best regards, John Schwarz.
This didn't get on this week's agenda, but if I understand the requirements, what's really needed here is some defined method for fixing or preallocating UIDs early in the system install, so that by the time that the packages come in the UIDs are already allocated.
I'm trying to come up with something now, because this has been bugging me for six or seven years now. What I do personally is a two-phase bringup, where additional packages are installed immediately after the system reboots into the installed OS.
In the rpm-ostree project this issue is a lot more important as we do binary replication, so we support this on the compose server side: See https://github.com/projectatomic/rpm-ostree/pull/56 and the check-passwd entry here: https://github.com/projectatomic/rpm-ostree/blob/master/doc/treefile.md
check-passwd
I'll also link to an in progress Anaconda PR to help enable this for traditional packaging: https://github.com/rhinstaller/anaconda/pull/80
That pull went in and will be in F23 as I understand things. The setup package maintainer is at least open to doing something like this, but I need to learn enough lua to make it work. And double check that setup %post is early enough. (Obviously setup %pre is too early and %posttrans is way too late, so I sure hope that %post is OK.)
Life would be so much simpler if we had /etc/passwd.d, but I'm sure that would break the world.
We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-07-09/fpc.2015-07-09-16.00.txt):
...tibbs still wants to work on his code to make this easier for dynamic ids though.
I'm just going to close this. I continue to play with this now that there's a Fedora release that supports the necessary kickstart hook, but there's no point in keeping an unrelated ticket open for it.
Metadata Update from @jschwarz: - Issue assigned to james
Login to comment on this ticket.