Standing Up Islandora

This is a disjointed and likely incomplete post, since I’m having a hard time making the time to write it properly. By the same token, i need to get it down in case I need to relearn it later.

As background, my server environment for this is CentOS 5, MySQL 5.0.95, 4.5 Gb RAM, eight Intel Xeon 2.33. Though it’s not strictly relevant to what I relate below, it’s worth noting that I had a quota of 4Gb. It really becomes relevant only later when trying to do a large-scale import of content, which turned out to be an order of magnitude or more greater than my quota.

First whack was, as recommended by Alan Stanley at UPEI, downloading the VM and importing it into VirtualBox. Despite having some familiarity with Linux environments, I am still a longtime GUI guy and didn’t read the install instructions on the Islandora site, so I wasn’t able to copy our the folders I might have needed.
Lessons learned:

  1. Read the install instructions, and read them all
  2. Once the VM is installed, you can use SCP or SFTP to copy content out.

The day after or two days after failing with the VirtualBox path, I went on vacation. This is always a good plan when you are trying to install something complex. What could possibly go wrong?

Fortunately for me, nothing major did go wrong, and I managed to find one morning to install Drupal 6, Java 6, and Fedora 3.5, and to get a second db for Fedora created. At the end of that morning, I felt good declaring that I had the Drupal and Fedora installs stable. I even had managed to get some Islandora modules into Drupal, but didn’t understand the dependency gaps. I also hadn’t managed to get the Drupal Servlet Filter installed, which foreshadowed the problems I had later with this piece of things. As sometimes with component-based systems, it was reasonably trivial to install the components but much harder to get them to play nicely together.
This is a good place to mention that I was installing everything in a nonstandard manner. That is, the box I was using for this proof of concept was one with a moderately high level of security on it, so I could not install to most of the usual locations, not even to /usr/local. As a consequence, I installed Fedora and Java to /home/[me]. In parallel, I requested a proper install of Java, which was taken care of by our very capable sysadmins.

Lessons learned:

  1. Read the install instructions, and read them all
  2. More specifically, I would have done better to try installing the dependencies, such as Java, earlier. It’s possible I could have even gotten the sysadmins to install Fedora. By the same token, it might still have been installed in a location that works with their security requirements and not with the Islandora configuration requirements. Things seemed to go fine even with the install location change in media res.

On full return from my vacation, I worked diligently (with invaluable assistance from Paul Pound of Discovery Garden and Alan Stanley) to get things fundamentally up and running, and I did. The sticking point seemed to be Fedora authenticating through Drupal. Some parts of the resolution (not necessarily in chronological order):

  • Somewhere along the line, the “Fedora SOAP management URL” in (Drupal) admin –> site config –> Islandora config was set to http://modlab.commons.yale.edu:8080/?api=API-M. It should have instead been http://modlab.commons.yale.edu:8080/fedora/wsdl?api=API-M.
  • Alan suggested we specify everything at (Drupal) admin –> site config –> Islandora config. It didn’t resolve everything immediately, but it may have helped.
  • Piecemeal testing was important, especially testing to make sure that Fedora was properly ingesting content. There are scripts in $FEDORA_HOME/client/bin that can be run to test ingestion (with content in $FEDORA_HOME/client/demo) on a low level. Full description available.
  • Reviewed my Fedora installation parameters at $FEDORA_HOME/install/install.properties. Turned out I was assuming that I was using FeSL when in fact that was set as FALSE in the install.properties file. Seeing this led me to make sure that both jaas.conf and web.xml were properly modified.
  • Edited the web.xml file to add the nodes described in the doco even though the nodes used as indicators of where to edit were not present.
  • Made sure the XACML policy included the actual IP of the server and not just the 127.0.0.1 local IP. More extensive documentation available in the Fedora documentation on writing XACML policies and on allowing API-M access from remote hosts.

I haven’t been this pleased to get something working in a long time. A good feeling indeed, though it would soon be replaced by frustrations in moving to level 2.