Working through installing PloneLDAP, plone.app.ldap, and their dependencies for Plone, and on three different platforms … I think I’ve got some solutions.
I’m in the middle of trying to figure out how to install Plone’s LDAP support — not use it, but just install it — and I’ve run into similar problems on three different platforms: Linux (RHEL4), OS X (10.5.4), and Windows XP (actually, both 32 and 64-bit versions of XP Professional).
Some of the problems I’ve had:
- On OS X, I’d installed OpenLDAP (openldap) and python-ldap (py-ldap) via MacPorts (port), as well as Berkeley DB (p5-berkeleydb) but when I ran buildout, I got a Berkeley DB version mismatch error. I’ve read that setting library environment variables (LD_LIBRARY_PATH and DYLD_LIBRARY_PATH) can help alleviate this, but this didn’t help in my case.
- On Linux, I’d installed OpenLDAP and python-ldap via package manager (up2date), but when I ran buildout, I got all kinds of LDAP-related errors. I found this strange, as I could use ldapsearch from the OpenLDAP installation to query LDAP servers.
- On Windows XP, I get the same errors as in Linux.
My results for installing python-ldap via easy_install:
- OS X: success (but this installation didn’t seem to find its way into my buildout attempts)
- Linux: failure with errors
- Windows: failure first with time-outs, and then errors similar to those in Linux above.
The solution (Linux version):
I began to work with the problem by downloading source distributions for Linux. I downloaded the latest 2.3.x of OpenLDAP (2.3.43) to /usr/local/, configured, then ran tests, which failed:
Could not locate slapd(8)
Much searching led me to an OpenLDAP FAQ-O-Matic entry on prerequisites:
At first glance, I was a bit puzzled by the sheer volume of prereqs listed here. At any rate: since my buildout traceback experiences indicated that Plone buildouts seem to call for Berkeley DB support, I assumed this option in the list was one that was needed:
SLAPD (with BDB or HDB database)
However, the “Sleepycat” download link given in that FAQ (and elsewhere) now redirects to an Oracle page, which seems to me something of a roadblock: typically, Oracle does not provide open source software; however, according to the licensing information for the Berkeley DB software, it seems the software is provided via a dual licensing model, and it may be distributed as open source if the typical conditions are met. And then, I assumed the version Plone users would want would be the “Berkeley DB 4.7.25, without encryption” for their platform. Of course, Oracle uses a tricky JS script to obfuscate the download link, so a simple wget may not be obvious for some users … that is, without this direct link:
The package’s installation procedure, which would be required reading without instructions like those on this page, is an HTML file buried in a sub-directory.
To install the Berkeley DB software, extract the tar-ball and run:
cd [Berkeley-DB-directory]/build_unix ../dist/configure make make install
Once installed, the libraries on my system were stored in:
Some of the text that flew past during the installation indicated that other applications might require these libraries in the LD_LIBRARY_PATH environment variable. So I set this with:
Then the OpenLDAP installation began:
./configure make depend make make test # <-- these tests took a long while to complete: about 45 minutes. make install
Once that had finished, I downloaded the latest 2.3.x version of python-ldap (2.3.5) from source. After unpacking the archive, I modified the package’s setup.cfg directives for library_dirs and include_dirs to point to the new OpenSSL directories:
library_dirs = /usr/local/openldap-2.3.43/include/lib include_dirs = /usr/local/openldap-2.3.43/include /usr/include/sasl
Luckily, I already had SASL installed, but I’m sure it could have been installed in much the same way as the other packages. I then ran:
python setup.py build python setup.py install
… that is, of course, after ensuring that ‘python’ pointed to my Python 2.4 installation.
And then, finally, I had a successful installation of python-ldap., which subsequently led to a successful buildout installation of PloneLDAP and plone.app.ldap, using my working (final?) buildout configuration.
That was simple, right? 😛 Thanks to Martin Aspeli for convincing me to start from scratch and try installing the necessary packages from source.
The solution (OS X version):
As mentioned above, I had installed all of PloneLDAP’s dependencies on OS X via ‘port’ packages. I’m not sure how, but I now believe that some Python-related or LDAP-related package must have gotten screwed up, or the wrong version had gotten installed.
Fixing this meant starting my Python 2.4 installation over from scratch: uninstalling it, and all its dependencies, and then re-installing only Python itself and the specific, related ports I needed in order to get Plone and its LDAP support up and running. For me, the eventual command I found for the uninstall was:
sudo port uninstall py-numeric py-elementtree py-altgraph py-bdist_mpkg \ py-macholib py-setuptools py-pil py-ldap python24 py-elementtree \ py-setuptools py-numeric py-game
And the re-install was simply:
sudo port install python24 py-setuptools py-pil py-ldap
I may need to re-install some of the other ports at some point, but I don’t need them at the moment.
Once I did this, and once I ensured that my port’s version of Python 2.4 was considered the system version, my working (final?) buildout configuration worked nicely.
Thanks to ‘DigitalD’ (Michael Dunlap) for the inspiration to look into exactly what ports were installed, tear down the related ports, and re-install them from scratch.
The solution (Windows version):
This remains a mystery. It’s simple enough in a *NIX environment to install packages from source, but Windows is an entirely different story: one needs either to rely upon third-party binary installers for important software components (like OpenLDAP), or install a UNIX pseudo-environment in order to compile one’s own binaries from source. And even then, troubleshooting problems is tricky.