Open Stack

Excerpts from Sullivan, Jon Paul's message of 2014-10-02 02:08:26 -0700:
> > -----Original Message-----
> > From: Clint Byrum [mailto:clint at 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.