Bug 3272

Local backups work, but remote backups fail.  Consider the
output from the command run on host mowgli, doing a remote
backup to itself: [The outcome is the same when doing this
between different hosts]

/sbin/dump 0f mowgli:/dev/st1 /
  DUMP: Date of this level 0 dump: Wed Jun  2 12:03:14 1999
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/sda1 (/) to /dev/st1 on host mowgli
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 62627 tape blocks on 1.61 tape(s).
/sbin/dump: Lost connection to remote host.
  DUMP: Bad return code from dump: 1

The problem turns out to be that dump tries to invoke
/sbin/rmt as rmt, but does not find it because /sbin is not
in the default path.

dump envokes rmt using an rcmd call [dumprmt.c line159]. The
argument of the remote program to run is set in
compat/include/pathnames.h line 49 as
 #define       _PATH_RMT       "rmt"
The problem is that the rmt program /sbin/rmt is NOT in the
default path, and so dump connects to a program that does
not exist.  Unfortunately, the rcmd call does not fail, nor
does the first write to the pipe opened by the rcmd call.
The first error is encountered when trying to read the reply
from the first write (which is the command to instruct rmt
to open the specified device file).  This leads to the very
misleading error message "lost connection" shown above.

Multiple solutions are possible.

1)  _PATH_RMT can be defined to be "/etc/rmt" instead of
"rmt".  This is the solution used by tar-1.12 to find rmt.
On all the hosts I checked this appears to be a symbolic
link to the real location of rmt [HP-UX, SunOS, Solaris,
Linux/Redhat, Linux/Debian].  The only exception I found was
AIX, and that is just a weird OS anyway.  I figure if it is
good enough for tar, it is good enough for me.

2)  Change the default path to include /sbin.  This way rcmd
will find rmt OK.  This does not appear to be a good idea
since it could have a bunch of side effects.

3)  Link /sbin/rmt to /bin/rmt or move rmt to the /bin. This
appears to be a good solution but since the /etc/rmt link is
already required for tar, this seems to be a proliferation
of links that is unnecessary.

Any of the above solutions solve the problem, and you could
probably find better ones, but #1 appears to be the
preferred solution.  Here is a patch file:
---------------------------------------------------------
--- dump-0.4b4/compat/include/pathnames.h.0
+++ dump-0.4b4/compat/include/pathnames.h
@@ -46,4 +46,4 @@
 #define        _PATH_DTMP      "/etc/dtmp"
 #define        _PATH_DUMPDATES "/etc/dumpdates"
 #define        _PATH_LOCK      "/tmp/dumplockXXXXXX"
-#define        _PATH_RMT       "rmt"
+#define        _PATH_RMT       "/etc/rmt"
---------------------------------------------------------

It is probably worth adding to the dump docs that the
/etc/rmt link is needed so that if the remote host is AIX or
something weird that there is a pointer

However, I am concerned that there is a problem somewhere in
the rcmd code that should report the failure earlier on and
somehow does not, leading to the misleading error message.
This is probably worth investigating.