Open Stack

Excerpts from Clint Byrum's message of 2014-10-02 01:50:33 +0000:
> 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'.

Wow, nice find!

> 
> 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.

+1 for this approach for the reasons mentioned.

> 
> * 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.

If we really want to go with this type of aproach we could also just
copy the existing /etc/passwd into the image thats being built. Then
when users are added they should be added in after existing users.

I still prefer the first solution, though.

> 
> * 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?
>