Установка и настройка Django на “боевом” сервере с CentOS 5

Django Fett )

Django не нужен?)

установка Pylons в Gentoo - emerge pylons sqlalchemy
Django не нужен! Pylons наше всё.

ПС apache тоже не нужен lighttpd наше всё!

Статья о том, что установка и настройка Django на “боевом” сервере с CentOS 5 нетривиальна?

С какими граблями столкнулся автор? Что заставило его написать статью?

> apache тоже не нужен lighttpd наше всё!

Кому-как. Для локалхоста достаточно и самоделки.

В общем-то да, нетривиальна. Некоторых пакетов нет в официальных репозитариях, или сильно старой версии... Кое-где документация не в тему (например, Using eggs with mod_python).

В общем статья нормальная, но явно не дотягивает до новости на LOR

>> apache тоже не нужен lighttpd наше всё! > Кому-как. Для локалхоста достаточно и самоделки.

гляжу вот тут на один сайтик работающий на "самоделке" lighttpd/1.4.18

Average queries per second: 1013

Total searches today: 6,909,860 (345493 per hour, 5609 per minute, 93.4 per second)

Интересный блог с одним постом. И эту лажу пропустили в качестве новости.

очень слабо. даже статьи ibm_dw интересней )

В убунте это ставится и настраивается за пять минут штатными средствами.

А зачем пятон на “боевом” сервере? Логичнее вроде бы наоборот удалять всё ненужное с “боевого” сервера-то.

>даже статьи ibm_dw интересней )

какое клевое оскорбление) спасибо, добавил себе в арсенал.

... а теперь хотелось бы послушать начальника транспортного цеха с рассказом о глобальности и надежности JAVA и PHP (ведь мы все прекрасно знаем, что rails/django - это только для тех, кто ниасилил глобальный и надежный php и ынтырпрайз java)

Полезная статья, на мой весьма непрофессиональный взгляд

В статье опечатка:
> а менее ресурсоемким сервером – *lighhtpd*

Зачем использовать
> ln -s `pwd`/django-trunk/django /usr/lib/python2.4/site-packages/django
вместо
"ln -s django-trunk/django /usr/lib/python2.4/site-packages"
От этого что-то изменится?

Упс

s%\"ln -s django-trunk/django /usr/lib/python2.4/site-packages\"/\"ln -s django-trunk/django /usr/lib/python2.4%site-packages/django\"%

Опечатку исправил, спасибо.

А с `pwd` - это я из официальной документации скопировал, если `pwd` и слэш убрать, ничего не изменится, насколько я понимаю...

> Для локалхоста достаточно и самоделки.
для локалхоста достаточно ./manage.py runserver набрать)

Вывод: CentOS 5 для django ну никак не подходит

>Вывод: CentOS 5 для django ну никак не подходит

Зато убунту подходит по всем статьям. Но не подходит для боевого сервера :-( Дебианщики есть? Как там с вышеперечисленными пакетами?

mod_wsgi по всем статьям уделывает mod_python (который впринципе самый медленный особенно с опачем) и он теперь бана^W портирован для nginx;)

./configure
make
make install

...

python setup.py install


да, такими советами вы быстро научитесь превращать любой сервер в необновляемый

Я только не пойму, "man django" (или что-то вроде) уже не катит? Или это версия "Для продвинутых чайниов aka кофейников"??

я чета дофига придираюсь, но можно и просто:

export PATH=${PATH}":/путь/до/джанги/django/bin"
export PYTHONPATH=${PYTHONPATH}":/путь/до/джанги"

добавить с скрипт-запускалку или конфиг (возможно будет чуть по-другому в зависимости от сервера)

> Установка и настройка Django на “боевом” сервере

и эти люди ругают gentoo за то, что там все это делается штатными средствами, а не путем насилования системы управления пакетами и всего остального, чем так гордятся поклонники тырпрайз дистрибутивов?

Debian Etch. Разворачивание MySQL + lighttpd + django и их настройка занимает не более получаса.

хватит уже постить ссылки на подобные опусы. люди, не знающие, как действительно настраивается боевой сервер, могут подумать, что это действительно так все и делается. или, как минимум, указывайте, что информация взята из крайне сомнительных источников.

> да, такими советами вы быстро научитесь превращать любой сервер в необновляемый

+1

Да, и в комментариях к той же статье

В: Мне кажется, что вместо компиляции memcached из исходников лучше добавить в yum репозиторий rpmforge, тогда не будет проблем с обновлениями.

О: Может, с определенной точки зрения и лучше. Но мне не хотелось сторонние репозитарии добавлять…

Угу, добавить сторонний репозиторий - это не Ъ. Надо всё с сырцов собирать.

> Debian Etch. Разворачивание MySQL + lighttpd + django и их настройка занимает не более получаса.

да-да-да. lighttpd из штатного репозитория etch (вы же не ставите пакеты из неофицальных репозиторияв, которые не были оттестированы и проверены разработчиками debian?) тянет за собой emacs, xlib и пр. мусор, зато собран без ssl и версии с дырами, которые были заделаны больше года назад.

Вы уж тогда до конца цитируйте... Все равно там не все, что нужно, в rpmforge есть, в любом случае что-то из исходников придется компилировать. А то, что есть, - старое.

> Угу, добавить сторонний репозиторий - это не Ъ. Надо всё с сырцов собирать.

ну, видимо, до попадания граблями по лбу необходимость использования родной пакетной системы кажется неочевидной;)

Вообще, как-то мне кажется устанавливать на _боевой_ сервер программу из _транка_ svn-овского это как-то.. Видимо жутко надежно.

хз кто там что увидел на debian etch, но lighttpd из репозитория debian lenny собран с ssl, не тянет за собой ничего лишнего, а так же имеет версию 1.4.19. у debian с пакетами как правило вообще никаких проблем нет

> mod_wsgi по всем статьям уделывает mod_python (который впринципе самый медленный особенно с опачем) и он теперь бана^W портирован для nginx;)

использовать nginx с mod_wsgi в нынешнем его виде - самоубийство. куча багов, стабильной версии в обозримом будущем не ожидается

> использовать nginx с mod_wsgi в нынешнем его виде - самоубийство. куча багов, стабильной версии в обозримом будущем не ожидается

а баги воспроизводимые ?

В статье только одна полезная вещь: настройка переадресовки статического контента на lighttpd. И то с оговорками - не могу догадаться кому придет в голову ставить два веб-сервера на одну машину - процент ускорения не должен быть слишком велик, чтобы так заморачиваться. Все же это решение для двух машин.

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

Во-первых, можно было взять srpm из livna.

Во-вторых, если уж чем-то не нравятся пакеты для fedora, существует программа checkinstall.

> Вообще, как-то мне кажется устанавливать на _боевой_ сервер программу из _транка_ svn-овского это как-то.. Видимо жутко надежно.

В джанго транк очень стабилен. Его официально используют на боевых серверах. К тому же ничего не мешает сначала обновлять транк на локальной машине, прогнать ./manage.py test, протестировать сайт ручками, а потом обновлять на серваке.

А 0.96 версия действительно очень слабовата. Мы на ней оставались до упора, но потом выяснили, что некоторые багофичи реально мешают нормально жить, и перешли на транк. Все работает стабильно.

может потом куда-нить кину srpm пакеты mod_fastcgi/memcached ..

Неужели ещё никто не начал сравнивать фреймворк Django с языком PHP?!

> Неужели ещё никто не начал сравнивать фреймворк Django с языком PHP?!

Что такое PHP и чем оно лучше python'а?

>В статье только одна полезная вещь: настройка переадресовки >статического контента на lighttpd. И то с оговорками - не могу >догадаться кому придет в голову ставить два веб-сервера на одну машину >- процент ускорения не должен быть слишком велик, чтобы так >заморачиваться. Все же это решение для двух машин. Тут вы не правы. На счет ускорения не в курсе, но с нагрузками справляется связка с кешируюцим статику фронтэндом гораздо лучше, особенно если много статичной графики. Правда предпочитаю nginx. Лично у меня на дедиках LA снижался после установки связки где-то на треть. >Статью можно назвать отчасти вредной за то, что автор использует сборки >программ из исходников, не упаковывая получившееся в rpm. +100 Необходимо осилить rpmbuild >Во-первых, можно было взять srpm из livna. Тут раз на раз, хотя на 80 процентов пакеты совпадают. Часто для центос заимствовал более свежий GD и ImageMagick.

спасибо паблевал apache и centos правда не нужны

> В джанго транк очень стабилен.
к сожалению, ни хрена =((
как повезет.
> Его официально используют на боевых серверах.
т.к. выбора особого нет
впрочем "стабильная" версия еще менее стабильна чем svn =(
причем они несовместимы в нескольких местах

а почему выбран вариант с mod_python, а не fcgi?

> Дебианщики есть? Как там с вышеперечисленными пакетами?

Все это разворачивается минут за 30-40 с нуля и без таких вот танцев

Debian - Как же, как же.
python - 2.4 ну это попровимо,
а вот modpython2.5 не встает по дефолту.

> версии с дырами, которые были заделаны больше года назад.

Про дебиановские обновления безопасности, вы разумеется не в курсе?

http://www.debian.org/security/

Последнее исправление для lighttpd - http://www.debian.org/security/2008/dsa-1540

>да-да-да. lighttpd из штатного репозитория etch (вы же не ставите пакеты из неофицальных репозиторияв, которые не были оттестированы и проверены разработчиками debian?) тянет за собой emacs, xlib и пр. мусор, зато собран без ssl и версии с дырами, которые были заделаны больше года назад.

Что-то у нас с руками не то, а может и с головой...

http://packages.debian.org/etch/lighttpd

> а почему выбран вариант с mod_python, а не fcgi?

потому что в мануалах по джанго описано как ставить с mod_python

> а почему выбран вариант с mod_python, а не fcgi?

Потому что mod_python рулит, а fcgi тихо посасывает в сторонке.

>потому что в мануалах по джанго описано как ставить с mod_python

А также там написано, как ставить на fcgi.