RPM: Query a specific rpm-file for information

Since I end up googling it each time I need this, it’s about time I write it down … If you want to query a specific RPM for information (Requires/Information/…) you’ll need to use the –package/-p option.

-p <file> — Query a Specific RPM Package File

Up to now, every means of specifying a package to an RPM query focused on packages that had already been installed. While it’s certainly very useful to be able to dredge up information about packages that are already on your system, what about packages that haven’t yet been installed? The -p option can do that for you.

So, if I wanted to show the Requires of my vmware-tools-kmp:

KMP: Define a new subpkg template

There might be reasons, you’d wish you could make the kernel module package do other things. Two already pop into my head: 1) The mpp-Image upgrades for the ibm-rdac kernel module packages and 2) the “adjustments” which need to be done post install for the VMware kernel module package in /etc/vmware-tools/locations.

What you basically do is this:

  1. Add the new subpkg template to your sources list
  2. Call the %suse_kernel_module_package macro with the option -s and then add your source number

For me this looks like this:

After that, you just need to copy over /usr/lib/rpm/rpm-suse-kernel-module-subpackage to /usr/src/packages/SOURCES/subpkg and make your adjustments to that copy.

For example the diff between those two could look like this:

This is my final version of the subpkg template and I hopefully demonstrated how powerful a customized subpkg template can be!

New vmware-tools-kmp

Disclaimer: I don’t take any responsibility for faults within the software, I just provide the RPM’s! Feel free to ask me about stuff concerning these RPM’s, but I ain’t accountable if your stuff goes kaboom! Oh, and those RPM’s aren’t recommended or supported by VMware!

Since we recently upgraded our VMware Infrastructure to VMware vSphere, I finally had a chance to refresh the RPM’s for the KMP for 2.6.16.60-0.39.3-0.1 and 2.6.27.21-0.1. You can find the source RPM here.

  • vmware-tools-kmp-bigsmp (SLES10: i586)
  • vmware-tools-kmp-debug (SLES10: i586/x86_64; SLES11: i586/x86_64)
  • vmware-tools-kmp-default (SLES10: i586/x86_64; SLES11: i586/x86_64)
  • vmware-tools-kmp-kdump (SLES10: i586/x86_64)
  • vmware-tools-kmp-kdumppae (SLES10: i586)
  • vmware-tools-kmp-pae (SLES11: i586)
  • vmware-tools-kmp-smp (SLES10: i586/x86_64)
  • vmware-tools-kmp-trace (SLES11: i586/x86_64)
  • vmware-tools-kmp-vmi (SLES10: i586; SLES11: i586)
  • vmware-tools-kmp-vmipae (SLES10: i586)
  • vmware-tools-kmp-xen (SLES10: i586/x86_64; SLES11: i586/x86_64)
  • vmware-tools-kmp-xenpae (SLES10: i586)

Just a heads-up: while the modules itself work, VMware did something to the init-script which prevents it to load the modules unless you run vmware-config-tools.pl. I’m still in the process of sorting that out.

Novell KMP: vmware-tools-kmp and ibm-lin_tape-kmp

Disclaimer: I don’t take any responsibility for faults within the software, I just provide the RPM’s! Feel free to ask me about stuff concerning these RPM’s, but I ain’t accountable if your stuff goes kaboom … Oh, and those RPM’s aren’t recommended or supported by Novell or IBM!

After working with the novell-kmp solution, I think it’s actually rather easy to create a “Kernel Module Package“. In the end, I created two additional KMP’s, one for the tools component of the VMware-Tools shipped with VMware ESX, and another for the lin_tape SCSI driver, used by our IBM TS3400 as well as the IBM TS7530.

Some parts (especially the build system used within the VMware kernel modules) took some figuring out/playing around, but I actually got it working. Now each time I update the VMware-Tools I just need to install the new RPM, tada! No need for a fully fledged build environment on every box.

