ARMAND%BCVMS.BITNET@wiscvm.wisc.EDU (11/25/87)
We are in the process of configuring an ULTRIX system on a 11/780. Several
problems have presented themselves including an inadequate Operator (OPSER)
shell, the apparent lack of access control of the tape drives, and the
unavailability of a chargeback accounting utility.
At this point, we are concerned with determining the most efficient and most
practical way to control access to the tape drive. The hardware is locked away
and inaccessible to the users. Therefore, something has to be put in place
which would allow the user to request that a tape be mounted by an operator and
a reply be sent back to the user when that's been completed. Additionally,
access by others to the drive should be removed while that user is working.
When the user is done, the drive would be "deallocated" and others could then
access it.
Communication to and from the operator is trivial(I think) and the "allocation"
of the drive can be taken care of by altering the file permissions on the
device special file which describes the tape drive. I would appreciate hearing
how other sites are dealing with this problem. Do you deal with it or let the
users wander inencumbered and unprotected? Suggestions? Does anyone have any
code already written that they would be willing to share with a newcomer to the
environment?
Any information concerning the other two previously mentioned problems (the
Operator shell and chargeback accounting) would also be greatly appreciated.
Armand Doucette
Sr. VAX System Specialist
Boston College, Information Processing Support
BITNET: ARMAND@BCVMS (the ULTRIX machine is not connected)howie@cunixc.columbia.edu (Howie Kaye) (11/26/87)
There are other problems involved here -- How does a user release the tape drive? What happens if the user never does release the drive, but logs out? We started dealing with this issue, and came up with having an inferior shell running under the tape-mount program. When you exit that shell, or the tape-mount program exits, then a daemon takes the drive back. ------------------------------------------------------------ Howie Kaye howie@columbia.edu Columbia University hlkcu@cuvma.bitnet Systems Group ...!rutgers!columbia!howie
gwyn@brl-smoke.ARPA (Doug Gwyn ) (11/26/87)
In article <271@cunixc.columbia.edu> howie@cunixc.columbia.edu (Howie Kaye) writes: >What happens if the user never does release the drive, but logs out? Long ago, I designed a public resource allocator that dealt with these issues. (However, I never implemented it.) The solution to the above question was that an attempt to allocate that was not able to be satisfied using known free resources would then inspect the supposedly allocated ones to see if the user was still active (logged in; this is extendable to looking for processes running on his behalf if the device was allocatable by daemons). This fit in nicely with my design goal of not requiring any modifications to existing system software (e.g. init). UNIX has long needed a standardized facility like this, and it ought to be much more general than merely an interface to magtape drives.
alan@mn-at1.UUCP (Alan Klietz) (11/26/87)
In article <10542@brl-adm.ARPA> ARMAND%BCVMS.BITNET@wiscvm.wisc.EDU writes:
<
<We are in the process of configuring an ULTRIX system on a 11/780. Several
<problems have presented themselves including an inadequate Operator (OPSER)
<shell, the apparent lack of access control of the tape drives, and the
<unavailability of a chargeback accounting utility.
<
Lack of resource accounting tools is a chronic problem cited by many DP shops
when they want to switch to UNIX.
<At this point, we are concerned with determining the most efficient and most
<practical way to control access to the tape drive. The hardware is locked away
<and inaccessible to the users. Therefore, something has to be put in place
<which would allow the user to request that a tape be mounted by an operator and
<a reply be sent back to the user when that's been completed. Additionally,
<access by others to the drive should be removed while that user is working.
<When the user is done, the drive would be "deallocated" and others could then
<access it.
<
Ok. You need a resource control server for tapes, you want operator controls,
a friendly-user interface, request queuing, deadlock detection or prevention,
and tape label handling (ASCII? EBCDIC? DECtape? All?). There are also
special label formats for multi-reel files, multi-file reels, and combinations
thereof.
If you are a big shop, you may also want tape security and validation.
Some users may have 100's or 1000's of tapes, some with duplicate
information, some with older versions of the same information. They
don't want to ask for tapes by an arbitrary serial number (would you
want to ask for your disk file by i-node number?) They want to access
by name and perhaps the version number. Or by date, or content.
The bottom line is that this is a non-trivial problem.
It gets further exacerbated when your users scream
"I can do it on my 20 year old IBM/370 machine! Why can't I do
it on your gee-whiz state-of-the-art Wombat XGL9900!??!!"
--
Alan Klietz
Minnesota Supercomputer Center (*)
1200 Washington Avenue South
Minneapolis, MN 55415 UUCP: ..rutgers!meccts!mn-at1!alan
Ph: +1 612 626 1836 ..ihnp4!dicome!mn-at1!alan (beware ihnp4)
ARPA: alan@uc.msc.umn.edu (was umn-rei-uc.arpa)
(*) An affiliate of the University of Minnesotaggs@ulysses.homer.nj.att.com (Griff Smith) (12/05/87)
In article <6740@brl-smoke.ARPA>, gwyn@brl-smoke.UUCP writes: > > Long ago, I designed a public resource allocator that dealt with these > issues. (However, I never implemented it.) I proposed one about three years ago and finally got it working last month. > UNIX has long needed a standardized facility like this, and it ought to > be much more general than merely an interface to magtape drives. I guess I'm on the right track. My system deals with files as resources: a resource is a set of file names and associated system names. One can allocate a resource on a system and all the associated files will be given to the requestor. Any files associated with alternate access points on other systems are marked "busy". The allocator also deals with the problems of simultaneous requests for resources and resolves conflicts. As for availability: that could be a problem. I built it for 4.[23]BSD using C++. Since I work for AT&T and we are pushing another brand of UNIX System, I probably have to port all the Berkeley network and select stuff before there is any hope of turning it into a product. This does not look easy. I also have to convince management that there is actually a market for this thing; the current attitude is that no one wants or needs it. For example: the Murray Hill Computer Center is running UTS-370 on a mainframe, and it comes with a fairly decent tape allocation and mount request system. They have removed the feature. Another example: when I installed the allocator in my center the operators noted that root could bypass the 000 permissions, so they dismissed the allocator as an unnecessary nuisance. I have some hopes that the system will become useful when I build a operator tape mount service, but the initial reaction from the operators is that they would revolt if they had to be available to mount tapes on demand. I fear the old days are dead. I would like to get some idea of real demand for resource allocation software. Would anyone actually pay for it, or must it be freeware? Is it worth my time to submit a paper to USENIX, or would it get scheduled for the Friday, 4:30, session if accepted? -- Griff Smith AT&T (Bell Laboratories), Murray Hill Phone: 1-201-582-7736 UUCP: {allegra|ihnp4}!ulysses!ggs Internet: ggs@ulysses.uucp
gwyn@brl-smoke.ARPA (Doug Gwyn ) (12/06/87)
In article <3254@ulysses.homer.nj.att.com> ggs@ulysses.homer.nj.att.com (Griff Smith) writes: >..., I probably have to port all the Berkeley network and >select stuff before there is any hope of turning it into a product. Why in the world use networking stuff? My idea was to have a list of controlled resources, which would be file-locked by the allocator, which in turn would not be a daemon but would run when necessary. The allocator would need to be able to chown resources from a "public" account to the requesting user. (It would also check when unable to satisfy a request to see if there were any vanished users whose resources could be reclaimed.) Explicitly deallocated resources or those detected to be idle would be chowned back to "public". It is also very handy for such a utility to be able to not only allocate resources by specific name (not necessarily the same as their filename) but also by class, e.g. "alloc magtape magtape". I think a talk and perhaps BOF session would be valuable; UNIX has needed some facility like this for ages and it would be good to have one (and ONLY one, which must therefore be well-designed) available as a standard part of the product. There are a lot of uses for it even in a single-user environment.
roy@phri.UUCP (Roy Smith) (12/06/87)
In article <3254@ulysses.homer.nj.att.com> ggs@ulysses.homer.nj.att.com (Griff Smith) writes: > I built it for 4.[23]BSD using C++. Since I work for AT&T and we are > pushing another brand of UNIX System, I probably have to port all the > Berkeley network and select stuff [...] That an AT&T employee would rather use a foreign, unsupported product than his own company's native, supported, official "one true Unix" says more about the relative merits of the two versions than anything I can think of. > I would like to get some idea of real demand for resource allocation > software. Would anyone actually pay for it, or must it be freeware? Difficult question. Yes, I would love to have it. No, I wouldn't pay for it. But then, being in an academic environment, there isn't much software that I *do* pay for. In a commercial setting, I could very well see myself forking over some cash for such an allocator (assuming it really works and is convenient to use); better than explaining to the boss why his valued tape got overwritten by somebody else who happend to run his tar on the wrong drive, without complaint from the system. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
gamiddleton@orchid.UUCP (12/07/87)
In article <6802@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > Why in the world use networking stuff? My idea was to have a list of > controlled resources, which would be file-locked by the allocator, > which in turn would not be a daemon but would run when necessary. It is necessary to use the network stuff because of the possibility that a single tape drive may be connected to two or more machines. If somebody on machine A is using a shared drive, then machine B has to be told not to allocate it to anybody.
ekrell@hector.UUCP (Eduardo Krell) (12/07/87)
In article <3053@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > That an AT&T employee would rather use a foreign, unsupported >product than his own company's native, supported, official "one true Unix" >says more about the relative merits of the two versions than anything I can >think of. I disagree with the implication. Both System V and BSD Unix have their pros and cons. Depending on what you're doing, in some cases you'll be better off with System V and in other cases you'll prefer BSD (for instance, research vs development). I see nothing wrong with that. It just says that neither is perfect. Eduardo Krell AT&T Bell Laboratories, Murray Hill {ihnp4,seismo,ucbvax}!ulysses!ekrell
haral@unisol.UUCP (Haral Tsitsivas) (12/09/87)
In article <10542@brl-adm.ARPA> ARMAND%BCVMS.BITNET@wiscvm.wisc.EDU writes: > >We are in the process of configuring an ULTRIX system on a 11/780. Several >problems have presented themselves including an inadequate Operator (OPSER) >shell, the apparent lack of access control of the tape drives, and the >unavailability of a chargeback accounting utility. SysAdmin, the system administration and security software marketed by UniSolutions, provides both a user-level tape allocator program and a resource chargeback module (resource chargeback is optional, tape-allocator included by default). The tape allocator itself is quite simple, it knows about a list of devices and allows the user to request a specific tape drive or any free tape drive. The tape drive can be released either by the user or by the operator (who may use the release program from his shell or from the SysAdmin menu). --Haral Tsitsivas UniSolutions Associates (213) 641-6739 ...!uunet!scgvaxd!ashtate!unisol!haral
allbery@ncoast.UUCP (Brandon Allbery) (12/10/87)
As quoted from <6802@brl-smoke.ARPA> by gwyn@brl-smoke.ARPA (Doug Gwyn ): +--------------- | I think a talk and perhaps BOF session would be valuable; UNIX has | needed some facility like this for ages and it would be good to have | one (and ONLY one, which must therefore be well-designed) available | as a standard part of the product. There are a lot of uses for it | even in a single-user environment. +--------------- I hate to say this, but the Xenix V/386 machine at work already has such a facility, and as far as I can tell it will work over the manufacturer's proprietary network file system as well. -- Brandon S. Allbery necntc!ncoast!allbery@harvard.harvard.edu {hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery Moderator of comp.sources.misc
gwyn@brl-smoke.ARPA (Doug Gwyn ) (12/13/87)
In article <3053@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: -In article <3254@ulysses.homer.nj.att.com> ggs@ulysses.homer.nj.att.com (Griff Smith) writes: -> I built it for 4.[23]BSD using C++. - That an AT&T employee would rather use a foreign, unsupported -product than his own company's native, supported, official "one true Unix" -says more about the relative merits of the two versions than anything I can -think of. It doesn't say a damn thing about the relative merits of the two systems! There are plenty of people that have a choice who for their own reasons prefer one version or the other. BRL's party line was that 4.nBSD was the preferred system, but there are many here and elsewhare who use my System V environment on those systems just because they like it better. (And there are plenty others who prefer the native 4.nBSD environment.) Do you want to say that just because Dennis Ritchie spends a lot of time working with UNIX System V on a Cray that that proves that UNIX System V has more merit than 4.nBSD? Let's not reopen the old silly "my system is better than yours" debate. Or at least, let's use better logic.
bzs@bu-cs.bu.EDU (Barry Shein) (12/15/87)
Doug Gwyn writes >Let's not reopen the old silly "my system is better than yours" debate. >Or at least, let's use better logic. Or even better, let's keep pointing out that the debate is over, Sun and AT&T will be merging and delivering one system in the near future. Any such system comparisons between 4.x and SysV will become a thing of the past and anyone hung up on such concepts will be a dinosaur. Hallelulah. -Barry Shein, Boston University
roger@celtics.UUCP (Roger B.A. Klorese) (12/16/87)
In article <10843@brl-adm.ARPA> bzs@bu-cs.bu.EDU (Barry Shein) writes: | |Doug Gwyn writes |>Let's not reopen the old silly "my system is better than yours" debate. |>Or at least, let's use better logic. | |Or even better, let's keep pointing out that the debate is over, Sun |and AT&T will be merging and delivering one system in the near future. |Any such system comparisons between 4.x and SysV will become a thing |of the past and anyone hung up on such concepts will be a dinosaur. | |Hallelulah. Barry: Whenever this thing that Sun and AT&T are delivering becomes available (and I'm not certain what "near future" means in this case), it will be a merge of SunOS and SysV, not BSD and SysV. What Berkeley does, and what other suppliers of BSD-derived software do, has yet to be seen. -- ///==\\ (Your message here...) /// Roger B.A. Klorese, CELERITY (Northeast Area) \\\ 40 Speen St., Framingham, MA 01701 +1 617 872-1552 \\\==// celtics!roger@necntc.nec.com - necntc!celtics!roger
allbery@ncoast.UUCP (Brandon Allbery) (12/19/87)
As quoted from <10843@brl-adm.ARPA> by bzs@bu-cs.bu.EDU (Barry Shein): +--------------- | Doug Gwyn writes | >Let's not reopen the old silly "my system is better than yours" debate. | >Or at least, let's use better logic. | | Or even better, let's keep pointing out that the debate is over, Sun | and AT&T will be merging and delivering one system in the near future. +--------------- Let's get real here. Any V.3/4.3 merge product will come out no sooner than 1990. +--------------- | Any such system comparisons between 4.x and SysV will become a thing | of the past and anyone hung up on such concepts will be a dinosaur. +--------------- ...until 4.4BSD comes out. ;-) (Round and round and round it goes....) Has anyone considered that the reason Bell Labs moved from V8 to V9 without releasing V8 is so they can have a monopoly on version numbers? After all, System V and 4.xBSD are kinda stuck, whereas V9 can be followed by V10... Maybe Dennis Ritchie is trying to tell us something! ;-) ;-) -- Brandon S. Allbery necntc!ncoast!allbery@harvard.harvard.edu {hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery Moderator of comp.sources.misc