Glassfish Admin Console fix after 3.1 upgrade

After upgrading my GlassFish server from 3.0 to 3.1 using its updatetool the admin console was no longer working. When accessing the admin console, I only got an empty page. In the domain server.log file I noticed the following error:

[#|2011-05-07T20:58:45.708+0200|WARNING|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=102;_ThreadName=Thread-1;|ApplicationDispatcher[] PWC1231: Servlet.service() for servlet FacesServlet threw exception java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event1'.
        at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
        at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
        at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate(LayoutComponent.java:348)
        at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:288)
...
  

After a little searching I found that this issue was apparently already reported and fixed (GLASSFISH-16087). Unfortunately on my server the problem still existed and the suggested workaround didn’t work for me. Fortunately directly changing the domain’s config/server.xml file directly did work. I shutdown Glassfix and lookup the following entry:

    <property name="restAuthURL" value="http://localhost:${ADMIN_LISTENER_PORT}/management/sessions"/>
  

as I understood from the reported issue the server was no longer listening to localhost I changed it into (please note I added both the hostname and changed the protocol to https):

    <property name="restAuthURL" value="https://prod.glassfish.mydomain.tld:${ADMIN_LISTENER_PORT}/management/sessions"/>
  

and after restarting my Glassfish server the admin console worked normally again.

Started a new challenge

Today I started a new challenge as senior manager with one the largest global Consultancy and System Integration practices. The first day was already very promising after working for a very small firm. A lot of things have been organized and people are taking care of it, instead of having to sort out things yourself. I am currently going through a 3-day introduction and hope to start my first assignment soon. Anyway the coming months will be very interesting…

Great… my employer declared bankrupt

I was informed today that my employer was declared bankrupt today by the court in Amsterdam… the interesting part is that 3 out of the 4 employees were still working on customer projects with contracts for between 1 and 6 months…

This definitely felt like a strange situation to be in, I definitely need to think this over to decide how to move forward. Later more…

Migrated my legacy Debian Linux server to ESXi

Today I managed to migrate my legacy Debian Linux server to a VMWare guest running on my temporary ESXi server without any problem. The downgrade from grub2 to grub (see Downgrading grub2 to grub legacy on Debian) apparently did the trick and after a few hours the migration complete successfully.

I must say I am pretty impressed by the functionality offered by VMWare vCenter Converter (Standaline). Not only does it allow one to migrate physical and virtual machines, when converting a physical machine it also gives you full control over the partitions created.

Tomorrow I will try to get VMWare ESXi running on my Dell PowerEdge 2850 server (apparently that old model still is supported by ESXi 4.1)…

Downgrading grub2 to grub legacy on Debian

Today I attempted to migrate my legacy Linux server to a VM on my ESXi server using VMWare vCenter Converter Standalone. Unfortunately the process failed after about 4 hours of processing with the error message “__FAILED: An error occurred during the conversion.__”… well, that was very helpful!
Fortunately the VMWare Converter allows to save the logs, in which after a bit of digging I found the following error:
{code}
[2011-01-01 22:17:14.338 10552 error ‘App’] [task,344] [LRO] Unexpected Exception: converter.fault.CloneFault
[2011-01-01 22:17:14.401 10552 info ‘App’] [task,373] [task-5] — ERROR — Convert: converter.fault.CloneFault
(converter.fault.CloneFault) {
dynamicType = ,
faultCause = (vmodl.MethodFault) null,
description = “GrubInstaller::InstallGrub: /usr/lib/vmware-converter/installGrub.sh failed with return code: 127, and message:
/vmware-updateGrub.sh: line 37: grub: command not found
Error running GRUB
Error running vmware-updateGrub.sh through chroot into /mnt/p2v-src-root
“,
msg = “”,
}
{code}
Apparently it attempted to make the converted VM bootable by executing grub again. This failed because my Debian system (running testing for a long time) had migrated to grub2 ages ago. Since googling didn’t render any hints and it would be a temporary move anyway as I am migrating everything off to other servers, I decided to downgrade grub to the legacy grub version available. Below is a description of the steps to achieve this.