SUSE Linux Enterprise Server 10:

  • ibm-lin_tape-1.24.0_2.6.16.60_0.37_f594963d-0.1 (i586, x86_64, SRPM)
    • ibm-lin_tape-kmp-bigsmp (i586)
    • ibm-lin_tape-kmp-debug (i586, x86_64)
    • ibm-lin_tape-kmp-default (i586, x86_64)
    • ibm-lin_tape-kmp-kdump (i586, x86_64)
    • ibm-lin_tape-kmp-kdumppae (i586)
    • ibm-lin_tape-kmp-smp (i586, x86_64)
    • ibm-lin_tape-kmp-vmi (i586)
    • ibm-lin_tape-kmp-vmipae (i586)
  • vmware-tools-kmp-3.5.0_153875_2.6.16.60_0.37_f594963d-0.1 (SRPM)
    • vmware-tools-kmp-bigsmp (i586)
    • vmware-tools-kmp-debug (i586, x86_64)
    • vmware-tools-kmp-default (i586, x86_64)
    • vmware-tools-kmp-kdump (i586, x86_64)
    • vmware-tools-kmp-kdumppae (i586)
    • vmware-tools-kmp-smp (i586, x86_64)
    • vmware-tools-kmp-vmi (i586)
    • vmware-tools-kmp-vmipae (i586)
    • vmware-tools-kmp-xen (i586, x86_64)
    • vmware-tools-kmp-xenpae (i586)

SUSE Linux Enterprise Server 11:

  • ibm-lin_tape-1.24.0_2.6.27.21_0.1-0.1 (i586, x86_64, SRPM)
    • ibm-lin_tape-kmp-debug (i586, x86_64)
    • ibm-lin_tape-kmp-default (i586, x86_64)
    • ibm-lin_tape-kmp-pae (i586)
    • ibm-lin_tape-kmp-trace (i586)
    • ibm-lin_tape-kmp-vm (i586, x86_64)
  • vmware-tools-kmp-3.5.0_153875_2.6.27.21_0.1-0.1 (SRPM)
    • vmware-tools-kmp-debug (i586, x86_64)
    • vmware-tools-kmp-default (i586, x86_64)
    • vmware-tools-kmp-pae (i586)
    • vmware-tools-kmp-trace (i586, x86_64)
    • vmware-tools-kmp-vmi (i586)
    • vmware-tools-kmp-xen (i586, x86_64)

Novell KMP: Useable version of ibm-rdac-ds4000

After some more tinkering, a lot more looking at the macros in /usr/lib/rpm/rpm-suse-kernel-module-subpackage and /usr/lib/rpm/suse_macros, I think I finally have a usable RPM’ified version of IBM’s Multipathing driver ready for use.

There is still one major annoyance left: each time you install a new ibm-rdac-ds4000-kmp RPM, you also need to reinstall the corresponding ibm-rdac-ds4000-initrd package, as the macros in /usr/lib/rpm don’t allow for custom %post or %postun.

As mentioned before, I’m gonna send them to LSI/IBM for review, and maybe, MAYBE they are actually gonna make use of that.

Without further delay, here’s the list of packages. Just a short explanation: you need mppUtil-%version, in order to install the ibm-rdac-ds4000-kmp.

  • mppUtil-09.03.0C05.0030-0.2 (i586, x86_64, SRPM)
  • ibm-rdac-kmp-09.03.0C05.0030_2.6.16.60_0.37_f594963d-0.2 (SRPM)
    • ibm-rdac-kmp-bigsmp (i586)
    • ibm-rdac-kmp-debug (i586, x86_64)
    • ibm-rdac-kmp-default (i586, x86_64)
    • ibm-rdac-kmp-kdump (i586, x86_64)
    • ibm-rdac-kmp-kdumppae (i586)
    • ibm-rdac-kmp-smp (i586, x86_64)
    • ibm-rdac-kmp-vmi (i586)
    • ibm-rdac-kmp-vmipae (i586)
  • ibm-rdac-ds4000-initrd-09.03.0C05.0030_2.6.16.60_0.37_f594963d-0.2
    • ibm-rdac-initrd-bigsmp (i586)
    • ibm-rdac-initrd-debug (i586, x86_64)
    • ibm-rdac-initrd-default (i586, x86_64)
    • ibm-rdac-initrd-kdump (i586, x86_64)
    • ibm-rdac-initrd-kdumppae (i586)
    • ibm-rdac-initrd-smp (i586, x86_64)
    • ibm-rdac-initrd-vmi (i586)
    • ibm-rdac-initrd-vmipae (i586)

