[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Web мастеру, CGI, Perl, PHP, Apache" (Архив | Для печати)

Сервер Apache - Настройка.

Сервер Apache имеет три файла конфигурации, они находятся в каталоге /usr/local/etc/httpd/conf. Эти файлы позволяют настроить все стороны функционирования сервера. После того как вы отредактируете эти файлы в соответствии с вашими требованиями, можете запускать сервер. Никакой другой настройки не требуется.

Прежде всего нужно перейти в каталог, содержащий файлы конфигурации, /usr/local/etc/httpd/conf. Здесь вы найдете три файла конфигурации.

Поскольку эти файлы должны служить для вас примером, не стоит сразу их редактировать; сначала сделайте копии, а уже затем приступайте к настройке сервера:

$for I in *-dist

>do

>mycopy = ▒basename $i √ dist▓

>cp $i $mycopy

>done

Теперь у вас должны быть три файла, имеющие расширение .conf. В табл. 3-1 приведены имена этих файлов и объяснено назначение каждого из них. У вас также по-прежнему должны оставаться исходные файлы ≈ dist; не удаляйте их на тот случай, если вы допустите ошибку в процессе настройки и вам придется вернуться к ним за справкой.

Таблица 3-1. Файлы конфигурации Apache HTTPd
 

Имя файла	Назначение
Httpd.conf	Файл конфигурации сервера, содержит основное техническое описание работы демона.
Srm.conf	Карта ресурсов сервера, указывает демону HTTPd порядок предоставления файлов.
Access, conf	Файл конфигурации доступа содержит информацию о том, кто имеет право осуществлять доступ к вашему серверу.

Рассмотрим основные изменения в файлах конфигурации, которые необходимо сделать, прежде чем запускать сервер. Мы также рассмотрим наиболее полезные из предлагаемых сервером Apache опций, сделав акцент на тех, которые перечислены в файлах конфигурации. Сервер Apache имеет огромное число редко используемых опций, рассмотрением которых мы заниматься не будем. Полную информацию о возможностях настройки сервера можно получить, прочитав официальную документацию на сервере Apache: http://www.apache.org/docs/. Теперь перейдите в каталог /usr/local/etc/httpd/conf (или в тот каталог, в котором вы установили сервер Apache) и следуйте инструкциям.

httpd.conf: файл конфигурации сервера

Файл httpd.conf содержит конфигурацию сервера. Откройте его в редакторе и измените указанные ниже строки, если это необходимо. Приведенные ниже описания послужат вам в качестве указаний. Они не являются исчерпывающими инструкциями, однако затрагивают те изменения, которые вам, возможно, придется внести, чтобы заставить сервер работать. Единственной строкой, которую вы обязаны, изменить, является строка, начинающаяся с ⌠ServerAdmin■. Остальным директивам по умолчанию присвоены разумные значения, поэтому взгляните на них, чтобы убедиться в правильности значений, но вносить в них изменения вряд ли потребуется.

ServerType

Для этой директивы значением по умолчанию является ServerType standalone. Серверы, работающие в автономном режиме (standalone), запускаются из загрузочных сценариев при запуске системы. Такая установка рекомендуется для улучшения производительности.

Серверу Apache (как и большинству традиционных серверов UNIX) для каждого соединения требуется запускать отдельную копию. Система UNIX оптимизирована специально для такого поведения, и накладные расходы на создание процессом собственной копии невелики. После запуска сервер, работающий в автономном режиме, начинает прослушивание на предмет наличия запросов на соединение. Обнаружив такой запрос, сервер ⌠раздваивается■ для его обслуживания. Когда копия заканчивает работу, она завершается. Эту основную модель можно изменить при помощи директив StartServers и MaxServers, как объясняется ниже.

В качестве альтернативы режиму standalone можно воспользоваться услугами демона inetd. В системах UNIX inetd представляет собой суперсервер. Большинство сетевых служб используется относительно редко по сравнению с десятками соединений в секунду, обслуживаемых занятыми HTTP-серверами. Даже такая популярная служба, как Telnet, обычно осуществляет не более одного соединения каждые несколько минут. Если для каждой из возможных сетевых служб запускать отдельный автономный сервер, это будет равносильно неоправданной растрате таких ценных системных ресурсов, как процессорное время и оперативная память. Решением этой проблемы для UNIX является использование демона inetd. Файл /etc/inetd.conf содержит список сетевых служб, за которые отвечает inetd. Этот демон использует для определения номера сетевого порта, связанного с каждой из конкретных служб, файл /etc/services и производит прослушивание этих портов на предмет появления запросов на соединения. При появлении запроса демон запускает для его обработки соответствующий сервер.

Хотя такой механизм идеален для сравнительно редко используемых служб, протокол HTTP не следует этой модели. Поскольку для каждой HTML-страницы, для каждого встроенного изображения и любого другого объекта, запрашиваемого пользователем, требуется отдельное соединение и, следовательно, отдельная копия сервера, то каждую минуту, если не каждую секунду, будет осуществляться несколько новых соединений.

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

Port

В этой директиве задается номер сетевого порта, на котором будет работать ваш сервер, если он запущен в автономном режиме (если используется inetd, то номер порта следует задать в файле /etc/services).

Значением по умолчанию для этой директивы является Port 80. К этому порту Web-броузеры пытаются подключиться по умолчанию, и он является стандартным портом для протокола HTTP и рекомендуется для использования на основном сервере вашего Web-узла. Если вы хотите запустить сервер на этом порту или на любом другом, номер которого меньше 1024, то вам потребуются привилегии суперпользователя (root).

Если вы не обладаете в этой системе привилегиями суперпользователя, то все-таки остается возможность запустить Web-сервер на порту с номером, превосходящим 1024. Вам только придется объявить об этом и включить номер порта в адрес URL; обычно используют номера 8000 или 8080. В дальнейшем предполагается, что вы обладаете правами суперпользователя в своей системе, и сервер запущен на порту, принятом по умолчанию.

HostnameLookups

В целях наблюдения за деятельностью пользователей сервер Apache ведет серию журнальных файлов, которые мы обсудим позднее. В одном из них ведется учет компьютеров, осуществивших доступ к серверу. Директива HostnameLookups указывает, записывается ли в журнальный файл имя компьютера (например, macl.shoop.com) или только его IP-адрес (например, 152.2.22.81). По умолчанию сервер сохраняет имя компьютера, но если ожидаемый объем графика очень велик, отключение опции HostnameLookups позволит немного уменьшить нагрузку на сервер. Это делается простым изменением строки на ⌠HostnameLookups off■.

User и Group

Эти параметры задают действительные идентификаторы пользователя и группы, которые присваиваются серверу, работающему в автономном режиме. (Если используется inetd, большинство систем UNIX требует указать идентификатор пользователя в файле /etc/inetd-conf). Можно задавать как имена, так и их числовые эквиваленты, которые можно найти в файлах /etc/passwd и /etc/group соответственно.

По умолчанию в качестве имени пользователя принимается nobody, что является превосходным выбором с точки зрения защиты информации. Такое имя гарантирует, что Web-сервер получит доступ только к тем файлам, к которым разрешен доступ на чтение для всех пользователей. Альтернативой является создание в системе специального пользователя и использование для работы Web-сервера его идентификатора. Какой бы идентификатор ни использовался, следует убедиться, что для него не существует доступа к системе через интерфейс командной строки. Ни в коем случае нельзя запускать сервер с привилегиями суперпользователя (root).

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

Обратите внимание, что для начинающего вебмастера именно эти директивы обычно представляют трудности. Если указанные пользователь и группа не существуют в системе, сервер не будет работать. Для директивы Group, например, по умолчанию принято значение ≈1, что во многих системах не является разрешенным идентификатором группы.

ServerAdmin

Это официальный электронный адрес вебмастера вашего Web-узла. Обычно используется адрес в форме WebMaster@ваш_cepвep, где ваш_сервер является хорошо известным именем вашего сервера. При этом адрес останется неизменным, даже если сменится вебмастер.

Этот адрес необходимо добавить в поддерживаемую почтовым сервером базу данных псевдонимов, находящуюся в файле /etc/aliases. Воспользовавшись привилегиями суперпользователя, добавьте в этот файл следующую строку:

webmaster: name

Вместо слова имя введите регистрационное имя пользователя, который будет заниматься обслуживанием вашего Web-сервера. Затем выполните следующую команду:

# newaliases

В результате база данных псевдонимов будет перестроена.

ServerRoot

В этой директиве задается базовый каталог, в котором будет установлено программное обеспечение HTTP-сервера Apache. По умолчанию это каталог /usr/local/etc/httpd. Если вы до сих пор следовали нашим инструкциям, вам не придется менять эту строку.

BindAddress

Эта директива используется только для компьютеров, имеющих более одного IP-адреса. С ее помощью можно устанавливать, прослушивание какого из IP-адресов компьютера сервер будет производить на предмет поступления запросов. Большинство компьютеров имеют один IP-адрес.

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

ErrorLog и TransferLog

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

Эти журнальные файлы весьма просты. В файле, указанном в директиве ErrorLog, сервер сохраняет сообщения диагностики, включая сообщения об ошибках, выдаваемые сценариями CGI. В файле, указанном в директиве TransferLog, сервер сохраняет все запросы клиентов. Если включена описанная выше опция HostnameLookups, то вместе с запросами регистрируются имена компьютеров. Если опция выключена, то регистрируются только IP-адреса компьютеров клиентов.

Вряд ли у вас возникнет необходимость (или желание) изменять значения в этих директивах.

PidFile и ScoreBoardFile

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

Директива ScoreBoardFile позволяет серверу Apache следить за собственной производительностью. Об использовании директивы ScoreBoardFile мы подробнее поговорим при рассмотрении модуля Status. Вряд ли у вас возникнет необходимость (или желание) изменять значения и в этих директивах.

ServerName

В этой строке должно стоять официальное имя вашего сервера в том виде, в котором оно появляется в строке URL (то есть http://www.ИMЯ_вaшeго_сервера/). Это должно быть имя компьютера, зарегистрированное в системе имен серверов вашей организации или провайдера.

CacheNegotiatedDocs

Эта директива предназначена для пользователей, работающих через прокси-сервер ≈ сервер, собирающий для них информацию, хранящий ее у себя и передающий им сохраненную копию вместо того, чтобы запрашивать в Интернете новую копию. Эта директива позволяет прокси-серверу кэшировать договорные документы, то есть документы, не получаемые динамически, такие как вывод сценариев CGI или сгенерированная сервером индексная страница. Обычно прокси-серверы не кэшируют такие документы, поскольку велика вероятность их изменения. По умолчанию эта директива отключена (закомментирована при помощи символа ⌠#■), и, вероятнее всего, вам не понадобится ее трогать.

Timeout

Это промежуток времени в секундах, в течение которого сервер ждет продолжения недополученного запроса или продолжает попытки возобновления приостановленной передачи ответа. Если у вас медленное соединение с Интернетом или вам приходится передавать большие файлы, увеличьте это значение. В противном случае, 20 минут является вполне достаточным временем ожидания реакции медленного клиента или медленного соединения.

KeepAlive и KeepAliveTimeout

Характеристики KeepAlive являются свойствами протокола HTTP I.I (который до сих пор имеет статус предложения), позволяющими ускорить обработку запросов. HTTP 1.0 при каждом запросе на передачу объекта создается новое соединение между клиентом и сервером. В сервере Apache реализована свойственная протоколу HTTP 1.1 возможность KeepAlive, что означает возможность запрашивать несколько объектов в рамках одного соединения. Например, раньше передача Web-страницы с четырьмя встроенными изображениями потребовала бы пять отдельных соединений, а с использованием KeepAlive все последовательные запросы производятся в рамках одного соединения. Очевидно, что это сокращает время обработки запросов сервером. Конечно, клиент должен уметь производить такие специальные запросы.

Значением по умолчанию для KeepAlive является 5 ≈ максимальное число запросов в рамках одного соединения. Когда значение этого параметра равно 5, наблюдается очевидное увеличение производительности. Чтобы отключить эту возможность, установите параметр KeepAlive равным нулю. Параметр KeepAliveTimeout отражает промежуток времени между последовательными запросами. Другими словами, если клиент в рамках одного соединения производит три запроса, а затем в течение нескольких секунд запросов от него не поступает, сервер считает, что третий запрос был последним. По умолчанию принимается значение 15 секунд.

StartServers

Обратите внимание, что директива StartServers в файле httpd.conf стоит после директив MinSpareServers и MaxSpareServers, однако понять значение директив Min- и MaxSpareServers значительно легче, если сначала разобраться с директивой StartServers.

Когда выбирается автономный (standalone) режим работы сервера (ServerType) и для параметра StartServers задается значение, большее 1 (по умолчанию принимается значение 5), происходит коренное изменение работы сервера. Вместо запуска одного экземпляра сервер при старте создает несколько собственных копий, при этом образуется пул серверов.

Исходная копия сервера выступает в качестве планировщика для всех серверов в пуле, принимая соединения и передавая их свободным копиям. Теоретически, такая стратегия ускоряет процесс обслуживания запросов, снижая накладные расходы. На практике, однако, некоторые вебмастеры утверждают, что этим эффектом можно пренебречь, если только сервер не является очень загруженным (более 100 000 запросов в день).

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

MaxSpareServers и MinSpareServers

Если число поступающих к вам запросов превышает число серверов в пуле, заданное параметром StartServers, буфер серверов увеличивается для обслуживания запросов. Эти дополнительные процессы-серверы не завершаются после обработки запроса, ради которого они были запущены; они остаются в памяти. Директива MaxSpareServers позволяет настраивать число свободных серверов, находящихся в пуле. Если их больше, чем указано в директиве MaxSpareServers, то лишние процессы завершаются. Аналогично, если свободных серверов в пуле меньше, чем допускает директива MinSpareServers, то в преддверии наплыва запросов создаются дополнительные копии сервера. Опять-таки, изменение этих настроек мало отражается на работе большинства Web-серверов.

MaxClients

Поскольку Web-серверы обрабатывают большое количество запросов от многочисленных клиентов, это может привести к запуску такого количе-

ства серверов, что компьютер перестанет справляться с нагрузкой. Директива MaxClients устанавливает максимальное число копий сервера, которые могут выполняться одновременно. Когда достигается этот предел (по умолчанию ≈ 150), новые запросы получают отказ. Если вам не хочется отказывать пользователям, не устанавливайте слишком маленькое значение. Медленный ответ все-таки лучше, чем отсутствие какого-либо ответа вообще.

MaxRequestsPerChild

В этой директиве задается время жизни любого отдельного сервера в пуле серверов. Обработав установленное здесь количество запросов (по умолчанию ≈ 30), копия сервера завершается, а вместо нее запускается новая. В большинстве систем изменение этого параметра не дает заметного эффекта.

ProxyRequests и директивы Cache

Как уже было отмечено, прокси-серверы действуют в качестве посредников между клиентами и настоящими серверами, располагающими запрашиваемой клиентом информацией. В разделе ⌠Развернутая конфигурация■ мы шаг за шагом рассмотрим процесс настройки прокси-сервера. Пока оставьте директиву ProxyRequests и разнообразные директивы Cache закомментированными.

Listen

Использование виртуальных серверов позволяет придать адресу URL такой вид, будто он указывает на отдельный узел, даже если в действительности за ним стоит только часть большого сервера. Например, на сервере www.webstores.com может иметься раздел для информации корпорации ShoopSoft. Традиционно адрес URL выглядел бы, как http:// www.webstores.com/shoopsoft/. С использованием механизма виртуальных серверов раздел, принадлежащий корпорации, мог бы получить адрес URL вида: http://www.shoop.com/, как будто у корпорации есть в Интернете свой собственный Web-сервер.

Установка виртуальных серверов подробно обсуждается в разделе ⌠Развернутая конфигурация■. Пока что не изменяйте строки, относящиеся к директивам VirtualHosts.

Закончим настройку

Проверьте еще раз файл access, conf и убедитесь, что определены все необходимые директивы. Затем сохраните файл и переходите к следующему файлу конфигурации: srm.conf.

srm.conf: карта ресурсов сервера

Карта ресурсов сервера, представляющая собой файл /usr/local/etc/httpd/ conf/srm.conf, указывает, откуда и каким образом сервер Apache должен брать файлы для передачи пользователям. Она позволяет преобразовать абстрактный мир адресов URL, поступающих серверу от клиентов, в реальные файлы и каталоги на компьютере, на котором работает сервер.

Откройте этот файл в редакторе и замените значения по умолчанию значениями, подходящими для вашего Web-сервера. Как и в файле httpd.conf, каждая директива и указанное в ней значение должны находиться в отдельной строке. Пустые строки и строки, начинающиеся с символа номера (#), игнорируются сервером.

Как и для файла httpd.cnf, большинство значений являются приемлемыми, поэтому сейчас вам вряд ли понадобится вносить значительные изменения. Для начала можно вообще оставить файл в исходном виде. Однако из всех файлов конфигурации наиболее важно понимать назначение именно файла srm.conf, поскольку информационное содержимое Web-узла почти полностью организуется и управляется с его помощью.

DocumentRoot

В этой директиве задается каталог, из которого берутся передаваемые клиентам документы. По умолчанию принимается каталог /usr/local/etc/ httpd/htdocs. Можно предоставлять клиентам и файлы, находящиеся в других каталогах, ≈ для этого используются символьные ссылки.

UserDir

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

UserDir DISABLED

Более подробно вопросы пользовательских каталогов и их отображение сервером будут рассмотрены ниже в разделе ⌠Планировка Web-пространства■.

Directorylndex

Эта директива позволяет задать название документа, возвращаемого по запросу, который не содержит в строке URL названия документа. Например, в адресе URL http://www.shoop.com/ отсутствует название документа, поэтому будет возвращен документ, указанный в директиве Directorylndex. Поскольку по умолчанию принимается название index.html, сервер передаст клиенту документ index.html из каталога DocumentRoot на сервере.

В директиве Directorylndex можно задать несколько имен файлов. Если первый документ, указанный в строке, не найден в каталоге, то сервер ищет следующий и, в случае успеха, передает его клиенту. Это особенно полезно при мультиплатформной разработке, поскольку компьютеры, оснащенные системами, основанными на DOS, не поддерживают расширения имен файлов более, чем из трех символов. Например, чтобы разрешить в качестве индексных страниц предавать файлы index.html или index.htm, поместите в строку Directorylndex следующие значения:

Directorylndex index.html index.htm

В этом примере, если в одном и том же каталоге присутствуют файлы index.html и index.htm, в качестве индексной страницы будет передан файл index.html, поскольку он стоит в списке первым.

Вам следует создать файл index.html (или файл с другим именем, в зависимости от того, как вы назовете свои индексные страницы) в каталоге DocumentRoot как для Web-узла, так и для основных разделов с документами (и, например, для домашних страниц пользователей). Эта настройка обеспечивает простой интерфейс пользователям, которым не нужно помнить название конкретного документа.

Она также предоставляет вам важный уровень защиты информации. По умолчанию, если клиент указывает адрес URL каталога, то сервер Apache передает в ответ список файлов, имеющихся в этом каталоге. Создав в каталоге индексный файл, вы лишите пользователей возможности получить список всех файлов в этом каталоге. Вам не обязательно создавать вводную страницу index.html для каждого Web-проекта; достаточно создать символьную ссылку на файл домашней страницы. Например, если ваш документ верхнего уровня называется MyHome.html, то при помощи следующей команды создается символьная ссылка под названием index.html, указывающая на MyHome.html:

$ ln -s MyHome.html index.html

Альтернативой, позволяющей любому другому пользователю использовать в качестве своей индексной страницы файл MyHome.html, является следующее написание директивы Directory Index:

Directoryindex index, html MyHome.html

FancyIndexing

Как уже было отмечено, при получении запроса на передачу каталога сервер Apache:

∙ находит файл, указанный в директиве Directorylndex (если таковой существует), и передает его клиенту;

∙ если файл Directorylndex не существует, передает клиенту оглавление каталога.

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

AddlconByType

При выборе опции Fancylndexing данная директива дает серверу знать, какие значки с какими файлами следует использовать в соответствии с MIME-типами файлов. Сервер использует следующий формат:

AddlconByType (.ALT, URL) MIME

∙ ALT ≈ это маленький фрагмент текста, который пользователи, работающие с текстовыми броузерами, увидят вместо значка.

∙ URL ≈ это адрес URL, по которому на вашем сервере размещен файл значка.

∙ MIME ≈ это MIME-тип либо набор MIME-типов, задаваемый с помощью шаблонов.

Адрес URL /icons задается в директиве Alias в этом же файле.

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

Addlcon, Defaultlcon

Значение в директиве Addlcon указывает серверу, какие значки следует использовать для представления файлов и каталогов, тогда как Defaultlcon представляет собой адрес URL значка, предназначенного для использования с файлами, не имеющими явно заданного значка.

AddDescription, ReadmeName, HeaderName и Indexignore

Следующий набор директив позволяет управлять содержимым оглавления каталога. Как Fancylndexing и все директивы Icon, эти опции используются, только если не найден файл, указанный в Directorylndex. Директива AddDescription позволяет сопроводить в оглавлении файлы, имеющие определенное имя, кратким описанием. В директивах ReadmeName и HeaderName задаются имена текстового файла и HTML-документа соответственно, которые появятся в оглавлении. Текстовый файл, указанный в ReadmeName, должен присутствовать в отображаемом каталоге, а в случае использования директивы HeaderName сервер добавит расширение .html к значению параметра HeaderName и будет искать документ с таким названием. Например, если оставить в директиве HeaderName принятое по умолчанию значение HEADER, то сервер Apache будет искать в каталоге документ HEADER.html. Значение, указанное в директиве ReadmeName, используется в своем исходном виде.

В директиве Indexignore указывается список файлов и подкаталогов, не включаемых в оглавление каталога. Обычно здесь при помощи шаблонов UNIX указываются имена системных файлов и файлов резервных копий. Например, одно из значений по умолчанию, ⌠*-■, используется для запрета отображения резервных копий, создаваемых редактором GNU emacs при каждом сеансе редактирования файлов.

AccessFileName

Если суперпользователь воспользуется директивой AccessFileName (см. раздел ⌠Доступ и идентификация■), то сервер Apache предоставит большие возможности управления поведением сервера в отношении предоставления пользователям документов из различных каталогов. Владельцы этих каталогов получают возможность вместо многих значений параметров в карте ресурсов сервера (srm.conf) установить свои собственные путем добавления директив в файл .htaccess в таком каталоге. Директива AccessFileName позволяет изменить имя этого файла. Далее в этой главе мы будем предполагать, что вы оставили в директиве AccessFileName значение по умолчанию.

DefaultType

Если клиент запрашивает файл с расширением, для которого на сервере не имеется соответствующего МIME-типа, то используется MIME-тип, указанный в директиве DefaultType. Карту соответствия расширений MIME-типам можно расширить, воспользовавшись рассматриваемой ниже директивой AddType.

AddEncoding

Обычно для файлов, предназначенных для передачи клиентам, используется несколько видов сжатия, или кодирования, что сокращает время передачи. Некоторые броузеры имеют встроенные утилиты распаковки, запускаемые для определенных MIME-типов. Эти MIME-типы указываются в директиве AddEncoding. По умолчанию указываются наиболее распространенные расширения .Z и .gz (файлы, сжатые программами compress и gzip соответственно), и, вероятнее всего, вам не понадобится добавлять какие-либо другие.

AddLanguage

Если вы планируете предоставлять пользователям документы на разных языках, то для преобразования аббревиатуры языка в расширение файла можно воспользоваться директивой AddLanguage. Аббревиатурой названия языка обычно служит принятый в Интернете код страны, например ≈ ⌠fr■ для французского языка или ⌠р1■ для польского. Английский, являясь исключением, имеет аббревиатуру ⌠en■. Если пользователь запрашивает файл home.html, и его броузер указывает, что владелец предпочитает использовать французский язык, то сервер обработает эти директивы, чтобы узнать, какое дополнительное расширение имени файла используется для франкоязычных документов. По умолчанию принято расширение .fr, поэтому пользователю будет передан документ home.html.fr. Конечно, если существует документ home.html, то пользователь получит именно его ≈ функции языковой поддержки включаются, только если не найден исходный документ.

LanguagePriority

Если на Web-сервере имеются документы на различных языках (home. html.fr, home.html.de, home.html.se), а клиент заказывает документ home.html, не выражая пожеланий относительно языка документа, то сервер должен решить, какой документ передать клиенту. В директиве LanguagePriority в убывающей последовательности перечисляются приоритеты различных языков. По умолчанию первым идет английский, затем французский, затем немецкий. В приведенном выше примере клиенту будет передан документ home.html.fr.

Redirect

Директива Redirect оказывается полезной, когда возникает неизбежная необходимость в переносе документов в другой каталог на сервере или даже на другой сервер. Например, если компания ShoopSoft решает вынести свое отделение, занимающееся операционной системой Linux, в отдельный филиал, то может быть принято решение поместить всю информацию этого отделения на новый сервер, находящийся в этом филиале. Если старый адрес URL был http://www.shoop.com/Linux, а адрес URL нового подразделения http://www.shooplinux.com/, то можно воспользоваться следующей директивой Redirect:

Redirect /Linux http://www.shooplinux.com/

В результате, все запросы на документы, касающиеся Linux и имеющие старый адрес URL, будут перенаправлены на сервер нового подразделения.

Alias

Директива Alias дает возможность предоставлять доступ к документам, находящимся не только в каталоге, указанном в директиве DocumentRoot, и его подкаталогах, но и в других каталогах. По умолчанию в директиве Alias задан только один псевдоним ≈ /icons, используемый директивами Addlcon и AddIconByType. Убедитесь, что эта строка Alias не закомментирована, то есть не начинается с символа #. Закомментированная директива будет игнорироваться сервером. Некоторые бета-версии сервера Apache поставлялись с закомментированными директивами Alias и ScriptAlias.

ScriptAlias

В директиве ScriptAlias указывается, в каких каталогах разрешен запуск сценариев CGI. По умолчанию используется следующая директива Script-Alias:

ScriptAlias /cgi-bin/ /usr/local/etc/httpd/cgi-bin/

Как и в случае директивы Alias, следует убедиться, что первым символом строки не является #. Принятое по умолчанию значение разрешает выполнение входящих в поставку сценариев CGI, например сценария fortune (возвращающего забавную цитату). В первом аргументе указывается виртуальный путь, который клиенты могут использовать для запуска сценариев CGI. Во втором аргументе указывается каталог, к которому осуществляется доступ в действительности.

Например, указан относительный адрес URL /cgi-bin/, а в действительности сценарии находятся в каталоге /usr/local/etc/httpd/cgi-bin, в этом случае для указания на сценарий CGI /usr/local/etc/httpd/cgi-bin/ fortune следует воспользоваться следующим адресом URL: http:// www.shoop.com/cgi-bin/fortune.

Разрешается добавлять неограниченное число директив ScriptAlias. Добавьте по одной для каждого пользователя (из числа тех, которым вы доверяете), имеющего желание писать и выполнять собственные сценарии CGI. Например, создать для пользователя jem каталог для выполнения сценариев CGI /jembin в каталоге /home/users/jem/html/cgi можно при помощи следующей строки:

ScriptAlias /jembin /home/users/jem/html/cgi

Если вы разрешаете всем пользователям создавать и запускать на вашем сервере сценарии CGI без какого-либо контроля или вмешательства с вашей стороны, можете включить MIME-тип CGI. Для этого прочитайте описание директивы AddType.

AddType

Эта директива полезна для добавления новых типов предоставляемых клиентам документов на основе использования MIME-типов. Хорошим примером нового'типа документа, который может понадобиться добавить, служит формат Adobe Acrobat, файлы которого используют расширение .pdf. Вам может потребоваться указать серверу, что документ является файлом Acrobat (судя по расширению), и отправить уведомление клиенту, чтобы он запустил программу просмотра файлов Acrobat. Директива AddType дает такую возможность. Например, чтобы сервер передал клиенту расширение .pdf, можно воспользоваться следующей командой:

AddType application/pdf pdf

Сервер Apache также распознает два специальных MIME-типа, облегчающих сопровождение сервера, которые можно указать в директиве AddType. В поставляемом с сервером файле srm.conf эти два типа закомментированы:

#AddType text/x-server-parsed-html.shtml

#AddType application/x-httpd-cgi.cgi

Первая директива AddType разрешает использование эффективных серверных включений; если удалить из нее символ комментария, то можно будет при помощи расширения .shtml указывать серверу, что в документе имеются серверные включения.

Серверные включения позволяют заставить сервер вставить в вашу Web-страницу другой документ или вывод какой-либо команды. Хотя данную возможность можно включить для всего Web-пространства, это заставит сервер просматривать на наличие включений каждый HTML-документ перед отправкой его клиенту. При этом затрачивается много системных ресурсов. Дополнительную информацию о серверных включениях можно найти по http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html.

Второй закомментированный тип, application/x-httpd-cgi, задает другое расширение, .cgi. Если удалить символ комментария из этой строки, то такое расширение будет указывать серверу, что файл является выполняемым сценарием CGI. Это позволит запускать сценарии где угодно на сервере, а не только в каталогах, указанных в директиве ScriptAlias.

Разрешить использование обоих этих типов можно, удалив из строк символ #.

AddHandler и Action

Кроме простого добавления и изменения MIME-типов при помощи директивы AddType, сервер Apache теперь также наделен возможностью модифицировать или производить синтаксический разбор файлов определенных типов перед отправкой их пользователю. Директива AddHandler ставит в соответствие расширению файла определенное действие. Некоторые из этих действий встроены в сервер, например, строка ⌠AddHandler server-parsed shtml■ ставит в соответствие всем файлам с расширением .shtml встроенную функцию сервера под названием ⌠server-parsed■, которая производит синтаксический разбор файлов с целью найти серверные включения. Функция, указанная в директиве AddHandler, не обязательно должна являться встроенной функцией сервера. Директива Action может ставить в соответствие функции из AddHandler сценарий CGI. Например, следующие строки в файле srm.conf сначала указывают серверу, что при каждой передаче файла с расширением .foot следует выполнять функцию foot-action. Затем функции foot-action ставится в соответствие сценарий /cgi-bin/footer, выполняющийся при каждом вызове функции foot-action.

AddHandler foot-action foot Action foot-action /cgi-bin/footer

Директива Action также позволяет ставить в соответствие MIME-типу непосредственно определенное действие. Например, у вас имеется сценарий, проверяющий, не является ли посетитель вашего Web-узла сотрудником конкурирующей фирмы. Запускать этот сценарий при каждом запросе на HTML-документ можно при помощи следующей директивы:

Action text/html /cgi-bin/mockery.pl

MetaDir и MetaSuffix

Директивы MetaDir и MetaSuffix выполняют те же функции, что и тег <МЕТА>, но метаинформация хранится отдельно от файла. Директива MetaDir указывает серверу, в каком подкаталоге текущего каталога хранятся файлы с метаинформацией. Директива MetaSuffix указывает серверу, какое расширение имеют эти файлы. Обычно файлы метаинформации имеют расширение .meta; так, метаинформация для файла index.html будет храниться в файле index.html.meta, расположенном в подкаталоге, указанном в директиве MetaDir.

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

полночь, 5 июля 1998 года, нужно поместить в файл метаинформации следующую строку:

Expires: Sunday, 5-Jul-98 12:00:00 GMT

ErrorDocument

Эта директива позволяет поставить в соответствие кодам ошибок HTTP-сервера адреса URL на том же сервере. Этой возможностью можно пользоваться для замены и усовершенствования сообщений об ошибках, выдаваемых сервером. Мы детально рассмотрим ее в разделе ⌠Развернутая конфигурация■, так что пока вы можете оставить ее закомментированной.

Эта директива является последней в карте ресурсов сервера. Задав значения, необходимые для начала работы, сохраните файл srm.conf и выйдите из редактора.

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

Сервер 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-документов размещается централизовано, упрощая их сопровождение и создание резервных копий.

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

Запуск сервера

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

Автономный режим

Чтобы запустить сервер в автономном режиме, достаточно просто добавить одну строку в сценарии, выполняемые при загрузке системы. В системе Linux этот файл сценариев называется /etc/rc.d/rc.local; в других системах он может носить имя /etc/rc.local, либо может потребоваться создание отдельного сценария в каталоге /etc/rc2.d. Если вы не знаете точно, обратитесь к руководству администратора, прилагаемому к вашей системе.

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

if [ -x /usr/local/etc/httpd/httpd ]

then

echo "Starting HTTP Server"

cd /usr/local/etc/httpd httpd > /dev/console 2>&1

else

echo "Can't start HTTP server!"

fi

Сохраните файл и выйдите из редактора. Добавленные вами строки проверяют, существует ли сервер HTTPd; если да, то производится его запуск. Хотя новые строки уже добавлены в сценарии, выполняемые при запуске системы, они не будут выполнены до тех пор, пока не будет произведена перезагрузка компьютера. Чтобы запустить сервер немедленно, необходимо, обладая полномочиями суперпользователя, ввести следующие команды:

ft cd /usr/local/etc/httpd ■./httpd

Если на экране или в файле /usr/local/etc/httpd/logs/error_log не появилось сообщений об ошибках, то запуск сервера можно считать произведенным успешно.

Запуск из inetd

Чтобы сервер запускался из демона inetd, нужно внести изменения в два файла. Первый из них, /etc/services, используется для определения хорошо известных портов и использующих их протоколов. Если для совместного использования в сети системных баз данных используется механизм NIS (также известный под названием YP), то необходимо произвести обновление этих системных баз при помощи команды yppush, чтобы изменения, сделанные в файле, возымели действие. Воспользовавшись привилегиями суперпользователя, откройте файл /etc/services и добавьте в его конец строку

http 80/tcp

Вторым файлом, в который необходимо внести изменения, является файл /etc/inetd.conf. Это файл конфигурации inetd. В нем указываются номера портов, которые должен прослушивать демон inetd, и действия, предпринимаемые при обнаружении соединения. Не отказываясь от полномочий суперпользователя, откройте файл /etc/inetd.conf и добавьте в его конец следующую строку (подчеркиваем, что все это ≈ одна строка):

http stream top nowait root /usr/local/etc/httpd/httpd httpd

Такая строка должна работать для большинства систем UNIX. Заслуживающим отдельного упоминания исключением является система Ultrix, в которой используется следующий формат:

http stream tcp nowait /usr/local/etc/httpd/httpd

Четвертое поле, которое в Ultrix не используется, указывает демону inetd, с полномочиями какого пользователя следует запускать сервер. Система Ultrix не позволяет задавать имя пользователя; серверы, запускаемые из inetd, всегда работают с полномочиями пользователя root. Поскольку это представляет потенциальную угрозу нарушения защиты информации, вам следует при помощи директивы User в файле conf/httpd.conf заменить имя пользователя на более подходящее, например nobody.

После того как в файлы /etc/services и /etc/inetd.conf добавлены необходимые строки, необходимо известить демон inetd об изменениях в его файлах конфигурации. Для этого узнайте номер процесса inetd (его PID) и пошлите демону сигнал HUP (hang-up). Это делается при помощи следующих команд (в системах линии System V, например, Solaris и Irix, в команде ps следует вместо указанных флагов использовать флаги -aef):

# ps -aux | grep inetd

root 11253 0.0 3.4 156 256 p5 S 23:01 0:00 grep inetd root 43 0.0 1.0 72 80 con S Feb 1 0:00 /usr/sbin/lned Kkill -HUP 43

По получении сигнала HUP демон inetd заново считывает файл /etc/inetd.conf и начинает прослушивание на предмет наличия HTTP-соединений.

Тестирование сервера

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

$ telnet localhost 80

Trying 127.0.0.1

Connected to localhost.

Escape character is "']'

Тем самым открывается соединение с HTTP-портом сервера. Когда соединение успешно установлено, можно убедиться, что все работает. Для этого введите следующую строку, завершив ее двукратным нажатием клавиши Return:

HEAD / НТТР/1.0

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

НТТР/1.0 200 OK

Date: Friday, 12-Dec-94 05:44:30 GMT

Server: Apache/1.1

MIME-version: 1.0

Content-type; text/html

Last-modified: Sunday, 12-Dec-94 01:21:23 GMT

Content-length: 2342

Connection closed by foreign host

Поздравляем, ваш Web-сервер работает! Теперь можно приступать к работе над содержимым, призванным прославить ваш Web-узел!

Доступ и идентификация

По умолчанию сервер Apache предоставляет довольно большую свободу управления доступом. В общем, любой файл или каталог попадает в карту ресурсов сервера и может передаваться клиенту по запросу, если:

∙ он находится в одном из подкаталогов каталога ServerRoot;

∙ в каталоге ServerRoot имеется символьная ссылка на него;

∙ он указан в директиве Alias;

∙ он находится в подкаталоге publc_html в домашнем каталоге пользователя.

Несмотря на то что по умолчанию приняты не слишком строгие меры по защите информации, сервер Apache предоставляет возможности точной настройки клиентского доступа и уровней доступа пользователей к информации.

Для этого есть два способа. Первый заключается в настройке глобального файла конфигурации доступа к серверу, /usr/local/etc/httpd/conf/access.conf. В этом файле можно задавать политику предоставления доступа для всего сервера в целом. Имеется возможность ограничивать доступ к определенным каталогам на сервере на основе IP-адресов или имен компьютеров клиентов. Можно также защитить каталоги паролями, разрешая доступ к серверу только определенным пользователям или группам пользователей.

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

Хотя наличие файла access.conf необходимо для работы сервера Apache, мы едва коснулись его в разделе, посвященном конфигурации сервера. Чтобы воспользоваться возможностями идентификации пользователей и управления доступом, необходимо лучшее понимание формата директив, находящихся в этом файле. В отличие от директив в файлах httpd.conf и srm.conf, директивы в файле access.conf имеют синтаксис, подобный синтаксису языка HTML, в котором отдельные элементы отмечают начало и конец секций. Эти директивы, отмечающие различные области управления доступом, называются директивами секционирования. При рассмотрении мы всегда будем заключать их в угловые скобки (< и >).

Директива <Directory> указывает каталог, к которому применяется ограничение доступа. Имя каталога должно быть абсолютным; разрешено использование шаблонов. В основном, используется следующий синтаксис:

<Directory directory_name>

access control directives

</Directory>

В директиве <Location> задается определенный адрес URL, который может обозначать целый каталог, отдельный файл или совокупность файлов,описываемую при помощи шаблонов, например, *.html ≈ все файлы, имена которых оканчиваются символами .html. В адрес URL не включаются название протокола и имя сервера, так, строка <Location http:// www.shoop.org/index.html> не будет являться правильным использованием директивы <Location>. Вот пример правильного синтаксиса директивы <Location>;

<Location URL>

access control directives

</Location>

Эти директивы управления доступом (access control directives) управляют типом доступа, предоставляемого сервером к указанному каталогу и всем расположенным в нем файлам и каталогам.

Большинство этих директив используется и в принадлежащих пользователям файлах .htaccess. Указанные в них значения имеют преимущество перед глобальными установками, если такое поведение разрешено в директиве AllowOverride.

Allow/Override

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

∙ None. Сервер игнорирует файлы .htaccess в этом каталоге. Если вы не намерены использовать для каталога файлы .htaccess, вам следует явно установить эту опцию, поскольку это повысит производительность сервера.

∙ Аll. По умолчанию пользователи имеют право переопределять в файлах .htaccess все глобальные установки доступа, для которых в этих файлах имеются эквивалентные команды.

∙ Options. Разрешает использование директивы Options (см. ниже раздел ⌠Options■),

∙ Filelnfo. Разрешает использование в файлах .htaccess директив Add-Туре и AddEncoding (см. раздел ⌠srm/conf: карта ресурсов сервера■, содержащий полное описание).

∙ AuthConfig. Разрешает использование директив AuthName, AuthType, AuthUserFile и AuthGroupFile, необходимых для защиты каталогов паролями.

∙ Limit. Разрешает использование директивы секционирования <Limit>. См. раздел, посвященный директиве <Limit>, в котором приведено подробное описание.

Options

Директива Options позволяет управлять тем, какие функции сервера доступны для использования в каталоге, указанном в секции <Directory> или в файле .htaccess. В директиве Options можно использовать следующие аргументы:

∙ None. В указанном каталоге не разрешается использование каких-либо функций.

∙ All В указанном каталоге разрешается использование всех возможностей (принимается по умолчанию).

∙ FollowSymLinks. Сервер следует символьным ссылкам, имеющимся в указанном каталоге.

∙ SymLinksIfOwnerMatch. Сервер следует символьным ссылкам, только если каталог назначения принадлежит тому же пользователю, что и сама ссылка.

∙ ExecCGI. В указанном каталоге разрешается выполнение сценариев CGI.

∙ Includes. В указанном каталоге разрешено использование серверных включений. Использование серверных включений требует, чтобы сервер производил синтаксический разбор всех HTML-файлов перед отправкой их клиентам. Нечего и говорить, что это крайне нагружает сервер, поэтому мы бы порекомендовали отключить эту опцию. Если вам необходимы серверные включения, разрешите их на уровне отдельных файлов при помощи директивы AddType, как это описано в разделе ⌠srm/conf: карта ресурсов сервера■

∙ Indexes. Сервер разрешает пользователям заказывать индексную страницу указанного каталога. Выключение этой опции запрещает передачу только списка файлов в каталоге, но не файла index.html.

∙ IncludesNoExec. Эта директива разрешает использование в указанном каталоге серверных включений, но запрещает запуск из них внешних программ.

XBitHack

Эта опция позволяет задать, будет ли сервер перед отправкой HTML-документа искать в нем какие-либо специальные указания. Такие указания, называемые серверными включениями, позволяют включить в документ другой HTML-документ, выполнить сценарий CGI и включить в страницу его вывод, либо вернуть информацию о странице, например дату ее последнего изменения. Если опция XBitHack включена, вам останется только сделать файл исполняемым, и сервер начнет поиск серверных включений. Сделать файл исполняемым можно при помощи следующей команды UNIX:

$ chmod а+х имя_файла

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

Директивы, относящиеся к карте ресурсов

Есть несколько директив, происходящих от файла конфигурации карты ресурсов сервера (srm/conf), значения в которых можно задавать для отдельных каталогов. Значения в следующих директивах, как уже было объяснено в разделе ⌠srm/conf: карта ресурсов сервера■, переопределяют значения в глобальном файле конфигурации для этих каталогов:

∙ AddType

∙ DefaultType

∙ AddDescription

∙ Addlcon

∙ Indexignore

∙ Defaultlcon

Пароли пользователя и группы

Сервер Apache предоставляет возможность реализации доступа к отдельным каталогам по паролю. Это осуществляется при помощи установок в глобальном файле конфигурации, либо в пользовательских файлах .htaccess. Чтобы защитить каталог паролем, необходимо задать значения в трех различных директивах: AuthName, AuthType и AuthUserFile. Использование четвертой директивы, AuthGroupFile, не является обязательным.

Директива AuthName должна представлять собой короткую строку, в которой задается пароль, запрашиваемый у пользователя.

Формат второй парольной директивы, AuthType, еще проще. В директиве AuthType задается метод идентификации пользователя, используемый сервером. В директиве AuthType разрешается указывать только два значения, Basic и Digest.

Если установить значение Basic, то будет использоваться стандартный для UNIX механизм парольной защиты, а также директива AuthUserFile. Если задать в директиве AuthType значение Digest, то будет задействована более надежная система шифрования, алгоритм MD5. На большинстве Web-серверов не стоит использовать установку Digest, поскольку эта возможность пока не поддерживается большинством броузеров. Ее разумно использовать в пределах интранета или для мелкомасштабных применений, когда вы знаете тип броузера, используемого всеми вашими пользователями.

В директиве AuthUserFile, используемой только при выбранном методе Basic, задается полный путь в файловой системе сервера Apache к файлу паролей пользователей для данного каталога. Для создания файла паролей применяется программа htpasswd, которую можно найти в каталоге /usr/local/etc/httpd/support. Например, новый файл паролей для пользователя mdw создается при помощи следующей команды:

$htpasswd -с /html/secured/.htpasswd mdw

Adding password for mdw.

New password:

Re-type new password:

Опция -с указывает программе htpasswd, что следует создать новый файл паролей. Если эта опция опущена, программа пытается отредактировать существующий файл паролей.

Если выбран метод Digest, то список паролей нужно указывать в директиве AuthDigestFile. Как и для директивы AuthUserFile, просто задайте в директиве AuthDigestFile путь в каталоге и имя файла паролей.

Чтобы создать файл паролей в этом варианте, воспользуйтесь программой /usr/local/etc/httpd/support/htdigest. Приведенный ниже пример иллюстрирует использование программы htdigest для создания пароля для пользователя jem:

$htdigest -с /etc/dlgest_passwd "[email protected]" jem

Adding passowd for jem. New password:

Re-type new password:

Единственным отличием от случая использования программы htpasswd является присутствие аргумента [email protected], представляющего собой название области, в которую включается пользователь jem. Области используются, если пользователь имеет в одной системе более одного имени или несколько паролей. Когда отображается название области, пользователь понимает, что следует ввести имя и пароль именно для этого домена.

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

smers: mdw ewt jem merry mgd

Такая строка создает на сервере Apache парольную группу smers с пятью членами.

<Limit>

Как и директива <Directory>, <Limit> является директивой секционирования. Она используется для наложения ограничений доступа к файлам в каталоге по протоколу HTTP. Директиву <Limit> можно использовать внутри секции <Directory> в файле access, conf, либо в пользовательском файле .htaccess (если этому не препятствует значение, указанное в директиве AllowOverride).

Директива <Limit> принимает в качестве аргументов один или несколько методов HTTP, к которым применимы следующие четыре директивы, используемые внутри секции <Limit>: deny (отказать), allow (разрешить), order (порядок) и require (потребовать).

Директивы deny и allow дают возможность задавать, каким компьютерам и доменам разрешен доступ к данным каталогам. Синтаксис этих директив одинаков, за каждой из них следует слово ⌠from■ и список компьютеров, которым сервер должен запретить или, наоборот, разрешить доступ к каталогу. В этот список можно включать:

∙ названия доменов, например shoop.com или cia.gov.

∙ названия хостов, например grumpy.shoop.com или bhurma.cia.gov.

∙ IP-адреса хостов, например 115.23.42.5.

∙ IP-адреса доменов, например 115.23.42.

∙ слово all, означающее все хосты.

В директиве order задается порядок, в котором сервер Apache рассматривает директивы deny и allow. Существуют три допустимых значения:

∙ deny,allow. Сначала сервер рассматривает директиву deny, а затем ≈ allow.

∙ allow,deny. Сначала сервер рассматривает директиву allow, а затем ≈ deny.

∙ mutual-failure. Сервер отказывает в доступе всем компьютерам, явно не указанным в списке allow.

Четвертая директива ≈ require. Ее можно использовать для установления парольной защиты каталога. За названием директивы должен следовать список элементов. Этими элементами могут служить имена пользователей или названия групп, заданные в директивах AuthUserFile или AuthGroupFile. Можно также воспользоваться ключевым словом valid-user, указывающим серверу, что любому пользователю, имя которого присутствует в директиве AuthUserFile, должен быть предоставлен доступ в случае ввода им правильного пароля.

Ниже приведен пример файла .htaccess, разрешающего доступ только авторизованным пользователям домена nsa.gov:

AuthUserFile /home/users/onorth/www/secure/.htpasswd

AuthName SecurityTest

AuthType Basic

<Limit GET>

order deny,allow

deny form all

allow from nsa.gov

require valid-user

</Limit>

Сервер вычисляет значение директивы <Limit> в следующей последовательности:

1. Запрещает любой доступ.

2. Разрешает доступ пользователям из домена nsa.gov.

3. Требует от пользователей из этого домена ввода имени и пароля, хранящихся в файле /home/users/onorth/www/secure/.htpasswd.

Если запрос прошел все эти проверки, то по нему будут предоставлены файлы из данного каталога.

Ускоренная идентификация пользователей с использованием файлов DBM

Идентификация пользователей при помощи стандартных файлов паролей производится путем проверки каждой строки файла в поисках совпадения. На Web-серверах с большими файлами паролей (порядка нескольких сотен) становятся ощутимыми накладные расходы на подобный синтаксический разбор файла. Сервер Apache предоставляет возможность использовать для хранения паролей и информации о группах файлы базы данных, называемые DBM-файлами. Эти файлы представляют собой примитивную базу данных, попросту приводящую в соответствие значение (пароль) ключу (имя пользователя), и таблицу преобразования для быстрого поиска требуемого ключа.

Для установки DBM-файлов паролей требуется сделать несколько шагов. Прежде всего, остановите сервер Apache. Для этого воспользуйтесь полномочиями суперпользователя (root), перейдите в каталог /usr/local/etc/ttpd и введите команду ⌠kill -TERM 'cat logs/httpd.pid'■ (важно использовать именно одинарные обратные кавычки).

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

∙ Перейдите в каталог /usr/local/etc/httpd/src (либо туда, где вы разместили исходные файлы сервера Apache) и откройте в редакторе файл Configuration.

∙ Перейдите к строке 78 и добавьте флаг -Indbm к выражению EXTRA_LIBS=.

∙ Перейдите к строке 242 и удалите из строки ⌠# Module dbm_ath_module mod_auth_dbm.o■ символ комментария ⌠#■.

∙ Заново откомпилируйте исходный код

Теперь, когда сервер откомпилирован заново и готов к работе, следует изменить установки в файле access.conf таким образом, чтобы вместо файлов паролей использовались DBM-файлы. Откройте в редакторе файл access.conf и замените директивы AuthUserFile новой директивой, AuthDBMUserFile;

если требуется использовать группы, то замените директиву AuthGroupFile директивой AuthDBMGroupFile. Измените имена файлов, указанные в директивах, таким образом, чтобы старые файлы не были стерты, например: AuthDBMUserFlle /etc/dbm_htpasswd AuthDBMGroupFlle /etc/dbm_htGroup

Теперь можно без опаски перезапускать сервер.

И наконец, создайте файл паролей, воспользовавшись программой dbmmanage, находящейся в каталоге /usr/local/etc/httpd/support. Следующий пример иллюстрирует добавление пользователя в файл паролей / etc/dbm_htpasswd:

# dbimnanare /etc/dbm_htpasswd adduser bob xists2me User bob added with password xlsts2me!, encrypted to XXLlyUj92/ZyI

Программа dbmmanage может не работать с версией интерпретатора peri, имеющейся в вашей системе. Например, dbmmanage не работает с интерпретатором peri версии 5.001, patchlevel 1m. (Чтобы посмотреть, какая версия используется в вашей системе, наберите команду ⌠peri -v■.) Решить проблему можно, если установить peri 4.036 (например, в каталоге/usr/bin/perl4.036 или /usr/local/bin/perl4.036). Измените первую строку сценария dbmmanage ≈ ⌠#!/usr/local/bin/perl■, указав в ней местоположение рег14.036, например, ⌠#!/usr/bin/ рег14.036■.

Вот и все, что требовалось сделать для включения механизма DBM-файлов паролей в вашей системе, и сокращение времени ответа вашего сервера с лихвой окупит проделанную работу.

Более подробную информацию об использовании механизма DBM-файлов паролей можно найти в инструкциях к серверу Apache по адресу http:// www.apache.org/docs/auth_dbm.html.

Развернутая конфигурация

Установка виртуальных хостов

Понятие виртуальных хостов возникло, когда корпорации стали создавать свои Web-узлы, но размещали их на серверном пространстве, арендованном у других фирм. Первоначально, чтобы получить адрес типа http://www.shoop.com, весь компьютер должен был быть выделен под один этот сервер. Web-узел, размещавшийся на арендованном пространстве на другом сервере, получал адрес вида http://www.websites.com/ shoop или http://www.shoop.com/shoop. В последнем случае, набрав адрес http://www.shoop.com, вы по-прежнему попадали на http:// www.websites.com ≈ указание /shoop являлось обязательным.

Для сервера Apache были разработаны два обходных пути, позволявших Web-узлу иметь собственное имя. Первое решение старше, но и работает со всеми броузерами. Второе решение проще, но использовать его могут только современные броузеры, например Netscape Navigator версии 2.0 или более поздней. Решая, каким из способов реализации виртуальных хостов воспользоваться, не забывайте о компромиссе между простотой реализации и универсальностью доступа.

Первое решение включает в себя три шага. Прежде всего следует сконфигурировать несколько IP-адресов так, чтобы они указывали на один и тот же сервер: ваш Web-сервер. Этот первый шаг должен сделать ваш сетевой администратор или провайдер. Попросите их добавить к серверу имен (name server) вашей сети адресную запись, или ⌠A-record■. В этой записи должен иметься свободный IP-адрес для нового имени вашего хоста, например 10.1.12.236 для www.virtualpizza.com.

Не забудьте, что нельзя просто выбрать для домена понравившееся вам название. Название домена следует зарегистрировать в организации InterNIC. Инструкции и расценки приведены на справочном Web-узле InterNIC, находящемся по адресу http://rs.internic.net/help/.

Следующим шагом является настройка вашего компьютера на прием трафика для нескольких IP-адресов через один сетевой интерфейс (например, сетевую карту Ethernet). Чтобы узнать название вашего сетевого интерфейса, введите без аргументов команду ifconfig, например:

ft ifconfig

ethO Link encap:10Mbps Ethernet Hwaddr 00:20:OD:OA:24:FF

inet addr:10.1.12.15 Beast: 10.1.12.255 Mask 255.0.0.0

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets: 13802051 errors:19 dropped:19 overruns:5

TX packets: 8357357 errors:0 dropped:0 over runs:0

Interrupt: 10 Base address: 0х300

В данном случае сетевой интерфейс носит название ⌠ethO■, сетевая карта Ethernet. Теперь достаточно просто ввести адрес-псевдоним ≈ второй адрес для той же самой карты.

Воспользовавшись полномочиями суперпользователя (root), при помощи приведенной ниже команды ifconfig задайте для сетевого интерфейса прием графика для второго IP-адреса:

ftifconfig ethO alias 10.1.12.256

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

Наконец, необходимо внести изменения в файлы конфигурации. Откройте в редакторе файл httpd-conf и удалите символ комментария из группы строк, начиная с <VirtualHost host.foo.com> и кончая строкой </ VirtualHost> включительно. Отредактируйте эти строки, использовав значения директив для нового сервера. Поставьте вместо названия host.foo.com в директивах <VirtualHost> и ServerName имя компьютера,

которое вам требуется использовать (в нашем примере ≈ www.virtualpizza.com). Значение в директиве DocumentRoot должно указывать на отдельную область хранения документов, специально предназначенных для этого сервера, например /usr/Iocal/etc/httpd/pizzadocs. Директивы ErrorLog и AccessLog позволят вам вести отдельные журнальные файлы для каждого из серверов, поэтому имеет смысл изменить имена журнальных файлов таким образом, чтобы они соответствовали именам серверов, особенно если эти файлы находятся в одном каталоге.

Вот и все, что требовалось сделать. Необходимость настройки сервера имен и конфигурации сетевого интерфейса была вызвана тем, что текущая версия протокола НТТР/1.0 не предоставляет возможности отслеживания имени хоста назначения. Сначала протокол находит по имени хоста его IP-адрес, а затем обращается к этому хосту, не сохраняя у себя его имя. Поэтому в качестве обходного пути можно задать отдельный IP-адрес для каждого сервера. Однако число адресов в Интернете не безгранично, и провайдеры со все меньшей охотой выделяют большие блоки адресов.

Второе решение заключается в использовании возможностей НТТР/1.1, версии протокола HTTP, до сих пор находящейся в стадии предложения. В HTTP/I.I отслеживается имя сервера назначения, и сервер Apache, равно как и некоторые броузеры (включая Netscape), пользуется этой возможностью. Это означает, что можно установить несколько серверов на одном IP-адресе. Эта возможность реализуется в два шага. Первый шаг опять-таки должен сделать сетевой администратор или провайдер. Сетевой администратор должен ввести для каждого ⌠фальшивого■ сервера псевдоним, называемый строкой CNAME, указывающий на реальный компьютер с Web-сервером. В приведенном выше примере администратор должен был бы создать строку CNAME для названия www.virtualpizza.com, указывающую на настоящий сервер, например pizza.food.net.

Второй шаг совпадает с последним шагом предыдущей процедуры: необходимо удалить символ комментария из относящихся к директиве Virtual-Host строк файла httpd.conf и поместить вместо значений по умолчанию информацию о вашем виртуальном Web-сервере.

Установка прокси-сервера

Как уже упоминалось выше, при рассмотрении директивы CacheNegotiated-Docs, прокси-сервер выполняет роль посредника между сервером и клиентом. Клиент обращается к своему прокси-серверу, а тот уже, в свою очередь, становится клиентом для сервера, содержащего требуемую информацию. Клиент запрашивает документ, но в его настройках указывается прокси-сервер для протокола HTTP (как показано на рис. 8). Этот запрос затем передается прокси-серверу, который перехватывает запрос и как клиент запрашивает документ у настоящего сервера. Настоящий сервер в ответ передает документ прокси-серверу. Прокси-сервер передает копию клиенту, начавшему всю цепочку. Обычно такой механизм используется в целях защиты информации, когда сеть находится за брандмауэром, препятствующим свободному обмену информацией между компьютерами, находящимися по разные его стороны.

Однако механизм прокси используется и для ускорения доступа к часто запрашиваемым документам. По завершении цепочки взаимодействий, описанной в предыдущем абзаце, заказанный документ может быть кэширован или сохранен на прокси-сервере. Когда следующий клиент заказывает тот же документ, прокси-сервер просто передает копию, сохраненную при предыдущем запросе, не обращаясь за документом в Интернет. Этот метод используется крупными провайдерами и даже некоторыми странами, например Новой Зеландией и Великобританией, для уменьшения объемов графика через загруженные соединения в Интернете.

Настроить сервер Apache в качестве прокси-сервера очень просто. Как и для большинства других возможностей, имеющиеся значения по умолчанию являются вполне разумными и могут, в большинстве случаев, использоваться в неизмененном виде. Откройте в редакторе файл httpd.conf, перейдите к строке, ⌠#Proxy Requests On■. Если вам требуется только включить механизм прокси, но не требуется кэшировать документы, просто удалите из этой строки символ комментария #. Однако неплохо было бы все-таки включить кэширование, поэтому мы рассмотрим опции, позволяющие с большей эффективностью использовать ваши часто запрашиваемые документы.

Первой в списке значений по умолчанию стоит директива CacheRoot, в которой задается каталог для хранения кэшируемых документов. Удалите из этой строки (и из строк всех других директив Cache) символ комментария и измените ее в случае, если значение в директиве DocumentRoot отличается от принятого по умолчанию.

Во второй директиве, CacheSize, указывается объем дискового пространства в килобайтах, отводимого под хранение кэшированных документов. Сервер может превысить этот объем, но как только это случится, он начнет удалять файлы из области кэша, чтобы снова сократить ее объем. Значение, принятое по умолчанию, 5 килобайт, в действительности является очень маленьким для сервера, планирующего производить кэширование для большого числа клиентов: только состоящая из двух страниц документация, описывающая возможности прокси-сервера Apache, занимает 7 килобайт. Установка CacheGcInterval задает интервал, с которым производится проверка размера области кэша; по умолчанию проверка производится каждые четыре часа.

Следующие три директивы позволяют устанавливать время нахождения документа в области кэша. Документы, передаваемые при помощи протокола HTTP, должны иметь дату окончания срока действия, указываемую в заголовке документа или в области метаинформации. Если дата окончания срока действия не передана либо она кажется вам слишком далекой, начинают действовать эти директивы. В директиве CacheMaxExpire задается максимальный промежуток времени, в течение которого документ может находиться в области кэша, вне зависимости от его срока действия. По умолчанию принимается значение 24 часа. Директива CacheLastModifiedFactor указывает, когда следует удалить документ, не имеющий срока действия. Заданное здесь значение умножается на промежуток времени, истекший с момента последнего изменения документа, и полученный результат принимается в качестве нового срока действия. Например, если последние изменения в документе были сделаны 24 часа назад, а в директиве CacheLastModifiedFactor было оставлено значение по умолчанию ≈ 0,1, то документ будет удален из области кэша через 2,4 часа (24 умножить на 0,1). Даже если полученный результат боль-

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

Наконец, директива NoCache предоставляет возможность запретить кэширование документов, полученных от некоторых серверов. Можно указать названия отдельных серверов, например www.virtualpizza.com, или целых доменов, например shoop.org, ≈ в последнем случае будет запрещено кэширование документов от серверов всего домена.

Одной из возможностей, пример использования которой не приведен в файле httpd-conf, является директива Proxy Pass. Это еще один способ кэширования документов, при котором клиент запрашивает документ непосредственно у прокси-сервера, и перехвата запроса не происходит. Директива имеет следующий синтаксис:

ProxyPass /mirror/toppings http://pepperoni.org/docs

В вышеприведенном примере серверу Apache указано запрашивать все документы, путь к которым начинается с /mirror/toppings, на удаленном Web-узле http://pepperoni.org/docs и предоставлять их клиентам, как будто эти документы находятся в файловой системе сервера. Это дает эффект зеркального Web-узла, поскольку появляется возможность запрашивать документы с различных Web-серверов, используя локальные адреса URL. Эффект зеркала объясняется тем, что на сервере производится кэширование документов (если, конечно, включены директивы Cache), создавая подобие системы ⌠зеркала по требованию■. Директива ProxyPass по-прежнему находится на стадии разработки, поэтому лучше будет опробовать ее, прежде чем предлагать в качестве услуги на вашем Web-сервере.

Смягченные, более дружественные сообщения об ошибках

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

Основное применение директивы ErrorDocument является очень простым. В ней помещается текстовая строка, возвращаемая клиенту, либо адрес, на который перенаправляется клиентский запрос. Синтаксис этой директивы: <ErrorDocviment кoд_oшuбкu вывод■, где код_ошибки заменяется одним из кодов ошибок HTTP протокола (табл. 3-2), который подвергается действию директивы, а вывод ≈ это либо адрес URL, либо текст, передаваемый клиенту в качестве описания ошибки.

Таблица 3-2. Распространенные коды возврата HTTP протокола с разъяснениями
 

Коды возврата HTTP	Значение
200	⌠ОК■: Документ существует и доступ к нему разрешен.
302	⌠Found■: Требуемый документ находится по другому адресу URL.
400	⌠Bad Request■: Сервер не смог распознать запрос.
401	⌠Unauthorized■: Клиент не имеет права осуществлять доступ к документу без специальных полномочий.
403	⌠Forbidden■: Сервер ни при каких обстоятельствах не предоставляет указанный документ.
404	⌠Not Found■: Документ не найден.
500	⌠Server Error■: На сервере произошла ошибка.
501	⌠Not Implemented■: Запрошенная возможность не поддерживается сервером.

 

В следующем примере использования директив ErrorDocument при различных распространенных ошибках показаны различные применения директивы ErrorDocument:

ErrorDocument 401 http://www.subscribe.coni/form.html

ErrorDocument 404 "There's nothing here by that name,

Check your spelling."

ErrorDocument 500 /errors/blaine_interni.html

В первом и третьем примерах броузеру возвращается адрес URL, по которому будет направлен клиент. В первом случае это документ на другом

сервере, а в третьем в качестве сообщения об ошибке будет возвращен локальный документ. Во втором примере броузеру в качестве ответа будет передана текстовая строка. Обратите внимание, что эта строка не берется в кавычки, а просто начинается с символа кавычки. Это служит указанием серверу, что все последующие символы следует интерпретировать как текстовую строку, а не как адрес URL.

Адрес URL в директиве ErrorDocument может вместо файла HTML указывать на сценарий CGI, но существуют специальные требования к сценарию, занимающемуся обработкой ошибок. Хороший пример такого сценария предоставляет распространение NCSA сервера (он предназначен для NCSA HTTPd 1.4, но прекрасно работает и с сервером Apache). Этот сценарий, носящий название nph-eror.pl, воспроизводит все распространенные сообщения об ошибках, используемые сервером, в формате, предоставляющем возможность легко изменить эти сообщения. Поместите сценарий в ваш каталог для сценариев CGI (вероятно, /usr/local/etc/httpd/cgi-bin), убедитесь, что сценарий является исполняемым (⌠chmod 755 nph-error.pl■ в командной строке UNIX), и попробуйте запустить его. Когда будете готовы взглянуть на результат внесенных изменений, измените одну из директив ErrorDocument примерно следующим образом:

ErrorDocument 404 /cgi-bin/nph-error.pl

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

Более подробную информацию об обработке ошибок с использованием сценариев CGI можно найти в документации и примерах NCSA по адресу http:// hoohoo.ncsa.uiuc.edu/docs/setup/srm/ErrorDocument.html.

Различные задачи сервера

Сопровождение HTTP-сервера ≈ это не только совмещение приятного с полезным. Чтобы он стабильно функционировал, требуется ежедневно выполнять большой объем рутинной работы.

Останов и перезапуск сервера

Если запуск сервера производится из демона inetd и вам необходимо отключить доступ к Web-серверу по протоколу HTTP, следует запретить демону inetd запуск дополнительных копий сервера. Воспользовавшись

полномочиями суперпользователя (root), закомментируйте в файле /etc/ inetcLconf строку, отвечающую за запуск сервера:

⌠http stream top nowait root /usr/local/etc/httpd/httpd httpd

Сохраните файл и выйдите из редактора. Чтобы внесенные изменения возымели действие, необходимо послать демону inetd сигнал hang-up, что детально рассматривалось в разделе ⌠Запуск сервера■ на стр. 97.

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

#cd /usr/local/etc/httpd

#kill 'cat logs/httpd.pid'

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

ftkill -1 'cat logs/httpd.pid'

В результате выполнения этой команды HTTP-серверу посылается сигнал HUP (hang-up). Получив сигнал, исходная копия сервера производит следующие действия:

∙ уничтожает все копии сервера в пуле серверов;

∙ уничтожает все остальные копии сервера;

∙ заново считывает файлы конфигурации и производит их синтаксический разбор;

∙ закрывает и вновь открывает журнальные файлы;

∙ заново инициализирует пул серверов, число процессов в котором берется из директивы StartServers в файле /usr/local/etc/httpd/conf/ httpd.conf.

Как видите, список довольно полный. Практически, послав серверу сигнал hang-up, вы производите сброс всех его параметров к начальным значениям. Если все прошло успешно, то в файле ErrorLog появится сообщение вида:

[Tue Apr 11 23:00:05 1995] httpd: successful restart

Ведение журнальных файлов и их анализ

По умолчанию журнальные файлы находятся в подкаталоге logs каталога, указанного в качестве корневого каталога сервера в директиве ServerRoot

в файле httpd.conf (обычно это каталог /usr/local/etc/httpd). В файле access_log производится учет всех соединений с вашим сервером. Он также используется различными программами для подготовки отчетов о работе сервера. Вам следует определить политику циклического перемещения журнальных файлов, обычно производимого в начале каждой недели или месяца. Для этого можно использовать следующую процедуру:

ftcd /usr/local/etc/httpd

ftmv logs/access_log logs/access_log.name_of_inonth.year

ffkill -1 'cat logs/httpd.pid'

Многим необходима статистика использования их Web-узла. В следующем списке приведены некоторые программы анализа журнальных файлов:

∙ Wusage, автор ≈ Томас Баутелл, ht1a■://siva.cshl.org/wusage.html.

∙ Fwgstat, автор ≈ Джонатан Мэгид, http://sunsite.unc.edu/jem/fwgstat. html.

∙GetStats, автор ≈ Кевин Хьюз, http://www.eit.com/software/ getstats/getstats.html.

∙ wwwstat, автор ≈ Рой Филдинг, http://www.iscuci.edu/WebSoft/ wwwstat/.

∙ gwstat, программа графического представления вывода из программы wwwstat, автор ≈ Кьеганг Лонг, http://dis.cs.umass.edu/stats/ gwstat.html.

Партнёры:

Хостинг: