We have a few historic maps from our McGregor collection available through our Geoserver installation, so I looked up their layer ids and manually added them into a page with OpenLayers. Nothing fancy here, just a test to see what it looks like.

var lat, long layer;
var zoom = 10;

var lat, lon, layer;
 var zoom = 10;

 map = new OpenLayers.Map('map');
 map.addControl(new OpenLayers.Control.LayerSwitcher());

 layer1 = new OpenLayers.Layer.WMS("Map of the Southern States",
 "http://lat.lib.virginia.edu:8080/geoserver/gwc/service/wms",
 {layers: "McGregor:000003056_00011"}
 );
 layer2 = new OpenLayers.Layer.WMS("Nova Virginae tabula",
 "http://lat.lib.virginia.edu:8080/geoserver/gwc/service/wms",
 {layers: "McGregor:000003482_00011"}
 );
 layer3 = new OpenLayers.Layer.WMS("A map of the most inhabited part of Virginia",
 "http://lat.lib.virginia.edu:8080/geoserver/gwc/service/wms",
 {layers: "McGregor:000003012_st1"}
 );
 layer4 = new OpenLayers.Layer.WMS("Carte de la campagne en Virginie du Major General Mis. de la Fayette",
 "http://lat.lib.virginia.edu:8080/geoserver/gwc/service/wms",
 {layers: "McGregor:000003013_st1"}
 );
 layer5 = new OpenLayers.Layer.WMS("Carte de la campagne en Virginie du Major General Mis. de la Fayette",
 "http://lat.lib.virginia.edu:8080/geoserver/gwc/service/wms",
 {layers: "McGregor:000003019_00011"}
 );

 map.addLayer(layer1);
 map.addLayer(layer2);
 map.addLayer(layer3);
 map.addLayer(layer4);
 map.addLayer(layer5);

if(navigator.geolocation){
 navigator.geolocation.getCurrentPosition(function(position){
 lat = position.coords.latitude;
 lon = position.coords.longitude;
 map.setCenter(new OpenLayers.LonLat(lon, lat), zoom);

 var vectorLayer = new OpenLayers.Layer.Vector("Overlay");
 var feature = new OpenLayers.Feature.Vector(
 new OpenLayers.Geometry.Point(lon, lat),
 {some:'data'},
 {externalGraphic: 'http://geocoder.ca/marker.png', graphicHeight: 64, graphicWidth: 48});
 vectorLayer.addFeatures(feature);
 map.addLayer(vectorLayer);
 });
 }

map.addControl(new OpenLayers.Control.PanZoomBar());

This actually worked surprisingly well the first time I launched it. With Firefox 3.5 I tested it on my laptop. At first I wasn’t using the geowebcache we had set up, so it was a bit slow. I changed to the geowebcache WMS service and things in the browser were noticeably faster.

At lunch, I handed an iPhone to Schuyler Erle who’s first instinct was to try to drag things around and zoom-in and out. Well, there was a fail as the controls you normally use in OpenLayers were far too small to actually be useful and it just didn’t feel right.

I then attempted to add in a touchHandler function to help with the interactions from the user. I found Ross Boucher’s post “iPhone Touch Events in JavaScript” and used his code to get the sliding working:

function touchHandler(event)
{
   var touches = event.changedTouches,
   first = touches[0],
   type = "";

   switch(event.type)
   {
     case "touchstart": type = "mousedown"; break;
     case "touchmove":  type="mousemove"; break;
     case "touchend":   type="mouseup"; break;
     default: return;
 }

 // initMouseEvent(type, canBubble, cancelable, view, clickCount,
 // screenX, screenY, clientX, clientY, ctrlKey,
 // altKey, shiftKey, metaKey, button, relatedTarget);

    var simulatedEvent = document.createEvent("MouseEvent");
    simulatedEvent.initMouseEvent(type, true, true, window, 1,
    first.screenX, first.screenY,
    first.clientX, first.clientY, false,
    false, false, false, 0/*left*/, null);

    first.target.dispatchEvent(simulatedEvent);
    event.preventDefault();
 }

 document.addEventListener("touchstart", touchHandler, true);
 document.addEventListener("touchmove", touchHandler, true);
 document.addEventListener("touchend", touchHandler, true);
 document.addEventListener("touchcancel", touchHandler, true);

Now the scrolling worked, but you could no longer zoom into the map (and we want real zoom, not just making the image bigger). I haven’t found a fix for this yet, but I have to say that this is a kind of cool way of interacting with these materials.

Something I need to talk with Joe about next week making your location a query to Geonetwork and then using the top n maps returned to build this interface. It’s a little like a coverage map for your current location.

What I’m going to do here is go through the setup for building the RPM and the spec file. This should work on just about any OS that uses RPM for installing software, but this isn’t tested very extensively.

So I guess the first thing to cover is what exactly an RPM is. RPM is the Redhat Package Manager and is an implementation of a container for other files. It allows you to quickly install software, including necessary programs to run the program, provides information about the program you are installing, informs users about potential conflicts between your program and the software currently installed on the system, and provides a path to install, upgrade, and remove the software.

Now, in the case of Omeka, you don’t really need a package manager if you’re a seasoned system administrator. However, if you’re wanting to run this yourself, and you have to convince others to manage the software for you (e.g. you’re running it at an institution), have an RPM that your systems administrator installs will save a lot of headaches, especially since upgrades to the software can be integrated into scheduled maintenance with kernel and other software upgrades.

Building RPMs requires two things, the source you want to install and a specification (spec) file that tells the software what to do. You’ll need to first set your system up to have the tools to build software which you can do with a couple of lines (as the root user):

yum groupinstall "Development Tools"
yum install rpmdevtools

Next we need the directory hierarchy for building the RPMs. You can do this manually, but there’s a handy tool for helping out called rpmdev-setuptree. In the terminal, if you run this command, it will create a new folder in your home directory named “rpmbuild” with the correct directories made for you.

rpmdev-setuptree

If you want these in a different location, say omeka_rpm, you can manually create the following hierarchy:

mkdir -p ~/omeka_rpm/BUILD
mkdir -p ~/omeka_rpm/BUILDROOT
mkdir -p ~/omeka_rpm/RPMS
mkdir -p ~/omeka_rpm/SOURCES
mkdir -p ~/omeka_rpm/SPECS
mkdir -p ~/omeka_rpm/SRPMS

For our purposes, we’re really going to be dealing in the SOURCES and SPEC directories. Let’s start with the setup for the source files. First you need to get the source files from Omeka’s website and put it into your SOURCES folder. We have to do some additional work with this file since it’s packaged using zip and the RPM is expecting a gzipped tarball. The following code snip assumes you’re using the default structure from the rpmdev-setuptree command and if a release after Omeka 1.1 is the most current, you will need to update the revision numbers.

cd ~/rpmbuild/SOURCES
wget http://omeka.org/files/omeka-1.1.zip
unzip omeka-1.1.zip
mv omeka-1.1 omeka
tar -czvf omeka-1.1.tar.gz omeka

Now if take a look at the directory, you should see a new file named “omeka-1.1.tar.gz” which is in the correct format for using it to build our RPM. There are two more files we need in here, an httpd configuration file and a readme for its use. Let’s just touch these so they exist and we can come back and add content to them a little later after I discuss them.

cd ~/rpmbuild/SOURCES
touch fedora-http-conf
touch README.fedora.omeka

Ok, let’s look at the real meat of this now. You need to create an omeka.spec file in the SPECS directory. This is the script that tells the rpmbuild tool how to set up the system.

I use gedit when I have a GUI, but emacs or vi work just as well (better if you’re good at the commands).

The idea behind this setup is to set up Omeka much like other software on the system is set up. This assumes that there will be only one installation of Omeka running on the system and takes into account that MySQL may be running on another server, so only the php >= 5.2.4, httpd, php-mysql, and ImageMagick packages are required. The configuration for the database connection is set in /etc/omeka/db.ini and uses a symbolic link to the application files in /usr/share/omeka (though this isn’t quite working yet). Themes and the archive folder shouldn’t get overwritten, so those directories stay in place. An httpd configuration for omeka (which aliases “/omeka”) is added into the httpd.conf directory. Since this software does not actually need to be compiled for a processor architecture type, the build archicture is set to noarch.

Summary: Omeka web publishing software
URL: http://omeka.org
Name: omeka
Version: 1.1
Group: Application/Publishing
Release: 1%{?dist}
License: GPL
Source0: %{name}-%{version}.tar.gz
Source1: omeka-http-conf
Source2: README.fedora.omeka
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: php >= 5.2.4, httpd, php-mysql, ImageMagick
BuildArch: noarch

%description
Omeka is a free and open source collections based web-based publishing platform for scholars, librarians, archivists, museum professionals, educators, and cultural enthusiasts.

%prep
%setup -q -n omeka

%install
 mkdir -p ${RPM_BUILD_ROOT}%{_datadir}/omeka
 mkdir -p ${RPM_BUILD_ROOT}%{_sysconfdir}/omeka
 install -m 0644 -D -p %{SOURCE1} ${RPM_BUILD_ROOT}%{_sysconfdir}/httpd/conf.d/omeka.conf
 cp -pr * ${RPM_BUILD_ROOT}%{_datadir}/omeka
 #cat db.ini | sed -e "s|dirname(__FILE__).'/'|'/usr/share/omeka/!|g" > ${RPM_BUILD_ROOT}%{_sysconfdir}/omeka/db.ini
 #/bin/ln -sf ../../../etc/omeka/db.ini ${RPM_BUILD_ROOT}%{_datadir}/omeka/db.ini
 /bin/cp %{SOURCE2} ./README.fedora
 # Remove empty files for rmplint
 find ${RPM_BUILD_ROOT} -empty -exec rm -f {} \;
 # These are docs; remove and docify later
 rm -f ${RPM_BUILD_ROOT}%{_datadir}/omeka/{readme.txt,license.txt,release.txt,changelog.txt}

%clean
 rm -rf ${RPM_BUILD_ROOT}

%files
 %defattr(-,root,root,-)
 %config(noreplace) %{_sysconfdir}/httpd/conf.d/omeka.conf
 %dir %{_datadir}/omeka
 %{_datadir}/omeka/admin
 %{_datadir}/omeka/application
 %{_datadir}/omeka/archive
 %doc changelog.txt
 %config(noreplace) %{_sysconfdir}/omeka/db.ini
 %{_datadir}/omeka/index.php
 %doc license.txt
 %{_datadir}/omeka/paths.php
 %{_datadir}/omeka/install
 %{_datadir}/omeka/plugins
 %doc readme.txt
 %doc release.txt
 %{_datadir}/omeka/robots.txt
 %{_datadir}/omeka/themes
 %dir %{_sysconfdir}/omeka

%changelog
* Mon Nov 09 2009 Wayne Graham <wayne dot graham at virginia dot edu> - 1.1
- Initial build

Now we can add in the httpd configuration that will get written. Open up SOURCES/omeka-http-conf and add

Alias /omeka /var/www/omeka

<Directory /var/www/omeka>
 AllowOverride Options
</Directory>

And README.fedora.omeka

Omeka is a database driven web publishing program.

Once this package is installed, there are a few configuration items which need
to be performed before Omeka is usable.  First, you need to establish a
username and password with which to connect to your MySQL database. You also need to make both
MySQL and Omeka aware of this configuration.  Let's start by creating the database and the
username / password inside MySQL first:

 # mysql
 mysql> create database omeka;
 Query OK, 1 row affected (0.00 sec)

 mysql> grant all privileges on omeka.* to omeka identified by '1superPrivateOmekaPassword!';
 Query OK, 0 rows affected (0.00 sec)

 mysql> flush privileges;
 Query OK, 0 rows affected (0.00 sec)

 mysql> exit
 Bye
 #

Under certain curcumstances, you may need to run variations of the "grant"
command:
mysql> grant all privileges on omeka.* to omeka@localhost identified by 'omeka';
 OR
mysql> grant all privileges on omeka.* to omeka@'%' identified by 'omeka';

This has created an empty database named 'omeka', created a user named
'omeka' with a password of '1superPrivateOmekaPassword!', and given the 'omeka' user total
permission over the 'omeka' database.  Obviously, you'll want to select a
different password, and you may want to choose different database and user
names depending on your installation.  The specific values you choose are
not constrained, they simply need to be consistent between the database and the
config file.

Next, you need to edit your /var/www/omeka/db.ini file to reflect the
values you've chosen.  These values will go in the appropriate places at the
beginning of that file.

Once that's done and the database server and web server have been started,
open a web browser to http://localhost/omeka/install/ and
follow the instructions given to you on the pages you see to set up the
database tables and begin publishing your Omeka instace.

Now everything is in place. Let’s try to build this thing. Go in to the SPEC directory and build the binary for the rpm.

cd ~/rpmbuild/SPECS
rpmbuild -bb omeka.spec

This takes a while, and if you’re running this through VMWare of VirtualServer, this process will demand some pretty hefty system resources and your system will slow down.

If everything has gone correctly, you should now have a nice new RPM package named omeka-1.1.fc11.noarch.rpm in the RPMS/noarch directory. You can test it out by installing the package with

rpm -Uvh omeka-1.1.fc11.noarch.rpm

What’s Next

For packaging RPMs like this, a few more infrastructure elements need to be in place. The following outlines some of them (if you have more, leave a comment).

• Put the build files into SCM (currently only in our private SVN repo)
• Auto-install dependencies
• Set up an RPM repository to work with yum
  • Target specific Linux builds
• Automate build
• Run MySQL setup script after initial install
• Build aptitude package (using alien?)

Additional Resources

• Chapter 4. Building RPM Packages
• How To Build RPM Packages on Fedora
• RPM scriptlet recipes
• Package Naming Guidelines
• Packaging Guidelines

A few years ago, I had written a bunch of Sherlock plugins for searching various library catalogs. Those pretty much lay dormant until I was talking with my student worker this last semester and he got quite excited about these, and wondered if there might be a way to also search the databases the library subscribes to, and provide off-campus access to these through our proxy server. This code is in a very basic stage right now, but essentially what I did was create a database driven application in PHP that generates OpenSearch XML for various targets to search against.

Right now, this only supports HTTP GET requests (POST parameters require an additional table), but here’s the DDL:

CREATE TABLE `plugins` (
  `id` char(36) NOT NULL,
  `short_name` varchar(50) NOT NULL,
  `description` varchar(255) NOT NULL,
  `engine` varchar(25) NOT NULL,
  `image` varchar(25) NOT NULL,
  `input_encoding` varchar(10) NOT NULL,
  `url` varchar(550) NOT NULL,
  `method` varchar(4) NOT NULL default 'get',
  `proxy` tinyint(1) NOT NULL default '1',
  KEY `engine_index` (`engine`),
  KEY `short_name_index` (`short_name`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

You don’t need all of these fields for every record, and here is some useful records…

INSERT INTO plugins (id, short_name, engine, input_encoding, method, proxy, url)
VALUES (UUID(), ' JStor', 'jstor', 'UTF-8', 'get', 1, 'http://www.jstor.org/action/doBasicSearch?Query=');

INSERT INTO plugins (id, short_name, engine, input_encoding, method, proxy, url)
VALUES (UUID(), 'Google Your University', 'google', 'UTF-8', 'get', 1, 'http://www.google.com/univ/wm?hl=en&ie=ISO-8859-1&btnG=Google+Search&q=');

INSERT INTO plugins (id, short_name, engine, input_encoding, method, proxy, url)
VALUES (UUID(), 'Google Scholar', 'googlescholar', 'UTF-8', 'get', 1, 'http://scholar.google.com/scholar?&hl=en&lr=&btnG=Search&q=');

INSERT INTO plugins (id, short_name, engine, input_encoding, method, proxy, url)
VALUES (UUID(), 'Ebrary', 'ebrary', 'UTF-8', 'get', 1, 'http://site.ebrary.com/lib//Top?layout=search&nosr=1&sch=sch&frm=smp.x&p00=');

INSERT INTO plugins (id, short_name, engine, input_encoding, method, proxy, url)
VALUES (UUID(), 'EbscoHost', 'ebsco', 'UTF-8', 'get', 1, 'http://search.ebscohost.com/login.aspx?db=aph&direct=true&bQuery=');

INSERT INTO plugins (id, short_name, engine, input_encoding, method, proxy, url)
VALUES (UUID(), 'LexisNexis', 'lexisnexis', 'UTF-8', 'get', 1, 'http://www.lexisnexis.com/us/lnacademic/search/homesubmitForm.do');

INSERT INTO plugins (id, short_name, engine, input_encoding, method, proxy, url)
VALUES (UUID(), 'Proquest UMI', 'umi', 'UTF-8', 'get', 1, 'http://proquest.umi.com/pqdweb?RQT=305&FT=1&DBId=414&SQ=');

INSERT INTO plugins (id, short_name, engine, input_encoding, method, proxy, url)
VALUES (UUID(), 'Science Direct', 'sciencedirect', 'UTF-8', 'get', 1, 'http://www.sciencedirect.com/science/quicksearch?query=');

Apparently I wrote the queries with MDB2, I’ve since moved most of my interactions to Zend Db (you should be able to write that part pretty quickly) and just dump the names of the plugins in the tableon a view:

foreach($plugins as $plugin):

    echo('<li>' . $plugin['short_name'] . ': ');
       echo(' <a href="openSearch.php?id=' . $plugin['id'] . '"><img src="images/a9.png" title="OpenSearch" /></a>'); 

        if(strlen($plugin['url']) > 0){
        	echo(' <a href="search.php?engine=' . $plugin['engine'] . '&q=regulators">test search');
            echo(' | <a href="#" title="Ref: ' . $plugin['engine'] . '" onClick="addOpenSearch(\'' . $plugin['engine'] . '\', \'gif\', \'Education\', \'' . $plugin['id'] . '\'); return false;">add</a>');
        }

        echo('</li>);

');
endforeach;

The add code is straight-forward

$result = $result[0];

$short_name = $result['short_name'];
$description = $result['description'];
$engine = $result['engine'];
$id = $result['id'];

$xml = <<<EOT
<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/"
xmlns:moz="http://www.mozilla.org/2006/browser/search/">
<ShortName>$short_name</ShortName>
<Description>$description</Description>
<Url type="text/html" method="get" template="http://<your_server>/plugins/proxy.php?engine=$engine&q="/>
<Contact>libsys@wm.edu</Contact>
<Image width="16" height="16">http://<your_server>/favicon.ico</Image>
<Developer>Wayne Graham</Developer>
<InputEncoding>UTF-8</InputEncoding>
<moz:SearchForm>http://<your_server>/plugins/search.php?engine=$engine</moz:SearchForm>
<moz:UpdateUrl>http://<your_server>/plugins/opensearch.php?$id</moz:UpdateUrl>
<moz:IconUpdateUrl>http://swem.wm.edu/favicon.ico</moz:IconUpdateUrl>
<moz:UpdateInterval>7</moz:UpdateInterval>
</OpenSearchDescription>
EOT;
header("Content-Type: text/xml");
echo($xml);

You just need a little JavaScript to add this in to IE and Firefox:

function addOpenSearch(name,ext,cat,pid,meth)
{
  if ((typeof window.external == "object") && ((typeof window.external.AddSearchProvider == "unknown") || (typeof window.external.AddSearchProvider == "function"))) {
    // See bugs 430058/430067/430070 for Camino
    if (((typeof window.external.AddSearchProvider == "unknown") || (window.navigator.vendor == 'Camino'))&& meth == "p") {
      alert("This plugin uses POST which is not currently supported by your browser's implementation of OpenSearch.");
    } else {
      window.external.AddSearchProvider("http:///plugins/install.php?id=" + pid);
    }
  } else {
    alert("You will need a browser which supports OpenSearch to install this plugin.");
  }
}

If I get some time soon, I’ll wrap this up into a package; rudimentary, but a decent start to your own app!

The Sun Installation Assistant CD really took all the work out of setting the thing up…it includes all the required drivers for the hard drives and NIC. Took a while since I was redirecting the KVM through the ILOM and sharing my ROM drive. Everything went very well, but I did notice that the OS I installed (Windows 2003 R2 Standard) has a limit of 4GB. I couldn’t for the life of me figure out what happend to the other 12GB. Been in *nix too long and forgot that Microsoft puts limits on the amount of RAM a server can support. I just need to reinstall with Enterprise edition. Not a huge deal, but it’s one of those things I wish I would have known/remembered.

I did set up a “test” share (it’s primarily to give our media center access to a lot of storage), but I ran into an issue(s) with OS X. Seems the mount would take, but you can’t see any of the files. You can move files to the server, but they don’t show up.

I think the bandwidth should be ok coming from the media center. There’s full gigE from the desktop to the server and I ganged the NICs.

I wished I could have used the Z-RAID, and I’m not sure that the Windows Dynamic RAID-5 will do quite the same job, but it’s a step forward in getting some storage (and not attached hard drives) for media production.

So I showed my student worker the search plugins I had made a few years ago and he got really excited. They’re burried on our website right now (but then again, so is everything), but he like the convienence. He actually got me to start thinking about it a bit more. IE 7 and Firefox both use OpenSearch now for their search plugins. There’s not a whole lot to this description (and it’s a lot more convienent than the Sherlock format). What if I built a quick app that could generate the XML for these and them people could install them? We could quickly develop a collection of useful plugins that would help folks get to data (hopefully) faster.

I started looking at it yesterday and it’s pretty straight forward…with a few exceptions. Most search engines use a get method, but I’m finding a bunch of our most popular search engine providers (e.g. lexisnexis, factiva, etc.) use a post method with weird session variables.

Focusing on just the “easy” stuff first, I wrote a database table (which is still in flux) that recorded the basic OpenSearch fields first: short_name, description, input_encoding, and url. I populated the fields with some basic search engines that folks use here at William and Mary: all the libraries, Google Scholar, Ebrary, JStor, EbscoHost, ScienceDirect, and our federated searching engine). I wrote a search proxy to rewrite the search URLs, though it’s really not necessary (and I may change that).

Since I got on the kick, I figured I’d write something up real quick for Vufind too. By adding a few lines of code, folks will be able to add the Vufind instance to their search list without doing much!

After I get the code a bit cleaner, and work through some of the other “issues” with search providers who use ‘POST’ for queries, I’ll add some code.

A while back I got a couple of Sun Thumpers (24TB each) to help out with our storage needs in the library. I’ve gotten to the point to deploy them. I have to admit I really dig the Solaris admin tools (web based ILOM) and the ZFS configuration tools.

The idea for the first Thumper is to make that the primary storage for of content for our institutional repository (we’re running DSpace). The last couple of days I’ve been getting down to a really geeky level in systems administration. I created an NFS share, but the question was on how to mount it. We use nfs3 in the integrated graphics labs to mount the high performance computing clusters, so I did this for DSpace and added an fstab entry

<server>:/dspace /dspace_nfs nfs rw,nosuid,hard,intr,rsize=32768,wsize=32768,tcp 0 0

I then ran some test to see what kind of throughput I could get.

time dd if=/dev/zero of=/dspace_nfs/dspace/testfile bs=16 count=16384

I got a result of

262144 bytes (262 kB) copied, 0.088866 seconds, 2.9 MB/s

Then, just to compare it against normal disk I/O, I did the same on the local hard drive

time dd if=dev/zero of=~/testfile bs=16 count=16384

This was quite a bit faster (as you probably would guess)

262144 bytes (262 kB) copied, 0.041865 seconds, 6.3 MB/s

To test the read speed, I took the same file and brought it back.

time dd if=/dspace_nfs/dspace/testfile of=/dev/null bs=16

On the NFS mount I got

262144 bytes (262 kB) copied, 0.017822 seconds, 14.7 MB/s

and on the local file system I got

262144 bytes (262 kB) copied, 0.015867 seconds, 16.5 MB/s

I was kind of surprised at how close the reads were. It’s not a huge file it’s moving (our larger files are around 350MB), but it’s reasonably consistence with an arbitrary file size of the PDFs we have in the collection.

I was corresponding with a colleague who’s been doing this way longer than I have and he suggested using a larger blocksize and writing/reading some files larger than the RAM size. I also wanted to test against NFS4 (I was using NFS3 in the fstab entry).

To do this, I just created a mount point and mounted the filesystem.

mkdir /mnt/nfs4
mount -t nfs4 <server>:/dspace /mnt/nfs4

I ran the same test on the new mount and got a result of

262144 bytes (262 kB) copied, 0.055023 seconds, 4.8 MB/s

and for the read

262144 bytes (262 kB) copied, 0.014205 seconds, 18.5 MB/s

So, it looks like NFSv4 is much improved over NFSv3!

The fix was pretty quick, but took a couple of minutes to locate. On top of installing the new package, you also need to run the vboxdrv setup to recompile the kernel module.

sudo /etc/init.d/vboxdrv setup

After you run this, everything runs wonderfly again

To get up and running with Solr, you’ll need some type of Servlet container. Typically when folks start talking about servlet containers, they’re talking about Tomcat or Jetty. In fact, Solr comes with Jetty 6.1.3 (they haven’t upgraded to 6.1.5 yet in the distribution). You may also hear about Resin, but in my experience, it runs a bit slower than Jetty and Tomcat. As a small note, servlet containers are different than J2EE application servers like JRun, Geronimo, GlassFish, and JBoss (which use servlet containers like Tomcat and Jetty, but also have EJB containers and can handle other types of logic). If you have a J2EE application server running, you can easily use Solr, and if not, consider using Jetty or Tomcat as your container server.

Since your environment can be as varied as there are IT departments, I won’t try to cover everything. Essentially you need to have at least the Java 1.5 JRE. However, I would strongly suggest the most current Java JDK (and not the JRE) as it has performance enhancements to run in server mode (with -server). If you don’t already have this Java version installed on your server (assuming this is the same server running CF), don’t worry, ColdFusion will still work if you install the required Java runtime.

Essentially the process for deploying Solr, once you have a servlet container up-and-running is to drop the solr.war file into the webapps directory on the server. It won’t do anything at this point as you need to set the configuration files for Solr. The easiest way to do this is copy the files from example/solr into a new directory (which I will refer to now as solr_home).

You can tell Java about the home directory by setting the solr.solr.home (-Dsolr.sol.home), set the JNDI lookup (“java:comp/env/solr/home”), or just throw it into the JVM’s working directory (the default path is ./solr). Now you just need to make sure everything is running. Just point your browser to http://<server>:<port>/solr/admin. You should then see the administration interface (you may need to restart your servlet container to get everything working properly), but it’s not an administrative interface like you get in CFAdmin. This is more of an informational administration panel. You can make sure everything is running, that there are documents in your index is set up properly, check out the schema and configuration files, and thread information. Really the only thing you can administer here is the log level.

For some more specific notes on intalling Solr in Tomcat and Jetty, check out Solr’s wiki. In particular, if you’re going to need multiple instances of Solr to run, pay attention to the sections on Multipe Solr apps on those wiki pages. ]]> http://www.liquidfoot.com/2007/10/05/solr-and-coldfusion-setting-up/feed/ 0 http://www.liquidfoot.com/2007/10/04/coldfusion-solr-client-solcoldfusion/ http://www.liquidfoot.com/2007/10/04/coldfusion-solr-client-solcoldfusion/#comments Thu, 04 Oct 2007 22:19:47 +0000 Wayne http://www.liquidfoot.com/?p=182

As I hinted at yesterday, I was close to having some code in the pipeline to abstract using Solr. I’ve finished the initial code with the following built in. Here’s a brief setup guide to start playing with the code.

First, you’re going to need to grab the latest release version of Solr (currently 1.2). The only real requirement to run this software is that you have a JRE of 1.5 or higher. Untar/zip the file somewhere convenient and open a command prompt. Get to the example directory in the apache-solr.1.2.x folder (cd /example). To start up the sample server running Jetty, just issue the following command:

This will start a new instance of the Solr server on your computer on port 8983. You can make sure this is running by navigating to http://localhost:8983/solr (NOTE: this is a link to your computer. If you get an error, it’s because your computer isn’t running an instance of Solr on port 8983).

At this point, it’s probably good to send you over to the Solr website to take a look at their tutorial. Go ahead. I’ll wait…

…

Great, you’re back.

You’ve seen some basic inserting, deleting, and querying of Solr index data. You may have also noticed that there are clients for PHP, Ruby, Python, and Java…no ColdFusion. I want to do a little more testing on this before I submit the patch, but I’ve added the initial code as an encosure here to do updating, deleting, and searching in Coldfusion.

The CFC SolColdfusion should be in the path org/apache/client (at least that’s where I’m putting in for the purposes of this initial demonstration). The initialization takes one required parameter (the Solr host) and then has two optional parameters (port and path).

To set this up, create an instance with

Now, there are a lot of different parameters you can send to Solr to perform different queries. And, since some of these key names can repeat, I chose to implement sending these parameters as an array. So, let’s set this up.

These parameters are basically what are the defaults that Solr will return back to you. If you want highlighting, you would need to add two additional row vectors with ‘hl = on’ and ‘hl.fl = ‘.

Searching is straight forward, taking a query, the start row, number of rows to return, and the array of parameters:

This searches all fields and all content and returns back an XML document with the search results in it.

In the result node, you’ll see that Solr returns an xmlAttribute of

of 0 (assuming you don’t have anything in the index). Let’s add an example document from the documents that come with Solr.

You’ll notice I used a commit and optmize statement. Neither of these statements are necessary every time you add a document, but be aware that Solr caches documents and won’t flush the new documents to disk unless you either commit the documents or the mergefactor setting you used in your solrconfig.xml file has been reached.

Now, let’s delete this document…

Don’t forget to commit deletions to the index!

There’ll be more soon (add multiple documents, delete by queries). In the mean time, try it out. If you have any comments, questions, concerns, whatever, let me know.