Dell’s OMSA (Open Manage Server Administrator) tools are quite nice, but the 6.5.x (and prior) version’s installation process did not lend itself to being automated and managed by Puppet. Now, with OMSA 7.0, things have changed, and mostly for the better. Especially for simplifying things from the puppet management side, and there is even a possibility that the new system will work well in our netboot environment. The older-style repository mirror would give us a heady mix a-la:

$ ls
bootstrap.cgi  per415                        system.ven_0x1028.dev_0x01e7
dx6000         per510                        system.ven_0x1028.dev_0x01ea
dx6000g        per515                        system.ven_0x1028.dev_0x01eb
dx6012s        per610                        system.ven_0x1028.dev_0x01f0
HEADER.shtml   per710                        system.ven_0x1028.dev_0x0205
mirrors.cgi    per715                        system.ven_0x1028.dev_0x0208
pe0420         per805                        system.ven_0x1028.dev_0x020b
pe0430         per810                        system.ven_0x1028.dev_0x020c
pe0440         per815                        system.ven_0x1028.dev_0x020f
pe0800         per900                        system.ven_0x1028.dev_0x0210
pe0830         per905                        system.ven_0x1028.dev_0x0221
pe0840         per910                        system.ven_0x1028.dev_0x0223
pe0850         pet100                        system.ven_0x1028.dev_0x0225
pe0860         pet105                        system.ven_0x1028.dev_0x0235
pe1430         pet110                        system.ven_0x1028.dev_0x0236
pe1435         pet110ii                      system.ven_0x1028.dev_0x0237
pe1800         pet300                        system.ven_0x1028.dev_0x023c
pe1850         pet310                        system.ven_0x1028.dev_0x025c
pe1855         pet410                        system.ven_0x1028.dev_0x027b
pe1900         pet605                        system.ven_0x1028.dev_0x0287
pe1950         pet610                        system.ven_0x1028.dev_0x028b
pe1955         pet710                        system.ven_0x1028.dev_0x028c
pe2800         platform_independent          system.ven_0x1028.dev_0x028d
pe2850         repoview.html                 system.ven_0x1028.dev_0x029b
pe2900         RPM-GPG-KEY-dell              system.ven_0x1028.dev_0x029c
pe2950         RPM-GPG-KEY-libsmbios         system.ven_0x1028.dev_0x02a3
pe2970         system.ven_0x1028.dev_0x016c  system.ven_0x1028.dev_0x02a4
pe6800         system.ven_0x1028.dev_0x016d  system.ven_0x1028.dev_0x02a5
pe6850         system.ven_0x1028.dev_0x016e  system.ven_0x1028.dev_0x02a6
pe6950         system.ven_0x1028.dev_0x016f  system.ven_0x1028.dev_0x02d3
pem600         system.ven_0x1028.dev_0x0170  system.ven_0x1028.dev_0x02d4
pem605         system.ven_0x1028.dev_0x0180  system.ven_0x1028.dev_0x02dc
pem610         system.ven_0x1028.dev_0x0183  system.ven_0x1028.dev_0x02f1
pem610x        system.ven_0x1028.dev_0x0185  system.ven_0x1028.dev_0x0430
pem710         system.ven_0x1028.dev_0x018a  system.ven_0x1028.dev_0x043c
pem710hd       system.ven_0x1028.dev_0x01ae  system.ven_0x1028.dev_0x0444
pem805         system.ven_0x1028.dev_0x01b1  system.ven_0x1028.dev_0x0445
pem905         system.ven_0x1028.dev_0x01b2  system.ven_0x1028.dev_0x045d
pem910         system.ven_0x1028.dev_0x01b3  system.ven_0x1028.dev_0x045f
pem915         system.ven_0x1028.dev_0x01b6  system.ven_0x1028.dev_0x0488
per200         system.ven_0x1028.dev_0x01b7  system.ven_0x1028.dev_0x0489
per210         system.ven_0x1028.dev_0x01b8  system.ven_0x1028.dev_0x04d6
per210ii       system.ven_0x1028.dev_0x01b9  system.ven_0x1028.dev_0x04dd
per300         system.ven_0x1028.dev_0x01bb  system.ven_0x1028.dev_0x04de
per310         system.ven_0x1028.dev_0x01df  system.ven_0x1028.dev_0x04fb
per410         system.ven_0x1028.dev_0x01e6  _tools

The setup wasn’t without its flaws – for one thing, one could not simply point Yum at this lot. Instead, the boostrap.cgi script was run (by way of wget -o piped to bash – what could wrong go with that?), which generated a repo definition file in /etc/yum.repos.d/ based on the system platform on which the boostrap was run, from which Yum could now install srvadmin, et cetera. Dell’s take on the матрешка installation method?

Technically, the initial steps are: 1) wget -q -O – http://repo-server/OMSA/hardware/latest/boostrap.cgi | bash 2) yum clean all 3) yum install srvadmin-all 4) /sbin/service dataeng start

In and of itself, this setup isn’t all that terrible. When it has to be automated with Puppet (our system configuration management system), however, shenanigans ensue.

Said shenanigans multiply at a rate that’d make a flat cat turn rainbow with envy when we try to manage rack-mounted netbooted Dell PowerEdge servers – the customized installation coded to a different hardware chassis means either separate netboots for each hardware class (and then, separate from that, netboot environment for the desktop-class machines which aren’t supported by OMSA), or trickery at boot-time. We chose later, but lack of happiness by all involved was noticeable.

Enter OMSA 7.0.The site does not appear to have the new software. Instead, one gets a large tarball within which there lives a different set of files:

/repos/pub/mirrors/$ ls -alF
total 538
drwxr-xr-x 6 root root    197 Jun 20 14:48 ./
drwxr-xr-x 8 root root    334 Jun 20 11:35 ../
-r-xr-xr-x 1 root root    899 Feb 15 08:39 COPYRIGHT.txt*
drwxrwxr-x 9 root root    144 Feb 15 08:39 docs/
-r-xr-xr-x 1 root root   9975 Feb 15 08:39 license.txt*
drwxr-xr-x 5 root root    107 Feb 15 02:38 linux/
-rwxrwxr-x 2 root root 111347 Feb 15 08:36*

Having to run is not all that much convenient than the previous setup. There is, however, one VERY large difference – there is now a common set of RPMs (split by OS) rather than by hardware, which allowed use to simply make a repo out of them.

Ingredients: OMSA 7.0 (One tarball) createrepo (one RPM, installed)

Steps: 1) Untar the OMSA 2) Create/switch to the OMSA 7.0 repo root directory Then, an incantation:

mkdir -p 5/x86_64/RPMS
cp linux/RPMS/supportRPMS/<em>/RHEL5/x86_64/</em> 5/x86_64/RPMS
mkdir -p 6/x86_64/RPMS
cp linux/RPMS/supportRPMS/<em>/RHEL6/x86_64/</em> 6/x86_64/RPMS
for rel in 5 6
  cd $rel/x86_64
  createrepo .
  cd ..

Craft yourself a yum repo file not unlike what’s listed below:

name=Dell OMSA repository - 7.0

When in doubt, yum clean all after any change to the /etc/yum.repos.d/ files.

Now, ‘yum install srvadmin-all’ works. The advantage is that we can have the repo definition put into place rather simply, and not worry about running scripts and various other things surrounding this.

The one thing the old method gave us was the ability to gather firmware versions of different components, as well as apply firmware updates. The New and Improved Way ™ doesn’t seem to provide this functionality, though it may be just a matter of figuring out the new thing.