Денис Колисниченко - Linux: Полное руководство Страница 98

OPTIONS="-DSSL"

Вам нужно только добавить нужные параметры в директиву OPTIONS, а обо всем остальном позаботится сценарий запуска /etc/init.d/httpd. Нужно отметить, что файл /etc/sysconfig/httpd появился в версии Apache 2.0.

16.6. Сценарий запуска сервера Apache /etc/init.d/httpd

Стандартный сценарий запуска веб-сервера Apache устанавливается из того же пакета, что и сам сервер, В версии Apache 2.0 можно вызывать сценарий запуска со следующими параметрами:

♦ start — запуск сервера;

♦ stop — завершение работы сервера;

♦ restart — перезапуск сервера;

♦ status — информация о работе сервера;

♦ condrestart — перезапуск сервера при наличии файла /var/run/httpd.pid. Этот файл создается при запуске сервера и удаляется при его останове. Если файл httpd.pid не удален, значит, сервер не был остановлен корректно: например, произошел сбой системы или банальное отключение питания.

Что же касается более старых версий Apache, то сценарии запуска позволяют указывать куда больше параметров, чем во второй версии:

♦ start — запуск сервера;

♦ stop — завершение работы сервера;

♦ restart — перезапуск сервера;

♦ reload — перезагрузка сервера. В отличие от перезапуска, когда сервер сначала останавливается командой kill (то есть, просто «убивается»), а потом запускается, при перезагрузке серверу передается сигнал HUP. Перезагрузка может понадобиться при изменении файла конфигурации сервера, чтобы изменения вступили в силу;

♦ condrestart — то же, что и одноименный параметр, описанный выше;

♦ status — информация о работе сервера;

♦ fullstatus — более подробная информация о работе сервера;

♦ help — подсказка;

♦ configtest — проверка файла конфигурации.

16.7. Графические конфигураторы Apache

Практически все параметры веб-сервера Apache можно установить, используя конфигуратор netconf (п.14.1.1). Запустите netconf от имени суперпользователя и выберите Server Tasks, а затем Apache Web-server. С помощью netconf вы легко можете определить виртуальные узлы, назначить параметры подкаталогов, определить спецификацию каталогов и модулей, а также установить параметры модуля mod_ssl (см. рис. 16.2), настройка которого рассмотрена далее в этой главе.

Рис. 16.2. Конфигурирование модуля mod_ssl

В дистрибутив Fedora Core включен более удобный конфигуратор system-config-httpd (рис. 16.3).

Рис. 16.3. system-config-httpd

16.8. Каталоги пользователей

Директива UserDir включает поддержку пользовательских каталогов. Эта директива определяет общее название подкаталога в домашних каталогах всех пользователей. По умолчанию используется каталог public_html. Данная возможность очень удобна при использовании ее в большой корпорации, где каждый сотрудник имеет собственную страничку. Раньше эта возможность часто использовалась на серверах, предоставляющих бесплатный хостинг. Может быть, помните адреса вида http://www.chat.ru/~mypage?

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

Доступ к файлам, расположенным в этих каталогах, производится с помощью указания регистрационного имени пользователя после имени сервера через тильду-слэш. Например, пусть имя сервера www.server.com, имя пользователя — denis, тогда URL-адрес будет выглядеть так: http://www.server.com/~denis. При этом сервер самостоятельно определит, где именно расположен домашний каталог пользователя. Если это каталог /home/den, то сервер передаст клиенту файл /home/den/public_html/index.html.

16.9. Виртуальный HTTP-сервер

Концепция виртуальных узлов позволяет одному серверу Apache поддерживать несколько сайтов. Пользователи видят отдельные веб-узлы, и получается, что один веб-сервер заменяет несколько. Это очень удобно, если нужно организовать персональные веб-сайты пользователей или собственные узлы подразделений компании, например, develop.mycompany.com.

