Starting user UIDs at 1000 - please check your packages

[Ric Wheeler]

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 at redhat.com>    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