Поддержка Web-сервера в Linux

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

* CGI-Сценарии. CGI (Common Gateway Interface - интерфейс общего шлюза) определяет порядок взаимодействия программ, осуществляющих динамическую генерацию HTML-документов, с Web-сервером. CGI-сценарии могут быть написаны практически на любом языке. Для их создания используются не только компилируемые, но и интерпретируемые языки, например Perl. Web-сервер запускает CGI-сценарий на выполнение в том случае, если это предусмотрено в URL. В процессе выполнения сценарий получает от Web-сервера данные, введенные пользователем, при необходимости вызывает другие программы и генерирует Web-страницу, передаваемую в ответ на запрос клиента.

* SSI (Server Side Includes - включаемые средства на стороне сервера) также предназначены для динамической генерации содержимого документа, но, в отличие от CGI-сценариев, которые формируют всю Web-страницу, SSI лишь изменяют шаблоны. SSI не обеспечивают такой гибкости, как CGI, но их удобно использовать для внесения небольших изменений в состав статических Web-страниц, например, для включения информации о текущей дате.

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

Поддержка CGI-сценариев

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

Для обеспечения работы с CGI необходимо загрузить соответствующий модуль Apache.

LoadModule cgi_module lib/apache/mod_cgi. so

Если компоненты, предназначенные для поддержки CGI-сценариев, включены в состав двоичных файлов Apache, вам надо активизировать их посредством директивы AddModule. (В некоторых случаях активизировать надо и компоненты, реализованные в виде модулей.)

AddModule mod_cgi. с

В результате сервер Apache получает возможность запускать CGI-сценарии и взаимодействовать с ними. Вам осталось лишь разрешить поддержку CGI для конкретных файлов и каталогов. Сделать это можно несколькими способами.

* ScriptAlias. Данная директива решает две задачи. Во-первых, она сообщает серверу Apache о том, что файлы, содержащиеся в указанном каталоге, должны интерпретироваться как CGI-сценарии. Во-вторых, посредством этой директивы задается соответствие между каталогом, расположенным на диске, и каталогом, который указывается в URL. Например, выражение ScriptAlias /scripts/ "/home/ httpd/cgi-bin/" отображает физический каталог /home/httpd/cgi-bin/ в каталог /scripts в составе URL. В результате, если пользователь укажет URL http: //www. threeroomco. com/scripts/test. р1,сервер запустит на выполнение сценарий test.pl, содержащийся в каталоге /home/httpd/ cgi-bin/. Часто при инсталляции Apache опции LoadModule и AddModule по умолчанию включаются в конфигурационный файл; вероятнее всего, вы встретите их, просматривая содержимое файла httpd.conf. Для работы с CGI-сценария-ми часто бывает нужен модуль mod_alias. Соответствующая директива обычно по умолчанию включается в состав конфигурационного файла. При возникновении проблем, проверьте, загружен ли данный модуль.

* Options +ExecCGI. Разрешить выполнение CGI-сценариев можно, указав значение +ExecCGI директивы Options. Данная опция не должна указываться для всей системы, ее имеет смысл применять только к отдельным каталогам (т. е. она должна присутствовать только в составе директивы <Directory>).

* . htaccess. Контролировать доступ к отдельному каталогу можно, размещая в нем файл .htaccess. Если в файле .htaccess содержится запись Options +ExecCGI, Apache будет запускать CGI-сценарии, находящиеся в этом каталоге. Чтобы это произошло, в файле httpd.conf должна находиться запись AllowOverride Options; эта запись должна воздействовать как минимум на каталог, содержащий файл . htaccess.

ВНИМАНИЕ Наличие записей Options +ExecCGI и AllowOverride Options представляет угрозу для системы. При неправильном использовании этих средств пользователи получают возможность создавать сценарии, предоставляющие полный доступ к системе. По этой причине в большинстве дистрибутивных пакетов использование файла .htaccess запрещено.

Часто при настройке Apache в конфигурационный файл включается директива ScriptAlias, отображающая каталог /home/httpd/cgi-bin файловой системы в каталог /cgi-bin в составе URL. Такая настройка удобна для администратора. Чтобы установить CGI-сценарий и сделать его доступным для пользователя, достаточно разместить соответствующий файл в каталоге /home/httpd/cgi-bin. При этом необходимо обратить внимание на права доступа к файлу. Поскольку сценарий предназначен для выполнения, для файла, содержащего код этого сценария, должен быть установлен соответствующий признак. Если вы написали сценарий самостоятельно или скопировали его с Web- или FTP-узла, то после размещения его в каталоге /home/httpd/cgi-bin надо выполнить команду chmod а+х иия_сценария.

Создание CGI-сценариев

Подобно другим сценариям, CGI-сценарии представляют собой программный код, предназначенный для выполнения. Данная глава не является руководством по написанию CGI-сценариев; в этом разделе приведены лишь некоторые общие рекомендации по работе с ними. Если вам потребуется дополнительная информация о создании CGI-сценариев, обратитесь к Web-странице по адресу http://httpd.apache.org/docs/howto/ cgi. html либо к одной из книг, посвященных этой теме.

