[openstack-dev] [TripleO] a need to assert user ownership in preserved state
clint at fewbar.com
Thu Oct 2 01:50:33 UTC 2014
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
* 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.
So, what do people think?
More information about the OpenStack-dev