On 2/16/19 12:14 PM, Bill Gee wrote:
...After the usermod programs ran, I then did a "find -uid=500" with an exec
option to change ownership. Repeat for changing GID. It found a few dozen files that
were not in my home directory.
On the server I ran the two "find" commands against the entire file system. It
took about half an hour to run. No surprise there as it was finding and changing several
hundred thousand files. I ran the uid change in one terminal and the gid change in
another. Between the two of them they consumed about 90% on both processor cores.
Hi Bill,
Just sharing some wisdom/experience. Too bad it's after the bulk of your work.
:-)
It should not have been consuming much cpu. This is an I/O-based activity.
My guess is you used something like
find -uid=500 -exec chown 1000 {} \;
This will start a chown process for each file, changing only one file at a
time. That's a lot of work the system has to do for each file! But you
probably know chown (and similar utilities) can take multiple file arguments,
and 'find' can help you take advantage grouping many arguments with the '+'
operator to -exec:
find -uid=500 -exec chown 1000 {} +
And you could combine the bulk of your I/O work of chgrp-ing for all of your
files at the same time by using 'chown 1000:1000'.
You might want to check your symlinks ('find -type l -ls'). You may have
changed the ownership of what they point to rather than the link itself,
precisely what the chown -h (--no-dereference) option is good for. Don't
forget to revisit what the permissions should be on the link targets. Bad
things would happen if the user had a symlink to /etc/passwd and/or /etc/shadow
in their home directory!
I also like to use -xdev to avoid traversing into any unexpected filesystems.
So I end up with:
find /somedir -xdev -uid=500 -exec chown -h newID:newGroup {} +
Hope that helps for the next time or someone else!
[This is off the top of my head, so beware of any mistakes...these commands
have significant consequences.]
Best regards,
Chris Schanzle
_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
