Archive for May, 2012|Monthly archive page

Installing IBM Data Studio Version 3.1.1 with Firefox 10 and above on Linux

The recent decision by the developers of Firefox to increase the major version number at an extraordinary rate has, I’m sure, caused problems for lots of developers trying to test for compatible versions. At my employer I know the developers now simply test for old versions rather than new ones.

IBM seem to have fallen foul of the changes too. I’ve just tried to install IBM Data Studio Version 3.1.1 on my desktop which runs a fairly standard CentOS 5.8. CentOS 5.8 comes with Firefox 10.0.4 at present. This is reasonably up to date so I didn’t imagine there would be issues so long as I got past any RHEL vs. CentOS tests in the installer. In fact, the whole install process broke very early. After much digging through the nested installation scripts, I found that the installer knew I was running Firefox but the version test reads:

supportedFirefoxVersion()
{
case "$*" in
*Firefox\ [1-9].*) return 0;;
*Firefox/[1-9].*) return 0;;
*Firefox*) return 1;;
*rv:1.[7-9]*) return 0;;
*rv:[2-9].*) return 0;;
*rv:*) return 1;;
Mozilla*\ 1.[7-9]*) return 0;;
Mozilla*\ [2-9].[0-9]*) return 0;;
*) return 1;;
esac
}

The problem of course is that this works for Firefox Version 1 through to 9, but fails for Version 10. I didn’t believe that Version 1 is OK but Version 10 isn’t!

If you hit this issue, expand the installer zip file and look for a file called <installerdir>/launchpad/browser.sh and edit the above subroutine. I simply changed it to allow any Firefox version:

supportedFirefoxVersion()
{
case "$*" in
*Firefox\ [1-9].*) return 0;;
*Firefox/[1-9].*) return 0;;
*Firefox*) return 0;; #### this line was changed
*rv:1.[7-9]*) return 0;;
*rv:[2-9].*) return 0;;
*rv:*) return 1;;
Mozilla*\ 1.[7-9]*) return 0;;
Mozilla*\ [2-9].[0-9]*) return 0;;
*) return 1;;
esac
}

The installation then runs through successfully.

DB2 – Needing more support?

IBM’s recent fanfare to announce the release of DB2 10 and the more muted news that DB2 9.1 reaches End of Support on the 30th of April this year, reminded me that the last time I looked, there was no End of Support date for DB2 9.7. Well, now there is a date; it is September 30, 2014. That’s pretty disappointingly close. It means that the most widely used version of DB2 9, and the one we use throughout our company, will get just over 5 years of support.

Today, 5 years of support for a major piece of software really isn’t very long at all. Most people wait for (at least) the first fix pack before even trying a test installation. There are often ‘a’ fix packs for DB2 which contain fixes for major bugs (I suspect there are often caused by the latest fix pack). You are well advised to wait a couple of months after a fix pack has been released before you try it just to see if there are fixes for the fixes. That reduces the useful support life from around 5 years to more like 4. From past experience, if you read the hype and put a major release of DB2 live within the first year of its General Availability (GA) then you’ll probably just about be the first person to do so.

With DB2 Version 8.1, as you applied fix pack 8 you reached Version 8.2 automatically. To get the full support life for DB2 Version 8 you simply started with Version 8.1 and kept applying fix packs as and when you were able or felt you needed them (fix packs are cumulative so you don’t have to take them all). With DB2 Version 9 all that changed. Going from DB2 Version 9.1 to 9.5 and then to 9.7 is a much bigger process. Each is a fresh install of DB2. So in terms of upgrade effort you can think of DB2 Version 9.1 as Version 9, Version 9.5 as Version 10 and Version 9.7 as Version 11 and so on.

I doubt very many people actually used Versions 9.1, 9.5, 9.7 and 9.8 on the same system. Version 9.5 seemed to get a fairly cool reception as it came only 15 months after Version 9.1, but Version 9.7 seems to have had a good take up, at least according to a DB2 Night Show poll I listened to last year. Version 9.8 is of less interest to most people because it’s major enhancement (the pureScale feature) is fairly specific.

Someone installing DB2 Version 9.7 just 3 months ago gets less than 3 years support. That’s considerably less than most people keep server hardware. If the database server is virtualised then there’s no reason for the server to ever need upgrading for the sake of hardware. Operating system vendors have really taken this to heart. Red Hat (our operating system of choice for DB2) are now promising 10 years of production support for RHEL 5. That gives you over 6 years of support *after* the release of RHEL 6. If IBM were to do the same, that would mean IBM extending DB2 Version 9.7 support by at least another 3 years.

Unless you use DB2 Express-C, DB2 is an expensive bit of software. It is certainly the most expensive software we use. An upgrade cycle for DB2 for all our systems takes about 8 to 9 months (I’ve done it twice). The effort involved can only be justified when we are refreshing hardware and we can do full parallel testing. It is a huge effort for us that is planned up to a year in advance. In a virtualised environment where hardware refresh ceases to be an issue, I just can’t imagine potential customers choosing to use software with such a short life expectancy.

Loss of network interfaces after applying CentOS kernel 2.6.18-308.4.1 on ESXi 4.1 Update 2

One of our hosting company requires us to keep up to date with RHEL 5 kernels on a server they support. As this is a production machine it means that when a new kernel is available I start applying it to development machines and migrate the upgrade through to production over a period of 3-4 weeks.

 

The first stage of testing is to apply the kernel on various ESXi hosted VMs and a couple of real servers, most of which run CentOS 5. The most recent kernel 2.6.18-308.4.1 seems to work OK, but on all of the ESXi hosts there seems to be an issue with the virtual network interfaces. In all cases I use the VMXNET 3 adapter type. The hosts are running ESXi 4.1 Update 2 with a number of HP provided bundles.

 

After the application of the updates and the subsequent reboot, only the local loopback network interface starts up. I’ve seen various suggestions as to what may be the cause but I can’t comment on those. To fix the issue, my initial test was to re-install the VMWare Tools which seems to do the trick. Having got that far, on a different guest I tried just rerunning vmware-config-tools.pl. That seems to solve the problem immediately (just restart the network service). The fix appears to be persistent across a reboot.