Install Python 2.5 on the new server from source, because dev Django prefers it and the distribution’s package is 2.3. Install dev Django from their subversion. Install PIL and flup, from source, because the docs for the app you’re setting up says it’ll need them. Grab and build pysvn because the app you’re setting up will, in fact, need it. Grab development subversion source, so pysvn will compile against it. Install subversion from source, because the source you built pysvn against is newer than the distribution’s package. Grab and try to build MySQLdb (the Python library), because although this is a private deployment, it is a deployment, so you might as well not use sqlite, plus you found the Django ORM isn’t 100% with sqlite anyway (apparently you can’t re-use a ForeignKey field as a primary key, with sqlite). Find the MySQLdb configurer can’t find
mysql_config, so it can’t configure the build. Poke around on your other server, where the app already runs on Django’s runserver (not for deployment), and rediscover you get
mysql_config from the distribution’s “testing” MySQL 5 package, not the package provided by your company. So reinstall MySQL from the testing repo package. Install
mod_python, because although it’s a private deployment, it’s a deployment, and you guess you shouldn’t use Django’s runserver. Configure the app to run under
mod_python can’t find the
django package. Find, oh, yeah, the packaged
mod_python will use the packaged Python 2.3, not the manually built 2.5, so it’s looking for packages under
django is actually installed. Try to have
mod_python include 2.5’s package paths. Find there are, in fact, weird errors that are doubtless more work to fix than just rebuilding
mod_python against Python 2.5.
Have some sleep, and most of a Saturday.
Grab and try to build
mod_python from source. Google around to figure out what
relocation R_X86_64_32 against 'a local symbol' can not be used when making a shared object; recompile with -fPIC means. Find there’s a
mod_wsgi, and decide to use it, since Django apps don’t necessarily use any special
mod_python facilities anyway. Find building
mod_wsgi has precisely the same error. Find the error means that, indeed, you didn’t build Python 2.5 with shared library support, which both modules need to embed Python in Apache. Rebuild Python 2.5 with the right configure option (
mod_wsgi from source. Configure Apache for the Django app with
mod_wsgi. Configure the app’s media uploads directory so it’ll quit its whining and run.
See that it runs!
But remember you want to use LDAP auth for this private deployment.
Look for how to set up the Django app’s LDAP backend. Find it’s only documented in the mailing list post by the author of the original patch. Install the
python-ldap package, as it was noted as required (of course) in the mailing list post. Set up LDAP in the app semi-right but find you can’t tell, because the app eats all exceptions, the only error it actually shows being “Invalid username or password.” Fiddle with the configuration settings, restarting Apache and trying to sign in again. Fix the app to expose the real error, which is that you thinkoed in the app’s
settings_local.py configuration file: you tried to define
AUTHENTICATION_BACKENDS as a single-item tuple, but you left out the comma that’s required to turn a string in parentheses into a tuple. Realize also that, huh, the
ldap package is missing. Realize that’s because (of course) you installed
python-ldap from a package, meaning it’s installed for the packaged Python 2.3, not your manually built Python 2.5. Grab and try to build
python-ldap from source. Find it doesn’t build against the
openldap-devel package that came already installed on the server; the package is for OpenLDAP 2.2, but the
python-ldap builder is hardcoded to look for for OpenLDAP 2.3. Try to update OpenLDAP from your distribution’s testing repo (it has 2.3), but find it “conflicts” with the existing
openldap 2.2 packages, and you’d have to reinstall every damn thing if you removed and reinstalled
openldap. Look for a download for an older version of
python-ldap (the package was 2.0.1 but you were trying to build the new one, 2.3.4). Don’t find one on the official download site. But it is a package, so
yum search then Google for a source package. Install the
python-ldap 2.0.1 source package you do find. Untar and build and install
python-ldap 2.0.1 from source. Confirm in the python shell that the
ldap module loads. Try using LDAP to sign into the app again. Find now it outright crashes with glibc malloc protection faults (
double free or corruption (out) or
free(): invalid pointer). Wonder if all this is really worth it.
Find that, OTOH, these Friday and Saturday nights are somehow still more satisfying than the preceding week.