roger@GW1.AGS.BNL.GOV (Roger A. Katz) (11/19/90)
I am about to merge separate internet registries. I am sure to see numerous examples where
Joe with unix id 150 is on registry A while Ann with unix id 150 is on registry B.
Question:
1. What is the effect on Joe's files when I change his unix id and do nothing else?
2. What does the /etc/syncids program really accomplish?
anyone who has experience in this type of endeavor i would greatly appreciate hearing about it.
addendum to question 1 above: Is there something else I must do? Must i re-acl all of joe's files?
thanks in advance.
----------------------------------------------------------------------
Email: roger@gw1.ags.bnl.gov Roger A. Katz
AGS Software Controls Group
Brookhaven National Laboratory
Upton, N.Y. 11973-5000
(516) 282-2732
I'm sure, I maybe wrong, but I'm sure.krowitz@RICHTER.MIT.EDU (David Krowitz) (11/20/90)
I believe the ACL's are stored as text (ie. "joe.somegroup.someorg") rather than as UID/GID pairs, so that you will not have to re-acl the files ... however, you *will* have to change the ownership of all of his files, since the file's ownership (is* stored as a UID/GID pair. If all of joe's files are stored in one location, this is fairly easy (if time consuming). Just use the "chown -R" command on joe's directory. If the files are scattered about the disk, it gets much harder. ZI suspose you could use the "find" command to search the entire disk for files with a UID of 150 and pipe their names into "chown" to change them to joe's new UID (do this *prior* to merging the registries or you may find some of Ann's files by mistake!). -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
rees@pisa.ifs.umich.edu (Jim Rees) (11/20/90)
In article <9011191504.AA02324@gw1.ags.bnl.gov>, roger@GW1.AGS.BNL.GOV (Roger A. Katz) writes:
I am about to merge separate internet registries. I am sure to see numerous examples where
Joe with unix id 150 is on registry A while Ann with unix id 150 is on registry B.
Question:
1. What is the effect on Joe's files when I change his unix id and do nothing else?
2. What does the /etc/syncids program really accomplish?
One of the really nice advantages of Apollo over other systems is that most
system resources are named internally by UIDs, which are 64 bit numbers
unique for all time. So Joe and Ann are identified by unique numbers in the
registry, and merging two registries is fundamentally no problem.
Unfortunately, we do have to live in the real world, and that means
assigning Unix IDs to Joe and Ann. Unix IDs are at most the size of an int,
and on some systems are only the size of a short, so they can't be unique.
So the registry maintains the Unix ID in addition to the UID.
To get good performance, it's not a good idea to have to go to the registry
every time you stat() a file, so the inode contains the Unix ID in addition
to the UID. The bad news is that this means the file system can get out of
sync with the registry if you change the UID-to-Unix-ID mapping.
That's where syncids comes in. It looks at the real ownership of the file,
which is specified by the UID, and looks up in the registry to find out
today's Unix ID to go with that ownership. Then it sets the Unix ID stored
in the inode to be correct for today's mapping.
The bottom line is that when you find Joe and Ann both have the same Unix
ID, you should re-assign one of them, then when you're all done you should
run syncids over all disks that might contain any files owned by someone
whose Unix ID has changed. That's it. No files actually change ownership
(as far as the kernel is concerned). *** Do not *** chown the files.
The right way to handle this would have been to widen Unix IDs to 64 bits
and make them unique. That's what Aegis tried to do. But as we know, Aegis
lost and Unix won, for reasons having nothing to do with UIDs. So we're
stuck with syncids.pato@apollo.HP.COM (Joe Pato) (11/20/90)
In article <9011191805.AA12801@richter.mit.edu>, krowitz@RICHTER.MIT.EDU (David Krowitz) writes: |> I believe the ACL's are stored as text (ie. "joe.somegroup.someorg") |> rather than as UID/GID pairs, so that you will not have to re-acl the |> files ... however, you *will* have to change the ownership of all |> of his files, since the file's ownership (is* stored as a UID/GID |> pair. If all of joe's files are stored in one location, this is |> fairly easy (if time consuming). Just use the "chown -R" command |> on joe's directory. If the files are scattered about the disk, it |> gets much harder. ZI suspose you could use the "find" command to search |> the entire disk for files with a UID of 150 and pipe their names into |> "chown" to change them to joe's new UID (do this *prior* to merging |> the registries or you may find some of Ann's files by mistake!). |> |> |> -- David Krowitz |> |> krowitz@richter.mit.edu (18.83.0.109) |> krowitz%richter.mit.edu@eddie.mit.edu |> krowitz%richter.mit.edu@mitvma.bitnet |> (in order of decreasing preference) This is essentially all wrong. Refer to Jim Rees' response for a description of what really goes in an acl and the "inode" equivalent (64-bit UIDs) and how to "fix" the unix id "hint" using /etc/syncids. David's advice is close to what you would have to do on a conventional UNIX file system - and it should NOT be followed on a Domain/OS file system. -- Joe Pato Cooperative Object Computing Operation Hewlett-Packard Company pato@apollo.hp.com