Helpfor UNIX System Administrators
`
`Essential
`
`System
`Administration
`
`O'REILLY*
`
`Meen Frisch
`
`Canon Exhibit 1110
`
`Page 1 of 55
`
`

`

`Essential System Administration
`Second Edition
`
`i^leen Frisch
`
`O'REILLY®
`Beijing • Cambridge • Famham • Koln • Paris • Sebastopol • Taipei • Tokyo
`
`Canon Exhibit 1110
`
`Page 2 of 55
`
`

`

`Essential System Administration. Second Edition
`by JEleen Frisch
`
`Copyright © 1991, 1995 O'Reilly& Associates, Inc. All rights reserved.
`Printed in the United States of America.
`
`Editor: Mike Loukides
`
`Production Editor: Nicole Gipson
`
`Printing History:
`
`October 1991:
`
`First Edition.
`
`January 1992:
`
`August 1992:
`
`January 1993:
`
`Minor corrections.
`
`Minor corrections.
`
`Minor corrections.
`
`September 1995:
`
`Second Edition.
`
`December 1995:
`
`Minor corrections.
`
`Nutshell Handbook, the Nutshell Handbook logo, and the O'Reilly logo are registered
`trademarks and The Java^®^ Series is a trademark of O'Reilly& Associates, Inc.
`
`Many of the designations used by manufacturers and sellers to distinguish their products are
`claimed as trademarks. Where those designations appear in this book, and O'Reilly &
`Associates, Inc. was aware of a trademark claim, the designations have been printed in caps
`or initial caps.
`
`While every precaution has been taken in the preparation of this book, the publisher assumes
`no responsibility for errors or omissions, or for damages resulting from the use of the
`information contained herein.
`
`ISBN: 1-56592-127-5
`[M]
`
`[1/00]
`
`Canon Exhibit 1110
`
`Page 3 of 55
`
`

