On 28 Feb 2001, Dave Dykstra <[EMAIL PROTECTED]> wrote:
> That's very much not the case around here yet. Most people use only the
> intranet and are just starting to get aquainted with ssh because of a
> push by corporate security. It's going to take quite a while before
> people to transition, and it would be very handy to be able to choose
> rsync or ssync commands to choose a different default.
I think that's probably better done as a site-specific thing at Bell
Labs, then.
> It would also ease confusion as everybody begins to think "r* means
> bad security".
I can understand what you mean, but I don't think that would help the
situation.
After all, consider that "r* means `remote'" is generally true, but
rsync has nothing to do with sync(1). And I don't want to give
anybody else the idea that plain rsync is necessarily as insecure as
rsh.
> I don't mind there being a configure option, but I do a wide binary
> distribution and would not be able to enable the option and I would
> object to it being the default because of the number of things it
> could break. For example, I'll expect I'll have a lot of cases
> where both sshd and rsh will be enabled for the same server so it
> won't fall back to rsh, but ssh will prompt for a password but rsh
> won't.
I guess this is getting off the track, but I think that is a kind of
wierd situation. If you're allowing rhosts login for rsh, why not
allow it for ssh?
> I object to having RSYNC_RSH be set to ssh by default. I also object to
> it causing an error if ssh is not installed.
This is really the heart of the question: should we ever change the
default in the upstream distribution to give people a prod to move to
ssh? Or, should we wait for 2.5 (if any) or 3.0 to do that?
I think we should change it, and sooner rather than later though not
necessarily right now.
> I think the name --with-default-rsh is better.
Yes, that's probably a better name.
Also, as you might have seen in a patch a while ago, I want to make
rsync give a better message if the remote shell fails. This should
make it clearer to people what's going wrong.
> > + AC_MSG_CHECKING("for $RSYNC_RSH in \$PATH")
> > + if locn=`which $RSYNC_RSH`
>
> "which" is not a standard function. It is not on three of the system
> types I build binaries for. Use AC_PATH_PROG(VARIABLE,
> PROG-TO-CHECK-FOR).
Thanks, I realized that just after I posted.
> Another problem is that the RSYNC_RSH define is used in main.c (~ line 184)
> to determine whether or not the blocking_io option should be turned on.
> I'm not sure how else to handle it unless you explicitly parse the name
> to see if the base portion starts with "r". However, that may break some
> people's scripts if they have written their own '-e' scripts which happen
> to start with "r". It may be worth it, however.
That's a good point. The whole non-blocking area is too ugly for
words, and perhaps a reason not to change anything about the remote
shell until 3.0.
> I still plan to contribute a patch to add a --with-default-ssh configure
> option which will default to ssh in the PATH, and if ssh is found it will
> install symlinks at bin/ssync and man/man1/ssync.1. I expect to set a
> RSYNC_SSH define and use that if arg0 starts with "s". I probably won't
> get to it until next week though.
Why not just do it as a shell script?
#! /bin/sh
rsync -e ssh "$@"
The GNU Standards (for what they're worth) deprecate having program
behaviour depend on argv[0], and I'm inclined to agree, especially
because you're doing to support a program that really should be dead
by now.
--
Martin Pool, Human Resource
Linuxcare. Inc. +61 2 6262 8990
[EMAIL PROTECTED], http://linuxcare.com.au/
Linuxcare. Putting Open Source to work.
