Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/unix/volume25/policy/part03

Text File | 1992-02-28 | 50KB | 1,277 lines

Newsgroups: comp.sources.unix
From: [e-mail] (Bud Hovell)
Subject: v25i139: policy V2 - tools for providing interactive timeshare policies, Part03/03
Sender: [e-mail]
Approved: [e-mail]

Submitted-By: [e-mail] (Bud Hovell)
Posting-Number: Volume 25, Issue 139
Archive-Name: policy/part03

Return-Path: oliveb!mtek!nosun.West.Sun.COM!bbh
Received: by cognition.pa.dec.com; id AA04521; Tue, 25 Feb 92 06:53:25 -0800
Received: by uucp-gw-1.pa.dec.com; id AA09068; Tue, 25 Feb 92 06:53:14 -0800
Received: by oliveb.ATC.OLIVETTI.COM (smail2.5)
    id AA08062; 25 Feb 92 06:52:46 PST (Tue)
Received: from Sun.COM (sun-barr) by sun.Eng.Sun.COM (4.1/SMI-4.1)
    id AA03211; Tue, 25 Feb 92 06:27:16 PST
Received: from nosun.West.Sun.COM by Sun.COM (4.1/SMI-4.1)
    id AA12979; Tue, 25 Feb 92 06:27:00 PST
Received: from mtek.UUCP by nosun.West.Sun.COM (4.1/SMI-4.1-900117)
    id AA00558; Tue, 25 Feb 92 06:26:51 PST
Received: by mtek.mtek.com (Smail2.5+apb/mje900117)
    id AA10558; Tue, 25 Feb 92 04:07:34 PST
Subject: Policy Package, part 3 of 3
To: vixie (Paul Vixie)
Date: Tue, 25 Feb 92 4:07:30 PST
Reply-To: [e-mail]
X-Mailer: ELM [version 2.4dev PL52]
Message-Id: <[e-mail]>
From: [e-mail] (Bud Hovell)


#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#        "End of archive 3 (of 3)."
# Contents:  misc/art.rt misc/art.ur2
# Wrapped by [e-mail] on Tue Feb 18 20:42:40 1992
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'misc/art.rt' -a "${1}" != "-c" ; then
  echo shar: Will not clobber existing file \"'misc/art.rt'\"
