Return to BSD News archive
Newsgroups: comp.os.386bsd.apps Path: sserve!newshost.anu.edu.au!munnari.oz.au!sgiblab!sdd.hp.com!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!usenet.coe.montana.edu!news.u.washington.edu!ns1.nodak.edu!plains.NoDak.edu!tinguely From: tinguely@plains.NoDak.edu (Mark Tinguely) Subject: Network Tape Mounting Program Sender: usenet@ns1.nodak.edu (Usenet login) Message-ID: <C4Aw7B.3zB@ns1.nodak.edu> Date: Mon, 22 Mar 1993 17:21:11 GMT Nntp-Posting-Host: plains.nodak.edu Organization: North Dakota State University Lines: 63 Here is the README file for ndsutp, a Network Tape Mounting Program. The server is known to run on BSD 4.2+ based machines, the clients are known to also run on System V based machines. This program can be anonymously ftp from plains.NoDak.edu (134.129.111.64) in the file pub/386BSD/tapeprog.tar.Z --- NDSUTP README --- This program aids centralized network (TCP/IP) backups by verifying tape requests, prompting a human operator to mount the tape and returning information if the mount request succeeded. This program purposely does not backup/restore your files, instead use dump/restore, gnutar, dd, cpio or some other utility. For security, each tape is owned by a user and has a password accessible by only the owner. To make tape sharing possible a tape MAY belong to a group, then either the owner account and the owner password or anyone knowing group password may mount the tape. Each tape is accessible from one host. When the tape is mounted the special files in /dev associated with the tape are chowned to either the user (if the tape request is local) or a special remtape account owns the tape and the remote user is automatically added to the server's ~remtape/.rhosts file (if the request is from a remote account). A small security hole exists here, if two remote tapes are mounted, it is possible for one remote user to read/write the wrong tape. This could be corrected by giving separate remote accounts per unit, but would be difficult for backup scripts to issue remote-shell commands. As an added security measure, the tape mounting program is given list of host to accept or deny connections. And therefor restricting which hosts can backup on the server's tape unit. This program can be configured so each tape drive can be in a separate class, or several similar drives can be treated as a single class (for example a bank of DAT drives can be a single class). With a bank of drives that make up a class, the next mount request will be matched with the next available drive in the class. Each tape drive has a unique name for operator mounting and user/script use. When dealing with a multiple drive class, it is still possible to specify mount on a particular unit by name. It should be easy and natural to extend this program to use robotic tape jute-box type tape drives. The server software is known to compile on Sun OS 4.0.x (Solbourne), Ultrix (DecStations), 386bsd. The client software is known to compile on System V (SCO), HPUX, NextStep, Sun OS (and Solbourne), 386bsd. This file "support.c" is missing from this distribution. This file allows tape mounting requests to be sent to the operator account on a mainframe console. This file is hack of a UREP source file written by the Pennsylvania State University. This file is only in Makefile.ndsu and will not be missed by anyone else. Thank-you to Solbourne for adding an ioctl() to detect the status of the tape (readwrite/readonly), but an apology for not using it because the local CC after a over a year and a half of having the 4.1.x tape, has not installed it, nor let users see the man pages. To run on a 386bsd, get the publically available DEC crypt routines from a non-USA ftp site. See the INSTALL file for installation information, and see man/General for information about operation and sample script files. --mark (tinguely@plains.NoDak.edu)