$ scp Django-1.1.1.tar.gz devio.us:

и распаковал его

$ gunzip Django-1.1.1.tar.gz
$ tar xvf Django-1.1.1.tar
$ ln -s Django-1.1.1 django #  для дальнейшего удобства

Добавим переменную окружения PYTHONPATH для корректной работы Django

$ export PYTHONPATH='/home/boombick/django'
$ echo "export PYTHONPATH='/home/boombick/django'" >> ~/.profile

И создадим симлинк для django-admin

$ mkdir ~/bin
$ ln -s /home/boombick/django/django/bin/django-admin.py /home/boombik/bin/django-admin.py

Дальше все просто: создаем новый проект Django

$ django-admin.py startproject djtest
$ cd djtest

И на этом этапе я просто запустил dev-сервер из поставки Django на высоком порту (занять порт с номером ниже 1024 без привелегий root не получится)

$ python manage.py runserver 0.0.0.0:32000

Зайдя на http://boombick.devio.us:32000 я увидел приветственную страницу пустого проекта Django. Все получилось :)

Запуск Django через CGI
В принципе, можно было бы оставить все и так. Но.
1. Хотелось все-таки ходить к себе на страничку по 80 порту
2. На free-аккаунте нельзя детачить приложения. Т.е. нельзя оставить запущенным сервер и разлогиниться. Что, впрочем, логично, иначе сервер превратился бы в рассадник IRC-ботов :)
Можно, конечно, извратиться и держать логин постоянно, восстанавливая оборванное подключение и перезапуская сервер, но это не наш путь.

Итак.
Сначала я просто пробрасывал запросы к Django через PHP (в виде index.php) :) Эдакий PHP-Proxy, но мало того, что это запредельно криво, так еще и не очень понятно, что делать с POST-запросами. Выход был один – заставить Django работать через CGI.
Помучив гугл я нашел несколько разноненных мануалов и приступил к выполнению.
Для начала создадим в директории $HOME/public_html файл django.cgi вот с таким содержанием:

#!/usr/local/bin/python
# encoding: utf-8
"""
django.cgi

A simple cgi script which uses the django WSGI to serve requests.
Rewrited for use on devio.us shell hosting

Code copy/pasted from PEP-0333 and then tweaked to serve django.

http://www.python.org/dev/peps/pep-0333/#the-server-gateway-side

This script assumes django is on your sys.path, and that your site code is at
/home/mycode/mysite. Copy this script into your cgi-bin directory (or do
whatever you need to to make a cgi script executable on your system), and then
update the paths at the bottom of this file to suit your site.

This is probably the slowest way to serve django pages, as the python
interpreter, the django code-base and your site code has to be loaded every
time a request is served. FCGI and mod_python solve this problem, use them if
you can.

In order to speed things up it may be worth experimenting with running
uncompressed zips on the sys.path for django and the site code, as this can be
(theorectically) faster. See PEP-0273 (specifically Benchmarks).

http://www.python.org/dev/peps/pep-0273/

Make sure all python files are compiled in your code base. See

http://docs.python.org/lib/module-compileall.html

"""

import os, sys
sys.path.append("/home/boombick/django") # Поменяйте на путь к Django
sys.path.append("/home/boombick/djtest")  # Поменяйте на путь к вашему проекту

import django.core.handlers.wsgi

def run_with_cgi(application):

    environ                      = dict(os.environ.items())
    environ['wsgi.input']        = sys.stdin
    environ['wsgi.errors']       = sys.stderr
    environ['wsgi.version']      = (1,0)
    environ['wsgi.multithread']  = False
    environ['wsgi.multiprocess'] = True
    environ['wsgi.run_once']     = True

    if environ.get('HTTPS','off') in ('on','1'):
        environ['wsgi.url_scheme'] = 'https'
    else:
        environ['wsgi.url_scheme'] = 'http'

    headers_set  = []
    headers_sent = []

    def write(data):
        if not headers_set:
             raise AssertionError("write() before start_response()")

        elif not headers_sent:
             # Before the first output, send the stored headers
             status, response_headers = headers_sent[:] = headers_set
             sys.stdout.write('Status: %s\r\n' % status)
             for header in response_headers:
                 sys.stdout.write('%s: %s\r\n' % header)
             sys.stdout.write('\r\n')

        sys.stdout.write(data)
        sys.stdout.flush()

    def start_response(status,response_headers,exc_info=None):
        if exc_info:
            try:
                if headers_sent:
                    # Re-raise original exception if headers sent
                    raise exc_info[0], exc_info[1], exc_info[2]
            finally:
                exc_info = None     # avoid dangling circular ref
        elif headers_set:
            raise AssertionError("Headers already set!")

        headers_set[:] = [status,response_headers]
        return write

    result = application(environ, start_response)
    try:
        for data in result:
            if data:    # don't send headers until body appears
                write(data)
        if not headers_sent:
            write('')   # send headers now if body was empty
    finally:
        if hasattr(result,'close'):
            result.close()

os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
run_with_cgi(django.core.handlers.wsgi.WSGIHandler())

Затем меняем в /path/to/dajngo-project/settings.py параметр ROOT_URLCONF на urls вместо projectname.urls
Делаем файл исполняемым

$ chmod a+x public_html/django.cgi

И проверяем работоспособность :)

http://boombick.devio.us/django.cgi

Если все ок, то можно переходить к следующему шагу. А если нет и вы получаете 500 ошибку, то смотрите лог. Который, кстати, лежит в /var/www/logs/error_log В процессе установки очень удобно было его мониторить в отдельной консольке при помощи tail -f
Учтите только, что в этот лог падают сообщения о всех ошибках и вам надо отделять свои запросы от остальных :)

Настройка Apache
Теперь надо настроить Apache для переадресации всех запросов к нашему django.cgi. Я очень давно не ковырялся с Apache (в последнее время использую исключительно nginx) и с трудом и доками вспоминал синтаксис mod_rewrite
В результате родился вот такой вот файлик .htaccess, который надо положить в директорию public_html

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /django.cgi%{REQUEST_URI}?%{QUERY_STRING}

Проверяем
В ~/djtest/urls.py добавим правило для обработки всех адресов

from django.conf.urls.defaults import *
from views import test_page

urlpatterns = patterns('',
    (r'^(.*)$', test_page)
)

И создадим файл ~/djtest/views.py с, собственно, обработчиком

from django.http import HttpResponse       

def test_page(request, url):
    html = "WORKING! Url is %s" % url
    return HttpResponse(html)

Заходим на http://boombick.devio.us/foo/bar

Все работает :)

Благодарности
Хочу сказать большое спасибо ребятам из конференции django@conference.jabber.ru, а конкретно ne_formal за неоценимую помощь :) Без него этот процесс затянулся бы куда больше!

Важное замечание
Если вы читали комментарии в начале файла django.cgi, то не могли не заметить такой абзац:

This is probably the slowest way to serve django pages, as the python
interpreter, the django code-base and your site code has to be loaded every
time a request is served. FCGI and mod_python solve this problem, use them if
you can.

Что в вольном переводе выглядит как:
Это самый медленный путь для работы с django. На каждый запрос создается экземпляр интерпретатора Python. Если у вас есть возможность использовать FCGI или mod_python – используйте их!
Так что статью прощу рассматривать исключительно как proof of concept или выход из совсем уж безвыходной ситуации! :)
Enjoy!

apt-get install mysql-server mysql-client

Задаем пароль для пользователя root (замените yourrootsqlpassword на ваш пароль)

mysqladmin -u root password yourrootsqlpassword

Проверим, какие адреса слушает MySQL, при помощи команды

netstat -tap | grep mysql

Вывод должен быть примерно таким:

tcp        0      0 localhost.localdo:mysql *:*                     LISTEN     2713/mysqld

Это значит, что MySQL слушает только localhost.localdomain и вы установили пароль. Если же вывод похож на:

tcp        0      0 *:mysql *:*                     LISTEN     2713/mysqld

вам необходимо также установить пароль для вашего хоста (в нашем примере это server1.example.com), иначе кто-угодно сможет подключиться к БД и манипулировать данными

mysqladmin -h server1.example.com -u root password yourrootsqlpassword

Устанавливаем Lighttpd, Python и python-mysqldb
Мы будем использовать скрипт, написанный на Python, для чтения конфигурации из БД. Устанавливаем все необходимое:

apt-get install lighttpd python python-mysqldb

Подготовка базы данных
Подключаемся к MySQL:

mysql -u root -p

создаем базу данных и пользователя. А также даем пользователю привилегии SELECT для запросов к нашей базе

CREATE DATABASE lighttpd;
GRANT SELECT ON lighttpd.* TO lighttpd@localhost IDENTIFIED BY 'secret';
GRANT SELECT ON lighttpd.* TO lighttpd@localhost.localdomain IDENTIFIED BY 'secret';
FLUSH PRIVILEGES;

Не забудьте заменить “secret” на реальный пароль
Осталось создать таблицу для наших виртуальных хостов и подготовка БД на этом закончена

USE lighttpd;
CREATE TABLE IF NOT EXISTS domains (
domain varchar(64) NOT NULL PRIMARY KEY,
docroot varchar(128) NOT NULL,
config text
);
quit;

Сценарий для получения данных из БД
Создаем скрипт на python, который будет читать из БД конфигурацию виртуальных хостов

#!/usr/bin/env python
import sys
import MySQLdb

# load configuration data from the database
db=MySQLdb.connect(host='localhost', db=sys.argv[1], user=sys.argv[2], passwd=sys.argv[3])
cur = db.cursor()
cur.execute("SELECT * FROM domains")
rs=cur.fetchall()
db.close()

for domain in rs:

    print "$HTTP[\"host\"] == \"%s\" {\nserver.document-root = \"%s\"\n%s\n}" % (domain[0], domain[1], domain[2])

и сохраняем его в /usr/share/lighttpd/mysql_vhost.py
Делаем скрипт исполняемым

chmod 755 /usr/share/lighttpd/mysql_vhost.py

Теперь надо настроить Лайти для использования нашего срипта. Для этого открываем конфиг /etc/lighttpd/lighttpd.conf и добавляем в конец следующую строчку

[...]
include_shell "/usr/share/lighttpd/mysql_vhost.py lighttpd lighttpd secret"

(первый параметр – это имя БД, второй – имя пользователя БД, третий – пароль для доступа к БД)
После всех изменений перезапустим lighttpd

/etc/init.d/lighttpd restart

Настройка виртуальных хостов
В примере мы настроим два виртуальных хоста: www.example.com (с корневым разделом в /var/www/www.example.com/web) и www.example.org (с корневым разделом в /var/www/www.example.org/web). Мы будем использовать различные параметры для каждого хоста для демонстрации возможностей :)
Для www.example.com мы разрешим листинг директорий и создадим алиас test, который будет указывать на DocumentRoot. Для
www.example.org листинг директорий будет отключен.

Если корневые разделы еще не существуют, то создадим их:

mkdir -p /var/www/www.example.com/web
mkdir -p /var/www/www.example.org/web

Подключаемся к MySQL и добавим описание наших хостов

INSERT INTO domains VALUES ('www.example.com','/var/www/www.example.com/web/','dir-listing.activate = "enable"\nalias.url = ( "/test" => "/var/www/www.example.com/web" )');
INSERT INTO domains VALUES ('www.example.org','/var/www/www.example.org/web/','dir-listing.activate = "disable"');

Обратите внимание на первый запрос INSERT. Если вы хотите использовать более одной директивы, то поместите между ними управляющий символ “\n”
Все, виртуальные хосты настроены. Для проверки корректности работы нашего скрипта, запустим его из командной строки:

/usr/share/lighttpd/mysql_vhost.py lighttpd lighttpd secret

В выводе должна содержаться корректная информация о наших хостах:

server1:~# /usr/share/lighttpd/mysql_vhost.py lighttpd lighttpd secret
$HTTP["host"] == "www.example.com" {
server.document-root = "/var/www/www.example.com/web/"
dir-listing.activate = "enable"
alias.url = ( "/test" => "/var/www/www.example.com/web" )
}
$HTTP["host"] == "www.example.org" {
server.document-root = "/var/www/www.example.org/web/"
dir-listing.activate = "disable"
}
server1:~#

В отличие от mod_mysql_vhost, наш способ требует перезапуска сервера

/etc/init.d/lighttpd restart

Тестируем
Пришло время проверить, верно ли работают наши виртуальные хосты. В корневых директориях хостов нет индексных файлов
http://www.example.com (листинг директорий включен)

http://www.example.com/test Директории test не существует, но мы прописали алиас для этого пути. Поэтому мы видим содержимое DocumentRoot

http://www.example.org Мы получаем ошибку 404, потому что индексного файла нет, а листинг директорий отключен

http://www.example.org/test Листинг директорий отключен, и мы не делали алиасов для этого хоста. Поэтому все та же ошибка 404

Оригинал: http://howtoforge.org/creating-advanced-mysql-based-vhosts-on-lighttpd-debian-etch

В этой статье я использую отличный адаптер psycopg2, хотя, в принципе, любая база данных Python, использующая DBAPI, будет работать аналогично. Единственное препятствие здесь заключается в том, что, по-моему, объектно-реляционные преобразования (object-relational mapping – ORM) скрывают слишком многое из того, что на самом деле происходит с обращениями к базе данных, накладывают ряд искусственных ограничений и, как правило, больше мешают программированию, а не облегчают его.

Без пулов
В идеальном случае (без объединения соединений в пул) любой поток или процесс, в котором серверное Web-приложение подключается к базе данных, будет быстро получать соединение, создавать курсор, затем выполнять некоторые довольно быстрые операции, подтверждать или откатывать операции назад, после чего закрывать соединение. Достаточно просто, если всё идёт хорошо. Например:

Web-сервер, записывающий информацию в СУБД

def AddData(foo, bar):
    "Эта функция обычно вызывается в собственном потоке"
    from psycopg import connect
    conn = connect("dbname=transact user=web host=server.mine")
    cur = conn.cursor()
    cur.execute("INSERT INTO userdata VALUES (%r, %r)" % (foo, bar))
    conn.commit()
    conn.close()

В данном примере показан не самый лучший исходный код, поскольку я мог бы поставить try/’except’ с двух сторон от вызова connect(), а может быть даже try/finally, чтобы удостовериться, что происходит вызов conn.close(). Также я не использую сокрытие значения в DBAPI, хотя мог бы. И всё же, AddData() имеет все внешние признаки типичного обращения к базе данных.

Что идет не так (и как это исправить)
В вышеприведённом исходном коде имеется несколько моментов, которые часто вызывают сложности. Одна из проблем состоит в том, что когда одновременно запущено множество потоков, на самом деле некоторые из них не смогут получить соединение, даже если ещё не достигнуто ограничение базы данных. Теоретически такая проблема не должна возникать, но в реальности это происходит. Другая проблема состоит в том, что когда достигнут предел для пула соединений базы данных — обычно из-за того, что потоки завершаются за большее время, чем ожидалось, либо вызывают исключения перед закрытием соединения — неудача в получении соединения становится гораздо более вероятной, чем хотелось бы.

Обе проблемы можно решить за счёт создания локального пула потоков. Пул соединений – это просто набор предварительно определённых соединений к базе данных, которые могут использоваться повторно и освобождаться каждым потоком с “виртуальным соединением”. При этом реальные соединения с базой данных закрываются относительно нечасто, тогда как их собранные в пул представители запрашиваются и освобождаются при каждой транзакции.

С одной стороны, объединение в пул предопределённых соединений из локального пула – это производимая в памяти операция, которая редко даёт сбой (кроме случая исчерпания лимита соединений), так как проблем со временем ожидания в сети или базе данных не возникает. С другой стороны, использование пула позволяет точно и локально управлять лимитом соединений. Если за ограничение количества соединений отвечает база данных, на уровне приложения невозможно определить количество используемых и свободных соединений; грубым приближением могло бы служить количество открытых потоков, но такой подход ненадёжен. Модуль antipool.py в фоновом режиме увеличивает и сокращает количество собранных в пул (реальных) соединений, чтобы не занимать реальные соединения дольше, чем необходимо. Для пользователя, однако, объединённое в пул соединение выглядит точно так же, как и реальное соединение с базой данных, за исключением того, что информация о наличии соединений в пуле является локальной, а максимальное количество соединений является параметром пула соединений, а не базы данных.

Даже при использовании antipool.py мне кажется более удобным заключить дальнейшую организацию пула в тонкую оболочку, а не использовать каждый раз все опции ConnectionPool. Более того, в самом общем случае при достижении предельного количества реальных соединений достаточно с помощью простой функции sleep() запросить ещё одно. Если множество вычислительных потоков действительно ведёт себя некорректно (никогда не закрывается), проблема сохранится, но, по крайней мере, будет легче выполнять отладку. Вот оболочка, которую я использую:

webapp_pool.py

"""USAGE:
from webapp_pool import get_connection
conn, cur = get_connection()   # Might hang, but never raises
cur.execute(SQL)
conn.commit()
conn.release()    # 'conn.release()' not 'conn.close()'
"""
import psycopg2
from time import sleep
from antipool import ConnectionPool
from database import host, database, user, MAXCONNECTIONS
conn_pool = ConnectionPool(psycopg2,
                           host=host,
                           database=database,
                           user=user,
                           options={'maxconn':MAXCONNECTIONS})
def get_connection():
    got_connection = False
    while not got_connection:
        try:
            conn = conn_pool.connection()
            cur = conn.cursor()
            got_connection = True
        except psycopg2.OperationalError, mess:
            # Might log exception here
            sleep(1)
        except AttributeError, mess:
            # Might log exception here
            sleep(1)
    return conn, cur

Заключение
В этой статье я использовал не требующий знания о базе данных модуль antipool.py. На мой взгляд, antipool.py весьма гибок; в нём есть дополнительные хорошо продуманные возможности, которые не обсуждались в этой короткой статье. Однако если вы планируете использовать встроенные в psycopg2 возможности или другие инструменты для организации пула, основные принципы использования соединений, объединённых в пулы, остаются прежними.

Оригинал: http://www.ibm.com/developerworks/ru/library/wa-antipool/index.html?ca=dre-ru-1210