Thursday 16 June 2011

Oracle client 11g installation under wine

I am a steadfast Fedora user both at home and at work. However, most of my colleagues tend to use Ubuntu and one of the problems I have come across a few times is the inability to install the Oracle client software under wine in Ubuntu. It all works fine under Fedora, so why does it fail on Ubuntu with the error message "java.lang.NullPointerException at oracle.sysman.oii.oiin.OiinNetOps.addNICInfo(OiinNetOps.java:109)"? I set out to find out.

After verifying that the installation error is reproducible and not just caused by a weird configuration specific to a single machine, I poked around the Oracle installation files to try to get an idea about how this error was occurring. Turns out that it is quite easy to reproduce. The following Java class does exactly that:

import java.net.InetAddress;
import java.net.NetworkInterface;

public class Test
{
	public static void main(String[] args)
	{
		try 
		{			
			InetAddress ia = InetAddress.getLocalHost();			
			NetworkInterface nic = NetworkInterface.getByInetAddress(ia);			
			String nicName = nic.getDisplayName();			
                        System.out.println(nicName);
		} 
		catch (Exception e) 
		{			
			e.printStackTrace();
		}	
	}
}


The above code runs perfectly fine on a Fedora installation but generates a NullPointerException on an Ubuntu installation at the point where nic.getDisplayName() method is called. This is caused by an oddity in network configuration of Debian based distributions. To avoid problems with fully qualified domain name resolution, Debian based workstations automatically get an entry in /etc/hosts of the form:
127.0.1.1  localhost.localdomain


Note that this is not the loopback address 127.0.0.1. Therefore, the localhost IP address ends up resolving to 127.0.1.1 - a valid "non-special" IP address. This in turn causes the above Java snippet to fail because quite correctly, it cannot detect a NIC bound to 127.0.1.1 on the local machine.
The solution is to either delete the above line from /etc/hosts or to add a new line as follows:
echo `hostname -i` "  "  `hostname -f` >> /etc/hosts



The Java code now runs without any exceptions natively, but under wine, it still causes the NPE. It appears that whatever native library used by Java (javanet.dll?) is not functioning properly under wine. In fact, under wine, Java cannot see any network interfaces at all. This can be proven by running the following piece of Java code under wine:

public class Test 
{
	public static void main(String[] args)
	{
		Enumeration nicList;
		try 
		{
			nicList = NetworkInterface.getNetworkInterfaces();		
		    while(nicList.hasMoreElements())
		    {
		    	NetworkInterface nic = nicList.nextElement();
		    	Enumeration ipList = nic.getInetAddresses();
		    	while(ipList.hasMoreElements())
		    	{
		    		System.out.println(nic.getName() + "-" + ipList.nextElement());
		    	}	    	
		    }
		} 
		catch (SocketException e) 
		{			
			e.printStackTrace();
		}
	}
}



So how does the Oracle installer run fine under Fedora and not under Ubuntu? I can't find a logical explanation for it. The only difference seems to be that the version of wine in the Ubuntu repositories is 1.2.x while Fedora ships with 1.3.x. (As always, Fedora ships with the bleeding edge development version of wine whilst Ubuntu ships with the stable release). To test whether version makes a difference, I uninstalled the stock wine installation from Ubuntu, downloaded the latest wine source (1.3.22) and compiled it as follows:

sudo apt-get -y remove wine && sudo apt-get autoremove
rm -rf ~/.wine
sudo apt-get -y install flex bison libx11-6 libx11-dev libfreetype6 libfreetype6-dev
wget http://ibiblio.org/pub/linux/system/emulators/wine/wine-1.3.22.tar.bz2
tar xvf wine-1.3.22.tar.bz2
cd wine-1.3.22/tools
./wineinstall


On my dual core Laptop with 2GB of RAM, compilation took about 1 hour.
Trying to run the Oracle client installer with the newly compiled version of wine still generates the old NPE, BUT, the installer doesn't crash there like before and actually continues to work! There's no logical explanation that I can think of for this strange behaviour, and frankly I am not too bothered about it. The important point is that I can finally mark this problem as solved and get some closure. :)

No comments: