Mutt is a popular email client (MUA) which is common on Linux systems.

Given below are some how-tos on basic uses of mutt. For all UNIX utilities, the "man pages" are your best bet to learn them. I’ve just documented some popular uses of mutt. Refer the "man pages" for a more comprehensive understanding of mutt. The commands below have been tested on Red Hat Enterprise Linux 4.0 AS Update 7 with mutt v1.4.1i, unless otherwise stated.

HOW-TO 1: Send email with blank/empty body

mutt -s "Test email" testmail@abc.com < /dev/null
#
# where:
# -s => Subject
# testmail@abc.com => recipient's email address
#

HOW-TO 2: Send email with body read from a file

mutt -s "Test email" testmail@abc.com < email_body.txt
#
# where:
# -s => Subject
# testmail@abc.com => recipient's email address
# email_body.txt => file containing message body
#

HOW-TO 3: Send email with a customized sender name and email address

# The .muttrc file is Mutt's configuration file. It's default location is the $HOME directory.
# If you locate it elsewhere, specify its location with the '-F' flag.
# Add the following to the .muttrc file:
set realname="Joe Bloggs"
set from="noreply@jb.com"
set use_from=yes
#
# where:
# realname => Sender's name as it appears in the recipient's mail inbox.
# from => the "reply-to" address
#

After configuring .muttrc, send emails as per how-tos 1 and 2.

HOW-TO 4: Send attachment(s)

mutt -s "Test email" -a file1 -a file2 testmail@abc.com < /dev/null
#
# where:
# -s => Subject
# testmail@abc.com => recipient's email address
# file1 => first attachment
# file2 => second attachment
#

HOW-TO 5: Send HTML email

I know that the technical purists out there abhor HTML emails due to potential issues with accessibility and security, but hey, there’s no denying the fact that HTML-formatted emails are far more interesting to look at than plain-text email and are better at drawing your attention to specific information (ask the marketing guys and senior executives!). HTML-formatted emails are supported by Mutt versions 1.5 and higher. Here’s how you may send an HTML-formatted email using mutt v1.5.21:

mutt -e "set content_type=text/html" -s "Test email" testmail@abc.com < welcome.html
#
# where:
# -s => Subject
# testmail@abc.com => recipient's email address
# -e => command to execute
# content_type => email body MIME type
#

The MIME type multipart/alternative ensures your emails are received properly by both plain-text and HTML clients, but it does not work well with mutt at present.

Sendmail is a popular Mail Transfer Agent (MTA) and it is the default MTA on Red hat Linux Enterprise (RHEL). Typically, within enterprises, you will need a Mail User Agent (MUA), an MTA and an SMTP Relay to send emails (outbound) from the Linux command-line or shell scripts.

So, let’s assume that your Mail Administrator provides you IP addresses of primary (192.168.1.1) and secondary (192.168.2.2) SMTP Relay hosts. Given below are steps to configure sendmail (on RHEL 4) to use the SMTP relays to send email (you must use root user’s privileges):

STEP 1: Verify sendmail packages

In order to configure sendmail, you will require the sendmail and sendmail-cf packages. Given below is an example of how to check for these packages:

rpm -qa | grep sendmail
 
sendmail-8.13.1-3.3.el4
sendmail-cf-8.13.1-3.3.el4

STEP 2: Modify sendmail.mc

Do not edit /etc/mail/sendmail.cf. Instead, you must edit /etc/mail/sendmail.mc (more readable than sendmail.cf) and use the m4 macro processor to generate sendmail.cf.

Edit /etc/mail/sendmail.mc and add the following line:

define(`SMART_HOST',`[192.168.1.1]:[192.168.2.2]')

Note:

(1) Pay attention to the quotes. Do not prefix the above by the letters dnl as dnl (delete to new line) denotes a comment in sendmail.mc

(2) If you wish to configure only 1 SMTP relay host (e.g. 192.168.1.1), then add the following:

define(`SMART_HOST',`192.168.1.1')

STEP 3: Start/Restart sendmail

When sendmail is started (if not running) or restarted (if running), then the sendmail.mc file will be processed by the m4 macro processor and a corresponding sendmail.cf will be generated. On RHEL, you may start sendmail as follows:

/sbin/service sendmail start

STEP 4: Use an MUA to test outbound mail

In order to test your sendmail configuration and the SMTP relays, use an MUA to send emails. Given below is an example that uses mutt to send emails:

mutt -s "test email" test@abc.com < /dev/null

Unlike the Oracle client which provides you with the required drivers and tools (e.g. sqlplus) to execute SQL statements against an Oracle database on a variety of platforms, Microsoft does not have such drivers and clients for non-Microsoft platforms. For example, there is no Microsoft driver which you can install on RHEL 4 to allow you configure an SQL interface to Microsoft’s SQL Server.

The goal of ODBC is to solve this very problem by providing a standard software interface for accessing a variety of database management systems on a variety of platforms.

Given below are steps to configure an SQL interface with MS SQL Server on a Red Hat Enterprise Linux 4 (RHEL 4) host:

STEP 1: Verify the installation of unixODBC

unixODBC is provided with Linux by default for recent versions of most Linux distributions. Refer the unixODBC home for more details on unixODBC

rpm -qa | grep unixODBC

If the unixODBC packages are not installed, then download them and install them using rpm

STEP 2: Install FreeTDS

Refer the FreeTDS home for more details on FreeTDS. Download the latest stable release and install it using rpm

STEP 3: Configure a DSN

In order for the unixODBC software to interface with MS SQL Server, the relevant database access details must be provided in a Database Source Name (DSN). To configure a DSN, edit /etc/odbc.ini and add the relevant details. Given below is a sample DSN in /etc/odbc.ini :

[MY_DSN]
Driver=/usr/lib64/libtdsodbc.so.0
Server=192.168.1.1
Port=1433
Database=TEST_DB
TDS_Version=7.0

In the sample DSN above, /usr/lib64/libtdsodbc.so.0 is the absolute path to the FreeTDS driver.

STEP 4: Use isql to interface with MS SQL Server

After successfully completing the 3 steps above, you are now ready to perform operations on the database. To do so, you may use the isql utility that is bundled with the unixODBC package. Given below are few examples on using isql :

# The examples below assume you have a DSN called MY_DSN
# configured in /etc/odbc.ini and the isql utility in your PATH.
#
# Example 1 : Open an interactive session
#
isql MY_DSN username password
 
+---------------------------------------+
| Connected!                            |
|                                       |
| sql-statement                         |
| help [tablename]                      |
| quit                                  |
|                                       |
+---------------------------------------+
SQL>
#
# Example 2 : Execute an SQL statement. Assume the statement is in a file
# called test.sql. The last line in test.sql must be a blank line.
#
cat test.sql | isql MY_DSN username password

Refer the isql man page for more details on using the isql utility.

Problem:

My PuTTY connection becomes inactive, thereby requiring me to reconnect to the server and login again.

Background & Analysis:

How to identify an inactive PuTTY connection? When you cannot type anything in your PuTTY window and you see "(inactive)" in your PuTTY window’s title bar, it means that your connection is inactive (has been dropped by the server).

Why does a PuTTY connection become inactive? Connections use resources like cpu and memory on the client and server. When a server determines that your session is idle (you have not used it for a pre-defined interval), it will drop your connection. This is done to protect the server (and network components) against a build-up of several redundant connections that could affect performance.

Solution:

In order to prevent the server from dropping your PuTTY connection and making it inactive, your PuTTY client must send packets to the server even when you’re not using it. Given below are steps to do this:

STEP 1: Modify Connection options

Go to PuTTY Configuration –> Connection and set the "seconds between keepalives" to a non-zero value. This ensures that your PuTTY client sends NULL packets to the server regularly. If you do not know the idle session timeout defined on your server, then choose a small value for the "seconds between keepalives". The value you select must be less than the idle session timeout of your server for PuTTY to keep your connection active. The default value is 0 which tells PuTTY not to bother about keeping the connection alive. Refer the picture below:

STEP 2: Save your PuTTY configuration

Saving your PuTTY session is not the most obvious feature of PuTTY as there’s no SAVE button on every configuration window. So, after completing STEP 1, you must go to the Session window and click the "Save" button. refer the picture below:

Root Cause:

My PuTTy connection became inactive because my PuTTY client was not sending "keepalive" packets to the server to prevent the connection from becoming idle and consequently, the server dropped the connection.

NOTE:

(1) The solution above describes a successful problem-solving experience and may not be applicable to other problems with similar symptoms.

(2) Your rating of this post will be much appreciated. Also, feel free to leave comments.