Chapter 13. Scripting for Administrators

The last chapter covered a major use of scripts for administrators: monitoring the systems you administer. Using MRTG, you can monitor CPU usage, available disk space, and network router throughput, among other things, but scripts come in handy in quite a few other areas. This chapter won't show you magical ways to run all of your systems. Instead, it describes how you can use scripts to improve your daily life and manage your systems with less work, including the following:

  • Deciding when and where to write scripts

  • Creating scripts in an organized fashion

  • Scripting complicated commands

  • Troubleshooting with scripts

  • Removing annoyances with scripts

  • Cleaning up yucky data formats

  • Automating your daily work with scripts

This chapter contains some very simple scripts and some complicated scripts. In all cases, though, the goal is to show techniques, not cleverness, and to focus on generating ideas for making your work easier.

Why Write Scripts?

From an administrator's point of view, scripts enable you to do the following:

  • Automate frequently run tasks

  • Remember complicated command-line options and file paths

  • Filter through data and respond with just the crucial items that require your attention

In these cases, scripts come in handy and, best of all, generally do not require a long time to write.

Scripting is fun. In about three minutes, you can create a useful script. The problem is that if you write all of your scripts in a totally ad hoc manner, you will end up with a confusing mess. If you approach your administration scripts with even a small amount of discipline, you will create a script library that will save you hours and hours of time.

