The Nagios Ecosystem: Nagios, Shinken, and Icinga

Nagios has been a standard-bearer for a long time, being developed originally by Ethan Galstad and included in Debian and Ubuntu for quite some time. In 2007, Ethan created a company built around providing enhancements to Nagios called Nagios Enterprises. However, for several years now there have been competitors to the original Nagios.

The first to come along was Icinga. This was a direct fork of the Nagios code that happened in May of 2009; the story of what lead to the fork was admirably reported by Free Software Magazine in April of 2012. In short, many developers were unhappy with the way that Nagios was being developed and with what they perceived as its many shortcomings which Ethan could not or would not fix. From Ethan’s standpoint, it was more about the enforcement of the Nagios trademark. The article summed it up best at the end: it’s complicated.

The H-Online also had an interview with Ethan Galstad about the future of Nagios and some of the history of the project.

Icinga is now in Ubuntu Universe and has been since Natty. It is also available for Debian Squeeze (current stable release).

Another project is Shinken: rather than a fork, it is a compatible replacement for the core Nagios code. When the Python-based Shinken code was rejected (vigorously) in summer of 2010 as a possible Nagios 4, it became an independent project. This project is newer than Icinga, but shows serious promise. It too, is now available in Ubuntu Universe and in Debian Wheezy (current testing release).

It is unfortunate that such animosity seems to swirl about Nagios; however, Icinga and Shinken appear to be quite healthy projects that provide much needed enhancements to Nagios users – and both are available in Ubuntu Precise Pangolin, the most recent Ubuntu LTS release.

I don’t know if Icinga or Shinken still work with Nagios mobile applications. If it’s just the URL, then the web server could rewrite the URL; if there is no compatible page for the mobile applications, then they can’t be used. However, I’d be surprised if there was no way to get the mobile apps working.

I’m going to try running Shinken and/or Nagios on an installation somewhere; we’ll see how it goes. I’ll report my experiences at a later date.

Log Rotation for MySQL using logrotate

The logrotate utility is a powerful and underrated utility used to rotate logs. It is one of Red Hat’s lesser known utilities; even so, it is available for a number of platforms, including Ubuntu.

However, its set up for MySQL is missing on Red Hat and incomplete on Ubuntu.

For Ubuntu, there is no rotation of the slow query logs. To rotate these logs, just add them to the standard Ubuntu logrotate file for MySQL – that is, /etc/logrotate.d/mysql-server. Add the logs to rotate to the beginning of the file, adding to the list of files already present there.

For Red Hat, a complete MySQL log rotation file is needed as there is none at all. The MySQL logrotation script was removed as part of a security update to Fedora Core 4 back on 17 May 2006, and later removed from Red Hat Enterprise Linux 4 Update 4. The reasoning was detailed in Bug #180639 (not available?) and Bug #182025. Since then, this missing logrotate file has been the subject of several bugs (such as Bug #547007) and also of message threads like this one from Red Hat’s rhelv5-list in July of 2007.

The response to all these queries is that the MySQL logrotate script is broken and it’s up to MySQL to fix it. However, this does not seem to take into account the new FLUSH LOGS command, and admins everywhere are creating their own scripts.

Over at Question Defense, Alex has a fabulous description of the entire process – from enabling logging through implementing log rotation. However, this process uses ~/.my.cnf to automatically log in; better is to use a file like /etc/mysql/maint.cnf the way that Debian (and Ubuntu) does it. In that case, Debian creates a special user and a password to go with it, and puts these into a file /detc/mysql/debian.cnf; here is a sample debian.cnf:

# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host     = localhost
user     = debian-sys-maint
password = i5Px6N4SZ9UhfSWa
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host     = localhost
user     = debian-sys-maint
password = i5Px6N4SZ9UhfSWa
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

For most purposes, only the [client] section is needed, along with the first three entries (host, user, and password). You could also specify the section as [mysqladmin] instead, which would limit the username and password to being used for mysqladmin only – which is the tool used during log rotation.