else
echo shar: Extracting \"'misc/art.rt'\" \(29944 characters\)
sed "s/^X//" >'misc/art.rt' <<'END_OF_FILE'
X
X
X
X                                  - 1 -
X
X
X
X       $Id: art.rt.N,v 5.3.2.5 91/09/03 09:55:27 policy USENET $
X
X       The following was first published in ROOT magazine, Volume
X       1, Number 4 and 5
X
X       Copyright 1989 Bjorn Satdeva.
X
X       Permission granted to distribute this article for nonprofit
X       purposes, as long as this header and copyright notice are
X       kept intact.
X
X                       On the Human Aspect of UNIX
X                            System Management
X
X                             by Bjorn Satdeva
X
X       Have you ever stopped for a moment, and thought about what
X       the job as system administrator really is about? Try to look
X       past the backups done last night, and the new user account
X       which was created this morning.  What is the real purpose
X       behind the work which is done by the system administrator
X       every day?
X
X       Traditionally, the system administration job is described in
X       terms of technology and programming.  But the core of system
X       administration is really about something completely
X       different.  It can actually be described with just three
X       letters: ``TLC''.  Tender Loving Care.
X
X       The work of a responsible system manager is to support the
X       users on his or her systems, to assist the management in
X       setting policies, and to help everybody to decide the future
X       needs of the site.  All too often, a system administrator
X       will say that his job is to take care of such and such a
X       system.  In my opinion, that is only a part of the truth.
X
X       The real job is to care for a number of fellow human beings,
X       which in one way or another are dependent on the computer
X       system which the administrator has been entrusted to
X       maintain.  And in this process, the UNIX system manager will
X       become known as a hard worker, always ready to do what is
X       necessary to keep the system running.  Right?
X
X       No. Wrong.  Dead wrong! Unfortunately, in the world of
X       realities, this is not usually the case.  The system manager
X       will only be visible to the world outside the computer room
X       when something goes wrong.  In this context, the question is
X       how can he avoid being the guest of honor at the ``necktie
X       party'' which inevitably follows a major system crash? In
X       fact, there is a lot which can be done through establishing
X       a good rapport with both the management and user community
X
X
X
X
X
X
X
X
X
X
X
X                                  - 2 -
X
X
X
X       within the system manager's company.  And good rapport
X       requires lots of ``TLC''.
X
X       Some of the ways the UNIX system manager can provide this is
X       by always being ready to listen to and act on the problems
X       in the user community, and by clearly communicating
X       situations and requirements which may affect the operation
X       of the system to the company management.  Last but certainly
X       not least, he must provide documentation.  Not necessarily
X       documentation in technical terms, but rather easily
X       understandable and clear statements of the policies and
X       procedures which have been established to govern the site.
X
X                           Dealing With People
X
X       The purpose of this article is to show some of the ways a
X       UNIX system manager can improve his relationships with both
X       the management and the user community at his site.  It will
X       be presented in two sections.  First, we will discuss the
X       system administrator's relationships with his management,
X       and then, in our second article, with the user community at
X       large.
X
X       We will explore these relationships in this sequence, not
X       because the management is a more important factor than the
X       users, but because this is the sequence in which these
X       relationships must be established.  Any attempt to build
X       strong relations to the user group of a system can easily be
X       undermined by a few negative management individuals.  It is
X       therefore extremely important for company management to be
X       totally in alignment with the goals of the system
X       administrator.
X
X       What follows is a story of how these solid human
X       relationships can be established.
X
X       Linda is the UNIX system manager at Buildmore Technologies,
X       Inc.  This company is, in many ways, a typical UNIX site.
X       It has a large number of UNIX systems which are used mostly
X       by the engineering departments, while other company
X       functions such as accounting, payroll, and word processing
X       are done on non-UNIX systems.
X
X       Linda has the responsibility for the administration of the
X       UNIX systems.  She has two system administrators and three
X       System Operators to do the daily work.  Linda is reporting
X       to Dave, the MIS manager, who knows nothing about UNIX and
X       therefore, is totally dependent.
X
X       Linda has only been with Buildmore Technologies, Inc. for a
X       few months.  When she started, the UNIX systems were in a
X
X
X
X
X
X
X
X
X
X
X
X                                  - 3 -
X
X
X
X       state of extreme chaos with just a single system
X       administrator trying to keep the systems working.  What he
X       was able to do could hardly be characterized as proper
X       ``administration''; fire fighting comes to mind as a much
X       better description.
X
X       The situation was further aggravated because Dave considered
X       UNIX to be a maverick system which was hopeless to
X       administer, and many of the users were convinced that the
X       MIS UNIX support was the last place in the world they could
X       expect any real help with their system problems.
X
X       This is the story behind some of the the things Linda did to
X       change the UNIX site at Buildmore Technologies from total
X       chaos to being a well administered and productive site.
X
X                          Analyze the Situation
X
X       Linda very soon realized that if she was going to have any
X       kind of success in cleaning up the UNIX system problems at
X       Buildmore, she would definitely need the full support of her
X       MIS Manager, Dave.  Therefore, she spent the first weeks in
X       her new position getting the situation in the Data Center
X       under some kind of control, and then quickly started
X       outlining some of the long term programs which had to be
X       undertaken to create a secure and properly administered
X       site.  She immediately began presenting and communicating
X       those needs to Dave.
X
X       Because Dave knew so little about UNIX, it was part of
X       Linda's responsibilities to inform and educate him about
X       what needed to be done at Buildmore Technologies, Inc.  She
X       did that by writing a number of memos, outlining the
X       strengths and weaknesses of UNIX in a number of areas such
X       as backup and security.  She further outlined some
X       suggestions and possible solutions in these areas.
X
X       In just a few months, Linda and Dave were able to come to an
X       understanding and an agreement on the requirements for their
X       site, and a strategy for how the site should be administered
X       began to emerge.  Linda began writing a number of documents
X       which, in an official manner, described how the UNIX site
X       would be run.  The first document she wrote was a Site
X       Policy.
X
X                          Getting It In Writing
X
X       Before we continue, perhaps we should define a ``Site
X       Policy''.  The Site Policy is the ``Constitution'' for the
X       site. It must describe in general and nontechnical terms the
X       policies which both the system administrator and the users
X
X
X
X
X
X
X
X
X
X
X
X                                  - 4 -
X
X
X
X       must follow when using the equipment and software at the
X       site.
X
X       It allows the top management to state the policies governing
X       the site in general terms, and provides the system
X       administrator with a platform upon which more specific
X       documents can be built.  Remember, the purpose of this Site
X       Policy is not to establish a mindless bureaucracy, but to
X       create a foundation on which the UNIX system manager can
X       build the correct system administration guidelines.
X
X       Linda's draft was written in exactly that manner.  Here are
X       some of the topics it covered:
X
X          +o Statement of purpose for the site
X
X            A very general description of how backups should be
X            done.  Linda decided that each machine should be backed
X            up fully once a week, and incrementally on a daily
X            basis.  She also described how many generations of
X            backup would be kept, and what generation of backups
X            should be kept offsite.
X
X          +o Knowing that site documentation and planning is very
X            important, but would take more time than she had for
X            her initial proposals, Linda requested that a Disaster
X            Recovery Plan and a Security Plan should be written as
X            soon as possible.  She further stated that sufficient
X            documentation describing the daily operations of the
X            site be properly maintained.
X
X          +o And finally, she described in general terms her
X            intentions to create a Security Plan for the site,
X            which included proper password protections, management
X            of dial-up lines, root permission access, and an
X            overall security audit.
X
X       Because of the many constructive and well-planned memos,
X       meetings and discussions which Linda encouraged with Dave,
X       she was able to easily write the Site Policy and Dave was
X       able to have the CEO of Buildmore Technologies sign off on
X       the document after just a few minor changes to Linda's
X       original draft.  Buildmore Technologies, Inc. now had an
X       official Site Policy in place for its UNIX machines, and
X       Linda could continue with the task of further improving the
X       administration, operation, and documentation of their UNIX
X       sites.
X
X                              Security Plan
X
X       With the Site Policy in place, it was time for Linda to
X
X
X
X
X
X
X
X
X
X
X
X                                  - 5 -
X
X
X
X       start to work on the other documents which her original Site
X       Policy stated would be required for their system. This
X       definitely included the development of a well thought-out
X       Security Plan for their system.
X
X       General system security had not been taken very seriously
X       before the Fall of 1988, when the Internet Worm crippled
X       hundred of UNIX systems and received a great deal of
X       publicity.  Since that event, many sites began at least
X       paying lip service to the type of system security which
X       Linda knew to be essential to protecting their UNIX site.
X
X       Linda knew that since Buildmore Technologies was connected
X       directly to both Internet and to UUCP, she would have to pay
X       special attention to security.  A large amount of electronic
X       mail was exchanged over their system every day through these
X       connections.
X
X       In her outline for the site security requirements, and how
X       it would be implemented in their ``Security Plan'', she
X       included some of the following important factors:
X
X          +o All user accounts would be required to have a password,
X            and a user account would only be created after
X            receiving a written request from an authorized manager.
X
X          +o All direct incoming modem lines were only allowed to be
X            used with UUCP.  Dial-in access for employees would be
X            required to go through a data switch with callback
X            facilities, to insure that calls were originating only
X            from authorized locations.
X
X          +o All systems would have an automatic security audit
X            program executed every night, and mail the results to
X            Linda for inspection.  To achieve this, Linda was using
X            the security utility in UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm SSSSeeeeccccuuuurrrriiiittttyyyy (Kochan
X            and Wood).  Although it did not do everything she
X            desired, it was still a very good beginning.
X
X          +o Knowing that the question of who would be allowed
X            possession of the root password is a controversial one
X            at many sites, Linda was determined to create a
X            sensible and secure policy to manage root permissions
X            in her initial documents.  In keeping with her sound
X            understanding of UNIX system fundamentals, she
X            determined only those key individuals who were
X            absolutely required to have root permission on their
X            system, and bypassed the inevitable random requests of
X            other users for root access as a matter of site and
X            company policy.
X
X
X
X
X
X
X
X
X
X
X
X
X                                  - 6 -
X
X
X
X                             Disasters Happen
X
X       The last big piece of documentation Linda wrote was the
X       Disaster Recovery Plan.  Before we actually look at the plan
X       which she proposed for Buildmore Technologies, Inc. a
X       general word about Disaster Plans is appropriate:
X
X       Many UNIX users and managers think that only large
X       commercial sites need a Disaster Recovery Plan, because they
X       have high demands for immediate continuation of their data
X       processing after a disaster.
X
X       However, even very small UNIX sites should have a Disaster
X       Recovery Plan.  It need not be a solution with alternate
X       data centers or standby equipment, but every Unix system
X       manager needs to consider what they will do if they lose
X       essential parts of their equipment due to natural disaster,
X       fire, theft, or just plain failure.
X
X       In creating this plan, it is often helpful to have everybody
X       at the site play a game of ``what if...?''. What if we lose
X       the root disk on our main file server? What happens if our
X       only tape drive fails, and we cannot restore any of our
X       backups for another week? And so on.
X
X       The most important part of this exercise and in writing the
X       Disaster Plan, is to analyze the possible manners in which a
X       site can fail, and what realistically can be done to prevent
X       excessive loses and recover from that situation.  All too
X       often, a site has no such prior planning in place.  When a
X       disaster hits, and notice that I have used the word ``when''
X       and not ``if'', a lot of time and money is wasted with
X       managers and technical personnel alike running around in
X       small circles like chickens without heads.
X
X       Knowing that intelligent site management demands foresight
X       and prior planning, the Disaster Recovery Plan Linda wrote
X       for Buildmore Technologies required offsite storage of a
X       major part of their backup tapes (tapes were sent offsite
X       daily).  And, it further required that a good quality
X       hardware maintenance contract on all important equipment be
X       secured with a reputable company.
X
X       If a big disaster, like a major earthquake or a fire should
X       hit their site, Linda planned on purchasing new equipment
X       and installing a new site over a five month period.  While
X       this solution was far from ideal, it was an acceptable
X       compromise between actual needs and the practical cost of
X       implementation.
X
X
X
X
X
X
X
X
X
X
X
X
X
X                                  - 7 -
X
X
X
X       The only piece of standby equipment she purchased
X       immediately was a hard disk, which was pre-formatted and had
X       the UNIX system files pre-installed on it.  By taking this
X       relatively inexpensive precautionary step, if the root disk
X       on any of her file servers should fail, she could cut the
X       repair time of her system down to only three or four hours,
X       instead of one to nine days.
X
X       Linda also knew that it is extremely important for every
X       UNIX system manager to write a weekly status report. This
X       document would serve a number of different and important
X       functions for her as System Administrator.  Firstly, it was
X       a formal method to inform her manager, Dave, about progress
X       with ongoing projects, what tasks had been completed, and
X       what was needed for the system in the near future.  She also
X       used the status report to convey any outstanding problems
X       which required solutions beyond the scope of her
X       responsibility. Any unresolved problem stayed on the status
X       report each week, until a satisfactory solution had been
X       found for it.
X
X       In the beginning of her work with Buildmore Technologies,
X       Linda discovered that there was not a sufficient number of
X       tape drives on their UNIX system, and that it was impossible
X       to provide adequate backup coverage for their systems.  She
X       listed this as a special and important problem on her weekly
X       status reports to Dave, but the top management of Buildmore
X       Technologies were reluctant to spend the large sum of money
X       which was necessary to implement a functional solution.
X
X       When a huge disk drive was lost a couple of months later,
X       and there were no recent backups of that drive, Buildmore
X       Technologies suffered an estimated loss of over 800 hours of
X       engineering time.  Because Linda had consistently turned in
X       her weekly status reports for the last two months stating
X       the existence of that situation and requesting funding for
X       additional tape drives, both she and Dave were in the clear
X       (some people call this site status reporting method ``CYA'',
X       an abbreviation which refers to covering a specific part of
X       the body which we will have to leave to the reader's
X       imagination!).
X
X                                 Summary
X
X       This concludes the first part of our story about Linda's
X       work with Buildmore Technologies, Inc.  We have described
X       how she developed her relationships with management,
X       organized a well-documented plan for proper site management,
X       and did her professional best to protect the interests of
X       her company from the potential economic losses incurred from
X       system failures.
X
X
X
X
X
X
X
X
X
X
X
X                                  - 8 -
X
X
X
X       She did so by using a combination of two very important
X       principles:
X
X       First, she exercised exceptionally good judgment in abiding
X       by the simple and sound principles of proper UNIX system
X       administration and site management.
X
X       Second, and very importantly, she remembered that both
X       managers and system users are, after all, human beings.  She
X       understood that fulfilling her technical responsibilities as
X       system administrator meant that she would have to
X       communicate her plans and the overall system requirements in
X       a manner which could be easily understood, accepted and
X       supported.
X
X       In my next article, I will discuss some of the basic
X       requirements for establishing an equally strong rapport with
X       the users of a UNIX system.  We will see how the same type
X       of rapport and clear communication of sound UNIX practices,
X       which Linda established with her management at Buildmore
X       Technologies, can be extended to the ``user community'' of
X       any UNIX site.
X
X       Remember, a well managed UNIX system is a happy, secure, and
X       reliable UNIX system!  See you next issue!
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X                                  - 9 -
X
X
X
X                     The Human Aspect of UNIX System
X                           Management (Part 2)
X
X                             by Bjorn Satdeva
X
X           This is the second of two articles about some of the
X       human factors in UNIX system administration. In the last
X       article, I stated that traditionally system management is
X       seen as a technological task, while the real job is to care
X       for a number of fellow human beings. Based on this I showed
X       how Linda, a UNIX system manager at the imaginary site
X       Buildmore Technologies, created a good working relationship
X       with management.  In this article, we will look at how a
X       similar good relationship can be built with the user
X       community.
X
X       As I stated last issue, the work with management and the
X       work with the user community are not two unrelated
X       processes.  Even though they have been described separately
X       in these two articles, they are very closely interconnected.
X       Many of the decisions Linda and Dave, the MIS manager, made
X       were based on input from the users.
X
X       The important factor here is ``the users''.  They are often
X       seen as a gray mass of disturbance.  A system manager who is
X       able to remember that the users are individuals, each in
X       many ways dependent on the computer in their daily work,
X       will be able to create a better working environment for
X       everybody.  Many system managers have ruined the reliability
X       and security of their sites by being unresponsive to their
X       users.  When a system manager is not supporting his users,
X       then they will attempt to bypass him in order to get their
X       work done.  The system manager has created an environment
X       where the security of the system is under constant attack
X       from users, and he is the one who is responsible for the
X       security violations, although indirectly.
X
X       The method Linda used to establish rapport with the user
X       community was almost identical to the manner she used with
X       management.  By keeping the users informed about the current
X       state of the systems, and being doubly sure to communicate
X       possible problems and scheduled downtime, she slowly created
X       an environment where the users were more understanding of
X       the occasional need for downtime or reorganization of the
X       systems.
X
X       Linda found that most users are reasonable people. They
X       often accept even severe restrictions, if they have been
X       notified ahead of time, and it has been explained how and
X       why the new solution is for the good of the user community
X       at large.
X
X
X
X
X
X
X
X
X
X
X
X                                  - 10 -
X
X
X
X       Of course, Linda was not able to fulfill every user's
X       request.  Whenever she was presented with a request which
X       could not be fulfilled, she always made sure to have a
X       meeting with the involved users to explain why the request
X       had to be rejected.  At the same meeting she also presented
X       what she thought could be workable alternatives.  In most
X       cases one or more of those alternatives was acceptable to
X       the users, but in cases where no alternative could be found,
X       she always made sure two things were done.  First, she
X       finished the meeting with a suggestion that people should
X       contact their direct manager in order to have the problem
X       escalated in the management hierarchy, and she notified her
X       own manager about the situation.
X
X       By doing so, she first of all ensured that the users felt
X       they had been heard.  Through their manager, they felt they
X       had an avenue to continue pursuing their requests. By
X       notifying her own manager, she had given him a chance to be
X       able to support (or reject) her position.  In many such
X       cases, the item of discussion involved purchase of more
X       expensive equipment, and the whole discussion had been
X       escalated to a higher level of management, where such
X       discussion belongs.  In this way good relations with users
X       will most likely be kept intact.
X
X                           How To Say No Nicely
X
X       Let's look at a few examples of the kind of requests Linda
X       got, where she could not provide the requested service.
X
X       One day Joe User came to her office and asked for more disk
X       space on the system he was using.  When she looked into the
X       request, she found that Joe already was occupying more than
X       75 Mbyte of disk space, while the total sources for the
X       project he was working on only required 45 Mbyte.
X       Confronted with this, Joe explained that he was keeping
X       backup copies of his files, so he could go back to previous
X       versions.  Linda's response was to teach Joe about SCCS
X       (Source Code Control System -Ed.), and showing him how he
X       could keep old releases without making a copy of the entire
X       source tree. Joe was satisfied, and Linda was able to
X       reclaim a significant amount of disk space.
X
X       Another example is the day Jim Smart walked into her office,
X       and demanded to know the root password. Linda was able to
X       reject Jim's request on the spot, and expect to be backed up
X       by her manager, because Linda had written the Site Policy,
X       and had top management sign off on it.
X
X       In all such cases, information, education and communication
X       proved to be essential.
X
X
X
X
X
X
X
X
X
X
X
X                                  - 11 -
X
X
X
X                         Let UNIX Help You Manage
X
X       UNIX provides a number of tools which help the system
X       manager or administrator communicate with the user
X       community.  Most of these are well known and used at most
X       sites, but for completeness, let us see how Linda used these
X       tools.
X
X       The classical method is of course email.  One of the first
X       things Linda did was to establish a mail alias, ``all'',
X       which could be used to email all users about downtime,
X       changes, or other inconveniences.  She wrote a small script
X       that ensured this alias always was automatically updated
X       from the password file, and therefore always representative
X       of the existing user community.  For communication from the
X       users to the system administrators, she made a special
X       account, ``sysadmin'' which was forwarded to the operators.
X
X       She also made it a policy that all messages sent out by
X       email should be reflected in the Message Of The Day file
X       (/etc/motd) and vice-versa.  By making the information
X       redundant, she was able to reach more users, although few
X       users did log in on a regular basis, in the workstation
X       environment at Buildmore Technologies.
X
X       A third method for communicating this kind of information is
X       found in UNIX System V with the news command.  This command
X       allows the system administrator to maintain a number of
X       files with information about system status which is shown to
X       the users during login.  Because Buildmore Technologies was
X       using mostly BSD-based workstations, Linda decided not to
X       use this facility on the few AT&T systems on the site (news
X       should not be confused with the Usenet news).
X
X       Besides using these methods for communicating with the
X       users, Linda also circulated all the memos she wrote for
X       Dave (see the first article) to all the users, with requests
X       for comments.  All the relevant feedback she got was worked
X       into the final documents.  This worked especially well in
X       her case, as she was new to Buildmore Technologies.  Lots of
X       information about previous decisions and configurations was
X       explained to her by engineers who had been at Buildmore for
X       years.  As this information was documented nowhere other
X       than in the brains of those people, she was able to obtain
X       information which kept her from making several important
X       mistakes.
X
X       Most important, Linda wanted to ensure that communications
X       with her users were working both ways. She therefore let
X       everybody know that she always was available for a chat
X       about problems or suggestions from the users, and many
X
X
X
X
X
X
X
X
X
X
X
X                                  - 12 -
X
X
X
X       potential problems were avoided or easily solved by such
X       informal meetings.  It would not have been possible to run
X       the site without the framework Linda had put in place in the
X       form of policies and procedures, but none of these created
X       so much trust and rapport with the users as these meetings.
X
X                     Dealing With Humans Is Necessary
X
X       By treating both managers and users as human beings, and by
X       establishing sound policies for the UNIX system management,
X       she was able to protect Buildmore Technologies from serious
X       system failures.  Through establishing both functional
X       procedures for system management and establishing good
X       rapport with people using UNIX - whether manager or user -
X       she created effective feedback which helped her prevent most
X       of the problems seen in less well-run sites.
X
X       The picture painted of Linda and Buildmore Technologies may
X       seem completely unrealistic to some readers, but skeptics
X       can be assured that these methods work. In the real world,
X       there are both incompetent managers and unreasonable users,
X       but a competent system manager can still create a well
X       administrate and well functioning site in spite of such
X       people.
X
X       In addition to technical skills, the key to successful UNIX
X       system management is providing lots of ``TLC'' to users and
X       managers, and to remember that sometimes ``CYA'' can be
X       necessary.
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
END_OF_FILE
echo shar: 61 control characters may be missing from \"'misc/art.rt'\"
if test 29944 -ne `wc -c <'misc/art.rt'`; then
    echo shar: \"'misc/art.rt'\" unpacked with wrong size!
