Виртуальный хостинг для Django (FreeBSD + Apache + mod_python / mod_wsgi)

[Vintorez]

Да, я в курсе, что Ваше сочетание удобнее предложенного. Скажу даже больше — Ваш подход практичнее для создания высоко нагруженных проектов (если еще добавить memcached). Но в данном случае я описал конфигурацию с Apache. Возможно, тем, кто пользуется этим web-сервером приведенная информация будет полезна. Знания лишними не бывают. :)

И кстати, с удовольствием прочитал бы про Вашу реализацию! Буду ждать топика!

[Istergul]

У нас аналогично.

[rule]

с вас значит тоже топик :-)

[xenolog]

О! напиши, плиз. я наверное тоже напишу про эту связку.
будет шанс сравнить и взять лучшее

[xenolog]

ага, давай делиться:
habrahabr.ru/blogs/django/139270/

[gigimon]

Убивать за упоминание mod_python, он уже давным давно не развивается, труп и deprecated.
А так, очередная статья как поднять простое

[xenolog]

про mod_python — согласен.
А вот про «поднять простое» — нет.
когда только начинаешь — очень не хватает толковой статьи как это _правильно_ сделать. И ответов на вопрос «а как это вообще бывает» тоже.

[Vintorez]

Благодарю за поддержку! :)

[gigimon]

да ладно, даже в оф доке есть инструкци docs.djangoproject.com/en/1.3/howto/deployment/modwsgi/
А сколько их в рунете ууу

[xenolog]

пиши, пиши…
обмен опытом всегда полезен. Часто бывает ценна даже не сама статья, а те идеи, которые там проскакивают намеком.

[Vintorez]

Писать стоит! В официальной документации слишком сухой язык. Не хватает реальных примеров.

[xenolog]

да ладно, даже в оф доке есть инструкци

да, есть.
Но врагу не пожелал бы следовать им.
как и держать в штатном месте (/var/www и аналогичном) что либо отличное от тестового сайта на локалхосте. С чьими правами оно там будет исполняться?

[Vintorez]

По поводу mod_python я в статье предупредил сразу, что он устарел. Поэтому не нахожу смысла в цитировании меня же в комментариях к моей статье. Но дело, конечно, Ваше!

[Regis]

Так зачем же было про него вообще писать, раз он устаревший и вы всё равно пишете про нормальный вариант? )

[Vintorez]

Ну, я привел два варианта просто для сравнения, захватив при этом кусочек истории (в виде mod_python). Так как FastCGI меня не прельщает, а uWSGI я еще не успел опробовать, поэтому описал приведенные модули. Может кому и пригодится — у людей разные капризы бывают. А как сказал Доктор Шелдон Купер: «Ну, жизнь без капризов — это не жизнь!» )

[egorinsk]

Ваше решение имеет очень серьезные недостатки.

По моему, так те, кто серверную папку ставят в /home, недалеко ушли от тех, кто в Windows все валят в корень c:. А как это папку потом вынести на сетевое хранилище? Как обеспечить доступ других пользователей?

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

Плюс, в вашей схеме надо руками создавать конфиг для каждого сайта. Не надоест? А если все 100 конфигов надо будет обновить? Вот, в нгинксе, например можно как-то регуляркой все эти хосты описать. (в апаче тоже есть nameVirtualHost, но он 100% неюзабелен).

[egorinsk]

Тогда надо дать серверу права на запись в /etc, что небезопасно. Проблема массового обновления конфигов тоже остается.

[shoorick]

По моему, так те, кто серверную папку ставят в /home, недалеко ушли от тех, кто в Windows все валят в корень c:

Апач под FreeBSD по умолчанию держит сайты в /usr/local/www, чем автору не понравился этот путь — непонятно. Мы (занимаясь хостингом) оставляем сайты именно там — просто домашние каталоги пользователей, размещающих у нас сайты, находятся, например, в /usr/local/www/data/SiteName. Плюс к этому, /usr/local/www, как правило — или отдельная файловая система, или вообще отдельный физический диск.

[Vintorez]

Я в статье забыл озвучить, что данный вариант приведен для тестового локального хоста (извиняюсь перед всеми). Поэтому о хостнге на настоящей рабочей станции здесь и не может идти речи.
Раздел /home у меня физически на отдельном жестком диске, потому и складываю туда все наработки. Я не думаю, что это критично, ведь я в любой момент могу все перенести в тот же /usr/local/www, а все конфиги проекта поправить чем-то вроде:
grep home/valera ./* | sed -i -e 's/home\/valera/usr\/local\/www/g' *
Или я не прав?

[shoorick]

Перезапускаем сервер:
/usr/local/etc/rc.d/apache22 restart

А зачем так? Есть же apachectl — он есть и для 1.3, и для 2.2, сидит в /usr/local/sbin, то есть по пути, упоминающемуся в $PATH у рута. Я для перезапуска апача просто пишу apachectl restart — этого вполне достаточно.

[Vintorez]

Не буду умничать, а приведу цитату из книги Майкла Лукаса, отмеченной у меня в списке литературы: «Хотя утилита apachectl(8) работает очень неплохо, рекомендую применять сценарий запуска, интегрированный в операционную систему FreeBSD. Этот сценарий запускает apachectl(8) с особыми настройками, необходимыми именно в вашем случае, и гарантирует, что при следующей загрузке системы сервер Apache будет работать точно так же, как до ее останова».
Ну, а на самом деле, я просто привык так поступать. Хотя, когда сильно тороплюсь, делаю как Вы.