This document intends to provide necessary information on installing Dell OpenManage Server Administrator 4.4 (OMSA) on Debian GNU/Linux 3.1 (Sarge). The document will begin on how to extract necessary files from OMSA RPM packages, continue on writing init.d scripts suitable for Debian and finally end on creating a simple Debian package of OMSA using dpkg.
Dell OpenManage Server Administrator is a tool for managing individual Dell PowerEdge servers. It can be used to monitor, configure, troubleshoot and update the system. OpenManage Server Administrator installation RPM packages can be downloaded from Dell's support site.
The package created using these instructions and files is a Debian package in it's most simplest form. The package may work, or it may not work. If compared to the guidelines given by the Debian Policy Manual, this package is totally broken. My quest was not to produce a high quality Debian package, but get OMSA installed on few Dell PowerEdge 1850/2850 servers. It works for me. I hope it works for you too.
If you are not interested in anyway how the OMSA package was created, this section is for you. I will shortly describe how to get OMSA running on your Dell server. If you are interested in how the package was made, jump to the next chapter.
First of all, you will need a Dell PowerEdge server. PowerEdge 1850 and 2850 are fine, I tested the package on those models. I haven't tried other models than those listed in the introduction, but you can try them too (tell me if it worked on some other models). The RAC service wont work on others than 1850/2850.
Getting the OMSA driver modules installed is the hardest part. You will need some knowledge on compiling a Linux kernel. Go to chapter OMSA driver modules for instructions on installing the driver modules. You will need Linux 2.6 kernel to use these instructions. After you have installed the drivers, you can download the OMSA package:
Installing the package is easy. Just type "dpkg -i dellomsa_4.4-1.deb" (or whatever the file name of the package is). Dpkg may complain of some missing dependencies (packages) – install the packages it asks for and try again. After all required packages are installed on the system, you should see something like this:
If everything went well, try running "/opt/dell/srvadmin/oma/bin/omreport chassis". You should get a short list of components and their states. For more CLI commands, check out the official OMSA manual. In case of problems, first check Misc. notes. It's good-to-know stuff anyway, so reading it wont hurt even if you don't have any problems.
As you probably already know, OMSA is only distributed as RPM packages. This is unfortunate for Debian users and the reason why I wrote this document. Installing OMSA on Debian from those RPM files is really not possible – I have tried using Debian packaged RPM and Alien to get them installed, but the installation and init.d scripts expect that you have a Redhat based distribution. In fact, Debian's RPM is not even recommended to be used for installing software.
Because I didn't have any other ideas, I used RPM to extract the packages and began to study their (pre)delete.sh and (pre)doinst.sh scripts. These are the scripts that are run when the package is installed/upgraded/removed/purged/etc. Some of the scripts were quite big and considering the number of RPMs (21), I decided that this was not the way for me to go on.
So, I finally decided to install Fedora Core 4 (32-bit) on PE1850 and then install complete OMSA 4.4 on it. This way I didn't have to poke around the (pre)delete.sh and (pre)doinst.sh scripts used by the RPM packages. Studying them would had required a lot of time and isn't meaningful for me (at the time). After the installation, I just copied all the files created by the installation process.
For your convenience, the tar files I have made of the installations are available for download. Now on I will continue with the one I made on PE1850. The reason why I mention this is that PE2550 uses RAC3 and PE1850 uses RAC4, so the installations differ. PE2550 is provided for people interested in trying that one out. Neither one of the tar files is usable on Debian 3.1 as is.
Here is a list of the files I spotted in 32-bit PE1850 installation (and included in the latter tar file mentioned above) with short descriptions:
As I mentioned, the init.d scripts provided by the OMSA installation are not usable on Debian. So I wrote new ones, simplified for Debian. The original init.d scripts can be used as a good reference. I replaced the original init.d scripts with two new scripts. I will describe them here (scripts downloadable by clicking their names). These scripts are crafted for 32-bit installation – using them with 64-bit installation will require some small modifications.
Finally I could begin creating package of OMSA. I will now explain what I did in plain words but also in unix commands. I hope this is clear enough to understand what was done.
I created a temporary directory /tmp/pkgroot. This directory will function as our imagined system's root directory. All files we put in this directory will be extracted in the system's root directory when the package is installed. In this directory, I extracted omsa-4.4-inst-fc4-pe1850.tar.gz and then removed these files:
The files above are quite Redhat specific and no use for creating a Debian package. Don't throw them away though if you're interested in writing your own init.d scripts. They are a good reference for doing that.
Commands executed this far:
OMSA needs libstdc++-libc6.2-2.so.3, but the Debian packaged version differs too much so that it could be used, so we need to copy it from Redhat. I have created a tar file of this library (copied from Fedora Core 4). The tar file is crafted so that it can be extracted to the package's root (it contains all necessary directories).
Next we can add our new init.d scripts to the etc/init.d directory. We also add file dellomsa to etc/default. This configuration file can be used to control which daemons will be started by dellomsa-daemons init.d script. You can check the contents of the file yourself, it has comments in it. By default, it only enables starting of the data engine to enable the use of omreport tool.
Now we have all files ready for our package. The next thing we will do is add Debian package specific stuff. I will not go into details with the files we're going to add now. They take care of installing the files to your system, adding some directories to /etc/ld.so.conf and starting the daemons for the first time. You can read about these files from the Debian Policy Manual.
We're now ready to put the package together using dpkg. We go one directory up and execute dpkg (the version string in filename must match the one in the DEBIAN/control file):
Now you should have file dellomsa_4.4-1.deb in /tmp. If you have the driver modules already installed, you can now try installing the package (otherwise check "OMSA driver modules" before):
Example output of the package installation is in quick start part.
OMSA needs two driver modules to run. One base module named dcdbas, and environment module named dcdesm, dcdtvm or dcdipm based on the server model. OMSA communicates with the drivers using device nodes created in /dev. These nodes are created by the init.d script which takes care of loading the driver modules.
The driver modules are distributed with OMSA – part in source code, part in precompiled object files. These files are located in directory /opt/dell/srvadmin/hapi/drivers/x86/dks. Dell provided init.d scripts take care of copying precompiled modules from /opt/dell/srvadmin/hapi/drivers/x86 to module directory or compiling the modules for the current running kernel. Automatic compiling requires that the source code for the running kernel is available thru' /lib/modules/<running-kernel-ver>/build symlink.
I went thru' the drivers and created a separate driver tar package. This is because in our environment, we compile all the Linux kernels in one centralized place. The kernel sources are not available on the production servers and Dell provided instsvcdrv would fail to compile the drivers. Instead, the drivers are compiled and included with our every kernel. The drivers are only loaded by the dellomsa-drivers init.d script, so this wont do any harm to our non-Dell based servers.
I have put the driver package on the net:
To use this package, you first need to compile yourself a Linux 2.6 kernel with CONFIG_REGPARM (use register parameters) enabled. You will also need serial support in the kernel if you want to use DRAC4. After the compilation, extract omsa-driver-4.4.tar.gz somewhere, cd to omsa-driver-4.4 and run "./builddriver.sh <kernel-source-dir>". The script will check that you have CONFIG_REGPARM enabled in the kernel config and gcc version >= 3.3.0 && <= 3.4.x. If everything is ok, it will compile the driver modules and copy them to /lib/modules/<corresponding-kernel-version>/extra.
You can check whether the modules were copied to the module directory (replace "2.6.12.2" with your kernel version):
Nagios is an open source host, service and network monitoring program. NRPE is a addon to Nagios. Quote from the Nagios FAQ: This addon [NRPE] allows you to execute "local" plugins (like check_disk, check_procs, etc.) on remote hosts. The NRPE daemon runs on the remote host and waits for plugin execution requests from the check_nrpe plugin on the monitoring host.
Nagios is our main monitoring software on the unix side here at the University of Tampere. I wrote a short NRPE plugin in Perl for polling hardware status of our Dell 8G (PE1850/2850s at the moment) servers. The plugin I made is still quite unfinished and doesn't yet make full use of the information provided by the omreport. The plugin does not even fully follow the Nagios plug-in development guidelines, but it fulfills our current needs. It simply executes omreport storage adisk controller=0 -fmt ssv and omreport chassis -fmt ssv, and then parses the output. Finally it outputs one line of status information and exists with a corresponding exit value.
The version 1.1 of the plugin is available at the URL http://www.cs.uta.fi/~pb72587/dellomsa/nrpe.
Setting up SNMP will require some manual work. RPMs' original init.d script did this automatically, but it is so small step to take care of that I decided not to automate it in anyway. I will shortly explain how to get SNMP working, step by step.
First, you will need to install snmpd. Debian packaged version is fine.
Next, add a line to /etc/snmp/snmpd.conf to allow OMSA to connect to snmpd using SMUX. This way snmpd is able to hand out information about the server. The line you have to add is:
After modifying the configuration file, restart snmpd by typing:
You probably also want to configure snmpd to allow querying of OMSA's information. Check snmpd's manual for doing this. Quickstart would be to comment out the first "com2sec" line and uncomment the second one.
Now snmpd should be fine. Next you need to enable SNMP support in OMSA by editing /etc/default/dellomsa. Change the line "SNMP_ENABLED=no" to "SNMP_ENABLED=yes". Then restart OMSA:
All done! You can use snmpwalk for testing (it's from the "snmp" package). Here's an example:
You should receive a long output of SNMP data. If you did, great! If you only got one line "End of MIB", your snmp access control is probably too tight to allow the query. Modify /etc/snmp/snmpd.conf again.
Dell's MIB file is provided with the OMSA installation. The file is /opt/dell/srvadmin/omsa/mibs/10892.mib.
| 2005-07-07 | First version to public |
|---|---|
| 2005-07-08 | Some spelling corrections |
| 2005-07-13 | Added PE2650 and PE1750 to the list of tested models |
| 2005-07-25 | Added signatures for some of the files (links added) |
| 2005-07-25 | Changed all the big file download links to use linux.dell.com as download site. Thanks go to Matt Domsch / Dell for mirroring these files. |
| 2005-08-25 | Added a note about Dell's MIB file needed for SNMP monitoring. |
| 2005-11-17 | The old OMSA drivers provided on this page cannot be used with >= Linux 2.6.14. This is because the verify_area function has been removed from kernel (it was replaced with access_ok). A patched version has been published. |
| 2006-01-29 | Minor fixes to documentation. |
This document and all the files are distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
If you have ideas how to make this document better or you have any other comments or tips, drop me an email.