Сервер Apache можно настроить несколькими способами: либо так, чтобы запускался один сервер, который будет прослушивать все обращения к виртуальным серверам (такой вариант настраивается при помощи директивы VirtualHost), либо запускать отдельный процесс для каждого виртуального сервера (в этом случае применяются директивы Listen и BirdAddress). В этом параграфе я буду рассматривать первый вариант.

Внутри блока директивы VirtualHost можно использовать любые директивы, кроме ServerType, BindAddress, Listen, NameVirtualHost, ServerRoot, TypesConfig, PidFile, MinRequestPerChild, MaxSpareServers, MinSpareServers, так как некоторые из них относятся к основному HTTP-серверу (например, ServerType), а некоторые — ко второму варианту настройки виртуальных серверов и здесь неприемлемы. Обязательно должны присутствовать директивы ServerName, DocumentRoot, ServerAdmin и ErrorLog.

В зависимости от версии и от настроек Apache виртуальные узлы могут прописываться либо в файле httpd.conf, либо в файле vhosts.conf.

Виртуальные серверы можно идентифицировать по имени или по IP-адресу.

16.9.1. Виртуальные серверы с идентификацией по имени

Идентификация по имени имеет существенное преимущество перед идентификацией по IP-адресу: вы не ограничены количеством адресов, имеющимся в вашем распоряжении. Вы можете использовать любое количество виртуальных серверов, и при этом вам не потребуются дополнительные адреса. Такое возможно благодаря использованию протокола HTTP/1.1. Данный протокол поддерживается всеми современными браузерами.

Поддержка виртуальных узлов обеспечивается директивами VirtualHost и NameVirtualHost. Если ваша система имеет только один IP-адрес, его нужно указать в директиве NameVirtualHost. Все блоки VirtualHost будут использовать этот IP-адрес.

Внутри блока VirtualHost записывается директива ServerName, задающая доменное имя для создаваемого виртуального сервера. Ее обязательно нужно записать, чтобы избежать поиска службой DNS — вы же не хотите, чтобы при неудачном поиске виртуальный сервер был заблокирован? Другие директивы в блоках VirtualHost описывают параметры каждого виртуального сервера в отдельности (листинг 16.10).

Листинг 16.10. Два виртуальных сервера — www и lib

ServerName den.dhsilabs.com

<NameVirtualHost 192.168.1.1>

<VirtualHost 192.168.1.1>

 ServerName www.dhsilabs.com

 ServerAdmin [email protected]

 DocumentRoot /var/httpd/www/html

 ErrorLog /var/https/www/logs/error.log

 TransferLog logs/access.log

</VirtualHost>

<VirtualHost 192.168.1.1>

 ServerName lib.dhsilabs.com

 ServerAdmin [email protected]

 DocumentRoot /var/httpd/lib/html

 ErrorLog /var/https/lib/logs/error.log

 TransferLog logs/access.log

</VirtualHost>

Если ваша система имеет только один IP-адрес, доступ к основному серверу напрямую будет невозможен: нужно включить его имя (в примере www.dhsilabs.com) в число виртуальных. Эти имена должны быть прописаны в службе DNS. При наличии двух IP-адресов можно один присвоить основному серверу, а другой — виртуальному.

Сервер Apache позволяет использовать несколько доменных имен для доступа к одному серверу, например:

ServerAlias www.dhsilabs.com www2.dhsilabs.com

При этом запросы, посланные по IP-адресам, которые присвоены вашим виртуальным узлам, должны соответствовать одному из указанных доменных имен. Чтобы зафиксировать запросы, не соответствующие ни одному из этих имен, нужно с помощью опции default:* создать виртуальный узел, который будет обслуживать такие запросы:

<VirtualHost _default_:*>

16.9.2. Виртуальные серверы с идентификацией по IP-адресу

В директиве VirtualHost в качестве адресов можно использовать доменные имена, но лучше указывать IP-адрес, причем действительный, а не виртуальный. В этом случае вы не будете зависеть от DNS при разрешении имени. Также потребуется один IP-адрес для вашего основного сервера. Если же распределить все адреса между виртуальными серверами, то нельзя будет получить доступ к основному серверу.

Листинг 16.11. Идентификация по IP-адресу