Following a few simple guidelines will help you avoid ending up with a confusing mess:

  • Use a consistent style. Indent your scripts to make them easier to read. (Use any indenting style you prefer; you're not limited to the style shown by the examples in this book.)

  • Store your scripts in a common location. For example, store your scripts in /usr/local/bin or the bin subdirectory of your home directory, $HOME/bin. You might also want to separate your administrative scripts into a directory of their own.

  • Document your scripts. Comment liberally. You want to especially document why you wrote the script or what problem it helps to solve. In addition, specify how to call the script, the command-line arguments and options, and so on.

None of these guidelines should require much work or restrict your creativity.

Note that some very sick people have even gone so far as to write poetry in scripts, usually in another scripting language called Perl. Avoid these people. They are the first who will become zombies when the big meteor hits the Earth. Remember, you were warned.

You've probably noticed the focus on not spending a lot of time. In today's IT environments, administrators typically manage too many systems with too few resources. Spend your time going after the proverbial low-hanging fruit, the easy ones, first. Tackle the harder stuff later.

Scripting Complicated Commands

Computers can remember things very well. People can't always do the same. If you have commands you need to run, but you tend to forget the command-line arguments or options, you can solve the problem by storing the command in a script. For example, the following script has only one actual command.

Try It Out: Turning on Networking over USB

Enter the script and name the file yopy:

#!/bin/sh

# Starts networking over a USB port for a connected device.
# Turn the device on, plug in the Yopy PDA, and then run this
# script.

/sbin/ifconfig usb0 192.168.1.1
echo "Yopy is on 192.168.1.1"

When you run this script, you'll see the following output:

$ yopy
Yopy is on 192.168.1.1

If the USB port cannot be configured for networking, you'll see an error like the following:

$ yopy
SIOCSIFADDR: Permission denied
usb0: unknown interface: No such device
Yopy is on 192.168.1.1

How It Works

In this script, the comments are longer than the commands. Don't worry about that, though. Enter as many comments as you think you need in your scripts, regardless of the length. These small scripts are not going to fill up your hard drive.

See the section on Commenting Your Scripts in Chapter 2 for more information on the importance of comments.

This script calls the ifconfig command to turn on TCP/IP networking over a USB link. The real purpose of the script is to enable a network link to a Yopy PDA over a USB cable. The Yopy runs Linux, the popular MySQL database, and the minimalist Boa web server.

See www.yopy.com for more information about this cool PDA.

While the script was written to establish a network link to a PDA, from a scripting point of view, this script remembers things for the poor, overworked administrator:

  • The ifconfig command resides in /sbin on this Linux system, not /bin, /usr/bin, nor /usr/sbin.

  • The USB networking device is usb0, although this is usually easy to figure out.

  • The IP address to talk to the Yopy is statically configured to 192.168.1.1. This is important for the Yopy's MySQL database security.

Any time you face a similar situation, turn to scripts to keep crucial data for you. Even a one-line script is worth creating if it saves you time and frustration.

The next example shows a few more lines of scripting commands but is similarly short.

Try It Out: Monitoring HTTP Data

Enter the following script and name the file tcpmon:

#!/bin/sh

# Runs the Apache Axis TCP monitor as a proxy between
# a web client and server. The tcpmon program then
# displays all the HTTP traffic between the client
# and server.
#
AXIS=$HOME/java/xml/axis-1_2RC2/lib ; export AXIS

CLASSPATH=$AXIS/axis.jar:$AXIS/log4j-1.2.8.jar ; export CLASSPATH

# java org.apache.axis.utils.tcpmon [listenPort targetHost targetPort]
java -Xmx400m org.apache.axis.utils.tcpmon 28080 vodka.liquor.vod 85

Run this script as shown here:

$ ./tcpmon

This script generates no output. Instead, it creates a window for monitoring network traffic.

How It Works

This script runs the Apache Axis TCP monitor program. Axis is a package for accessing web services from Java applications. The tcpmon program is a utility program in the Axis package.

See ws.apache.org/axis/ for more information about Apache Axis.

The tcpmon program displays a window showing each HTTP request to a remote web server and the full contents of the corresponding response. With web servers, the data sent to the remote server, along with the response, are encoded in XML and usually not visible to the user. Thus, a tool such as tcpmon can shed some light on any problems that might develop when calling on remote web services.

Because Axis requires a Java runtime engine, you must have the java command available on your system. Prior to calling the java command, you need to set up the classpath, the set of directories that hold compiled Java code that the program requires.

This script sets the CLASSPATH environment variable, used by the java command, to hold two files: axis.jar and log4j-1.2.8.jar. Both of these files reside inside the Axis distribution. The script sets the AXIS environment variable to this directory, which makes it easier to change the name of the directory if Axis is installed in another location or upgraded to a new version. Using the AXIS environment variable also shortens the line that sets the CLASSPATH environment variable.

The tcpmon script, therefore, remembers the following:

  • Where on disk the Axis package was installed. Because the installation directory has the version number, this can be hard to remember.

  • Which Java libraries, called jar files, are required by the tcpmon program.

  • The Java class name of the tcpmon program, org.apache.axis.utils.tcpmon. The class name is needed to launch the application.

  • That the tcpmon program can use a lot of memory. The -Xmx400m sets the program to use a maximum of 400 megabytes of memory for Java objects.

  • The command-line arguments needed for the tcpmon program, as well as the required order for the command-line arguments.

  • The hostname and port number of the remote server.

  • The local port number used as a proxy for the remote server.

As you can see, even with a short script, you can save a lot of useful information in a script.

The preceding script was instrumental in testing a web site designed for a vodka promotion. The web site shown, vodka.liquor.vod, is fake, to protect the innocent.

While the scripting of complicated commands usually results in fairly small scripts, troubleshooting enables you to create more detailed scripts. Creating larger scripts does not necessarily show your scripting prowess. The goal, as always, is to solve problems.

Troubleshooting Your Systems

Just as writing larger scripts is not an end in itself, it is very important when troubleshooting that you don't end up reporting too much information. Therefore, when you create your troubleshooting scripts, focus on reporting only problems or essential information.

One of the most common problems on systems, especially those with minimal attention, is filling disks. To see how much space is used on a given disk or on all your system's disks, you can use the df command, as shown here:

$ df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda2             24193540   3980000  18984568  18% /
/dev/hda1               101086     10933     84934  12% /boot
none                    501696         0    501696   0% /dev/shm
/dev/hda5             48592392  25049972  21074036  55% /home2
/dev/sda1               507104    147936    359168  30% /media/TITAN

This example shows all the disks mounted on a particular system. The -k command-line option tells the df command to return the results in 1K blocks. You can then interpret the results to determine whether any of the disks requires further attention. Alternatively, you could write a script to perform the interpretation for you.

Try It Out: Checking Disk Space

Enter the following script and name the file diskcheck:

#!/bin/sh

# Output warnings if disks are too full (in percentage
# terms) or have too little space available.

# This script goes through all the mounted file systems
# and checks each to see if the disk is nearly full,
# reporting only on those disks that warrant more attention.


# Set thresholds
min_free=4000

max_in_use=90


# Get a list of all file systems.
filesystems=`df -k | grep -v Use | grep -v none | awk '{ print $6 }'`

for filesystem in $filesystems
do
    # Cache results for this file system.
entry=`df -k $filesystem | tail −1`

    # Split out the amount of space free as well as in-use percentage.
    free=`echo $entry | cut -d' ' -f4`
    in_use=`echo $entry | cut -d' ' -f5 | cut -d'%' -f1 `

    # Check the file system percent in use.
    if [ $(expr "$in_use > $max_in_use" ) ]
    then
        echo "$filesystem has only $free KB free at $in_use%."
    else
        # Check the available space against threshold.
        # Only make this check if the in use is OK.

        result=$( echo "
            scale=2   /* two decimal places */
            print $free < $min_free" | bc)


        if [ $(expr "$result != 0" ) ]
        then
            echo "$filesystem has only $free KB free."
        fi
    fi

done

When you run this script, and if everything is okay, you'll see no output:

$ sh diskcheck
$

Conversely, if you have a disk or disks that are nearly filled up, you'll see output like the following:

$ sh diskcheck
/home2 has only 200768 KB free at 91%.

How It Works

This script introduces no new concepts, so you should be able to read the script and determine what it does.

This script uses two threshold values to check disk space: a percentage full value and an amount free. If the disk is more than the threshold amount full, in percentage terms, the script considers this a problem. Furthermore, if the disk has only a minimal amount of space left, the script considers this a problem. These two thresholds enable the script to work for most any disk, large or small.

The thresholds appear at the top of the script to make it easier to change the values. Feel free to modify the values to whatever makes sense in your environment.

After setting the thresholds, the first major command extracts the name of each mounted file system using the df command:

filesystems=`df -k | grep -v Use | grep -v none | awk '{ print $6 }'`

Breaking this command line into pieces, the first command, df -k, lists the amount of disk space in kilobytes (-k). Most modern versions of df use kilobytes by default, but even so, using this option is safe and harmless. If you come across a system that uses the 512-byte blocks instead, the -k option will fix up the results.

The grep -v command looks for all lines that do not match the given pattern. The grep -v Use command removes the first header line. The second grep command, grep -v none, removes the special /dev/shm entry on Linux systems. You can add other grep commands to remove any extraneous devices.

The last command on this line, awk, prints the sixth field in the output. This is the name of the mount point where the file system is mounted. Use $1 instead of $6 if you want the device entry for the file system instead. In most cases, the mount point, such as /, /tmp, or /home, proves more meaningful than the device entry, such as /dev/hda5 or /dev/sdb1.

The next step is to loop over all the file systems, using a for loop:

for filesystem in $filesystems
do
   # ...
done

In each iteration of the loop, the first step is to call the df command again with just the name of the specific file system:

entry=`df -k $filesystem | tail −1`

This is not very efficient, as the script just called the df command previously, but this format makes it easier to extract the data. The script pipes the results of the df command to the tail command to remove the header line.

Once the script has the data on a file system, it can retrieve the most interesting values. In this case, these values are the percent used and the amount of free space:

# Split out the amount of space free as well as in-use percentage.
    free=`echo $entry | cut -d' ' -f4`
    in_use=`echo $entry | cut -d' ' -f5 | cut -d'%' -f1 `

The script sets the free variable to the amount of free space, held in the fourth field of the data. The cut command extracts the necessary field.

You should always pass a field delimiter to the cut command. Set this using the -d option.

The script sets the in_use variable to the percentage of the disk that is used. In this case, the script calls the cut command twice. The first call to cut extracts the value, such as 51%. The second cut command removes the percent sign and leaves just the number, so the script can perform comparisons on the percentage.

The most important comparison is to check whether the disk is too full, percentagewise:

if [ $(expr "$in_use > $max_in_use" ) ]
then
    echo "$filesystem has only $free KB free at $in_use%."
else
    # ...
fi

The if statement contains a lot of syntax. You must put the value passed to the expr command in quotes; otherwise, the shell will interpret > as redirecting stdout and, similarly, < as redirecting stdin.

If the first check passes, then the script verifies that at least a certain minimal amount of disk space is available. This test does not make sense if the script is already displaying a warning about the disk, so the script only performs this check if the first check passes.

This check uses the bc command:

result=$( echo "
    scale=2   /* two decimal places */
    print $free < $min_free" | bc)

if [ $(expr "$result != 0" ) ]
then
    echo "$filesystem has only $free KB free."
fi

An earlier version of this script used the expr command, similar to the first check:

if [ $(expr "$free < $min_free" ) ]
then
    echo "$filesystem has only $free KB free."
fi

This did not work, surprisingly. The numbers reported by the df command are all whole numbers (integers), so no floating-point math is required. Previously, we needed the bc command to handle floating-point math. The numbers, while integers, were too big for the poor old expr command. Any disks with gigabytes of space will overload expr, hence the use of the bc command.

Another important task when troubleshooting a system is verifying that the necessary processes are running, such as a web server or a database, as shown in the following Try It Out.

Try It Out: Checking for Processes

As shown in a number of previous examples, you can use the ps command to list processes:

$ ps -e
  PID TTY          TIME CMD
    1 ?        00:00:00 init
    2 ?        00:00:00 ksoftirqd/0
    3 ?        00:00:00 events/0
    4 ?        00:00:00 khelper
    5 ?        00:00:00 kacpid
   27 ?        00:00:00 kblockd/0
   28 ?        00:00:00 khubd
   37 ?        00:00:00 pdflush
   38 ?        00:00:00 pdflush
   40 ?        00:00:00 aio/0
   39 ?        00:00:00 kswapd0
  113 ?        00:00:00 kseriod
  187 ?        00:00:00 kjournald
 1014 ?        00:00:00 udevd
1641 ?        00:00:00 kjournald
 1642 ?        00:00:00 kjournald
 1892 ?        00:00:00 syslogd
 1896 ?        00:00:00 klogd
 1917 ?        00:00:00 portmap
 1937 ?        00:00:00 rpc.statd
 1970 ?        00:00:00 rpc.idmapd
 2040 ?        00:00:00 nifd
 2070 ?        00:00:00 mDNSResponder
 2083 ?        00:00:00 smartd
 2093 ?        00:00:00 acpid
 2105 ?        00:00:00 cupsd
 2141 ?        00:00:00 sshd
 2152 ?        00:00:00 xinetd
 2172 ?        00:00:00 sendmail
 2180 ?        00:00:00 sendmail
 2191 ?        00:00:00 gpm
 2201 ?        00:00:00 crond
 2227 ?        00:00:00 xfs
 2246 ?        00:00:00 atd
 2265 ?        00:00:00 dbus-daemon-1
 2278 ?        00:00:00 cups-config-dae
 2289 ?        00:00:13 hald
 2299 tty1     00:00:00 mingetty
 2339 tty2     00:00:00 mingetty
 2340 tty3     00:00:00 mingetty
 2411 tty4     00:00:00 mingetty
 2447 tty5     00:00:00 mingetty
 2464 tty6     00:00:00 mingetty
 2587 ?        00:00:00 gdm-binary
 2763 ?        00:00:00 gdm-binary
 2773 ?        00:03:37 X
 3000 ?        00:00:00 ssh-agent
 3226 ?        00:00:00 gconfd-2
 3352 ?        00:00:00 dhclient
 3452 ?        00:00:00 artsd
 5226 ?        00:00:00 gnome-session
 5254 ?        00:00:00 ssh-agent
 5281 ?        00:00:00 dbus-daemon-1
 5282 ?        00:00:00 dbus-launch
 5286 ?        00:00:01 gconfd-2
 5289 ?        00:00:00 gnome-keyring-d
 5291 ?        00:00:00 bonobo-activati
 5293 ?        00:00:03 metacity
 5295 ?        00:00:00 gnome-settings-
 5301 ?        00:00:03 gam_server
 5310 ?        00:00:00 xscreensaver
 5316 ?        00:00:00 gnome-volume-ma
 5318 ?        00:00:01 gnome-panel
 5320 ?        00:00:10 nautilus
 5325 ?        00:00:00 eggcups
 5331 ?        00:00:00 evolution-alarm
 5333 ?        00:00:02 gnome-terminal
 5335 ?        00:00:04 gedit
 5337 ?        00:00:01 rhythmbox
 5342 ?        00:00:00 evolution-data-
5361 ?        00:00:00 gnome-vfs-daemo
 5369 ?        00:00:00 mapping-daemon
 5371 ?        00:00:00 nautilus-throbb
 5373 ?        00:00:03 wnck-applet
 5375 ?        00:00:00 pam-panel-icon
 5376 ?        00:00:00 pam_timestamp_c
 5389 ?        00:00:00 gnome-pty-helpe
 5394 pts/1    00:00:00 bash
 5404 pts/2    00:00:00 bash
 5409 pts/3    00:00:00 bash
 5441 ?        00:00:00 notification-ar
 5443 ?        00:00:00 mixer_applet2
 5454 ?        00:00:00 clock-applet
 5456 ?        00:00:00 gnome-netstatus
 5458 ?        00:00:00 gweather-applet
 5502 ?        00:00:00 scsi_eh_0
 5503 ?        00:00:00 usb-storage
 5619 ?        00:00:51 soffice.bin
 5689 ?        00:00:00 firefox
 5706 ?        00:00:00 run-mozilla.sh
 5711 ?        00:00:04 firefox-bin
 5857 pts/3    00:00:00 ps

How It Works

The -e command-line option tells the ps command to list every process. Most people use the -e option with -f, for full output. In this example, however, the goal is to get the command name and skip the rest of the output; therefore, this uses only -e and not -ef as command-line options to ps.

Note that on BSD-derived Unix systems, such as Mac OS X, the ps option will be aux instead of -e.

This example ran on a desktop system. Note that on a server system, you would likely have a lot more processes.

You can place this type of check into a script, of course, leading to the next example.

Try It Out: Verifying Processes Are Running

Enter the following script and name the file processcheck:

#!/bin/sh

# Checks to see if a given process is running.
# Pass in a command-line argument of the pattern
# to look for. The script will output all the
# occurrences.

pattern=$1

ps -e | grep -v $$ | grep $pattern | awk '{print $4}'

When you run this script, you need to pass a pattern for grep to use to search for the processes, as shown in this example:

$ ./processcheck k
ksoftirqd/0
khelper
kacpid
kblockd/0
khubd
kswapd0
kseriod
kjournald
kjournald
kjournald
klogd
gnome-keyring-d
wnck-applet
clock-applet
awk

Alternately, you can try a longer pattern, such as the following:

$ ./processcheck gnome
gnome-session
gnome-keyring-d
gnome-settings-
gnome-volume-ma
gnome-panel
gnome-terminal
gnome-vfs-daemo
gnome-pty-helpe
gnome-netstatus

How It Works

The processcheck script calls the ps command to list all the processes running on the system. The script directs the output of the ps command to the grep -v command. This command filters out the current process, which should always match the pattern, as the pattern is a command-line argument. (This is called a false positive match.)

The $$ variable is described in Chapter 9.

The script next takes the first command-line argument and passes this to the grep command, filtering out all but the process entries that match the pattern. Finally, the awk command strips out the extraneous data, leaving just the process names. The process names are important in case you pass a partial name as the pattern to match. For example, many system kernel-related processes start with the letter k. Similarly, many desktop applications that are part of the KDE desktop environment also start with the letter k. Without seeing the full process names, you cannot tell what is running.

Note that if you use ps with the aux option, you need to change the awk command to print $11 instead of $4.

Removing Minor Annoyances

Minor annoyances are anything that bugs you (anything small, that is, so Windows security issues don't count). You can use the capabilities of scripts to perform the necessary setup work for commands, so you don't have to.

Whenever possible, let the script do the work, as in the following example.

Try It Out: Running a Command in a Directory

Enter the following script and name the file jabber:

#!/bin/sh
cd $HOME/java/im/BS211-complete ; sh buddySpace.sh

When you run this script, you'll see output like the following:

$ ./jabber
loading preferences...
initializing core...
loading GUI...
loading sounds...
initializing plug-ins...
loading conferencing...
loading mapping...
loading html view...
loading browse...

This script launches the BuddySpace window, shown in Figure 13-1. This simple script performs one task: This version of BuddySpace won't start unless you launch it from its installation directory. Having to change directories prior to launching a program, and having to do this every day, counts as a minor annoyance.

Figure 13-1

Figure 13.1. Figure 13-1

How It Works

BuddySpace provides an instant messaging, or IM, client using the Jabber protocol. Jabber gateways then enable connections to MSN, AOL, Yahoo!, and other IM networks.

See www.jabber.org for more information on the Jabber protocol. See kmi.open.ac.uk/projects/buddyspace for more information about the BuddySpace client application. BuddySpace is written in Java, so it runs on Mac OS X, Windows, Linux, Solaris, and other versions of Unix. BuddySpace also includes an extensive set of frequently asked questions.

Whenever you face a similar situation, you can write a similar script to remove the annoyance. The next script follows a similar concept.

Try It Out: Playing Your Favorite Songs

Enter this script and name the file favs:

#!/bin/sh
xmms $HOME/multi/mp3/fav_playlist.m3u

How It Works

This is another tiny script. It launches the XMMS multimedia player application and passes XMMS the name of a playlist file, telling XMMS which songs to play. Again, the whole point of this script is to save typing.

These examples, while short, should give you some ideas about what you can do with scripts. Once you start scripting the small things, larger things become a lot easier.

Cleaning Up Data

Many programs, systems, and devices log information or can describe themselves, sometimes in excruciating detail. It's the detail that is the problem. You can become overwhelmed by the massive amount of information to slog through just to get to the useful bits. As you'd suspect, scripts can help here as well.

Try It Out: Viewing Linux USB Port Details

On a Linux system, you can gather a lot of information on the USB ports by looking at the special file /proc/bus/usb/devices:

$ cat /proc/bus/usb/devices

T:  Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 3
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.9-1.681_FC3 ohci_hcd
S:  Product=OHCI Host Controller
S:  SerialNumber=0000:00:02.1
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  7 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0781 ProdID=8888 Rev= 1.00
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=83(I) Atr=03(Int.) MxPS=   2 Ivl=1ms

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 3
B:  Alloc= 14/900 us ( 2%), #Int=  1, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.9-1.681_FC3 ohci_hcd
S:  Product=OHCI Host Controller
S:  SerialNumber=0000:00:02.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=1.5 MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=046d ProdID=c00b Rev= 6.10
S:  Manufacturer=Logitech
S:  Product=USB Mouse
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=10ms

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480 MxCh= 6
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.9-1.681_FC3 ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=0000:00:02.2
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=256ms

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  8 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0781 ProdID=7108 Rev=20.00
S:  Manufacturer=SanDisk Corporation
S:  Product=Cruzer Titanium
S:  SerialNumber=00000000000000104629
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=31875us

How It Works

In this example, the Linux box has four USB ports, two on the front and two on the back. Three devices are plugged in: a Logitech USB mouse and two USB flash drives. One of the USB flash drives requires a USB 2.0 port, at least on Linux. Note that although this system has four USB ports, it contains extra entries where devices are plugged in.

Entries with a speed of 480 are USB 2.0 ports. In this data, speed appears as Spd. Entries with a speed of 12 are USB 1.1 ports. USB mice typically reduce the speed. For example, the mouse shown here indicates a speed of 1.5.

USB ports are odd ducks. You can plug in more than one device to each port if the first device has another port or is itself a USB hub with more than one port. Therefore, the system needs to report on any connected devices along with the capabilities of the ports themselves.

Note that reading /proc/bus/usb/devices can take a long time. This is not a real file but part of the pseudo-file system, /proc. You can speed things up with the lsusb command, a Linux-specific command, as shown in the next Try It Out.

Try It Out: Using the lsusb Command

The lsusb command provides a quick overview of the USB ports and devices on a system:

$ /sbin/lsusb
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 002: ID 046d:c00b Logitech, Inc. MouseMan Wheel
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 003: ID 0781:7108 SanDisk Corp.
Bus 001 Device 001: ID 0000:0000

The lsusb command can also output data in tree mode, as shown here:

$ /sbin/lsusb -t
Bus#  3
`-Dev#   1 Vendor 0x0000 Product 0x0000
  `-Dev#   2 Vendor 0x0c76 Product 0x0003
Bus#  2
`-Dev#   1 Vendor 0x0000 Product 0x0000
  `-Dev#   2 Vendor 0x046d Product 0xc00b
Bus#  1
`-Dev#   1 Vendor 0x0000 Product 0x0000
  `-Dev#   3 Vendor 0x0781 Product 0x7108

The preceding example shows the three USB buses, each with a connected device.

You can ask the lsusb command for more information, but you usually must be logged in as the root user to do so. You will also need a kernel at version 2.3.15 or newer. The -v option, for example, tells the lsusb command to output verbose information, as shown here:

# /sbin/lsusb -v -s 003

Bus 001 Device 003: ID 0781:7108 SanDisk Corp.
Device Descriptor:
bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0781 SanDisk Corp.
  idProduct          0x7108
  bcdDevice           20.00
  iManufacturer           1 SanDisk Corporation
  iProduct                2 Cruzer Titanium
  iSerial                 3 00000000000000104629
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk (Zip)
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               none
          Usage Type               Data
        wMaxPacketSize     0x0200  bytes 512 once
        bInterval             255
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               none
          Usage Type               Data
        wMaxPacketSize     0x0200  bytes 512 once
        bInterval             255
  Language IDs: (length=4)
     0409 English(US)

How It Works

This example just prints out verbose information on one device, 003 (Bus 001 Device 003 from the previous example). One line in particular indicates that this system supports at least one USB 2.0 port:

bcdUSB               2.00

You can use the grep command to search for this entry on all USB devices:

# /sbin/lsusb -v | grep bcdUSB
  bcdUSB               1.10
  bcdUSB               1.10
  bcdUSB               1.10
  bcdUSB               2.00
  bcdUSB               2.00

The USB 2.0 ports indicate that a given system can support more sophisticated USB devices. You can look for them with the following script.

Try It Out: Checking for Modern USB Ports

Enter the following script and name the file usbcheck:

#!/bin/sh

# Checks for the USB version support, typically 1.1 or
# 2.0, for USB ports on a given Linux system.
#
# NOTE: You must be logged in as root to run this script.

echo "USB support:"
/sbin/lsusb -v | grep bcdUSB | awk '{print $2}'

When you run this script, you'll see output like the following:

# ./usbcheck
USB support:
1.10
1.10
1.10
2.00
2.00

How It Works

Remember that you must be logged in as root to run this script. This script starts with the lsusb command in verbose mode, which outputs far too much information to be useful. The script redirects the output of the lsusb command to the grep command to search for the entries on USB specification support, such as 2.0. The script redirects the output of the grep command to the awk command, to remove the odd bsdUSB text and just show the USB version numbers.

In addition, the script outputs a header line of its own, to help explain the output.

Ironically, this script and the information extracted from /proc/bus/usb/devices helped determine that an older Linux box had two USB 2.0 ports, on the rear of the machine, of course. The front USB ports are all USB 1.1. This is important because certain devices won't work on Linux connected to a 1.1 port. The Sandisk Cruzer Titanium, listed in the previous output, is one such device.

Automating Daily Work

Anything you do day in and day out falls into this category. Use the techniques shown in the previous examples, as well as the previous chapters. Once you have created a script to automate some aspect of your work, you can schedule that script to run at a particular time.

The cron scheduler, introduced in Chapter 12, enables you to run commands on a periodic schedule. You can use cron by setting up a crontab file that specifies when to run the script. Other than the scheduling, however, this type of scripting is the same as any other kind.

Summary

Scripts are an administrator's best friend. They can remember things for you, speed up your work, and sort through yucky output, extracting just the nuggets of useful information necessary to make informed decisions.

This chapter focused on using scripts, and spending very little time writing them, for a big return in time saved for common administrative work. The scripts in this chapter are intended to provoke discussion and further thought about what you can do with scripts.

In the administrative arena, scripts can help you with the following:

  • Remembering complicated commands, command-line options, and command-line arguments for you

  • Troubleshooting, such as checking the amount of available disk space and whether certain types of processes are running

  • Removing minor annoyances

  • Digesting voluminous data and extracting useful information

  • Repetitive tasks you do every day

  • Anything else that bothers you or you think is ripe for scripting

The next chapter switches gears from boring administrative work to fun, graphical, splashy desktop automation. You can use scripts to help with desktop applications as well, especially on that most graphical of systems, Mac OS X.

Exercises

  1. Identify some issues at your organization and discuss how you can use scripts to help reduce the problems. (Stick to issues related to your computer systems, rather than annoying colleagues or dim-witted managers.)

  2. Look at the online documentation for the ps command. Discuss at least three useful things ps can report.

  3. Write a script to determine whether a given file system or mount point is mounted, and output the amount of free space on the file system if it is mounted. If the file system is not mounted, the script should output an error.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.189.170.134