Im currently exploring Rabbit MQ and had a few issues getting up and running reliably on Mac OSX. The problem wasted so much of my own free time that I thought it would be a good idea to post about it and perhaps it might help others in the future.

The Problem

The broken boots normally as the rabbitmq user defined in the system – however, when trying to connect to it using rabbitmqctl you get the following error (repeatedly):

macbookpro:~ timperrett$ sudo rabbitmqctl status
Status of node rabbit@macbookpro ...
{badrpc,nodedown}
...done.

The Solution

After many hours dabbling, and checking, checking again, rechecking my user and permissions setup, I found that it was actually to do with the way in which ERlang networks. Essentially, I was running the broker on:

rabbit@macbookpro

However, whilst I could ping the host “macbookpro” from terminal, it appears that Rabbit MQ needed it defined in the /etc/hosts file in order to work correctly.

Both strange and annoying, perhaps this will save someone some time!

Well, after a long stint of having no decent MySQL support (as uProduce only supports up to version 4 out of the box. Other than my ODBC monkey patch there has been no version 5 support), I have managed to find a working, and critically viable, solution for using MySQL 5 with XMPie uProduce.

cherrycitysoftware.com sell (not that you can even call it that, its only $10) a little mysql driver that with a little bit of work you can make work with uProduce and uPlan – its nice to have MySQL back!

You can use a DSN with generic DB like this:

Provider=OleMySql.MySqlSource.1;Password=YOURPASSWORD;Persist 
SecurityInfo=True;User ID=YOURUSERNAME;Data Source=YOURDBHOST;
Location=YOURDBHOST;Mode=Read;Trace="";Initial Catalog=INITIALDATABASE

Initial results are great – its working cleanly and quickly – good times with MySQL!

Short Story

libxsl-ruby is a nightmare to install. If you can indeed get it to install at all. I couldnt get the bloody thing to install at all on my 10.5 OSX box; and thats with ALL the required libs installed. I get the impression that its not very well maintained anymore and the project following has dropped off.

I turned to ruby-xslt – based on REXML, so yes, its slower. If your looking for speed then persist with the libxsl ruby path, but otherwise, save yourself a lot of time and just use this. Its vastly simpler!

Long(er) Story

Libxsl sucks. Strong statment I know. I would say im a fairly techincal chap, and ive just spent, nay, wasted, the last 3 – 4 hours trying to work out why libxsl-ruby wont install. Thats a bit of a bugger indeed. Who knows what the problem is, but ultimately its less portable due to reliance of the Gnome XML parsing libs. Granted there very fast, but thats no help at all if you cant even install them.

REXML vs Libxml is a non-contest. We all know libxml is significantly faster – if you need that speed then i strongly advise you to continue with libxml; it will pay dividends in the end. If however your not going to need very fast parsing, then really, save yourself a lot of wasted time and use REXML.

REXML is bundled with the ruby distribution, so its also a lot more portable that libxml2. Anyway, if your even still reading, stop now, and bosh this into your terminal:

sudo gem install ruby-xslt

Job done.

Well, its time for production now – remember that tutorial way back about building PostGRE on OSX? Well Ive just done it on Ubuntu Server, but from scratch, with all the GIS bells and whistles ;)

Lets tuck in…

First off, rather than me labour the point (anyone familiar with linux will breeze this part) check out this really usefull post – its got all the things you need for doing the actual compilation and install.

There are however a few Ubuntu related “gotchas”. Firstly, after you install GEOS, both ldconfig doesnt yet know about the new libs you’ve just installed at /usr/local/lib. To make it read the new libs you’ve gotta create a new file called ld.so.conf and stick it in /etc – fill it with the following:

/lib/
/usr/lib/
/usr/local/lib/
/usr/X11R6/lib/

Then to make it read in the new config, do this:

/sbin/ldconfig -f /etc/ld.so.conf

To check that its now reading your GEOS libs, run the following, and make sure you see a similar output (depending on the version of GEOS you installed)

$ /sbin/ldconfig -p | grep geos
    libgeos_c.so.1 (libc6,x86-64) => /usr/local/lib/libgeos_c.so.1
    libgeos_c.so (libc6,x86-64) => /usr/local/lib/libgeos_c.so
    libgeos.so.2 (libc6,x86-64) => /usr/lib/libgeos.so.2
    libgeos.so (libc6,x86-64) => /usr/lib/libgeos.so

Another helping sir?

OK – were good to go on that front. The key thing now is that we need to be able to add GIS functions and type handlers to any given database. Provided you set up the ldconfig stuff correctly, doing:

su -- postgres /usr/local/pgsql/bin/psql \
-f /usr/local/pgsql/share/lwpostgis.sql \
-d yourdbnamegoeshere

If this didnt work, you have a problem with your ldconfig! There are fixes out there which advise changing the lwpostgis.sql script, but in my personal opinion, thats not fixing the problem, thats just dirtying a fresh install.

Next, after I had everything up and running, it was puzzling me that there was no init.d script available (the google force was not strong today), I rummaged around in the source I downloaded, and found a startup-scripts dir in the contrib directory, result. Take that script, and bosh it into /etc/init.d and do:

sudo /usr/sbin/update-rc.d postgresql-8.2.5 defaults

Then you have a fully working PostGRE install with GIS sugar!!!

Hopefully this might help someone one day :)