Hi, Until now we have been using rsync with SSH for copying data across different sites. They are bundled within wrappers and are circulated thru' cronjobs. All the sites exchange data in this way. It is working fine in all the sites, but except for 1 site. It transfers the files fine, but it changes the permissions on the files. It does'nt retain it as per the source nor as per the umask setting of the destination. Curiously, whatever be the file permission it masks the group and users to 00 and retains the perm for owner. For ex: If the source has perm 555, when it reaches the destination in question, it becomes 500. If the source has perm 755, when it reaches destination in question, it becomes 700. However, If we add the -p bit to rsync, it's retaining the permissions. But the question is, Till now it was working fine. And, this is happening to only one hosts among a list of 10 hosts. The command we are using is; =============================================================== rsync --inplace --partial --no-whole-file --rsync-path="/usr/bin/rsync" -e ssh "/localhome/adm/rsync.test" "msctrans@hostname:/tmp/rsync.test" -vvv option o/p: opening connection using ssh <hostname> -l msctrans /usr/bin/rsync --server -vvv --inplace . mscdir/receive/1.SSH [sender] make_file(1.SSH,*,2) server_recv(2) starting pid=1424 send_file_list done send_files starting recv_file_name(1.SSH) received 1 names recv_file_list done get_local_name count=1 mscdir/receive/1.SSH recv_files(1) starting generator starting pid=1424 count=1 delta-transmission enabled recv_generator(mscdir/receive/1.SSH,0) send_files(0, /var/opt/ei/msc/transmit/1.SSH) send_files mapped /var/opt/ei/msc/transmit/1.SSH of size 0 calling match_sums /var/opt/ei/msc/transmit/1.SSH 1.SSH sending file_sum false_alarms=0 tag_hits=0 matches=0 sender finished /var/opt/ei/msc/transmit/1.SSH generate_files phase=1 send_files phase=1 recv_files(mscdir/receive/1.SSH) got file_sum finishing mscdir/receive/1.SSH recv_files phase=1 generate_files phase=2 send_files phase=2 send files finished total: matches=0 tag_hits=0 false_alarms=0 data=0 recv_files phase=2 generate_files phase=3 recv_files finished generate_files finished sent 82 bytes received 42 bytes 22.55 bytes/sec total size is 0 speedup is 0.00 _exit_cleanup(code=0, file=main.c, line=789): about to ca =========================================================== If I use -p or -a it works fine. But I want to know, what was working all this time is not working now and it involves to be changed across different sites. It would be of great help, if any of you can guide me thru' this. Thanks in Advance, Vasuamthi -------------- next part -------------- HTML attachment scrubbed and removed
On Fri, 2007-12-07 at 12:35 +0530, vasumg@gmail.com wrote:> Curiously, whatever be the file permission it masks the group and > users to 00 and retains the perm for owner.> However, If we add the -p bit to rsync, it's retaining the > permissions.This is strong evidence that the umask seen by the receiving rsync process may not be what you expect. To find out what the umask is, run something like: ssh mcstrans@hostname umask It might also be helpful to strace the receiving rsync by passing --rsync-path="strace -f -o /tmp/rsync.log rsync" . Matt
On Tue, 2007-12-11 at 20:45 +0530, vasumg@gmail.com wrote:> Yes Exactly. > When I give; > > $ ssh mcstrans@hostname umask > 077 > Which explains my problem. > > Is this taking from /etc/profile?. B'cos under ~msctrans/.profile, the > umask is set to 022. > > How do I by-pass and tell rsync to not to take from /etc/profile. > Our admin team is not ready to chage the umask to 022 in /etc/profile > for security reasons.When you launch rsync on the local machine, the remote sshd runs the remote user's shell (defined in /etc/passwd) and passes it the rsync server command line. Which startup files (if any) take effect is under the control of this shell, not rsync. If you are using bash, its somewhat complex startup file behavior is documented in the bash(1) man page. In any case, you can override the umask specifically for the remote rsync by passing --rsync-path='umask 0022 && rsync' . Assuming that the filesystem and the installed rsync on "hostname" both support POSIX ACLs, an alternative way to specify that new destination files should get 644/755 permissions is to set a default ACL of 755 on the destination. Matt
On Sun, 2007-12-16 at 06:00 +0530, vasumg@gmail.com wrote:> Thanks for your advise on using ACL's. > Since the rsync command is embedded within a wrapper, if I have to > change the command, I will have to rebuild the entire package and > install the new package on all the related servers. > To avoid this, I plan to use ACL's on the destination machine as an > alternative. > We use vxfs filesystem on a HP_UX 11.11 machine.I've only used ACLs with rsync on Linux, so I can't vouch that it will work on HP-UX, but it's worth a try. First, note that the ACLs will only have an effect if the copy of rsync installed on "hostname" supports ACLs. To test your current copy of rsync, run: ssh mcstrans@hostname /usr/bin/rsync --version and look for "ACLs" in the list of capabilities. Recent development versions of rsync 3.0.0 support ACLs (though you should be wary of using them on a production system), and the source packages of older versions of rsync come with a patch "patches/acls.diff" to add ACL support. It may turn out that installing the necessary copy of rsync on "hostname" to recognize the ACLs is just as much work as modifying the rsync script to override the umask. But if you do want to use ACLs, read on:> How do I set the acls' on a top-level directory.. > Any file created within this dir should have 644 permission. > How do I do this. Does it have any side-effects of which I should be > careful about. > I donot have much exp on setting acl and since this is a major > production machine I cannot take chances.It looks like the HP-UX command to set ACLs is setacl . To have new files created with mode 644 and new subdirectories created with mode 755, you should set a default ACL of 755. A directory's default ACL affects only new files immediately in that directory, so you need to set the default ACL of the destination and all existing subdirectories inside it (new subdirectories will inherit the default ACL when they are created). To do this, run the following command as user mcstrans on "hostname": find /tmp/rsync.test -type d -exec setacl -m d:u::7,d:g::5,d:c::5,d:o::5 {} + See the setacl(1) man page for more information. I strongly encourage you to make another directory on the destination host to test that you can set its default ACLs and that rsync observes them when copying files into that directory before you mess with the real destination. Matt