Friday, September 19, 2014

How a mail server works

I had originally written this tutorial for xmodulo.com
Email service is one of the most often used services globally. Today almost everyone has at least one email account. Although clicking on the email send button and delivery of an email message appear seamless, a lot of events take place behind the scenes to make sure that the email reaches its final destination.
The functionality of a mail server can be divided broadly into two processes: sending and receiving emails. The following two protocols oversee these processes.
  • Sending email: Simple Mail Transfer Protocol (SMTP)
  • Receiving email: Post Office Protocol (POP) / Internet Message Access Protocol (IMAP)

Terminology

The following terminology is important in understanding the operation of a mail server.
  • Mail User Agent (MUA): The MUA is a component which interacts with end users directly. Examples of MUA are Thunderbird, MS Outlook, Zimbra Desktop. Web mail interfaces like Gmail and Yahoo! are also MUA.
  • Mail Transfer Agent (MTA): The MTA is responsible for transferring an email from a sending mail server all the way to a recipient mail server. Examples of MTA are sendmail and postfix.
  • Mail Delivery Agent (MDA): Within a destination mail server, local MTA accepts an incoming email from remote MTA. The email is then delivered to user's mailbox by MDA.
  • POP/IMAP: POP and IMAP protocols are used to fetch emails from a recipient server's mailbox to recipient MUA.
  • Mail Exchanger Record (MX): The MX record is the DNS entry for mail servers. This record points to the IP address towards which emails should be shot. The lowest MX record always wins, i.e., gets the highest priority. For example, MX 10 is better than MX 20. The IP address of the MX record may vary based on the design and configuration requirements, as will be discussed later in the article.
When a sender clicks on the send button, SMTP (MTA) ensures end to end delivery of an email from a sender-side server to a destination server. Upon reaching the destination server, the MTA local to the destination server accepts the email, and hands it over to the local MDA. The MDA then writes the email to a receiver's mailbox. When the recipient checks for emails, they are fetched by MUA by using protocols like POP or IMAP.

Mail Service Without Use of Service Provider MX

To keep things simple, the first example will exclude the use of any service provider MX. Let us assume thatuserA@exampleA.tst is trying to send an email to userB@exampleB.tst.
The following parameters are configured.
  • Both exampleA.tst and exampleB.tst domains have proper DNS registrations.
  • DNS servers have valid MX records for both domains (the records are shown in the figure).
A series of the following events take place as soon as a user initiates sending an email.
  1. The MUA of a sender initiates a connection to exampleA.tst mail server using SMTP (typically TCP Port 25).
  2. The server mail.exampleA.tst receives an email, and learns that a destination domain is exampleB.tst. The mail server generates a query to a local DNS server asking about the MX record for exampleB.tst. Let us assume that there is no information about the destination domain in the local DNS cache yet.
  3. The local DNS server in turn generates a recursive query towards the authoritative DNS server, and learns about the MX record details of exampleB.tst. This information is shared with the mail server mail.exampleA.tstas an answer.
  4. Now that the mail server has the IP address of the destination mail server, it sends the email directly towards the server mail.exampleB.tst over the Internet. SMTP is used for communication between the source and destination mail servers.
  5. The incoming email is received by the SMTP (MTA) local to mail.exampleB.tst. After the email is received, it is handed over to MDA, which then writes the mail to a recipient's mailbox stored in the server. The server has separate mailboxes for each user.
  6. When the recipient checks the email via POP or IMAP, the email is fetched by MUA from the server. Depending on MUA configuration, emails can be downloaded in the workstation, copies can be kept in both server and workstation, or emails between server and MUA are synced.

Mail Service with Use of Service Provider MX

Most ISPs maintain their own Mail Exchangers (MX) for their customers. These MX servers are also known as Smarthosts or Relay Servers. Smarthosts are usually equipped with advanced virus scanners, powerful spam mail detection and blocking systems. These servers are also built to ensure maximum up-time and best performance for email delivery service.
Using the service provider MX is optional, but it can provide some additional benefits, such as:
  • Mail scanners provide security against both incoming and outgoing malicious mails and mail attachments.
  • ISP MX is the last hop before a customer's end mail server. Even if a customer's mail server goes down, incoming mails will stay in the SMTP queue of ISP MX until queue timer expires. The MX server will keep trying to send emails periodically to the customer. Emails can be delivered whenever the customer' mail server comes back online. This feature can significantly reduce the rate of undelivered emails, i.e. bounces.
Let us assume that exampleA.tst is a customer of ISP A, and exampleB.tst a customer of ISP B. Also assume thatexampleA.tst mail server is configured to send all outgoing mails via mx.ispA.com, while exampleB.tst wants to use the MX server of the ISP B, i.e., mx.ispB.com. As mentioned earlier, the lowest MX record gets the highest priority. Keeping this in mind. The (hypothetical) MX record for exampleB.tst can be defined as below.
 
   IN MX 10 mx.ispB.com
   IN MX 20 mail.exampleB.tst
mx.ispB.com  IN A  Y.Y.Y.Y
mail.exampleB.tst IN A  B.B.B.B
With proper configuration, the following events take place while an email is sent from userA@exampleA.tst touserB@exampleB.tst.
  1. An email is sent from userA@exampleA.tst MUA to mail server mail.exampleA.tst using SMTP. The mail server mail.exampleA.tst is configured to send all outbound mails to mx.ispA.com, instead of sending emails directly towards a destination over the Internet. Virus/spam check is done as soon as ISP A relay host i.e., MX receives the email.
  2. Assuming that the server mx.ispA.com does not have any DNS information about exampleB.tst, a query is sent to a local DNS server asking about the MX record.
  3. The local DNS server gathers required information, and learns both MX 10 and MX 20 records. Since MX 10 is the lowest MX record, it will be used as a primary mail server. MX 20 will be used only when MX 10 goes down i.e., ISP B Smarthost is unreachable for some reason. The DNS server answers the query of the MX server with necessary information.
  4. As the server mx.ispA.tst has all necessary information, it sends the email directly towards mx.ispB.comover the Internet. The email is scanned upon arrival. When the ISP B Smarthost recognizes that the server itself is not the final destination, it forwards the email to the customer's mail server, based on the forwarding decision configured by the server's administrator.
  5. The local SMTP in mail.exampleB.tst receives the incoming mail, and hands it over to local MDA. The MDA in turn delivers the email to a recipient's mailbox.
  6. Finally, the recipient can check the email using POP or IMAP.
To sum up, the entire process of email communication needs many steps performed in the background. Based on the configuration, emails can be sent directly over the Internet from one server to another. Service provider MX can also be used depending on the requirements, and of course, SLAs (Service Level Agreements).
Hope this helps.

How to configure SNMPv3 in Ubuntu, CentOS and Cisco

I had originally written this tutorial for xmodulo.com
Simple Network Management Protocol (SNMP) is a widely used protocol for gathering information about what is going on within a device. For example, CPU and RAM usage, load on a server, traffic status in a network interface, and many other interesting properties of a device can be queried using SNMP.
Currently, three versions of SNMP are available: v1, v2c and v3. SNMP v1 and v2c can be easily configured, which has been discussed in a previous article. SNMPv3 adds some additional features, including authentication and encryption schemes (e.g., MD5, SHA, AES and DES). This makes SNMPv3 more secure and advisable while you run SNMP queries over the Internet.
SNMPv3 configuration is a bit different compared to SNMP v1 or v2c. The following sections explain in detail how the configuration is done.

Configure SNMPv3 on Ubuntu or Debian

The net-snmp-config tool is used for configuration. The following example creates a read-only SNMPv3 user named 'snmpv3user' with password 'snmpv3pass'. Default authentication method MD5 and default encryption DES are used. These values can be customized as well.
root@server:~# apt-get install snmp snmpd
root@server:~# service snmpd stop
root@server:~# net-snmp-config --create-snmpv3-user -ro -A snmpv3pass snmpv3user
## OUTPUT ##
adding the following line to /var/lib/snmp/snmpd.conf:
   createUser snmpv3user MD5 "snmpv3pass" DES
adding the following line to /usr/share/snmp/snmpd.conf:
   rouser snmpv3user
