О портах в nginx

Потребовалось развернуть 2 разных инстанса сервера на джанго на одном и том же хосте, но на разных портах.
Django крутится в mod_wsgi за nginx.
На первый взгляд всё выглядело нормально, но сюрприз образовался, когда попытался я зайти в админку: после логина следовал редирект на сайт с дефолтным 80-м портом (хотя в админку я залезал по другому порту).
Вскрытие (спустя более часа разбирательств) показало, что во всём виноват проксирующий nginx, в котором была прописана директива "proxy_set_header Host $host:$server_port;". Всё легко разрешилось добавлением порта - "proxy_set_header Host $server_port;".

Pip, о сколько в этом слове...

Что-то вот совсем понять не могу в чём проблема и как её диагностировать:
Через fabric создаётся новый virtualenv и в него устанавливаются все зависимости с помощью "pip install -r requirements.txt". Всё вроде бы хорошо, но иногда pip зависает на продолжительное время и весь процесс занимает десятки минут вместо стандартного времени менее минуты.

А мужики-то не знают!

Обнаружил , что у pip есть опция кэшировать загружаемые пакеты. Для этого надо присвоить переменной окружения $PIP_DOWNLOAD_CACHE папку, где будет располагаться этот кэш.
Забавно, но на оф. сайте pip эта опция фигуриует только в новостях.
На самом деле захотелось сделать развёртывание совсем с 0, с созданием virtualenv и не заморачиваясь на исправление зависимостей, но каждый раз скачивать десяток мегабайт по-моему всёж некоторое расточительство, особенно когда состав пакетов менятся довольно редко. Пусть даже и в наше время мегабитных подключений.

Спасибо русским программистам!

Предыдущая война с mod_wsgi закончилась в итоге тем, что Apache был "спрятан" за проксирующий nginx, что решило проблему с "залипающими" запросами. Заодно и статике теперь должна оптимальней отдаваться.
Думал было использовать ещё Nginx upload module, написал даже нужный код (т.к. данные в итоге приходят немного иначе). Однако, по запарке забыл код обновить, а в результате обнаружилось, что оно и без этого замечательно работает. Поэтому оставил пока тот вариант "на всякий пожарный". Хотя толком не помешало бы тесты сделать, чтоб понять, даст ли оно какую-либо разницу.
В любом случае nginx рулит, спасибо Игорю Сысоеву.

WSGI...

Вот толи я неважный линуксовый админ, толи в связке CentOS+mod_wsgi что-то "нетак":
время от времени Apache "затыкается" и из внешних признаков обнаружились лишь записи с "Premature end of script headers:" для сайта на Django. Причём вчера такое поведение получилось повторить сделав touch одному из wsgi-скриптов, ошибки же повалились для другого сайта, откуда могут тут взяться "наведённые" проблемы совершенно непонятно.
Возможно, надо обновить mod_wsgi с 2.5 до 2.8, или вообще собрать по-нормальному другой сервер (и плюнуть на CentOS), но пока чуть поживём с непонятками.

А кончил за упокой...

Для первого нашего Django-проекта я решил использовать South, чтобы меньше заморачиваться с модификациями БД (например, выполнять их автоматически при деплойменте). Всё здорово, но вот в версии 0.5 была подлая "засада" - South не совсем корректно понимал вариант, когда default для полей задавался через callable. Приходилось ручками править определение поля, создавать миграцию, а потом исправлять поле на первоначальный вариант. Однако вышла версия 0.6 и там это было исправлено. "Здорово" подумал я, но не тут-то было :)
Проблема возникла в обновлении версии пакета, который был поставлен в virtualenv через pip. В документации к pip данный вопрос вообще никак не освещается. Путём гугления обнаружилась опция --upgrade, только вот указывать для файла с зависимостями оказалось неверным вариантом, потому как через зависимости тянулся почему-то злосчастный PIL, некорректно устанавливающийся.
Пришлось делать апгрейд пакета отдельно ручками как

pip -E . install --upgrade South

Но в site-packages остаются "концы" от старой версии 0.5, поэтому их пришлось ручками стереть.
Python, конечно, неплохой язык, но вот всё чаще вспоминаются слова dmz про package hell, и это далеко не радует.

R.I.P. mod_python

Проблемы в CentOS разрешились тривиальным удалением mod_python (с его помощью публиковался trac). Одновременно включить его и mod_wsgi не удалось, да и не нужно в принципе, trac ведь может и через wsgi работать.
В общем не надо 2 разными способами решать одну и ту же задачу одновременно - скорей всего только заморочки лишние нарисуются.

О сколько нам пакетов чудных...

Пытаюсь сейчас разобрать деплоймент Django-приложений. Остановился на fabric, virtualenv и pip. Всё вроде бы интересно, но вот возникли некоторые неувязки - PIL не устанавливается через

#pip install PIL

можно, конечно использовать

#pip install http://effbot.org/downloads/Imaging-1.1.6.tar.gz

но как-то "не спортивно", поэтому захотелось использовать site-packages куда будут установлены некоторые "дефолтные" пакеты (в т.ч. PIL). Только вот окружения, созданные через virtualenv, не хотели видеть глобальные пакеты. Пришлось посерьёзней разобраться с разбором импортов в python.
Причина оказалась в том, что товарищи из Ubuntu "пошаманили" с python 2.6 и site-packages зовутся dist-packages, буквально-таки:

  if use_default_sitedirname:
      return pylib.replace('/dist-packages', '/site-packages')
  else:
      return pylib

поэтому ставить надо было не через sudo pip install/easy_install virtualenv, а с помощью sudo apt-get install python-virtualenv.
Теперь я понимаю, о чём Джеймс Беннет писал в своём посте про проблемы с пакетами.
Продолжу разбираться дальше и, наверное, напишу пост о варианте развёртывания, который у меня получится.