We’ve a few Exchange admins at work this week for a special
project (for those of you outside the technorati, Microsoft Exchange is
a mail server). One of them dropped by my cube because he was
interested in the software I use to relay mail (it, too, is a mail
server—I’ve just configured it to pass on mail rather than
holding onto it). So I gave him a quick overview of the commands I use
to see how many messages are sitting in the queue, to count the number
of probably spams, and to track the progress of a message through the
system, from arrival, through processing and to departure to its final
destination.
The look on his face was priceless. Stunned, he said something along
the lines of Now I understand why you guys love Unix so much;
it’d have taken us twenty minutes to do that, and with no
guarantee of the correct result.
It had taken me something rather
less than a minute.
Yes, Unix has a bit of a learning curve, but once learnt it is part
of one’s being, and its capabilities are tools which lie ready for
one’s hand. All useful skills require a bit of learning, but the
payoff is worth it.
For those who are curious, mailq is a command which prints
out a list of the messages currently queued up, whom they’re from,
whom they’re to & their status, and finally prints the number
of messages sitting in the queue & the number of bytes their
contents sum to. tail is another command which shows the end
of a file (its tail, you see); so I simply typed mailq | tail
-1, which shows the very last line of the output from
mailq.
Since I know that a message sitting in the queue for MAILER-DAEMON is
probably a bounce from a spam (genuine MAILER-DAEMON messages are almost
always delivered instantaneously), I just search the output of
mailq for the string MAILER-DAEMON. Fortunately enough,
there is a Unix command to search for things: the general regular
expression parser (which can do much more complex things than look for a
particular string, of course), or grep, so I can run
mailq | grep MAILER-DAEMON and see only those lines which
contain that string. Of course, that’s not overly useful—I
don’t really care to see them; I just wish to
count them. There is another command, wc, which
counts the number of characters, words and lines in a file (the name
comes from word count), so all I need to do is run mailq | grep
MAILER-DAEMON | wc -l (the -l tells wc that
I just want the line count, not the rest of the info); since each line
corresponds to a single message, I know the number of messages. So now
I know how many messages there are for MAILER-DAEMON, and I know that
messages for MAILER-DAEMON sitting in the queue are almost certainly
undeliverable bounces from spams, I know how many of the messages in
queue are likely to be caused by spam.
Likewise, when tracing the progress of a message through the system,
I just have to examine the logs. They’re simple text files which
I can search with grep, perhaps looking for the address of
the sender or the recipient—from that found line I can get the ID
of the message, and from that I can search the logs for only those lines
pertaining to that message. I can see it arrive; I can see the mail
server (postfix, a truly excellent
bit of software) pass it back-and-forth as it determines where it needs
to go & examines it to see whether it might be spam, and I can see
it leave.
All these examples use standard bits of the Unix toolkit. Unix was
first used for word processing, and those text-oriented tools make
searching through system logs dead simple. Since a large portion of a
sysadmin’s work involves examining logs, that means that Unix
makes my job dead simple.
I pity those yoked with lesser systems.
