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.