Managing Root's Email

Mike Donovan

I get lots of email, consisting mostly of junk (of course), notes from co-workers, and reports from scheduled jobs. The junk I just delete, the notes I keep and/or reply to, and the reports I used to read once and throw away. However, I sometimes regretted that practice when the information was needed later. In this article, I'll describe how I set up a shareable, self-maintaining repository for such reports, using Cyrus IMAP and its "expire" feature.

The Problem

I work at a fair-sized community college (7,500 students, 1,200 desktops, and a few dozen servers), and we were (until recently) working without a full-time sys admin, so several of us were sharing sys admin duties. Each of us used to receive all of the usual cron job-generated reports, but few of us kept the reports after reading them. When something broke, we would try to go back and look at recent reports to figure out when the problem started, but first we would have to find those reports or go dig though log files instead.

We needed a simple, easily accessed shared repository for those emailed reports, which would maintain itself (much as "logrotate" maintains syslog's files), and from which no one could prematurely delete anything.

The Solution

There are many ways to approach this problem, but my solution was based on our recently completed installation of Cyrus IMAP, a mailbox server that was also designed to provide an IMAP interface to a USENET News server. As such, it includes two very helpful features: well-implemented shared mailbox access (with full access control), and an "expire" feature that would normally be used only on "news" folders.

To begin, I created a new IMAP account called "logcollector". (We're using Cyrus IMAP with an LDAP user database, so I just created an LDAP entry and let Cyrus's autocreate patches do the rest.)

Then, I logged into the account via our local SquirrelMail Web-based mail client setup. (We've also installed Alexandros Vellis's excellent SIEVE filter editor and shared folder access control plug-ins; I'll be using those later on.)

I created one new folder within that account, called "14days". I then opened up a root shell on the mail server and used Cyrus's "cyradm" tool to set the "expire" attribute on that folder:

# cyradm -u cyrus-admin localhost
IMAP Password:
localhost> mboxconfig user/logcollector/14days expire 14
localhost> info user/logcollector/14days
{user/logcollector/14days}:
   expire: 14
   lastupdate: 23-Jul-2005 16:16:12 -0500
   partition: 1
   size: 0
localhost> exit

Anything placed in that folder will auto-expire after 14 days due to a nightly cron job. Furthermore, any subfolder of that folder will inherit the same behavior.

Next, I went back into SquirrelMail, clicked on "Shares" (one of the plug-ins I mentioned earlier), and added my co-workers (and myself!) to the access list for the "14days" folder, giving everyone only "Read" access. That way, only the auto-expire script can delete emails; no one else can.

I also created some subfolders within "14days" with names like "logwatch", "cron", etc. For some folders, I later added more read-only users, where appropriate. I also created two extra subfolders called "other" and "not-for-me", to catch unexpected emails for logcollector and otherwise.

Turning It On

Once I had a place to keep the reports, I went to each server in my network and changed where all reports would be sent. The easiest way to do this is to add an entry to /etc/aliases to forward all of the local root email to the central "logcollector" account, but whenever possible (and convenient) I modified the sending program to send to an extended address like "logcollector+logwatch" to make filtering easier.

I left things that way for a day or two because I needed some examples to work with, then I logged back into SquirrelMail as "logcollector", clicked on "Filters" (the other plug-in), and started writing SIEVE rules to sort everything into subfolders of "14days". After a month of occasional tweaking, I had the reports going where I wanted them to, and all of the overflow going into "other" (if it was sent to "root" or "logcollector") or "not-for-me" (if it was BCC'd junkmail).

Using the Results

I then went into my standalone email client (Netscape 7.2) and turned off the "show subscribed folders only" option in my IMAP settings, restarted it, and saw a new expandable subfolder called "user" at the same level as my "INBOX". This folder contained "logcollector", which contained "14days", which contained all of those new subfolders. I could read (or search) any of the report emails, and Cyrus IMAP remembered my read/unread status for each message, separate from any other user's status. I couldn't delete anything (or set message flags) nor could anyone else, but I could copy emails into my own folders if I thought I might want them more than 14 days later.

I also logged into SquirrelMail as myself and found that I needed to click on "Folders" and subscribe to all of those report folders (and their parent folders) to make them accessible. The downside of that is, if I create any new report folders, I'll also need to subscribe to each of them to see them in SquirrelMail. Whenever I need to clean up something in the shared folders (say something is mis-filed or the junkmails are getting too big), or if I need to add new subfolders or filtering rules, I can simply log into SquirrelMail as "logcollector" to gain full write access.

After showing my coworkers how to get at the shared report folders, everyone was very happy to get themselves removed from all of the separate report scripts' "To:" lists!

Other Solutions

Because we already had SquirrelMail set up with the plug-ins I needed, I used them to do most of the setup of mailbox access and filters, but Cyrus IMAP comes with its own tools to make those changes, if needed.

This solution used IMAP as the shared-access method, but there are many other ways to achieve a similar result:

• An access-controlled USENET server with any newsreader as an interface.
• The Web-accessible archiving interface from a suitable mailing list program.
• A custom solution based on a Web-accessible database.

The key characteristics would be that reports would go in, specific users could browse and search them, and the reports would be cleaned out automatically after some predetermined length of time.

Further Possibilities

This solution could easily be combined with Brian Martin's method (from the August 2005 issue of Sys Admin) of creating multiple email reports for a single cron job, by collecting the detailed reports in the shared repository and sending the summaries directly to the appropriate people's accounts.

Having created a central point through which all emailed reports will pass, it would certainly be possible to feed selected emails into a short awk or Perl script to detect error messages and then generate "events" to be passed into an existing monitoring system, such as OpenNMS or Nagios. This would allow the failure of an unmodified cron script (or some unmodifiable proprietary program) to trigger an alert, an automatic response, or anything else, with suitable recognition and suppression of excessive error reports.

Additionally, having a script read your report emails for you, and notify you when they're actually worth reading yourself, could be the biggest benefit of this solution.

Resources

Cyrus IMAP -- http://asg.web.cmu.edu/cyrus/

SquirrelMail -- http://www.squirrelmail.org/

SIEVE Mail Filters Plug-in -- http://email.uoa.gr/projects/squirrelmail/avelsieve.php

Shared Folder Access Control Plug-in -- http://email.uoa.gr/projects/squirrelmail/useracl.php

Mike Donovan is the Network Manager at SUNY Rockland Community College in Suffern, New York. You can contact him at: rccgeek@gmail.com.