Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!uunet!olivea!genie!udel!haven.umd.edu!decuac!hussar.dco.dec.com!mjr
From: mjr@hussar.dco.dec.com (Marcus J. Ranum)
Newsgroups: comp.unix.wizards
Subject: Re: network backup in a heterogeneous environment
Message-ID: <1991Apr26.134612.10406@decuac.dec.com>
Date: 26 Apr 91 13:46:12 GMT
References: <1991Apr24.140354.25607@aplcen.apl.jhu.edu> <1991Apr25.223913.28479@comp.vuw.ac.nz>
Organization: Digital Equipment Corp., Washington Ultrix Resource Center
Lines: 29

duncan@comp.vuw.ac.nz (Duncan McEwan) writes:

>All that is needed to support rdump is a way of running "/etc/rmt" via
>the rcmd(3) library call (ie via rsh(1).

	It's actually easier than that. Since /etc/rmt expects to be
reading and writing to its standard output, you can just put it (on a
UNIX box, anyhow) where inetd will launch it. On other machines, you
might need to put a few little hacks into it to make it bind a known
port.

	/etc/rmt doesn't have any notion of permissions, so I have a
version that reads an /etc/tapecap file with host/device/user permissions
and a bunch of similar stuff. This code is going to be released when
I've tested it for a while longer. (along with other useful supporting
code)

	There is some brain-damage in the rmt protocol - the tape ioctl
commands *assume* that the values of the mtops are the same, which is a
bit of a nono, and, more amusingly, in some spots it passes data structs
back and forth, without any concern at all with respect to byte order,
and whatnot. (the status/'S' op, for example). Unfortunately, lots of
people seem to use it, so it's hard to make it right. I thought about
fixing it for my version, but that meant I'd have to hack dump/rdump,
too, which is pure evil. For non-dump/rdump archives I have a client
that just handles talking directly to the remote rmtd and stores its
standard input.

mjr.