If you’d like to create your BoMC iso using Ubuntu , you might’ve noticed that BoMC doesn’t support it.

I’m on 10.04 and found that using the RHEL5 binary worked. At the time of writing, the name of the file is ibm_utl_bomc_3.00_rhel5_i386.bin . I tried the RHEL6 one first and it complained about a missing libssl library (libssl.so.10) so I would guess if you are on a newer version of Ubuntu, you should use this one instead.

You might see this error when executing it, and it will cause the downloads to fail

Simply execute this to create an Redhat release file at /etc/redhat-release , and this will make BoMC work.

Then simply execute it like this, put in your machine details, and out comes the iso:

This particular time, this error cropped up when trying to run Eclipse Memory Analyzer over a X11 Forwarding session using SSH. Eclipse would throw this error and fail to start.

To fix it, run

If you don’t have dbus-uuidgen , it’s in the dbus package, which can be installed by issuing yum install dbus (of course!).

Happy weekend!

Boom!

#Original Post#
We’re working on a boot from SAN ‘modernization’ project at the moment. Which is another way to say we’re getting rid of it. It’s way too complicated! And if the SAN goes down, all the boot partitions go with it. This just introduces an extra dependency that can completely nullify any fault tolerant or HA strategies that you may have in place in the vSphere layer. No prizes for guessing who this has happened to recently!

What to do instead? The new HS22V blade systems we are using have a tiny little usb port on the motherboard where you can install a USB key. Load ESXi on it, and you’re golden.

So I need to make a list of which hosts need fixing up and which are booting from usb already or are using local storage. We’d started this process recently but want to step it up now. But which ESXi machines in the farm are booting from what ? How can you tell?

With fdisk of course – simply enable Remote Tech Support mode (see here for details) and ssh into your host.

Run

and look for the ‘*’ in the boot column. That’s the partition that ESXi is booting from. If you see a device called /dev/disks/mpx.vmhba32:C0:T0:L0 , you’re booting from usb. If the device is something more like /dev/disks/naa.600508e000000000194a56b4310b4804 you are booting from SAN or a local disk.

Here’s the fdisk output for my usb stick.

So to try to fix this situation, I had a really good hunt on the internet for sites selling a battery specific to this model. The best I could find was a company that would sell me a whole new NVRAM IV card for $2500 USD! At least it had a refurbished battery, but it was a little more than I wanted to spend.

I ended up taking the battery to a auto battery shop on a lark and the guy there reckoned he could sort me out. I left the original one with him for around two weeks. He ended up selling me a Sanyo SCB-53P0941 . It cost about $80 bucks. It was a little bit bigger than the original one and wouldn’t fit on the NVRAM IV housing, so I lashed it in place with a cable tie.

As you can see from this horrible photo, I have an old iPhone.

It took about a day to charge up but now it looks like things are good, as you can see by the log below:

The original battery looked like it had a chip in it, so I thought it might need to grafted on to the new battery, but it’s pretty stock. Now you can sleep at night, knowing that you won’t lose any data. Obviously, this is very dodgy and you shouldn’t connect some battery that a random dude in an auto parts store sent you. Our NetApp Filer (FAS960C) is so old that it is out of support, so I had nothing to lose, and the information for a blog post to gain.

But my Was Password was correct. I had set it myself and just used it to log into the admin console.

The key is the “MethodDelegat” part of the log message. This column is the source of the log message. “Delegate method” made me think of bundled applications that use the RunAsRole . The pznscheduler application runs on a schedule, and sure enough also has a RunAsRole associated with it.

So what has happened, is that the WAS password has changed but the password is also saved with the pznscheduler application, and that saved password hasn’t been changed. Quite simply, there is a mismatch. This can happen on 6.1 and 7.0, and may also be related to the Portal Admin Password – it just depends which user is mapped as the RunAsRole . There are more applications that use the RunAsRole for Portal 6.0 .

For 6.0 here are the default out of the box applications you need to worry about when changing the password. LWP_TAI, pznscheduler, LWP_CAI, LWP_Security_Ext.

Of course, you may have other custom applications you need to worry about. The LWP apps use the Portal Admin user by default, so that’s why I didn’t have to change them.

For 6.1 you should check pznscheduler and CatalogHandler and for 7.0 the pznscheduler application is the only one you need to worry about.

So to fix it up, if you log into the WAS Admin Console and look for the pznscheduler app in the list of Enterprise Applications, you will see the “Map RunAs roles to users” link like in the picture below.

Then in the next dialog, reenter the new password.

This dialog can be a bit funny so you may have to play around with it a bit. Restart Portal and the error should be gone!

So I wanted to add an rpm for the Rational Build Forge agent to my CentOS install tree. The machine that hosts my RHEL/CentOS/Fedora repositories is an old Fedora 10 machine. One of the reasons why I blog about this stuff is to keep notes, so when I forget how to do something, it is easy to go back and copy and paste the esoteric command I am looking for. So I looked up the old post on how to add packages to a repo and after copying in the Build Forge rpm, I ran the following command:

Then I edited my kickstart file to include the new package and tried to run the install. Immediately I got the following error:

