Thomas Limoncelli - Time Management for System Administrators

For example, after editing /etc/aliases (part of sendmail, Postfix, and various mail-transport-agent packages), you must run the newaliases command. That's pretty easy to remember, right?

After editing Postfix's transports file, should you run the newtransports command? No, that would be too obvious. You must run postmap transports. And there is the m4 command to run after editing .m4 files, and so on and so on.

Who has time to remember which command is used after which file is edited? Details like that are what computers are for.

make to the rescue! You might think of make as a programming tool—the program you run when compiling software. In reality, it lets you set up any kind of relationship involving the need to run a command to update one file if another changes.

Tip

make is one of the most powerful system administration tools ever invented. I hear programmers find it useful, too!

make has more features than Liz Taylor has had husbands, so I'll give a short introduction. (If you read the first two chapters of most books on make , you'll know 99 percent of what you need to for most system administration tasks and 10 times more than what your coworkers know.)

A Brief Introduction to make

make reads a configuration file aptly named Makefile . In this file, you will find recipes. They instruct make how to do its work.

Each recipe looks like this: whole: partA partB partC command that creates whole

The recipe begins with the file that is going to be created, then a colon, and then it lists the files needed to build the main file. In this example, the recipe is about whole and establishes a relationship between it and partA, partB, and partC. If partA, partB, or partC is ever updated, then we need to (re)run the command that generates whole.

A real-world example helps: aliases.db: aliases newaliases @echo Done updating aliases

This code means that if aliases is changed, regenerate aliases.db using the command newaliases . Then the recipe outputs "Done updating aliases" to announce its success.

Notice that the second and third lines of the recipe are indented. They must be indented with a tab, not multiple spaces. Why? My theory is that the original creator of make wanted to punish me every time I use cut-and-paste on a system that turns tabs into spaces. However, I don't take it personally.

The update doesn't happen automatically. You have to run make to make it happen: Server1# make aliases.dbnewaliases Done updating aliases Server1#

That's it! make read its configuration file, figured out that aliases was newer than aliases.db by checking the timestamp of the files, and determined that running newaliases would bring aliases.db up-to-date. If we run it again: Server1# make aliases.dbServer1#

There's no output. Why? Because now the timestamps on the files indicate that there is no work to be done: aliases.db is newer than aliases . make is lazy and will calculate the minimum amount of work required to do what you ask. It makes these decisions based on the timestamps of the files.

Here's another Makefile code sample: file1.output: file1.input command1 file.output file2.output: file2.input command2 file2.input >$@

In the first example, the command to be run uses stdin and stdout (file redirection using < and >) to read file.input and write file.output . The second example is similar, but the command takes the input filename on the command line and redirects the output to...what? Oh, $@ means "The file that this recipe is creating," or, in this case, file2.output . Why isn't it something simple like $me or $this? Who knows! You don't have to use $@, it just makes you look smarter than your coworkers.

make with no command-line parameters runs the first recipe in Makefile . It is traditional to name the first recipe all and have it run all the recipes you would expect as the default. This way, running make makes all the important recipes. It might not be literally all the recipes, but it is all the recipes you want to make by default. It might look like this: all: aliases.db access.db

make with no options then makes sure that aliases.db and access.db are up-to-date. Since there is no command as part of all, no file called all will be created. Thus, make always thinks that all is out-of-date ("Doesn't exist" equals "Is out of date"). You'll soon see why that is important.

Remember that make is lazy. If access.db is out-of-date but the other file isn't, it just runs the commands to bring access.db up-to-date. In fact, if bringing access.db up-to-date required something else, and that required something else, and so on, make would very intelligently do just the minimum work required.

In addition to all, I usually include a couple of other useful commands: reload: postfix reload stop: postfix stop start: postfix start

Think about what that means. If I run make reload, make is going to notice that there is no file called reload , so it will run postfix reload thinking that the command will create a file called reload . Ah ha! I fooled them, didn't I? The command I listed tells postfix to reload its configuration. That command doesn't create a file called reload at all! Therefore, the next time I run make reload, make will run the command again. In other words, if you want something to always happen, make sure the recipe simply doesn't create the file that make is expecting to create.

With the above code in my Makefile , I can reload, stop, and start postfix by typing make reload, make stop, or make start, respectively. If there are other things that should be stopped (for example, an IMAP server, web-based email client, and so on), I can include commands to do those things in the recipes. I don't have to remember all the commands.

This is a good time for me to point out a little lie that I told earlier. I said that each recipe begins with the file that is going to be created, followed by a colon, and then it lists the files that make up the main file. make doesn't know whether those files really make up the file to be created. There's no way it could tell. Those items listed after the colon are really just dependencies that must be up-to-date.

Here's a simple Makefile from a system that runs Postfix and includes recipes for rebuilding the index for aliases and access. You'll notice that at the top are some constants (NEWALISES, PDIR, and so on) that are used throughout the file. Also, a backward slash (\) at the end of the line is used to continue long lines: NEWALISES=/usr/sbin/newaliases PDIR=/etc/postfix POSTMAP=/usr/local/postfix/sbin/postmap # The "commands" all: $(PDIR)/aliases.pag $(PDIR)/aliases.dir \ $(PDIR)/access.dir $(PDIR)/access.pag reload reload: postfix reload stop: postfix stop start: postfix start # # When aliases changes, generate the .pag and .dir files # $(PDIR)/aliases.pag $(PDIR)/aliases.dir: $(PDIR)/aliases $(NEWALIASES) # # When access changes, generate the .pag and .dir files # $(PDIR)/access.dir $(PDIR)/access.pag: $(PDIR)/access $(POSTMAP) $(PDIR)/access

Now I can edit either aliases or access and type make. I don't have to remember that the commands to update the indexes are extremely different. And I don't have to remember to tell postfix to reload its configuration each time because the all recipe includes that. The reload at the end of all will trigger that recipe every time.