Perl for System Administration

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In my town, several of our local bus lines are powered by cables strung high above the street. One day, when going to an unfamiliar destination, I asked the driver to let me know when a particular street was approaching. He said, "I'm sorry, I can't. I just follow the wires."

These are words you will never hear good system administrators use to describe their job. System and network administration is about deciding what wires to put in place, where to put them, getting them deployed, keeping watch over them, and then eventually ripping them out and starting all over again. Good system administration is hardly ever rote, especially in multiplatform environments where the challenges come fast and furious. Like any other craft, there are better and worse ways to meet these challenges. This book is for the people who face those challenges, either as full-time system administrators or part-time tinkerers. I'll try to show you how Perl can help.

System administration work should use any and every computer language available when appropriate. So why single out Perl for a book?

The answer to this question harkens back the to the very nature of system administration. Rémy Evard, a colleague and friend, once described the job of a system administrator like this: "On one side, you have a set of resources: computers, networks, software, etc. On the other side, you have a set of users with needs and projects—people who want to get work done. Our job is to bring these two sets together in the most optimal way possible, translating between the world of vague human needs and the technical world when necessary."

System administration is often a glue job; Perl is one of the best glue languages. Perl was being used for system administration work well before the World Wide Web came along with its voracious need for glue mechanisms.

Perl has several other things going for it from a system administration perspective:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In my town, several of our local bus lines are powered by cables strung high above the street. One day, when going to an unfamiliar destination, I asked the driver to let me know when a particular street was approaching. He said, "I'm sorry, I can't. I just follow the wires."

These are words you will never hear good system administrators use to describe their job. System and network administration is about deciding what wires to put in place, where to put them, getting them deployed, keeping watch over them, and then eventually ripping them out and starting all over again. Good system administration is hardly ever rote, especially in multiplatform environments where the challenges come fast and furious. Like any other craft, there are better and worse ways to meet these challenges. This book is for the people who face those challenges, either as full-time system administrators or part-time tinkerers. I'll try to show you how Perl can help.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

System administration work should use any and every computer language available when appropriate. So why single out Perl for a book?

The answer to this question harkens back the to the very nature of system administration. Rémy Evard, a colleague and friend, once described the job of a system administrator like this: "On one side, you have a set of resources: computers, networks, software, etc. On the other side, you have a set of users with needs and projects—people who want to get work done. Our job is to bring these two sets together in the most optimal way possible, translating between the world of vague human needs and the technical world when necessary."

System administration is often a glue job; Perl is one of the best glue languages. Perl was being used for system administration work well before the World Wide Web came along with its voracious need for glue mechanisms.

Perl has several other things going for it from a system administration perspective:

It is clearly an offspring of the various Unix shells and the C language, tools many system administrators are comfortable using.
It is available on almost all modern operating systems. It does its best to present a consistent interface on each. This is important for multiplatform system administration.
It has excellent tools for text manipulation, database access, and network programming, three of the mainstays of the profession.
The core language can easily be extended through a carefully constructed module mechanism.
A large and dedicated community of users has poured countless hours into creating modules for virtually every task. Most of these modules are collected in an organized fashion (more on these collections in a moment). This community support can be very empowering.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In the 1966-68 "Batman" television show, the dynamic duo wore utility belts. If Batman and Robin had to scale a building, Batman would say, "Quick Robin, the Bat Grappling Hook! " Or Batman would say, "Quick Robin, the Bat Knockout Gas!" and they'd both have the right tool at hand to subdue the bad guys. This book aims to give you the utility belt you need to do good system administration work.

Every chapter attempts to provide you with three things.