root@server:~# service snmpd start
Testing SNMPv3
snmpwalk is used to test SNMP configuration. Successful snmpwalk should provide tons of output. The following example illustrates the usage of snmpwalk using the recently created v3 user and v3 password. The IP address of the local Ubuntu/Debian server is 192.168.1.1.
root@server:~# snmpwalk -u snmpv3user -A snmpv3pass -a MD5 -l authnoPriv 192.168.1.1 -v3
### SAMPLE OUTPUT ### 
iso.3.6.1.2.1.1.1.0 = STRING: "Linux server 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64"
iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.8072.3.2.10
iso.3.6.1.2.1.1.3.0 = Timeticks: (68028) 0:11:20.28
iso.3.6.1.2.1.1.7.0 = INTEGER: 72
iso.3.6.1.2.1.1.8.0 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.1.9.1.2.1 = OID: iso.3.6.1.6.3.10.3.1.1
iso.3.6.1.2.1.1.9.1.2.2 = OID: iso.3.6.1.6.3.11.3.1.1
iso.3.6.1.2.1.1.9.1.2.3 = OID: iso.3.6.1.6.3.15.2.1.1
iso.3.6.1.2.1.1.9.1.2.4 = OID: iso.3.6.1.6.3.1
iso.3.6.1.2.1.1.9.1.2.5 = OID: iso.3.6.1.2.1.49
iso.3.6.1.2.1.1.9.1.2.6 = OID: iso.3.6.1.2.1.4
iso.3.6.1.2.1.1.9.1.2.7 = OID: iso.3.6.1.2.1.50
iso.3.6.1.2.1.1.9.1.2.8 = OID: iso.3.6.1.6.3.16.2.2.1
iso.3.6.1.2.1.1.9.1.3.1 = STRING: "The SNMP Management Architecture MIB."
iso.3.6.1.2.1.1.9.1.3.2 = STRING: "The MIB for Message Processing and Dispatching."
iso.3.6.1.2.1.1.9.1.3.3 = STRING: "The management information definitions for the SNMP User-based Security Model."
iso.3.6.1.2.1.1.9.1.3.4 = STRING: "The MIB module for SNMPv2 entities"
iso.3.6.1.2.1.1.9.1.3.5 = STRING: "The MIB module for managing TCP implementations"
iso.3.6.1.2.1.1.9.1.3.6 = STRING: "The MIB module for managing IP and ICMP implementations"
iso.3.6.1.2.1.1.9.1.3.7 = STRING: "The MIB module for managing UDP implementations"
iso.3.6.1.2.1.1.9.1.3.8 = STRING: "View-based Access Control Model for SNMP."
iso.3.6.1.2.1.1.9.1.4.1 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.1.9.1.4.2 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.1.9.1.4.3 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.1.9.1.4.4 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.1.9.1.4.5 = Timeticks: (0) 0:00:00.00
### And the walk goes on and on ###
Deleting SNMPv3 User
While the net-snmp-config tool is running, information about v3 users is stored in the files/var/lib/snmp/snmpd.conf and /usr/share/snmp/snmpd.conf. Removing the information should do the trick.
root@server:~# service snmpd stop
root@server:~# vim /var/lib/snmp/snmpd.conf
## there should be a similar encrypted line that contains information on the user ##
## this line is removed ##
usmUser 1 3 0x80001f8880056e06573a1e895100000000 0x736e6d7076337573657200 0x736e6d7076337573657200 NULL .1.3.6.1.6.3.10.1.1.2 0x945ed3c9708ea5493f53f953b45a4513 .1.3.6.1.6.3.10.1.2.2 0x945ed3c9708ea5493f53f953b45a4513 ""
root@server:~# vim /usr/share/snmp/snmpd.conf
## The following line is removed ##
   rouser snmpv3user
Don't forget to restart snmpd afterwards.
root@server:~# service snmpd start

Configure SNMPv3 on CentOS or RHEL

The process of configuring SNMPv3 user in CentOS or RHEL is a bit different compared to Ubuntu, but the basics are the same.
First of all, necessary software is set up using yumAdding Reporfoge repository is always a good idea.
[root@server ~]# yum install net-snmp-utils net-snmp-devel
Now that necessary packages are installed, the read-only SNMP user is created after snmpd is stopped.
[root@server ~]# service snmpd stop
[root@server ~]# net-snmp-create-v3-user -ro -A snmpv3pass -a MD5 -x DES snmpv3user
## OUTPUT ##
adding the following line to /var/lib/net-snmp/snmpd.conf:
   createUser snmpv3user MD5 "snmpv3pass" DES
