Hack and / - Mutt Tweaks for System Administrators
I am one of those people who stores everything in e-mail. Travel reservations, phone numbers—if it is in an e-mail message, I know one way or another I can find the information. That might be one of the reasons I have been using mutt as my main mail program both at home and work for years. It is difficult to beat when you need to read, search and navigate large mailboxes full of mail. That, and it has vi-style key bindings. I love vi-style key bindings.
If you are a sysadmin, there are even more reasons to love mutt. For one, you probably spend a good deal of your day in front of a terminal, so why not read your mail from there as well? A lot of administrators like to run stripped-down servers that don't include binaries for X or graphical tools, but mutt is small, and what's more, you can ssh to a server or your work desktop from another machine and check your mail.
At work, I like to segregate my e-mail into folders, based on whether a message is from a person or a server (and, of course, I segregate them further from there). If you manage a lot of servers, those mailboxes can start to get rather large. Almost nothing compares to mutt when you need to open a mailbox with a few thousand new messages. This brings me to my first almost-essential mutt tweak: header caching.
Header caching is a feature that has shown up in mutt only in the past few years. Essentially, it allows mutt to cache the headers from mailboxes, so that the next time you load the mailbox, it has to pull down only the new messages. This is particularly handy with IMAP servers or even large local mailboxes.
To enable header caching, create a directory called .muttheaders in your home directory, then add the following line to your ~/.muttrc, and restart mutt or reload your mutt config:
This tweak is, in some ways, more organizational, and it's handy not only for sysadmins but also for anyone who runs mutt on multiple machines. Many mutt guides will tell you to split .muttrc into multiple files for different types of configuration, so you can have one file that has all of your color options, another with your key bindings and so forth. Then, you simply can add a source line to your .muttrc file that points to the new file, and mutt will load those options as well.
What I like to do is take it a step further and create a .mutt directory in my home directory and place all of those files including my .muttrc in that directory. Then, I create a new file in my home directory called .muttrc.local. In this file, I store any options that are specific to just that particular machine (IMAP settings, local mailbox locations and so on) and keep the rest of the options organized in different files in the .mutt directory. Finally, I create a symlink from ~/.mutt/.muttrc to ~/.muttrc, so mutt still will be able to find it. In this .muttrc, you would find source lines like:
source ~/.muttrc.local source ~/.mutt/colors source ~/.mutt/aliases source ~/.mutt/mailboxes
The advantage to this arrangement is that once I make a change to any of the files in .mutt, I simply can rsync that entire directory to any other machine on which I run mutt, and all of my changes will be there. If I didn't segregate these to a directory and separate .muttrc.local, I would have to worry that any local settings from one machine would clobber the rest.
If you read through a lot of cron, Nagios or other e-mail your servers generate for you, it's easy to let your eyes glaze over and miss important content. What I like to do is tweak my mutt configuration so that certain words, like warning, are colored in bright yellow, and words like error and fail show up in bright red. This is surprisingly easy to do with mutt in only a few lines:
color body brightyellow default warning color body brightred default error color body white default 'no error' color body brightred default "fail(ure|ed)?"
Notice the line that matches no error. I noticed that some messages said “no error” in them, and the error section still was being colored red. If this happens with your keywords, simply add a similar line in there to override the previous less-specific match. You don't have to limit yourself to just these keywords. For instance, you also could highlight certain server names with a particular color or assign different data-center locations distinct colors.
Kyle Rankin is a VP of engineering operations at Final, Inc., the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal. Follow him @kylerankin.
- Bruce Nikkel's Practical Forensic Imaging (No Starch Press)
- Transitioning to Python 3
- Progress on Privacy
- Linux Journal December 2016
- Stepping into Science
- CORSAIR's Carbide Air 740
- Tech Tip: Really Simple HTTP Server with Python
- Radio Free Linux
- Red Hat OpenStack Platform
- FutureVault Inc.'s FutureVault
Pick up any e-commerce web or mobile app today, and you’ll be holding a mashup of interconnected applications and services from a variety of different providers. For instance, when you connect to Amazon’s e-commerce app, cookies, tags and pixels that are monitored by solutions like Exact Target, BazaarVoice, Bing, Shopzilla, Liveramp and Google Tag Manager track every action you take. You’re presented with special offers and coupons based on your viewing and buying patterns. If you find something you want for your birthday, a third party manages your wish list, which you can share through multiple social- media outlets or email to a friend. When you select something to buy, you find yourself presented with similar items as kind suggestions. And when you finally check out, you’re offered the ability to pay with promo codes, gifts cards, PayPal or a variety of credit cards.Get the Guide