Рецепты настройки Apache2

Файл доступа к серверу

Сервер Apache предоставляет широкий выбор возможностей, позволяющих сделать сопровождение сервера более удобным; некоторые из них находят применение в обеспечении защиты информации на вашем Web-узле. Файл доступа к серверу (/usr/local/etc/httpd/conf/access.conf) позволяет включать либо выключать такие возможности на уровне отдельных каталогов.

Кроме того, этот файл используется для ограничения доступа к вашему серверу некоторых пользователей и компьютеров. Более подробно эти возможности рассмотрены в разделе ⌠Доступ и идентификация■. На данном этапе мы произведем лишь минимальную их настройку, необходимую для работы сервера.

Откройте в редакторе файл access.conf. Входящая в поставку копия файла access, conf предоставляет три варианта описания доступа: один для каталога cgi-bin, другой для каталога документов, а третий демонстрирует некоторые возможности управления доступом к различным каталогам.

Первое описание позволяет управлять каталогом сценариев CGI. Обратите внимание, что в файле используется синтаксис языка HTML, в котором тег <Directory /usr/local/etc/httpd/cgi-bin> отмечает начало секции с описанием опций для используемого сервером по умолчанию каталога cgi-bin. Эту секцию закрывает тег </Directory>.

Вторая директива должна выглядеть следующим образом:

<Directory /usr/local/etc/httpd/htdocs>

Если вы изменили название корневого каталога для документов в файле srm.conf, следует внести это изменение и в файл access.conf.

Третья директива, <Location>, является новой возможностью сервера Apache. Она подобна директиве <Directory>, только вместо названия каталога указывается адрес URL. Этот адрес URL может указывать на каталог, отдельный файл либо содержать шаблон (строку *.html). В директиве <Location>, уже присутствующей в файле srm.conf, задается область, резервируемая для проверки вебмастером состояния сервера, /status. Доступ к этой области разрешен только пользователям домена nowhere.com. Если вы замените nowhere.com названием вашего домена, то получите возможность пользоваться этой информацией о состоянии (если вы откомпилировали модуль mod_status.c.

Сохраните файл access.conf и выйдите из редактора. Теперь можно начинать планировку Web-пространства.

Планировка Web-пространства

Существует несколько способов предоставления клиентам файлов из вашего Web-пространства. Как уже отмечалось, в директиве DocumentRoot файла srm.eonf задается основной каталог для ваших документов. Способ, которым сервер приводит в соответствие адресам URL файлы из файловой системы на вашем компьютере, иллюстрируется следующим примером адреса URL: http://www.shoop.com/home.html.

Сервер берет путь, указанный в директиве DocumentRoot, и добавляет к нему имя файла home.html. Если вы не изменяли принятое по умолчанию значение DocumentRoot, то сервер передаст клиенту файл /usr/local/etc/ http/htdocs/home.html. Помещать все файлы и каталоги, предназначенные для клиентов, в каталог ServerRoot или его подкаталоги не обязательно. Можно организовать Web-сервер по-другому.

Каталоги, управляемые пользователем

Включить возможность управляемых пользователями каталогов HTML можно при помощи директивы UserDir в файле srm.conf. Эта опция задает общее название подкаталога в домашних каталогах всех пользователей, из которого будут браться файлы, предназначенные для клиентов. По умолчанию это подкаталог public_html.

Доступ к таким каталогам производится при помощи адреса URL, в котором путь в каталоге начинается со знака тильды (~), за которым следует регистрационное имя пользователя. Когда сервер получает запрос с таким адресом URL, он ищет в файле /etc/passwd название домашнего каталога пользователя. Проследить связь между адресом URL и этим каталогом можно на примере http://www.shoop.com/~chris/index.html.

Если у пользователяchris есть домашний каталог /home/users/chris, a значением параметра UserDir является public_html, то по этому запросу сервер передаст файл /home/users/chris/public_html/index.html.

Установка псевдонимов

Привести в соответствие отдельным адресам URL каталоги в вашей системе можно, воспользовавшись директивой Alias в файле srm.conf. Это дает возможность предоставлять клиентам файлы, находящиеся не в корневом каталоге для документов или его подкаталогах. Например, если вам нужно предоставлять документы из каталога /public/ftp/multimedia, можно сделать их доступными на сервере ShoopSoft по запросу адреса URL http:/ /www.shoopsoft.com/multimedia:

Alias /multimedia /public/ftp/multimedia

В настоящее время сервер Apache позволяет задать таким образом не более 50 псевдонимов. Если требуется большее число псевдонимов, придется переопределить макрос MAX_ALIASES в файле /usr/local/etc/httpd/src/ httpd.h и заново откомпилировать сервер.

Символьные ссылки

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

Например, вы решили оставить в директиве DocumentRoot значение по умолчанию, /usr/local/etc/httpd/htdocs. Теперь вы можете сделать корневым каталогом для документов каталог /public/html, введя команду:

#ln -s /public/html /usr/local/etc/httpd/htdocs

Соглашением, принятым для удобства обслуживания, является создание ссылки на корневой каталог документов из корневого каталога системы. Если для названия корневого каталога документов использовалось значение по умолчанию, /usr/local/etc/httpd/htdocs, то ссылку на него из корневого каталога можно создать при помощи команды

# In -s /usr/local/etc/httpd/htdocs /html

Эта команда упрощает доступ к подкаталогам каталога ServerRoot, избавляя от необходимости набирать на клавиатуре длинные пути. Это также является хорошим мнемоническим средством для пользователей, не знакомых со средой UNIX. Пользователи легко запомнят, что их Web-страницы находятся в каталоге /html. В приводимых далее примерах подразумевается наличие у вас такой ссылки. Однако если задать слишком много символьных ссылок, то время, сэкономленное на вводе с клавиатуры, будет потрачено на поиск действительного местоположения файла в нагромождении ссылок. Следите за своими ссылками и используйте их только там, где это необходимо.

Другие соображения

То, каким образом вы решите организовать собственный Web-узел, в немалой степени зависит от характера вашей организации и назначения вашего сервера, а также от контингента пользователей. Например, многие университеты предоставляют домашние страницы своим студентам. Регистрационные счета студентов являются недолговечными по определению, поэтому использование метода UserDir (когда документы хранятся в подкаталоге public_html домашнего каталога пользователя) является здесь вполне уместным. Когда студент заканчивает обучение, его доступ к системе ликвидируется, а домашний каталог ≈ уничтожается, при этом исчезает и каталог с Web-документами. Любые квоты, выделенные домашним каталогам студентов, распространяются и на их Web-документы, снимая необходимость выделения отдельных квот специально для Web-документов.

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

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