Friday, February 19, 2010

Installing and configuring caching nameserver (named) on Linux (Fedora 12)

To configure caching-nameserver on local machine in my case on my laptop running Fedora 12, local caching nameserver which will use "cascade" to other functional DNS server in this case my ISP DNS servers.

Advantage: Reduces the delay in domain name resolution drastically as the requests for frequently accessed websites are served from cache. Google for cache nameserver to learn more.

Installing caching-nameserver:

# yum install caching-nameserver

Configuring caching-nameserver:

The main configuration file reside in /etc/named.conf

Not much need to be changed in this file, however if you want to cascade your ISP DNS servers as forwarder, then edit the named.conf and add forwarder directive under the 'options' section.

options {
        listen-on port 53 { 127.0.0.1; };
        listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query     { localhost; };
        recursion yes;
    // Replace the IPs with the DNS of your ISP
    forwarders { 192.168.36.204; 192.168.36.210; };
        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside . trust-anchor dlv.isc.org.;
};

And if you do not want to use 'dnssec' then disable it by...

dnssec-enable no;
dnssec-validation no;


Starting caching-nameserver:

# service named start

Or

# /etc/init.d/named start

To make named start every time you reboot your machine

# chkconfig named on

Or

# setup


Go to "System services" and check named

Using caching-nameserver:

To use your caching-nameserver, add the following line to /etc/resolv.conf

nameserver 127.0.0.1

Now your system will use your own nameserver (in caching mode) for resolving all domain names

$ dig askarali.org
Query time: 8 msec

First time the response time will be little high, next time the DNS query response will be served from local cache and will takes very little time

$ dig askarali.org
$ Query time: 0 msec

Friday, February 12, 2010

Sending SNMP Traps from Nagios

As well as receiving SNMP traps in Nagios, you can send SNMP traps from Nagios to a remote SNMP management station like HP OpenView (NNM) or the like. The easiest way to do this is to create a notification command that generates an SNMP trap. This way, you can use an SNMP management station as a notification destination. This will mean that the trap will be sent every time a notification is scheduled.


Prerequisites:

net-snmp, net-snmp-utils should be installed on Monitoring host running Nagios

Connectivity between management station and nagios has been stablished and nagios can connect and send snmptraps to snmptrap 162/udp port on management station.


1. First of all define notification command, below is the commands for service and hosts in commands.cfg

# 'send-service-trap' command definition
define command{
      command_name send-service-trap
      command_line /usr/local/bin/send-service-trap manager public "$HOSTNAME$" "$SERVICEDESC$" $SERVICESTATEID$ "$SERVICEOUTPUT$"
}

# 'send-host-trap' command definition
define command{
                command_name send-host-trap
                command_line /usr/local/bin/send-host-trap manager public "$HOSTNAME$" $HOSTSTATEID$ "$HOSTOUTPUT$"
}

Both the commands call the shell scripts send-service-trap and send-host-trap in /usr/local/bin/. Passing the hostname or IP address of the destination management station and the target community string, manager and public, respectively.

A number of macros are also passed to the shell script representing the hostname, the service description, the service/host state in numeric form, and the output of the host/service check.

The snmptrap tool generates SNMP traps and can send them to remote management stations. The traps are generated according to a Nagios
MIB available from the same Sourceforge project as the Nagios plug-ins. You can download the MIB from http://prdownloads.sourceforge.net/nagiosplug/nagiosmib-1.0.0.tar.gz?download.

The package contains two MIB files: a root MIB file containing basic definitions for Nagios OIDs called NAGIOS-ROOT-MIB and an MIB containing events and traps called NAGIOS-NOTIFY-MIB. You will need to install both MIB files into your SNMP management device; for example, if your trap daemon is the snmptrapd daemon, you would generally copy these files to the /usr/share/snmp/mibs directory. When you start the snmptrapd daemon, you load the MIB files using the -m
and -M options:

Also copy the MIBs files on localhost where Nagios is running under snmp/mibs

/usr/sbin/snmptrapd -m ALL -M /usr/share/snmp/mibs -Lf /var/log/snmptrapd.log


Tip:  There is an excellent HOWTO on how to use snmptrap to send traps here.

Note: Your own SNMP management station, such as HP OpenView or the like, will have its own method of loading MIB files. You should refer to its documentation for that.

2. Define a contact for Management station

Need to define a contact for management station in the same way we create for other contact person, to receive SNMP traps from Nagios whereever Nagios send notificaiton for host/service

define contact{
        contact_name                             managementstation
        use                                              generic-contact
        alias                                            Management Station
        service_notification_options    w,u,c,r
        host_notification_options         d,u,r
        service_notification_commands   send-service-trap
        host_notification_commands      send-host-trap
        }


3. Add the new conatct to contactgroup for hosts/services for which you want to send SNMP traps

define contactgroup{
        contactgroup_name       linuxadmins
        alias                                Linux Servers Administrators
        members                         me, managementstation
}

Now whenever there is a alert for linux servers Nagios will notify contact "managementstation" which in turn call the commands send-service-trap/send-host-trap accordingly depends on host or service alert.

4. send-service-trap/send-host-trap Shell Script

===/usr/local/bin/send-service-trap ====
# Arguments:
# $1 = Management Station
# $2 = Community String
# $3 = host_name
# $4 = service_description (Description of the service)
# $5 = return_code (An integer that determines the state
#       of the service check, 0=OK, 1=WARNING, 2=CRITICAL,
#       3=UNKNOWN).
# $6 = plugin_output (A text string that should be used
#       as the plugin output for the service check)
#
#
/usr/bin/snmptrap -v 2c -c $2 $1 '' NAGIOS-NOTIFY-MIB::nSvcEvent nSvcHostname s "$3" nSvcDesc s "$4" nSvcStateID i $5 nSvcOutput s "$6"


===/usr/local/bin/send-host-trap=======
# Arguments:
# $1 = Management Station
# $2 = Community String
# $3 = host_name
# $4 = HostStatID A number that corresponds to the current state of the host: 0=UP, 1=DOWN, 2=UNREACHABLE.
# $5 = HOSTOUTPUT The first line of text output from the last host check (i.e. "Ping OK").
#
#
/usr/bin/snmptrap -v 2c -c $2 $1 '' NAGIOS-NOTIFY-MIB::nHostEvent nHostname s "$3" nHostStateID i $4 nHostOutput s "$5"


The shell script receives all the incoming variables and passes them to the snmptrap command

-v = snmp version
-c = community string
$1 = Management Station IP address or hostname

The next two single quotes are special characters representing the uptime portion of a trap. They will be replaced with the current uptime of the system generating the trap when the snmptrap command is executed.

The enterprise OID is specified next; in this case it is NAGIOS-NOTIFY-MIB::nSvcEvent and NAGIOS-NOTIFY-MIB::nHostEvent. The NAGIOS-NOTIFY-MIB is the name of the MIB module being referenced, and the nSvcEvent/nHostEvent is the trap defined for sending service events. Together these form the enterprise OID.

Next specified a list of individual OIDs and their variables that I’m passing as part of the trap. They are, in order, the hostname, the service description, the host/service status ID in numerical form, and the output of the host/service check.

Enclosing the values ones that might contain multiword data in quotation marks so that they are passed cleanly to the command.

Tip:  You can find these and other OIDs that you can use with the traps and notifications defined in the NAGIOS-ROOT-MIB and NAGIOS-NOTIFY-MIB MIB files.