adding the following line to /etc/snmp/snmpd.conf:
   rouser snmpv3user
[root@server ~]# service snmpd start
Testing SNMPv3
snmpwalk is a powerful tool for testing SNMP configuration and output. Successful snmpwalk should provide tons of output as follows.
[root@server ~]# snmpwalk -u snmpv3user -A snmpv3pass -a MD5 -l authnoPriv 192.168.1.2 -v3
### OUTPUT ###
SNMPv2-MIB::sysDescr.0 = STRING: Linux server.example.tst 2.6.32-71.el6.i686 #1 SMP Fri Nov 12 04:17:17 GMT 2010 i686
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (28963) 0:04:49.63
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (1) 0:00:00.01
SNMPv2-MIB::sysORID.1 = OID: SNMP-MPD-MIB::snmpMPDMIBObjects.3.1.1
SNMPv2-MIB::sysORID.2 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance
SNMPv2-MIB::sysORID.3 = OID: SNMP-FRAMEWORK-MIB::snmpFrameworkMIBCompliance
SNMPv2-MIB::sysORID.4 = OID: SNMPv2-MIB::snmpMIB
SNMPv2-MIB::sysORID.5 = OID: TCP-MIB::tcpMIB
SNMPv2-MIB::sysORID.6 = OID: IP-MIB::ip
SNMPv2-MIB::sysORID.7 = OID: UDP-MIB::udpMIB
SNMPv2-MIB::sysORID.8 = OID: SNMP-VIEW-BASED-ACM-MIB::vacmBasicGroup
SNMPv2-MIB::sysORDescr.1 = STRING: The MIB for Message Processing and Dispatching.
SNMPv2-MIB::sysORDescr.2 = STRING: The MIB for Message Processing and Dispatching.
SNMPv2-MIB::sysORDescr.3 = STRING: The SNMP Management Architecture MIB.
SNMPv2-MIB::sysORDescr.4 = STRING: The MIB module for SNMPv2 entities
SNMPv2-MIB::sysORDescr.5 = STRING: The MIB module for managing TCP implementation
## and the output continues ##

Deleting SNMPv3 User

The information about the SNMPv3 user are added in two files. Those entries are removed for deleting the SNMP user.
root@server:~# service snmpd stop
root@server:~# vim /var/lib/net-snmp/snmpd.conf
## there should be a similar encrypted line that contains information on the user ##
## this line is removed ##
usmUser 1 3 0x80001f8880056e06573a1e895100000000 0x736e6d7076337573657200 0x736e6d7076337573657200 NULL .1.3.6.1.6.3.10.1.1.2 0x945ed3c9708ea5493f53f953b45a4513 .1.3.6.1.6.3.10.1.2.2 0x945ed3c9708ea5493f53f953b45a4513 ""
root@server:~# vim /etc/snmp/snmpd.conf
## The following line is removed ##
   rouser snmpv3user
root@server:~# service snmpd start
Firewall Tuning (Optional)
The following example firewall rule can be used to limit the source IP addresses that are allowed to conduct SNMP queries. Two IP addresses (e.g., 192.168.1.100/101) are whitelisted.
root@server:~# iptables -A INPUT -s 192.168.1.100/32 -p udp –dport 161 -j ACCEPT
root@server:~# iptables -A INPUT -s 192.168.1.101/32 -p udp –dport 161 -j ACCEPT
root@server:~# iptables -A INPUT -p udp –dport 161 -j DROP

Configure SNMPv3 on Cisco Switches and Routers

Cisco switches and routers support SNMPv3 as well. This demonstration will create an Access Control List (ACL) first to limit the source IP addresses that are permitted to do SNMP queries. This step, however, can be skipped.
Setting up ACL (Optional)
## global config mode ##
ip access-list standard SNMP_ACL
permit 192.168.1.100
permit 192.168.1.100
SNMPv3 Configuration
The following configuration creates a v3 group named v3Group with authNoPriv security level. The optional access list defined earlier can also be specified.
## global config mode ##
## With ACL ##
snmp-server group v3Group v3 auth access SNMP_ACL