The critical command is this one:

/usr/bin/mysqladmin --defaults-file=/etc/mysql/logrotate.cnf

…where logrotate.cnf contains username and password details as described above. All the rest of the logrotate file is settings and script-bulletproofing:

# Modified Ubuntu logrotate script for MySQL server
#
# Untested under Red Hat, but should work: filenames will have to be changed
/var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log {
        daily
        rotate 7
        missingok
        create 640 mysql adm
        compress
        sharedscripts
        postrotate
                test -x /usr/bin/mysqladmin || exit 0
                MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/logrotate.cnf"
                if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then
                  if killall -q -s0 -umysql mysqld; then
                    exit 1
                  fi 
                else
                  $MYADMIN flush-logs
                fi
        endscript
}

Turning off NET-SNMP overlogging

In the normal configuration – both on Red Hat and Ubuntu – you’ll find that SNMP is filling your logs with an endless amount of log entries, especially if you have monitoring tools that use SNMP every five minutes. They’ll generate messages like this:

Jan  8 13:45:02 example snmpd[2048]: Connection from UDP: [10.0.0.1]:51890
Jan  8 13:45:02 example snmpd[2048]: Received SNMP packet(s) from UDP: [10.0.0.1]:51890
Jan  8 13:45:02 example last message repeated 2 times

To get rid of these, change the priority levels that are logged by NET-SNMP. This can be done by changing the options sent to SNMP.

Look for a file /etc/default/snmpd or /etc/sysconfig/snmpd or similar. There should be a set of SNMP options – probably with an option like this one:

-Ls d

Change this option to be:

-LS5d

This will log everything at level NOTICE or higher (that is, severity level 5 down to severity 0). The severity levels used are those used by syslog; they are described in syslog(3).

This works because the messages being seen are logged at level INFO; by not logging items at that severity level the log entries no longer clutter the syslog files.

However, there is another set of messages that are common to NET-SNMP logs:

Sep  7 09:47:29 burp snmpd[19242]: diskio.c: don't know how to handle 9 request
Sep  7 09:47:29 burp snmpd[19242]: diskio.c: don't know how to handle 10 request
Sep  7 09:47:29 burp snmpd[19242]: diskio.c: don't know how to handle 11 request

