On 12/10/12 8:37 PM, Howard Bampton wrote:
> On Mon, Dec 10, 2012 at 6:55 PM, Todd D. Taft <[email protected]> wrote:
>> Thanks to a reorganization, I have to move about 50 Linux systems from the
>> LDAP server run by one group to the LDAP server run by a different group.
>> In most cases, the UIDs (uidNumber) and GIDs (gidNumber) for a given user or
>> group don't match between the systems. Since most files are accessed via
>> local filesystems or NFS, I think I will need to renumber the ownership of
>> all of the files on these systems. Are there any tools/utilities available
>> (or hints from people who have done similar projects) that make this process
>> less painful and go faster?
>
> If you are doing one user at a time, try something like this (GNU
> find/xargs required):
>
> find /path/to/fix -user olduid -print0 | xargs -0 chown -h newuid
I've been doing UID & GID migrations to move from flat files to LDAP
recently. I find that using --from=OldUID:OldGID is an excellent way to
help prevent shooting oneself in the foot. This is especially true when
one of the owner/group may be a system account/group, while the other
owner/group is an individual. It makes the -R option safe:
chown -Rh --from:OldUID:OldGID NewUID:NewGID /home/alice /local/scripts
(chown should always be followed by -h, of course)
Check for files with OldUID or OldGID after that change, and you may
find some things that need to be fixed, like a script owned
bob:dba
where Bob is not a DBA, or
root:alice
where you just wonder who failed to specify root:root when they chown'ed
it last. >8^)
Also, be sure to check your UID/GID To and From lists, so that if you
have a case of:
User OldUID NewUID
Alice 1234 5678
Bob 5678 9012
you change Bob's files first, so that Alice's files aren't changed to
Bob's OldUID, and then changed along with his files to Bob's NewUID.
We went one user at a time, which walks the file tree more than once but
prevents race conditions on UID/GID number re-use.
> Reasonably efficient (and won't churn out processes for each file).
> Walks the filesystem once per user.
>
> If you are doing all users at once, then you need an ugly find (I
> don't recall the precise syntax) that does something like this:
> find /path/to/fix \( -user olduid -exec chown -h newuid \) -o \( -user
> olduid#2 -exec chown -h newuid#2)
>
> Walks the filesystem once, beats the heck out of the process table
> (one exec per file).
>
> Make sure to do chown -h, not just chown lest someone have a sym link
> from the place you are walking to /etc/shadow (or less sensitive but
> still annoying places). It looks like GNU chown doesn't break stuff
> and this may not be needed there.
>
> My experience with this is ~10 years ago with Solaris and ufs. The
> process was unpleasant. I took some shortcuts since 99% of the files
> under a user's top level directory were owned by them I could do the
> first style finds at that level and get most of the filesystem cleaned
> up fairly quickly.
>
> We had quotas set on the filesystem (with values larger than the
> filesystem size) so we could keep an eye on how much space each person
> used. This helped a bit with the process- tracking down stray files
> that were missed and now were unowned (our uid's went from 4-5 digits
> to 7+ (employee id) which made this easy).
>
> Do watch out for problems if there are possible conflicts and look for
> them first if you can (i.e. uid 1234 should be 2345, but existing 2345
> should be 3456).
>
> Some apps (Clearcase comes to mind) do NOT like uid changes. Look out
> for this too.
>
> We didn't have to do gids, but the process should be similar.
_______________________________________________
Tech mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
