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.
|Contrast Security's Contrast Enterprise||Aug 30, 2016|
|illusive networks' Deceptions Everywhere||Aug 29, 2016|
|Happy Birthday Linux||Aug 25, 2016|
|ContainerCon Vendors Offer Flexible Solutions for Managing All Your New Micro-VMs||Aug 24, 2016|
|Updates from LinuxCon and ContainerCon, Toronto, August 2016||Aug 23, 2016|
|NVMe over Fabrics Support Coming to the Linux 4.8 Kernel||Aug 22, 2016|
- Contrast Security's Contrast Enterprise
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- illusive networks' Deceptions Everywhere
- Happy Birthday Linux
- What I Wish I’d Known When I Was an Embedded Linux Newbie
- ContainerCon Vendors Offer Flexible Solutions for Managing All Your New Micro-VMs
- New Version of GParted
- Tech Tip: Really Simple HTTP Server with Python
- Returning Values from Bash Functions
- All about printf
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide