UnixBench is a super cool utility that performs a series of benchmark tests and provides some fairly comprehensive results against a baseline system. It takes a while to run – especially if you have multiple CPUs. Mine took about 30 minutes.

I wanted the best (or lets say most representative) score I could get so I killed everything and effectively booted into runlevel 3 – which is almost everything except X. So here are my results…

unknown configuration node //DB2

At this point i was thinking how the hell did VirtualBox know about my DB2 installation – assuming that my DB2 database installed on that VM was an issue. A little confusing here too given that i would get the VM window and then it would just close so it wasn’t getting anywhere near starting the OS – WindowsXP.

Anyway a bit of digging about and then this:

takisd@fitter:~> VBoxManage getextradata WindowsXP-1 enumerate
Key: GUI/LastCloseAction, Value: powerOff
Key: GUI/LastGuestSizeHint, Value: 640,480
Key: GUI/LastNormalWindowPosition, Value: 1437,47,640,527
Key: GUI/LastWindowPostion, Value: 1422,111,1224,867
Key: GUI/MiniToolBarAlignment, Value: bottom
Key: GUI/MiniToolBarAutoHide, Value: on
Key: GUI/SaveMountedAtRuntime, Value: yes
Key: GUI/ShowMiniToolBar, Value: yes
Key: VBoxInternal/Devices/pcnet/0/LUN#0/Config/DB2/GuestPort, Value: 50000
Key: VBoxInternal/Devices/pcnet/0/LUN#0/Config/DB2/HostPort, Value: 50000
Key: VBoxInternal/Devices/pcnet/0/LUN#0/Config/DB2/Protocol, Value: TCP
Key: VBoxInternal/Devices/pcnet/0/LUN#0/Config/Firebird/GuestPort, Value: 3050
Key: VBoxInternal/Devices/pcnet/0/LUN#0/Config/Firebird/HostPort, Value: 3050
Key: VBoxInternal/Devices/pcnet/0/LUN#0/Config/Firebird/Protocol, Value: TCP
Key: VBoxInternal/Devices/pcnet/0/LUN#0/Config/Oracle/GuestPort, Value: 1521
Key: VBoxInternal/Devices/pcnet/0/LUN#0/Config/Oracle/HostPort, Value: 1521
Key: VBoxInternal/Devices/pcnet/0/LUN#0/Config/Oracle/Protocol, Value: TCP
Key: VBoxInternal/Devices/pcnet/0/LUN#0/Config/SQLServer/GuestPort, Value: 1433
Key: VBoxInternal/Devices/pcnet/0/LUN#0/Config/SQLServer/HostPort, Value: 1433
Key: VBoxInternal/Devices/pcnet/0/LUN#0/Config/SQLServer/Protocol, Value: TCP

…where WindowsXP-1 is the name of the virtual machine.

So all my intalled DBs on that particular VM had a setting on them for respective ports. I use most VMs for testing against various databases for various apps and mainly for Execute Query.

I vaguely recalled setting these some time ago – probably as a network response for forwarding – either way i didn’t really remember and resetting these with empty values fixed the problem like this:

VBoxManage setextradata WindowsXP-1 "VBoxInternal/Devices/pcnet/0/LUN#0/Config/DB2/GuestPort"

…and so on for the other nodes. Restarting the OS worked just fine and I now have my VMs back. Not sure if this documented anywhere by Oracle – quite the gotcha for seemingly simple upgrade.

…and here i was thinking WTF did Oracle do now…

Frankly, I don’t know for sure which particular package was the culprit. There was nothing logged that pointed to any issues – indeed any and all logs I went through indicated all was well. I also could not find a single thing online that resembled what I was experiencing. I have managed my own servers for about 10 years now. I’m far from a competent Linux admin but I usually know enough to get by or just enough to get out of trouble, so I became severely frustrated when a seemingly simple upgrade could result in all my sites being made unavailable.

I started by stripping back my Apache install to next to nothing – which brought back a single static site i set up as a test. Then line-by-line I reintroduced various modules, includes and various directive lines. At the very bottom I had my mod_jk include – which by the way serves over half of my sites.

As soon as I reintroduced mod_jk it dumped. After much fiddling, rebuilding mod_jk, installing from rpm, downgrading packages, tinkering with various mod_jk parameters, using strace on startup (great article on debugging with strace here) I finally put it down to the inclusion of the following:

<Location /*/META-INF/*>
    Deny From All
</Location>
<Location /*/WEB-INF/*>
    Deny From All
</Location>

The above tells Apache as a global directive to disallow any access to the protected Java web application directories WEB-INF and META-INF.

The lines above have been a part of my apache/mod_jk config for as long as I remember. I haven’t yet had a good look as to why the above is no longer acceptable – I’m just relieved to have everything back up. I would have expected Apache to complain about configuration errors, issue the relevant message and fail to start just like it does for most other issues. Not so in this case and furthermore it silently takes down the whole server instance.

I didn’t find any references to this anywhere – perhaps this will help someone equally confused as I was

After some serious digging (it drove me a little nuts) and a plethora of less than helpful tips and references I stumbled across this:  Webalizer – Web Server Statistics “how to”.

Apparently it has something to do with the way browsers accessing the site report their name and that some have multiple parens (‘(‘ and ‘)’) in it. This had the affect of confusing the mangle agent that reports agent names accessing the site. The fix was specifying a MangleAgents value other than 1 (zero or 2 worked fine). I set it to 2 and all is well – I now have all my stats working again.

After a little bit of stuffing around to get the bridge networking up and running (vmware did this for you on startup quite nicely), i’m all good now with a couple of guest operating systems installed and running with no issue. Some useful docs and info for setting up with Debian can be found on the Debian Virtual Box wiki here. A huge plus is also that it comes with a neat script to build the vbox module for the running kernel.

Overall, so far VirtualBox is more than a suitable replacement for vmware. Give it a shot if you haven’t already.

In any case take a look here: http://groups.google.com/group/vmkernelnewbies/web/how-to-install-vmware-in-2-6-26-linux-kernel

Theres a new vmware-any-any patch that fixes the build error under kernel 2.6.26.

We are trying to tell the system that the hardware clock is set to UTC.

Edit the following: /etc/default/rcS. Modify UTC to read UTC=yes (or no depending on what you are trying to achieve).

Some additional good resources for time:  Debian Administration and the Debian online docs.

Attempt to build nvidia module for kernel 2.6.25.1 failed. The nvidia installer needs to be patched as described here. After this. just build and install as normal and all is well.

A bit of digging uncovered this: http://lenrek.wordpress.com/2008/04/24/vmware-105-and-kernel-2625/. It got me up and running quite nicely.

Small point to note – i used to apply the vmware-any-any-update-116 patch and then run /usr/bin/vmware-config.pl. Patches for the 2.6.25 kernel do not apply to a patched vmware-server install. i ran without the any-any patch and all worked fine nonetheless.

Finally, as i normally do i executed the following to ensure correct operation of the console:

cd /usr/lib/vmware/lib/libpng12.so.0
mv libpng12.so.0 libpng12.so.0.old
ln -sf /usr/lib/libpng12.so.0 libpng12.so.0
cd /usr/lib/vmware/lib/libgcc_s.so.1
mv libgcc_s.so.1 libgcc_s.so.1.old
ln -sf /lib/libgcc_s.so.1

Check it out here… well worth a look especially if you run Gnome or XFCE.