5

I found an article online that gives instructions on how to backup your dedicated server using rsync.

In one of the steps of this article I am supposed to create a user called "rsync" and add sudo privileges to it. Everything is going well but the visudo options for the "rsync" user are pretty hard to understand. Some of the options for the "/usr/bin/rsync" command have virtually no documentation on the Internet.

Following is the visudo line that I am referring to:

rsync ALL=(ALL) NOPASSWD: /usr/bin/rsync --server --sender -logDtprze.iLsf --numeric-ids . /

To begin with, I kind of understand the "--server --sender" properties. What is really bugging me is the option "-logDtprze.iLsf".

I have a CentOS server and this option is not available in the rsync documentation when I run the command "man rsync". Actually, every time I try to use this option in visudo, nothing works.

I eventually found a vague reference to "-logDtprze.iLsf" as being a new feature of rsync in Debian. I am not sure about that.

I just wanted to know what this option does and if it will be OK to ignore it in my backup set up.

I also wanted to understand the purpose of the period & slash at the end of the line ". /"

EDIT: Thanks bodgit! I feel like an idiot! :)

4 Answers 4

6

It's the short options -l, -o, -g, -D, etc. which instead of spelling them out separately can be collapsed which is standard behaviour for most Unix tools, i.e. rm -rf is the same as rm -r -f.

4
  • Thanks for the help! bodgit! I feel like an idiot. What threw me off was the period "." in the middle of the parameters. The whole thing looked like the name of a file with the file extension being ".iLsf". Aug 3, 2016 at 18:32
  • 1
    By the way, do you know the function of the period "." in the middle of this sequence of parameters? Aug 3, 2016 at 18:33
  • 1
    The -e and -f options both expect a value. I can't speak for the rsync option parsing but I'd assume it would see -....e.iLsf and take .iLsf as the value of the -e option which is almost certainly not what you want. Incidentally you can also simplify the options and use -a which is equivalent to -logDtpr.
    – bodgit
    Aug 5, 2016 at 16:20
  • Hi, Bodgit! Thank you very much for coming back and answering my second question. That was really helpful. Aug 10, 2016 at 21:55
4

I did a little investigation and found the meaning for each letter in the sequence of parameters "-logDtprze.iLsf"

-l, --links                 copy symlinks as symlinks
-o, --owner                 preserve owner (super-user only)
-g, --group                 preserve group
-D, --devices               transfer character and block device files
-t, --times                 preserve modification times
-p, --perms                 preserve permissions
-r, --recursive             copy directories recursively
-z, --compress              compresses data as it is sent to the destination
-e, --rsh=COMMAND           allows to choose an alternative remote shell program
.
-i, --itemize-changes       show list of changes being made to each file
-L, --copy-links            transform symlink into referent file/dir
-s, --protect-args          no space-splitting; wildcard chars only
-f, --filter=RULE           allows to add rules to exclude certain files

The only thing I have not been able to understand is the meaning of the period "." in the middle of the parameters.

3

As pointed out in other comments, -logDtprze.iLsf is a combination of short options, but the subtlety lies around the -e. part. Because -e expects an argument, everything after it is the value for the -e option. This is a common behavior for Unix commands short options, and we can confirm this behavior by looking at popt(3) POPT_ARG_STRING (the library rsync uses to parse options). So it's equivalent to:

-l -o -g -D -t -p -r -z -e '.iLsf'

While -e is documented on the rsync client as the short version of --rsh "specify the remote shell to use", .iLsf doesn't make much sense as a remote shell. The -e option is actually hijacked by the internal rsync client/server protocol to pass compatibility flags instead: https://github.com/WayneD/rsync/blob/13c4019e94015b234697c75d9d3624862e962d3c/compat.c#L160

You can see the source code of how this is constructed here, in the maybe_add_e_option function in options.c: https://github.com/WayneD/rsync/blob/f44e76b65c5819edb1a5b2fbbe732d5d214b35de/options.c#L2951

And it's parsed in compat.c: https://github.com/WayneD/rsync/blob/13c4019e94015b234697c75d9d3624862e962d3c/compat.c#L134

.iLsf means that:

  • .: rsync is using a final version of the protocol. If it was using a pre-release (where SUBPROTOCOL_VERSION != 0), it would send <PROTOCOL_VERSION>.<SUBPROTOCOL_VERSION> instead of just .

Then it's followed by a number of behavior flags known as client_info in compat.c:

  • i: allow_inc_recurse
  • L: symlink time-setting support
  • s: symlink iconv translation support
  • f: flist I/O-error safety support
2

you have stumbled apon a fairly complex interaction between several parts of an RSYNC over SSH session.

While the other answers here give some insight into the rsync options, those options may not necessarily apply to your particular situation which may be unique depending on the options you are sending to rsync.

So, no, it's not OK to ignore these options as they may be quite different for your case.

The real key to this apparently strange set of rsync options is to capture the actual command being sent in your particular case.

There's at least a couple of ways to do that. One way is to rsync backup of a file big enough to take say 20 seconds to transfer, to give a chance to inspect running processes on the remote machine during the transfer, e.g., a command such as:

rsync -a -e "ssh -i /Users/myuser/keys/id_test -l test" 192.168.1.101:/home/test/100m.txt /Users/myuser/100m.txt

where /home/test/100m.txt is a large enough file to take long enough to have time to view the process while it is transferring.

To see the actual command being used by rsync over ssh, have a separate terminal window logged on to the remote machine and do

ps auxww|grep rsync

while the file is transferring. In my case doing the above gave:

# ps auxww|grep rsync
test     3860  7.5  0.0  13520  2780 ?        Ss   18:49   0:00 rsync --server --sender -logDtpr . /home/test/100m.txt
root      3862  0.0  0.0  12784   968 pts/0    S+   18:49   0:00 grep rsync

this then gives insight into where all those rsync command options came from, in my case "logDtpr" from doing "rsync -a", YMMV.

Another way to find the command being sent is to use the environment variable SSH_ORIGINAL_COMMAND, from man SSH:

SSH_ORIGINAL_COMMAND  This variable contains the original command line if a forced command is executed.  It can be used to extract the original arguments.

you can then use the authorized_keys options (see the AUTHORIZED_KEYS FILE FORMAT entry in man SSHD) to add a forced command "command=myscript" to the key being used to logon on the remote server and make that command be a shell script "myscript" which has a couple of lines in it like:

echo "$SSH_ORIGINAL_COMMAND" >> /fullpathto/mysshlog
exec $SSH_ORIGINAL_COMMAND   

then when you run your rsync the actual command used will end up in the log file "mysshlog"

You can see from the command found in first example above that for your case the trailing / would be the source path of the rsync files to be copied.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.