## Without ACL ##
snmp-server group v3Group v3 auth
A user v3user is created and added under v3Group. The MD5 password and AES encryption key are also defined.
snmp-server user v3user v3Group v3 auth md5 snmpv3pass priv aes 128 snmpv3pass
Testing SNMPv3
The SNMP user and associated group can be viewed in the Cisco device.
### privileged EXEC mode ##
show snmp user
User name: v3user
Engine ID: ************************
storage-type: nonvolatile        active
Authentication Protocol: MD5
Privacy Protocol: AES128
Group-name:  v3Group
snmpwalk from any Linux box can also be used to verify the configuration and examine the output.
snmpwalk -u snmpv3user -A snmpv3pass -a MD5 -l authnoPriv 192.168.1.3 -v3
iso.3.6.1.2.1.1.1.0 = STRING: "Cisco IOS Software” 
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.9.1.1166
iso.3.6.1.2.1.1.7.0 = INTEGER: 78
iso.3.6.1.2.1.1.8.0 = Timeticks: (0) 0:00:00.00
iso.3.6.1.2.1.2.1.0 = INTEGER: 54
iso.3.6.1.2.1.2.2.1.1.1 = INTEGER: 1
iso.3.6.1.2.1.2.2.1.1.2 = INTEGER: 2
iso.3.6.1.2.1.2.2.1.1.3 = INTEGER: 3
## output truncated ##
Hope this helps.

How to monitor common services with Nagios

I had originally written this tutorial for xmodulo.com.
Nagios comes with a wide range of built-in scripts for monitoring services. This tutorial will cover the process of using some of these scripts for checking common services, such as MySQL, Apache web server, DNS, etc.
To keep the article focused on service monitoring, we will not be configuring hostgroups or templates, as they have been covered in a previous tutorial. Nonetheless, they can be tuned to match the requirements.

Running Nagios Check in CLI