fi
# end of 'misc/art.rt'
fi
if test -f 'misc/art.ur2' -a "${1}" != "-c" ; then
  echo shar: Will not clobber existing file \"'misc/art.ur2'\"
else
echo shar: Extracting \"'misc/art.ur2'\" \(15924 characters\)
sed "s/^X//" >'misc/art.ur2' <<'END_OF_FILE'
X
X
X
X
X
X
X
X       $Id: art.ur2.N,v 5.3.2.5 91/09/03 09:55:38 policy USENET $
X
X              Revised from "Famous Last Words", UNIX REVIEW,
X                        July 1991 (Vol. 9, No. 7)
X
X
X                         AAAA GGGGLLLLIIIIMMMMPPPPSSSSEEEE OOOOFFFF TTTTHHHHEEEE GGGGAAAALLLLLLLLOOOOWWWWSSSS
X
X                              by Bud Hovell
X
X
X       ``_A _g_l_i_m_p_s_e _o_f _t_h_e _g_a_l_l_o_w_s _h_a_s _a _m_a_r_v_e_l_o_u_s _w_a_y _o_f _f_o_c_u_s_s_i_n_g
X       _t_h_e _m_i_n_d.''  - Dr. Ben Johnson
X
X
X       IIIInnnnttttrrrroooodddduuuuccccttttiiiioooonnnn
X
X       There is evidence of growing concern by administrators in
X       the UNIX community and elsewhere about how to achieve an
X       appropriate level of control over the local computing
X       environment through policy guidance.
X
X       Indeed, policy is now becoming a hot topic.  More adminis-
X       trators recognize increasing need to assure that users
X       (including themselves) will not subvert the organizational
X       mission or system integrity, violate basic minimum standards
X       of courtesy, privacy, and ethics, or inadvertently incur
X       criminal or civil liabilities.
X
X       It is not true that ``people are no damn good'', and that
X       one must, therefore, check their tendency to intentional
X       diabolic mischief. There is no need to imprison users.
X
X       But with a numerical expansion of ordinary login users and
X       an obscene abundance of eager lawyers, the preparation and
X       maintenance of carefully crafted policy eventually may
X       become a precondition for networking survival. (It may even
X       come to pass that some body of fundamental policy "stan-
X       dards" may be adopted in order to avoid the chaos of having
X       each organization gin up its own home-spun protocol, result-
X       ing in a crazy-quilt of policy definitions which mainly
X       differ only in choice of language.)
X
X       The current trend seems certain to head us all into higher
X       levels of risk.  Administrators who now express concern
X       about these growing risks may turn out to have been the
X       ``futurists''.
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X                                  - 2 -
X
X
X
X       SSSSoooo WWWWhhhhaaaatttt''''ssss tttthhhheeee NNNNeeeewwwwssss????
X
X       A recent voluntary survey we conducted among system adminis-
X       trators and system managers on the uuuusssseeeennnneeeetttt drew returns from
X       nearly 300 respondents located at educational, commercial,
X       and other organizations.  These locations serve some 100,000
X       users, and most have more than a hundred users each.  These
X       points emerge for immediate comment.
X
X       Half of administrators and system managers say they have
X       held primary authority to define policies, and two-thirds
X       that they have been the primary enforcement authority -- and
X       will be so in the future.
X
X       Allowing policy to be primarily defined by individual user
X       practices has been the historical case at one-third of
X       sites, but this will dramatically decline to only one-fifth
X       in the future.
X
X       Verbal transmission of policy has been the dominant pattern
X       at half of all sites, historically, but will fall to only
X       one-quarter of sites.
X
X       Fewer than ten percent of administrators identify upper
X       management decisions as the source of primary authority,
X       either for policy definition or for policy enforcement. And
X       they forecast only a faint upward trend.
X
X       So there is some good news -- and some bad.
X
X       TTTThhhheeee GGGGoooooooodddd NNNNeeeewwwwssss
X
X       Evidently, allowing each user to ``do his own thing'' is
X       going to be a fading practice as time goes on, and the
X       majority of administrators will assert their own authority
X       to influence adoption of more formal definition and enforce-
X       ment of local policy.
X
X       Administrators hold positions of trust by demonstrating both
X       technical knowledge and personal integrity. They must sup-
X       port the needs of users, while also fending off unwarranted
X       threats to the system itself.
X
X       Also, administrators have the most intimate knowledge of
X       system (and user) behavior, and are thus able to offer
X       unique insight for the framing of effective written policy.
X
X       They are also, therefore, the logical first persons for
X       users to turn to for expert guidance on policy interpreta-
X       tion and computer usage procedures.
X
X
X
X
X
X
X
X
X
X
X
X
X                                  - 3 -
X
X
X
X       TTTThhhheeee BBBBaaaadddd NNNNeeeewwwwssss
X
X       What should throw up a red flag to even the most casual
X       observer is the almost total lack of mention of top manage-
X       ment as the primary authority for either definition or
X       enforcement of how computer resources will be used.
X
X       Top management members have no more valuable function than
X       to underwrite key policy decisions upon which everyone will
X       depend for effective, coordinated action. And this simply
X       doesn't appear to be happening for computer resource policy.
X       This creates a yawning chasm of uncertainty for everyone --
X       and not least for the system administrator.
X
X       The administrator may be the main agent for working with
X       users and supervisors to define and present the policy pro-
X       posal. But without top management as the approving and
X       enforcing authority, the adminstrator may be sailing in
X       treacherous waters, indeed: he or she should help forge and
X       operate the levers of policy, but should _n_e_v_e_r be pressed
X       into service as the ultimate fulcrum of authority.
X
X       PPPPoooolllliiiiccccyyyy aaaannnndddd AAAAuuuutttthhhhoooorrrriiiittttyyyy
X
X       It is often appropriate to delegate responsibility and
X       authority as far down into the organization as possible. But
X       top management is not then free to simply disappear; it must
X       still stand firmly and visibly behind those policies upon
X       which the organization relies to limit exposure to poten-
X       tially grievous mistakes that could be costly in a networked
X       environment.
X
X       In a recent article, ``Policies for Appropriate Use of Net-
X       work and Computing Resources'', CERFnet News, May 1991 (Vol.
X       3, No. 4), Brent Auernheimer points out:
X
X          In addition to defining acceptable user behavior, poli-
X          cies provide a locus of action in which administrators
X          can operate confidently and that supervisors can justify.
X
X          It is important that when incidents of inappropriate
X          behavior arise, system administrators have options avail-
X          able other than to immediately cut off accused users, or
X          to do nothing, allowing the possible misuse to continue.
X
X          A well written policy is essential in making fair, defen-
X          sible decisions.
X
X       When required to act, the administrator must have clearly
X       defined authority which only top management can legitimately
X       give.
X
X
X
X
X
X
X
X
X
X
X
X                                  - 4 -
X
X
X
X       It should be the administrator's first priority to gain this
X       authority by any ethical means. This may require dragging
X       the dark hearse of potential lawsuit through the legal
X       department and right up to the front door of the executive
X       offices -- or simply re-flavoring the dish to match the con-
X       temporary tastes of upper management (_s_e_e _N_o_t_e).
X
X       Every reasonable measure should be taken by the administra-
X       tor to ensure his or her decisions will never be undercut by
X       someone higher up. One never knows for sure that top manage-
X       ment backing is solid until controversy actually presents
X       the acid test. ``Real'' policy is only what top management
X       will back to the hilt.
X
X       The only thing more dreadful than no policy at all is having
X       one that deceives by offering a false promise of full sup-
X       port which falters in the breech.  Policies which receive
X       public, written endorsement from top management rarely
X       suffer this fate.
X
X       FFFFooooccccuuuussssssssiiiinnnngggg tttthhhheeee MMMMiiiinnnndddd
X
X       When developing policy, one should keep a sharp eye on the
X       gallows.  From a front-row seat, if possible.
X
X       Writing effective policy is nothing less than the dead-
X       serious business of formulating strategies to successfully
X       cheat the hangman at every turn.  Right now, it appears that
X       most of what exists for a guide is legal and lay speculation
X       -- but few tangible court rulings.
X
X       Now, I'm no lawyer (and will never play one on TV), so when
X       I hear that there is a significant new area of law about
X       which even the courts haven't really spoken, I become only
X       mildly tuned in to the discussion.  But when I realize that
X       my company could conceivably be invited to help define that
X       new law in the form of an unappetizing lawsuit where no one
X       has even a vague notion of what the outcome will be, then my
X       thoughts become more sober.
X
X       Such concern should not be lightly dismissed: juries come in
X       with some pretty weird findings these days. And lawyers get
X       their reputations not only by winning, but by being credited
X       with defining "new law", invariably at someone else's
X       expense.
X
X       It may be reasonable to assume that any organization operat-
X       ing today in a networked environment probably is exposed to
X       some sort of workable claim which might be troublesome to
X       resolve under threat of suit. Someone will eventually be
X       nominated to be "it" in this game of legal blindmans-bluff.
X
X
X
X
X
X
X
X
X
X
X
X                                  - 5 -
X
X
X
X       One would wish to ward off an invitation to the platform to
X       share in this dubious honor.
X
X       DDDDooooddddggggiiiinnnngggg tttthhhheeee NNNNoooooooosssseeee
X
X       Since the courts offer little valuable guidance about how to
X       safely proceed in an internetworked environment, the best
X       available substitute may well be the experience of the
X       administrator, expressed within written policies which top
X       management is willing to endorse.  (Competent legal review
X       wouldn't hurt either, but don't make the mistake of turning
X       over the main task to your lawyer: he'll want to write it
X       for court, and you must be sure it's written, instead, for
X       people.)
X
X       Indeed, the very best available defense under fire may prove
X       to be formal, well-advertised policy which preexists any
X       claim by a user that his rights were grievously violated as
X       the consequence of transactions and behaviors between per-
X       sons in a multi-user environment (for which management might
X       be held liable).
X
X       Management, according to its particular mission, has the
X       duty of asserting adequate policy control over how owned
X       resources shall be used. Failure to publically articulate
X       such policy before a claim arises may be tantamount to
X       pleading ``no contest''.
X
X       PPPPllllaaaaiiiinnnn JJJJuuuussssttttiiiicccceeee
X
X       Ultimately, the motivation and rational for publishing
X       comprehensive and appropriate policy has less to do with
X       fear of brutish court proceedings and much more to do with
X       fundamental human courtesy and plain, simple justice.
X
X       Providing sound, thoughtful policies for the users in an
X       organization is not just a nice thing to do. It's the
X       responsible thing to do.
X
X       No real substitute exists for letting people know, right up
X       front, what is really expected of them. Putting it in a con-
X       cise form that is forthright and unambiguous helps defeat
X       private interpretation, which invariably rushes to fill a
X       vacuum. It is then absolutely reasonable to expect users to
X       fully live up to it. The vast majority will do so with a
X       willing sense of responsibility and no complaints.
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X                                  - 6 -
X
X
X
X                                 [ NOTE ]
X
X       PPPPoooolllliiiiccccyyyy IIIIssss QQQQuuuuaaaalllliiiittttyyyy
X
X       The administrative staff at the Midget-Widget Manufacturing
X       Company recently received the following missive from the MIS
X       Manager:  ``_I_n_c_r_e_m_e_n_t_a_l _b_a_c_k_u_p_s _o_f _a_l_l _u_s_e_r _f_i_l_e_s _w_i_l_l _b_e
X       _p_e_r_f_o_r_m_e_d _b_y _t_h_e _o_n-_d_u_t_y _a_d_m_i_n_i_s_t_r_a_t_o_r _b_e_g_i_n_n_i_n_g _a_t _1_1 _p_m
X       _e_a_c_h _d_a_y, _e_x_c_e_p_t _t_h_a_t _o_n _F_r_i_d_a_y _i_t _w_i_l_l _b_e _a _f_u_l_l _b_a_c_k_u_p.''
X
X       System administrators now have a very specific procedure
X       about what actions must be taken, when, and by whom.  But
X       what the administrator staff never saw was this previously-
X       written policy directive to the MIS Manager from the General
X       Manager at Midget-Widget:  ``_A_l_l _l_o_c_a_l _c_o_m_p_u_t_e_r_s _m_u_s_t _b_e
X       _b_a_c_k_e_d _u_p _a_t _a _f_r_e_q_u_e_n_c_y _t_o _e_n_s_u_r_e _t_h_a_t _a_n_y _s_y_s_t_e_m _f_a_i_l_u_r_e,
X       _n_a_t_u_r_a_l _d_i_s_a_s_t_e_r, _o_r _o_t_h_e_r _c_a_l_a_m_i_t_y _w_i_l_l _n_e_v_e_r _r_e_s_u_l_t _i_n
X       _m_o_r_e _t_h_a_n _e_i_g_h_t _h_o_u_r_s _l_o_s_t _w_o_r_k-_p_r_o_d_u_c_t _f_o_r _a_n_y _l_o_g_i_n
X       _u_s_e_r.''  Notice that the General Manager has defined his
X       policy in terms of a specific, measurable outcome -- that
X       lost work-product for any user may never exceed eight hours.
X       Now we can fully understand the standard the MIS Manager is
X       trying to meet in the procedure that he has written for his
X       own staff.
X
X       Regrettably, the procedure must be rejected. The Human
X       Resources Manager tells us that there is a new programmer
X       just hired who will begin working four 10-hour days each
X       week so that he can have more time to visit his sick mother
X       in San Pedro. Also, Midget-Widget has extraordinarily dedi-
X       cated users who routinely stay an hour or so late to finish
X       up their work.
X
X       So the the MIS Manager must now redesign his procedure to
X       handle all known exceptions. Or negotiate with the General
X       Manager to change the stated standard.
X
X       With an outcome-oriented policy in place, weighing the suf-
X       ficiency and appropriateness of procedure becomes a much
X       simpler task, and helps make solid quality-enhancement of
X       the user environment an achievable goal.  Though top
X       managers may not always support strong ``policy'', they may
X       stand in line to sign up for what you present as ``qual-
X       ity''!
X
X       [ Author Bio ]
X
X       Bud Hovell is a productivity and project management special-
X       ist with MMMMTTTTEEEEKKKK IIIInnnntttteeeerrrrnnnnaaaattttiiiioooonnnnaaaallll,,,, IIIInnnncccc....
X
X
X
X
X
X
X
X
X
X
END_OF_FILE
echo shar: 881 control characters may be missing from \"'misc/art.ur2'\"
if test 15924 -ne `wc -c <'misc/art.ur2'`; then
    echo shar: \"'misc/art.ur2'\" unpacked with wrong size!
fi
# end of 'misc/art.ur2'
fi
echo shar: End of archive 3 \(of 3\).
cp /dev/null ark3isdone
MISSING=""
for I in 1 2 3 ; do
    if test ! -f ark${I}isdone ; then
    MISSING="${MISSING} ${I}"
    fi
done
if test "${MISSING}" = "" ; then
    echo You have unpacked all 3 archives.
    echo "'This is usenet version 5.3.2.5 of 91/09/03.'"
    rm -f ark[1-9]isdone
else
    echo You still need to unpack the following archives:
    echo "        " ${MISSING}
fi
##  End of shell archive.
exit 0
--
Bud Hovell
_______________
[e-mail]