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

[greywolf%starwolf.com@localhost]

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

From: greywolf%starwolf.com@localhost
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/56631: rdump fails to back up to remote file
Date: Fri, 21 Jan 2022 23:39:03 -0800 (PST)

 Hi there!
 
 On 1/15/22 11:20 PM, Michael van Elst wrote:
 >  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.
 
 Seems a bit archaic; should it not be resolving the host to a FQDN?
 
 >  rcmd() uses a single file descriptor (stdin, stdout, stderr are
 >  all the same), so ssh messages on stderr botch the RMT protocol.
 >
 
 Oooff.  Good to know, even if this seems to violate the POLA
 
 >  The command invoked is /etc/rmt which can manage a tape drive.
 >  While it can write to a file, it doesn't create it.
 
 Apparently it *can* create it if passed the proper argument; I tested
 this by handing the following to rmt locally:
 
 O/path/to/file
 514
 
 [514 = 0x202 = O_CREAT|O_RDWR]
 
 I'm just not quite sure what to patch to make this work or to make it at
 least an option to pass thru from rdump to rmt.
 
 >  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.
 
 Thank you for the heads up; rcmd(1) didn't even register on my radar.
 
 (The fact that RCMD_CMD is taken as a full literal string with no
 tokenization (i.e. one cannot include arguments in RCMD_CMD) seems
 ALSO a bug, or at least a candidate for enhancement, but that's
 something for another day.)
 
 
 				--*greywolf;