Clear and concise information about a system administration domain.: In each chapter we discuss in depth one domain of the system administration world. The number of possible domains in multiplatform system administration is huge, far too many to be included in a single book. The best survey books on just Unix system administration, Essential System Administration, by Æleen Frisch (O'Reilly & Associates), and Unix System Administration Handbook, by Evi Nemeth, Garth Snyder, and Trent R. Hein (Prentice-Hall), are two and three times, respectively, the size of this book. We'll be looking at topics from three different operating systems: Unix, Windows NT, Windows 2000, and MacOS.

As a result, some hard choices were made on what to include and what to exclude. In general the topics that I believe will become even more important over the next five years made the cut. Important technologies like XML are explored because they are likely to have a significant impact on the field as time goes by. Unfortunately, these guidelines meant that some system administration stalwarts like backup and printing are edged out by newer topics like LDAP and SNMP. The skills and tools provided by this book can help with the domains I omit, but a direct treatment will have to be found elsewhere.

I've tried to put together a good stew of system and network administration information for people with varying levels of experience in the field. Seasoned veterans and new recruits may come away from this book having learned completely different material, but everyone should find something of interest to chew on. Each chapter ends with a list of references which can help you get deeper into a topic should you so choose.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

To get the most of this book, you will need some technical background and some resources at hand. Let's start with the background first:

You'll need to know some Perl: There isn't enough room in this book to provide the basics of the Perl language, so you need to seek that elsewhere before working through this material. Once you have learned the material in a book like Learning Perl, by Randal L. Schwartz and Tom Christiansen (O'Reilly), or Learning Perl on Win32 Systems, by Randal L. Schwartz, Erik Olson, and Tom Christiansen (O'Reilly), you should be in good shape to approach the code in this book.
You'll need to know the basics of your operating system(s): This book assumes that you have some facility with the operating system or systems you plan to administer. You'll need to know how to get around in that OS, run commands, find documentation, etc. Background information on the more complex frameworks built into the OS (e.g., WMI on Windows 2000 or SNMP) is provided.
You may need to know the specifics of your operating system(s): I make an attempt to describe the differences between the major operating systems as we encounter them, but I can't cover all of the intra-OS differences. In particular, every variant of Unix is a little different from all of the others. As a result, you may need to find OS-specific information and roll with the punches should the information be different than what is described here.

For technical resources, you will need just two things:

Perl: You will need a copy of Perl installed on or available to every system you wish to administer. The downloads section of

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Much of the benefit of using Perl for system administration work comes from all of the free code available in module form. The modules mentioned in this book can be found in one of three places:

Comprehensive Perl Archive Network (CPAN): CPAN is a huge archive of Perl source code, documentation, scripts, and modules that is replicated at over a hundred sites around the world. Information on CPAN can be found at http://www.cpan.org. The easiest way to find the modules on CPAN is to use the search engine developed and maintained by Elaine Ashton, Graham Barr, and Clifton Posey at http://search.cpan.org. The "CPAN Search:" box makes it simple to find the right modules for the job.
Individual repositories for pre-built packages: In a moment we'll encounter the Perl Package Manager (PPM ), an especially important tool for Win32 Perl users. This tool connects to repositories (the most famous one is housed at ActiveState) to retrieve pre-built module packages. A good list of these repositories can be found in the PPM Frequently Asked Questions list at http://www.activestate.com/Products/ActivePerl//docs/faq/ActivePerl-faq2.html. If a Win32 package we use does come from a repository other than ActiveState's, I'll be sure to point you at it. For MacOS modules, the canonical place to look is the MacPerl Module Porters site at http://pudge.net/mmp/.
Individual web sites: Some modules are not published to CPAN or any of the PPM repositories. I'll always tell you where to get modules if they are found off the beaten path.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Before we continue with the book, let's take a few minutes for some cautionary words. Programs written for system administration have a twist that makes them different from most other programs. On Unix and NT/2000 they are often run with elevated privileges, i.e., as root or Administrator. With this power comes responsibility. There is an extra onus on us as programmers to write secure code. We write code that can and will bypass the security restrictions placed on mere mortals. If we are not careful, less "ethical" users may use flaws in our code for nefarious purposes. Here are some of the issues you should consider when you use Perl under these circumstances.

By all means, use Perl. But if you can, avoid having your code run in a privileged context. Most tasks do not require root or Administrator privileges. For example, your log analysis program probably does not need to run as root. Create another, less privileged user for this sort of automation. Have a small, dedicated, privileged program hand the data to that user if necessary, and then use that user to perform the analysis.

Sometimes you can't avoid running a script as root or Administrator. For instance, a mail delivery program you create may need to be able to write to a file as any user on the system. Programs like these should shed their omnipotence as soon as possible during their run.

Perl programs running under Unix and Linux can set the $< and $> variables:

# permanently drops privs
($<,$>) = (getpwnam('nobody'),getpwnam('nobody'));

This sets the real and effective user IDs to that of nobody, hopefully an underprivileged user. To be even more thorough, you may wish to use $( and $)to change the real and effective group IDs as well.

Windows NT and Windows 2000 do not have user IDs per se, but there are similar processes for dropping privileges. Windows 2000 has a feature called "RunAs" which can be used to run processes as a different user. Under both Windows NT and Windows 2000, users with the user right of

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

http://dwheeler.com/secure-programs/Secure-Programs-HOWTO.html is a HOWTO document for secure programming under Linux, but the concepts and techniques are applicable to other situations as well.
http://www.cs.ucdavis.edu/~bishop/secprog.html contains more good secure programming resources from security expert Matt Bishop.
http://www.homeport.org/~adam/review.html lists security code review guidelines by Adam Shostack.
http://www.dnaco.net/~kragen/security-holes.html is a good paper on how to find security holes (especially in your own code) by Kragen Sitaker.
http://www.shmoo.com/securecode/ offers an excellent collection of articles on how to write secure code.
Perl CGI Problems, by Rain Forest Puppy (Phrack Magazine, 1999) can be found online at http://www.insecure.org/news/P55-07.txt or from the Phrack archives at http://www.phrack.com/archive.html.
Perl Cookbook, by Tom Christiansen and Nathan Torkington (O'Reilly, 1998) contains many good tips on coding securely.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Laptops fall in slow motion. Or at least that's the way it looked when the laptop I was using to write this book fell off a table onto a hardwood floor. The machine was still in one piece and running when I picked it up. As I checked the laptop to see if anything was damaged, I noticed it started to run slower and slower. Not only that, but the laptop began to make sporadic and disturbing humming-buzzing sounds during disk access. Figuring the software slowdown was caused by a software problem, I shut the laptop down. It did not go gently into the night, refusing to shut down cleanly. This was a bad sign.

Even worse was its reluctance to boot again. It would begin the Windows NT booting process and then fail with a "file not found" error. By now it was clear that the fall had caused some serious physical damage to the hard drive. The heads had probably skidded over the hard drive platter surface, destroying files and directory entries in their wake. Now the question was, "Did any of my files survive? Did the files for this book survive?"

I first tried booting to Linux, the other operating system installed on the laptop. Linux booted fine, an encouraging sign. The files for this book, however, resided on the Windows NT NTFS partition that did not boot. Using Martin von Löwis's Linux NTFS driver, available at http://www.informatik.hu-berlin.de/~loewis/ntfs/ (now shipping with the Linux 2.2 kernels), I mounted the partition and was greeted with what looked like all of my files intact.

My attempts to copy these files off that partition would proceed fine for a while until I reached a certain file. At that point the drive would make those ominous sounds again and the backup would fail. It was clear that if I wanted to rescue my data I was going to have to skip all the damaged files on the disk. The program I was using ( gnutar) had the ability to skip a list of files, but here was the problem: which files? There were over sixteen thousand files on this filesystem at time of impact. How was I going to figure out which files were damaged and which were fine? Clearly running

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Laptops fall in slow motion. Or at least that's the way it looked when the laptop I was using to write this book fell off a table onto a hardwood floor. The machine was still in one piece and running when I picked it up. As I checked the laptop to see if anything was damaged, I noticed it started to run slower and slower. Not only that, but the laptop began to make sporadic and disturbing humming-buzzing sounds during disk access. Figuring the software slowdown was caused by a software problem, I shut the laptop down. It did not go gently into the night, refusing to shut down cleanly. This was a bad sign.

Even worse was its reluctance to boot again. It would begin the Windows NT booting process and then fail with a "file not found" error. By now it was clear that the fall had caused some serious physical damage to the hard drive. The heads had probably skidded over the hard drive platter surface, destroying files and directory entries in their wake. Now the question was, "Did any of my files survive? Did the files for this book survive?"

I first tried booting to Linux, the other operating system installed on the laptop. Linux booted fine, an encouraging sign. The files for this book, however, resided on the Windows NT NTFS partition that did not boot. Using Martin von Löwis's Linux NTFS driver, available at http://www.informatik.hu-berlin.de/~loewis/ntfs/ (now shipping with the Linux 2.2 kernels), I mounted the partition and was greeted with what looked like all of my files intact.

My attempts to copy these files off that partition would proceed fine for a while until I reached a certain file. At that point the drive would make those ominous sounds again and the backup would fail. It was clear that if I wanted to rescue my data I was going to have to skip all the damaged files on the disk. The program I was using ( gnutar) had the ability to skip a list of files, but here was the problem: which files? There were over sixteen thousand files on this filesystem at time of impact. How was I going to figure out which files were damaged and which were fine? Clearly running

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

We'll start with a quick review of the native filesystems for each of our target operating systems. Some of this may be old news to you, especially if you have significant experience with a particular operating system. Still, it is worth your while to pay careful attention to the differences between the filesystems (especially the ones you don't know) if you intend to write Perl code that works on multiple platforms.

All modern Unix variants ship with a native filesystem with semantics that resemble those of their common ancestor, the Berkeley Fast File System. Different vendors have extended their filesystem implementations in different ways (e.g., Solaris adds Access Control Lists for better security, Digital Unix ships a spiffy transaction-based filesystem called advfs, etc.). We'll be writing code aimed at the lowest common denominator to allow it to work across different Unix platforms.

The top, or root, of a Unix filesystem is indicated by a forward slash (/). To uniquely identify a file or directory in a Unix filesystem, we construct a path starting with a slash and then add directories, separating them with forward slashes, as we descend deeper into the filesystem. The final component of this path is the desired directory or filename. Directory and filenames in modern Unix variants are case sensitive. Almost all ASCII characters can be used in these names if you are crafty enough, but sticking to alphanumeric characters and some limited punctuation will save you hassle later.

Windows NT (Version 4.0 as of this writing) ships with two supported filesystems: File Allocation Table (FAT) and NT FileSystem (NTFS). Windows 2000 adds FAT32, an improved version of FAT that allows for larger partitions and smaller cluster sizes to the NT family.

Windows NT uses an extended version of the basic FAT filesystems found in DOS. Before we look at the extended version, it is important to understand the foibles of the basic FAT filesystem. In basic or real-mode FAT filesystems, filenames conform to the 8.3 specification. This means that file and directory names can start with no more than eight characters, must have a period (or

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

By now you are probably itching to get to some practical applications of Perl. We'll begin by examining the process of "walking the filesystem," one of the most common system administration tasks associated with filesystems. Typically this entails searching an entire set of directory trees and taking action based on the files or directories we find. Each OS provides a tool for this task. Under Unix it is the find command, under NT and Windows 2000 it is Find Files or Folders or Search For Files or Folders, and in MacOS it is Find File or Sherlock. All of these commands are useful for searching, but they lack the power by themselves to perform arbitrary and complex operations as they encounter their desired search targets. We're going to see how Perl allows us to write more sophisticated file walking code beginning with the very basics and ratcheting up the complexity as we go on.

To get started, let's take a common scenario that provides a clear problem for us to solve. In this scenario, we're a Unix system administrator with overflowing user filesystems and an empty budget. (Unix is being picked on first, but the other operating systems will get their turns in a moment.)

We can't add more disk space without any money, so we've got to make better use of our existing resources. Our first step is to remove all the files on our filesystems that can be eliminated. Under Unix, good candidates for elimination are the core files left around by programs that have died nasty deaths. Most users either do not notice that these files are created, or just ignore them in their directory, leaving large amounts of disk space claimed for no reason. We need something to search through a filesystem and delete these varmints.

To walk a filesystem, we start by reading the contents of a single directory and work our way down from there. Let's ease into the process and begin with code that examines the contents of the current directory and reports on either a core file or another directory to be searched.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Now that we've seen the basics of filesystem walking, here's a faster and spiffier way to do it. Perl comes with a module called File::Find that allows Perl to emulate the Unix find command. The easiest way to begin using this module is to use the find2perl command to generate prototypical Perl code for you.

find2perl is not always easy to use on non-Unix Perl ports. For example, MacOS users either will need Macintosh Programmer's Workshop (MPW) to run it, or should modify the code to take @ARGV from a dialog box. Here's a code snippet from Chris Nandor, co-author of MacPerl: Power and Ease, to do this:

@ARGV = @ARGV ? @ARGV : split "\s",
MacPerl::Ask("Arguments?");

All ports do have the File::Find

module that find2perl and find.pl use, so this should not be a real problem. We'll show you how to call it directly later in this chapter.

For instance, let's say you need some code to search the /home directory for files named beesknees. The command line that uses the Unix find command is:

            % find /home -name beesknees -print

Feed the same options to find2perl:

            % find2perl /home -name beesknees -print

and it produces:

#!/usr/bin/perl
    eval 'exec /usr/bin/perl -S $0 ${1+"$@"}'
        if $running_under_some_shell;

require "find.pl";

# Traverse desired filesystems

&find('/home');

exit;

sub wanted {
    /^beesknees$/ && print("$name\n");
}

The find2perl-generated code is fairly straightforward. It loads in the necessary find.pl library with a require statement, then calls the subroutine &find( ) with the name of the starting directory. We'll discuss the purpose of the &wanted( ) subroutine in a moment, since that's where all of the interesting modifications we're about to explore will live.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Perl scripts like our core-killers from the last section can offer a way to deal with junk files that cause unnecessary disk full situations. But even when run on a regular basis, they are still a reactive approach; the administrator deals with these files only after they've come into existence and cluttered the filesystem.

There's another, more proactive approach: filesystem quotas. Filesystem quotas, operating system permitting, allow you to constrain the amount of disk space a particular user can consume on a filesystem. Windows 2000 and all modern Unix variants offer quotas. NT4 requires a third-party product, and MacOS users are S.O.L. (Simply or Sore Out of Luck).

Though proactive, this approach is considerably more heavy-handed than cleanup scripts because it applies to all files, not just spurious ones like core dumps. Most system administrators find using a combination of the automated cleanup scripts and quotas to be the best strategy. The former helps prevent the latter from being necessary.

In this section, we'll deal with manipulating Unix quotas from Perl. Before we get to that subject, we should take a moment to understand how quotas are set and queried "by hand." To enable quotas on a filesystem, a Unix system administrator usually adds an entry to the filesystem mount table (e.g., /etc/fstab or /etc/vfstab) and then reboots the system or manually invokes the quota enable command (usually quotaon). Here's an example /etc/vfstab from a Solaris box:

#device            device              mount  FS    fsck    mount     mount
#to mount          to fsck             point  type  pass    at boot   options
/dev/dsk/c0t0d0s7 /dev/dsk/c0d0t0d0s7  /home  ufs   2       yes       rq

The rq option in the last column enables quotas on this filesystem. They are stored on a per-user basis. To view the quota entries for a user on all of the mounted filesystems that have quotas enabled, one can invoke the quota command like so:

$ quota -v sabrams

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Given the methods of controlling filesystem usage we've just explored, it is only natural to want to keep track of how well they work. To end this chapter, let's look at a method for querying the filesystem usage on each of the operating systems found in this book.

MacOS is the operating system for which this task is hardest. MacOS does have a Macintosh Toolbox routine (PBHGetVInfo) to retrieve volume information, but at the current time there is no MacPerl module available to make calling this function easy. Instead, we have to take a roundabout approach and ask the Finder to query this information for us. This is easy in practice thanks to a glue module, but the setup needed for this method makes MacOS the more difficult operating system to deal with.

All the materials for the following involve work by Chris Nandor and can be found at http://pudge.net or on CPAN. Bear with me as we go over this setup step by step:

Install the cpan-mac bundle. cpan-mac includes the CPAN.pm module by Andreas J. König and other handy modules we mentioned in Chapter 1. Even if you don't want to query filesystem usage from MacOS, you'll still be well served by installing this bundle. When you install this bundle, be sure to follow all of the directions found in the README file.
Install the latest Mac::AppleEvents::Simple module by dropping the distribution file on top of the installme droplet.
Install the Mac::Glue module. The installme droplet decompresses and unpacks the contents of the Mac::Glue distribution file into a new folder as part of the installation process. Be sure to run the gluedialect and gluescriptadds setup scripts from the scripts subfolder of the unpacked distribution.
Create the finder glue file. Open your System Folder and drag the Finder file on top of the gluemac droplet to create the necessary glue file (and, in a particularly nice touch by Nandor, to create pod documentation for the glue).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Name	CPAN ID	Version
`File::Find` (ships with Perl)
`File::Spec` (ships with Perl)
`Cwd` (ships with Perl)
`Win32::File::GetAttributes` (ships with ActiveState Perl)
`Win32::FileSecurity` (ships with ActiveState Perl)
`File::Basename` (ships with Perl)
`Getopt::Std` (ships with Perl)
`Quota`	TOMZO	1.2.3
`cpan-mac` (bundle)	CNANDOR	0.40
`Mac::AppleEvents::Simple`	CNANDOR	0.81
`Mac::Glue`	CNANDOR	0.58

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

For good information on platform differences for Perl programmers, the perlport manual page is invaluable. Chris Nandor and Gurasamy Sarathy presented a talk based on an early version of this manual page at the Perl Conference 2.0; Nandor has posted the slides from this talk at http://pudge.net/macperl/tpc/98.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Here's a short pop quiz. If it wasn't for users, system administration would be:

a) More pleasant.
b) Nonexistent.

Despite the comments from system administrators on their most beleaguered days, b) is the best answer to this question. As I mentioned in the first chapter, ultimately system administration is about making it possible for people to use the available technology.

Why all the grumbling then? Users introduce two things into the systems and networks we administer that make them significantly more complex: nondeterminism and individuality. We'll address the nondeterminism issues when we discuss user activity in the next chapter, but for now let's focus on individuality.

In most cases, users want to retain their own separate identities. Not only do they want a unique name, but they want unique "stuff" too. They want to be able to say, "These are my files. I keep them in my directories. I print them with my print quota. I make them available from my home page on the Web." Modern operating systems keep an account of all of these details for each user.

But who keeps track of all of the accounts on a system or network of systems? Who is ultimately responsible for creating, protecting, and disposing of these little shells for individuals? I'd hazard a guess and say "you, dear reader" — or if not you personally, then tools you'll build to act as your proxy. This chapter is designed to help you with that responsibility.

Let's begin our discussion of users by addressing some of the pieces of information that form their identity and how it is stored on a system. We'll start by looking at Unix and Unix-variant users, and then address the same issues for Windows NT/Windows 2000. For current-generation MacOS systems, this is a non-issue, so we'll skip MacOS in this chapter. Once we address identity information for both operating systems, we'll construct a basic account system.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When discussing this topic, we have to putter around in a few key files because they store the persistent definition of a user's identity. By persistent definition, I mean those attributes of a user that exist during the entire lifespan of that user, persisting even while that user is not actively using a computer. Another word that we'll use for this persistent identity is account. If you have an account on a system, you can log in and become a user of that system.

