One of my favorite automation strategies is to use Makefiles. The reason is that unlike a shell script you get free error-checking: a Makefile will bomb out on you if one command in the sequence fails. You can also chain targets together, lay out sub-dependencies, and the rest. I’m just finishing up on a little project which has this as the top-level target:
# default all: dhcp sync yay # cron-able dhcp: hosts restart-dhcpd # Positive feedback rocks! yay: @echo @echo "YAY! Have a fortune cookie:" @echo @fortune -sa
The first target, “all” is what will be run when a user types “make” and you see that things get broken down further. The “sync” target depends on the user to either enter a password or forward an ssh credential.
The last target I’m particularly proud of. It is nice that a Makefile will bail when it hits an error, but I for one have been known to kick off a command and turn my attention elsewhere and not notice if it failed. I try not to do this . . . but we all screw up sometimes, and the chance of missing whether the command succeeded or not is greater when the command takes a while to complete.
I see a possibility of someone running a command that breaks DHCP and then failing to notice, and that bothers me. How do we reduce the chances of this happening? Well, give the user something to look forward to! It will be fun to seek your fortune cookie and if there is no fortune cookie you know it is time to hustle and fix things!
Alas, I just deployed the system on one network, and this feature caused me a moment of concern. I ran
make, scrolled past a bunch of output, and ended up with:
YAY! Have a fortune cookie: I'm so broke I can't even pay attention.
That’s the sort of flip error message I would expect me to embed in a process, so I had to wonder what that message meant. Then I said “but the fortune cookie bit only comes at the successful end, why is there an error . . . oh! HAHA!!”
Process worked fine, it was my own sense of humor that failed.