This site uses advanced css techniques
We've been happy users of the excellent Postfix mail server for some time -- it's so much of a nicer experience than Sendmail. In the process we've developed a minor technique for managing the various small database files that Postfix uses, and we've been asked to elaborate on them. Hence this Tech Tip.
BUT - this is not a tutorial on Postfix, nor is it designed to provide configuration advice. This is exclusively about how to manage the configuration that you've come to on your own.
The postfix main.cf configuration file can specify the location of several small database files (the "maps"):
virtual_alias_maps = hash:/etc/postfix/virtual transport_maps = hash:/etc/postfix/transport relay_domains = $mydestination, $mydomain, hash:/etc/postfix/relays ...
and so on. These are "hash" maps that are that are maintained in Berkeley DB format (there are other map formats, but we're not addressing them here). The files are maintained in regular text format, then "compiled" into the DB format with the postmap command, which is provided with Postfix.
Building any given map file is easy enough, and we'll use the transport file as an example:
# cd /etc/postfix # vi transport example.com smtp:[mail.example.com]:25 ... # ls -l transport* -rw-r--r-- 1 root root 7292 Nov 30 2002 transport # postmap transport creates "transport.db" from "transport" # ls -l transport* -rw-r--r-- 1 root root 7292 Nov 30 2002 transport -rw-r--r-- 1 root root 12288 Sep 26 14:24 transport.db
Subsequent edits of this file simply require running postmap transport command again to rebuild the .db file.
But as the number of these .db files increases, it gets harder to keep track of which ones must be rebuilt after a handful of edits: configuration changes are often made in groups. It's possible to create a small shell script to do this:
# cd /etc/postfix # cat rebuild-maps cd /etc/postfix newaliases the "aliases" file is a special case postmap transport postmap relays postmap virtual ... # chmod +x rebuild-maps # ./rebuild-maps
Though this is simple, it rebuilds files even when not necessary. We have used the make command for so long that employing it here feels really natural to us. It's one of the oldest parts of the UNIX software-development toolkit.
A "makefile" is a small text file that describes the dependency relationships between various files, as well as instructions on how to rebuild target files from source files. That's exactly what we're doing here: in the example we showed earlier, "transport" is the source file and "transport.db" is the object file.
1: MAPS = relays.db aliases.db transport.db relocated.db \ 2: virtual.db sender_checks.db rejected_recips.db \ 3: helo_access.db 4: 5: all : $(MAPS) 6: 7: aliases.db : aliases 8: tab newaliases 9: 10: %.db : % 11: tab postmap $*
We'll review this makefile, though not strictly in top-to-bottom order. We use GNU Make exclusively - older makes don't have quite the same syntax for all the parts.
When the make command is run, it finds the first target in the file and uses it as the overall goal. In this case, it's all. This isn't a "real" target (in the sense of actually creating a file with that name), but it's a common catch-all virtual rule.
The dependencies are all the files on the right side - the elements of the $(MAPS) macro - and each one goes through the same process. The list of all rules is consulted, and a "best match" is found if possible. A more-specific rule always matches over a less-specific rule: even though the lines 10.11 rule could build aliases.db from aliases with the postmap command, the most specific rule just above it is used instead.
Once the makefile is constructed, one simply edits the text files as needed, then type make.
IMPORTANT - where a tab is indicated, it must be present - use of spaces is not equivalent. Mistakenly using spaces instead of a tab is one of the leading causes of broken makefiles. This is not obvious.
We are not at all anxious to get into the "make tutorial" business, but there are a few additional notes we'll touch on.