Diagram of OMSA 5.0 components' dependencies, excl. RAC components
This document intends to represent the progress of my efforts to re-package Dell OpenManage Server Administrator 5.0 (OMSA) as Debian packages.
| 2006-10-17 | My work on OMSA is completely stalled. I don't have time to work on it, at least not right now. |
|---|---|
| 2006-07-13 | The repackaging work has not progressed the way as I expected. I'm working on a major J2EE software project which is currently taking most of my time. I try to get at least the base packages repackaged before end of August, but we'll see. |
| 2006-06-09 | OMSA 5.0 is out! I have started re-packaging it. Check out the re-packaging status in the section Current status. |
Dell OpenManage Server Administrator (OMSA) is a tool for managing Dell PowerEdge servers. It can be used to monitor, configure, diagnose and update the system. OpenManage Server Administrator installation packages can be downloaded from Dell's support site. Unfortunately, Dell only provides Linux version of OMSA as RPM packages, targeted for RHEL.
My intention is to re-package OMSA 5.0 as Debian packages and provide necessary instructions for installing OMSA 5.0 on Debian-based distributions. My primary target is Debian Sarge, but at least Ubuntu Dapper Drake is under consideration. This time I am going to take the idea of re-packaging one step further compared to my previous OMSA 4.4 packages. Instead of making one big Debian package containing all the components of OMSA, I will try to preserve the original modularization as identical as possible and create a somewhat 1:1 Debian packages of the original RPMs.
I don't have any schedule for my re-packaging process, but I expect to get the base components re-packaged during June 2006. At least the RAC3 component packages are bit problematic, so I can't promise that I will be able to re-package OMSA 5.0 as a whole. Neither can I promise that the re-packaging will be possible at all because of all the Red Hat / RPM specific stuff that has been put into OMSA's scripts. I really have to consider how much time I'm willing to spend on doing something like this on my spare time.
This work is based on the original OMSA 5.0 package provided by Dell. The package is named OMI-SrvAdmin-Dell-Web-LX-50_A00.tar.gz and it's available for download on Dell's support site.
I wanted to first do some planning instead of just blindly begin the re-packaging of OMSA. My main plan is to re-package OMSA package by package and then test each package individually. To be able to test each package immediately after re-packaging, I made up two diagrams of the dependencies of each OMSA package. I simply downloaded OMSA's RPM packages and used rpm (rpm -qpR pkgname.rpm) to find out the package dependencies of each package.
Below are two diagrams of the OMSA's RPM packages representing their dependencies (original Microsoft Visio file of the diagrams). I had to break the dependencies into two diagrams, because the dependencies didn't fit single diagram nicely. The first one represents the base RPMs, excluding the RAC components. The second one represents the RAC components, including their dependencies on the base RPMs. Each blue box in the diagrams represent a RPM package of OMSA. I have also added the dependencies pointing to the packages that do not belong to OMSA -- they have yellow background and should be provided by the Linux distribution in question. In the second diagram some of the OMSA's packages have grey background meaning that the dependencies of those packages have already been represented in the first diagram and I only had to include them to be able to refer to them in the second diagram.
I have created a table of OMSA's packages so that it is easier to follow how the re-packaging process is progressing. The packages are ordered in the way I am going to re-package them. Red cell background denotes that I have not yet began re-packaging the package. Yellow background denotes that the work is in progress and green background denotes an already re-packaged package. I will add a link to a separate page for each completed package. Those pages will contain my notes about the re-packaged packages and short explanation what I did to get the package re-packaged.
I have divided the packages into two separate tables. The first table contains the OMSA's base component packages and the second table contains the RAC component packages.
| Package name | Purpose | Status | Notes |
|---|---|---|---|
| srvadmin-omilcore | - | in progress | - |
| instsvc-drivers | - | undone | - |
| srvadmin-ipmi | - | undone | - |
| srvadmin-deng | - | undone | - |
| srvadmin-hapi | - | undone | - |
| srvadmin-isvc | - | undone | - |
| srvadmin-omacore | - | undone | - |
| srvadmin-odf | - | undone | - |
| srvadmin-storage | - | undone | - |
| srvadmin-cm | - | undone | - |
| srvadmin-omhip | - | undone | - |
| srvadmin-jre | - | undone | - |
| srvadmin-old | - | undone | - |
| srvadmin-iws | - | undone | - |
| Package name | Purpose | Status | Notes |
|---|---|---|---|
| srvadmin-racsvc | - | undone | - |
| srvadmin-rac4-components | - | undone | - |
| srvadmin-racdrsc4 | - | undone | - |
| srvadmin-rac5-components | - | undone | - |
| srvadmin-racdrsc5 | - | undone | - |
| srvadmin-racadm4 | - | undone | - |
| srvadmin-racadm5 | - | undone | - |
| srvadmin-racser | - | undone | - |
| srvadmin-rac3-components | - | undone | - |
| srvadmin-racdrsc3 | - | undone | - |
| srvadmin-racvnc | - | undone | - |
| srvadmin-racser-devel | - | undone | - |
Re-packaging a single package is quite straightforward as is. Each RPM package contains a pile of program files (the actual package contents) and possibly few scripts used by the package management software to install and uninstall the package. This is quite simplified view of the situation, but fits the scope of this document. As said, RPM package may contain few scripts to do some tasks involving the (un)installation of the package. These tasks can be divided into:
Fortunately, Debian packages follow a very similar approach for tasks with just a small exception: there's no place for verifying tasks. OMSA's packages don't contain any verifying tasks, so I don't have to worry about them. The biggest work in re-packaging is to get the scripts (used for the tasks mentioned above) to work in Debian. Each script may even work differently depending whether we are upgrading an old package or installing the package into clean system. After the necessary modifications to the scripts I simply follow the normal Debian package creation guidelines set by Debian Policy Manual.
So far I have used the following tools in a way or another:
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.