...
The Python-based Django framework has been chosen at UC Berkeley to provide additional functionality within deployed instances of CollectionSpace. Uses include reporting and other collection administration tasks, as well as outward facing, public web-sites for presentation of the data stored in a CollectionSpace instance.This document describes
Normally, you may assume that this environment already exists and is operating on UC Berkeley VMs used for CollectionSpace. Indeed, if you have a choice, you should choose a VM that already has the required packages installed.
But if you are unlucky enough to have to do it yourself, here are the steps we have used at UC Berkeley to feather the bed for CSpace-Django webapps.
Below are the steps necessary for installing and running a Django web application, using the Apache Webserver and WSGI as the front-end. Much of the configuration of a Django application will be project-specific, so this is not intended as a one-size-fits-all approach.
...
Note |
---|
This document will cover the installation steps only for Linux platforms. Because UC Berkeley deployments run on RedHat Linux machines, the main focus will be on yum-managed servers. Some attention will be given to aptitude- (or apt-) based systems. |
Contents
Table of Contents | ||
---|---|---|
|
Installation
Install Python
Django requires any Python version from 2.6.5 to 2.7,x. To ensure Python is installed and is the required version, type into the shell:
Code Block | ||
---|---|---|
| ||
python -V
Python 2.7.1
|
Note |
---|
Linux systems are highly dependent on the default installed version of Python. If the default version of Python is not adequate, DO NOT try to upgrade it unless you fully understand the consequences. Rather, install a usable version alongside of it. Keep in mind that you are not using the default version as you do the later steps, particularly when installing mod-wsgi. |
...
Be sure that httpd-tools are installed, as well:
Code Block |
---|
httpd.x86_64 2.2.15-29.el6_4
httpd-tools.x86_64 2.2.15-29.el6_4
|
...
If not installed, on Yum systems, it can be installed with the command:
Code Block |
---|
yum install httpd
yum install httpd-tools
|
And on Aptitude systems:
Code Block |
---|
apt-get install apache2
apt-get install apache2-utils
|
...
If no appropriate binary version of mod_wsgi
is available, download the source code and unpack it in a convenient place:
Code Block |
---|
tar -zxf mod_wsgi-3.4.tar.gz
cd mod_wsgi-3.4
./configure
make
|
This will probably not be good enough, since you will probably be wanting to compile against a different version of python (why else would you be compiling from source?), so the configure
command might look more like:
Code Block |
---|
./configure --with-python=/usr/local/bin/python2.7
|
If you get a compiler error about not finding the apache apxs
file then add yet another option:
Code Block |
---|
./configure --with-python=/usr/local/bin/python2.7 --with-apxs=/usr/local/apache/bin/apxs
|
...
When the mod_wsgi
source code has been configured and compiled successfully, run
Code Block |
---|
make install
|
which will copy the compiled mod_wsgi.so
file into the apache2 or httpd modules directory.
...
Pip is a tool for installing and managing Python packages.
Begin by checking whether Pip is installed, and if so, which version:
Code Block lang bash sudo yum list installed | grep -i pip
or
Code Block lang bash which pip
- If Pip is not installed, install it.
- On RedHat systems, this is a slightly roundabout process:
Install the python-devel package:
Code Block lang bash sudo yum install python-devel
Install python-setuptools:
Code Block lang bash sudo yum install python-setuptools
Info python-distribute might work, too: http://docs.python-guide.org/en/latest/starting/install/linux/
Install Pip:
Code Block lang bash sudo easy_install pip
Update setuptools using Pip:
Code Block lang bash sudo pip install setuptools --upgrade
For apt-based systems, the process is straight-forward:
Code Block lang bash sudo apt-get install python-pip python-dev build-essential
Note The python-dev and build-essential packages are recommended to install along, because it isn't possible to install any Python module that ships with a C extension without them later on.
- On RedHat systems, this is a slightly roundabout process:
Upgrade Pip (same process for apt- and yum-compatible systems)
Code Block lang bash sudo pip install --upgrade pip
Tip Please install any Python libraries that you might need.
Install Virtualenv
Check that virtualenv is installed
Code Block lang bash which virtualenv
If it isn't already present, install virtualenv:
Code Block lang bash sudo pip install virtualenv
...
Tip |
---|
Virtualenvwrapper is a wrapper for Virtualenv that allows for easier management of multiple environments on the same server. Its post-activate and pre-deactivate hooks might create an easy way to, for example, point to configuration files with passwords that one would like to manage outside of a Git environment. |
Check that virtualenvwrapper is installed
Code Block lang bash which virtualenvwrapper.sh
If it isn't already present, install Virtualenvwrapper (same for apt- and yum-compatible systems
Code Block lang bash sudo pip install virtualenvwrapper
...
Note |
---|
Django 1.6 also requires Python 2.6 or 2.7, but is compatible as well with Python 3.x. |
Make a Django directory
Make a Django directory. This directory will contain all of your virtualenvs and Django projects:
Code Block cd /usr/local/share sudo mkdir django
Give read/write access to the users who will need to create and edit Django webapps. The following instructions assume that you have previously created a Unix group called
developers
that includes these users.Code Block sudo chgrp developers django
The entire directory tree leading to a Django app must be readable by whatever account is running the http server, typically
apache
or, on Ubuntu,www-data
. To facilitate this, make the Django directory readable and executable by everyone. This will ensure that Apache can read the entire directory path down to the level of each of your Django projects. (By default, the parent/usr/local/share
directory already is readable and executable by everyone.)Code Block sudo chmod 775 django
Warning Ed. note - this makes the
django
directory writable by group. Explain why we do this?
Create a virtual environment
Create a virtual environment in a subdirectory within the Django directory. (The virtual environment in this example happens to be named "venv26", referring to the use of a Python 2.6.x version within that environment.)
Code Block cd django sudo virtualenv --no-site-packages venv26 sudo chgrp developers venv26/ sudo chmod g+w venv26/
Make the virtual environment active:
Code Block cd venv26 source bin/activate
Note You should see the virtual machine name (venv26) displayed in your shell prompt once you've activated the vm.
Install Django
Install Django within the virtual environment:
Code Block sudo sh -c "source ../venv26/bin/activate; pip install django"
Note A note about the syntax used above: Running the sequence of commands as
root
installs Django within the activated virtual environment. If run as two separate steps, the commandsudo pip install django
would exit virtualenv and install Django in a system directory.
(Optional) Install Python module to support Postgres bindings:
Install psycopg2
Code Block export PATH=$PATH:/usr/pgsql-9.2/bin pip install psycopg2
Warning Ed.note: not yet tested.
...
It's a good idea at this point to create a 'hello world' Django project, to verify that Apache and Django are configured correctly to talk to one another. To create a "hello world" project, change to your Django directory and enter the Django startproject
command:
Code Block |
---|
cd /usr/local/share/django
django-admin.py startproject hello_world
|
...
At some place inside each of your Django project directories, Apache Web Server will need to be able to write files, so make another directory inside of the hello_world
directory named, for instance, apache
. (There's nothing special about the name, and you call it anything that seems appropriate.)
Code Block |
---|
cd hello_world
mkdir apache
|
Make whatever account is running the http server, such as apache
or (on Ubuntu) www-data
, the owner of that directory with full access rights; e.g.
Code Block |
---|
sudo chown apache:apache apache
sudo chmod u+rwx
|
...
Change to Apache's directory for user-created configuration files, conf.d
. Depending on your system, this directory might be located at /etc/httpd/conf.d
or /etc/apache2/conf.d
; e.g.
Code Block |
---|
cd /etc/httpd/conf.d
|
Configure Apache directives
...
WSGISocketPrefix
Code Block |
---|
WSGISocketPrefix run/wsgi
|
Directory
Warning Ed. note: Is it necessary to grant Apache permissions beyond the
django/
directory?Code Block <Directory "/usr/local/share/django/hello_world"> Order allow,deny Allow from all </Directory>
WSGIScriptAlias
Code Block WSGIScriptAlias /hello_world /usr/local/share/django/hello_world/hello_world/wsgi.py
...
Warning |
---|
Ed. note: Wrapping |
Code Block |
---|
WSGIDaemonProcess hello_world_wsgi
<Location /hello_world
WSGIProcessGroup hello_world_wsgi
</Location>
|
A further change required to the above configuration, if you use daemon mode, is that you can’t use WSGIPythonPath
; instead you should use the python-path option to WSGIDaemonProcess
, for example:
Code Block |
---|
WSGIDaemonProcess hello_world_wsgi python-path=/path/to/hello_world project:/path/to/venv/lib/python2.7/site-packages
|
...
The following is a sample configuration for two Django projects, pahma_project and cspace_django_project, running in parallel in Daemon mode:
Code Block |
---|
<!-- We're using the same virtual environment for both projects, since their dependencies do not conflict, located at /usr/local/share/django/vir274 -->
WSGIDaemonProcess pahma_project_wsgi python-path=/usr/local/share/django/pahma_project:/usr/local/share/django/vir274/lib/python2.7/site-packages user=apache group=apache
WSGIDaemonProcess cspace_django_project_wsgi python-path=/usr/local/share/django/cspace_django_project:/usr/local/share/django/vir274/lib/python2.7/site-packages user=apache group=apache
<!-- Each project has a wsgi.py file in it -->
WSGIScriptAlias /pahma_project /usr/local/share/django/pahma_project/cspace_django_site/wsgi.py
WSGIScriptAlias /cspace_django_project /usr/local/share/django/cspace_django_project/cspace_django_site/wsgi.py
WSGISocketPrefix run/wsgi
<!-- the location for each webapp should be unique, and should match the value of WSGI_BASE in the project's wsgi.py file -->
<Location /pahma_project>
WSGIProcessGroup pahma_project_wsgi
</Location>
<Location /cspace_django_project>
WSGIProcessGroup cspace_django_project_wsgi
</Location>
<!-- for running two cspace django projects alongside each other, you will have to give the static root a unique name here, and change the STATIC_URL in that project's settings.py file to match -->
Alias /static /usr/local/share/django/pahma_project/static_root
Alias /cspace_django_project_static /usr/local/share/django/cspace_django_project/static_root
<Directory "/usr/local/share/django/pahma_project/static_root">
Order deny,allow
Deny from all
Allow from all
</Directory>
<Directory "/usr/local/share/django/cspace_django_project/static_root">
Order deny,allow
Deny from all
Allow from all
</Directory>
|
Note | ||
---|---|---|
Notice that we have specifically defined the user and group in the configuration, even though that may not strictly be necessary:
(If you do include them, be sure not to introduce typos!) Also, note that |
...