Category: FLOSS

About Free/Libre/Open Source Software

Monitoring Lotus Notes/Domino Servers

Very recently I was asked to setup Nagios to monitor the Lotus Notes/Domino Servers. There were some around 500 plus servers across the globe. It was an all Windows shop and the current monitoring was being done using GSX, HP Systems Insight Manager and IBM Director. The client wanted a comprehensive solution so that they have a single monitoring interface to look at and after an initial discussion they decided to go ahead with Nagios.

This document looks at monitoring Lotus Notes/Domino servers using SNMP through Nagios. I have provided some of the required OIDs and their initial warning and critical threshold values in tabular format. There are many more interesting OIDs listed in the domino.mib file. Also I have attached the Nagios commands definition file and service definition files at the end of the document. In order to use certain checks, some plugins are required which can be downloaded from http://www.barbich.net/websvn/wsvn/nagios/nagios/plugins/check_lotus_state.pl.

Note – I recently found that the required plugins are not available on the original site anymore, so I have made my copy available with this document. You can download the scripts from the link at the bottom of the document.

To start with I asked the windows administrators to install the Lotus/Domino SNMP Agent on all servers and after that I got hold of a copy of domino.mib file which is located in C:\system32.

Next I listed all the interesting parameters from the domino.mob file and started querying a set of test servers to find out if a value is being returned or not. Following is the OID list and what each OID means. Most of these checks are only valid in the Active node. This is important to know if the Domino servers are in a HA cluster (active-standby pair). If there is only one Domino Server then these checks will apply.

Moinitoring Checks on Active Node

Monitoring Checks on Active Node
Nagios Service Check	OID	Description	Threshholds (w- warning, c-critical)
dead-mail	enterprises.334.72.1.1.4.1.0	Number of dead (undeliverable) mail messages	w 80, c 100
routing-failures	enterprises.334.72.1.1.4.3.0	Total number of routing failures since the server started	w 100, c 150
pending-routing	enterprises.334.72.1.1.4.6.0	Number of mail messages waiting to be routed	w10, c 20
pending-local	enterprises.334.72.1.1.4.7.0	Number of pending mail messages awaiting local delivery	w 10, c 20
average-hops	enterprises.334.72.1.1.4.10.0	Average number of server hops for mail delivery	w 10, c 15
max-mail-delivery-time	enterprises.334.72.1.1.4.12.0	Maximum time for mail delivery in seconds	w 300, c@600
router-unable-to-transfer	enterprises.334.72.1.1.4.19.0	Number of mail messages the router was unable to transfer	w 80, c100
mail-held-in-queue	enterprises.334.72.1.1.4.21.0	Number of mail messages in message queue on hold	w 80, c 100
mails-pending	enterprises.334.72.1.1.4.31.0	Number of mail messages pending	w@80, c@100
mailbox-dns-pending	enterprises.334.72.1.1.4.34.0	Number of mail messages in MAIL.BOX waiting for DNS	w 10, c 20
databases-in-cache	enterprises.334.72.1.1.10.15.0	The number of databases currently in the cache. Administrators should monitor this number to see whether it approaches the NSF_DBCACHE_MAXENTRIES setting. If it does, this indicates the cache is under pressure. If this situation occurs frequently, the administrator should increase the setting for NSF_DBCACHE_MAXENTRIES	w 80, c 100
database-cache-hits	enterprises.334.72.1.1.10.17.0	The number of times an lnDBCacheInitialDbOpen is satisfied by finding a database in the cache. A high ‘hits-to-opens’ ratio indicates the database cache is working effectively, since most users are opening databases in the cache without having to wait for the usual time required by an initial (non-cache) open. If the ratio is low (in other words, more users are having to wait for databases not in the cache to open), the administrator can increase the NSF_DBCACHE_MAXENTRIES	w, c
database-cache-overcrowding	enterprises.334.72.1.1.10.21.0	The number of times a database is not placed into the cache when it is closed because lnDBCacheCurrentEntries equals or exceeds lnDBCacheMaxEntries*1.5. This number should stay low. If it begins to rise, you should increase the NSF_DbCache_Maxentries settings	w 10, c 20
replicator-status	enterprises.334.72.1.1.6.1.3.0	Status of the Replicator task
router-status	enterprises.334.72.1.1.6.1.4.0	Status of the Router task
replication-failed	enterprises.334.72.1.1.5.4.0	Number of replications that generated an error
server-availability-index	enterprises.334.72.1.1.6.3.19.0	Current percentage index of server’s availability. Value range is 0-100. Zero (0) indicates no available resources; a value of 100 indicates server completely available

Interesting OIDs to plot for trend analysis

Interesting OIDs to plot for Trend Analysis
enterprises.334.72.1.1.4.2.0	Number of messges received by router
enterprises.334.72.1.1.4.4.0	Total number of mail messages routed since the server started
enterprises.334.72.1.1.4.5.0	Number of messages router attempted to transfer
enterprises.334.72.1.1.4.8.0	Notes server’s mail domain
enterprises.334.72.1.1.4.11.0	Average size of mail messages delivered in bytes
enterprises.334.72.1.1.4.13.0	Maximum number of server hops for mail delivery
enterprises.334.72.1.1.4.14.0	Maximum size of mail delivered in bytes
enterprises.334.72.1.1.4.15.0	Minimum time for mail delivery in seconds
enterprises.334.72.1.1.4.16.0	Minimum number of server hops for mail delivery
enterprises.334.72.1.1.4.17.0	Minimum size of mail delivered in bytes
enterprises.334.72.1.1.4.18.0	Total mail transferred in kilobytes
enterprises.334.72.1.1.4.20.0	Count of actual mail items delivered (may be different from delivered which counts individual messages)
enterprises.334.72.1.1.4.26.0	Peak transfer rate
enterprises.334.72.1.1.4.27.0	Peak number of messages transferred
enterprises.334.72.1.1.4.32.0	Number of mail messages moved from MAIL.BOX via SMTP
cache cmd hit rate	enterprises.334.72.1.1.15.1.24.0
cache db hit rate	enterprises.334.72.1.1.15.1.26.0
hourly access denials	enterprises.334.72.1.1.11.6.0
req per 5 min	enterprises.334.72.1.1.15.1.13.0
unsuccesfull run	enterprises.334.72.1.1.11.9.0

Files and Scripts

April 1, 2007

Apache LDAP Authentication
mod_auth_ldap modules allows an LDAP directory to be used to store the database for HTTP Basic authentication. This document describes an example implementation in Red Hat Enterprise Linux 4. This document also applies to any Linux distribution in general, provided the mod_auth_ldap module is loaded.

I have used Microsoft Active Directory as my LDAP server as that’s what I had at the time of writing this. But any LDAP Server will do for this.

Setting up webserver

On Red Hat Enterprise Linux 4, when the httpd package is installed, mod_auth_ldap gets installed with it. By default Red Hat Enterprise 4 httpd.conf file does not allow the overriding of any setting by the .htaccess file. Following are the default settings:
```
<Directory />
    Options FollowSymLinks
    AllowOverride None
</Directory>

<Directory "/var/www/html">
    Options Indexes FollowSymLinks
    AllowOverride None
    .......
    .......
</Directory>
```
I changed the settings for /var/www/html to:
```
<Directory "/var/www/html">
    Options Indexes FollowSymLinks
    AllowOverride AuthConfig
    .......
    .......
</Directory>
```
This enabled me to put the required authentication directives in the .htaccess files. You need to have administrative access to the web server or get this done from your administrator.

Next we need to find whether the mod_auth_ldap module is being loaded or not This can be done as follows on RHEL4
```
$ grep mod_auth_ldap /etc/httpd/conf/httpd.conf
LoadModule auth_ldap_module modules/mod_auth_ldap.so
```
Test Setup

I have created a directory test_auth in the DocumentRoot which I want to have restrictive access using ldap authentication. Following commands will create the required directory and an index.html file in it.
```
$ sudo mkdir /var/www/html/test_auth
$ sudo cat >>/var/www/html/test_auth/index.html <<__EOF__
<html>
<head><title>Test page</title></head>
<body><h1>Test page</h1><p>Hello World!</p></body>
</html>
__EOF__
```
Now we can create an .htaccess file containing the required authentication directives:
```
$ sudo vi /var/www/html/test_auth/.htaccess
AuthType Basic
AuthName "Restricted Access"
AuthLDAPEnabled on
AuthLDAPURL 'ldap://msadc01.unixclinic.net:389/ou=Users and Machines,ou=IN,dc=unixclinic,dc=net?sAMAccountName?sub?(memberOf=cn=Infrastructure Team,ou=Groups,ou=Users and Machines,ou=IN,dc=unixclinic,dc=net)'
AuthLDAPBindDN "apache_ldap_query@unixclinic.net"
AuthLDAPBindPassword pA554Auth
require valid-user
```
The AuthLDAPURL specifies the LDAP server, the base DN, the attribute to use in the search, as well as the extra search filter to use and is a single line without any line breaks. The URL specifies that the access is restricted to the members of the “Infrastructure Team”. AuthLDAPBindDN is an optional DN (Distinguished Name) to use in binding to the LDAP server. If this is not specified then mod_auth_ldap will use anonymous bind. Most professionally setup LDAP Servers (and Active Directory Servers) does not allow anonymous binds against the directory.

Resources
Like this:
Like Loading…
January 24, 2007

Using SNAT for Highly Available Services

Problem

Often network based services are restricted to a particular source IP address. A common example is SNMP. A good system/network administrator will restrict access to the SNMP daemon from a particular host, usually a central management server. Sometimes these central management servers are HA pair. Under these circumstances, a service address can be used for the active node. This service address has access to the desired networking resource. Heartbeat usually will start this service IP address as a resource on the active node. This will result in the Active node taking over the IP address, which enables the node to listen on that IP address for incoming requests. But this still does not solve the problem of active node attempting to access a network resource, because all packets originating from this node will bear the primary IP address of this node and not the secondary address(es) or aliased address(es).

Solution

For such cases, SNAT (Source Network Address Translation) can be useful. Using SNAT we can ask the kernel to change the source IP addresses on all outgoing packets. But the IP address which we want on our packets must be present either as a primary or secondary or aliased IP address. This can be checked as:

# ip addr show bond0
6: bond0:  mtu 1500 qdisc noqueue
    link/ether 00:18:fe:89:df:d8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.3/16 brd 172.16.255.255 scope global bond0
    inet 192.168.1.2/16 brd 172.16.255.255 scope global secondary bond0:0
    inet 192.168.1.1/16 brd 172.16.255.255 scope global secondary bond0:1
    inet6 fe80::218:feff:fe89:dfd8/64 scope link
       valid_lft forever preferred_lft forever

# ifconfig bond0
bond0     Link encap:Ethernet  HWaddr 00:18:FE:89:DF:D8
          inet addr:192.168.1.3  Bcast:172.16.255.255  Mask:255.255.0.0
          inet6 addr: fe80::218:feff:fe89:dfd8/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:53589964 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25857501 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:40502210697 (37.7 GiB)  TX bytes:4148482317 (3.8 GiB)

Instead of specifying a interface, all interfaces can also be viewed using:

# ip addr show
1: lo:  mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
    link/ether 00:18:fe:89:df:d8 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::218:feff:fe89:dfd8/64 scope link
       valid_lft forever preferred_lft forever
3: eth1:  mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
    link/ether 00:18:fe:89:df:d8 brd ff:ff:ff:ff:ff:ff
4: sit0:  mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0
6: bond0:  mtu 1500 qdisc noqueue
    link/ether 00:18:fe:89:df:d8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.3/16 brd 172.16.255.255 scope global bond0
    inet 192.168.1.2/16 brd 172.16.255.255 scope global secondary bond0:0
    inet 192.168.1.1/16 brd 172.16.255.255 scope global secondary bond0:1
    inet6 fe80::218:feff:fe89:dfd8/64 scope link
       valid_lft forever preferred_lft forever

# ifconfig
bond0     Link encap:Ethernet  HWaddr 00:18:FE:89:DF:D8
          inet addr:192.168.1.3  Bcast:172.16.255.255  Mask:255.255.0.0
          inet6 addr: fe80::218:feff:fe89:dfd8/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:53587551 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25855600 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:40501872867 (37.7 GiB)  TX bytes:4148267377 (3.8 GiB)

bond0:0   Link encap:Ethernet  HWaddr 00:18:FE:89:DF:D8
          inet addr:192.168.1.2  Bcast:172.16.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1

bond0:1   Link encap:Ethernet  HWaddr 00:18:FE:89:DF:D8
          inet addr:192.168.1.1  Bcast:172.16.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1

eth0      Link encap:Ethernet  HWaddr 00:18:FE:89:DF:D8
          inet6 addr: fe80::218:feff:fe89:dfd8/64 Scope:Link
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:53587551 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25855600 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:40501872867 (37.7 GiB)  TX bytes:4148267377 (3.8 GiB)
          Interrupt:185

eth1      Link encap:Ethernet  HWaddr 00:18:FE:89:DF:D8
          UP BROADCAST SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:193

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:536101 errors:0 dropped:0 overruns:0 frame:0
          TX packets:536101 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:59243777 (56.4 MiB)  TX bytes:59243777 (56.4 MiB)

My NICs are bonded and hence bond0 is the interface I use.

Setting Up SNAT

In Linux IPTables can be used to setup SNAT.
To change the source IP address of all packets going out of the box to anywhere, following rule can be used:

$ sudo /sbin/iptables -t nat -A POSTROUTING -o bond0 -j SNAT --to-source 192.168.1.1

The result can be seen as follows:

$ sudo /sbin/iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
SNAT       all  --  anywhere             anywhere            to:192.168.1.1

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

I normally restrict SNAT to selected services and destination IP addresses only. The following three IPTables command respectively translates the source address for all packets destined for 10.199.65.191 to 192.168.1.1, only ICMP packets destined for 192.168.2.4 and all packets destined for network 192.168.1.0/24:

$ sudo /sbin/iptables -t nat -A POSTROUTING -d 10.199.65.191 -o bond0 -j SNAT --to-source 192.168.1.1
$ sudo /sbin/iptables -t nat -A POSTROUTING -d 192.168.2.4 -p ICMP -o bond0 -j SNAT --to-source 192.168.1.1
$ sudo /sbin/iptables -t nat -A POSTROUTING -d 192.168.1.0/24 -o bond0 -j SNAT --to-source 192.168.1.1

The result of all these commands can be seen as:

$ sudo /sbin/iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
SNAT       all  --  anywhere             anywhere            to:192.168.1.1
SNAT       all  --  anywhere             10.199.65.191       to:192.168.1.1
SNAT       icmp --  anywhere             192.168.2.4         to:192.168.1.1
SNAT       all  --  anywhere             192.168.1..0/24     to:192.168.1.1

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Setting Heartbeat and IPTables for SNAT

The /etc/ha.d/haresources file in heartbeat can be set to accept the desired IP address as a resource and associate it with a script which can start/stop/restart these IPTables rules.

$ sudo vi /etc/ha.d/haresources
node01 192.168.1.1 iptables

Red Hat and Fedora has such a script and which is located in /etc/init.d/iptables. This script reads a file /etc/sysconfig/iptables, which contains various rules in iptables-save format. I had created a similar script for Debian and derivatives distributions which reads the rules from /etc/iptables file. The script is given below:

#! /bin/sh
# Script      - iptables
# Description - Read IPTables rule from a file in iptables-save format.
# Author      - Ajitabh Pandey 
#
PATH=/usr/sbin:/usr/bin:/sbin:/bin
DESC="IPTables Configuration Script"
NAME=iptables
DAEMON=/sbin/$NAME
SCRIPTNAME=/etc/init.d/$NAME

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

# Load the VERBOSE setting and other rcS variables
[ -f /etc/default/rcS ] && . /etc/default/rcS

if [ ! -e /etc/iptables ]
then
        echo "no valid iptables config file found!"
        exit 1
fi

case "$1" in
  start)
        echo "Starting $DESC:" "$NAME"
        /sbin/iptables-restore /etc/iptables
        ;;
  stop)
        echo "Stopping $DESC:" "$NAME"
        $DAEMON -F -t nat
        $DAEMON -F
        ;;
  restart|force-reload)
        echo "Restarting $DESC:" "$NAME"
        $DAEMON -F -t nat
        $DAEMON -F
        /sbin/iptables-restore /etc/iptables
        ;;
  *)
        echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
        exit 3
        ;;
esac

Following is a sample iptables rules file, in iptables-save format.

*nat
:PREROUTING ACCEPT [53:8294]
:POSTROUTING ACCEPT [55:11107]
:OUTPUT ACCEPT [55:11107]

# Allow all ICMP packets to be SNATed
-A POSTROUTING  -p ICMP -o bond0 -j SNAT --to-source 192.168.0.1

# Allow packets destined for SNMP port (161) on local network to be SNATed
-A POSTROUTING -d 192.168.0.0/24 -p tcp -m tcp --dport snmp -o bond0 -j SNAT --to-source 192.168.0.1
-A POSTROUTING -d 192.168.0.0/24 -p udp -m udp --dport snmp -o bond0 -j SNAT --to-source 192.168.0.1

# These are for the time servers on internet
-A POSTROUTING -p tcp -m tcp --dport ntp -o bond0 -j SNAT --to-source 192.168.0.1
COMMIT

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [144:12748]
COMMIT

January 23, 2007

Migrating Users in Linux
When a server is to be replaced, often it is a requirement to migrate all user accounts as it is to the new server, which means that the password on these accounts also should not change.

Before the account migration a brief freeze should be imposed on the server. This means no new accounts are to be created till the migration is completed and tested.

To do the migration I used the “pwunconv” utility and merged the passwd file and shadow file on the source server, then copied it across to the new server.

On the new server also I ran the “pwunconv” utility to merge the passwd and shadow files and then appended the file copied from the old server to it.
On old server
```
sysadmin@old-server:$ sudo /usr/sbin/pwunconv
sysadmin@old-server:$ cp /etc/passwd newpasswd
sysadmin@old-server:$ scp newpasswd new-server:.
```
On new server
- Removing the system accounts of the old-server as the new-server already has its own system accounts.
```
ajitabhp@new-server:$ vi newpasswd
......
[remove the system accounts]
```
- Merge the passwd and shadow files and then append the newpasswd to the /etc/passwd file
```
ajitabhp@new-server:$ sudo /usr/sbin/pwunconv
ajitabhp@new-server:$ sudo cat newpasswd >>/etc/passwd
```
- Change the shell of all users who have /sbin/nologin to /bin/false. This step was required as Debian does not have /sbin/nologin shell, instead it has /bin/false.
```
ajitabhp@new-server:$ sudo sed -i 's/\/sbin\/nologin/\/bin\/false/' /etc/passwd
```
- Finally split the /etc/passwd file to /etc/passwd and /etc/shadow files and do a syntax check and then sort the entries on the basis of UIDs
```
ajitabhp@new-server:$ sudo /usr/sbin/pwconv
ajitabhp@new-server:$ sudo /usr/sbin/pwck
ajitabhp@new-server:$ sudo /usr/sbin/pwck -s
```
The syntax check told me that the home directories for all the accounts which I migrated from old-server does not exist. So, I ran this one liner to automatically generate the home directories from the /etc/passwd file, if they dont already exists:
```
ajitabhp@new-server:~$ grep "/home" /etc/passwd|cut -d: -f1,6|sed -e 's/:/ /'|while read user directory;do if [ ! -d $directory ]; then sudo mkdir $directory;sudo chown $user:users $directory;sudo chmod 755 $directory;fi;done
```
Another quick run on /usr/sbin/pwck gave the following:
```
ajitabhp@new-server:~$ sudo /usr/sbin/pwck
user news: directory /var/spool/news does not exist
user uucp: directory /var/spool/uucp does not exist
user www-data: directory /var/www does not exist
user list: directory /var/list does not exist
user irc: directory /var/run/ircd does not exist
user gnats: directory /var/lib/gnats does not exist
user nobody: directory /nonexistent does not exist
pwck: no changes
```
This is fine as these are all system accounts.

Like this:
Like Loading…
January 18, 2007
Setting up SNMP
SNMP is Simple Network Management Protocol. It allows the operational statistics of a computer to be stored in object identifiers (OIDs) which can then be remotely queried and changed.
For any serious remote monitoring, SNMP is required. I generally prefer to monitor server performances remotely using Nagios and SNMP.
This document describes the SNMP setup, which can then be used by any SNMP remote management software.
As a security measure, one needs to know the passwords or community strings in order to query the OIDs. The read-only community strings allow the data to be queried only and the read-write community strings allows the data to be changed.
I will be refering the setup on an Ubuntu server, while they should apply to any linux distribution.
Install SNMP daemon by
```
$ sudo apt-get install snmpd
```
and then add the following lines on top of the cofiguration file – /etc/snmp/snmpd.conf as follows.
```
$ sudo vi /etc/snmp/snmpd.conf
# type of string   private/public  host-from-which-access-is-restricted
rwcommunity        private         127.0.0.1
rocommunity        public          127.0.0.1

rwcommunity        ultraprivate    cms.unixclinic.net
rocommunity        itsallyours     cms.unixclinic.net
```
The first column is the type of community string, the second column is the community string itself and the third column (not mandatory) is the host restricted to use that community string.
The first two lines specifies that only localhost (127.0.0.1) is allowed to query the SNMP daemon using the specified read-only and read-write community strings. The next two lines specifies that only the host cms.unixclinic.net is allowed to query the SNMP daemon using the specified read-only and read-write strings.

If I remove the hostname (cms.unixclinic.net) then basically any host can query the snmp daemon if it knows the right community strings.

After making these changes, give the snmp daemon a restart and then test it using snmpwalk program:
```
$ sudo invoke-rc.d snmpd restart
Restarting network management services: snmpd.
$ snmpwalk -v1 -c public localhost system
SNMPv2-MIB::sysDescr.0 = STRING: Linux cms.unixclinic.net 2.6.17-10-generic #2 SMP Tue Dec 5 21:16:35 UTC 2006 x86_64
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1314) 0:00:13.14
SNMPv2-MIB::sysContact.0 = STRING: Ajitabh Pandey <hostmaster (at) unixclinic (dot) net>
SNMPv2-MIB::sysName.0 = STRING: cms.unixclinic.net
.......
.......
```
As a result of snmpwalk, you should see the system details as reported by SNMP. The snmpwalk command executed above means, you are querying “localhost” for “system” MIB and have specified SNMP ver 1 protocol to be used and the community string is “public”. Now as you know that this community string is for read-only access and is restricted to queries from 127.0.0.1 IP address only, so this works fine.

Further, if you now try to execute the following command over the network from host “cms.unixclinic.net” using the community string “itsallyours”, it should also work. But in mycase instead a timeout is received:
```
$ snmpwalk -v1 -c itsallyours cms.unixclinic.net system
Timeout: No Response from cms.unixclinic.net
```
Just for clarification, the current host from which snmpwalk is being run is also cms.unixclinic.net.

This should work on most distributions (RHEL 3, RHEL 4 and Debian Sarge it works like this), but on Ubuntu “Edgy Eft” 6.10 its not the case. This will fail. The reason being the defualt settings of SNMP. Following is the output of ps command from both an Edgy Eft machine and Sarge machine:
```
Ubuntu $  ps -ef|grep snmp|grep -v "grep"
snmp      5620     1  0 11:39 ?        00:00:00 /usr/sbin/snmpd -Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1

Debian $ ps -ef|grep snmp|grep -v "grep"
root      2777     1  0  2006 ?        00:46:35 /usr/sbin/snmpd -Lsd -Lf /dev/null -p /var/run/snmpd.pid
```
If you see carefully, that Ubuntu 6.10 snmp daemon is by default restricted to 127.0.0.1. This means that it is only listening on localhost. To change that and make it listen on all interfaces we need to change the /etc/default/snmpd file:

Change the following line
```
$ sudo vi /etc/default/snmpd
.....
SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1'
.....
```
to
```
SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid'
```
and then restart SNMPD
```
$ sudo invoke-rc.d snmpd restart
```
Like this:
Like Loading…
January 15, 2007

Category: FLOSS

Monitoring Lotus Notes/Domino Servers

Moinitoring Checks on Active Node

Interesting OIDs to plot for trend analysis

Files and Scripts

Like this:

Apache LDAP Authentication

Setting up webserver

Test Setup

Resources

Like this:

Using SNAT for Highly Available Services

Problem

Solution

Setting Up SNAT

Setting Heartbeat and IPTables for SNAT

Like this:

Migrating Users in Linux

Like this:

Setting up SNMP

Like this: