Mark Needham

Damana and I previously posted about our experiences with different Ruby LDAP solutions.

Having settled on Ruby-LDAP (although having read Ola and Steven’s comments we will now look at ruby-net-ldap) we then needed to put together the setup, installation and teardown into a ruby script file.

A quick bit of Googling revealed that we could use the Kernel.exec method to do this.

For example, you could put the following in a ruby script file and it would execute and show you the current directory listing:

exec "ls"

The problem with using Kernel.exec, which we became aware of after reading Jay’s post, is that we lose control of the current process – i.e. the script will exit after running ‘exec’ and won’t process any other commands that follow it in the file.

Luckily for us there is another method called Kernel.system which allows us to execute a command in a sub shell, and therefore continue processing other commands that follow it.

We were able to use this method for making calls to the make script to install Ruby-LDAP:

@extconf = "ruby extconf.rb"
system @extconf
system "make"
system "make install"

There is one more option we can use if we need to collect the results called %x[...]. We didn’t need to collect the results so we have gone with ‘Kernel.system’ for the time being.

Jay covers the options in more detail on his post for those that need more information than I have presented.

As I mentioned in an earlier post a colleague and I spent a few days looking at how to connect to an OpenDS LDAP server using Ruby.

We ended up analysing four different solutions for solving the problem.

Active LDAP

This approach involved using the Active LDAP Ruby which “provides an object oriented interface to LDAP. It maps LDAP entries to Ruby objects with LDAP attribute accessors based on your LDAP server’s schema and each object’s objectClasses”.

We had real problems trying to even connect to our OpenDS server using this library. We eventually found out that OpenDS is not actually listed as one of the supported interfaces.

The real benefit of this approach was that the library is written in Ruby meaning that getting permission to install it would be easier.

The fact that we couldn’t actually get it to work didn’t help!

Java LDAP libraries + RJB

This approach involved interacting with LDAP with Java libraries and then using the Ruby Java Bridge to connect to these from our Ruby code.

We were able to solve the problem quite easily using this approach but the Ruby code we ended up writing was very Javaesque in style and it didn’t feel like we were utilising the power of Ruby by using Java for such a fundamental part of the problem we were attempting to solve.

On the positive side RJB is easily installable via a gem and we were able to connect to OpenDS and execute the operations that were required.

Ruby-LDAP

The third option we looked at was Ruby-LDAP, a Ruby extension library written in C.

The disadvantage of this was that we needed to have make available to install it onto our machine. Seeing as we were using a Mac this meant downloading XCode to make use of the GCC compiler.

Interacting with the different libraries was tricky initially but we eventually got the hang of it and were able to connect to OpenDS despite it not being listed as one of the supported libraries.

ruby-net-ldap

ruby-net-ldap is a pure Ruby LDAP library, installable via a gem.

This had by far the best examples and most intuitive interface of the options that we analysed and worked for us first time without too much fuss. Connecting to our Open DS server was seamless.

Overall

Our original selection, despite the slightly more complicated installation was Ruby-LDAP.

However, Ola Bini pointed out ruby-net-ldap which actually proved to meet our criteria even more closely than Ruby-LDAP did and as such was the option we went with.

For those that are interested, Damana has posted more of the technical details behind the approaches we took.