Survey

[Frank Peters]

In article <richard.652960541 at fafnir.la.locus.com> richard at locus.com (Richard M. Mathews) writes:

   It is my understanding that this group is for discussions of Unix on large
   machines (how large is large?).  I'd be interested in starting things off
   by finding out what large machines and what versions of Unix you have out
   there.  For what do you use these systems?

   We have AIX/370 running on 370s including a 3090.  We have been working
   with IBM to develop AIX on these machines.  Since we use VM to run lots
   of small virtual machines in different configurations, perhaps we don't
   count as users of "large Unix" (except when helping a customer who IS
   using a large system).  As a supplier of such systems, we are, however,
   very interested in the opinions and needs of such users.

   What other large systems are out there?  What sorts of problems do you
   have that you feel are unique to users of large systems?

Well, we are developing a different kind of 'large system' that has
its own unique complexities.

We are in the process of migrating from a mainframe environment to a
distributed environment of UNIX servers and workstations.  Though none
of these systems taken individually are what I would call large
(though I wouldn't call a Sun 4/490 small either), taken together they
add up to more power and complexity than any mainframe I'm familiar
with.

There are a great many issues that are addressed in typical mainframe
operating systems (and perhaps by big iron unices like UTS and
AIX/370) that are all but ignored in the typical mini and workstation
implementations of UNIX.

I would hope that discussion of how varius users have addressed the
following issues would be appropriate to this group.

(1)  Operator driven UNIX.  The concept of a machine room operator is
     ingrained in most mainfram operating systems.  The concept of a
     large installation in which many of the day to day administration
     tasks are performed by operators in a machine room rather than by
     the user or the system administrator with root priviledges is 
     relatively foreign to most UNIX implementations.  There are
     really two sub issues involved here.

     a) We generally have two operators on duty in our machine room
        during peak hours.  Either of these operators must perform
        tasks such as answering requests, killing runaway logins and
        the like.  Requiring each of these operators to log in under a
        separate userid leads to an unacceptable amount of wasted
        time.  On the other hand, a single operator userid is a
        definite security problem.  We are currently attempting to
        establish an operator userid that can only be logged in on the
        system console in our machine room.

     b) We would like to delegate many tasks such as tape control,
        backup, printer control and such to our operators.  At the
        same time we don't want to share the root password.  There are
        a few systems out there to allow the delegation of tasks to
        certain users.  All of these, of course, have security issues
        involved that must be considered.

(2)  Tape device management.  Another capability supported in
     mainframe operating systems is the ability to gain exclusive
     control of a tape device, request that a tape be mounted, and
     release the device when the user is finished with it.  We would
     like to have this capability in our UNIX environment as well.

(3)  Load balancing.  In a single box balancing the load among several
     CPUs is relatively straitforward (at least in concept).  When
     your CPUs are spread across a dozen or more machines how do you
     avoid the situation of one machine being sunk to its knees while
     another is nearly idle.  When you add multiple classes of
     processor (is a 4/490 at 50% more loaded than a sparstation at
     30%?) or multiple types  (how do the above two compare to a
     decstation 3100 at 40%?) this issue can become a nightmare.

(4)  Userid management.  Most UNIX boxes come with instructions about
     which several files should be edited to add a user to the system.
     We are developing programs to manage the addition of userids in a
     relatively bullet proof way so that non-technical personnel can
     add new users.  While there are programs to do that around very
     few address the large system issues such as password file locking
     and batch additions of large groups of users like a class roll.

(5)  Accounting.  We have many projects of one sort and another which
     require accounting of resources.  On our mainframe we have an
     account number which can be used for this purpose.  The same
     userid can be under many accounts.  The UNIX accounting system
     (at least the one on a Sun running SunOS 4.1) doesn't seem to
     have an equivalent concept.  As far as we can determine no
     accounting information by group is available so that the newgrp
     command gives us no help.  It looks as if we will have to have
     multiple userids per user in this case.  The thought of that is
     repulsive both from a personal and administrative viewpoint.

I'm sure there are many other issues out there waiting for us that we
haven't thought of yet.  Any discussion or suggestions on the above
would be most welcome.

Regards,
FWP
--
--
Frank Peters   Internet:  fwp1 at CC.MsState.Edu         Bitnet:  FWP1 at MsState
               Phone:     (601)325-2942               FAX:     (601)325-8921