Настроить apache по взрослому, да и вообще о хостинге

1. разные мпм (мультипроцессные обработчики). от MPM зависит эффективность работы. для хостинга самый предпочтительный вариант mpm-itk, т.к дает возможность апачевским child-ам работать от указанного UIDа.

2. http://httpd.apache.org/docs/2.0/ru/

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

волшебной таблетки не существует.

Как сделать, чтобы для виртуального хоста была доступны директория...но не было даже намёков на доступ к другим поддиректориям

правильно выставить права доступа

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

Options +Indexes и -Indexes соответственно.

Что дальше с этим делать: делать /usr/share/drupal6 корнем виртуального хоста или создавать симплинк в /var/www/мойкрутойсайт.ru?

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

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

У вас отсутствует и то и другое. Т.е. вы не читали документацию и опыта у вас нет. Значит ставьте apache как попало, запускайте то, что вам нужно, нарабатывайте опыт. Потом, когда опыт придет, вопросы типа «чтобы сервер не был тормозным и чтобы меня никакой кулхацкер не мог сломать» отпадут сами собой.

>1. В репозитории, кроме метапакета apache2 имеются apache2-mpm-event, apache2-mpm-prefork и apache2-mpm-worker. При установке метапакета устанавливается apache2-mpm-prefork. Для чего нужны остальные?

Это разные вещи. Например, mpm-worker использует треды, а не форки, для работы. Это, в общем случае, улучшает производительность, но не все модули thread-safe. Например mod_php не thread-safe. Глобально, надёжно.

Впрочем, нужность воркера уже не та, так как быстрые сервера есть и вне апача (lighttpd, nginx), а mod_php всё равно работает нормально только на префорке.

Про itk сказали выше. От себя скажу, что для своего хостинга он, в общем-то, не всегда нужен. Мы, например, запускаем разные FastCGI процессы под разными юзерами, и этого хватает.

У кого есть нормальный русскоязычный справочник по директивам apache2?

Учи английский. Никто же не жалуется, что чтобы осилить математику нужно уметь немного считать в уме. Тут то же самое, хочешь понять - учи. Благо читать мануалы просто.

В продолжении вопроса про кулхацкера. Как сделать, чтобы для виртуального хоста была доступны директория /var/www/мойкрутойсайт.ru и /var/www/мойкрутойсайт.ru/docs, но не было даже намёков на доступ к другим поддиректориям /var/www/мойкрутойсайт.ru?

Смотреть на document root, всякие там directory и location в конфиге. В документации всё описано, там просто и логично.

Что дальше с этим делать: делать /usr/share/drupal6 корнем виртуального хоста или создавать симплинк в /var/www/мойкрутойсайт.ru?

Вопрос вкуса. Симлинк лучше, можно потом поменять содержимое, не трогая конфиг. В любом случае надо понимать, что некоторым приложениям нужны права на запись, поэтому просто так в /usr/... ссылаться нельзя.

Опять же, можно в хоме для юзеров класть например всё это.

В пакете ещё есть какая-то хрень в /etc/drupal

Конфиг

Зачем нужен этот огород?

Для обновлений. Это очень хорошо - появилась уязвимость, а тебе надо только aptitude дёрнуть и всё починится. Всегда б так.

Или лучше не обращать внимание на существование таких пакетов и ставить php-движки обычным способом: скачиванием и распаковкой?

Если не надо патчить или не надо новую версию - ставь с пакетов. Проще обновлять и меньше проблем - за тебя думает мэйнтейнер. Если надо новые версии, какие-то исправления или что-то ещё - ставь вручную в директорию сайта.

http://httpd.apache.org/docs/2.0/ru/.

Мало пользы от этой страницы. И дело не в том, что «Краткий справочник по директивам» на английском, при желании всё прочитать и разобрать можно, а дело в том что отсутствуют примеры и пояснения почему оптимально именно так.

Смотреть на document root, всякие там directory и location в конфиге. В документации всё описано, там просто и логично.

Такая запись проканает:

<VirtualHost *:80>
   ServerAdmin sunny0sergey@gmail.com
   ServerName iskatel.dyndns.info
   ServerAlias www.iskatel.dyndns.info
   DocumentRoot "/var/www/iskatel.dyndns.info"
   ErrorLog "/var/www/iskatel.dyndns.info/error.log"
   CustomLog "/var/www/iskatel.dyndns.info/access.log" common
   <Directory "/">
      Options None
      AllowOverride None
   </Directory>
   <Directory "/var/www/iskatel.dyndns.info">
      Options Indexes FollowSymLinks
      AllowOverride None
   </Directory> 
   <Directory "/var/www/iskatel.dyndns.info/*">
      Options None
      AllowOverride None
   </Directory>
</VirtualHost>

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

оптимально для чего или для кого?
для разных случаев оптимальные настройки могут кардинально отличаться.

Такая запись проканает

сайт в /var/www/iskatel.dyndns.info работать будет.

