Automate your sysadmin with adl
I used to work for a company that was in the business of deploying laptops running Linux into hospitals. We automated the installation of these laptops to such a degree that all we had to do build a new laptop was unwrap it, plug it into an ethernet network and turn it on. We used PXE boot and our own bespoke deployment system to achieve it. It even supported deploying automatic configuration updates over a mobile phone connection, while the laptops were in a different country.
It never seems to be worth going to the effort to setup a tool like cfengine or puppet when configuring a new desktop computer, a virtual server to run your blog, or a VPS for a small client who is keen to keep the budget down. But why should automation be expensive?
There's a little tool that I use when I want automation, but I need to do it on the cheap;
adl. I think "adl" standards for "ADmin Log", but it's so long since I wrote it that I forget.
Download the latest version, then unpack the tarball and type:
$ sudo cp adl /usr/local/bin
$ sudo chmod +x /usr/local/bin/adl
adl like this:
$ sudo adl -C Installing mongrel and god
$ sudo adl apt-get install ruby1.8-dev -y
$ sudo adl gem install mongrel
$ sudo adl gem install god
adl runs each command for you, and records them in a log file if they execute successfully. The log looks something like this:
# 2008/01/14: Installing mongrel and god (graham)
apt-get install ruby1.8-dev -y
gem install mongrel
gem install god
Note the format of this log file; it is indistinguishable from a shell script. Yep, that's right — it's your replayable record of what you did to setup your computer. Documentation and automation in one. Nifty.
-C option added a block comment. They come in handy when you're reading through the log a few months later to find out just how you configured something. Use a lowercase
-c to add a one line comment without a date stamp.
Recording changes to files
A replayable log is no good to you if you only record half the changes. What happens when you make some changes to a config file?
adl will keep track of changes to files too. Since we installed
god above, we might want to configure log rotation. That means we need to create a new file. Don't use vi/nano/emacs/whatever here; use
adl with the
$ sudo adl -e /etc/logrotate.d/god
adl will open your editor of choice (set the
EDITOR environment variable to choose; if it's not set it'll default to
vi) so you can create/change the file, then save your file to disk. It will also append the changes to the log file, again in a replayable manner. Here's the log entry for our logrotate.d file:
cat <<'EOPATCH' > /etc/logrotate.d/god
The Unix heads amongst you will have noticed that the above snippet will overwrite any existing copy of the file. Worry not,
adl knew the file didn't exist before hand. If we now make a one line change to that file, we get something slightly different written to the log:
patch /etc/logrotate.d/god <<'EOPATCH'
--- /etc/logrotate.d/god.orig 2008-04-05 10:02:05.000000000 +0000
+++ /etc/logrotate.d/god 2008-04-05 10:02:13.000000000 +0000
@@ -3,5 +3,5 @@
- rotate 28
+ rotate 14
That's it in a nutshell. Can you think of a way to improve on this? Leave me a comment, or check out the source and play with it yourself.
- Add a block comment before you start a major task.
- Change the editor used to edit files by setting the
- Change the name of the log file used by
adlby setting the
adlto install itself, by copying the script to your freshly installed computer and then typing
sh ./adl -e /usr/local/bin/adl. Then load the contents of the
adlscript into the editor and save it. Hey presto - it records it's own installation in the log file!
- Test how easy it is to rebuild your servers before you need them; setup a freshly installed virtual machine and try exectuing your logs.
Automated server administration on the cheap involves:
- Installing your operating system in the usual manner.
- Installing and using
- Backing up your
- Rebuilding a freshly installed computer by typing