I've decided I'm sick of Windows. I used to use Linux as my primary OS with no Windows, but since joining the corporate world, especially in South Africa, I've been forced into using Windows against my will.
This is for various reasons, and despite my many attempts over three years. There were lots of little battles along the way, like driver support for the laptop I was using etc. Those have mostly been won. However, there are some big battles left, and I plan on tackling them. This is the first of my 'Corporate OSS' entries, where I will document my solutions to these problems, if they exist.
First on the menu is connecting to the network believe it or not.
My company uses PEAP on all it's network points. While great for security, this has posed some problems. The first is that support for wired PEAP in ubuntu is poor at best. I eventually managed to work out what was stopping me. My company uses the Active Directory computer account to authenticate via PEAP. This makes sense so that the computer can get on the network before a user logs on and talk to AD for authentication. However, this makes it difficult for me, as I don't have access to my computer account's password, and Active Directory changes it regularly. I have logged a call to enable PEAP auth for my user account and spoken to people nicely, but the chances of getting this resolved without large amounts of effort are slim.
This leads me to my solution. I am rarely in the office, and spend most of my days connecting in via a client's network, Wifi or HSDPA. However, to get access to those juicy internal network resources, I need to use our corporate VPN. For tips on getting the HSDPA working, you can check my prior entry, although it is hardware specific.
We use the Aventail Connect VPN from Sonicwall. A quick google shows me that there's a linux version of the client. An equally quick e-mail to our VPN support guys gets me an even quicker 'linux-violates-corporate-standards' response, moving on. On a whim I type the URL for the VPN concentrator into my browser. Lo-and-behold, it has a great web-based interface. After logging in I can download the linux version myself. Unfortunately, an ancient version 8 of the client was provided.
Now that I knew what it is called, I do some more googling. Unfortunately Aventail doesn't put a version number in the initial file, so after downloading 6 copies, I strike it lucky and find a version 9. To save you the same trouble, you can get your copy here. Bear in mind this is commercial software and you must have a license to use it.
After unpacking it, you are supposed to run the installer with 'sh install.sh' however, they've made it bash dependant and Ubuntu's default sh, dash, won't do the trick. Edit install.sh to update the first line to point to bash. It will run, and bomb out with an error about missing libraries. Ignore it, it is installed.
However, this is where it gets ugly. The libraries it was missing were libssl.so.0.9.7 and libcrypto.so.0.9.7. These are provided by the libssl0.9.8 package. However, you will need to create your own symlinks to libssl.so.0.9.7. Don't bother, it won't work. There is a problem with the default Ubuntu Intrepid libssl0.9.8 which makes Aventail bomb out on the handshake for no explainable reason. Thanks to Benjamin Smith's work for identifying the problem and solution.
You need to install a fresh version of the openssl libraries. Benjamin provides instructions on how to do this. However, I encountered some complexity.
I am using a 64bit version of Ubuntu, however, the Aventail connect is looking for 32bit versions of the libraries. So we need to make sure the new libs end up linked to /usr/lib32 (/use/lib if you're on a 32bit OS). Second, openssl does not like compiling 32bit libraries on a 64bit system. It will happily insert any -target, -arch or -m switches into the CFLAGS, but it will put them there along side their 64bit equivalents. In the end the linux32 command came to my rescue as detailed in an earlier entry. If you're on a 32bit system then you can ignore much of this.
Once I had a 32bit version of the libraries compiled, as confirmed by a 'file libssl.so.0.9.8' on the newly compiled library, I wanted to make a Debian package. I use checkinstall for these purposes, as it makes creating a package very simple. However, the current version of checkinstall doesn't play well with kernels >2.6.16 as detailed by the developer. The workaround it to use the --fstrans=no switch. This will write the files to their final locations however, so make sure you're doing it on the system you will be using it on. Or, if you are using Intrepid amd64, you can use my 32bit package available here.
Next, to fix up the links, you will need to run the following commands as root to link the libraries in the right place, and make sure you haven't b0rked your openssl (which compiles despite being instructed not to):
cd /usr/lib32/
cp /usr/local/ssl/lib/libssl.so libssl.so.0.9.8
ln -s libssl.so.0.9.8 libssl.so.0.9.7
cp /usr/local/ssl/lib/libcrypto.so libcrypto.so.0.9.8
ln -s libcrypto.so.0.9.8 libcrypto.so.0.9.7
ldconfig
cd /usr/bin
ln -s /usr/local/ssl/bin/openssl openssl
ln -s /usr/local/ssl/bin/c_rehash c_rehash
If you're on a 32bit system then do it in /usr/lib instead of /usr/lib32. The ugly complexity here is that you end up with three packages overlapping eachother:
- libssl0.9.8 - This is the 64bit version of the library
- ia32-libs - This provides the 32bit version of the openssl libraries, which are deleted. It provides other 32bit libs too.
- openssl - This is overwritten with the new version, and contains the shared libraries as well, unlike Ubuntu's package
Either way, a ldd of AvConnect should now paint a pretty picture:
singe@blackguard:~$ ldd /usr/local/Aventail/AvConnect
linux-gate.so.1 => (0xf7fa2000)
libpthread.so.0 => /lib32/libpthread.so.0 (0xf7f74000)
libssl.so.0.9.7 => /usr/lib32/libssl.so.0.9.7 (0xf7f30000)
libcrypto.so.0.9.7 => /usr/lib32/libcrypto.so.0.9.7 (0xf7ddd000)
libm.so.6 => /lib32/libm.so.6 (0xf7db7000)
libc.so.6 => /lib32/libc.so.6 (0xf7c59000)
/lib/ld-linux.so.2 (0xf7fa3000)
libdl.so.2 => /lib32/libdl.so.2 (0xf7c55000)
singe@blackguard:~$
Running startct should work, and voila you have internal network access via your VPN.
Next up, the horrors of connecting to an Exchange server, and no Evolution is not the answer.