CGI-сценарии принимают входные данные через стандартный ввод и выводят сгенерированную Web-страницу через стандартный вывод. Вывод текста, который должен быть передан клиенту, ничем не отличается от обычного вывода на консоль. Необходимо лишь помнить, что клиент просматривает информацию посредством Web-броузера, поэтому ваш CGI-сценарий должен генерировать информацию в формате HTML либо в другом формате, поддерживаемом Web-клиентом. (Например, вы можете сформировать ответ в виде графического файла.)

Помимо HTML-кода, CGI-сценарий должен создать поле заголовка Content-Type и в качестве его значения указать МШЕ-тип данных, передаваемых клиенту. Это поле имеет следующий вид:

Content-type: text/html\r\n\r\n

В данном примере указан MIME-тип text/html, означающий, что в ответ на запрос клиента CGI-сценарий сгенерировал HTML-документ. Символы \r\n\r\n соответствуют двум переводам строки, в результате поле заголовка будет отделено от остальных данных пустой строкой. Код сценария зависит от используемого вами языка программирования. Простейший пример CGI-сценария, написанного на языке Perl, приведен в листинге 20.1. Как видно из листинга, в процессе выполнения сценарий выводит строку текста. Записав файл с этим кодом в каталог, предназначенный для размещения CGI-сценариев, установите права доступа. Если после этого вы зададите URL сценария в поле адреса броузера, то увидите строку "Hello, Web".

Листинг 20.1. Простой CGI -сценарий, написанный на языке Perl #!/usr/bin/perl

print "Content-type: text/html\r\n\r\n"; print "Hello, Web";

С обработкой входных данных дело обстоит несколько сложнее. Ваш сценарий получит данные только в том случае, если они были введены пользователем посредством интерактивных элементов, содержащихся в форме. Данные поступают на вход сценария в виде набора пар имя-значение. Имя отделяется от значения символом =, а пары имя-значение разделяются символами &. Пример строки параметров, передаваемой CGI-сценарию, приведен ниже.

city=Oberlin&state=OH&zip=44074

Перед тем как использовать полученные данные, надо произвести разбор строки параметров. В языке Perl предусмотрены мощные средства работы со строками. Этот факт стал одной из причин популярности Perl среди разработчиков CGI-сценариев.

Повышение уровня защиты при использовании CGI-сценариев

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

Существуют способы, позволяющие уменьшить риск, связанный с использованием CGI-сценариев. Перед установкой сценариев необходимо еще раз поверить значения директив User и Group в файле httpd. conf. CGI-сценарии выполняются с полномочиями пользователя, указанного посредством этих директив, поэтому, используя учетную запись, предусматривающую минимальные права, вы ограничите возможности злоумышленника, если тому удастся получить контроль над CGI-сценарием. Идеальный вариант -создать учетную запись и группу, специально предназначенные для обеспечения работы сервера Apache; регистрация в системе с помощью этой учетной записи должна быть запрещена. Однако подобная мера не гарантирует безопасность системы. Недостатки в сценарии могут стать базой, используя которую взломщик продолжит действия по проникновению в систему.

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

Библиотеки сценариев размещены на различных Web-узлах, например, вы можете обратиться по адресу http: //www. cpan. org.

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

Поддержка защищенных Web-узлов

