Replicating a tree with root permissions
daniel.rawson at asml.com
Thu Jan 18 17:55:16 GMT 2007
We have a large (20Gb, 250000 files) tree which needs to replicate across our WAN on a regular basis. We have been using a wrapper script around rsync to do this; the wrapper script runs setuid-root on a Solaris 8 server. However, we have on-going problems with files whose permissions don't replicate correctly. These file permissions are the REAL problem; if the permissions aren't correct, the tree isn't useful.
Current rsync command-line:
rsync -e rsh --stats --delete -avz --ignore-errors --blocking-io --exclude-from="exclude.list" --rsync-path="rsync_path" remote_host:/my/source/dir /my/source
The most recent failure involves files which are owned by root; if I run the setuid wrapper script from a user account, the permissions are not updated; if I run the setuid script as root (and change the command line to add "user at remote_host), then the permissions get updated.
Note that there are other files in the tree which are owned by root which replicate correctly!!!
- rsync v2.6.6 at both sites.
- Solaris 8 at both sites.
- The entire WAN is one Solaris NIS domain, so the user names / uid's match on both sides.
- We are NOT able to leave the rsync daemon running at either end. . . .:-(
- The tree contains files belonging to MANY different users, including root. It also includes setuid scripts which SHOULD be replicated with the setuid bits intact.
- The entire tree is NFS mounted at both sites from a NetApp file server.
- If I run with "-n -i", it clearly shows that the file permissions will not be updated when a regular user starts the script, but WILL be updated if the script is run by root.
What is the most reliable way to replicate this tree and retain the permissions on the "target" site?
The information contained in this communication and any attachments is confidential
and may be privileged, and is for the sole use of the intended recipient(s). Any
unauthorized review, use, disclosure or distribution is prohibited. If you are not
the intended recipient, please notify the sender immediately by replying to this
message and destroy all copies of this message and any attachments. ASML is neither
liable for the proper and complete transmission of the information contained in this
communication, nor for any delay in its receipt.
More information about the rsync