This is the result of a bug (Red Hat Bugzilla #474093 – login required) which causes these “errors” when the SNMP diskIOTable is traversed. Red Hat fixed this bug back in September of 2009.

According to this message by Chris Rizzo, Red Hat stated:

The message that you see here is a result of querying for statistics
that are not available on the linux system. Requests 9, 10, and 11 are
defined as:

#define DISKIO_LA1 9
#define DISKIO_LA5 10
#define DISKIO_LA15 11

You can see where these statistics pop up by querying the SNMP diskIOTable using this command:

snmptable -v 2c -c public host diskIOTable

The output will look like this:

SNMP table: UCD-DISKIO-MIB::diskIOTable

 diskIOIndex diskIODevice diskIONRead diskIONWritten diskIOReads diskIOWrites diskIOLA1 diskIOLA5 diskIOLA15 diskIONReadX diskIONWrittenX
           1         ram0           0              0           0            0         ?         ?          ?            0               0
           2         ram1           0              0           0            0         ?         ?          ?            0               0
           3         ram2           0              0           0            0         ?         ?          ?            0               0
           4         ram3           0              0           0            0         ?         ?          ?            0               0
           5         ram4           0              0           0            0         ?         ?          ?            0               0
           6         ram5           0              0           0            0         ?         ?          ?            0               0
           7         ram6           0              0           0            0         ?         ?          ?            0               0
           8         ram7           0              0           0            0         ?         ?          ?            0               0
           9         ram8           0              0           0            0         ?         ?          ?            0               0
          10         ram9           0              0           0            0         ?         ?          ?            0               0
          11        ram10           0              0           0            0         ?         ?          ?            0               0
          12        ram11           0              0           0            0         ?         ?          ?            0               0
          13        ram12           0              0           0            0         ?         ?          ?            0               0
          14        ram13           0              0           0            0         ?         ?          ?            0               0
          15        ram14           0              0           0            0         ?         ?          ?            0               0
          16        ram15           0              0           0            0         ?         ?          ?            0               0
          17        loop0           0              0           0            0         ?         ?          ?            0               0
          18        loop1           0              0           0            0         ?         ?          ?            0               0
          19        loop2           0              0           0            0         ?         ?          ?            0               0
          20        loop3           0              0           0            0         ?         ?          ?            0               0
          21        loop4           0              0           0            0         ?         ?          ?            0               0
          22        loop5           0              0           0            0         ?         ?          ?            0               0
          23        loop6           0              0           0            0         ?         ?          ?            0               0
          24        loop7           0              0           0            0         ?         ?          ?            0               0
          25          sr0           0              0           0            0         ?         ?          ?            0               0
          26          sda  2840214016     1178369536     8946299      2080062         ?         ?          ? 990682692096     18358238720
          27         sda1      598016         208896          82            8         ?         ?          ?       598016          208896
          28         sda2        2048              0           2            0         ?         ?          ?         2048               0
          29         sda3     2286592        4649984         449          332         ?         ?          ?      2286592         4649984
          30         sda5  2836463104     1173473792     8945636      2079527         ?         ?          ? 990678941184     18353342976
          31          sdb  2960873984     1173473792     1940422      2079476         ?         ?          ? 990803352064     18353342976
          32         sdb1      638976              0          83            0         ?         ?          ?       638976               0
          33         sdb2      798720              0         153            0         ?         ?          ?       798720               0
          34         sdb3        6144              0           2            0         ?         ?          ?         6144               0
          35         sdb5  2958672384     1173473792     1940080      2079284         ?         ?          ? 990801150464     18353342976
          36          md0  3051716608     1727252992       93765      1641387         ?         ?          ?   3051716608     14612154880
          37          sdc  3067452416      425118208     1640751      3638614         ?         ?          ? 101851700224    438511782400
          38         sdc1  3067317248      425118208     1640721      3638613         ?         ?          ? 101851565056    438511782400
          39          sdd      307712              0          76            0         ?         ?          ?       307712               0
          40         sdd1      147968              0          37            0         ?         ?          ?       147968               0
          41         sdd2      131072              0          32            0         ?         ?          ?       131072               0

Towards the right side of center, you can see the metrics diskIOLA1, diskIOLA5, diskIOLA15; these are unsupported on Linux (as marked by the ? in each column). These are the 1 minute average disk load (as a percentage), the 5 minute average disk load, and the 15 minute average disk load respectively.

The three have SNMP OIDs of .1.3.6.1.4.1.2021.13.15.1.1.9 and .1.3.6.1.4.1.2021.13.15.1.1.10 and .1.3.6.1.4.1.2021.13.15.1.1.11 respectively – thus, the logged complaint of not knowing how to handle request 9 (or 10 or 11).

Without changing the code, there doesn’t seem to be any way to eradicate this message if you are querying the diskIOTable. Red Hat fixed the bug, perhaps others will? The bug remains on Ubuntu Lucid Lynx, unfortunately.

Using Nagios from an Android Phone

I got an Android phone in the last year, and started looking in earnest for a Nagios client for it. With a Nagios client, you can read what the current status is of your systems in Nagios.

There are several available; the two most often mentioned are NagRoid and NagMonDroid. However, neither one of these worked for me, and there are indeed others that were good.

All of the clients use the same basic method to get data from Nagios: scrape the data from a web page. The biggest problem comes when that web page is not available – or is incorrect. Most of these applications request a URL, but sometimes are unclear as to what URL they want exactly. Add to that the fact that Nagios changed its URL structure slightly between versions and it gets even more complicated.

To discover what was happening, I used tcpdump to watch the accesses to the web server from the Nagios clients, as well as watching the Apache logs. By doing this, I was able to discern what URLs were being loaded.

Here are some of the URL paths being looked for by the various clients:

• /cgi-bin/tac.cgi
• /cgi-bin/status.cgi
• /cgi-bin/nagios3/statuswml.cgi?style=uprobs
• /cgi-bin/nagios3/status.cgi?style=detail
• /cgi-bin/nagios3/status.cgi?&servicestatustypes=29&serviceprops=262144

Further complicating matters in my case was the fact that any unrecognized URL was massaged (via mod_rewrite) into serving the main Nagios page via SSL.

However, by using mod_rewrite it was possible to rewrite the old /cgi-bin paths to a newer /cgi-bin/nagios3 path, and things started working.

In the case of the statuswml.cgi file, Google Chrome wanted to download the resulting file instead of actually using it somehow.

The main choices for Nagios clients on Android are these:

• NagRoid
• NagMonDroid
• aNag
• jNag (and jNag ad supported)
• TiNag (and TiNag Light)

I have gone with aNag – it has a nice interface, good use of notification, and worked without trouble once the URL was fixed up. Several of the others never did work right – or they gave no indication that they were working right. In the case of jNag, it also requires a modified Nagios server and the installation of mkLivestatus. aNag was the one that was easiest to work with and get working.

aNag does use a mostly text-based format to show data, but it has the ability to manipulate services as well as one-button access to the web interface directly.

Logging transfers via SFTP

When you install OpenSSH, you also get SFTP for free: a replacement for FTP. (Note that SFTP is related to FTP by name only.)

SFTP is very useful, but as is normally configured, it does not provide any logging of user’s file transfers. For monitoring usage, this can be a problem.

The original setting in sshd_config might look like this:

Subsystem sftp /usr/libexec/openssh/sftp-server

This lack of logging is easily remedied; the details can be found in the man page for sftp-server:

Subsystem sftp /usr/libexec/openssh/sftp-server -l INFO

For best results, check your system’s man pages for the available options.

What’s Wrong with Nagios? (and Monitoring)

Nagios (or its new off-spring, Icinga) is the king of open source monitoring, and there are others like it. So what’s wrong with monitoring? Why does it bug me so?

Nagios is not the complete monitoring solution that many think it is because it can only mark the passing of a threshold: there is basically only two states: good and not good (ignoring “warning” and “unknown” for now).

What monitoring needs is two things: a) time, and b) flexibility.

Time is the ability to look at the change in a process or value over time. Disk I/O might or might not be high – but has it been high for the last twenty minutes or is it just on a peak? Has disk usage been slowly increasing or did it skyrocket in the last minute? This capability can be provided by tools like the System Event Correlator (SEC). The biggest problem with SEC is that it runs by scanning logs; if something isn’t logged SEC won’t see it.

The second thing is what drove me to write: there is no flexibility in these good/not-good checks that Nagios and its ilk provide. There is also not enough flexibility in SEC and others like it.

What is needed is a pattern recognition system – one that says, this load is not like the others that the system has experienced at this time in the past. If you look at a chart of system load on an average server (with users or developers on it) you’ll see that the load rises in the morning and decreases at closing time. When using Nagios, the load is either good or bad – with a single value. Yet a moderately heavy load could be a danger sign at 3 a.m. but not at 11 a.m. Likewise, having 30 users logged in is not a problem at 3 p.m. on a Tuesday – but could be a big problem at 3 p.m. on a Sunday.

What we really need is a learning system that can match the current information from the system with recorded information from the past – matched by time.

It’s always been said that open source is driven by someone “scratching an itch.” This sounds like mine…

Net-SNMP SMUX Fails on Ubuntu: A Fix

When trying to set up Dell OpenManage on some servers, I found that SMUX was not working. SMUX is a protocol that allows agents to connect to a SNMP daemon and provide answers to SNMP queries in a portion of the tree.

When working, SNMP should generate this log message in /var/log/daemon.log:

May 11 17:14:18 serverx snmpd[29678]: accepted smux peer: oid SNMPv2-SMI::enterprises.674.10892.1, descr Systems Management SNMP MIB Plug-in Manager

In my case, I saw this instead:

May 11 17:06:59 serverx snmpd[29471]: /etc/snmp/snmpd.conf: line 370: Warning: Unknown token: smuxpeer.

After a long time fussing with SNMP and Dell OpenManage, it turned out that the problem was that the SMUX subsystem was being disabled at daemon startup by an option set in /etc/default/snmpd. Using the -I option will turn on (or off) a particular module used by snmpd. In this case, the line looked like this:

SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid'

With this configuration, the SMUX module is disabled. For snmpd to support SMUX, the line should look like this instead (removing the -I option and its argument):

SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -g snmp -p /var/run/snmpd.pid'

After making the change, restart the daemon:

service snmpd restart

This should then fix problems in using Dell OpenManage (or other SMUX agents). You don’t have to restart Dell OpenManage to make this work, but it should have SNMP enabled (which provides the smuxpeer line in snmpd.conf).

To enable SNMP for Dell OpenManage, use this:

service dataeng enablesnmp

To restart the Dell OpenManage services, don’t use the usual services; use this command instead (which takes care of all Dell OpenManage services):

srvadmin-services.sh restart

Why SMUX should be disabled I couldn’t say. The system is running Ubuntu 10.04.2 LTS with snmpd 5.4.2.1-dfsg0ubuntu1-0ubuntu2.1.

Nagios and the Ampersand Character in URLs

When configuring Nagios for notifications, you will have something like this:

# commands.cfg

# vim: se nowrap

#========================================
# NOTIFICATIONS
#========================================

# 'notify-host-by-email' command definition
define command{
        command_name    notify-host-by-email
        command_line    /usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nAddress: $HOSTADDRESS$\nInfo: $HOSTOUTPUT$\n\nDate/Time: $LONGDATETIME$\n" | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Host Alert: $HOSTNAME$ is $HOSTSTATE$ **" $CONTACTEMAIL$
        }

# 'notify-service-by-email' command definition
define command{
        command_name    notify-service-by-email
        command_line    /usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$" | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$
        }

Now, you might want to extend these by adding the host or service URL. With this addition, the receiver of the message can click on the URL for more data.

The URL for the notes and actions are available; they are in these macros

• $HOSTACTIONURL$
• $SERVICEACTIONURL$
• $HOSTNOTESURL$
• $SERVICENOTESURL$

It should be simple to add these to the command_line line in the Nagios configuration; unfortunately, it is not that simple. This is because ampersands are removed from the URL when it is inserted. Ampersands are used to separate arguments that are sent to web pages – and may be included in the URLs. PNP4Nagios does this, and sends arguments to its web pages separated by ampersands (as it should).

The Nagios documentation hints at this character cleansing process, but does not mention these macros as ones that are cleaned and stripped of shell characters.

The shell characters that are stripped can be set with the illegal_macro_output_chars setting in the main configuration file. According to the documentation, the affected macros are: $HOSTOUTPUT$, $HOSTPERFDATA$, $HOSTACKAUTHOR$, $HOSTACKCOMMENT$, $SERVICEOUTPUT$, $SERVICEPERFDATA$, $SERVICEACKAUTHOR$, and $SERVICEACKCOMMENT$.

There are ways to escape some characters in certain situations, but escaping the ampersand doesn’t work here – especially since the URLs are taken literally (and uninterpreted) in other situations.

The resolution to this problem is to bypass the macro altogether and use the environment variables instead. Replace the macro with its environment variable equivalent. For example, replace:

$HOSTACTIONURL$

in the command_line entry with this:

$${NAGIOS_HOSTACTIONURL}

With this, the string that is actually passed to the shell is:

${NAGIOS_HOSTACTIONURL}

which then is interpreted as a shell environment variable (which, in this case, is set by Nagios). The squiggly brackets are possibly irrelevant, but they don’t hurt.

