Monthly Archives: September 2011

OpenIndiana 151a is out – and powered by Illumos

In case you haven’t already heard, OpenIndiana development release 151a is out. The critical change in this release is that it’s now based on the Illumos kernel, developed by star ex-Sun Microsystems talent in the wake of Oracle’s compeltely styleless killing off of OpenSolaris. Substantial new features which you won’t be seeing in Solaris 11 anytime soon such as KVM support are built-in and tightly integrated. And yes, KVM support for AMD CPUs is on the way – hopefully in time for the 8-core AMD Bulldozer architecture desktop CPUs…

There are also a nice set of desktop software additions, some of which OpenIndiana and OpenSolaris before it has been needing for ages, for example a capable suite of multimedia playback applications. OpenIndiana now has dedicated SFE repositories from which VLC and Mplayer can be installed, as well as bonus goodies such as Scribus and more.

OpenIndiana download links, release notes, and SFE repository details:

http://openindiana.org/
http://wiki.openindiana.org/oi/oi_151a+Release+Notes
http://wiki.openindiana.org/oi/Spec+Files+Extra+Repository

After running 151a for a few days (the upgrade from release 148 was completely seamless by the way), I was presented with something I hadn’t seen for a long time, not since OpenSolaris development was closed off a couple years back…

OpenIndiana update manager

Advertisements

Secure (SSL) LDAP authentication between OpenDJ and Ubuntu

A quick update to my post here regarding using OpenDJ as an LDAP authentication service for Ubuntu 10.04 clients.

A commenter asked how to enable secure LDAP with this configuration, so what follows is a quick and dirty guide which explains how I got this working using SSL on my setup. This is only intended for testing purposes.

A couple of changes should be noted however: First, I am now using OpenDJ 2.4.2 (as opposed to 2.4.1), and second I am running OpenDJ on Ubuntu 10.04 x86 as well in this example (i.e. same OS for server and client).

 

1) Export the OpenDJ server certificate in PEM encoded file format

During setup of our test OpenDJ server, we elected to generate a self-signed certificate for secure LDAP connectivity. We need to export this certificate in a format that ultimately will be installed in our Ubuntu client, such that it can trust the OpenDJ server for secure authentication.

We use the Java keytool utility to do this. More on keytool may be found here: http://download.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html

In the case of my sample OpenDJ server, the OpenDJ Java keystore file (which contains the certificate) is found at /opt/OpenDJ/config/keystore

We can then use the keytool command to export the self-signed certificate in the keystore as a PEM encoded certificate file. In my example there is no password for the keystore, so when promtped one can just press Enter without providing a password. The alias refers to the particular certificate as referenced in the keystore file, which for a self-signed certificate in a default OpenDJ installation is named server-cert. Finally we are exporting the certificate to the Desktop as opendjserver.pem:

$ keytool -keystore /opt/OpenDJ/config/keystore -export -alias server-cert -rfc -file ~/Desktop/opendjserver.pem
Enter keystore password:  

*****************  WARNING WARNING WARNING  *****************
* The integrity of the information stored in your keystore  *
* has NOT been verified!  In order to verify its integrity, *
* you must provide your keystore password.                  *
*****************  WARNING WARNING WARNING  *****************

Certificate stored in file </home/dave/Desktop/opendjserver.pem>

 

If you like, you can view the contents of a certificate by also using the keytool command. To view the certificate generated in the above step for example:

$ keytool -printcert -v -file opendjserver.pem 
Owner: CN=opendjserver, O=OpenDS Self-Signed Certificate
Issuer: CN=opendjserver, O=OpenDS Self-Signed Certificate
Serial number: 
Valid from: Sat Sep 10 00:34:27 NZST 2011 until: Mon Sep 09 00:34:27 NZST 2013
Certificate fingerprints:
	 MD5:  
	 SHA1: 
	 Signature algorithm name: SHA1withRSA
	 Version: 3

 

2) Copy the certificate to the Ubuntu client

We simply copy this certificate to the test Ubuntu VM and place it at /usr/share/ca-certificates

We also want to make the certificate owned by root and world readable:

$ ls -al opendjserver.pem 
-rw-r--r-- 1 root root 731 2011-09-15 17:03 opendjserver.pem

 

3) Modify the client LDAP configuration file

We now make some modifications to /etc/ldap.conf. There are many options which can be set or uncommented, however, I have found that only the below two modifications need to be made to an otherwise unmodified file in its default state. This is especially noteworthy considering that entries such as “#ssl on” apparently do not need to be uncommented.

First, specify a secure LDAP URI. In our example, OpenDJ running on the server named opendjserver is being accessed securely over port 1636:

# Another way to specify your LDAP server is to provide an
uri ldaps://opendjserver:1636

(Note that if you are using a server host name instead of an IP address, and you are not running DNS, you will need to modify /etc/hosts so that the server hostname is pointing to the server IP address.)

 

Next, point to the server certificate. Create the following entry:

TLS_CACERTFILE /usr/share/ca-certificates/opendjserver.pem

 

3) Test connectivity

From the command line on the client we can see if we can retrieve account information for LDAP users:

$ id dave
uid=1001(dave) gid=119(admin) groups=119(admin)
$ 
$ getent passwd dave
dave:*:1001:119:Dave Koelmeyer:/home/dave:

(Note that if testing in this way it may be useful to uninstall nscd if it has been installed beforehand – as it may have cached successful lookups leading to potentially misleading results if something isn’t working as it should.)

That should be it, and you should now have a basic setup that securely authenticates host logins to the system.

Apple MobileMe Mail is a steaming pile of dung

While the Apple faithful await the roll-out of the supposedly new and improved iCloud service, let’s not forget the colossal and hopefully soon-to-be-forgotten joke that has been MobileMe, in particular, MobileMe mail.

I signed up to MobileMe when it was known as .Mac, back in the heady days of being primarily a Mac user (before the dark times, before the Empire). Having a Mac mail account along with calendaring, online storage, chat and web pages seemed like a fairly nice deal, even if it did cost 120 bucks local.

Over time however, the only component of MobileMe I’ve really come to use regularly has been iDisk, and even that I access from Gnome on OpenIndiana (iDisk Finder integration with Mac OS itself being hopelessly slow and unstable). I’ve tried to buy in to the whole “email as web app” experience, but if MobileMe is anything to go by it’s just not ready for prime time. Let’s reflect on some salient points here.

Firing up MobileMe on Firefox 5 it’s entirely usual to have the GUI sitting there grinding its gears just to bring up your inbox view:

MobileMe loading

Even once it’s up and running, beware of clicking on an email item to actually read it as you might have to wait for the item itself to load:

MobileMe more loading

MobileMe often falls over at the first hurdle:

MobileMe is unavailable

And of course, everyone just loves the service failing hard right when you want to load that critical email, or even worse, send the one you have just written without any way to save it other than to manually copy its contents to the clipboard:

MobileMe error loading message

So there you have it: a paid service with worse-than-free performance (and calendaring by the way is useless for me as it hardly talks to anything else).