Time Management for System Administrators

Essential System Administration (O'Reilly). Another excellent book that includes many command-line examples.

Advanced Bash-Scripting Guide. Visit http://www.tldp.org/guides.html.

Step 3: Bring the Steps Together

Once the code for each step works, you can bring the code for each step together into one big script.

Even when bringing the code together, it is best to add one step at a time. Test after each new step is added. This is called incremental development and is the best way to test automation. By testing after each small change, you are more certain that the entire shebang will work when you are done.

For example, when we hire a new person, we have to create his account in the LDAP directory, set up his web space on our internal web server, and test his account to make sure it was created properly. Each of these steps can be automated individually. We verify that we have working commands for each step. Then we put the first set of commands into a script and test just that. We make sure the command-line option-processing junk works, any debugging commands we want work, and so on. We run the script and make sure the LDAP entries are correct. Once that all works, we add the next group of commands and test that. We make sure the LDAP entries are still correct, and then check that the internal web space exists. Then we add the next step and test the entire thing again.

Step 4: Test It All Together

Finally, we test the entire thing. If we have tested each step as we added it to the program, there is actually very little testing to be done.

Programmers generally dislike testing. They want things to work on the first try. By integrating testing into each step along the way, the testing doesn't seem too laborious and, as a result, there is a lot less of it to do at the end.

Simple Things Done Often

Here are some automation examples that are simple things we do a lot. Windows system administrators take heed—these examples are fairly Unix/Linux-centric, but the general principles apply to all operating systems.

Command Shortcuts

Most command-line systems have some kind of alias facility. This enables you to create new commands out of old ones. The syntax is different for every kind of command line. Unix has many different shell (command-line) languages, the most popular being bash and csh. They are different in many ways, but what you'll notice here (mostly) is that bash requires an equals sign. I'll give examples for both shells.

Tip

The bash examples will work for any shell modeled after the original Bourne Shell by Steve Bourne (/bin/sh), such as the Korn Shell (/bin/ksh), and the Z Shell (/bin/zsh). Likewise, the csh examples will work for any shell with csh roots, including the Tenex C shell (/bin/tcsh).

Getting to the right directory

For example, I often need to change directory (cd) to a specific directory that has a very long path. This is a good example of where an alias is useful.

Bash: alias book='cd ~tal/projects/books/time/chapters'

csh: alias book 'cd ~tal/projects/books/time/chapters'

Now I can type book whenever I want to be in the right directory for working on my current book. If I start working on a new book, I update the alias. (I've been typing 'book' for the last six or so years!)

This not only saves typing, it records the location so that you don't have to memorize it. One less thing that you have to remember is always a good idea.

To make an alias permanent, you have to add the above line to your .profile, .bashrc (bash), or .cshrc file (csh). These files are only read at login, so either log out and log back in, or source the files to read them in again:

Bash: . ~/.profile

csh: source ~/.cshrc

(Note: the bash command to source a file is the period, or dot.)

An alias can contain multiple commands. Separate them with semicolons. Here's an example where we need to change to a particular directory and set an environment variable based on