Installing VMware vSphere CLI 4.0 in Ubuntu 10.04 LTS

Installing the VMware vSphere Command Line Interface (CLI) has the potential for problems. In my case, it generated an error – a three-year old error. Perl returns the error:

undefined symbol: Perl_Tstack_sp_ptr

Not only has this error been around for three years, it also has shown up in numerous other instances. Ed Haletky wrestled with the error in VMware vSphere CLI back in June of 2008. The error surfaced in Arch Linux in 2008, both in running their package manager and in running cpan itself. This error also came up (again in 2008) in attempting to build and run Zimbra. (The response from Zimbra support was cold and unwavering: we don’t support that environment and won’t discuss it. How unfortunate.) The error also affected the installation of Bugzilla according to this email thread from 2009.

On the Perl Porters mailing list, there is an in-depth response as to what causes this error. From reading these messages, it appears that there are two related causes:

• Using modules compiled for Perl 5.8 with Perl 5.10
• Using modules compiled against a threaded Perl with an unthreaded Perl

One recommended solution is to recompile the modules using the cpan utility:

cpan -r

That may or may not be enough; it depends on if there were other errors. In attempting to run the vSphere CLI, I get this error:

IO::Compress::Gzip version 2.02 required--this is only version 2.005

To fix this, I ran cpan this way:

cpan IO::Compress::Gzip

In my case, that loaded IO::Compress::Gzip version 2.033.

I also loaded the libxml2-dev package; I don’t know if that was necessary or not:

apt-get install libxml2-dev

Whenever using cpan, I always wonder how it affects my packaged installations and whether it installs for all users or just me (and how to control that) – but I’ve never had any problems and installs as root seem to go into /usr/local – which makes sense.

Having done all this, I can now use the vSphere CLI to activate SNMP on the ESXi 4 servers. For the record, this is an integral part of ESXi 4 and supports all SNMP polling and traps – previously, only SNMP traps were supported. Certainly a nice improvement.

Installing Dell OpenManage with Ubuntu and Red Hat Linux

Dell OpenManage Server Administrator is a program for managing Dell machines. Dell provides support for Windows, SUSE Linux Enterprise Server (SLES), and Red Hat Enterprise Linux (RHEL).

There is, however, no support for Ubuntu whatsoever and no support for a Red Hat Yum Repository. Both of these failings are somewhat rectified by kind people working for Dell. Instructions from Dell regarding the Ubuntu APT repository and the Red Hat Yum Repository are available. The Dell wiki has more details on the Red Hat repository as well.

Over at Keith’s Code there is a fantastic tutorial on how to get Dell OMSA running on Ubuntu.

To get the yum repository loaded into Red Hat Enterprise Linux, just pull this file from the web and execute it:

wget -q -O - http://linux.dell.com/repo/hardware/latest/bootstrap.cgi | bash

Note that these directions come from Dell’s repository page and the file itself comes from linux.dell.com. It pulls in some RPMs that load the repository and update the cache with the available files. This is what the execution looked like for me:

Downloading GPG key: http://linux.dell.com/repo/hardware/latest/RPM-GPG-KEY-dell
    Key already exists in RPM, skipping
Downloading GPG key: http://linux.dell.com/repo/hardware/latest/RPM-GPG-KEY-libsmbios
    Importing key into RPM.
