On Wed, Feb 28, 2001 at 11:04:56AM +1100, Martin Pool wrote:
> > Dave Dykstra wrote:
> > >How does everybody (especially Martin and Tridge) feel about the idea of
> > >rsync defaulting to "-e ssh" if it is invoked under the name ssync? Around
> > >here everybody is being told they should stop using r* commands and start
> > >using the s* equivalents so it seems a natural changeover. If there is
> > >general agreement, I'm willing to implement it and change the default
> > >installation to install symlinks at bin/ssync and man/man1/ssync.1.
>
> Personally I don't see any need to build a separate binary when a
> shell script or alias would do just as well.
I certainly wasn't talking about building a separate binary, I was just
talking about putting a symlink called 'ssync' in the standard install if
ssh was found.
> Also, I think in any
> given system people are going to either be using rsh or ssh, not both.
> (Does *anyone* really use rsh rather than daemon or ssh anymore?)
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. It would also
ease confusion as everybody begins to think "r* means bad security".
Regarding Phil's comment about there not being a need to use up the name
"ssync" in the command name space, I argue that a lot of people who have
heard of rsync and ssh would expect ssync to be a secure version of rsync
and would be confused if somebody used that name for something else.
> It seems fairly clear that it would be good to change over to SSH as
> the default:
>
> * for people who can use either, it's better to be secure by default.
>
> * people still using rsh should be gently encouraged to move to ssh
> unless they speifically choose to stay.
>
> * ssh can (optionally) fall back to using rsh if there's no ssh
> server listening.
>
> * forgetting to set RSYNC_RSH or -e is a pretty common problem for
> people wanting to start using it.
>
> * if all else fails, you can do
> --with-default-rsh=/etc/alternatives/remoteshell, or ln -s rsh shh
>
> However, I can imagine this causing small problems for people building
> binary distributions.
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.
On Wed, Feb 28, 2001 at 04:31:44PM +1100, Martin Pool wrote:
> This is my idea of the patch. Note that this would make ssh the
> default for 2.4.7, unless you specify otherwise at configure or run
> time.
...
> Index: configure.in
> ===================================================================
> RCS file: /data/cvs/rsync/configure.in,v
> retrieving revision 1.67
> diff -p -c -r1.67 configure.in
> *** configure.in 2001/02/24 01:37:48 1.67
> --- configure.in 2001/02/28 05:15:17
> *************** AC_PROG_CC
> *** 42,47 ****
> --- 42,62 ----
> AC_PROG_INSTALL
> AC_SUBST(SHELL)
>
> + AC_ARG_WITH(rsh,
> + [ --with-rsh=COMMAND use alternative remote shell program],
> + [ RSYNC_RSH="$withval" ],
> + [ RSYNC_RSH=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.
I think the name --with-default-rsh is better.
> +
> + 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).
> + then
> + AC_MSG_RESULT($locn)
> + else
> + AC_MSG_RESULT(no)
> + AC_MSG_WARN("$RSYNC_RSH does not seem to be in \$PATH on this machine")
> + fi
> + AC_DEFINE_UNQUOTED(RSYNC_RSH, "$RSYNC_RSH", [Default remote shell program to use])
> +
> AC_CHECK_PROG(HAVE_REMSH, remsh, 1, 0)
> AC_DEFINE_UNQUOTED(HAVE_REMSH, $HAVE_REMSH)
...
> Index: rsync.h
> ===================================================================
> RCS file: /data/cvs/rsync/rsync.h,v
> retrieving revision 1.97
> diff -p -c -r1.97 rsync.h
> *** rsync.h 2001/02/23 01:02:55 1.97
> --- rsync.h 2001/02/28 05:15:21
> *************** enum logcode {FNONE=0, FERROR=1, FINFO=2
> *** 73,84 ****
>
> #include "config.h"
>
> - #if HAVE_REMSH
> - #define RSYNC_RSH "remsh"
> - #else
> - #define RSYNC_RSH "rsh"
> - #endif
> -
> #include <sys/types.h>
>
> #ifdef HAVE_UNISTD_H
> --- 73,78 ----
Here's one problem I see: you're setting HAVE_REMSH but aren't using it
anymore. You need to have it take precedence in the setting of RSYNC_RSH
in configure.
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.
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.
- Dave Dykstra
