Continuation of "Arrrgh! rsync "chroot failed" error message!"

I find myself in the same situation of the author of the thread
entitled "Arrrgh! rsync "chroot failed" error message!" See
http://tinyurl.com/o9kog or
http://groups.google.ca/group/comp.o...b8512e8f6c233a
..

I am trying to use rsync to synchronize some files between two systems.
I'm planning on doing this rather frequently, so it's my understanding
that I should use the rsync daemon mode, and using ssh is basically a
requirement as well.

My most recent successful step was to link the /etc/rsyncd.conf file to
$HOME for my remote user, and I'm now getting this error:

$ rsync --rsh="ssh" -av --delete test.txt
remoteHost::ModuleName/my/path

@ERROR: chroot failed
rsync error: error starting client-server protocol (code 5) at
main.c(1296) [sender=2.6.8]

Basically, what I want to know is this: In the thread above, the
response was basically, "If you want to use ssh, then don't use the
rsync daemon." That seems to be a common response on the web. Is it
true? Is there a sensible way to use both ssh and the rsync daemon?

As a related question, what is the additional overhead for NOT running
rsync in daemon mode?

Thanks.

(E-Mail Removed) <(E-Mail Removed)> wrote:
> I am trying to use rsync to synchronize some files between two systems.
> I'm planning on doing this rather frequently, so it's my understanding
> that I should use the rsync daemon mode, and using ssh is basically a
> requirement as well.

You probably don't want daemon mode at all. In fact, unless you know
why you need it, disable it. I've never needed daemon mode, and I use
rsync between many groups of machines.


> My most recent successful step was to link the /etc/rsyncd.conf file to
> $HOME for my remote user, and I'm now getting this error:

> $ rsync --rsh="ssh" -av --delete test.txt
> remoteHost::ModuleName/my/path

I'd recomment this instead:

rsync -avP --rsh="ssh" --delete test.txt rhost:{optional_remote_path}


> Basically, what I want to know is this: [I've read that] "If you want
> to use ssh, then don't use the rsync daemon." That seems to be a common
> response on the web. Is it true?

Yes. A daemon would typically be used to control access to an rsync tree
in situations where the client does not have a login on the server.
(Think public repository.) If you do have login access to the server
it's generally far easier to use ssh/rsh and treat rsync like scp/rcp.


> Is there a sensible way to use both ssh and the rsync daemon?

Yes, but you really ought to think about the reasons for wanting both.


> As a related question, what is the additional overhead for NOT running
> rsync in daemon mode?

The rsync client has to log in to the remote system (using ssh/rsh). But
then, the rsync daemon would have to authenticate inbound connections
anyway, so perhaps it's not a significant overhead.

Chris

Thanks for the response!

Chris Davies wrote:
> > Is there a sensible way to use both ssh and the rsync daemon?
>
> Yes, but you really ought to think about the reasons for wanting both.

My reason was mainly because I thought that it would use less
resources. We're developing an Active/Standby system, and the design
decision was made that the Active system (which is also doing other
processing, of course) will push changes and sync requests to the
Standby system.

> The rsync client has to log in to the remote system (using ssh/rsh). But
> then, the rsync daemon would have to authenticate inbound connections
> anyway, so perhaps it's not a significant overhead.

Minimizing overhead on the Active system is the goal, but at this point
I don't have any data on which to base a decision. If there's not a
big difference, not using the rsync daemon certainly appears to be
easier.

(E-Mail Removed) <(E-Mail Removed)> wrote:
> We're developing an Active/Standby system, and the design
> decision was made that the Active system (which is also doing other
> processing, of course) will push changes and sync requests to the
> Standby system.

You've seen the High Availability site, http://www.linux-ha.org/?
Chris