Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'rsync vs. rdist' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
rsync vs. rdist
Authored by: themostbob on Sep 29, '03 12:50:03PM
This is an old debate, though not that hotly contested: clicky

Rsync's most direct ancestors are the suite of "r" utilities—rlogin, rsh, and rdist. These command-line programs are most famous for being serious security holes. Fortunately, the holes have been plugged on most modern Unix distributions. But using rdist—rsync's closest relativeis still potentially risky. Once you've opened up rdist, you've opened up all the other "r" commands for every user on that system.

Why take the risk? Rsync can run as a secure, stand-alone server, and that reduces the possibility of compromising your password file. Rsync is also quicker than rdist. The rsync protocol transfers only the differences between two sets of files, so if you have a multimegabyte content tree, the entire tree won't need to be transferred each time you update.

And rsync's already installed.

[ Reply to This | # ]
rsync vs. rdist
Authored by: HobartJ on Sep 30, '03 08:25:18AM

rdist does "push" while rsync does "pull". Both are useful.

(Yes, you can push with rsync, but not to many machines at once.)

Rdist can use ssh as the transport protocol, so it is no longer true
that opening up for rdist opens up the old 'r' commands.

It's true that rsync is more efficient. But rdist allows any transport
program that takes the right command line arguments, so it might
even be possible to do rdist via rsync (a wrapper might be required).



[ Reply to This | # ]
rsync vs. rdist
Authored by: Fil Machi on Sep 30, '03 08:24:28PM

A little warning. The the article referenced above (clicky), gives a flawed method for creating a lock file to prevent two or more instances of rsync from running simulateously, "to avoid data corruption" according to the author.

That method only works some of the time. In other words, it depends on a race condition and so can result in two or more instances of rsync running simultaneously, exactly what the author of that script was trying to avoid.

In fact, Listing 3 of that article is a good example of how NOT to do file locking using files.

The race condition is in this code (taken from the article):

if [ -f $LOCK ]; then
        echo "Rsync failed on ${SYSTEM} -- lock in place."
        exit
fi

touch $LOCK
rsync -r --delete $SOURCE $DEST

There is no way to ensure that after testing for the existence of the lock file (-f $LOCK), the same instance of the script will get to immediately create the lock file (touch $LOCK). The OS is free to switch to another instance of the same script that someone else (or cron) may have started at about the same time. This second instance could get to test and create the lock file before the OS resumes the first instance. When the first script resumes, it will blindly continue where it left off and create the lock file, regardless of whether it was just created by the second instance. Both instances would believe they own the lock and both would go on to run the rsync command.

Better to use a locking method based on an atomic filesystem operation such as creating a hard link. Just a heads up to the unsuspecting.



[ Reply to This | # ]