Re: [atomic-devel] Consiering a host UID/GID upgrade discontinuity (breaking CentOS7 Atomic and F22)

[Jason Brooks <jbrooks redhat com>]

----- Original Message -----
> From: "Colin Walters" <walters verbum org>
> To: atomic-devel projectatomic io
> Sent: Thursday, April 30, 2015 9:50:27 AM
> Subject: [atomic-devel] Consiering a host UID/GID upgrade discontinuity (breaking CentOS7 Atomic and F22)
> 
> I posted before about uids/gids:
> 
> https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2015-January/msg00008.html
> 
> OSTree (like Docker) ships numeric uid/gids - the way I think of this, the
> binaries
> have "fixated" on a particular name -> uid mapping.
> 
>  rpm-ostree grew infrastructure to ensure the fixation remains constant, we
>  don't yet have
> an equivalent for this for either
>  - The Docker base image, which is built using Anaconda in ImageFactory in
>  Koji;
>    see https://github.com/rhinstaller/anaconda/pull/80#issuecomment-94834420
>  - Dockerfiles invoking yum; It is however not too hard to populate
>  /etc/passwd by hand
>    similar to the above
> 
> Anyways on to the actual topic of this post - recently Ian McLeod did some
> work
> to extract the metadata for a downstream rebuild for CentOS that has the
> uids used in Red Hat Enterprise Linux Atomic Host:
> https://github.com/CentOS/sig-atomic-buildscripts/blob/downstream/passwd
> 
> I'd like to propose using these for both CentOS 7 Atomic and F22 Atomic Host.
> It would break upgrades for CentOS, and F21 -> F22 - but since F22 isn't
> released yet, it's better to do this now.

+1 from me

Jason



> 
> # Cleanly terminating the current CentOS release
> 
> I can do a special build of into the current branch which would do something
> like this:
> 
> $ atomic host upgrade
> Checking for updates:
> error: There are no more updates to this branch; see
> http://wiki.centos.org/SpecialInterestGroup/Atomic/UpgradeDiscontinuity
> 
> And basically the wiki would describe how you'd need to reinstall.
> 
> There are actually OSTree-level tricks we could do to avoid reinstallation,
> but if things like the `ssh_keys` group changes it's a bit tricky.
> 
>