The command createrepo looks over your rpms and creates a bunch of metadata for them that yum reads when deciding to do updates. This metadata is saved in a folder called repodata, and I thought that the resulting folder might’ve been at the wrong tree. So I kept rerunning the install with the repodata folder in different places, all the while watching the apache logs to make sure the installer was hitting the right places and not getting too many 404 errors. This didn’t seem to be going anywhere until eventually I found an interesting bug report here.

Apparently the createrepo command has changed at 0.9.7. The default checksum routine that it now uses is sha256, where before it just used sha. You will recall that the server I am using as a repository is a Fedora 10 machine. The CentOS/RHEL version of the installation engine (named anaconda) doesn’t understand sha256, only the older sha checksum routine. So when the CentOS version of anaconda hits a repodata folder generated by createrepo running on Fedora 10, it just sees it as garbage.

The workaround is to force createrepo to use the sha algorithm, like so:

If you had a CentOS/RHEL only environment, this obviously wouldn’t happen, so this problem is quite localized. And will almost definitely go away with RHEL6, because that version of anaconda will be able to understand sha256.

Luckily there is a workaround. Go into the ‘edit settings’ screen for the Solaris guest and click the options tab. Change the Guest Operating System Version to Solaris 10 32 Bit, instead of 64 bit. Then the boot goes more like this:

I made a screen cast of the slow boot as well, but it literally is the same thing as above, except it just goes on for 5 minutes. It could be the most boring video on the internet. The fast boot video above is probably the second most boring video on the internet! It’s just a hard problem to explain in words.

This setting doesn’t mean that you’ll be running a 32 bit OS or anything either – as far as I can tell it doesn’t do anything besides fix the slow boot problem!

Peter commented on my post about installing Portal on Ubuntu, and my response got a bit long, so I thought it might might a good post by itself.

Peter writes:

got thru the install but WCM doesnt appear in the admin (for libraries) or UI. can you confirm you can see the WCM stuff in yr portal? and maybe share wpinstalllog.txt with me?

Hey Peter,

When WCM doesn’t come up, it could be a couple of things :

The simplest explanation is that you’ve selected the ‘admin’ install in the setup wizard, so you get a blank Portal out of the box. You can validate this in the PortalServer/wps.properties file, the property WPInstallType will tell you what sort of install you have done. To add WCM to an admin install, run the task:

Log into Portal and you should see the WCM stuff under the content tab.

It could also be that you have installed the server version of Portal. Check the file PortalServer/wps.properties and check the value of WPFamilyName . It should read WPFamilyName=content. If it says something else you’ve installed the ‘server’ version of the software – which doesn’t include WCM. This is the worst problem because you basically have to reinstall again – there’s no way to add WCM to a server version. You can see which downloaded files make up each version of Portal in the download documents for each release. The download document for the server version is here, and the content version is here. I hope this isn’t your problem

With 6.0 (not valid for 6.1, but I’ll include it anyway), on Linux you can get a problem where the WCM authoring page and portlet are there, but don’t render properly – the inside of the portlet is just blank. I’ve covered this before in this post.

Let us know how you go Peter!

Anyway, when trying this out, I got this error when starting Apache. This error is pretty straightforward :

This simply means that the wrong version of the plugin is installed. I’m using 64 bit linux and 64 bit Apache, but the 32 bit version of the WAS Plugin. Reinstalling the 64 bit version made it work fine.

The first thing to do when debugging a WAS install problem is to look at the logs in ~/waslogs . These indicated the following problem:

My system had heaps of space on it! Surely the installer wouldn’t even run if there was 0 MB free! The method that the installer used to determine how much disk space was free was failing. But how does the installer figure out how much disk space is free? After lots of poking and prodding around I stumbled on dtrace. I had heard of it before, but never had the opportunity to use it. Dtrace is a mechanism to instrument and probe the tiniest little interactions on a Solaris/BSD/OSX machine. Being so powerful, it has a steep learning curve. This collection of handy dtrace oneliners was really helpful.

I kicked off the WAS install portion of the Portal install and ran this dtrace command in another window.

It captured each file interaction that occurred when running the install. Luckily the WAS install failed after about 30 seconds, so there wasn’t too much data to wade through.

Here is the dtrace log (trace.log from the command above). Something called gushellsupport.sh is calling df (standard unix disk free command). This must be how the installer determines how much disk space is free. The column on the left is the pid of the install process (which is java) . The library files on the far right are what is being called by each executable; the next column over to the left.

This script, gushellsupport.sh, is owned by InstallShield so I can’t publish the contents of it. But it has a diskcheck function in it that relies on ‘/usr/xpg4/bin/df’ which I didn’t have installed. Solaris has many different versions of the same tools that are left behind for backwards compatibility. When installing this system initially, I used the “Core System Support” option in the Solaris install to build a lean, quick machine. Unfortunately it didn’t come with this legacy version of df.

df belongs in a package called SUNWxcu4. To install it, mount your Solaris CD and go to the directory Solaris_10/Product/ . In there, copy the subdirectory ‘SUNWxcu4′ to /var/spool/pkg and run

If you rerun the install again it’ll work since gushellsupport.sh is calling the correct version of df. Talk about obscure huh?