So... I just quit my job. The shock of realizing that starting next week I will not be seeing the people I have worked along side for the last 9 years has started up a fit of introspection that would normally require some sort of blunt trauma (or drugs). I have quit Pacbrake in order to move to RIP.tv. This new gig will have me working on highly scalable video delivery and community tools. I cannot unfortunately say much more than that about the new projects. More details as press releases follow.

Go get it at Enomalism.com or download it from sourceforge. Let's get more eyeballs on this so that we can fix the bugs and start adding more features!

Note to those coming from Sam Johnston's blog

I wonder how much time it took him to find a blog post that he could use to cast our team in a negative light via my blog... Complaining about my changing a proxy configuration from 2 years ago seems a bit of a stretch, esp. since we released with the problem fixed. Ah well, I suppose if he had some positive comment about anything, I would just drop dead from shock.

Update: I tossed out my problematic lighttpd config, and moved back to apache. Two lines, and everything is fixed:

  ProxyPass / http://localhost:8080/
  ProxyPassReverse / http://localhost:8080/

The rest of this post is OBSOLETE!

Being the quintessential professional, I decided to upgrade TurboGears yesterday, on the eve of the release of two... TWO major projects. I am funny that way. Seriously, there were some issues with IE supporting the authentication system on the older version of TurboGears which I was using. This left me with two unpalatable options (the upgrade, or not supporting IE at all).

After the ugprade of course, all hell broke loose. While my authentication problems disappeared right away, previous methods for integrating TurboGears and Lighttpd ceased to function, and I was left with enterprise applications without SSL support, which is a non starter any way you look at it.

Time to put on the thinking cap. Follow along for the FIXAGE!

Lately, I have been reading a large number of posts about the loss of "browser metaphors" in AJAX applications. The biggest beef is generally the reduced or eliminated functionality of the back button in the browser, but other complaints such as:

• Loss of state
• Insecure traffic
• Network inavailability
• Inconsistent frameworks
• Did I mention the back button?

The salient point here is that the Metaphor has changed. While I think that there are good points here (especially from the loss of state perspective), the majority of these gripes have more to do with a lack of comfort with a new metaphor than they do with the value in a new paradigm...

Enomalism just got a little cooler with the addition of a full AJAX terminal package (based upon the AjaxTerm project, but ported to TurboGears with some wierd backend stuff added to handle arbitrary virtual ptys. When I did the code, it turned out that ther newer 3.02 version of Xen used a completely different interface for reading DomU information. To work around this, I moved to doing things "the right way" and started using XenStoreD to read pty info.

One of the holy grails for the Enomalism project is the ability to have remote serial console over AJAX, without needing to have a running SSH daemon on the DomU. I recently solved this problem (which is going to be part of the core open source release) and thought I would document it here. After all, there could be ANOTHER nerd who needs to write an application that takes control of the virtual serial Xen consoles without using expect. Xen serial consoles are amazingly simple, robust, and eliminate the need for SSH on your DomU.

Note: This post has become somewhat obsolete, since I have found the method for reading XenStoreD directly

I was asked recently why it is that I do not use Ruby, and instead focus on development using Python and PHP for web applications.

Basically, it is because there is stuff in my fridge older than the Ruby language.

Granted, I probably need to clean out my fridge, but the Ruby language is new, and it's long term viability seems to be coupled tightly with Rails. While TurboGears (for example) is arguably less mature than Rails, it is based on a mature language which I can readily hack into a more usable state if I run into problems (which I have not, so far).

Whilst working on Enomalism, I ran into an interesting issue; when I provision a new Domain, I need to untar a giant drive image. Turns out that it is a good idea to make sure it runs in the background, since TurboGears will block while writing the file.

I decided to use Fork in order to avoid the Global Interpreter Lock problems that pop up with it (and as a side note, a small RAM sacrifice avoids the problem here). The next problem was that I ended up with unterminable background processes since TurboGears tries to intercept the sys.exit() calls to reload the app. That is only a problem during development, and easily solved with kill "yourProcessHere" calls.

The outcome? It is trivial to call Fork from TurboGears, and I had no problem running background LDAP and tarfile calls, so you should be OK too! I have not yet tested to see how it deals with the JSON callbacks, but I suspect tha

Just a quick note (more to myself than anybody else). If you want to bind to an LDAP server (something that I am doing for a big nasty virtualization project), and you want to do it over SSL, there is no documentation in the project manuals. After some quick source code browsing, and a serendipitous find in the sourceforge forums, I have a method. Here it is:

#This is only required if you are using a self signed cert. 
#Probably turn it off for production code.
#ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_NEVER)
#ActiveDirectory? Do this, otherwise, leave it out. Thanks: Deepak Giridharagopal
#ldap.set_option(ldap.OPT_REFERRALS, 0)
lconn=ldap.initialize("ldaps://"+theNameOfYourServerGoesHere)
lconn.simple_bind(userDistinguishedName,userSecretPassword)
#DO whatever: I am changing passwords...
return lconn.passwd_s(theDistinguishedNameOfTheUser,oldpass,newpass)        

This is really terribly important, since the passwd functions will not work unless you are either on TLS or SSL. I am using this method successfully on fedora-ds, but it should also work on OpenLDAP/SlapD.

Lately I have been using the new (or in truth, really old) Fedora Directory Server for all of my LDAP needs. Since most everybody looking for scalable authentication and identity management ends up using LDAP eventually, and since I was not happy with slapd (which is stable, but a pain to use), I ended up giving Fedora-DS a try. Am I ever glad I did. Using the same (old) server as ther netscape directory server, with a nice Java based management interface, Fedora DS really does give a good alternative to Microsoft ActiveDirectory or Netscape eDirectory, and at NO CHARGE!

Our new Enomalism project is using it, although you could deploy on slapd if you REALLY wanted to. I have also played with authenticating Typo3 and TurboGears against it too. THe only issue I had was that SSL is not configured out of the box, and can be flaky to get working correctly. There are docs available, but they seemed a bit ambiguous at times. Overall though, much easier to set up than, say, OpenLDAP.