markpasc (markpasc) wrote,

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. Find 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 /usr/lib/python2.3, not /usr/local/lib/python2.5 where 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 (--enable-shared). Install 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 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.

Tags: let's go shopping, unix is hard
  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened