Hehe... gotcha. --server and --sender are undocumented because they are
commands used by the initiating rsync to cause the called rsync behave as
a slave. --daemon IS documented well enough, though it's meaningless
unless you also read the (also very good) rsyncd.conf documentation.
The message you were reading was about a special application, not normal
usage.
Tim Conway
tim.conway@philips.com
303.682.4917
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, n9hmg on AIM
perl -e 'print pack(nnnnnnnnnnnn,
19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970),
".\n" '
"There are some who call me.... Tim?"
"Martin A. Brown" <mabrown@securepipe.com>
Sent by: rsync-admin@lists.samba.org
01/24/2002 02:33 PM
To: rsync@lists.samba.org
cc: (bcc: Tim Conway/LMT/SC/PHILIPS)
Subject: rsync: future of the --server option
Classification:
Hello list members,
I notice here that the --server option is listed as undocumented.
http://rsync.samba.org/rsync/fom-serve/cache/88.html
My question is that the --server option is not documented, and I'd like
not to build functionality into one of my systems without trusting that it
will be there in the future.
I was able to find the --server option simply by watching the rsync
entries in the process table when I did not use the command restrictions
for the DSA key. I, however, would very much like to use belt and
suspenders: I would like to restrict access to this DSA key and also
restrict this DSA key to this individual rsync command.
I have been able to make rsync do my bidding by calling...here's a snippet
of my .ssh/authorized_keys2 file:
command="/usr/bin/rsync --quiet --delete --links --perms --recursive \
--server /home/mabrown/miccawillow/" ssh-dss AAAA....
For now, I'm happy to continue using the version of rsync I am using
(rsync-2.4.6) as I have been very happy with it. I would like to know
what the development plan includes for the undocumented --server option
(and the --sender option, too I guess).
Thanks for a great product.
-Martin
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com