Write repository configuration
Downloading repository RPM
Installing repository rpm: http://linux.dell.com/repo/hardware/latest/platform_independent/rh50_64/prereq/dell-omsa-repository-2-5.noarch.rpm
Installing yum plugins for system id
Loaded plugins: rhnplugin, security
This system is not subscribed to any channels.
RHN channel support will be disabled.
dell-omsa-indep                                                                                                                       | 1.9 kB     00:00
dell-omsa-indep/primary                                                                                                               |  87 kB     00:00
dell-omsa-indep                                                                                                                                      655/655
dell-omsa-specific                                                                                                                    | 1.9 kB     00:00
dell-omsa-specific/primary                                                                                                            |  87 kB     00:00
dell-omsa-specific                                                                                                                                   655/655
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package yum-dellsysid.x86_64 0:2.2.26-6.2.el5 set to be updated
--> Processing Dependency: smbios-utils-python >= 2.2.0 for package: yum-dellsysid
--> Running transaction check
---> Package smbios-utils-python.x86_64 0:2.2.26-6.2.el5 set to be updated
--> Processing Dependency: python-smbios = 2.2.26-6.2.el5 for package: smbios-utils-python
--> Running transaction check
---> Package python-smbios.x86_64 0:2.2.26-6.2.el5 set to be updated
--> Processing Dependency: libsmbios = 2.2.26-6.2.el5 for package: python-smbios
--> Processing Dependency: python-ctypes for package: python-smbios
--> Running transaction check
---> Package libsmbios.x86_64 0:2.2.26-6.2.el5 set to be updated
---> Package python-ctypes.x86_64 0:1.0.2-1.1.el5 set to be updated
--> Finished Dependency Resolution
 
Dependencies Resolved
 
=============================================================================================================================================================
Package                                   Arch                         Version                               Repository                                Size
=============================================================================================================================================================
Installing:
 yum-dellsysid                             x86_64                       2.2.26-6.2.el5                        dell-omsa-indep                           16 k
Installing for dependencies:
 libsmbios                                 x86_64                       2.2.26-6.2.el5                        dell-omsa-specific                       1.5 M
 python-ctypes                             x86_64                       1.0.2-1.1.el5                         dell-omsa-specific                       215 k
 python-smbios                             x86_64                       2.2.26-6.2.el5                        dell-omsa-specific                        71 k
 smbios-utils-python                       x86_64                       2.2.26-6.2.el5                        dell-omsa-specific                        63 k
 
Transaction Summary
=============================================================================================================================================================
Install      5 Package(s)
Update       0 Package(s)
Remove       0 Package(s)
 
Total download size: 1.9 M
Downloading Packages:
(1/5): yum-dellsysid-2.2.26-6.2.el5.x86_64.rpm                                                                                        |  16 kB     00:00
(2/5): smbios-utils-python-2.2.26-6.2.el5.x86_64.rpm                                                                                  |  63 kB     00:00
(3/5): python-smbios-2.2.26-6.2.el5.x86_64.rpm                                                                                        |  71 kB     00:00
(4/5): python-ctypes-1.0.2-1.1.el5.x86_64.rpm                                                                                         | 215 kB     00:00
(5/5): libsmbios-2.2.26-6.2.el5.x86_64.rpm                                                                                            | 1.5 MB     00:06
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                        222 kB/s | 1.9 MB     00:08
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing     : python-ctypes                                                                                                                         1/5
  Installing     : libsmbios                                                                                                                             2/5
  Installing     : python-smbios                                                                                                                         3/5
  Installing     : smbios-utils-python                                                                                                                   4/5
  Installing     : yum-dellsysid                                                                                                                         5/5
 
Installed:
  yum-dellsysid.x86_64 0:2.2.26-6.2.el5
 
Dependency Installed:
  libsmbios.x86_64 0:2.2.26-6.2.el5 python-ctypes.x86_64 0:1.0.2-1.1.el5 python-smbios.x86_64 0:2.2.26-6.2.el5 smbios-utils-python.x86_64 0:2.2.26-6.2.el5
 
Complete!
Loaded plugins: dellsysid, security
Cleaning up Everything
Done!

Activating the APT repository on an Ubuntu system is even easier; add this file to /etc/apt/sources.list.d/ and do an apt-get update:

# Get latest Dell OpenManage software
deb http://linux.dell.com/repo/community/deb/latest /


Dell’s OMSA works with SNMP traps and with IPMI, so make sure that these are fully supported and enabled. There is a good introduction to IPMI from Intel that is often referenced, but is missing: it is available here (and is referenced as 25133701.pdf in links elsewhere). There’s also a good quick overview of IPMI from Terry Gleidt.