для разных случаев оптимальные настройки могут кардинально отличаться.

Тогда наверное мне следует описать мой конкретный случай.

Сайт №1 - мой домашний сайт, открытый во внешний мир. Пока делается лишь для того, чтобы изучить, как это работает. Вряд ли будет обслуживать более чем 15 клиентов одновременно, хотя мне было бы приятно.

Сайт №2 - скрипт wtorrent, для управления собственным клиентом rtorrent, доступен только мне.

Сайт №3 - скрипт phpmyadmin, для управления собственными базами mysql, доступный, понятное дело, тоже только мне.

появилась уязвимость, а тебе надо только aptitude дёрнуть и всё починится.

Или сломается ;)

Зачем городить сайты для 2х (wtorrent/phpmyadmin) скриптов? Поднимите ssl вариант сайта №1, положите их в диру на ssl версии сайта №1 и защитите ее паролем, который будете знать только вы.

могу лишь посоветовать для wtorrent и phpmyadmin увеличить memory_limit и max_execution_time. mpm-itk нужен только если работает mod_php, что подозреваю у тебя и будет.

>>появилась уязвимость, а тебе надо только aptitude дёрнуть и всё починится.

Или сломается ;)

изменяя ядро Drupal, ты убиваешь котенка.

если не лезть куда не попадя — ничего не сломается.

> изменяя ядро Drupal, ты убиваешь котенка.

страшно подумать сколько котят убивает комьюнити друпал.
б-же, у них все руки в крови!

Странное название темы. Как для трех виртуалхостов домашнего назначения.

изменяя ядро Drupal, ты убиваешь котенка.

Кроме drupal есть и другие продукты. И неизменность ядра drupal никак не гарантирует 100% корректную работу после обновления.

если не лезть куда не попадя — ничего не сломается.

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

вот уже почти два года «бездумно обновляю» несколько сайтов на 6-м друпале. ничего не перестало работать. ЧЯДНТ?

Кроме drupal есть и другие продукты.

ТС говорил о нем (и о медиавики, который тоже прекрасно обновляется).

ЧЯДНТ?

Когда очередной php (и не только) обновится и у какой-нибудь функции изменится формат ввода или вывода - узнаешь. Причем вполне возможно - узнаешь не сразу, ибо с виду «ничего не перестало работать»

ТС говорил о нем (и о медиавики, который тоже прекрасно обновляется).

ТС вообще не понимает о чем говорит, поэтому ему надо знать, что бездумно делать что-либо в т.ч. обновлять _разное_ по не следует.

Ваш замКО.

>>ЧЯДНТ?

Когда очередной php (и не только) обновится и у какой-нибудь функции изменится формат ввода или вывода - узнаешь. Причем вполне возможно - узнаешь не сразу, ибо с виду «ничего не перестало работать»

так кто бездумно обновится? drupal или php? вы уж определитесь.

не мелите чушь.

в пределах одного релиза дебиана _внезапно_ не обновится php с 5.2 на 5.3, и drupal не станет вдруг седьмым из шестого. а до того времени формат ввода-вывода функций не изменится.

так кто бездумно обновится? drupal или php? вы уж определитесь.

Научитесь читать цитаты, на которые отвечаете.
«Бездумное обновление всего подряд приводит к тому..»

_внезапно_ не обновится php с 5.2 на 5.3,

Внезапно с 5.2 на 5.3 совершенно не обязательно. И drupal'у вашему вовсе не обязательно становится 7м, чтобы что-нибудь сломалось после обновления.

короче. все понятно. толстота превышает разумные пределы.

предлагаю отправиться... небездумно обновлять свой LFS.

ТС говорил о нем (и о медиавики, который тоже прекрасно обновляется).

Ну я знаю два php-движка (хотя их наверное гораздо больше), которые существуют в виде deb-пакетов: mediawiki и drupal. Может быть drupal - пример неудачный, хотя ладно начали о нём - будеим говорить о нём. Смотрим содержимое пакета, кроме /usr/share/drupal6, в котором собственно скрипт и доков в /usr/share/doc/drupal6 он содержит:

/etc/cron.d/drupal6
/etc/drupal/6/apache.conf
/etc/drupal/6/htaccess
/etc/drupal/6/profiles/default/default.profile
/etc/drupal/6/sites/default/files
/etc/drupal/6/sites/default/settings.php
/usr/share/lintian/overrides/drupal6

ТС вообще не понимает о чем говорит, поэтому ему надо знать, что бездумно делать что-либо

Да, не понимаю. Я устанавливаю apache2 и вижу, что файл /etc/apache2/httpd.conf - пустой, видимо теперь он считается аттавизмом. Вижу, что все директивы, которые должны быть в нём теперь находятся в /etc/apache2/apache2.conf и ещё куча файлов и директорий, которые прикручены к нему при помощи include. Понимаю, что всё это придумано для того чтобы устанавливаемые модули начинали работать из коробки, но не понимаю как это редактировать, чтобы ничего не порушить. У меня сайт, находящийся на моём собственном сервере грузится за тоже время, что и сайты из Интернета. Разве это нормально?

