UNIX System Administration Handbook - Evi Nemeth [461]
The lines regarding intellectual property seem to be getting fuzzier and fuzzier. It’s well established that you can let someone listen to your new CD or even loan that CD to a friend. And it’s fine to transfer the music to your computer and listen to it that way. But what if you want to play the CD over the Internet from work? What if you let your friend listen that way, too? What if only one of you listens at a time?
Applications such as Napster (napster.com) have pushed this concept of sharing music via the Internet to extremes. Napster turns every user’s digital music collection into an Internet server. From a computer science point of view, Napster is an interesting system—it’s probably the largest distributed client/server application in existence. As might be expected, however, it has raised a lot of hackles.
Napster hit college campuses in the fall of 1999 and instantly doubled many sites’ Internet service bills. Some ISPs threatened to cancel service to customers who used it. The music industry has sued Napster for violation of copyright laws. As of this writing, the situation has snowballed into a kind of Gordian lawsuit involving many different parties. Somehow, we doubt that the resolution of this situation will shed much light on the general issues that it raises.
As might be expected given the uncertainty surrounding these issues, many sites (not to mention governments) lack a well-defined policy for dealing with them.
27.1 POLICY AND PROCEDURE
While researching this chapter, we talked to bigshots in the system administration world, in computer security, in the standards community, and in computer law. We were surprised that they all mentioned “signed, written policy” as being essential to a healthy organization.
Policies and procedures should be written down, approved by management, and checked by lawyers. It’s preferable that this preparation be completed before the documents need to be used to deal with a thorny problem. Several different policy documents should exist:
• Administrative service policies
• Rights and responsibilities of users
• Policies regarding sysadmins (users with special privileges)
• Guest account policy
Procedures in the form of checklists or recipes can be used to codify existing practice. They are useful both for new sysadmins and for old hands. Several benefits of standard procedures are:
• The chores are always done in the same way.
• Checklists reduce the likelihood of errors or forgotten steps.
• It’s faster for the sysadmin to work from a recipe.
• The changes are self-documenting.
• Written procedures provide a measurable standard of correctness.
Today, UNIX is replacing the big mainframes of the past and performing mission-critical functions in the corporate world. In these big UNIX shops, checklists, often called “run books,” serve as the documentation for common tasks. They’re usually kept on-line and also in the form of printed manuals. The sysadmins that write and maintain the run books are often a layer away from the support crew that uses them, but such organization and standardization pays off in the long run.
Here are some common tasks for which you might want to set up procedures:
• Adding a host
• Adding a user
• Localizing a machine
• Setting up TCP wrappers on a machine
• Setting up backups for a new machine
• Securing a new machine
• Restarting a complicated piece of software
• Reviving a web site that is not responding or not serving any data
• Unjamming and restarting a printer
• Upgrading the operating system
• Installing a software package
• Installing software from the net
• Upgrading critical software (sendmail , gcc , named , etc.)
• Backing up and restoring files
• Performing emergency shutdowns (all hosts, all but important hosts, etc.)
Many issues sit squarely between policy and procedure. For