Tim Child

I am normally using Debian, Ubuntu or even Suse for deploying Django, but a recent customer needed to deploy on Red Hat Enterprise Server 5.

We decided beforehand to test deployment on RHEL5 and also on CentOS 5.4 and so these instructions should work for both environments. NginX will be used as the webserver.

The first thing I like to do is to upgrade the repository and add EPEL. This wasn’t needed I found on the RedHat box I was using, but was needed on CentOS but your mileage might vary. It should be noted that we made the system as up to date as possible with patches and yum updates.

I won’t be covering the database setup, it is assumed that this is already setup and done. I also won’t be covering the actually placing of the Django application anywhere.

Python 2.4 ships with both RHEL5 and CentOS 5 and is needed for the packaging environment YUM so I would advise not to replace it but just compile and install 2.5.5 (or 2.6) next to it.

Now we need to build and install NginX. I choose this primarily because of my experience with it, (I have used Apache2 a lot but its archaic ) and because of its speed.

There is a decent RedHat init.d script here: http://wiki.nginx.org/RedHatNginxInitScript, but remember that I have changed the installation location above so you will need to change the location in that script of nginx from /usr/sbin/nginx to /usr/local/sbin/nginx

You will also need a nginx.conf configuration script for /etc/nginx/ or you could roll your own using sites-available, sites-enabled pattern. I will attach the script soon.

Now with Python 2.5 installed we can install Django and other requirements:

I am using easy_install here as that is the most widely used tool, but pip with a requirements file is a better solution.

Now we need a database adapter. I am using PostgreSQL 8.4.2, if you are using MySQL, Oracle or some other database you will need to follow the recommended route for the Python adapter.

Change the location of pg_config:

And now install:

Then you need to install your application. This is really specific to your needs. I choose to install the files in /opt/cantemo/application-name as that is specific to our solutions, but RedHat style might mean that you wish to install somewhere else.

Lastly you will want to have your application start easily and also make sure that it starts if the machine ever reboots. To do this I am going to install the start-stop-daemon that is used on Debian based Linux distros on Redhat. I read some threads that it will but there is no ETA on that.

You should download the initd script for Django from http://code.djangoproject.com/wiki/InitdScriptForLinux. Change the RUN_AS user to the user on RedHat that you are going to use for running Nginx. By default this is apache.

Lastly make sure that your application directories have the correct user permissions but you should be able to start everything by issuing the following commands:

Eric Florenzano posted a nice tutorial on deploying django using FastCGI so also check that out, but I didn’t have much luck with daemontools on CentOS, and didn’t bother trying on RedHat. I suggest instead using start-stop-daemon. Check it out for other hints and tips though, particularly on prefork vs. threaded, pip, and more nginx configuration tips.

I have become quite the fan of both Hudson and Sphinx. At Cantemo we are using Hudson for Continuous Integration testing, and its a large improvement over buildbot which I was trying before.

For documentation at the moment I am using Sphinx, a python based documentation generator. We require the documentation to be updated at the same time as the development and tests are built so it is becoming second nature to build documents soon after development is done.

Sphinx allows the creation of documents in ReStructured Text and has build options for creating HTML, LaTeX, PDFs and other version of documents so I tied it into a Hudson build.

Firstly you need a working Hudson installation. There are many tutorials on doing this that work fine, so please google for one. You will probably have the following requirements for following the rest of the steps:

• Hudson Python plugin
• pip installed for python
• VirtualEnv installed for python

Second you need a Sphinx project that can be built.

1. Firstly create a new job in Hudson, call it what you want. I am using the free-style software project type.
   
2. Now start filling in the details. I am going to check out from subversion (you can also use HG, Git or whatever.). The repo URL will be checked when you fill in the details, and you will have the option to supply username and password credentials. The user Hudson is running under on my Linux box has public/private key SSH authentication.

   

   An example of the URL is:

   http://your host/yourrepo/development/Documentation/Development/trunk
3. Now create a build shell.

   

   cd $WORKSPACE
   virtualenv -q docs
   source ./docs/bin/activate
   pip install -q -E ./docs -r trunk/requirements.pip
   cd trunk
   sphinx-build -b html source build

   This is:

   • Change to the current workspace directory
   • Create a Python Virtual Environment called docs
   • Activate that environment
   • Use Pip to install the requirements held with the sphinx project
   • Change into the trunk directory
   • Build the HTML version of the sphinx documentation

   My screenshots show an extra step for Rsyncing the files to a remote host. This is because I want to publish the results of the build. The FTP and SCP plugin for Hudson are not so great so I prefer manually rsyncing as a build step for now.

My Sphinx project is checked out above the source files, and in this location is a requirements.pip file for pip to use when installing into the Virtual Environment. This file is basically:

You could also put your project in here so that sphinx can auto-document modules, or put other requirements for PDF generation.

Then try a build.

I have been using Hudson as a continuous integration server for a short while now and I am super impressed. I have it running on Debian and is really quite feature-full.

One thing that I did have a problem with was with the standard Debian 5 Java environment there was a problem using TLS for mail it seemed, and I didn’t just want to send stuff to gmail’s SMTP server all the time so I configured a local Postfix SMTP relay on another server.

This guide, Send Mail Postfix Through Gmail’s SMTP On A Ubuntu LTS Server helped a lot – but be sure to read the comments as there are some helpful hints.

So now I have it. Hudson running and sending email through my relay to my gmail accounts.

More information on Hudson soon.

Finally have done something about the sorry state of these pages.

I had a quick 3 hour sprint today to see how much I could do with the aim to improve this site in the following ways:

1. Improve readability
2. Get rid of all the unneccesary links and content
3. Generally update the look and colours
4. Remove that horrible header image that I had
5. Make the site more useful for viewers

3 hours isn’t a long time to do a complete redesign so I consider this the undesigned addition and its probably all the better for it.

I also took the opportunity to do the site in HTML 5. No canvas tags yet.

Next up I will be reintroducing things like search and archive links because it really does need them, but until then I feel happier about what I can see here.

Here is a simple decorator that isn’t mentioned properly in the Django documentation.

It basically checks to see if the user is logged in and has is_staff before allowing a user access to the view. Use like you would the normal
@login_required decorator.