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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
- SuperTuxKart 0.9.2 Released
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