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-адресу
