Sunday, November 15, 2009

Testing with IronPython

We all know that unit testing is important with software development. But the tests themselves are not always so black and white. IDEs like SharpDevelop or MonoDevelop have things like NUnit to help test a wide range of things like equality, identity, collection, and etc. These are great tools, but what happens when you don't know what the data being gathered/generated should be? How can we assert something when we don't know what it should be?

My situation was this, I wrote a C# library for work to pull customer information and create reports based on the customer's monthly fees. Since the fees vary between customers, it was difficult to make sure that the data being pulled was accurate. Since I have been losing time with this portion of the project, I decided it would be a good time to test the abilities of Iron Python.

Why use Iron Python? Couple of reasons. First, since this is a .NET project, Iron Python can load the library through the clr.AddReferenceToFile command. Second, it can be ran as a script rather than compiling a new C# project. This means that I can alter/update the script and rerun it when I need to. Nice convenience.

What I did was write a script to pull in the .dll library and call the various objects to display the information stored in them in an organized way. Like so...

import sys,clr

clr.AddReference("System")
from System import *

if __name__ == '__main__':

    dllPath = Environment.CurrentDirectory.ToString() + r'\bin\Debug'

    sys.path.append(dllPath)
    clr.AddReferenceToFile('nameOf.dll')

    from nameOfNamespace import *

    print "Start going through the objects..."
From here, I can create test objects from the dll and see if what data is being pulled and confirm it with external sources to make sure it is accurate. The first time I ran it, I found (and corrected) a few missteps on my part. Within the first 30 minutes of running it, I was able to fix problems that would have taken me much longer in the final product. Pretty cool.

Sunday, November 8, 2009

Troubleshooting Hardware can be a pain in the a$$ (note the dollar signs)

Ever since I have tinkered with computers and machines from one type or another, hardware has always been my achilles heel. Not only is it difficult to troubleshoot but it can be expensive as well. There was this one time along time ago where I had a 500+mhz Pentium 3 machine that would lock up at random times and when I would escape to the BIOS, the BIOS would lock up also. How do you troubleshoot something like that? I remember calling up my dad to take a look at it and when he saw the BIOS freeze, he was as stumped as I was. I ended up replacing almost everything in that computer and it still ran like crap. To this day, I don't know the exact cause(s) of that machine's problem but that was years ago.

So what brought this on? About a week or two ago, my OpenBSD machine started displaying hard drive errors out of the blue. What was nice was the error message displayed was pretty specific which was easier to figure out but it meant that I would have to buy another hard drive. However, awhile after I removed the offending drive the error started appearing more frequently at different times for different drives. At that point I started thinking it may have a bad hd controller on the board. The board is an older DFI board that has been holding up for about 4+ years so it was plausible that the board was the issue. I was about to look into new mother boards when I thought about trying a new harddrive cable. So I pulled out an old hard drive ribbon cable and gave it a go and everything started working. I almost spent money on a new hard drive and motherboard when all I needed was a new hard drive cable. I should have known based on how that cable looked. I'm surprised it lasted as long as it did...

So learn something from this kids. Hard drive failures could be just bad cables.

Saturday, September 26, 2009

Mono for all

Everytime I think about this post, I'm usually away from my machine to make it. I finally thought about it near my machine...

Ever since I heard of the Mono Project, I was always intrigued. I always thought the Mono project had a good purpose behind it. When Microsoft comes out with new software, 90%+ of the time the new software only works on Windows (with the few exceptions like Office which they port to Mac). And what's worse is that these new become popular within the workplace for whatever reason. Projects like Mono make it possible for people like me to develop .NET software on non-Microsoft platforms. One would think that projects like this would not be as good as the real thing. That person would be surprised.

A few years ago, when Mono was still in the 1.x range, I gave it a shot to see how it would look and run. If I remember correctly, they were still trying to tighten down their version of WinForms during that time which make sense because when my sample project opened, it didn't look quite right. It didn't look awful by a long shot. The fact that it opened at all was a nice surprise. It just didn't look as polished as it did on Microsoft.NET. So a few weeks ago, I decided to try out another old .NET project I had laying around on Mono to see how it would look. This time it was on Mono 2.4. This time the project came up and looked SOOOOO much better than it use to. There were still minor oddities (like text on a tab didn't show up all the way) but there was nothing that would have prevented me from distributing the project on Mono if it was still actively being developed. The functionality that I did test on my project worked just fine too. I don't use p/invoke or anything else in my projects that would tie it to a Windows machine so I don't think that much else would be broken.

These guys on this project have busted their asses these past couple years to bring .NET to non-Windows machines and their work is really shining through. If they keep it up, I wouldn't be surprised if Mono usage would rise drastically. If you haven't already, give it a try.....

Wednesday, September 23, 2009

Django 1.1 imported to OpenBSD Current

It is kinda old news now but it was nice of the powers that be to update the ports tree to the most current version of Django. Even though it wasn't committed in time for 4.6 (timing was off between the Django release and ports lock), it should be in for 4.7. I'm just happy that the 4.6 release will have something greater than the 0.96 version of Django.

Go ahead and preorder your copy of OpenBSD 4.6 today!!!

Thursday, September 17, 2009

It's amazing what's floating out there

Since initially toying with Lighttpd last month, I decided to set it up on my home machine to see how it can handle a simple django site. After some tinkering and some development with a site, I got it up and running. It was pretty cool. I let it go for a couple of days before deciding on checking the logs to see how they were setup. The first few lines were from me doing tests but the rest of the lines were interesting. There were many lines that looked like someone was scanning for phpmyadmin and other people looking for ecommerce components, AppServ vulnerabilities, and someone referencing a site called www.wantsfly.com. These kinds of attacks seemed pretty consistent until a few days ago when the entries stopped. The bottom line is that one must protect themselves regardless of the type of website. I was hosting at home with no advertising of any kind and I was hit with these attacks. Luckily, I don't use phpmyadmin, AppServ or any kind of ecommerce software for my site.

So read your logs boys and girls. Learn about the kinds of attacks that are out there and protect yourself from them...

Sunday, August 30, 2009

Hello Lighttpd, nice to meet you

Since I've been trying to wrap my brain around web server configs for the past couple of weeks, I thought that I would give Lighttpd a try since I've read quite a bit of positive reviews of it. I must say, I wish I went this route the first time. As a test, I thought I would setup django 1.1 on OpenBSD using Lighttpd instead of the native httpd that comes with OpenBSD out of the box. I was able to get it going in about 10-15 minutes after setting up the configure files using the how-to guides on Django's site. It was nice to see that good admin login screen after little tinkering. The only draw back that took me longer than I wanted was that Lighttpd was adding unwanted items to the url that prevented me from logging in completely. However, this was easily rectified by adding the following line to the settings.py file:
FORCE_SCRIPT_NAME=""
This may be the route to take with django on OpenBSD systems from now on because of the easy to use settings. Just remember to install flup...

Sunday, August 23, 2009

mod_wsgi on OpenBSD - take 2

Before we get going, I would like to point out that this information is provided to you at your own risk. You should know how to modify configuration files and rebuild programs before you attempt to perform the steps above. I am not responsible for any damage, loss of data, or loss of use if you attempt to use any of this information on your own systems.

Sorry, I have to cover my a$$. :)

Let's get this thing rolling, shall we?

As I stated in my previous post, the only ways to get mod_wsgi working with the version of apache that comes stock with OpenBSD are:
  1. Recompile apache with the pthread lib -or-
  2. Use the LD_PRELOAD trick to preload the pthread library before running httpd
If you are squeemish on recompiling, go ahead and use the LD_PRELOAD trick. Please keep in mind though that you need the exact path and version number of pthread for it to work. This means that you also need to keep track of the version number of pthread whenever a new version of OpenBSD is released. Example:
LD_PRELOAD=/usr/lib/libpthread.so.11.0 apachectl start
To be honest, recompiling apache is a bit easier and less of a hand cramp. Per James Turner's post, you just need to add one line to the configure file: /usr/src/usr.sbin/httpd/src/Configure. At line 519 of the configure file, just add LIBS="$LIBS -pthread". So the section will go from this:
*-openbsd*)
OS='OpenBSD'
DBM_LIB=""
DB_LIB=""
DEF_WANTHSREGEX=no
;;
to this:
*-openbsd*)
OS='OpenBSD'
DBM_LIB=""
DB_LIB=""
DEF_WANTHSREGEX=no
LIBS="$LIBS -pthread" # Add pthread library
;;
Then rebuild httpd using the following commands. This is where I had problems last week. I wasn't rebuilding this correctly...
apachectl stop
cd /usr/src/usr.sbin/httpd
make -f Makefile.bsd-wrapper obj
make -f Makefile.bsd-wrapper cleandir
make -f Makefile.bsd-wrapper depend
make -f Makefile.bsd-wrapper
make -f Makefile.bsd-wrapper install
Then restart apache. Do this every time you install a new version of OpenBSD and you'll be able to use mod_wsgi.

Afer some more tweeking of the settings, I was able to get a sample django project to run under mod_wsgi. However, it wasn't without its quarks...

When I was testing the admin site under wsgi, I noticed that none of the css or other media files where showing up. I know it wasn't the project because it looked fine when using the fcgi method. I spent the better part of a day picking the site apart to try to understand why the media information wasn't displaying. I was using alias left and right and everything in between but nothing was working. After googling for a few minutes, I landed back on mod_wsgi's site on the configuration guidelines under the hosting static files anchor. The link to the actual spot is here. Well it turns out that the only time the Alias module takes precedence over WSGIScriptAlias on Apache 1.3 is when mod_wsgi is loaded before the mod_alias module. Ok, so I shoot over to the httpd.conf file to set mod_wsgi to load first when I notice that mod_alias isn't even listed in the conf file. Wait a minute, so that mean... ahh crap. mod_alias is statically compiled into OpenBSD's apache. So in order for alias to work with wsgi is to
recompile apache again....shit....

Nope, ain't gonna do it just for the media files. That's just too much work for something this small. An easier, and the recommended way per the django folks, is to just setup another site or virtual host just to host these files and point to that site in the settings.py file in the project. Like so:
ADMIN_MEDIA_PREFIX='http://localhost:8180/media/'
You can set the alias with the virtual host like you would normally, just make sure you point it to the correct chroot path where the django files are kept. On OpenBSD, this should be:
/usr/local/lib/python2.5/site-packages/django/contrib/admin/media
This would probably be a better setup anyway because you don't have to worry about aliasing the media files for every django project you do. But going the mod_wsgi route on OpenBSD, it's really the only way.

With this being said, this may be the way to go in the future. However, since mod_wsgi is not in ports (yet) and considering the recompiling needed in order for it to work, you probably won't get much support as you would the fastcgi method of setting up django on Openbsd's chroot apache server. But at least the options are starting to grow...

Friday, August 21, 2009

Old Legacy of Kain Defiance promo



Another thing I thought I would share while going through some old files. I grabbed it from Eidos back in 2003 when they were promoting that game. I don't care what anyone says, the Blood Omen/Legacy of Kain series was one of the best series I've ever played. It has one of the best told stories in game history and the voice acting of everyone involved was is unmatched to this day. If it weren't for time constraints that the company faced during development, I'm sure it would have been even better. Too bad that they haven't made another game since then.

Eidos was sold to Square enix earlier this year so I don't know if they are going to put any more money behind this series. I would love to be proven wrong though....

Thursday, August 20, 2009

IronPython on non-Windows system!

Michael Foord went ahead and replied to my question:
Well, advantages IronPython has over CPython:

* AppDomains (restrict security priveleges of untrusted code)
* Access to .NET / Mono libraries
* Threading without the GIL (scale pure-Python code across multiple cores)
* Easily create applications with multiple isolated Python engines
* Easy to compile applications to binary and make binary distributions
* Much easier to extend with C# than CPython is with C
* Through the DLR you get interoperability with C# / F# / IronRuby / IronScheme...

Some of these are more compelling than others of course, YMMV. :-)

In addition to which IronPython can be used as an easy to embed scripting language for applications written in C#. *If* Mono is useful (which I think it is) *then* IronPython is useful...

This response really does give clarity on what I was trying to understand. Today, I use Ironpython for scripting projects that I need done quickly. I haven't had the chance to explore it further due to time constraints at work (when I get home, I don't wanna think about work :)). I bought the Ironpython book as well to help get me further along the road. So thanks Michael for your insight in this.

They should have these facts posted somewhere on the Ironpython site like a Iron vs C wiki or something like that. If they do, it should be easy to find.

Wednesday, August 19, 2009

Didn't expect that to happen

It's funny the way things work in life...

A few days ago, I wrote a post on Ironpython on non-windows systems, which is here, where I was trying to understand the benefits of having Ironpython on non-windows systems compared to cPython which is common on most of these systems. I didn't think much of it at the time because it was early in the morning when I wrote it and I figured it wouldn't really go anywhere. Well, I came back a couple days later to actually find comments to that post. I didn't realize anyone read my shit. That was a big surprise to me. The first comment was from guy named Michael Foord (whose name sounded familiar when I first read it) saying:
Because IronPython and IronRuby both work fine on Mono and are just as useful in environments using Mono as they are in environments using .NET.
This statement does make sense to me. I never thought that Ironpython doesn't work on Mono. In fact, I was able to compile Ironpython on my mac using Monodevelop a couple weeks ago which was pretty cool. However, I'm still trying to understand what benefits Ironpython has over cPython in a non-Windows environment. I responded to his comment yesterday in my comments section but I don't think that was the best method. Oh well. Live and learn I guess.

Well, today while at work. I was looking for a book in my desk when I saw the Ironpython in Action book in my desk with the name Foord on the spine. It took me a few minutes to remember where I saw that name before. After it sunk in, I slapped myself in the forehead. And to top it off, when I when to his blog, I found that he put a blurb of what I wrote on his blog. See here... The last thing I expected when I wrote that post was to get a comment and a link from the author of IronPython in Action. How'd that happen?

Just to reiterate. I'm not against Ironpython. I use it at work and it's good at the tasks I throw at it. I'm just trying to understand what benefits it has on a system like Debian or Redhat.

mod_wsgi on OpenBSD

