FOSSwire

I’ve typically been pretty conservative when choosing a web server. Typically, I’ll use Apache to run most sites, and possibly Lighttpd for static files. Experimenting never really has been something done with a web server once I’m past the initial setup.

I’m willing to change that, however, especially after seeing the Cherokee web server in action. At first glance it seems to just be another lightweight web server, and in the end, it is.

The Cherokee website has its own benchmarks against Apache, Lighttpd, and Nginx, with Cherokee coming out on top in terms of the most requests. They are fairly comprehensive, though if you’re not one to trust benchmarks these may not seem any different from those conducted by others.

The one sole feature that could really give Cherokee a solid place in the server market is its method of administration. Most free software server solutions typically offer plenty of organized configuration files to tune and edit at your leisure. If you really have the desire to do so, Cherokee won’t prevent you from directly editing its own configuration. However, there is something much better:

The entire server can be managed using cherokee-admin, the web interface you see above. In fact, it’s highly recommended to manage the server using this administration interface. Your first thoughts may include security issues of a web-managed server, but many of those are dissolved quickly: cherokee-admin must be run in a console, and then a one-time-use password is generated for the administration interface. When you are done, stop cherokee-admin, and everything is safely closed away once more.

The administration interface alone may be responsible for converting many websites to Cherokee. Any entry barrier that may have existed from editing config files might nearly disappear: right after installation, all you must do is fire up cherokee-admin and begin configuring your new web server.

There are a lot of other cool gems included as well. A panic script can be invoked should Cherokee crash, alerting the administrator immediately. It natively supports fcgi and FastCGI, and includes a default rule to help set up PHP in a few moments. Even things such as switching users, accomplished by compiling suexec in Apache, are only a text entry away in Cherokee.

Version 0.99.9 was recently released, so 1.0 can’t be too far around the corner. If you’re looking to find a server that doesn’t need to be manually configured, or just want something speedy, Cherokee is definitely the path to take.

I recently posted about using nohup to run a command, particularly on a remote machine, that keeps running even when you close the terminal or connection that started it.

Several people in the comments there also suggested GNU Screen for a similar purpose.

So, what is Screen? It describes itself as:

... a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells.

Basically, among other things, it can create multiple 'virtual terminals' that run inside a single physical terminal or connection, and offers you additional features, such as resuming sessions later and basic copy and paste.

What we're interested in in the context of my other post is running commands in the background on remote machines, so I can start a command running, disconnect from SSH, but the command will stay running.

Screen, unlike Nohup, will allow me to come back later and interact directly with the terminal that I started, not just dump the results of a command to a file.

On your remote machine, start the program:

$ screen

You'll get a brief copyright notice and such, just press Space as directed. You are now running Screen (although it won't look any different to a normal terminal session by default).

Now, feel free to go off and start that important task. Once it's up and running, press Ctrl+A, then Ctrl+D. Screen sends you back to your shell and you can now disconnect.

Later, when you want to come back, run:

$ screen -r

Your old session is restored! Anything you started should still be running.

Screen is a lot more powerful than just offering this feature, however, but we'll save the rest for another day.

Finally, when you are actually done with a Screen session for good, quit it by pressing Ctrl+A, then Ctrl+\ or you can simply type exit into the terminal as normal.

[image source]

I've recently started learning Django for doing web development, so as part of that, I needed to also learn how to set up Django within mod_python so I could deploy my new Django applications on my server.

In this post, I'll be sharing the method I used to install mod_python and Django on my CentOS 5, Apache-based web server. So without any further ado, let's get started on the process!

Starting Off

I'll be running the latest SVN release of Django, which provides the latest features. Despite not officially being stable, I've found it to be fine, and doesn't restrict me to having to develop to the older spec of the 0.9x releases. That siad, you should regularly update your SVN copy to keep updated with the latest security and bug fixes.

Apparently:

"We improve Django almost every day and are pretty good about keeping the code stable. Thus, using the latest development code is a safe and easy way to get access to new features as they're added."

Before we get started downloading Django, however, we first need to grab mod_python (the plumbing between Apache and Django) for the installed Apache. The easiest way to do this is through yum:

# yum install mod_python

This should automatically add to your httpd.conf Modules, but if it doesn't, then you should manually do so with the line:

Module python_module modules/mod_python.so

Getting and Installing Django

Now let's go and get the latest version of Django. For the whole of this tutorial, I'll assume you are putting Django in /opt, as I am here. As root:

# mkdir /opt/django
# cd /opt/django
# svn co http://code.djangoproject.com/svn/django/trunk/

Once the SVN checkout completes, you have Django downloaded. Next, we need to get it installed into Python, by symlinking this new Django directory into Python's site-packages directory.

# ln -s /opt/django/trunk/django /usr/lib/python2.4/site-packages

Also, we should at this point add django-admin.py to your PATH, so you can use it to create new Django projects from anywhere on your system.

# ln -s /opt/django/trunk/django/bin/django-admin.py /usr/local/bin/django-admin.py

To test that the Django installation worked, run the following. If it works, Python shouldn't give you any error message and go silently back to its prompt. If you get ImportError: No module named django, you have a problem. Check that symlink to /opt/django/trunk/django is in Python's site-packages directory.

# python
>>> import django

Getting a Database Library

You need a Python module for the database you plan to use with Django installed, so that Django can talk to the database. Most people will be using MySQL, so that's what I'll cover installing here.

Right now, the version of connector module MySQL-python in the CentOS repositories is too old to use with the SVN release of Django. Instead, get the latest tar.gz release from here.

Once that's downloaded, do this in the directory where you downloaded it:

# tar xzvf MySQL-python-1.2.2.tar.gz
# cd MySQL-python-1.2.2
# python setup.py build
# python setup.py install

Making Application and Template Directories

Django applications aren't deployed like PHP, for example. Your application's source files and templates are kept outside of your web server's document root (much better for security), and you instead use Django's URL resolvers to build a logical URL structure. This also has the disadvantage of meaning you have to put your media files for a project somewhere separately, but I'll cover that later.

For now, we need to make both an application directory, where our application code will reside, and a template directory. In CentOS, the document root by default is /var/www/html, meaning we have the whole of /var/www/ to use for other web server stuff that needs to remain outside the web server's normal root. Perfect for this.

# mkdir /var/www/djangoapps
# chown apache /var/www/djangoapps
# mkdir /var/www/djangotemplates
# chown apache /var/www/djangotemplates

Make an Egg Cache

We're almost done in the preparation stage, but we also have to add a Python egg cache that the web server can write to. I found the easiest way to do this was to add a new directory in /var/cache for the purpose.

# mkdir -p /var/cache/www/pythoneggs
# chown apache /var/cache/www/pythoneggs

Serving up Media Files

Media files have to be done separately. If you're into Vhosts, you could set up a subdomain for serving media, but the simplest way is to just make a /media directory in /var/www/html and place your Django application's media in a subfolder of that (then updating settings.py for each app to reflect the location).

If you're planning on using the Django admin interface, I recommend symlinking the Django admin media directory in here too, like so:

# ln -s /opt/django/trunk/django/contrib/admin/media /var/www/html/media/admin

Now, set ADMIN_MEDIA to this path in the settings.py file for each app you deploy.

Deploying an Application

Finally, you need to actually deploy an application. Here, I'll assume you're working with an application named myapp. Initially, you should drop the application source code in /var/www/djangoapps/myapp, the templates in /var/www/djangotemplates/myapp and your media in the media location you set up earlier.

Make sure at this point you now go back to /var/www/djangoapps/myapp/settings.py and tweak the project's settings, including Debug mode, media URL, admin media URL and anything else relevant to your new deployment. Also, don't forget to check your database settings if you're working with a different database server or instance.

You also need to go into urls.py and update the URL patterns with a prefix that you want to use for your application (in this case, /myapp), or your links will be broken and URLs won't resolve once installed.

In httpd.conf, add a Location tag to specify your new application's root:

<Location /myapp>
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE myapp.settings
SetEnv PYTHON_EGG_CACHE "/var/cache/www/pythoneggs"
PythonDebug Off
PythonPath "['/var/www/djangoapps'] + sys.path"
</Location>

Save httpd.conf, and restart Apache:

# /etc/init.d/httpd restart

Also remember that any changes to source code will likely require a restart of Apache to read them in.