—-
1 Downgrade from grub2 to grub legacy
Before you start make a backup of the current grub2 configuration with:
{code}
sudo tar -cvzf /boot/grub2-backout.tar.gz /etc/grub.d /boot/grub
{code}
~~Please note that I am using sudo to execute commands as root. If you don’t use sudo, simply login as root and remove the sudo from each command.~~

To get starte with the downgrade, get the list of grub packages installed as you need to remove them all (sounds more dangerous than it is). Get the list and store and show it with the following command:
{code}
dpkg -l grub\* | egrep “^ii ” | tee /boot/grub2-backout.list
{code}
which on my system gave:
{code}
ii grub 0.97-63 GRand Unified Bootloader (dummy package)
ii grub-common 1.98+20100804- GRand Unified Bootloader, version 2 (common
ii grub-doc 0.97-63 Documentation for GRand Unified Bootloader (
ii grub-legacy-do 0.97-63 Documentation for GRUB Legacy
ii grub-pc 1.98+20100804- GRand Unified Bootloader, version 2 (PC/BIOS
{code}
With the above 2 pieces of output in /boot/ you should be able to recover and rollback the procedure below in case anything goes wrong. See under Rollback below for the steps to revert this procedure.

First purge the current grub installation (please note this __is__ dangerous as it makes your system unbootable) and install the “~~legacy~~” grub package. Please be aware that the following statements will not just remove the packages, but also your all configuration (that’s why you needed the backup).
{code}
sudo apt-get remove –purge `dpkg -l grub\* | egrep “^ii ” | cut -d\ -f 3`
sudo apt-get install grub-legacy
{code}
The first line above automatically deinstalls all grub packages and their configuration automatically. You can also specify yourself which packages to remove by writing your ~~apt-get remove~~ statement yourself, just make sure you get rid of everything!

Next let grub install itself on your MBR of your primary harddisk ~~/dev/sda~~ in my case with:
{code}
sudo grub-install /dev/sda
{code}
which should give output like:
{code}
Searching for GRUB installation directory … found: /boot/grub
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install’.

(hd0) /dev/sda
(hd1) /dev/sdb
{code}

If the output is similar (the list of devices is obviously depending on your system’s configuration), you have succesfully installed grub on your harddisk, now it is time to let grub regenerate its configuration with the following command:
{code}
sudo update-grub
{code}
Which should produc output similar to
{code}
Searching for GRUB installation directory … found: /boot/grub
Searching for default file … found: /boot/grub/default
Testing for an existing GRUB menu.lst file …

Generating /boot/grub/menu.lst
Searching for splash image … none found, skipping …
Found kernel: /boot/vmlinuz-2.6.32-trunk-686-bigmem
Found kernel: /boot/vmlinuz-2.6.32-5-686-bigmem
Updating /boot/grub/menu.lst … done
{code}
If your output again looks similar (obviously the list of kernels may differ), congratulations! You have successfully downgraded to grub.

Please note that the grub boot menu created has been automatically generated, so any customizations you made to the boot menu are lost. In case you originally had made customizations made in your menu.lst before you upgraded to grub2, you may be able to see those by executing
{code}
diff -wu /boot/grub/menu.lst /boot/grub/menu.lst_backup_by_grub2_postinst | more
{code}
Putting them back in ~~/boot/grub/menu.lst~~ is unfortunately a manual step, but doable if you have something to start with.

Now it’s time to test the downgrade by rebooting… fingers crossed!

Now I still need to retry to virtualize my legacy Linux server, but that’s something for tomorrow…

—-
1 Rollback
In case anything goes bad during your downgrade, you should be able to roll things back with the following three commands:
{code}
sudo apt-get remove –purge `dpkg -l grub\* | egrep “^ii ” | cut -d\ -f 3`
sudo apt-get install `cut -d\ -f 3 < /boot/grub2-backout.list`
sudo tar -xzf /boot/grub2-backout.tar.gz
{code}

Happy New Year!

A happy 2010 to everyone! I wish you all the best for this year, all in good health. Enjoy the festivities and make it a great start of the new year.

During this year do have the intention to make frequent posts to this blog, you will be the judge of whether I will be able to keep that promise you (and feel free to remind me of it!).

now back to the party…

Configuring IP aliases cleanly on Debian

I like using different IP addresses for different services on my internal network. Thanks to RFC1918 this is no problem at all, as there are several network ranges dedicated for private networks. Using a firewall with that supports NAT (something people didn’t think of yet when writing the RFC) gives a maximum amount of flexibility when moving services around between servers and keeping things simple.

Setting up network interfaces with multiple interfaces is not really supported by Debian’s ifupdown tools. Yes you can do this easily by adding the necessary calls to the ip utility to your network interface definitions, but this is ugly and error-prone. That’s why I came up with the attached script, which adds support for the keyword aliases to your /etc/network/interfaces configuration so you can define additional IP addresses like this:

{code}
iface eth0 inet static
address 192.168.0.2
netmask 255.255.255.0
broadcast 192.168.0.255
aliases 192.168.0.100 192.168.0.101 192.168.0.102
192.168.0.103
{code}

Bringing up or down the interface will automatically add or remove the aliases. Please note that aliases added this way should always be on the same network as the primary address of the interface. To have multiple addresses on the same physical interfaces you need to use vlan’s or alias devices.

To install the script on you Debian host, simply save the script attached to this post as a file called aliases in your current directory and execute the following commands as root:

{code}
chmod 755 aliases
chown root.root aliases
cp aliases /etc/network/if-up.d
ln -s ../if-up.d/aliases /etc/network/if-down.d
{code}

And add your aliases to your devices in /etc/network/interfaces

Welcome to my relaunched Blog

Welcome to the relaunched version of my personal blog. After little over 18 months of inactivity I have decided to start all over. The key reason for this is that I am in the middle of a complete overhaul of my network and server infrastructure. After over 6 years of organic growth and adjustments things just need a cleanup. During this I expect to have to sort out a lot of stuff to make things working that I plan to write about here, so this place will probably be mainly technical in the beginning. I do expect to start writing about non-technical stuff too here (in due time) when I feel sharing my opinion about something may make a difference.

The old blog that I started more than 5 years ago on this address has moved here, just in case there is still something of use for anyone there. I do expect to go through that in due time, move still relevant articles/information over to this one (obviously in an updated fresh post) and drop the old (no longer supported) application.

Even though there are a lot of fantastic (even free) services for hosting your private blog, mail and other infrastructure "in the cloud", I have consciously decided to continue hosting and operating my blog, other web services and e-mail myself. The key reason for this is that it just gives you a lot more flexibility and I still think it’s fun to be busy with this stuff (bear in mind, I am no longer allowed to play with stuff that much during my day job). Another important reason for this decision is that I do not want to become dependent on things I cannot control or press the reset button for myself. I once read a great summary on Chris Brogan’ blog of what happens if Google decides to block your account. Yes this is definitely an incident, but I am just not sure what Google and all free providers competing with them are up to (you may call me paranoid, that’s fine though it will make me think you are naive). In the end they will have to make money somehow and if they fail, simply close down services or turn the service in a paid or ‘fremium‘ variant, leaving you little choice how to proceed.

For this blog I have decided to use Pebble, a java blogging system, running on a Glassfish v3 Open Source Edition application server as it suited my needs. The hosting server is a VM running Debian Linux on VMWare ESXi (the free version) This is all still an experiment and in its early stages (hence the default layout and theme, that will change soon, don’t worry).

More later… feel free to comment!