Generally, installing webapps is a pretty painless process because the majority of them are written in PHP. Wordpress is a PHP app, as is Drupal, Mambo/Joomla, phpBB, and a bunch of other widely used applications. All you have to do is copy the package files to your web directory, make the database, run an install script, and you’re up and running.
Trac is a bug tracker, wiki and Subversion browser, all in one package. Trac is an oustanding piece of software, and very lovely to look at; seeing your code with syntax highlighting and line numbers on the web is a thing of beauty (well, if you’re into that sort of thing, anyways). There’s just one problem with Trac: it’s “really difficult” to install on Dreamhost. It’s no picnic. Especially if you’re not comfortable with Linux. Or building from source. As a certified Linux noob, I am all that and more. And yet I thought, hey, how hard could it be?
If you’re not insane or a nerd, you’ll want to step off here. For the rest of you, into the breech!
My .bash_profile is already modified to take care of Django’s needs, so I had to change the environment variables somewhat to keep the Django paths I’d already put in. I also made sure to keep :$PATH at the end of my PATH statement, just to make sure everything loaded in the proper order, though as I’m still unclear as to when env variables work and when they don’t, this may be mostly pointless.
Trac, Clearsilver, SQLite PySQLite and SWIG all installed as in the guide, with minor modifications to the Clearsilver install. So far, so good.
Subversion is where everything falls apart. First, Subversion complained that it couldn’t find the apr packages. I have no idea what those are, but after searching and trying several solutions, I hit upon the Dreamhost wiki’s entry on upgrading Subversion on Dreamhost, which added a download and untarring of a dependencies package. Perfect!
Except not, mainly because once Subversion was all installed and I tried the python -c test, I get this:
Traceback (most recent call last):
File "<string>", line 1, in ?
File "/home/robm351/lib/svn-python/svn/client.py", line 19, in ?
from libsvn.client import *
File "/home/robm351/lib/svn-python/libsvn/client.py", line 5, in ?
import _client
ImportError: /home/robm351/lib/libsvn_ra_dav-1.so.0: undefined symbol: SSL_load_error_strings
Thus follows several hours of head-bashing and rebuilding. The flipturn.org guide suggested I add LD_PRELOAD=libssl.so to get around a broken dependency. So I went and entered that into my .bash_profile and tried rebuilding: nothing. The filpturn guide also pointed to a longer, more involved solution that the author felt was “unnecessary” in light of the LD_PRELOAD solution, but that didn’t work for me so it was the long, convoluted solution for me.
Basically, something was broken somehow in Neon having to do with OpenSSL, so to solve the problem I simply had to build a new OpenSSL, then rebuild Neon linking to the new OpenSSL library, then rebuild Subversion pointing to the new Neon library. Just figuring that much out was a triumph on my part, I like to think. But then I built OpenSSL and Neon, and suddenly I had no idea where Neon went. Every attempt to build Subversion with --with-neon=[some path] failed; the build process jsut wasn’t finding Neon. At first I figured it was because I’d installed the wrong version; turns out Subversion v1.4.3 doesn’t play nice with Neons above version 0.25.5, and I had 0.26.something. FINE. Kill the old Neon, build a new Neon, rebuild Subversion. Still no dice; same error, can’t find the library.
Strangely enough, Trac works fine at this point because Subversion imports into python just fine. So I go ahead and start building the Trac environment, connecting my repository, and feeling pretty good about myself. Then I try to install the Webadmin plugin. The natmaster guide uses Subversion to download the WebAdmin package, which is when Subversion begins complaining of an “unsupported URL scheme.” Unsupported? What the hell does that mean? Turns out if Subversion can’t find the Neon library in the path you fed it, it doesn’t build in Neon support at all. Neon is the HTTP library Subversion needs to access any web URL. Hence, no Neon, no http downloading. Fun. So I wasn’t off the hook after all.
More bashing of heads against walls, and I still can’t get that damned python -c test to work without giving me an SSL error. Finally, an angel from above lands on my shoulders and whispers the answer in my ear. Well, actually, it went something more like this:
“You idiot! Remember in the flipturn guide, when it said to set the LD_PRELOAD environment variable? You never actually did that in the index.fcgi handler, so when python runs through FastCGI it has no idea that it’s supposed to load libssl.so first! Did you REALLY think setting LD_PRELOAD in your .bash_profile was going to do it? Didn’t you learn anything from when you tried to install Django?”
So I stuck the LD_PRELOAD variable in my index.fcgi, and what do you know? I wasted a couple of hours chasing my own tail for nothing, because suddenly it all works.
I’m never doing this again.