FOSSwire

You may or may not have heard that Microsoft recently sponsored the Apache Foundation, to the tune of $100,000 a year.

While I'd love to believe that Microsoft is finally changing its tune on the open source development model and actually honestly trying to promote interoperability, it seems I am not the only one with cynical and sceptical views on Microsoft's real agenda.

Bruce Perens, creator of the Open Source Definition and co-founder of the Open Source Initiative has written an interesting and insightful article discussing what he believes Microsoft's 'game' to be this time around.

Just a few years ago, Microsoft exec Jim Allchin called open source "an intellectual-property destroyer, I can't imagine something that could be worse than this for the software business and the intellectual-property business." [...]

Now they just want to interoperate, right?

Wrong. You wouldn't have to look too far to convince yourself that Microsoft still engages in hard-edged fighting against open source. The Office Open XML standard has recently been pushed through ISO with so many irregularities in process that four nations complained. There already was an ISO-accredited office document standard called OpenDocument, created by the OpenOffice team. It was one-tenth the size of Microsoft's effort, and did the same work. But it would have put Microsoft and open source on an equal footing. Office Open XML, in contrast, is 6,000 pages long, so large that it's not possible for a programmer to learn it in his or her useful lifetime. That'll keep the open source folks from ever handling files quite the same way that Microsoft does.

He also touches on some of the wider issues that the open source development model faces today later on.

It is definitely an interesting read if you're interested in these sort of issues.

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.

See also: Part 2.

First of all, I'd like to wish all FOSSwire readers a very happy new year! Hope it's a good one. Now, the task of keeping a server secure can be a difficult one at times. Getting the compromise and balance between security and convenience right isn't easy to do.

In the first part of this multi-part series, I'm going to show you how to lock down your Linux-based server setup and make it a little bit more secure with a few easy, practical steps that you can take. So without any further ado, let's begin.

In this part, I'm going to focus on steps you can take with your web server software. I'll be focusing specifically on Apache, but many of these steps can be adapted for other software.

1 - Hide your exact version number

By default, Apache throws out the exact version number of itself with every reply to every web request that gets to your server. This isn't necessarily a problem, but it does give the potential attacker lots of information about your setup. If they notice your version is out of date, they might be able to exploit a security hole.

To change what Apache, reports, go to the configuration file httpd.conf and change the line starting with ServerTokens. I recommend setting it to Major, so that only the major version of your server software is reported (e.g. Apache/2):

ServerTokens Major

I know, it's security by obscurity - but every little bit helps. It's more important of course to keep all your software up to date with the latest security fixes as soon as they are available.

2 - Don't enable directory indexes

A directory index is a page that appears when you don't have an index.html or other file set for a directory in your web server's root. The index shows anyone out there on the internet all the files in that directory, and allows them to browse through your web server's contents where you don't have index.html files.

There are some occasions when this behaviour is desirable, for example, a download site, but in most cases it can expose things you don't want exposed, so turn them off.

The default setting for directory indexes is in the Options directive of your main Directory tag in httpd.conf.

What that means is that there will be something starting like this:

<Directory "/var/www/html">
Options Indexes FollowSymLinks

You need to make sure the Options line does not include the word Indexes. Also, if you have manually specified Indexes for any other directories your web server is configured to serve, you will need to check there too.

3 - Make sure backup source files don't get served up

If you work directly on your server with some programs and you are editing things such as PHP scripts or other source code that shouldn't be exposed to your users, you might be unaware that those programs are creating backup files.

Backing up is always a great idea, but it's not so great when those backup files could expose your code, passwords and other information to users, or worse, malicious people.

These files usually end in a ~ symbol. For example, a lot of KDE programs will save index.php~ as a backup when you work on index.php. Aside from cleaning up your backup files at all times, you can also make it so that even if you do leave one of these backup files on the server itself, it will be executed rather than dished out as plain text.

With PHP using mod_php, for example, you can set the AddType directive to parse and execute .php~ files.

AddType application/x-httpd-php .php .phtml .php~ .phtml~

If the worst comes to the worst and you leave a backup file in a live directory, all that will happen if someone browses to it will be - it will execute and run as it should do, not giving your code to everyone in the neighbourhood.

4 - Turn off error reporting

If you use a server-side language, like PHP or Perl or anything else, you've got an added layer of complexity where things can go wrong. If something does go wrong when one of your dynamic scripts runs, it's best not to show the world the details about that error.

It could be that error was caused by a malicious person, and the details from that error message could help them to do more bad stuff on your system. So instead of showing error messages, hide them.

Of course, we don't suppress them completely, or that would mean we wouldn't get notified when something breaks. Instead, have them dumped into your log file, where you can check later and fix things knowing that your users don't know all the details about what went wrong. After all, most of them don't want to know, and some of those that do might not have good intentions.

The steps to do this will vary with what server-side technology you're using. With PHP, you need to go into php.ini and make sure you have the following line set to Off, not On:

display_errors = Off

5 - Remain alert

It's common sense, yes, but it's all too easy to fall into a false sense of security and believe everything is fine. You should be aggressively checking log files for errors and suspicious activity and making sure you know exactly what's going on. If you don't, go through and check that everything is in place and how it should be.

Keep passwords and other authentication mechanisms secure and change them often. Know your server inside and out, so that you know when something is wrong.

See you in Part 2!