External Network Unification Part 2: CMS LDAP Connections

So I've been examining what we have, and thinking about what we want, and thinking about how to get there with regards to external network unification.

Here's what we have:

  • A mail server running FreeBSD and getting user info from it's own, local DB
  • A web and FTP server running same, getting user info (I believe) from the mail server
  • A community site running the Mambo CMS, running on the same BSD machine as the web/FTP server, getting its user data from MySQL
  • A custom-built online computer reservations system, also running on the web/FTP server, getting its user data from a second MySQL database
  • A Quicktime Streaming Server running Mac OSX Server, getting user info from the local NetInfo database

Here's what we want:

  • An LDAP server with all user information
  • A mail server running FreeBSD, getting user info from LDAP
  • A web and FTP server running same, getting user info from LDAP
  • A community site running Mambo (or similar) getting user info from LDAP
  • A custom-built (or prefab, if available) online computer reservations system getting user info from LDAP
  • A Quicktime Streaming Server running Mac OSX Server, getting user info from LDAP

Are you sensing a pattern? Did you notice how much easier the second list is to read and understand? Boy I sure did. Extrapolate.

So, porting some of these systems — particularly the BSD machines that rely on local databases of users — shouldn't be too bad: build the LDAP server, point the BSD boxes at it, and, bam! we're done. I'm almost not worried about those. They're standard *NIX boxes, and LDAP support is built in and fairly easy to set up, at least in terms of getting user data. Same with the Quicktime Server: Mac OS X has stupid-simple support for authenticating to LDAP, and there's tons of good documentation on the subject. So I've been concentrating on our web apps, which promise to be much tougher, and recently I had what I think will turn out to be a real breakthrough.

When last I wrote about this topic I was experimenting with setting up my first FreeBSD server, and also with some simple PHP/MySQL-driven web apps that purported to authenticate against LDAP. The one I finally got to work was a freebie called MRBS. MRBS is great. We may even modify it and use it for certain staff-centered scheduling tasks. It's great that it works with LDAP, and it's pretty easy to get set up, after some trial and error and help from AFP548. It's given me a way to go with certain other proposed web-apps in the future. And, most importantly, it's allowed me to demonstrate proof-of-concept. But if MRBS is our future, what about our present?

We have a whole lot of time and effort invested in our current Mambo site. Not so much that it would kill us to move to a new system, but enough so that moving would be painful, and we'd better have a plan and damn good reasons to do so before making the attempt. So for the past however many weeks now, I've been building and testing a multitude of CMS systems. In doing so, I've been primarily concerned with two things: 1) Will this system authenticate to LDAP? 2) Does it have all the functionality (or more) that we currently enjoy on our Mambo site?

I figured the easiest thing to do — and a good place to start — would be to get our current Mambo site to work with LDAP. This would save us the trouble of setting up and learning a whole new system and porting over all our content — again, not the end of the world, but not exactly desirable either. Turns out there is an LDAP hack available for Mambo, but the hack is only supported under older versions of Mambo. I tried installing every version of Mambo I could, and every version of the hack, and every combination of these, as well as hacks to the hack I'd found in forums. No luck. I simply could not get the Mambo LDAP hack to work.

It was at this point I began to turn my attention to other CMSes that might support LDAP. After hunting around I stumbled upon Plone, which looked like a worthy contender, and which supposedly supported LDAP authentication. The thing I liked about Plone from the get-go was that it is ported to Mac OS X, which is what I'm testing all this on, so installation was a breeze. Plone even installs in its own folder in /Applications, and it's here that, somehow, the Plone site root lives. The system itself is very nicely structured as well. The interface is clean and easy to understand, and even fairly easy to modify, in minor cosmetic ways. But getting Plone to authenticate to LDAP turned out to be a little scary and labor intensive for my tastes. Plone runs on Python and MySQL (as opposed to Mambo's PHP/MySQL engine), so Python is responsible for making calls to LDAP. According to the LDAP module READ ME, LDAP authentication in Plone requires the python-ldap module to be installed. Installing this looked to be a pain, and no one in my organization (myself included) knows the first thing about Python, so it was at this point I bailed and began to start thinking about another approach. So much for Plone.

The next system I tried was Drupal. Drupal was also supposed to have LDAP support, though I never got around to really looking into it. I really liked Drupal: It's fast and simple, and the interface is sharp and clean. And Drupal has great user management with support for custom roles and permissions. But Drupal doesn't come with much out of the box, and I never really got around to figuring out how to install additional components. In fact, though I guess you could install one, Drupal does not come with a WYSIWYG HTML editor, which is one of the main reasons we're using a CMS in the first place. So I moved on despite some of the really nice things I saw in Drupal.

Some time later I was talking to a fellow sysadmin about all this, and he said, "What about Joomla?" and I said, "I thought that cost money." and he said, "No, it's the new Mambo." And I thought, "Hmmm... The new Mambo, eh?..."

Needless to say, the next day I'd installed my first Joomla install. I liked what I saw. It has a very similar look and feel to Mambo, particularly on the back-end. In fact, it's almost exactly the same because Joomla is developed by the former developers of Mambo. I'm not (yet) sure what went down, but apparently the bulk of the Mambo team jumped ship and began their own, separate CMS project. So Joomla really is the new Mambo.

Joomla also claimed to support LDAP, and according to their documentation, LDAP would be built in to the next release. This is apparently true, as Joomla 1.1 Alpha includes a built-in LDAP plugin. I installed the Beta and gave it a whirl, but no joy. I couldn't get the Joomla beta to authenticate to LDAP. Reading around some more led me to a new variant of the Mambo LDAP hack that's made to work with the latest stable version of Joomla, version 1.0.8. I also read what I believe was a comment in the Joomla forums from the originator of that hack who swears allegiance to the Joomla team, which probably explains why there are no new versions for Mambo.

Last week I installed Joomla 1.0.8 and the ported LDAP hack for Joomla 1.0.8 and guess what? After weeks of scrounging and searching and hoping and praying and cursing and installing CMS after CMS, it worked!

It fucking god damn worked.

This is great. Not only was installing the hack easy as pie, but setting up the LDAP authentication — for the first time since I dug in on this — was a breeze and worked completely as I'd hoped and expected it to. Not only that, but migrating our Mambo site to Joomla should be a fairly easy task since Joomla is built on the Mambo core. The Joomla site even provides instructions on how to do this, and they don't sound terribly difficult at all. The bonus is that the built-in Joomla LDAP authentication looks promising and, down the line, will hopefully eliminate the need for a "hacked" solution. But until then, the hack works great for our purposes.

This is a huge milestone for the External Network Unification project. Getting our CMS — really, our most complex web application — to work with LDAP was one of my biggest concerns. Going with Joomla gives us the LDAP stuff we need, maintains consistent usability on both the front- and back-ends, makes migrating a whole mess easier, and provides good scalability in terms of development and support for the future. Joomla's developer team appears to be solid, the third-party developer community seems very active, and the LDAP support looks to be headed in the right direction and available in the near term. While it's by no means a done deal, this looks very promising.

Next on the list:

  • Getting our custom computer reservations system to work with LDAP (or finding/building a replacement)
  • Learning and building an LDAP server on FreeBSD (not Mac OSX)

I'm going in. Wish me luck.