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? > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