Users come into being on a system at the point when their information is first added to the password file (or the directory service which offers the same information). A user's subsequent departure from the scene occurs when this entry is removed. We'll dive right in and look at how the user identity is stored.

Let's start off with the "classic" password file format and then get more sophisticated from there. I call this format classic because it is the parent for all of the other Unix password file formats currently in use. It is still in use today in many Unix variants, including SunOS, Digital Unix, and Linux. Usually found on the system as /etc/passwd, this file consists of lines of ASCII text, each line representing a different account on the system or a link to another directory service. A line in this file is composed of several colon-separated fields. We'll take a close look at all of these fields as soon as we see how to retrieve them.

Here's an example line from /etc/passwd:

dnb:fMP.olmno4jGA6:6700:520:David N. Blank-Edelman:/home/dnb:/bin/zsh

There are at least two ways to go about accessing this information from Perl:

If we access it "by hand," we can treat this file like any random text file and parse it accordingly:

$passwd = "/etc/passwd";
open(PW,$passwd) or die "Can't open $passwd:$!\n";
while (<PW>){
	($name,$passwd,$uid,$gid,$gcos,$dir,$shell) = split(/:/);

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Now that we've explored the pieces of information that Unix systems cobble together to form a user's identity, let's take a look at the same topic for NT/2000 users. Much of this info is conceptually similar, so we'll dwell mostly on the differences between the two operating systems.

NT/2000 stores the persistent identity information for a user in a database called the SAM (Security Accounts Manager), or directory, database. The SAM database is part of the NT/2000 registry living in %SYSTEMROOT%/system32/config. The files that make up the registry are all stored in a binary format, meaning normal Perl text manipulation idioms cannot be used to read or write changes to this database. It is theoretically possible to use Perl's binary data operators (i.e.,

pack(
)

and unpack( )) with the SAM, providing you do so when NT/2000 is not running, but this way lies madness and misery.

