On Mon, Dec 15, 2003 at 10:51:08AM -0800, Wayne Davison wrote:> On Mon, Dec 15, 2003 at 10:03:28AM -0800, jw schultz wrote: > > > The one thing i really would have liked to have seen in a version bump > > would have been changing the default remote shell to ssh instead of > > rsh/remsh. > > I can see this being both a good thing (since I think it is a better > default for new users) and a painful thing (for people who still use > rsh). I'd be in favor of making this change, but I'm not sure if we > should try to slip it into 2.6.0 or not; on the one hand it is a very > simple change to make, but on the other it has a big impact on how rsync > works. I suppose we should just leave it for later.Code-wise it is almost trivial but user impact for those that depend on the default being rsh or remsh is potentially non-trivial. I think most that need rsh instead of ssh would be fine just setting RSYNC_RSH but the magic with [non]blocking io based on if ((blocking_io == -1) && (strcmp(cmd, RSYNC_RSH) == 0)) blocking_io = 1; might means some might have to add the --blocking-io option so they might as well use "-e rsh --blocking-io". Of course that bit of logic also means that "configure --with-rsh=ssh" would get the logic wrong too so it is in a sense broken already. I suppose we could change that to if ((blocking_io == -1) && (strcmp(cmd, 'rsh') == 0) || (strcmp(cmd, 'remsh') == 0)) blocking_io = 1; Which comes close to the intent of the original though it doesn't deal with someone doing "configure --with-rsh=/usr/local/bin/rsh" It would be worthwhile to add a note in INSTALL to advise people of the --with-rsh configure option. Any thoughts, particularly with regard to putting this in before 2.6.0? -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt
On Mon, Dec 15, 2003 at 12:11:41PM -0800, jw schultz wrote:> It would be worthwhile to add a note in INSTALL to advise people of > the --with-rsh configure option.I would not currently recommend that people use --with-rsh to set the default to be ssh because that affects the blocking I/O default in a weird way (i.e. it makes ssh default to blocking I/O and an override of rsh default to non-blocking I/O, which is backwards from what is desired).> Any thoughts, particularly with regard to putting this in before > 2.6.0?I've attached one possible patch that does the following: - Changed configure.in to set RSYNC_RSH to "ssh" by default (be sure to run "autoconf" if you try this patch). - Changed main.c to make blocking_io be the default if the remote shell command is either rsh or remsh (instead of comparing with RSYNC_RSH). We should then add a prominent release note that says that any site that still desires a default of rsh (or remsh) should add "--with-rsh=rsh" (or "--with-rsh=remsh") to their ./configure command. I'm feeling a little more comfortable with this change now. What do folks think about having something like this in 2.6.0? ..wayne.. -------------- next part -------------- --- configure.in 15 Dec 2003 19:00:20 -0000 1.173 +++ configure.in 16 Dec 2003 04:24:31 -0000 @@ -90,14 +90,14 @@ [ --with-included-popt use bundled popt library, not from system]) AC_ARG_WITH(rsync-path, - [ --with-rsync-path=PATH set default --rsync-path to PATH (default: \"rsync\")], + [ --with-rsync-path=PATH set default --rsync-path to PATH (default: rsync)], [ RSYNC_PATH="$with_rsync_path" ], [ RSYNC_PATH="rsync" ]) AC_DEFINE_UNQUOTED(RSYNC_PATH, "$RSYNC_PATH", [location of rsync on remote machine]) AC_ARG_WITH(rsh, - AC_HELP_STRING([--with-rsh=CMD], [set rsh command to CMD (default: \"remsh\" or \"rsh\")])) + AC_HELP_STRING([--with-rsh=CMD], [set remote shell command to CMD (default: ssh)])) AC_CHECK_PROG(HAVE_REMSH, remsh, 1, 0) AC_DEFINE_UNQUOTED(HAVE_REMSH, $HAVE_REMSH, [remote shell is remsh not rsh]) @@ -105,11 +105,8 @@ if test x"$with_rsh" != x then RSYNC_RSH="$with_rsh" -elif test x"$HAVE_REMSH" = x1 -then - RSYNC_RSH="remsh" else - RSYNC_RSH="rsh" + RSYNC_RSH="ssh" fi AC_DEFINE_UNQUOTED(RSYNC_RSH, "$RSYNC_RSH", [default -e command]) --- main.c 11 Sep 2003 04:53:05 -0000 1.172 +++ main.c 16 Dec 2003 04:24:31 -0000 @@ -241,8 +241,15 @@ args[argc++] = rsync_path; - if ((blocking_io == -1) && (strcmp(cmd, RSYNC_RSH) == 0)) - blocking_io = 1; + if (blocking_io == -1) { + char *cp = strrchr(cmd, '/'); + if (cp) + cp++; + else + cp = cmd; + if (strcmp(cp, "rsh") == 0 || strcmp(cp, "remsh") == 0) + blocking_io = 1; + } server_options(args,&argc); --- rsync.h 15 Dec 2003 08:07:38 -0000 1.157 +++ rsync.h 16 Dec 2003 04:24:31 -0000 @@ -107,9 +107,7 @@ #include "config.h" -/* The default RSYNC_RSH is always set in config.h, either to "remsh", - * "rsh", or otherwise something specified by the user. HAVE_REMSH - * controls parameter munging for HP/UX, etc. */ +/* The default RSYNC_RSH is always set in config.h. */ #include <sys/types.h>
I second that. Keeping rsh as the default is both an annoyance and a security risk, depending on one's local setup and installation. In fact I recently compiled 2.5.7 via "configure --with-rsh=ssh". Now I'm finding out with horror that this screws up things with blocking I/O, which defies the purpose. IMHO using ssh as the remote shell should be the default or should be trivial for sysadmins to select system wide (e.g. a configure option at compile time). Forcing individual users to have to set RSYNC_RSH just isn't good enough for a variety of reasons. So I say go with Wayne's patch. -- Alberto>>> I'm feeling a little more comfortable with this change now. What do >>> folks think about having something like [ssh instead of rsh as default] in > > 2.6.0? > > I'd say go for it. If nothing else, it would be nice to get away from the > current situation of potentially *encouraging* newbs to *start* using rsh > because it's rsync's default behavior. Sort of an "if you don't know how to > enable rsh then you shouldn't *be* enabling rsh" situation, if you know what > I mean. > > Besides, I'm personally at a loss to understand why anybody would (much less > should) still be using rsh in the first place. If they're running rsync on > an incredibly old machine and want to conserve the cycles ssh would use for > encryption or don't have ssh available, they can always just run an rsync > daemon.**************************************************************************** Alberto Accomazzi NASA Astrophysics Data System http://adswww.harvard.edu Harvard-Smithsonian Center for Astrophysics http://cfa-www.harvard.edu 60 Garden Street, MS 31, Cambridge, MA 02138 USA ****************************************************************************
I'm all for making it use ssh as default.
That said, I've noticed (at least when using -e ssh) that if ssh prompts
for a password or such, and you hit ctrl-c, you're more often than not
left with a tty with screwed up settings. This is because ssh turns off
echo and such for asking the password, and hitting ctrl-c will trigger
the rsync's cleanup code, which may kill the child (i.e. ssh) before it
itself has had a chance to clean up. In fact, this was also reported as
a bug on the Debian package at one time.
Inserting a short delay completely solves the problem for me.
The patch is below. I'd like to see this go into 2.6.0 if possible.
Paul Slootman
--- rsync-2.5.7.orig/cleanup.c
+++ rsync-2.5.7/cleanup.c
@@ -104,6 +104,16 @@
if (cleanup_child_pid != -1) {
int status;
+ /* if the user hits ctrl-C while ssh is prompting for a
password,
+ * then the kill_all() below may kill ssh before ssh has a
+ * chance to restore the tty settings (i.e. turn echo back on).
+ * By sleeping for a short time, ssh gets a bigger chance to
+ * do the right thing. When ssh exits, the select() in msleep()
+ * will be interrupted by SIGCHLD anyway.
+ * If child processes are not ssh waiting for a password, then
+ * this tiny delay shouldn't hurt anything.
+ */
+ msleep(400);
if (waitpid(cleanup_child_pid, &status, WNOHANG) == cleanup_child_pid) {
status = WEXITSTATUS(status);
if (status > code) code = status;
Possibly Parallel Threads
- configure --with-rsh=CMD and default blocking-IO support
- [Bug 1924] New: unable to rsync between a PC with cygwin and a unix machine using rsh
- rsync 2.5.5, "unexpected tag failures", Solaris 2.6 vs. 2.8, "--b locking-io" workaround
- Doubt in Rsync !!
- Problem with rsync on WinXP going to HP-UX or Linux