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 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.