Luckily, there are better ways to access and manipulate this information via Perl.

One approach is to call an external binary to interact with the OS for you. Every NT/2000 machine has a feature-bloated command called net that can add, delete, and view users. net is quirky and limited, and probably the method of last resort.

For example, here's the net command in action on a machine with two accounts:

C:\>net users

User accounts for \\HOTDIGGITYDOG
----------------------------------
Administrator            Guest
The command completed successfully.

It would be easy to parse the output of this program from Perl if we needed to. Besides net, there are other commercial packages that offer a command-line executable to perform similar tasks.

Another approach is to use the Perl module Win32::NetAdmin (bundled with the ActiveState Perl distribution) or one of the modules created to fill in the gaps in the functionality of

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Now that we've had a good look at user identity, we can begin to address the administration aspect of user accounts. Rather than just show you the select Perl subroutines or function calls you need for user addition and deletion, we're going to take this topic to the next level by showing these operations in a larger context. In the remainder of this chapter, we're going to work towards writing a bare-bones account system that starts to really manage both NT and Unix users.

Our account system will be constructed in four parts: user interface, data storage, process scripts (Microsoft would call them the "business logic"), and low-level library routines. From a process perspective they work together (see Figure 3.2).

Figure 3.2: The structure of a basic account system

Requests come into the system through a user interface and get placed into an "add account queue" file for processing. We'll just call this an "add queue" from here on in. A process script reads this queue, performs the required account creations, and stores information about the created accounts in a separate database. That takes care of adding the users to our system.

For removing a user, the process is similar. A user interface is used to create a "remove queue." A second process script reads this queue and deletes the users from our system and updates the central database.

We isolate these operations into separate conceptual parts because it gives us the maximum possible flexibility should we decide to change things later. For instance, if some day we decide to change our database backend, we only need to modify the low-level library routines. Similarly, if we want our user addition process to include additional steps (perhaps cross-checking against another database in Human Resources), we will only need to change the process script in question.Let's start by looking at the first component: the user interface used to create the initial account queue. For the bare-bones purposes of this book, we'll use a simple text-based user interface to query for account parameters:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Name	CPAN ID	Version
`User::pwent` (ships with Perl)
`File::stat` (ships with Perl)
`Win32::AdminMisc` (found at `http://www.roth.net`)		20000117
`Win32::Perms` (found at `http://www.roth.net`)		20000216
`Win32::Lanman` (found at `ftp://ftp.roth.net/pub/ntperl/Others/Lanman/`)		1.05
`IO::File` (ships with Perl)	GBARR	1.20
`XML::Writer`	DMEGG	0.30
`XML::Parser`	COOPERCL	2.27
`Data::Dumper`	GSAR	2.101
`XML::Simple`	GRANTM	1.01

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

http://www.freebsd.org/cgi/man.cgi is where the FreeBSD Project provides access to the online manual pages for *BSD and other Unix variants. This is a handy way to compare the file formats and user administration commands (useradd, et al.) for several operating systems.
Practical Unix & Internet Security, 2nd Edition, by Simson Garfinkel and Gene Spafford (O'Reilly, 1999), is an excellent place to start for information about password files.

http://Jenda.Krynicky.cz is another site with useful Win32 modules applicable to user administration.
http://windows.microsoft.com/windows2000/en/server/help/, from the Windows 2000 online help. (Navigate to the Active Directory→Concepts→Understanding Active Directory→Understanding Groups section.) This is a good overview of the new Windows 2000 group mechanisms.
http://www.activestate.com/support/mailing_lists.htm hosts the Perl-Win32-Admin and Perl-Win32-Users mailing lists. Both lists and their archives are invaluable resources for Win32 programmers.
Win32 Perl Programming: The Standard Extensions, by Dave Roth (Macmillan Technical Publishing, 1999) is currently the best reference for Win32 Perl module programming.
Windows NT User Administration, by Ashley J. Meggitt and Timothy D. Ritchey (O'Reilly, 1997).
http://www.mspress.com are the publishers of the Microsoft NT Resource kit. They also offer a subscription services that provides access to the latest RK utilities.
http://www.roth.net is the home of Win32::AdminMisc, Win32::Perms, and other modules the Win32 community relies upon for user administration.

There's been a tremendous explosion of material covering XML in the last two years. The following are some of the best references I know of for people interested in learning about XML. There haven't been any XML for Perl books released as of this publication, but I know of several projects in the works.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In the previous chapter, we explored the identity of a user and how this identity is managed and stored. Now let's talk about how to manage users while they are active on our systems and network.

The significant actions of users fall into four domains:

Processes: Users can spawn, kill, pause, and resume processes on our machines. These processes compete for a computer's finite processing power, adding resource issues to the list of problems a system administrator needs to mediate.
File operations: Most of the time, operations like writing, reading, creating, deleting, etc., take place when some user process interacts with files in a filesystem. But under Unix, there's more to this picture. Unix uses the filesystem as a gateway to more than just file storage. Device control, input/output channels, and even some process control and network access are file operations. We dealt with filesystem administration in Chapter 2, but in this chapter we'll approach this topic from a user administration perspective.
Network: Users can send and receive data over network interfaces on our machine. There is material elsewhere in this book on networking, but we'll address this issue here from a different perspective.
OS-specific activities: This last domain is a catchall for the OS-specific features that users can access via different APIs. Included in this list are things like GUI element controls, shared memory usage, file sharing APIs, sound, etc. This category is so diverse that there's no way to discuss it well in our current context. I recommend tracking down the OS-specific web sites like

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

"Control" might be too strong a word for the functionality offered under MacOS, since MacOS is not multiuser and is just barely multitasking. Using the module Mac::Processes, we can interact with the Macintosh Process Manager using the MacOS Toolbox API for process control. If you are going to delve any deeper than surface level with this module, you'll want to seek out a copy of the Inside Macintosh:Processes volume that deals with the Process Manager.

When we load Mac::Processes via the standard use Mac::Processes directive, it initializes a special hash called %Process. This hash is magical because it always contains a representation of the current process state of the machine thanks to Perl's tied variable functionality. Each time the contents of %Process are accessed, information about the machine's current running processes are returned. To see a list of the current process serial numbers (the MacOS term for process ID, often abbreviated as PSN ), we can simply query the list of keys in this hash:

use Mac::Processes;
print map{"$_\n"} keys %Process;

For more information on the individual processes, we need to work with the values returned for each key. Each hash entry contains an object representing a ProcessInfo structure. To get at the individual fields of this structure, you call object methods with their names. For more information on each field and what it represents, see the canonical reference book Inside Macintosh:Processes. The currently available method names are processName( ),

processNumber(
)

, processType( ), processSignature( ),

processSize(
)

, processMode( ), processLocation( ),

processLauncher(
)

, processLaunchDate( ), processActiveTime( ), and processAppSpec( ).

To get a list of the running processes and their names, we could write:

use Mac::Processes;
while(($psn, $psi) = each (%Process)){
  $name = $psi->processName(  );
  write;
}

format STDOUT_TOP =
Process Serial Number

Table of Contents