VMware Update Manager issues

Well, I recently (last Wednesday) had a lot of trouble with Update Manager.

First I thought, upgrading vCenter and modules to 5.0U1 would solve my troubles, however it did not. Update Manager was still complaining about something. Since neither in the vCenter Update Manager nor the vCenter log itself were having any useful information I enabled SSHd and the ESXi Shell via the vCenter client:

SSH’ed into the ESX host and looked at /var/log/esxupdate.log, and found this particular log:

As you can see from the above log, for whatever reason, the Update Manager is trying to install an updated version of the VMware HA agent (vmware-fdm). Now, since that isn’t the job of Update Manager (afaik, vCenter handles that separately), I figured what the hell, let’s try and remove it as the ESX host was already in Maintainance Mode:

And guess what: after removing the package and then rerunning the Remediate task on the host, my troubles were gone.

hama_mce client for XBMC on Ubuntu

Well, I finally switched back to the official builds of XBMC (well, semi-official).

Now, since my previous and my current media center doesn’t come with a remote like, say a Boxee box, I built myself a custom one using a Hama MCE Remote Control and a Logitech Harmony 300. After trying a bunch of things (it actually works like a standard mouse), I stumbled upon this Trac ticket.

After first wrangling the sources into a patch, sometime ago when I switched to a new media center I started using the official builds as I mentioned earlier.

One disadvantage of the official builds is, that I can’t patch in the event client. Eventually I decided to write a small debian package containing everything the event client previously had.

Running XBMC/Ubuntu on Zotac HD-ID34

I recently bought a replacement for my aging Acer Revo R1600. I decided to go with the HD-ID34, since I didn’t wanna fiddle with buying a bunch of components. Installed a copy of Windows 7 on it (just to try it out …. :-P), and downloaded the Ubuntu 11.10 mini.iso. However the mini.iso apparently has issues (no clue which), basically it boots but gets stuck when bringing up the network connectivity (which is fucked up, since the mini.iso needs network connectivity to contiune the installation).

So I went a version back (11.04 – Natty Narwhal) and installed my stuff, however the audio didn’t work. So I kicked of a distribution upgrade, and about half an hour later that was finished. But still no audio …

1) The SPDIF channels were muted (no surprise there)
2) XBMC sent the audio do card 0, device 0 (which is basically /dev/null)

After playing around with the audio output settings (and trying different devices without any luck), I finally found a post for OpenELEC for the ZBOX (for an older version, but non the less, it still applied) describing what I had to configure.

Audio output = HDMI
Speaker configuration = 7.1 (or the what your receiver is capable of)

Audio output device = custom
Custom audio device = plughw:1,7

Passthrough output device = custom
Custom passthrough device = plughw:1,7

What’s just left now, is actually mounting the thing to the wall, since it looks just shabby sitting on my TV wall.

NetApp FAS/Data ONTAP public key authentification with CIFS/NFS license

Well as the title says, sadly we bought our FAS6210 without CIFS/NFS license. Thus, in order to create the folder structure/add the authorized_keys file, you’ll have to work for your money a little bit.

First, you need to run cifs setup / cifs passwd somewhere. I did it on our Data ONTAP simulator, which comes in handy for things like that.

You’ll get a cryptic looking password (no clue which format that is), looking like this: _OnWddr)xa.

Now, in order for the ftpd process to work, you need to create a /etc/passwd file. Usually the cifs setup would take care of that, but since we don’t own a CIFS license and I didn’t wanna add a trial license, I simply did what I described above on our simulator.

Now, open a SSH session with your filer. Create a new /etc/passwd file using wrfile. The new passwd file should look like this:

Now make sure, to replace the whole string in between the double dots with the one you got from the output of cifs passwd. After that is done, enable the FTP daemon using the options command:

Now, create your authorized_keys file somewhere (I exported my Public Key using PuTTygen), and from there open a ftp sessions with your root user on the filer. In the ftp shell run this:

The above example asumes that you created the authorized_keys file in the folder Desktop (that’s where my Desktop folder is, so replace it to suit your needs). Afterwards, disable the FTP daemon again:

And, tada … enjoy SSH password-less with your shiny public key.

UCS blades w/ Boot-from-SAN and AutoYaST

As I wrote before about enabling multipathing for the AutoYaST installation it’s about time I write this one here.

Sadly AutoYaST needs a little push in the right direction (as to where to actually put the root device), so here’s part of my AutoYaST profile for such a Cisco blade:

Now, the profile addition takes care of the placement of the root-device now (simply parses multipath -ll) and adjusts the pulled profile accordingly (/tmp/profile/modified.xml), which AutoYaST then re-reads.

Now, after installing the system, it’s gonna come up broken and shitty. That’s what the chroot-script above is for. This script looks like this (the original idea was here, look through the attachments):

What the script does, is 1) fix the occurances of /dev/mapper/, since this isn’t the proper way 2) create a multipathing initrd. Without the creation of the multipath-aware initrd the system will also not boot!