XBMC: Adding the ppa keys to apt

I recently bought an Acer Aspire Revo and had one of my trainees put XMBC on a SDHC card today. So after a bit of toying earlier, I started looking at the thing (from the command line that is).

One thing, if you enable the PPA (ppa.launchpad.net) sources, apt/aptitude is gonna babble something about an unverified key.

I ended up looking the error up (since I only have an Ubuntu desktop). There’s a simple solution for this:

Alternatively you can also use this:

DawiControl SIL3114

Well, if you remember back to last December, I had some severe troubles with this fake ass RAID controller. At the time I posted my last problem (or rather, my conclusion) I already bought a 3WARE Escalade 9550SXU-8LP on EBay (used, since I didn’t want to spend ~400 EUR). Now after the controller arrived in mid-January, I ended up buying a new main-board, processor, memory, … in order to put the 3WARE card to use; initially I thought the 3WARE card would fit into my A7N8X-X, but apparently that only had a 16bit PCI-slot.

Now, after reinstalling the box, and a short while in the 3WARE controller BIOS, I ended up with a 2,9TiB RAID5 array. That’s it for this lovely DawiControl crap. If anyone needs one, I still have the one I bought at work (lying around in a shelf), holler me.

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 …

IBM RDAC: Installing the driver for a (not yet) running version

Well, kernel updates on our Linux servers running IBM’s RDAC driver (developed by LSI) is a real pest .. especially if you have to reboot the box two times in order to install the drivers/initrd correctly.

So I sat down and looked at the Makefile. Turns out, it just needs four tweaks in order to be working with a different kernel version (which you have to pass using environment variables to make).

After that, a simple make KERNEL_OBJ=/lib/modules/2.6.16.60-0.37_f594963d-smp/build OS_VER=2.6.16.60-0.37_f594963d-smp install correctly installs the modules in /lib/modules, rebuilds the correct modules dependencies and builds the correct initrd image.

Winter on Spiekeroog

Well, as I wrote last year, I spent some time with my brother on Spiekeroog (that’s where he’s currently living and working). As I left on December 4th, it started snowing like crazy ..

If you read the old article, you might remember that I mentioned Spiekeroog is 100% free of fossil fueled vehicles. That being said, let’s continue with the story I’m about to tell.

Anyway, my brother was walking me back to the hotel boat and we waited a bit in the harbour since we were a bit early. Now, every item is delivered by ship to the island, since there’s no other way (besides by air, which is kinda expensive ..). Anyway, them dockworkers ain’t stupid. They needed some snow-free space, and they started clearing the snow. But how ?

Well, again, them ain’t stupid … You take a forklift and a euro-pallet and you got what ? Exactly, a snow plow!

Spiekeroogish snow plow
Spiekeroog’ish snow plow

I know, the images are kinda grainy, sadly I only had my cell phone to take the photo (left the digital camera at home). C’est la vie ..

Firefox: Hosting Xmarks (formerly Foxmarks) on lighttpd

Well, I am an enthusiastic user of Xmarks (or Foxmarks) and played with this again and again. So this weekend, I finally decided to do it properly. I sat down, recreated the whole WebDAV stuff (even if I cheated of this HowtoForge article).

Always redirect traffic to HTTPS, since transmitting username and passwords via HTTP ain’t that secure (MITM)

Okay, so here are the shortended setup instructions:

  1. Enable mod_access, mod_auth, mod_redirect and mod_webdav in /etc/lighttpd/lighttpd.conf
  2. Create the necessary directories
  3. Create the htpasswd-file
  4. Configure the redirections

Since we just created the necessary directories, as well as a htpasswd-file containing a user we should be able to change the configuration now:

Now, just restart the lighttpd service and watch your WebDAV shine. Seriously, there are a couple of things you should be aware of:

  1. When using a home-grown WebDAV server with HTTPS (meaning, custom certificate), Firefox is gonna be blocking the site at first (and Xmarks is gonna fail with a rather cryptic “Error 8172“). Navigate to the URL manually and add an Exception for the certificate.
  2. Before changing the URL’s in Xmarks, I made the error and manually created directories named “bookmarks” and “passwords”, which I then entered in the respective dialogboxes in the settings window. That however made Xmarks cry horribly when running the synchronization.

After deleting the folders, it works just fine.