Allan Saddi's projects blog

I added a umask keyword parameter to both fcgi.WSGIServer and fcgi_fork.WSGIServer. If given and binding to a UNIX socket, the umask will be changed right before the socket is bound. Afterwards, the umask will be restored.

This should allow one to change the file permissions of the socket without altering the umask of the entire application. (If you need it to be, say, group-writable or world-writable.)

I took the time to clean up (and that mainly involved ripping out the version checking code) both VanaClock and VanaClockMIDlet. I then threw in a copy of the GPL and slapped the standard GPL header on all of my source files. And now this somehow means it's open source.

Anyhow, see their respective pages for download links.

I got an inquiry about VanaClockMIDlet today. It turns out my webserver was misconfigured and was using the text/plain MIME-type for .jar files (bad!). After fixing that, I found out from the user that though it ran, certain things were broken. Unsurprising, actually, since the sister project, VanaClock, developed overflow problems that I eventually corrected.

I was about to tell him "I'm sorry, I can't do anything" (because I don't have a MIDP development environment anymore), when I decided to just give it a try. So I tracked down MIDP for OS X, ProGuard, and an illusive little Ant task named JarSizeFix. After updating the build.xml file and correctly guessing where the overflow was occuring, I managed to create a fixed version.

At least, it appeared fixed on the simulator.

Anyway, VanaClock and VanaClockMIDlet are projects that I've openly abandoned. Yet I still get feature requests and other inquiries about them now and then. And for some reason, I feel the need to keep the source code locked up. Maybe because they were my first non-trivial Objective-C and Java applications (respectively). There's an element of nostalgia... or embarrassment. Ah well, someday I'll set them free. And oddly enough, I will probably release them under GPL (rather than my favorite 2-clause BSD license). I just need to be bugged about it more...

I decided to put on my sysadmin hat and do a little work on kalahari (my co-located server). I didn't really have a plan. And I'd been upgrading things here and there over the past few weeks. (Like bringing Subversion up to 1.3.1 from 1.1.x. Thankfully that went painlessly.)

I decided to set up Trac, just to give it a try. Rather than install it through the FreeBSD ports system, I installed most of the dependencies and did a manual install. It was surprisingly painless. The Trac files and environment live in the trac user's home directory... and I run Trac using the WSGI patch + flup's AJP server. Quite simple.

As a digression, sometimes I wonder if people wonder about my affinity for AJP. My webserver has both mod_fastcgi and mod_jk. (Alas, I'm not brave enough to upgrade to httpd 2.2.x yet, for the built-in mod_proxy_xxx modules.) But I prefer to run web applications/services as a different user. CGI/FastCGI would require me to set up the application to run as www:www... and just setting up the permissions alone would be a nightmare. (Not to mention the insecurity of running as the generic www user... not that I don't trust the other users of my server. ) I can't use SCGI because mod_scgi doesn't coexist peacefully with mod_fastcgi under httpd 2.x. And I realize FastCGI apps can be run in an "app-server" mode for lack of a better term (as a manually spawned process), but configuration of AJP seems so much simpler.

Well, that and I run Tomcat as well. I would say the web applications/services on kalahari are now evenly split between Python-based and J2EE-based platforms. (Although one internal app still runs on WebObjects...)

Anyhow, I also decided to revive the old wiki, the main use of which was to serve the help pages for blog.flup.org. I did the same as I did with Trac. Manual installation, WSGI backend + AJP server from flup.

Lastly, I revived flup.org/u (my simple URL shortener). I took it down some time ago because of abuse, but it was always my intent to restore it once I had some basic authentication/authorization built in. Well, with the CAS server now long in place, it was pretty easy. As an aside, I've been itching to write some sort of CAS WSGI middleware, but I see Paste already has something. Still, it would be nice to have some sort of generic filter/interceptor framework. If not for WSGI, then for flup's Publisher.