A couple of years ago, while learning TurboGears, I wrote a web application to simplify management of DNS zone files. Fast forward to today and I finally found a few minutes to clean it up a bit and make a release.

It is called Zoner and differs from many DNS management interfaces in that it works directly with live zone files. The zone files remain the master copy of domain details and can still be edited manually without effecting Zoner, as opposed to storing the domain structure in a database and generating zone files when needed (or reconfiguring bind to read directly from SQL). It also stores an audit trail for all changes (made through Zoner) and zones can be rolled back to any previous version.

Zoner might also be a useful reference app for anyone learning TurboGears 1.0. It is relatively simple, uses SQLAlchemy and Kid with Paginate and Form widgets.

At work we run a bunch of web applications (mostly TurboGears, CherryPy & Twisted apps) and host them behind Apache, using mod_proxy (and sometimes mod_rewrite) to present a clean URL to the outside world, but allowing each of the apps to run on their own private ports behind the scenes. Different people manage different web apps.

In front of our web farms we use hardware load balancers to handle request arbitration, which provides nice protection from servers or Apache instances going down.

The biggest problem I've had with this configuration until now is that when we need to perform maintenance on a particular web application, bringing that application down causes Apache to return an unhelpful message like "Service unavailable" to the client, as its attempt to reverse proxy the connection to the internal service fails.

For a long while I've wanted mod_proxy to be smarter, where I could tell it "hey, if the normal service you are forwarding to is not available, forward to this one instead". And "this one" would simply be the the same service running on a different peer server.

Well, that is exactly what mod_proxy_balancer in Apache 2.2 allows you to do. It goes beyond that and can provide weighted load balancing of internal services, but it also allows you to define "hot spares" which are only used if the normal service(s) are unavailable. This is what I'm using, with a config like:

# Reverse Proxy /myapp to an internal web service, with fail-over to a hot standby
<Proxy balancer://myappcluster>
    BalancerMember http://127.0.0.1:7825
    # the hot standby on server2
    BalancerMember http://10.0.0.2:7825 status=+H
</Proxy>
<Location /myapp>
    ProxyPass           balancer://myappcluster
    ProxyPassReverse    http://127.0.0.1:7825
    ProxyPassReverse    http://10.0.0.2:7825
</Location>

This config tells Apache to proxy requests for /myapp to a web service on localhost at http://127.0.0.1:7825

If that service becomes unavailable (ie: you take it down for maintenance) then it will automatically send requests to http://10.0.0.2:7825 instead. The "status=+H" defines that member as a Hot Standby. When the default service is back on-line mod_proxy_balancer will pick that up within about 60 seconds or so and revert back to forwarding all requests to it.

The ProxyPassReverse directives are unrelated to the proxy balancing smarts, but are usually required if you want to handle redirects/etc properly.

You can also get real load balancing if you define some BalancerMember entries that aren't hot standbys. mod_proxy_balancer will balance requests across them and hot standby members won't be used until all normal members become unavailable. You can control the weighting of members and the balancing method to, if you like. See proxypass and mod_proxy_balancer docs.

TurboGears 1.0.2 has just been released, and yours truly has been listed as a contributor in the CHANGELOG. Admittedly the patches I submitted were only a couple of minor enhancements to the paginate functionality, but it is nice to help out on the project, and 1.0.2 saves me from running my own patched branch of TG.

I had a TurboGears project that was created using "quickstart" and so was using the default SQLObject ORM to handle its model.

I wanted to use SQLAlchemy instead, which is easy for a new project ("tg-admin quickstart -s") but for my existing project I needed to change the model to use SQLAlchemy objects.

Luckily I hadn't actually changed the default model (setup for identity) yet, so these were the files that could simply be replaced with those from a "tg-admin quickstart -s" build:

• json.py


• model.py

The two config files also needed modifying (change the sqlobject references to sqlalchemy instead):

• dev.cfg


• config/app.cfg

Finally, I threw away the existing (sqlite) db and re-created it:

$ rm devdata.sqlite
$ tg-admin sql create

If you actually had some important data in the DB (I didn't) you would need to dump and restore it.