On Wed, Aug 19, 2015 at 10:19 AM, David Sommerseth
<[log in to unmask]> wrote:
> On 19/08/15 15:32, Chris Schanzle wrote:
>> On 08/19/2015 09:07 AM, David Sommerseth wrote:
>>> On 19/08/15 14:51, Chris Schanzle wrote:
>>> [...snip...]
>>>> >I wouldn't imagine migrating to the new scheme would be*that*
>>>> difficult
>>>> >once you nail down the user, old uid, new uid, change their passwd uid,
>>>> >then run something like this on all your systems: find PATHS -user
>>>> >$oldID -exec chown -h $newID {} +
>>> I've done this a few times.  Basically my routine was:
>>>
>>> ---------------------------------------------------------------
>>>   for d in /home /var /tmp;  # See note below
>>>   do
>>>      find $d -uid ${OLD_UID} -exec chown -ch ${NEW_UID} {} \;
>>>      find $d -gid ${OLD_GID} -exec chgrp -ch ${NEW_GID} {} \;
>>>   done;
>>
>> That's fine, but there's no need for the loop -- just put all the paths
>> right after "find".  And by using the + operator, you don't fork
>> chown/chgrp for every file.
>
> Cool, thanks a lot!  I didn't know about the + syntax.
>
> The reason I used a for loop was actually more for readability when I
> did the uid/gid split.  Performance wise, it might be better to gather
> them all in a single 'find' call, especially when using +.
>
>> If you're changing GID's too, separating out the GID search/reset is a
>> good idea to ensure you get all the GID's (not just those matching a UID
>> and using chown -h ${NEW_UID}:${NEW_GID}, which could result in
>> unexpected GID changes.
>
> Yeah, did that mistake on the first box I switched.  Luckily enough for
> me, it was a small file system with not too many files.

Also, I'd encourage adding the "-xdev" option, to avoid descending
"/proc" or "/sys" and mucking up live processes that may be running
with the old uid. It can also get nightmarish if anything is mounted
via NFS, if you fail to use the "-xdev" option.