Excerpts from Sullivan, Jon Paul's message of 2014-10-02 02:08:26 -0700: > > -----Original Message----- > > From: Clint Byrum [mailto:cl...@fewbar.com] > > Sent: 02 October 2014 02:51 > > To: openstack-dev > > Subject: [openstack-dev] [TripleO] a need to assert user ownership in > > preserved state > > > > Recently we've been testing image based updates using TripleO, and we've > > run into an interesting conundrum. > > > > Currently, our image build scripts create a user per service for the > > image. We don't, at this time, assert a UID, so it could get any UID in > > the /etc/passwd database of the image. > > > > However, if we add a service that happens to have its users created > > before a previously existing service, the UID's shift by one. When this > > new image is deployed, the username might be 'ceilometer', but > > /mnt/state/var/lib/ceilometer is now owned by 'cinder'. > > > > Here are 3 approaches, which are not mutually exclusive to one another. > > There are likely others, and I'd be interested in hearing your ideas. > > > > * Static UID's for all state-preserving services. Basically we'd just > > allocate these UID's from a static pool and those are always the UIDs > > no matter what. This is the simplest solution, but does not help > > anybody who is already looking to update a TripleO cloud. Also, this > > would cause problems if TripleO wants to merge with any existing > > system that might also want to use similar UID's. This also provides > > no guard against non-static UID's storing things on the state > > partition. > > > > * Fix the UID's on image update. We can backup /etc/passwd and > > /etc/group to /mnt/state, and on bootup we can diff the two, and any > > UIDs that changed can be migrated. This could be very costly if the > > swift storage UID changed, with millions of files present on the > > system. This merge process is also not atomic and may not be > > reversible, so it is a bit scary to automate this. > > > > * Assert ownership when registering state path. We could have any > > state-preserving elements register their desire for any important > > globs for the state drive to be owned by a particular symbolic > > username. This is just a different, more manual way to fix the UID's > > and carries the same cons. > > For these last two cases, of fixing the file ownership on first boot based on > the previous UIDs of a username, why would we decide to fix the data files? > > If instead we were to change the UIDs such that the data files were correct, > the only thing to fix up would be the installed files in the image, which are > a well-defined and limited set of files. >
Great point JP! I think that this is similar to Greg's suggestion of copying the uid/gid database into the image. If we copy it in before the image is built, we "fix" the image by building it right in the first place. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
