Linux.com

Feature

The Tenth Commandment of system administration

By Brian Warshawsky on June 27, 2005 (8:00:00 AM)

Share    Print    Comments   

If you're a system administrator, eventually you're going to need to write a shell script. If you're like me and you enjoy scripting, you'll find reasons to write shell scripts for just about everything.

X. Thou shalt not waste time doing repetitive and mundane tasks

hell scripts are nothing more than a semi-sequential list of commands for your shell to run to automate a process that might take you days or weeks to do. This can include sorting syslog entries on a remote logging server, polling your servers for newly available network services, automating your backup policies, creating user accounts, and any other number of tasks. These tasks can be accomplished with any number of different shells, but by far the most common is bash, so that's what we'll focus on here.

I have always believed the best way to learn is by example, so we'll look at an actual shell script to explain some of the fundamentals. In the following example, we're going to take a look at a script I wrote to facilitate packet captures within a a network for visual playback in a program called EtherApe. Don't worry if you don't understand everything in it right away. I'll explain it all in due time.

Except for the first line, a pound sign within a script denotes a comment, and anything following on that line is ignored when the script is parsed.

#!/bin/bash

# This is called the 'shebang' and all your scripts should start with #it.
# It tells the operating system where to find the shell to interpret
# your commands.

# The following line is a denotes a function, which is a set of code
# that you can write once, but call as many times as you'd like during
# the execution of your script.
kapture ()
{
name=`date +%T`
tethereal -i eth0 -a duration:900 -n -w<nobr> <wbr></nobr>/kapture/current/$name.kap
}

cleanup ()
{
find<nobr> <wbr></nobr>/kapture/archive -mtime +7 -exec rm {}\;
}

archive ()
{
archive=`date +%d.%m.%y`
cd<nobr> <wbr></nobr>/kapture
tar --create --file=./archive/$archive.tar<nobr> <wbr></nobr>./current/*
rm<nobr> <wbr></nobr>/kapture/current/*.kap
}
# The Kapture function uses a CLI based version of ethereal to capture
# packets and stores them into a time stamped file.  The cleanup
# function is used to go through once a day and remove any file modified
# more than 7 days ago.  The archive function is used to collect 24 hours
# worth of data into a single tar file for easier storage.

kapturecount=0
a=1
b=2
# Above I've declared variables for use in my upcoming loop.  Note that
# a and b are used only as a cheap method of making sure that the loop
# never ends.

while [ "$b" != "$a" ]    # 1 will never equal 2, so the loop continues
do
kapture  # here we're calling the function we declared at the beginning.
((kapturecount++))  # This is called an incremental, or a counter.
#It's what keeps track of how many times the loop has run.
# Below are if loops to check the value of the counter, and act
# accordingly.  Because each kapture runs for 15 minutes, this works
# out to about every 24 hours.
if [ "$kapturecount" == 95 ]
then
	archive
fi
if [ "$kapturecount" == 96]
then
	cleanup
	$kapturecount=0   # reset the loop count and start again.
fi
done

There is more to this script, in the form of playing with the<nobr> <wbr></nobr>.kap files that it creates, but we'll leave that for now. Notice that functions are always created and declared before they are run within the script. Basically, we've just told the computer to remember each of those sets of commands for later use. You cannot call a function before you've declared it, or it will not work.

The loops are important as well. These can prove useful for determining the direction the script takes depending on the outcome of defined tests, as illustrated above. They can also perform a variety of actions on lists of files, files in a directory, or any number of other options. A basic understanding to loops is essential for effective shell scripting.

This shell script isn't perfect, and it isn't the only way to accomplish the task at hand. Indeed, there are probably more powerful commercial tools available that would do a much better job of traffic analysis. However, I developed this in a hurry to troubleshoot a problem, and as a result, it meets my specific needs better than any commercial application could.

If you're interested in learning more about shell scripting, I recommend you pick up Ken Burtch's book "Linux Shell Scripting with Bash." It is an excellent guide for explaining the intricacies of bash shell scripting, and provides many fine examples of solutions to various problems.

Conclusion

We've made it to the end. I hope you've been able to pick up a few helpful tidbits of information to facilitate your role as a system or network administrator. I know over the years these 10 basic rules have served me well, and I sincerely hope they can do the same for you. It is important to never forget the fundamentals of your profession, as it is often easy to get carried away and overwhelmed by the details that make up our careers. When something like that happens, it becomes easy to forget the reasons why we all started this work in the first place -- likely, because of an underlying love for technology and the things we can make it do. Whether you're designing a backup system, tracking log files, monitoring your network, or any of the other tasks, routine or not, that you tackle every day, you should always enjoy what you do.

The 10 commandments:
I. Thou shalt make regular and complete backups
II. Thou shalt establish absolute trust in thy servers
III. Thou shalt be the first to know when something goes down
IV. Thou shalt keep server logs on everything
V. Thou shalt document complete and effective policies and procedures
VI. Thou shalt know what cable goes where
VII. Thou shalt use encryption for insecure services
VIII. Thou shalt not lose system logs when a server dies
IX. Thou shalt know the openings into your servers
X. Thou shalt not waste time doing repetitive and mundane tasks

Share    Print    Comments   

Comments

on The Tenth Commandment of system administration

Note: Comments are owned by the poster. We are not responsible for their content.

Hades scripts

Posted by: ubahmapk on June 27, 2005 11:40 PM
Wow. didn't know I could write 'hell scripts' in linux!

#

Re:Hades scripts

Posted by: Anonymous Coward on June 28, 2005 12:05 AM
Yeah. You guys might want to fix that.

#

infinite loop

Posted by: Anonymous Coward on June 28, 2005 12:14 AM
You can simply use while [ true ]

#

Re:infinite loop

Posted by: Anonymous Coward on June 28, 2005 02:20 AM
You can simply use while [ true ]


The brackets aren't even necessary. while true is sufficient.

#

Re:infinite loop

Posted by: Anonymous Coward on June 28, 2005 11:47 AM
Or even while : and save another 3 bytes<nobr> <wbr></nobr>:-)

#

Re:infinite loop

Posted by: Anonymous Coward on June 29, 2005 08:07 AM
Yeah, but 'while true do' has a cretain ring to it. No?

#

Re:infinite loop

Posted by: Anonymous Coward on June 29, 2005 08:09 AM
cretain? Froyd? Is that you?

#

Re:infinite loop

Posted by: Anonymous Coward on June 29, 2005 03:21 PM
Yeah, but everyone knows that : returns true, surely?<nobr> <wbr></nobr>:-)

#

Parameter testing

Posted by: Anonymous Coward on June 28, 2005 12:09 PM
You could tidy the script a little with:
case "$kapturecount" in
95) archive<nobr> <wbr></nobr>;;
96) cleanup; kapturecount=0
esac

And the line which goes:
$kapturecount=0 # reset the loop count and start again.
Should really be (surely?):
kapturecount=0 # reset the loop count and start again.

This has been a great series. All kudos to Brian Warshawsky for a great series of articles to help budding sysadmins and adding some food for thought to grey-beards as well.

#

Possibly use a newer language?

Posted by: Tall Mario on June 28, 2005 06:48 PM
The bash shell has been around since the first version of Unix, and doesn't seem to have changed much since then. In particular, it seems to lack concepts such as Objective Orientation and Garbage Collecting which are essential for modern programming development.


Perhaps a more modern language could be used for this instead. Java provides all the features of a modern language, and recent versions of Java are GIT-compiled for speed. It seems to me that with a more powerful language and greater performance, Java would make a much better alternative.

#

Re:Possibly use a newer language?

Posted by: Anonymous Coward on June 28, 2005 11:27 PM
And that power is excessive for most sys admin tasks. Scripts are for small repetitive tasks. If you need to do more, well, that's when you move to something bigger.

#

Re:Possibly use a newer language?

Posted by: vtre17 on June 29, 2005 12:19 AM
What would we do without your overly insightful comments...

#

Re:Possibly use a newer language?

Posted by: Anonymous Coward on June 29, 2005 07:59 AM
Now, 'C' here!

#

Re:Possibly use a newer language?

Posted by: Anonymous Coward on June 29, 2005 08:24 AM
import java.io.*;

class MyExecClass {

Runtime runEnviron = Runtime.getRuntime();
try {

        Process newProcess = runEnviron.exec("/usr/bin/normalUnixCommand");
} catch (IOException e) {

        System.out.println("Problem with command.");
}

}

compared with

#!/bin/bash<nobr> <wbr></nobr>/usr/bin/normalUnixCommand

I Have Been Trolled. I Have Lost. I am having a nice day.

#

Re:Possibly use a newer language?

Posted by: Anonymous Coward on June 29, 2005 11:19 AM
You are free to use OO perl or python as a scripting language.... as far as I know you can't create executable text files using the java programming language, though.

#

Re:Possibly use a newer language?

Posted by: Anonymous Coward on June 29, 2005 03:13 PM
Bash (sic) is a relative whipper-snapper and was certainly not around with the first version of Unix, or for many, many years. Just to be pedantic.

Maybe we should use fortran for all those numeric scripts that sysadmins use<nobr> <wbr></nobr>;-)

The original script shows exactly the philosophy of what a sysadmin needs in a language. Just a simple and quick tool to link together the executables, that an admin uses, to make something powerful which does exactly what is needed. You can't buy that, no-body sells the tool that suits your exact needs. Well, at least that's the opinion of an old fart like me.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya