Open Stack

> -----Original Message-----
> From: Clint Byrum [mailto:clint at fewbar.com]
> Sent: 02 October 2014 15:16
> To: openstack-dev
> Subject: Re: [openstack-dev] [TripleO] a need to assert user ownership
> in preserved state
> 
> Excerpts from Gregory Haynes's message of 2014-10-01 19:09:38 -0700:
> > 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!
> >
> 
> Indeed, the Helion dev team discovered this one whilst working on
> updating between alternating builds that added or removed some services.
> 
> Oh, I forgot to mention the bug reference:
> 
> https://bugs.launchpad.net/tripleo/+bug/1374626
> 
> > >
> > > 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 do like this approach, and it isn't one I had considered. We will know
> what image we want to update from in nearly every situation. Also this
> supports another case, which is rolling back to the previous image,
> quite well.
> 
> Really this is just an automated form of static UID assignment.

So for situations where images are built and then distributed 2 things would need to happen:
    1. Identify new users and add them to the passswd file.
    2. Modify ownership of files in the new image whose owners UID have changed, as per my previous mail.

> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Thanks, 
Jon-Paul Sullivan ☺ Cloud Services - @hpcloud

Postal Address: Hewlett-Packard Galway Limited, Ballybrit Business Park, Galway.
Registered Office: Hewlett-Packard Galway Limited, 63-74 Sir John Rogerson's Quay, Dublin 2. 
Registered Number: 361933
 
The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error you should delete it from your system immediately and advise the sender.

To any recipient of this message within HP, unless otherwise stated, you should consider this message and attachments as "HP CONFIDENTIAL".