It is generally recommended to run the Nagios service check scripts in CLI before adding them to Nagios. This will give an idea on whether the execution will be successful and what the output of the script will look like.
All of the scripts are located at /etc/nagios-plugins/config/ with the executable files stored at/usr/lib/nagios/plugins/
Here is how it is done.
root@nagios:~# cd /etc/nagios-plugins/config/
The provided scripts contain help on the syntax. The example contains partial output.
root@nagios:~# cat /etc/nagios-plugins/config/tcp_udp.cfg
# 'check_tcp' command definition
define command{
        command_name    check_tcp
        command_line    /usr/lib/nagios/plugins/check_tcp -H '$HOSTADDRESS$' -p '$ARG1$'
Now that the syntax is available, TCP port 80 can be checked as follows.
root@nagios:~# /usr/lib/nagios/plugins/check_tcp -H 10.10.10.1 -p 80
TCP OK - 0.000 second response time on port 80|time=0.000222s;;;0.000000;10.000000

Example Topology

In this tutorial, the following three servers are being used. Each server runs one or more common services. The Nagios server is running on Ubuntu.
  • Server 1 (10.10.10.1) : MySQL, Apache2
  • Server 2 (10.10.10.2) : Postfix, Apache2
  • Server 3 (10.10.10.3): DNS
First, the servers are defined in Nagios.
root@nagios:~# vim /etc/nagios3/conf.d/example.cfg
define host{
        use                     generic-host            
        host_name               test-server-1
        alias                   test-server-1
        address                 10.10.10.1
        }

define host{
        use                     generic-host            
        host_name               test-server-2
        alias                   test-server-2
        address                 10.10.10.2
        }

define host{
        use                     generic-host            
        host_name               test-server-3
        alias                   test-server-3
        address                 10.10.10.3
        }

Monitor MySQL Service

MySQL Monitoring Requirements

  1. Monitor whether MySQL is running by checking port 3306.
  2. Monitor the availability of certain database 'testDB'.

MySQL Server Setting

When it comes to checking MySQL, it should be kept in mind that MySQL, by default, listens on only the loopback interface 127.0.0.1. This increases the security of the database. Manual tuning is needed to tell MySQL to listen on other interfaces as well. Here is how it can be done.
This setting is done on all MySQL servers.
root@nagios:~# vim /etc/mysql/my.cnf
The following line is commented out to make MySQL listens on all interfaces.
#bind-address           = 127.0.0.1
Also, MySQL would not let just any host to connect to it. A user 'nagios' is created for both localhost and for 'any' host. This user is then granted all permission to all databases and will be used for monitoring.
The following settings are done for all MySQL servers.
root@nagios:~# mysql -u root –p
## MySQL root password here ##
A user 'nagios@localhost' is created in MySQL server.
mysql> CREATE USER 'nagios'@'localhost' IDENTIFIED BY 'nagios-pass';
mysql> GRANT ALL PRIVILEGES ON *.* TO 'nagios'@'localhost';
A user 'nagios@any-host' is created.
mysql> CREATE USER 'nagios'@'%' IDENTIFIED BY 'nagios-pass';
mysql> GRANT ALL PRIVILEGES ON *.* TO 'nagios'@'%';

mysql> FLUSH PRIVILEGES;
This should enable MySQL to listen on all interfaces, as well as accept incoming connections from user 'nagios' at any host.
Note that there are possible security implications of this change, so it's worth mentioning a few words:
  • This setting will expose MySQL to all available interfaces, including WAN. It is vital to make sure only legitimate networks have access to the database. Filters such as firewall and TCP wrappers should be used.
  • The MySQL 'nagios' user password should be very strong. If there are few Nagios servers, then MySQL user 'nagios@servername' should be created instead of 'nagios@%' i.e., any host.

Nagios Configuration for MySQL

The following tuning should do the trick.
root@nagios:~# vim /etc/nagios3/conf.d/services_nagios2.cfg
define service{
use   generic-service
host_name  test-server-1
;hostgroup can be used instead as well

service_description  Check MYSQL via TCP port
check_command   check_tcp!3306
        }

define service{
use    generic-service
host_name   test-server-1
;hostgroup can be used instead as well

service_description Check availability of database 'testDB'
check_command check_mysql_database!nagios!nagios-pass!testDB
;check_mysql!userName!userPassword!databaseName
        }
This way, Nagios can help monitor the accessibility of both MySQL servers and the database stored within the servers.

Monitor Apache Web Server

Nagios can be used to monitor Apache web server as well.

Apache Monitoring Requirements

  • Monitor whether the apache server is available.
This task is really easy as Nagios has a built-in command for this.
root@nagios:~# vim /etc/nagios3/conf.d/services_nagios2.cfg
define service{
use   generic-service
host_name  test-server-1, test-server-2
service_description Check Apache Web Server
check_command  check_http
        }
Now that was really simple.

Monitor DNS Service

Nagios can monitor DNS service by asking the DNS server to either resolve a specific fully qualified domain name (FQDN), or by asking the server to use the dig tool. The default FQDN used for testing is www.google.com, but it can be changed as needed. The following file can be modified to do the job.
root@nagios:~# vim /etc/nagios-plugins/config/dns.cfg
## The -H portion can be modified to replace Google ##
define command{
command_name    check_dns
command_line    /usr/lib/nagios/plugins/check_dns -H www.google.com -s '$HOSTADDRESS$'
}
Then edit the following file.
root@nagios:~# vim /etc/nagios3/conf.d/services_nagios2.cfg
## Nagios asks server-3 to resolve the IP for google.com ##
define service{
use                             generic-service
host_name                       test-server-3
service_description     Check DNS
check_command           check_dns
        }

## Nagios asks server-3 to dig google.com ##
define service{
use                             generic-service
host_name                       test-server-3
service_description     Check DNS via dig
check_command           check_dig!www.google.com
        }

Monitor Mail Server

Nagios can monitor different mail server components like SMTP, POP, IMAP and mailq. As mentioned earlier, server-2 has postfix mail server set up on it. Nagios will be configured to monitor SMTP and mail queue of the server.
root@nagios:~# vim /etc/nagios3/conf.d/services_nagios2.cfg
define service{
use                     generic-service
host_name               test-server-2
service_description     Check SMTP
check_command           check_smtp
        }

define service{
use                     generic-service
host_name               test-server-2
service_description     Check Mail Queue
check_command           check_mailq_postfix!50!100
     ;warning at 50, critical at 100
        }
The following screenshot shows a complete overview of all the service checks that have been configured so far.

Port Based Monitoring for Custom Applications

Let us assume that the following custom application is also running in the network, listening on a particular port.
  • Test Server 1: custom application (TCP Port 12345)
With a little tweaking, Nagios can help monitor this application port as well.
root@nagios:~# vim /etc/nagios3/conf.d/services_nagios2.cfg
define service{
use                     generic-service
host_name               test-server-1
service_description     Check server 1 custom application
check_command           check_tcp!12345
        }
On a finishing note, Nagios can monitor many other sectors of a network. The scripts stored in /etc/nagios-plugins/config/ can shed some light on the awesome capabilities of Nagios.
Some of the scripts provided with Nagios are restricted to the local server only. Examples include server load, number of concurrent processes, number of logged in users. These checks can provide useful insight on what is going on within the Nagios server.
Hope this helps.

How to configure Nagios for audio alerts and mobile notifications

I had originally written this tutorial for xmodulo.com
In a Network Operation Centre (NOC) environment, setting up alerts is extremely important. As one of the most popular NOC monitoring systems, Nagios features powerful alerting services. Alerts generated by Nagios can be sent out in various means, so that they can be acted upon immediately. Email notification is the most commonly used option.
This tutorial presents two other ways to send out Nagios alerts: (1) audio alerts via web browser, and (2) audio/vibration alerts via an Android app.

Nagios Checker - A Firefox Add-on

A small Mozilla Firefox add-on named Nagios Checker written by Petr ┼áimek can be used to gather information from Nagios, and generate audio alarms whenever a problem is detected. It is very easy to set up.
Requirements
  • Nagios Checker will gather information from a Nagios server every minute.
  • Nagios Checker will generate audio alarms only when there is a change in network
    health, i.e., alarms will not be produced for the same host over and over again.
Installation and Configuration
Nagios Checker can easily be obtained in the Firefox add-on menu. A simple search should do the trick.
The Add-on Bar must be enabled.
The add-on is configured to gather information from a Nagios server.
Nagios server IP/hostname, nagiosadmin user and password are set.
The path to the status.cgi script is located. The path to CGI directory would be:
  • Debian/Ubuntu: http://IP/nagios3/cgi-bin/
  • CentOS/RHEL: http://IP/nagios/cgi-bin/
The URL for status.cgi is manually defined as the process of locating it automatically is not always successful.
After exiting the dialog box with OK, the check interval is set.
By default, Nagios Checker will produce audio alarms over and over again with each check (every minute in this case) if at least one problem exists. This could be very annoying. Nagios Checker is tuned so that it generates alarms only if a new problem appears.
And now we are ready to use Nagios Checker with Firefox. It is a very useful tool in any NOC environment that has to monitor a lot of hosts.

aNag - An Android App for Nagios

aNag is an Android app that can be configured to gather information from a Nagios server, and provide alerts (audio and/or vibration) in Android phones. It is a lightweight, free, easy to configure software with no advertisements. It can be easily installed from the Google Play store.
After aNag has been downloaded and installed, configuring it is very easy. Pressing the menu button in the phone should give a panel containing 'settings'.
A new instance is created.
The parameters for the new instance are entered. The path to CGI directory would be:
  • Debian/Ubuntu: http://IP/nagios3/cgi-bin/
  • CentOS/RHEL: http://IP/nagios/cgi-bin/
aNag is highly customizable. The notification period, update interval and other parameters can be changed from the settings menu. One of the important things that can be configured would be specifying whether aNag should query a Nagios server if any data connection is available, or it should check only over Wi-Fi. This setting can be found under 'settings -> low level settings'.
At this point, we are ready to use aNag. It should generate alerts as needed. The app interface should contain all the necessary details.
Another useful feature of aNag is the ability to shut down the app and associated services while not in use. This frees up phone resources that can be used for other purposes. This feature can be found by tapping the menu button.
Hope this helps.