При использовании сценариев часто осуществляется шифрование передаваемых данных. Действия по кодированию и декодированию информации при обмене между Web-сервером и Web-броузером определяется протоколом SSL (Secure Sockets Layer - уровень защищенного гнезда). Протокол SSL часто используется на узлах электронной коммерции для защиты важных данных. Для поддержки SSL-кодирования при работе Apache требуется дополнительное программное обеспечение, например, mod_ssl (http: //www. modssl.org) или программы, разработанные в рамках проекта Apache-SSL (http: //www.apache-ssl.org). Для поддержки SSL-можно также использовать продукты, распространяемые на коммерческой основе.

Задачи, решаемые с помощью SSL

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

* Шифрование. SSL позволяет обеим взаимодействующим сторонам выполнять шифрование данных, обеспечивая тем самым их сохранность. Это необходимо в тех случаях, когда Web-клиент должен обмениваться с Web-сервером важной информацией, например передавать номера платежных карточек и банковских счетов. Для кодирования применяется технология открытого ключа, согласно которой каждая из взаимодействующих сторон использует два ключа. Шифрование осуществляется с помощью открытого, или общего, ключа, предоставляемого другой взаимодействующей стороной, а для расшифровки применяется собственной закрытый, или личный, ключ. Таким образом, передавая данные, участник сетевого взаимодействия уверен, что расшифровать их сможет только тот, для кого они предназначены.

* Аутентификация. Даже при использовании шифрования передача важных данных по Internet связана с определенным риском. Может оказаться, что принимающий узел - не тот, за кого он себя выдает. Например, если вы ввели в поле адреса броузера URL http: //www. abigretailer . com, можете ли вы быть уверены, что ваш запрос попадет на тот узел, на который вы его отправляете? Не исключено, что злоумышленнику удалось изменить настройку сервера DNS или маршрутизатора и перенаправить запрос на свой компьютер. SSL предоставляет средства аутентификации участников взаимодействия. Идентификация осуществляется посредством сертификатов, предоставляемых организацией, специализирующейся на этом. Сертификат, полученный от сертифицирующей организации (СА - certificate authority), представляет собой цифровой код, используемый для создания общего ключа. Если один участник взаимодействия передал свой сертификат, полученный от СА, то другой участник может быть уверен, что его партнер по обмену данными - именно тот, за кого он себя выдает. (В последнее время стало ясно, что даже сертификаты не позволяют гарантированно идентифицировать участников взаимодействия. Так, в 2001 г. сертификаты Microsoft были по ошибке выданы организациям, не имеющим к корпорации никакого отношения.)

При необходимости вы сами можете выступать в роли сертифицирующей ор-н/ГЧ, ганизации, однако ваши сертификаты будут пригодны только для внутреннего ЗМЕТКУ использования. "Внешние пользователи не будут иметь никакой гарантии того, что сертификат не фальсифицирован. Поэтому, если вы собираетесь организовать узел электронной коммерции, вам необходимо получить сертификат от СА. Список СА можно найти по адресу http: //www. apache-ssl. org/#Digital_Certif icates. Пользователям, обращающимся к Web-узлам посредством броузеров, сертификаты не нужны, так как Web-серверы практически никогда не проверяют идентичность пользователей.

При работе посредством протокола SSL используется порт, отличный от порта 80. По умолчанию для взаимодействия по защищенному протоколу HTTP (HTTPS) применяется порт 443. Чтобы Web-броузер указал в запросе этот порт, URL, введенный пользователем, должен начинаться с символов https: //. Настраивая Apache для поддержки SSL, вы можете установить один сервер, который будет по-разному реагировать на обращения через порты с номерами 80 и 443, либо использовать два сервера различных типов. Первый подход реализовать проще, но может возникнуть ситуация, при которой целесообразнее использовать два сервера (например, Apache для обработки SSL-запросов и thttpd для поддержки обычного HTTP-взаимодействия).

Настройка средств поддержки SSL

Для того чтобы сервер Apache мог поддерживать SSL-соединения, надо сконфигурировать SSL-пакет. В настоящее время в системе Linux чаще всего используются два таких пакета.

* SSLeay (http://www2.psy.uq.edu.au/~ftp/Crypto/ssleay/)

* OpenSSL (http://www.openssl.org)

Вскоре после своего появления OpenSSL приобрел статус стандарта в системе Linux. Он содержится в составе многих дистрибутивных пакетов Linux, включая Debian, Mandrake, Red Hat и SuSE. Пакеты SSLeay и OpenSSL выполняют одинаковые функции, но исполняемые файлы носят разные имена (ssleayи openssl) и для их настройки используются различные конфигурационные файлы.

После инсталляции OpenSSL вам необходимо получить сертификат. Для работы в Internet потребуется сертификат, выданный СА, но для тестирования сервера можно создать сертификат самостоятельно. Некоторые сценарии установки Apache SSL создают сертификат автоматически. Если в процедуре инсталляции не предусмотрено формирование сертификата, вы можете использовать следующую команду;

# openssl req $@ -new -x509 -nodes \ -config /usr/share/doc/apache-ssl/examples/ssleay.cnf \ -out /etc/apache-ssl/apache.pem \ -keyout /etc/apache-ssl/apache.pem

В данном примере предполагается, что настройка средств поддержки SSL осуществляется посредством конфигурационного файла /etc/apache-ssl, а в составе пакета поставляется образец конфигурационного файла /usr/share/ doc/apache-ssl/examples/ssleay. cnf. При необходимости вы можете изменить имена файлов или каталогов. Обратная косая черта указывает на то, что продолжение команды находится на следующей строке. Если вся команда помещается в одной строке, символ \ можно не использовать.

В процессе выполнения утилита openssl запросит дополнительную информацию, например имя компьютера. Эта информация включается в состав сертификата, который содержится в файле/etc/apache-ssl/apache.pem.

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

Certificate signer notfOUnd)! Ш K"OtMflWCM*tor Wserver S"ft1 registered VWp"y|nM'"ll*"*lMetfM

Установка компонентов Apache, предназначенных для поддержки SSL

Считается, что поддержка SSL в сервере Apache осуществляется за счет дополнительных модулей. На практике для установки SSL-модулей необходимо внести некоторые изменения в структуру сервера и повторно скомпилировать Apache. В некоторых инсталляционных пакетах SSL-модули включены по умолчанию, и код сервера скомпилирован с учетом использования SSL-компонентов. Если вы попытаетесь объединить компоненты обычного сервера Apache и пакета, сформированного для обеспечения поддержки SSL, такой сервер скорее всего работать не будет.

Во многих случаях для управления сервером, созданным с учетом поддержки SSL, используется конфигурационный файл, отличный от файла, применяемого для настройки обычного сервера Apache. Например, в системе Debian сервер Apache, настроенный для поддержки SSL, использует конфигурационный файл /etc/apache-sal, в то время как для стандартной конфигурации Apache в этой системе применяется файл /etc/ apache. Конфигурационные файлы для SSL-серверов во многом совпадают с файлами для Apache без поддержки SSL, за исключением некоторых директив, значения которых вам, возможно, придется изменить. Часть этих директив описана ниже.

* ServerType. Сервер с поддержкой SSL не может запускаться посредством суперсервера, поэтому для директивы ServerType должно быть установлено значение standalone.

* Использование портов. Для взаимодействия по протоколу SSL используется порт 443. При этом необходимо учитывать, что директива Listen позволяет связать сервер с определенным номером порта.

* Загрузка модулей. В качестве значений директив LoadModuXe иAddModule могут быть указаны один или несколько модулей, имеющих отношение к поддержке SSL Как правило, в конфигурационном файле, сформированном по умолчанию, значения этих директив установлены корректно.

* SSLRequireSSL. Включив данную директиву в состав <Directory>, вы запретите доступ к каталогу для клиентов, не поддерживающих SSL. (Значения данной директивы не указываются.) Использование SSLRequireSSL позволяет предотвратить передачу важных данных по незащищенному каналу. Очевидно, что, помимо данной опции, следует применять и другие средства, ограничивающие доступ к каталогу.

* SSLEnable. Директива SSLEnable разрешает использование протокола SSL при обмене данными. Подобно SSLRequireSSL, значения для данной директивы не предусмотрены.

* SSLCACertificatePath. Эта директива указывает на каталог, содержащий сертификат. Например, в качестве значения SSLCACertificatePath может быть указано /etc/apache-ssl.

* SSLCertif icateFile. В качестве значения данной директивы указывается файл, содержащий сертификат (например, /etc/apache-SSI/apache .pem). Помимо указанных выше, для управления SSL-взаимодействием могут использоваться и другие директивы. Информацию о них можно получить, просмотрев комментарии в составе конфигурационного файла либо обратившись к документации на сервер Apache или к книгам по данной теме.

Установив конфигурацию сервера, вы можете запускать его для поддержки SSL-взаимодействия. Чтобы обратиться к серверу, надо ввести в поле адреса броузера URL, начинающийся символами https : //. Если вы самостоятельно сгенерировали сертификат, броузер отобразит предупреждающее сообщение, подобное тому, которое показано на рис. 20.2. Чтобы протестировать создаваемый вами узел, вы можете принять этот сертификат (некоторые броузеры позволяют задать условия дальнейшего использования сертификата). ВНИМАНИЕ Работая в Internet, не следует принимать сертификаты, созданные администраторами Web-узлов. Если сервер использует сертификат, выданный сертифицирующей организацией, броузер не отображает предупреждающее сообщение. Если же подобное сообщение появилось на экране, это означает, что при использовании сертификата была допущена ошибка (например, сервер продолжает работать с сертификатом, срок действия которого истек) либо администратор вовсе не обращался к сертифицирующей организации. Появление предупреждающего сообщения также может означать, что злоумышленник пытается представить свой узел как узел официальной организации и собрать с его помощью важные данные.

Организация виртуальных доменов

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

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

Наличие виртуальных доменов позволяет Web-серверу по-разному обрабатывать запросы, в зависимости от имен, указанных в них. (Чтобы к Web-серверу можно было обращаться по разным именам, необходимо создать несколько записей в конфигурационном файле DNS-сервера.) Примеры использования виртуальных доменов описаны ниже.

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

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

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

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

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

Конфигурация виртуальных доменов

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

Использование VirtualDocumentRoot

VirtualDocumentRoot- одна из основных директив, используемых для настройки виртуальных доменов. Эта директива позволяет указать имя каталога, которое будет выполнять роль корневого каталога документов при указании в составе запроса определенного имени. В качестве значения VirtualDocumentRoot указывается имя каталога, которое может содержать различные переменные. (Назначение этих переменных описано в табл. 20.1.)

Рассмотрим в качестве примера следующую запись:

VirtualDocumentRoot /home/httpd/%0

Серверы Internet

Она сообщает серверу о том, что он должен использовать подкаталог каталога /home/ httpd, имя которого соответствует полному имени сервера, указанному в составе запроса. Например, если в запросе задан URL http://www.threeroomco.com/index. html, сервер будет искать файл /home/httpd/www.threeroomco.com/index. html. Такой способ очень удобен, но если вам необходимо поддерживать большое количество Web-узлов, то придется создавать много подкаталогов с достаточно длинными именами (в данном примере все подкаталоги должны присутствовать в каталоге /home/httpd). При необходимости вы можете использовать в качестве имени каталога часть доменного имени. Пример подобного подхода иллюстрирует приведенная ниже запись.

VirtualDocumentRoot /home/httpd/%-1/%-2

Если в конфигурационном файле содержится такое выражение, то, получив запрос, в котором указан URL http://www.threeroomco.com/index.html, Apache вернет клиенту файл /home/httpd/com/threeroomco/index.html (если он имеется на сервере). Если вы хотите использовать в имени каталога лишь один символ из доменного имени, вам надо включить в состав конфигурационного файла запись наподобие следующей:

VirtualDocumentRoot /home/httpd/%-2.1/%0

Теперь при получении URL http: / /www. threeroomco. com/ index. html Apache вернет клиенту файл /home/httpd/t/www.threeroomco.com/index.html. Переменная %-2 .1 определяет первый (. 1) символ в составе имени домена (-2), предшествующего имени домена верхнего уровня.

Независимо от значения директивы VirtualDocumentRoot, вам надо задать значение Off для директивы UseCanonicalName.

UseCanonicalName Off

Если директива UseCanonicalName будет иметь значение On, устанавливаемое по умолчанию при инсталляции сервера, Apache будет использовать для обработки относительных ссылок доменное имя компьютера, на котором он выполняется. Например, если в документе index, html содержится ссылка на Web-страницу products . html, Apache будет стараться извлечь ее, основываясь на своем каноническом имени. При наличии виртуальных доменов такое поведение недопустимо. Если задать значение Off директивы UseCanonicalName, то для обработки относительных ссылок Apache будет применять имя, соответствующее виртуальному домену.

Использование <VirtualHost>

Альтернативный подход к созданию виртуальных доменов предполагает непосредственное описание каждого из них. Для этого в конфигурационном файле Apache предусмотрены две специальные директивы.

* NameVirtualHost. Данная директива указывается в главном конфигурационном файле Apache и информирует сервер о том, что вы собираетесь использовать виртуальные узлы. В качестве значения этой директивы чаще всего указывается символ *; при этом необходимо определять виртуальные домены для поддержки всех типов обращения к серверу. Кроме того, значением опции NameVirtualHost может быть IP-адрес, связанный с сетевым интерфейсом; в этом случае конфигурация основного сервера применяется ко всем запросам, за исключением запросов, переданных через этот интерфейс, и запросов, соответствующих определению виртуального узла.

* <VirtualHost>. Данная директива указывает на начало блока, содержащего определение виртуального домена. Для этой директивы задаются те же значения, что и для директивы NameVirtualHost. Признаком окончания блока служит директива </VirtualHost>. В состав блока включаются директивы, определяющие конфигурацию виртуального домена; здесь вы можете указать многие из тех директив, которые используются для настройки сервера, не поддерживающего виртуальные узлы.

В составе блока, сформированного с помощью <VirtualHost>, обычно указываются директивы ServerName (она определяет имя, которому соответствует данный блок) и DocumentRoot. При необходимости вы также можете настроить другие характеристики сервера, например разрешить выполнение CGI-сценариев. В качестве примера рассмотрим следующий фрагмент конфигурационного файла, который описывает два виртуальных Web-узла:

NameVirtualHost *

<VirtualHost *>

ServerName www.threeroomco.com

DocumentRoot/home/httpd/threeroomco/html

ScriptAlias /cgi-bin/ "/home/httpd/threeroomco/cgi-bin/" </VirtualHost>

<VirtualHost *>

ServerName www.pangaea.edu

DocumentRoot /home/httpd/pangaea-u/html </VirtualHost>

Если сервер настроен подобным образом, то при обращении к нему посредством имени www. threeroomco. com он будет предоставлять клиенту статические файлы, которые находятся в каталоге /home/httpd/threeroomco/html, или запускать на выполнение сценарии, содержащиеся в каталоге /home/httpd/threeroomco/cgi-bin. Если же в запросе указано имя www. pangaea. edu, то статические файлы будут извлекаться из каталога /home/httpd/pangaea-u/html, а выполнение CGI-сценариев будет запрещено.

В отличие от VirtualDocumentRoot, использование директивы <VirtualHost> позволяет настроить каждый виртуальный узел и размещать документы в произвольных позициях файловой системы. С другой стороны, VirtualDocumentRoot предельно упрощает добавление новых доменов; для этого достаточно создать новый каталог. В большинстве случаев администраторы предпочитают использовать директиву <VirtualHost>, однако вы можете выбрать любой из этих способов, исходя из особенностей поставленной перед вами задачи.

Создание содержимого Web-узла

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

Форматы данных, используемых при создании Web-узла

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

Основу большинства Web-страниц составляет HTML-файл. Этот файл содержит текстовые данные, пригодные для редактирования с помощью обычного текстового редактора. Пример простого HTML-файла приведен в листинге 20.2. Данные, содержащиеся в HTML-файле, делятся на две категории: текст, предназначенный для отображения в окне броузера, и последовательности символов, помещенные в угловые скобки, называемые дескрипторами. Дескрипторы представляют собой элементы форматирования, а также выполняют некоторые другие функции. Большинство дескрипторов используются парами, каждая из которых состоит из открывающего и закрывающего дескрипторов. Открывающий и закрывающий дескрипторы имеют одно и то же имя, но перед именем закрывающего дескриптора указывается символ /. В состав открывающего дескриптора часто входят атрибуты, уточняющие действия дескриптора. Например, с помощью атрибутов могут задаваться размеры изображения и содержащий его файл, цвет фона и текста и т. д. Некоторые из дескрипторов формируют ссылки на документы, расположенные на том же сервере, либо на других Web-серверах.

Назначение некоторых из дескрипторов, приведенных в листинге 20.2, очевидно, другие требуют более подробного рассмотрения. Ниже представлено описание дескрипторов, наиболее часто встречающихся в HTML-документах.

* <HTML>. Данный дескриптор сообщает о том, что документ является HTML-документом. Большинство броузеров не требует наличия этого дескриптора, но желательно указывать его, так как он предусмотрен спецификацией языка.

* <HEAD>. HTML-документ делится на заголовок и тело документа. В заголовке в основном содержится информация, не предназначенная для отображения (за исключением содержимого элемента <TITLE>). Заголовок содержится между открывающим и закрывающим дескриптором <HEAD>.

Листинг 20.2. Пример HTML-файла __ _ __

<!DOCTYPE HTML PUBLIC ;^77IETF77DTD HTML гТоПЁйЫ

<HTMLXHEAD>

<TIТЬЕ>Пример Web"=страницы</TITLE>

</HEAD>

<BODY BGCOLOR="#FFFFFF" TEXT="#000000">

<CENTERXH1 ALIGN="CENTER">Пример ИеЬ"=страницы</Н1></СЕЫТЕК>

<IMG SRC="graphics/logo.jpg" ALT="Logo" WIDTH="197"

HEIGHT="279"> <Р>Данная Web''-странича содержит <А

HREF="http://www.threeroomco.com/anotherpage.html">

гипертекстовую ссылку.</AX/P>

</BODYX/HTML>

. <TITLE>. Строка, заданная с помощью этого дескриптора, выводится в заголовке окна броузера. Эта же строка отображается в списке закладок,

. <BODY>. С помощью данного дескриптора формируется тело HTML-документа. В состав дескриптора <BODY> часто включают атрибуты, определяющие цвет текста и фона, и другие характеристики документа.

. <Н1>. Заголовки позволяют делить текст документа на разделы и, как правило, отображаются шрифтом большего размера, чем обычный текст. Создавая код Web-страницы, вы можете включать в него заголовки различных уровней. Наивысшим считается уровень 1 (<Н1>), а самым низким - уровень 6 (<Нб>). В листинге 20.2 в дескрипторе <Н1> содержится атрибут ALIGN, который сообщает Web-броузеру о том, что текст заголовка должен быть размещен по центру экрана. К сожалению, не все броузеры правильно обрабатывают атрибут выравнивания в составе заголовка, поэтому, чтобы обеспечить корректное отображение информации, его приходится дублировать дескриптором <CENTER>.

. <CENTER>. В листинге 20.2 заголовок, формируемый с помощью дескриптора <Н1>, выравнивается по центру экрана не только посредством атрибута ALIGN, но и с помощью дескриптора <CENTER>. Во многих современных броузерах такая избыточность не нужна, но если вы хотите, чтобы документ корректно отображался в старых броузерах, вам следует задавать как дескриптор <CENTER>, так и атрибут ALIGN.

. <IMG>. Данный дескриптор позволяет включать на Web-страницу графические изображения. Пример использования дескриптора <IMG> приведен в листинге 20.2. Обычно в дескриптор <IMG> включают различные атрибуты. Атрибут SRC указывает на файл, содержащий изображение; если изображение хранится на том же сервере, значением атрибута является имя файла, а если файл с изображением находится на другом сервере, то в качестве значения SRC задается абсолютный URL этого файла. Атрибут ALT задает текст, описывающий изображение. Этот текст отображается броузерами, в которых запрещен вывод изображений, а также выводится на экран при помещении на изображение курсора мыши. Атрибуты WIDTH и HEIGHT задают ширину и высоту изображения, что позволяет броузеру отображать текст документа еще до того, как загрузка изображения закончится.

* <Р>. Данный дескриптор определяет начало абзаца. Web-броузер автоматически переносит текст, достигший правого края окна, на новую строку.

* <А HREF>. С помощью дескриптора <А> создается гипертекстовая ссылка (при этом URL документа, на который указывается ссылка, задается в качестве значения атрибута HREF). Текст ссылки выделяется в окне броузера цветом и подчеркиванием. После щелчка мышью на ссылке в окне броузера отображается документ, URL которого задан посредством атрибута HREF.

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

Помимо HTML-файлов, Web-серверы могут предоставлять клиентским программам и другие типы документов. Так, например, в листинге 20.2 был приведен пример изображения, включаемого на Web-страницу с помощью дескриптора <IMG>. В документе можно создавать гипертекстовые ссылки, указывающие на текстовые и графические файлы, исполняемые программы, сценарии и другие типы данных. Необходимо лишь, чтобы сервер мог определить MIME-тип каждого из документов. Для этого используется файл mime. types, который рассматривался ранее в этой главе. Если сервер Apache не может определить MIME-тип файла, он передает данные как неформатированный текст. Это становится источником проблем при работе некоторых операционных систем, так как специальные символы, находящиеся в составе файла, могут разрушить изображение на экране.

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

* GIF. Graphics Interchange Format (формат обмена графическими данными) приобрел популярность в 1980-х. В данном формате используется схема сжатия без потери информации. Это означает, что изображение, полученное после распаковки, будет в точности совпадать с исходным изображением. Для представления цвета в GIF-изображениях используется до 8 битов, т. е. такое изображение может содержать максимум 256 цветов.

* PNG. Portable Network Graphic (переносимые сетевые графические данные) также использует схему сжатия без потери информации. В отличие от GIF, PNG позволяет представлять цвет посредством большего количества битов (обычно применяется 24-битовое представление, но PNG дает возможность использовать для этой цели до 64 битов). Недостатком PNG является тот факт, что данный формат поддерживается не всеми броузерами. Более подробную информацию о PNG можно получить по адресуhttp://www.libpng.org/pub/png/.

* JPEG. В формате Joint Photographic Expert Group (объединенная группа экспертов по обработке фотоснимков) используется сжатие с потерей информации. В результате достигается большая степень сжатия по сравнению с форматами GIF и PNG, но распакованное изображение отличается от исходного. Для представления цвета в JPEG может применяться до 24 битов.

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

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

Инструментальные средства создания Web-страниц

Несмотря на то что HTML-документы можно создавать с помощью обычных текстовых редакторов, многие Web-дизайнеры предпочитают использовать для этой цели специализированные инструменты с графическим пользовательским интерфейсом. Данные инструменты позволяют редактировать текст документа подобно текстовым процессорам WYSIWYG (what you see is what you get); при этом для выравнивания, создания абзацев, отображения текста полужирным шрифтом и выполнения других подобных действий используются кнопки, расположенные на панели инструментов. Поскольку при работе сервера Apache не имеет значения, каким способом были сформированы Web-страницы, нет никаких оснований отказываться от использования специализированных инструментальных средств. Единственным исключением является редактор Microsoft Front Page. Этот инструмент создает Web-страницы, ориентированные на конкретный сервер, поэтому при работе с Apache лучше отказаться от его использования.

Некоторые инструменты, предназначенные для создания HTML-документов, предоставляют средства автоматического копирования созданных файлов на сервер. При использовании сервера Apache эти средства могут работать некорректно, поэтому желательно сохранять HTML-файлы на локальном диске, а затем копировать их на сервер с помощью FTP.

Ниже описаны некоторые инструменты, которые могут быть использованы при создании Web-страниц.

* Текстовые процессоры. Многие современные текстовые процессоры предоставляют возможность экспортировать документы в формате HTML. (Поскольку средства форматирования текстовых процессоров мощнее, чем соответствующие средства, предусмотренные в языке HTML, при сохранении документа в виде HTML-файла внешний вид текста может несколько измениться.) Для тех, кто привык работать с текстовыми процессорами, они могут стать удобными инструментами подготовки Web-страниц. В системе Linux возможность экспортирования в HTML-формат предоставляют программы Applix Words, StarOfficeи WordPerfect.

* Web-броузеры. Многие популярные Web-броузеры, выполняющиеся в системе Linux, в частности Netscape, содержат средства для подготовки HTML-документов. Такие средства лучше подходят для создания Web-страниц, чем текстовые процессоры.

* Независимые программы подготовки Web-страниц. Единственным назначением этих инструментов является создание HTML-документов. В качестве примеров подобных программ, работающих в системе Linux, можно привести ASHE (http: // www.cs.rpi.edu/pub/puninj/ASHE/), August (http://www.lls.se/ -johanb/august/), Bluefish (http: //bluefish.openof f ice.п1)и WebSphere (http://www-4.ibm.com/software/webservers/hpbuilder/). Некоторые из этих инструментов очень просты, другие позволяют выполнять достаточно сложные действия.

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

Особенности создания Web-страниц

Некоторые Web-дизайнеры стараются в полной мере использовать возможности, предусмотренные спецификацией HTML, и создают HTML-документы, напоминающие страницы печатных изданий. Однако использование расширенных средств HTML может стать источником проблем. Дело в том, что предсказать, как тот или иной броузер будет обрабатывать некоторый фрагмент HTML-кода, практически невозможно. Даже предельно простая Web-страница, код которой показан в листинге 20.2, может по-разному выглядеть в различных броузерах. Как было замечено ранее, некоторые броузеры не обрабатывают дескриптор <CENTER>, другие игнорируют атрибут ALIGN в составе заголовка. Шрифт, указанный в документе, будет отображаться только в том случае, если он присутствует на компьютере, на котором выполняется Web-броузер, в противном случае содержимое документа будет воспроизведено с использованием шрифта по умолчанию. Цвет, заданный для отображения Web-страницы, должен сочетаться с цветами, выбранными пользователем. (Одна из ошибок, часто допускаемых Web-дизайнерами, связана с использованием цветов. Если задать цвет фона, не указав при этом цвет для отображения текста, могут возникнуть проблемы при выводе содержимого документа на экран. Предположим, например, что вы задали в документе белый цвет фона. Если при этом пользователь установил по умолчанию отображение белого текста на черном фоне, то прочитать текст документа в окне броузера будет невозможно. В листинге 20.2 заданы цвет фона и переднего плана, но не указан цвет для отображения гипертекстовых ссылок. Это также может стать источником проблем при выводе документа.)

Поскольку броузеры по-разному интерпретируют HTML-код, желательно проверять созданные вами Web-страницы в различных броузерах. Как минимум вы должны выяснить, как отображаются ваши документы в наиболее популярных на сегодняшний день клиентских Web-программах: Netscape Navigator и Microsoft Internet Explorer. По возможности следует проверить качество воспроизведения документа в различных версиях этих броузеров. Следует также учитывать, что в последнее время среди пользователей Linux стали популярны броузеры Mozilla (http: //www. mozilla. org, вариант Netscape Navigator, распространяемый в исходных кодах), Opera (http: //www. opera. com) и Коп-queror (созданный в рамках проекта KDE). Особого внимания заслуживает броузер Lynx (http: //lynx. browser. org), отображающий лишь текстовую информацию. Если вы хотите, чтобы ваши Web-страницы были доступны всем пользователям, необходимо протестировать их с помощью данного броузера. Несмотря на то что Lynx в настоящее время практически не используется, он позволяет выявить большинство проблем, которые не очевидны при работе с другими броузерами. Обеспечив воспроизведение Web-страницы посредством клиентской программы, отображающей лишь текст, вы упростите работу с Web-документами пользователей с нарушениями зрения, применяющих синтезаторы речи. Необходимо также учитывать интересы пользователей, работающих с различными операционными системами. В системе Windows наиболее популярным является броузер Internet Explorer, в других системах, например MacOS, BeOS и OS/2, используются и другие клиентские программы. Некоторые из них работают на различных платформах, другие ориентированы на выполнение в конкретной операционной системе.

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

Анализ файлов протоколов

Файлы протоколов - важный источник сведений о работе Web-сервера. Информация, содержащаяся в этих файлах, поможет вам администрировать Web-узел. Файлы протоколов включают информацию о клиентских программах, обращающихся к серверу, о документах, запрашиваемых клиентами, о времени обращений и другие сведения. Для анализа содержимого файлов протоколов вручную требуется много времени и усилий, поэтому большинство администраторов делают это с помощью специализированных инструментов, которые упрощают обработку данных. Наиболее часто для этой цели применяются программы Analog и Webalizer.

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

Формат файла протокола Apache

Данные могут записываться в файл протокола Apache в различных форматах; конкретный формат задается с помощью директивы CustomLog. В данном разделе описывается формат combined, который объединяет в одном файле различные данные. Запись в формате combined выглядит следующим образом:

192.168.1.1 - - [06/Nov/2002:16:45:49 -0500] "GET /index.html \ НТТР/1.0" 200 8597 '*-** "Mozilla (Xll; I; Linux 2.0.32 1586)"

Эта запись включает следующие компоненты.

* Доменное имя или IP-адрес клиента. Первое поле записи содержит адрес или имя клиента, от которого был получен запрос.

* Идентификатор пользователя. Следующие два поля содержат имя пользователя, инициировавшего запрос. В первом из этих полей содержится имя для сервера identd, а во втором - имя для HTTP-аутентификации. (В данном примере в этих полях указаны дефисы, указывающие на то, что сведения о пользователе не доступны.)

* Дата и время. Apache записывает дату и время передачи запроса. В этой записи содержится локальное время с указанием временного пояса (в данном примере -0500).

* HTTP-запрос. HTTP-запрос включает команду, переданную клиентом (GET), запрашиваемый документ (/index.html) и версию протокола HTML (1.0). С помощью этой информации можно определить, какие из документов, расположенных на вашем Web-узле, наиболее популярны среди пользователей.

...