|drostie.org mostly out of limbo
||[May. 12th, 2009|03:46 pm]
I had underestimated the previous months' schoolwork, which really required a bunch of effort. But the end of April and early May, I pushed very hard, and basically the entire Django backend of drostie.org has been written. This included one day where I just sat down and coded my own admin interface, because I didn't like the one that came with Django and I could tell it was only a ~ 1 day project. The admin interface looks like this:|
After Apache was too much of a resource hog for my taste, I elected to start running Django out of Lighttpd. Surprisingly, I found Lighty to be more versatile than Apache -- though the documentation is *abominable* and there were several features missing. (For example, client certificate support is presently restricted to LDAP, which is quite like saying "You can pick your nose, but only with this shotgun.") But mod_auth can work for my administrative backend just as well as a client cert, so long as Firefox remembers my password and my computer doesn't die spectacularly.
In particular, here's the problem that drove me to lighttpd: I want several subdomains, like code.drostie.org and aca.drostie.org and muse.drostie.org and odd.drostie.org and so forth. They shouldn't share file namespaces (a text file on code shouldn't be visible from odd; the images on odd shouldn't be visible from code), except for some common files that should only be in one place, so that I can update them all at once. That's the business of a rewrite engine, of course, which Apache can only do with mod_rewrite voodoo; and mod_rewrite is a notoriously difficult module for Apache because it implements basically a full-featured scripting language in a medium that was never designed for it. I basically learned Lua overnight in order to program a quick mod_magnet script to do the exact redirection I wanted. I still don't like Lua, but I can live with Lua.
Meanwhile, Apache does *not* like partial host-awareness: you're supposed to either run virtual hosts or to run a single dedicated host. Well, with the rewrite script, you can see that I don't need host-awareness usually -- the file logic is rewritten manually for that. But, here's the problem: some of my pages (the admin ones) use HTTP-based logins to save some coding effort. This *has* to be host-aware, since the server has no other direct way to distinguish these pages from any other page served by Django. (I could have also hardcoded the authentication credentials into Django, but I originally wanted to use an SSL client certificate to do this process. I'd still like to switch over, whenever lighttpd actually implements client certificate support.)
Now, these subdomains must also direct their django calls to some central django applet, which I decided from the start would be host-aware and would implement certain "Projects" (code, odd, aca). This is *supposed* to be done with Apache's mod_python or mod_wsgi, but this also tends to break with virtual hosting. (When I tried to have WSGI kibbutz on another server's WSGI process, it got angry at me.) The native separation in Lighttpd between the web server and the FastCGI Django server made complete sense to me, in this respect. And I had no real issue setting up the pidfiles or the Unix socket to make it all work nice and smooth.
It's all coming together. "Push, push, push," I keep telling myself. "Do something -- anything -- even if it's typing a meaningless line into the source code. Get your brain moving on the project and progress will just happen."
And it is.