On 07/20/2011 02:06 PM, Simo Sorce wrote: > On Wed, 2011-07-20 at 13:52 -0400, Ric Wheeler wrote: >> On 07/20/2011 01:19 PM, Simo Sorce wrote: >>> On Wed, 2011-07-20 at 12:29 -0400, Ric Wheeler wrote: >>>> On 07/20/2011 12:28 PM, Miloslav Trmač wrote: >>>>> On Wed, Jul 20, 2011 at 6:24 PM, Ric Wheeler<rwheeler@xxxxxxxxxx> wrote: >>>>>> I normally build systems with (at least!) a separate /boot, / and /home. >>>>>> This lets me do a full install, blow away old fedora system partitions and >>>>>> not lose any user data. >>>>>> >>>>>> Since that puts down a pristine F16 image, does that mean we need to chown >>>>>> all of the user files that survive in a separate partition? >>>>> Either chown the files, or create a kickstart file that puts >>>>> /etc/login.defs in place in a %pre script. chown is probably much >>>>> simpler unless you have many systems to manage. >>>>> Mirek >>>> Makes sense... >>>> >>>> We should also note that this might be a common need for users who have SAN >>>> attached storage (and that could be large, multi-user systems). >>> If they don't already have a directory or at the very least a way to >>> rsync /etc/passwd around they do not have a production grade >>> installation. >>> >>> If they already have shared user information this change shouldn't make >>> much of a difference to them unless they want to change existing user >>> Ids. >>> >>> Simo. >>> >> With SAN attached storage (or just the clean install example I gave earlier in >> the thread), the install will have existing user ID's but their /etc/password >> (and so on) will get nuked during the install which could/will re-use existing >> user ID's. >> >> rsync won't help since their data is all local already. You will need to "chown" >> the user files to the higher range PID's. > If you nuke /etc/passwd you always need to do that anyway. > If you rely on useradd() to create users with the same ids as before > that's really poor admin practice. > > Simo. Agreed, but that does not mean that we don't need to flag this as something to be aware of :) (In practice, for a laptop/desktop with a couple of users, this has not been a practical issue for most clean install upgrades.) Ric -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
