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...

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...

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....

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.

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.

Don't mind me while I geek out...

More Tron: Legacy Info

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... ;)