Excerpts from James Polley's message of 2014-10-02 05:37:25 +0000: > All three of the options presented here seem to assume that UIDs will always > be allocated at image-build time. I think that's because most of these UIDs > will be used to write files into the chroot at image-create time - if I could > think of some way around that, I think we could avoid this problem more > neatly by not assigning the UIDs until first boot > > But since we can't do that, would it be possible to compromise by having the > UIDs read in from heat metadata, and using the current allocation process if > none is provided? > > This should allow people who prefer to have static UIDs to have simple > drop-in config, but also allow people who want to dynamically read from > existing images to scrape the details and then drop them in. > > To aid people who have existing images, perhaps we could provide a small tool > (if one doesn't already exist) that simply reads /etc/passwd and returns a > JSON username:uid map, to be added into the heat local environment when > building the next image? >
What I was suggesting before as an alternate solution is a more simple version of this - just copy the existing /etc/passwd and friends into the chroot at the start of building a new image. This should cause new users to be created in a safe way. IMO I like the uid pinning better as a solution, though. Cheers, Greg _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