`

`xii
`
`Preface
`
`Naturally, some of this information will constitute advice about system administra
`tion; I won't be shy about letting you know what my opinion is. But I'm actually
`much more interested in giving you the information you need to make informed
`decisions for your own situation than in providing a single, univocal view of the
`"right way" to administer a UNIX system. It's more important that you know what
`the issues are concerning, say, system backups, than that you adopt anyone's spe
`cific philosophy or scheme. When you are familiar with the problem and the
`potential approaches to it, you'll be in a position to decide for yourself what's right
`for your system.
`
`Although this book will be useful to anyone who takes care of a UNIX system, I
`have also included some material designed especially for system administration
`professionals. Another way that this book covers essential system administration is
`that it tries to convey the essence of what system administration is, as well as a
`way of approaching it when it is your job or a significant part of it. This encom
`passes intangibles like system administration as a profession, professionalism (not
`the same thing), human and humane factors inherent in system administration, and
`its relationship to the world at large. When such issues are directly relevant to the
`primary, technical content of the book, I mention them. In addition, I've included
`other information of this sort in special sidebars (the first one comes later in this
`Preface). They are designed to be informative and thought-provoking, and are, on
`occasion, deliberately provocative.
`
`The UNIX Universe
`More and more, people find themselves taking care of multiple computers, often
`from more than one manufacturer; it's quite rare to find a system administrator
`who is only responsible for one system (unless he has other, unrelated duties as
`well). While UNIX is widely lauded in marketing brochures as the "standard" oper
`ating system "from microcomputers to supercomputers"—and I must confess to
`having written a few of those brochures myself—^this is not at all the same as there
`being a "standard" UNIX. At this point, UNIX is hopelessly plural, and nowhere is
`this plurality more evident than in system administration. Before going on to dis
`cuss how this book addresses that fact, let's take a brief look at how things got to
`be the way they are now.
`
`The following diagram attempts to capture the current state of things. It illustrates
`a simplified UNIX genealogy, with an emphasis on influences and family relation
`ships (albeit Faulknerian ones) rather than on strict chronology and historical
`accuracy. It traces the major lines of descent from an arbitrary point in time: UNIX
`Version 6 in 1975 (note that the dates in the diagram refer to the earliest rnanifesta-
`tion of each version). Over time, two distinct flavors (strains) of UNIX emerged
`from its beginnings at AT&T Bell Laboratories—^which I'll refer to as System V and
`BSD—but there was also considerable cross-influence between them (in fact, a
`more detailed diagram would indicate this even more clearly).
`
`Canon Exhibit 1110
`
`Page 4 of 55
`
`

`

`Preface
`
`xiii
`
`- direct descent
`
`- strong influence
`
`AT&T Bell Labs
`(c.1969-1970)
`
`XENIX
`(1979 onward)
`
`Version?
`(1979)
`
`System III
`(1982)
`
`System V.2
`(1984)
`
`OSF/1
`(C.I 992)
`
`System V.4
`(1988)
`
`4.2 BSD
`(1984)
`
`4.3 BSD
`(1985)
`
`4.4 BSD
`(1993)
`
`Figure 1: UNIXgenealogy (simplified)
`
`The split we see today between System V and BSD occurred after Version 6.^ The
`developers at the University of California, Berkeley extended UNIX in many ways,
`
`t The movement from Version 7 to System III in the System V line is a simplification of strict
`chronology and descent. System III was derived from an intermediate release between Ver
`sion 6 and Version 7 (CB unix), and not everyVersion 7 feature was included in System III.
`A word about nomenclature: The successive releases of UNIX from the research group at
`Bell Labs were originally known as "editions"—^the Sixth Edition, for example—^although
`these versions are now generally referred to as "Versions." After Version 6, there are two
`distinct sets of releases from Bell Labs: Versions 7 and following (constituting the original
`research line), and System III through System v (commercial implementations started from
`this line). Laterversions of SystemV are called "Releases," as in SystemV Release 3 and Sys
`tem V Release 4.
`The opening chapters of Lifewith UNIX, by Don Libes and Sandy Ressler (PTR Prentice Hall,
`Special Edition, 1992), give a very entertaining overview of the history of UNIX; the preface
`to the Special Edition updates events through about 1992.
`
`Canon Exhibit 1110
`
`Page 5 of 55
`
`

`

`xiv
`
`Preface
`
`to
`job control, TCP/IP networking,
`the C shell,
`adding virtual memory support,
`name just a few. Some of these contributions were merged into the AT&T code
`lines at various points.
`
`System V Release 4 is often described as a merger of the System V and BSD lines,
`but this is not quite accurate. It incorporates the most important features of BSD
`(and SunOS) into System V. The union is a marriage and not a merger, however,
`with some but not all characteristics from each parent dominant in the offspring
`(as well as a few whose origins no one is quite sure of). In this book, I'll refer to
`System V Releases 3 and 4 as V.3 and V.4 respectively.
`
`The diagram also includes two other variations: XENIX and OSF/1. XENIX, the first
`microcomputer UNIX version, is still in use today. It was derived from Version 7
`and converted to System V Release 2 gradually over time. XENIX then in turn influ
`enced System V Release 3 when many of its capabilities were merged into System
`V Release 3.2.
`
`In 1988, Sun and AT65:T agreed to jointly develop future versions of System V. In
`response, IBM, DEC, Hewlett-Packard, and other computer and computer-related
`companies and organizations formed the Open Software Foundation (OSF), design
`ing it with the explicit goal of producing an alternative, compatible, non-AT&T-
`dependant UNIX-like operating system. OSF/1 is the result of this effort"^ (although
`its importance is more as a standards definition than as an actual operating system
`implementation).
`
`the 1980's brought
`The proliferation of new computer companies throughout
`dozens of new UNIX, systems to market—^UNEX was usually chosen as much for its
`low cost and lack of serious alternatives than for its technical characteristics—and
`also as many variants. These vendors tended to start with some version of System
`V or BSD and then make small
`to extensive modifications and customizations.
`Extant operating systems mostly spring from System V Release 3 (usually Release
`3.2), System V Release 4, and occasionally 4.2 or 4.3 BSD (SunOS is the major
`exception, derived from an earlier BSD version). As a further complication, many
`vendors freely intermixed System V and BSD features within a single operating sys
`tem.
`
`Recent years have seen a number of efforts at standardizing UNDC.^ Competition
`has
`shifted
`from acrimonious
`lawsuits
`and countersuits
`to
`surface-level
`
`t As well as, and perhaps more importantly, Motif and the Distributed Computing Environ
`ment (DCE).
`t The most important general standards are POSIX (defined by the IEEE/ANSI), AT&T's System
`V Interface Definition (SVID Issue 2 is System V Release 3, and SVID Issue 3 is System v
`Release 4), the OSF's Application Environment Specification (AES), and the X/Open Portabil
`ity Guide (currently XPG4) from X/Open, a consortium founded in the United Kingdom in
`1984 that now exists for the purpose of defining UNIX standards. X/Open controls the UNIX
`trademark and accordingly has the power to test and validate compliance with its standard,
`thereby awarding or withholding the right for an operating system to be called UNIX (the
`validation process is known as "branding"). Of all of these standards, only POSIX can truly
`be said to be vendor-independent.
`
`Canon Exhibit 1110
`
`Page 6 of 55
`
`

`

`Preface
`
`xv
`
`cooperation in unifying the various versions. However, existing standards simply
`don't address system administration at anything beyond the most superficial level.^
`Since vendors are free to do as they please in the absence of a standard, there is
`no guarantee that system administrative commands and procedures will even be
`similar under different operating systems that uphold the same set of standards.
`
`UNIX Versions Discussed in This Book
`How do you make sense out of the myriad of UNIX variations? One approach is to
`use computer systems only from a single vendor. However, since that often has
`other disadvantages, most of us end up having to deal with more than one kind of
`UNIX system. Fortunately, taking care of n different kinds of systems doesn't mean
`that you have to learn as many different administrative command sets and
`approaches. Ultimately, we get back to the fact that there are really just two dis
`tinct UNIX varieties; it's just that the features of any specific UNIX implementation
`can be an arbitrary mixture of System V and BSD features (regardless of its history
`and origins). This doesn't always ensure that there are only two different com
`mands to perform the same administrative function—there are cases where practi
`cally every vendor uses a different one—^but it does mean that there are generally
`just two different approaches to the area or issue. And once you understand the
`underlying structure, philosophy, and assumptions,
`learning the specific com
`mands for any given system is simple.
`
`juggling several UNIX ver
`When you recognize and take advantage of this fact,
`sions becomes straightforward rather than impossibly difficult. In reality,
`lots of
`people do it every day, and this book is designed to reflect that and support them.
`It will also make administering heterogeneous environments even easier by sys
`tematically providing information about different systems all in one place.
`
`The UNIX versions covered by this book appear in Figure 1-2, which illustrates the
`influences on the various operating systems, rather than their actual origins.''' Each
`of them is described briefly in the following list; the icons which appear to the left
`of each name indicate ,the degree to which a particular version acts and feels more
`like a System V system or a BSD system from a system administration point of
`view.
`
`t POSIX.7 is designed to address this lack, but it is still in the early discussion stage.
`t If the version on your system isn't one of them, don't despair. Read on anyway, and you'll
`find that the general information given here applies to your system as well in most cases.
`Note that HP-UX 9 derives from V.3 rather than V.4.
`The names of some of these operating systems may very well change within the lifetime of
`this book as they become officially UNIX branded.
`
`Canon Exhibit 1110
`
`Page 7 of 55
`
`

`

`In This Chapter:
`• The System
`Administrator'sJob
`• Becoming Supentser
`• Communicating with
`Users
`• Menu Interfacesfor
`System
`Admtntstmtkm
`
`Intvoductton to
`System Administration
`
`The System Administrator'sJob
`A plausible, even traditional, way to begin a book like this is to provide a list of
`system management tasks. I'm not sure such lists are really worth much, although
`I will provide one in a moment. I think they leave out too many intangibles, the
`sort of things that take up a lot of time or energy, but never make it into job
`descriptions. Lists also tend to suggest that system management has some kind of
`coherence across the vastly different environments where people find themselves
`responsible for or taking care of computers. There are similarities, of course, but
`what is important on one system won't necessarily be on another at another site,
`or on the same system at a different time. And systems that are very different may
`have similar system management needs, while nearly identical systems in different
`environments might have very different ones.
`
`But now to the list. In lieu of an idealized list, I offer the following unordered
`recitation of the things I spent the most time doing the last time my official job title
`was "System Administrator," a position in which I managed several central systems
`driving numerous CAD/CAM workstations:
`
`• Adding new users.
`
`• Adding toner to electrostatic plotters.
`
`• Doing backups.
`
`•
`
`Restoring files from backups that users had accidentally deleted or trashed.
`
`• Answering user questions ("How do I send mail?"), usually not for the first or
`last time.
`
`Canon Exhibit 1110
`
`Page 8 of 55
`
`

`

`Chapter 1: Introduction to System Administration
`
`• Monitoring system activity and trying to tune system parameters to make these
`overloaded systems have the response time of an idle system.
`
`• Moving jobs up in the print queue, after more or less user whining, pleading
`or begging, contrary to stated policy (about moving jobs, not about whining).
`
`• Worrying about system security and plugging the most noxious security holes I
`had inherited.
`
`•
`
`•
`
`Installing programs and operating system updates.
`
`Trying to free up disk space (and especially contiguous disk space).
`
`• Rebooting the system after a crash (always at late and inconvenient times).
`
`•
`
`Straightening out network glitches ("Why isn't hamlet talking to Ophelia?"}-
`Occasionally, this involved physically tracing the Ethernet cable around the
`building, checking it at each node.
`
`• Rearranging furniture to accommodate new equipment; installing said equip
`ment.
`
`•
`
`•
`
`•
`
`Figuring out why a program/command/account suddenly and mysteriously
`stopped working since yesterday, even though the user swore that he had
`changed nothing.
`
`Fixing—or rather, trying to fix—corrupted CAD/CAM binary data files.
`
`Going to meetings.
`
`• Adding new systems to the network.
`
`• Writing scripts to automate as many of the above activities as possible.
`
`As this list indicates, formal system management is truly a hodgepodge of activi
`ties, and involves at least as many people skills as computer skills. While I'll offer
`some advice along these lines in a moment, interacting with people is best learned
`by watching others, emulating their successes, and avoiding their mistakes.
`
`Currently, I set up and look after a potpourri of workstations from many different
`vendors, as well as a couple of larger systems (in terms of size but not necessarily
`CPU power), with some PCs thrown in to keep things interesting. Despite these
`significant hardware changes, it's surprising how many of the preceding activities I
`still have to do. Adding toner may now mean changing a toner cartridge in a laser
`printer, backups now go to floppy disk and 8mm tape rather than 9-track tape,
`and user problems and questions are in different areas but are still very much on
`the list. And while there are (thankfully) no meetings,^ there's probably even more
`furniture moving and cable tracing.
`
`t Well, no formal ones anyway. There are lots of informal discussions about system admin
`istrative issues like security, Internet access, security, whether to set up a World Wide Web
`server, security—^you get the idea.
`
`Canon Exhibit 1110
`
`Page 9 of 55
`
`

`

`The System Administrator'sJob
`
`Some of these topics—^moving furniture and going to or avoiding meetings, most
`obviously—are beyond the scope of this book. Other topics, like system tuning,
`can't be treated exhaustively; the reason is usually because the topic is just too
`large. In these cases, however, I'll point you in the direction of another book that
`takes up where I leave off (the full references are always given in the Bibliogra
`phy. This book will cover most of the ordinary tasks that fall under the category
`of "system administration." The discussion will be relevant to you whether you've
`got a single 486 or Pentium (running UNIX), a room full of mainframes, a building
`full of networked workstations, or a cornbination of several types of computers.
`Not all topics will apply to everyone, but I've learned not to rule out any of them
`a priori for a given class of user. For example, it's often thought that only big sys
`tems need accounting, but it's now very common for small businesses to address
`their computing needs with a moderately-sized UNIX system, and they need to be
`able to bill their customers individually. The moral
`is: take what you need and
`leave the rest; you're the best judge of what's relevant and what isn't.
`
`I've touched briefly on some of the nontechnical aspects of system administration.
`These dynamics will probably not be an issue if it really is just you and your 486
`(or you and your Cray, for that matter), but if you interact with other people at all,
`they will come up. It's a cliche that system administration is a thankless job—one
`widely-reprinted cartoon has a user saying "I'd thank you but system administra
`tion is a thankless job"—^but things are actually more complicated than that. As
`another cliche puts it, system administration is like keeping the trains on time; no
`one notices except when they're late.
`
`System management often seems to involve a tension between authority arid
`responsibility on the one hand and service and cooperation on the other. The
`extremes seem easier to maintain than any middle ground; fascistic dictators who
`rule "their system" with an iron hand, unhindered by the needs of users, find their
`opposite in the harried system managers who jump from one user request to the
`next,
`in continual interrupt mode. The trick is to find a balance between being
`accessible to users and their needs, and sometimes even their mere wants, while
`still maintaining your authority and sticking to the policies you've put in place for
`the overall system welfare. The goal is to provide an environment where users can
`get what they need to do done,
`in as easy and efficient a manner as possible,
`given the constraints of security, other users' needs, the inherent capabilities of the
`system, and the realities and constraints of the human community in which all of
`them are located.
`
`To put it more concretely, the key to successful, productive system administration
`is knowing when to solve a CPU-overuse problem with a command like:"'"
`
`# kill -9 "ps -ef I awk '$l=="cdiavez" {print $2}'"
`
`t Under SunOS and Linux, you'd use ps aux for the first command in the pipe (this form will
`also work on Solaris, AIX, and Digital UNIX systems).
`
`Canon Exhibit 1110
`
`Page 10 of 55
`
`

`

`Chapter 1: Introduction to System Administration
`
`(this command blows away all of user Chavez's processes), and it's also knowing
`when to use:
`
`$ write Chavez
`You've got a lot of identical processes running on dalton.
`An^ problem I can help with?
`
`and when to walk over to her desk and talk with her face-to-face. The first
`approach displays UNIX finesse as well as administrative brute force, and both are
`certainly appropriate—even vital—at times. At other times, a simpler, less aggres
`sive approach will work better to resolve your system's performance problems as
`well as the user's confusion. It's also important to remember that there are some
`problems no UNIX command can address.
`
`To a great extent, successful system administration is a combination of careful
`planning and habit, however much it may seem like crisis intervention at times.
`The key to really handling a crisis well is having had the foresight and taken the
`time to anticipate and plan for exactly the emergency that has just come up (or at
`least some approximation of it). As long as it only happens once in a great while,
`snatching victory from the jaws of defeat can be very satisfying and even exhilarat
`ing.
`
`On the other hand, many crises can be prevented altogether by a determined
`devotion to carrying out all the careful procedures you've designed: changing the
`root password regularly, faithfully making backups (no matter how tedious), log
`ging out and clearing the terminal screen as a ritual, testing every change several
`times before letting it loose, sticking to policies you've set for users' benefit—
`whatever you need to do for your system. (As Emerson said, "a foolish consistency
`is the hobgoblin of little minds," but not a wise one.)
`
`My philosophy of system administration boils down to a few basic strategies which
`can be applied to virtually any task that it encompasses:
`
`•
`
`Plan it before you do it.
`
`• Make it reversible.
`
`• Make changes incrementally.
`
`•
`
`Test, test, test, before you unleash it on the world.
`
`• Know how things really work.
`
`I learned some of these things from a friend who worked in a museum putting
`together ancient pottery fragments: always make it reversible. The museum fol
`lowed this practice so that
`if better reconstructive techniques were developed
`decades from now, they could undo the current work and use the better method.
`As far as possible, I've tried to do the same with computers, adding changes grad
`ually and preserving a path by which to back out of them.
`
`Canon Exhibit 1110
`
`Page 11 of 55
`
`

`

`Becoming Supermer
`
`A simple example of this sort of attitude in action concerns editing system configu
`ration files. UNIX systems rely on many configuration files, and every major subsys
`tem has its own files (all of which we'll get to). Many of these will need to be
`modified from time to time.
`
`I never modify the original copy of the configuration file, either as delivered with
`the system or as I found it when I took over the system. Rather, I always make a
`copy of these files the first time I change them, appending the suffix .dist to the
`filename; for example:
`
`# cd /etc
`# CP inittab inittab.dist
`# chinod a-w inittab.dist
`
`I write-protect the .dist file so I'll always have it to refer to. On systems that sup
`port it, use the cp command's -p option to replicate the file's current modification
`time into the copy.
`
`I also make a copy of the current configuration file before changing it in any way
`so undesirable changes can be easily undone. I add a suffix like .old or .sav to the
`filename for these copies. At the same time, I formulate a plan (at least
`in my
`head) about how I am going to recover from the worst consequence of an unsuc
`cessful change that I can envision (e.g., I'll boot to single-user mode and copy the
`old version back).
`
`Once I've made the changes I need to (or the first major change when several are
`needed), I test the new version of the file, in a safe (non-production) environment
`if possible. Of course, testing won't always find every bug or prevent every prob
`lem, but it will eliminate the most obvious ones. Making only one major change at
`a time also makes testing easier.
`
`The remaining sections of this chapter discuss some important administrative tools.
`The first describes how to become the superuser (the UNIX privileged account).
`Since I believe a good system manager needs to have both technical expertise and
`an awareness of and sensitivity to the user community (of which he's a part), this
`first chapter includes a section on UNIX communication commands. The goal of
`these discussions—as well as of this book as a whole—is to highlight how a sys
`tem manager thinks about system tasks and problems, rather than to provide lit
`eral, cookbook solutions for common scenarios. Important administrative tools of
`other kinds are covered in Chapter 3, Essential Administrative Tools.
`
`Becoming Superuser
`On a UNIX system, the superuser is a privileged account with unrestricted access to
`all files and commands. The username of this account is root. Many administrative
`tasks and their associated commands require superuser status.
`
`There are two ways to become the superuser. The first is to log in as root directly.
`The second way is to execute the command su while logged in under another
`
`Canon Exhibit 1110
`
`Page 12 of 55
`
`

`

`Chapter 1: Introduction to System Administration
`
`username. After entering the su command, the system will prompt you for the root
`password. If you type the password correctly, the system will display a pound sign
`(#), indicating that you have successfully become superuser, and that the rules nor
`mally restricting file access and command execution do not apply. For example:
`
`$ su
`Password:
`
`#
`
`Not echoed
`
`If you typed the password incorrectly, the operating system will print the word
`"Sorry" and return the normal prompt. You may exit from the superuser account
`with exit or a CTRL-D. You may stop the shell and place it in the background with
`the suspendcommand; you can return to it later using fg."*^
`
`When you run su, the new shell inherits the environment from your current shell.
`You can simulate an actual root login session with the following command form:
`
`$ su -
`
`Unlike some other operating systems, the UNIX superuser has all privileges all the
`time: access to all files, commands, etc. Therefore, it is all too easy for a superuser
`to crash the system, destroy important files, and create havoc inadvertently. For
`this reason, people who know the superuser password (including the system
`administrator) should not do their routine work as superuser. Only use superuser
`status when it is needed.
`
`this password should be
`The root account should always have a password;
`changed periodically. Only experienced UNIX users with special requirements
`should know the superuser password. To set or change the superuser password,
`become superuser and execute the following command:
`
`# passwd
`
`The system will usually ask you to type the old superuser password, and then ask
`you to type the new password twice.* The root password should also be changed
`whenever someone who knows it stops using the system for any reason (e.g.,
`transfer, new job, etc.), or if there is any suspicion that an unauthorized user has
`learned it. Passwords are discussed in detail in the section called "Guidelines for
`choosing passwords" in Chapter 5, User Accounts.
`
`I try to avoid logging in directly as root Instead, I su to root only as necessary,
`exiting from or suspending the superuser shell when possible. Alternatively, in a
`windowing environment, you can create a separate window in which you su to
`root, again executing commands there only as necessary.
`
`t Assuming that the shell you are using has job control; suspend won't work in minimalist
`implementations of the Bourne shell and other shells that don't allow processes to be sus
`pended.
`i In a few implementations, passwd will change your user account password rather than the
`superuser password when you have su'ed to root
`In this case, use the command passwd
`root.
`
`Canon Exhibit 1110
`
`Page 13 of 55
`
`

`

`Becoming Supermer
`
`For security reasons, it's a bad idea to leave any logged in session unattended; nat
`urally, that goes double for a root session. Whenever I leave my desk (or any loca
`tion where I am running as roof), I log out or lock the screen to prevent anyone
`from sneaking onto the system. The xlock command will lock an X session; the
`password of the logged in user must be entered to unlock it again (on some sys
`tems,
`the root password can also unlock sessions locked by other users). The
`lockscreen performs the equivalent operation under SunView on SunOS systems.
`Screen locking programs have security pitfalls of their own, but they do prevent
`opportunistic breaches of system security that would otherwise be caused by a
`momentary lapse into laziness.
`
`PC-based versions of UNIX pose special challenges in this respect in that they typi
`cally offer multiple simultaneous sessions from a single console (see the section
`called 'Terminal Line Configuration Files" in Chapter 11, Terminals and Modems,
`for more details). It's all too easy to forget about a secondary session. On SCO
`UNIX systems, you must lock each session individually, using the lock command
`for regular sessions, and the scolock command for scologin-based sessions (which
`may also be accessed via the Lock icon in the Controls). The lock command asks
`you to enter a special password specific to that lock session; I always use my reg
`ular password because I invariably forget what I chose when I pick a different
`one. It will also automatically log the session out after 30 minutes; you can change
`this default by specifying a different value for DEFLOGOUT in the /etc/default/lock
`file, an ASCII file accessible from any editor.
`
`Many Linux distributions include the vlock command (see the Bibliography for
`places to obtain it if yours doesn't); its -a option may be used to lock all virtual
`console sessions simultaneously. Either the password of the user who invoked it
`or the root password may be used to release the lock.
`
`Controlling Access to the Superuser Account
`On System V systems, any user who knows the root password may become super-
`user at any time by using su. BSD limited access to su to members of group 0 (the
`wheelgroup).^ Under SunOS, if the wheelgroup has a null user*list in the group file
`(/etc/group}, than any user may su to root; otherwise, only members of the wheel
`group can use it.
`
`to any other
`The su command may be used to change one's current account
`account (after giving the proper password); it takes the username corresponding
`to the desired account as its argument, and root is the default when no argument
`is provided. AIX allows the system administrator to specify su usage on an
`account-by-account basis (no restrictions are imposed by default). The following
`
`t UNIX systems organize user accounts into collections known as groups; all users are mem
`bers of one or more groups. Groups are defined by a numerical group ID and are also usu
`ally given a name. We'll define groups more precisely in Chapter 5.
`
`Canon Exhibit 1110
`
`Page 14 of 55
`
`

`

`Chapter1:Introduction to System Administration
`
`commands display the current groups, which may su to root and then limit access
`to it to the system 2ind admins groups:
`
`# Isuser -a sugroups root
`root sugroups=AIiL
`# chuser sugroups="system, admins" root
`
`Although it is generally very BSD-like, Linux offers no control over the access to
`the su command. It generally uses the GNU version of the command, whose
`authors are constitutionallyopposed to such limitations:
`This program does not support a "wheel group" that restricts who can su to super-
`user accounts, because that can help fascist system administrators hold unwar
`ranted power over other users.
`
`—^the su man page
`Of course, this reasoning applies equally well to having a root password in the
`first place. Note that the version of su in the shadow package is restricted to mem
`bers of group 0 (the package provides support for a shadow password file and
`related features).
`Most UNIX versions allowyou to restrict direct roo? logins to certainterminals. This
`is discussed in the section entitled die section called "Controlling Access to Serial
`Lines" in Chapter 11.
`
`An Armadillo??
`
`The armadillo typifies one attribute that a successful sys
`tem administrator needs: a thick skin. Armadillos also
`thrive under difficult environmental conditions,
`through
`strength and perseverence, which is also what system
`administrators have to do a lot of the time (see the
`Colophon at the back of the book for more information about the armadillo).
`System managers will find odier qualities valuable as well, including the
`quickness and cleverness of the mongoose (UNIX is the snake), the sense of
`adventure and playfulness of puppies or kittens, and, at times, a chameleon
`like ability to blend in with