The commands listed in the /tape144/root/notes file
could be run from a script. When I tried, I got rpc setup errors.
I suspect it was just that the commands were run too quickly, and
the portmapper hadn't properly installed itself. I found that
typing the sequence in manually worked fine, so I've recommended
that.
I think this setup is secure. Note that somebody can still get
access to all your files if they go to the tape drive and pull
the tape out before you get there, then then read the tape
themselves. People with very sensitive data might consider
encrypting the stream from the archiver. Archive to standard
output and pipe the output to the encrypter, and redirect the
output of the encrypter to append to the named pipe
/tmp/tapepipe as described above. Note that errors
in the recovery process will result in all files after that point
being unrecoverable, as the entire archive is now a single
DES-encrypted stream. It is possible to use options on afio to
send each file in the archive first through gzip, then into an
encryption program like des, but note that this compressing first
does provide a fair amount of known plaintext for determined code
breakers to work with, so a better approach might be to skip the
gzip step and simply encrypt it with des, at the expense of
significantly more tape area. Needless to say, DES encrypted
files don't compress.
The rc.inet1 directions I've included will allow
only communication with the local network, not the rest of the
world through a gateway.
During a full recovery to a blank hard disk the SAR disk #3
provides ftape.o to the MS-DOS machine through NFS.
This is because some old versions of the ftape
module can't control some tape drives when there is a disk
mounted in the floppy drive. With newer kernels, the entire NFS
stuff can be omitted.
This is very important. ***TEST*** the SAR recovery
procedure. I did, but don't leave anything to chance. Make sure
that you can recover at least one file from your tape to the
Linux machine using only the SAR disks (i.e. without mounting the
hard disk). If you can't reboot the Linux machine without
inconveniencing a lot of users, change the setup information on
the SAR disks to assign the ``linux'' identity to
another MS-DOS machine and then boot the two MS-DOS machines into
Linux to make sure everything works. Then, change the
``linux'' identity back again so that you have
usable SAR disks.