This package should be usable with System Storage DS4000 as well as System Storage DS3000 (they use the exact same source code).

I also know, that this solution isn’t really perfect. I’ve been looking at the %triggerin/%triggerun macros, but right now I can’t draw up a scenario (an easy one at that) to successfully use triggers in this situation. Only idea coming up looks like this:

  1. Put the triggers into ibm-rdac-ds4000
  2. When installing the kernel module packages, write the kernelversion/-flavor into a temporary file (impossible, since the macros don’t let you influence %post), and then let the trigger create/update the MPP initrd

If anyone knows a better solution (as in easier, without the writing to a separate file), I’m all ears.

Novell KMP: KMP’ing IBM’s RDAC driver

Well, after yesterday’s lesson about getting the IBM RDAC to install for a not-yet-running kernel, I decided to take it a step further. Novell does have some documentation about KMP’s, which is actually rather good, especially the guide written by Andreas Grünbacher.

After a short tinkering, I got it actually working. I was kinda surprised, at how easily it actually is. One problem I still have to deal with, is modifying the %post, to generate the mpp-initrd image. For now, the KMP only contains the default %post, which updates the modules.* stuff.

Now, I’m kinda asking myself, why don’t more vendors submit their drivers to Novell in form of KMP’s … Anyway, I’m gonna send mine the LSI/IBM way, maybe they’ll pick it up …

Building opsview for SUSE Linux Enterprise 10

Disclaimer: I don’t take any responsibility for faults within the software, I just provide the RPM’s! Feel free to ask me about stuff concerning these RPM’s, but I ain’t accountable if your stuff goes kaboom

Well, I just looked at opsview again (haha, thanks Alex :-P). Only trouble is, the people over at opsview don’t distribute RPM’s for that … After registering for their site, to download the SRPM’s (or to download anything), I got the RPM’s and started looking at them.

Well, the only things I needed to adjust in opsview-base, opsview-core and opsview-perl were the dependencies. I also needed to rebuild a RPM for perl-Version from Dag Wieers, since opsview-perl required them to even build.

  1. opsview 2.14.1 (build 1695-1)
    • opsview-agent (i586, x86_64)
    • opsview-base (i586, x86_64)
    • opsview-core (noarch)
    • opsview-perl (i586, x86_64)
    • opsview-reports (noarch)
    • opsview-slave (i586, x86_64)
    • opsview-web (noarch)
  2. opsview 3.0.0 (beta, build 1895-1)
    • opsview-agent (i586, x86_64)
    • opsview-base (i586, x86_64)
    • opsview-core (noarch)
    • opsview-perl (i586, x86_64)
    • opsview-reports (noarch)
    • opsview-slave (noarch)
    • opsview-web (noarch)

Installation order is like this:

  1. opsview-base
  2. opsview-perl
  3. opsview-web
  4. opsview-core
  5. opsview-reports

If you are looking for older versions, try the respective directory on distributions.barfoo.org (for example i586 for SLES10).

If you encounter a missing link (either striked or just missing), please note that older builds aren’t available anymore.

Nagios and check_ram yet again

As some people know, I previously “created” (mostly modified the check_swap plug-in to print RAM usage) check_ram in C. Now one of my problems for the past few months was putting the C plug-in as well as “supported” environment under the same hat. Today I had another look at the amount of available plug-ins in NagiosExchange. There are quite a few plug-ins available, but as I do have some experience with Python, I used the one written in Python.

It was rather easy hacking in support for performance data into it, as the below shows. Someone else already posted a non-unified diff for performance data support, but that ain’t quite right according to the Nagios plug-in development guidelines.

Read More

The clue to build ppc64 RPM’s

Remember, I talked about building RPM’s on SLES10SP2 on ppc64 ? Well, turns out I was rather stupid .. and it was rather simple (don’t ask me why I didn’t think of that). I tried asking solar, I used Google (apparently with the wrong search parameters), nothing though. Not a clue.

Today it bugged me again, so I used Google again. This time with “ppc64 suse rpmbuild“, and guess what I saw within the preview of the second hit ..

And here I thought I was missing something, turns out I was really stupid though .. *shrug* Building stuff like nagios works with that just fine ..

Update: or not. It worked only a single time and is broken ever since again. Guess I’m gonna reload the box on Tuesday.