>Что с этим делать?

Снести нафиг и поставить по-человечески официальную версию

думаю, прежде чем задаваться такими вопросами, не мешает узнать устройство дебиановской системы конфигов, почему так разложено по разным каталогам и файлам. очевидно же, в /etc/apache2/httpd.conf записываются те пользовательские директивы, которые не должны перезаписаться при обновлении apache ( и соответственно основного apache2.conf); в mods-available и sites-available записываются конфиги, относящиеся к доступным модулям и сайтам, конфиги которые активируюся командами a2enmod и a2ensite соответственно. в mods-enabled и sites-enabled названные команды создают симлинки. это все, конечно же, можно делать и руками, но зачем?

У меня сайт, находящийся на моём собственном сервере грузится за тоже время, что и сайты из Интернета. Разве это нормально?

нет, не нормально, но причина этого точно не в раскладках конфигов апача.

Что с этим делать? Ну /etc/dru...

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

надо знать, что в друпале сайты (друпал поддерживает мультисайтинг) максимально отделены от основного движка. если скачать официальную версию, то можно обнаружить внутри с десяток каталогов. так вот, что-то править и что-то писать можно только в одном: в каталоге sites. туда кладутся все модули, темы и библиотеки сайтов. там же лежат и конфиги сайтов. если пользователь что-то поправит в каталоге include, к примеру, то отгребет неприятностей при следующем обновлении гарантировано.

соответственно, мейнтейнеры дебиана справедливо рассудили, что то, что доступно пользователю — кладем в /etc/drupal6/, что ему не подвластно — в /usr/share/drupal6

в общем случае, если принять что сайт на друпале на серваке у нас один, создаем в каталоге /etc/drupal/6 еще три директории: modules, themes, libraries и кладем в них соответствующее наполнение. если же нужно изменить что-то в файлах ядра, ручками своими погаными в /usr/share/drupal6 не лезем, а аккуратненько создаем новый модуль, в котором при помощи хуков ядра изменяем функции API.

фатально вредно не обновление без особых заморочек (если, конечно, это не gentoo), вредно бездумное изменение конфигов и структуры. если кто-то так сделал конфиги, значит так нужно.

> Я устанавливаю apache2 и вижу, что файл /etc/apache2/httpd.conf - пустой, видимо теперь он считается аттавизмом

это только в идиотском дебилиане подобное.
во фре, слаке, центоси - httpd.conf на месте и работает. правда чуть в разных местах лежит. в линуксах в /etc а во фре в /usr/local/etc/

У меня сайт, находящийся на моём собственном сервере грузится за тоже время, что и сайты из Интернета. Разве это нормально?

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

> то, что доступно пользователю — кладем в /etc/drupal6/

root-у разве что. пользователям писать в /etc глупо и вредно. даже если это /etc/drupal.

>root-у разве что. пользователям писать в /etc глупо и вредно. даже если это /etc/drupal

ну имеется в виду человеку, администратору. не машине

имхо правильнее всего не доверять установку веб-движков пакетменеджеру.
веб-движок должен ставиться в /home/hostingusers/userXXX/www/
права на запись и чтение этой директории должны быть только у userXXX, и apache должен работать с mpm-itk с AssignUserID userXXX. вот это - по взрослому.

Да кстати, вы уж определитесь где сайты правильнее всего держать: ну то что не в /usr это понятно? А вот в /var или в /home?

>имхо правильнее всего не доверять установку веб-движков пакетменеджеру.

почему, если ядро движка все равно не доступно для записи пользователя?

веб-движок должен ставиться в /home/hostingusers/userXXX/www/

и отдать ему на откуп обновление дыр движка? если предлагать именно drupal-хостинг, то ему достаточно оставить возможность писать в /home/hostingusers/userXXX/drupalsite, то есть только в ту часть движка, которая нужна только ему, его модулям, темам и библиотекам. при этом можно у него забрать даже обновление «обязательных» модулей, вроде views, cck и token, установив их в /etc/drupal/6/sites/default/

права на запись и чтение этой директории должны быть только у userXXX,

проверю как-нить на досуге, можно ли мультисайтинговую схему реализовать через mpm-itk. по идее вроде можно.

>А вот в /var или в /home?

все юзерозависимое в /home. в /var/www должна лежать только дефолтная заглушка без всяких движков и проч.

это только в идиотском дебилиане подобное.

во фре, слаке, центоси - httpd.conf на месте и работает. правда чуть в разных местах лежит. в линуксах в /etc а во фре в /usr/local/etc/



гриш, что-то там админиш еще ?
умник <вырезано цензурой>
http://wiki.apache.org/httpd/DistrosDefaultLayout

а ТС сперва документацию читать и аглицкий изучать