Ever since I started learning about OpenBSD a few years ago, I always tried to find easier ways of getting Python to play with the version of Apache that comes with OpenBSD out of the box. Mod_Python was a nice try but it doesn't work with Apache 1.3. So I've been settling with FastCGI for the time being. Works ok and seems to have some advantages but it can be difficult to get going, especially in a chrooted environment. Well, while browsing the django docs I noticed that the preferred setup switched from mod_python to mod_wsgi. This was a nice surprise since mod_wsgi works with Apache 1.3 and 2.0+ (if I'm reading their docs right). To top it off, I found a port entry by James Turner that looked good. It was a couple versions old but still good to try. I threw the port into an OpenBSD test environment and it installed without issues. But that's where the fun ended.

After I installed it and tried to start the Apache server, the errors started to flow. Kinda disappointing but in mod_wsgi's defense, it's difficult to account for everything type of apache setup when creating a mod. I dug around a bit and found that the issue is with the chrooting and the pthread library. In an earlier post by James Turner pointed this out and two possible ways of getting around this issue. One is by adding a line in the httpd configure file to include the pthread library during the build and the other is by using the LD_PRELOAD variable. I recently tried to do the first item but during the build process, I received building errors. I'm thinking that the error occurred due to my setup but I haven't had a chance to setup another test system since then. Option two works to a point. It's alot of text to type and if the system reboots, you'll see errors during the boot up process. You can make this easier by editing the rc and apachectl files to include the LD_PRELOAD before the command. Even this makes the upgrade process more complicated because you have to account for the version number of the pthread library. These modifications aren't the most ideal but they are not impossible to do.

All this aside, this hasn't been imported into the OpenBSD port system. Although I am not sure of the official reason behind this, I'm thinking that these problems do not help. Until it is and this little quark is fixed, I would suggest sticking with the fcgi route for Django on OpenBSD. If you are daring enough, you can try yourself, at your own risk of course.

Saturday, August 15, 2009

IronPython on non-Windows system?

I was reading a post on Monologue this morning and there was a post getting IronPython & IronRuby into Redhat (I'm assuming the rpm repositories) and it got me thinking about this. My biggest question to this is, WHY?

Don't get me wrong, I use both Python and IronPython at work for various tasks. But at work, I am on a Windows machine. They both have their advantages. With IronPython, the main advantage that I see is its use with the .NET Office Interop libraries for accessing Powerpoint, Word, and Excel for automation work. Yes, Python is capable of interacting with Office too but there is a bit more prep work involved. Other than this, there isn't much that IronPython can do that cPython can't do and vice-versa.

With that said, I go back to my original question. Why port IronPython (or Iron anything for that matter) to a non-Windows system. Both Python and Ruby are already ported to the vast majority of non-Windows systems including some of the lesser known systems. And since Microsoft Office is only on Windows (and Mac but I'm not sure that Mono can or will work with it on a mac), I don't see any reason to bother.

But those of you out there who may be reading this and may be interested in porting something like this for whatever reason, don't let me stop you... ;)

Wednesday, July 29, 2009

Testing Django 1.1

I'm sitting here watching the runtests.py script that came with Django 1.1 run in a high verbose mode. I must say that I am happy with this thing as it saves me testing time. Of course, it took me a bit of time to set it up as it doesn't run 100% out of the box. I needed to copy over my settings.py file into the testing directory and touch the __init__.py file. I can understand why this is setup this way but it is a tad bit of a headache to move the files around. I am going to see if I can write something that will take care of setting up a temp db environment for regress purposes. It probably won't account for everything but it could be a start of something....

Thursday, July 23, 2009

Microsoft and 7

Let's be honest, you can't go to any of the news outlets without hearing something about Windows 7 that is going to be released on Oct 22. What is amazing to me is how much press (aka opinions) this release is getting. Both positive and negative articles are popping up all over the place. You can get a good idea over at eweek.com. I can understand that MS wants this to succeed considering the Vista failure but there are those that want this thing to utterly fail. There always seem to be extremists on both sides of any fence.

What do I think? I don't know and I don't think I would be someone qualified to make a prediction. I'm too conflicted. One side of me thinks that it'll flop because Microsoft keeps stressing that 7 has Vista underneath. Just using the term "Vista" is a general turn off for me. However, if we review history at the other ill mentioned OS, say Millennium Edition, we see that it was preceded by XP, which Microsoft is still (kinda) supporting 8+ years later. So I am not sure how far 7 will fly.

If 7 ends up going belly up, the future for Microsoft won't look good. However, I have a couple thoughts on how Microsoft could continue on:

Stop making operating systems and focus on office software.
Let's face it, if 7 flops then that will be two failures in a row. At that point, it might be time to cut bait and just focus on what has been working for them. Their office line has been better received lately than their operating systems. If they turn their focus on that and enable it for (heaven forbid) Open Source operating systems, they probably could do ok.

Follow Apple's example.
What do I mean by this? Well, since may people think that Microsoft copies Apple's exterior design (a la Vista and OS X), they might as well go all out and take a similar path with its interior. Base future versions of Windows on Unix. Why not? OS X is primarily a BSD userland with a proprietary kernel to drive it. Why can't Microsoft do this? What would they have to lose? If they based their new system off of NetBSD, not only would they have a better underlying system but the flexability that could carry over to future smartphone operating systems.

I know what you are thinking. If they did that, wouldn't existing applications stop working? Yes, but didn't Microsoft prove that they don't really care about that kind of thing when they released Vista? And to top it off, rather than fix existing compatibility with 7, they are using virtualization for XP compatibility. Worse case, have Microsoft buy Cedega software for their old API emulation. They could fix it and ship it since they know how that work. (In theory, anyway)

These are just thoughts I have. Do I think Microsoft would do any of the above? Most likely no unless hell froze over. Do I think Windows 7 will fail? I think it has a 50/50 shot. The jury won't come back until next year...

Sunday, July 19, 2009

Finally posted the script..

It's funny how time seems to fly. I was reviewing my first (and only) post here and while I was making some modifications to it, I realized that I never got around to posting my script that made the process easier. Well, I setup a google code repository for it so I can get better feedback on it. It is under the ISC License so take it and do what you wish. The google code page is located here.

I am going to see if I can start posting more on a regular basis depending on my schedule. Not that I'm popular or anything but it's a fun little hobby..

Tuesday, January 13, 2009

Django on OpenBSD

This is an article about setting up the Python web framework Django in OpenBSD's chrooted apache server. For those who want to learn more about Django or OpenBSD, please visit their homepages.

I've been looking through the web for awhile now trying to find a way to hook up django in OpenBSD's version of Apache with little avail. I've seen methods that incorporated installing Apache 2.2 and mod_python or through other webservers (like lighttpd) but nothing for chrooted Apache. Since the version of mod_python needed for Django only runs on Apache 2.0 or later, I needed to find out how to run Django on FastCGI in order for it to run on Apache 1.3. So I toyed around with it with the help of a couple of sites to get me started and I got it running. If anyone is interested, here are the directions I took to get things going....

Before we begin, I used OpenBSD 4.4, Python 2.5, and django 0.96.2 during my experiments. Not to say that it won't work for future or past versions but I wanted to be clear to avoid problems due to file versions listed here...

The first thing to do is to install the necessary tools on the OpenBSD system of choice. This can be done by simply typing the following command:
pkg_add -i python py-flup py-django fcgi mod_fastcgi

Depending on which database adapter you want to use, just tack it on. I'm personally biased towards Postgresql but many people use mysql so type in either:
"pkg_add -i py-psycopg2" for postgresql or "pkg_add -i py-mysql" for mysql.

The next thing to do was setup Python in a chrooted environment. It may sound daunting but it's actually not that bad. You just need to make sure that /var/www has enough space. First, copy all of the python files and associated files to the chrooted directory. Don't forget to create the necessary directories in the chroot environment (ie: /bin/sh -> /var/www/bin/sh). This includes the following files in no particular order:
  • /bin/sh
  • /sbin/ldconfig
  • /usr/local/bin/python2.5
  • /usr/local/bin/pydoc2.5
  • /usr/local/bin/python2.5-config
  • /usr/libexec/ld.so
  • /usr/lib/libc.so.48.0
  • /usr/lib/libcom_err.so.16.0
  • /usr/lib/libcrypto.so.14.0
  • /usr/lib/libm.so.3.0
  • /usr/lib/libncurses.so.10.0
  • /usr/lib/libpthread.so.11.0
  • /usr/lib/libreadline.so.3.0
  • /usr/lib/libssl.so.11.0
  • /usr/lib/libstdc++.so.45.0
  • /usr/lib/libutil.so.11.0
  • /usr/lib/libz.so.4.1
  • /usr/local/lib/libfcgi++.so.1.0
  • /usr/local/lib/libfcgi.so.0.0
  • /usr/local/lib/libpython2.5.so.1.0
Side note: we are copying all of the python executables into chroot as is. Since django (and possibly others) may rely on the actual "python" name as the executable, you can either copy them over without the version number (ie: python2.5 -> python) or setup symbolic links. If you go with the latter route, make sure you link them without the chroot directory. Otherwise, you will probably run into problems.

I also copied the entire /usr/local/lib/python2.5 directory over to make sure that none of the modules were missed. Some of you may want to be more cautious and only move over the files you feel are necessary. Your call..

More files to copy. If you are using postgresql, you need the following:
  • /usr/local/lib/libecpg.so.7.0
  • /usr/local/lib/libecpg_compat.so.4.0
  • /usr/local/lib/libpgtypes.so.4.0
  • /usr/local/lib/libpg.so.5.1

For mysql, you'll need:
  • /usr/local/lib/libmysqlclient.so.19.0
  • /usr/local/lib/libmysqlclient_r.so.19.0
  • /usr/local/lib/mysql/libmysqlclient.so.19.0
  • /usr/local/lib/mysql/libmysqlclient_r.so.19.0
Edit: I missed this part last time so my apologies to anyone listening. Django requires some additional nodes to run correctly. Since we are chrooting in /var/www, Django will not be able to access them. They can be recreated in the necessary area by issuing the following commands...
mknod -m 666 /var/www/dev/null c 2 2
mknod -m 644 /var/www/dev/random c 45 0
mknod -m 644 /var/www/dev/urandom c 45 2
If you want to know more about the above commands, I suggest reviewing the OpenBSD manpages since they are very detailed and clear on the commands.

Once all of the files are copied, generate a chrooted ld.hints.so file by typing the command:
chroot /var/www /sbin/ldconfig /usr/local/lib
Once this is done, you should now have a chrooted python to play with. You can confirm this by typing:
chroot /var/www /usr/local/bin/python
If a python prompt comes up, it means that python successfully chrooted in /var/www. You should be able to play with the modules, including the database adapters to make sure that they are operating correctly. I would suggest that once you get in this area, you should start playing with some of the Django modules. In particular, try something like:
import django
django.VERSION
If python errors out or if one of the database adapters doesn't import correctly, it means that a file (usually an .so library) was missed somewhere. Use the ldd command to help find out which files are missing.

Now build a django project. More detailed directions on how to do this can be found at Django's website. After the project is created, create an empty __init__.py file in the directory one level up. You'll need this in a minute. Now, in the project directory, you'll need to create an fcgi file for apache to use. You can name it anything you wish, as long as you are consistant and the file is located in the project root path. I will use mysite.fcgi just for reference. In this file, it should look something like this:

#! /usr/local/bin/python

# This file is based off of the example posted on Django's website:
# http://docs.djangoproject.com/en/dev/howto/deployment/fastcgi/#howto-deployment-fastcgi

import os,sys

# This should be the chrooted path one level up from your Django project
RootPath = "/django"

sys.path.insert(0, RootPath)

os.environ['DJANGO_SETTINGS_MODULE'] = "(project name).settings"

from django.core.servers.fastcgi import runfastcgi
runfastcgi(method="threaded", daemonize="false")
Once the file is created, apache needs to be setup. Usually, it can be setup as a virtual host. I like to import virtual host setups from external files for easier management. Mine is setup like so:
# Chrooted path to Django project root path
<Directory /django/OpenDjango>
Options ExecCGI FollowSymLinks
AllowOverride all
Allow from all
Order allow,deny
</Directory>

<VirtualHost *>
AddHandler fastcgi-script fcg fcgi

ServerName django.blahblahblah.doesntexist.org

# Complete (not chrooted) path to Django project root path
DocumentRoot /var/www/django/OpenDjango

Alias /media /usr/local/lib/python2.5/site-packages/django/contrib/admin/media

RewriteEngine On
RewriteRule ^/(media.*)$ /$1 [QSA,L,PT]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^/(.*)$ /mysite.fcgi/$1 [QSA,L]
</VirtualHost>
Restart apache and check the website. You should be greeted by generic Django page saying you need to get started. I hope this helps those who were running into similar issues that I was when trying to get this thing going.

A few notes to keep in mind:
  • Remember to remove the "nodev" option from the /var partition in fstab before proceeding (thanks for the reminder Thodoris)
  • You should be comfortable with python, OpenBSD, and apache before attempting this
  • Before I did this to my production server, I setup a test system via Qemu or VirtualBox to make sure what I was doing.
  • Follow the instructions that are given to you by pkg_add when installing the packages
  • FYI -When going this route, the python processes that are started run under the www user. I'm not sure of the security implications of this but it beats running external FastCGI servers under the root user.
Any questions or comments are welcome. I'm sure that this process can be improved upon...

Thanks...