Eat. Pray. Script.

I don’t know if I’ll ever be as famous as Steve Jobs, but if you ask me how to perform just about any repetitive administrative task, I’ll tell you, “There’s a script for that,” and its corollary is: If there isn’t a script for that, write one.

If you look at any system administrator job description, there’s a listing for scripting somewhere in it. Sys admins must script. And, if you’re a good administrator, you’ve Googled to see whether some clever sys admin has already created the script you need. There’s no use reinventing the wheel or writing and debugging your own script if someone else has gone to the trouble for you. After all, you couldn’t rightfully earn the “lazy administrator” label if you started from scratch every time. And, by lazy, I mean smart.

Smart administrators attempt to automate every task possible with scripts: file transfers, file copys, temporary file removals, idle account lockouts, backups. On the surface, smart administrators appear lazy. The truth is, they’re hard at work in the background via scripts, cascading scripts, and cron jobs, and they’re hard at work in the foreground creating even more scripts to do their bidding.

A computer is the perfect minion: It’s dumb but ready to help, it never complains about what time it is when you ask it to do something; it does exactly what you tell it to do, and it doesn’t take breaks, vacation, or sick days. It’s always there ready to execute your every command.

Automation doesn’t neccessarily mean firing off a script to restart a service, copy a file or start a backup, although it certainly can mean that. For example, you have 300 servers that require a change to a particular configuration file. It might take days to complete that task manually, but, if you write a script to make the connection to the remote system, copy the file with the new information, restart the service, disconnect and proceed to the next system, the entire process might take less than an hour.

Consider a second example in which you must routinely change the Administrator password on hundreds of Windows server systems. How would you do it? Again, connecting to each one manually would be an overwhelming and lengthy task. Writing a simple script to handle the task takes a fraction of the time, and there’s no chance of a misspelling or accidental system omission along the way. A script performs the same tasks on each system it touches.

Which Language?

I’ve found no scripting language to be superior to any other for automation. In fact, for any particularly complex task, I might employ multiple languages. For example, Perl is an extremely mature and powerful language for extracting information from systems and databases. Modules exist for just about every possible parameter, registry entry, and system information bit that you can imagine. It also has a variety of database modules that allow you to connect to and query most database systems.

Bash is very good at handling lists and loops. Plus, you can call other scripts from it easily. For automation scripting, I always start with Bash and work my way through the other languages as needed per task. Although not written in stone, my standard language preference priority is: Bash, Perl, PHP, Expect. If I can’t do something in Bash (e.g., efficiently query a database), then I’ll use Perl or PHP. I turn to Expect for those times when I need the magic of automated shell interaction.

The difficult part of Expect is that you have to be able to predict and emulate shell responses. Autoexpect helps you sort through the unexpected shell responses and prompts. It isn’t perfect but it cuts down on your script debugging time.

PHP is an all-around good language like Perl. Often, when I find that a particular task is too difficult to do (for me) in Perl, I’ll create a PHP script to handle the processing. For certain jobs, such as creating dynamic web pages, its syntax and flexibility make quick work of an otherwise lengthy project. But, it’s also a matter of preference. You might feel the same way about Perl or Ruby.

But, the takeaway for language selection is to pick the one or ones with which you feel most comfortable. Since Perl, PHP, and Bash have a common C language heritage, it’s easy for me to cross-program in them all.

Dedicated Automation Systems

My personal preference is to create what I call “dedicated automation systems” to use as the pivot point for all automation. If I have a mixed environment comprising Windows, Linux, and Unix, I’ll spin up a virtual machine (VM) or a decommissioned physical machine for my automation systems. Creating dedicated systems separates them from those in production. If you maintain your automation systems outside of production, you can also reboot as necessary, reimage as necessary, install and uninstall applications as needed, and test at will.

Virtual machines are excellent choices to use as dedicated automation systems for all of the reasons given above. VMs also give you the opportunity to test and debug your scripts without harm to any production system.

Your requirements will vary, but on my automation systems, I always install the following components for Windows: Cygwin (complete), PHP, and PsTools. Cygwin is a huge subset of Linux/Unix tools for Windows systems, including Perl, Expect, and many others. Using it allows you to create cross-platform scripts for automation without having to use Windows tools in addition to Linux/Unix tools. You can leverage one set of skills for all operating environments.

PsTools, created by Mark Russinovich of Sysinternals (now owned by Microsoft), is a set of absolutely essential tools that are useful even in an all-Microsoft environment.

For Linux and Unix systems, I install Webmin, PHP, MySQL, Apache, and Expect. Perl is now a standard part of most Linux distributions. If it isn’t part of yours, install it. Use Webmin to add modules to your Perl installation. Its interface is far easier to use than CPAN’s command-line interface. Additionally, Webmin provides you with a web-based graphical interface for managing almost every aspect of your Linux or Unix system.