Re: bin/56631: rdump fails to back up to remote file

[mlelstv%serpens.de@localhost (Michael van Elst)]

The following reply was made to PR bin/56631; it has been noted by GNATS.

From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/56631: rdump fails to back up to remote file
Date: Sun, 16 Jan 2022 07:14:57 -0000 (UTC)

 greywolf%starwolf.com@localhost writes:
 
 ># rdump 0uaf dumphost:/backupdir/_root.0 /
 >  DUMP: Found /dev/rld0a on / in /etc/fstab
 >  DUMP: Date of this level 0 dump: Sat Jan 15 18:49:08 2022
 >  DUMP: Date of last level 0 dump: the epoch
 >  DUMP: Dumping /dev/rld0a (/) to /backupdir/_root.0 on host dumphost
 >  DUMP: Label: none
 >  DUMP: mapping (Pass I) [regular files]
 >  DUMP: mapping (Pass II) [directories]
 >  DUMP: estimated 341149 tape blocks.
 >rdump: Lost connection to remote host.
 
 
 This can fail for several reasons.
 
 RCMD_CMD is called as $RCMD_CMD -4 -l $user $host /etc/rmt, so
 that's IPv4 only. The $host is also canonicalized, e.g. a short
 hostname (without fqdn) gets a '.' appended.
 
 rcmd() uses a single file descriptor (stdin, stdout, stderr are
 all the same), so ssh messages on stderr botch the RMT protocol.
 
 The command invoked is /etc/rmt which can manage a tape drive.
 While it can write to a file, it doesn't create it.
 
 I was successful with an .ssh/config stanza of:
 
 Host mytapehost.*
 	LogLevel Quiet
 	ForwardX11 no
 	ForwardAgent no
 
 and pre-creating the output file on mytapehost. You can also
 wrap ssh like:
 
 /bin/sh
 exec ssh -qxa "$@"
 
 with a similar effect.
 
 
 N.B. rcmd(1) is unsuitable for testing as it ignores RCMD_CMD.