Хокинс С. - Администрирование Web-сервера Apache и руководст

12.1. Введение

Среди целей, которые преследовались при разработке сервера Apache, можно отме тить и следующую — создать такое программное обеспечение, которое могло бы рабо тать с продуктами сторонних разработчиков. Для этого был создан Apache API (Application Programmer Interface — интерфейс программирования приложений). Он позволяет взаимодействовать с сервером практически во всех аспектах его работы. Это означает, что разработчик может создавать свои собственные директивы и настраивать сервер в любой фазе его работы.

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

Для более полного изучения программного интерфейса Apache существует только одна книга, на которую стоит обратить внимание, — это книга Writing Apache Modules with Perl and С, написанная в соавторстве Линкольном Штайном (Lincoln Stein) и Дугам Мак Ичерном (Doug MacEachem).

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

12.1.1. Модуль mod_perl

Первоначальный программный интерфейс сервера Apache ограничивался только языком С. Но в 1996 году паренек по имени Дуг Мак Ичерн создал модуль mod_perl, являющийся полнофункциональным интерпретатором Perl, реализованным как МО дуль Apache. Модуль mod_perl с помощью вызова методов и объектов позволяет по

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

12.2. Инсталляция модуля mod_perl

Модуль mod_perl в стандартный дистрибутив не включен, но его можно бесплат но загрузить с узла http://perl.apache.org.

Посетите этот узел и загрузите дистрибутив. Дистрибутив хранится в упакованном виде. Распакуйте его.

tar zxvf mod_perl X.XX.tar.gz

В результате будет создан каталог mod_perl X.XX. Перейдите в этоткаталог.

cd mod_perl X.XX

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

Таблица 12.1. Команды файла Makefile.pl

С другой стороны, обработку можно ограничить отдельными фазами цикла запро сов. Опции Makefile. PL и соответствующие им директивы Apache перечислены в табл. 12.2.

12.2.1. Построение модуля mod_perl

Как видно из приведенной выше таблицы, файл Makefile. PL имеет множество опций. Вряд ли у вас все получится с первого раза. Поэтому рекомендуется создать отдельный сценарий, функции которого заключаются только в вызове файла Make file. PL. При построении программы httpd с модулем mod_perl можно воспользо ваться следующей последовательностью директив, генерирующей Makefile:

perl Makefile.PL \ PREFIX=/opt/apache \ APACHE_PREFIX=/opt/apache \

APACHE_SRC=/opt/apache/src \ DO_HTTPD=1 \

EVERYTHING=1

Чтобы построить новый файл httpd, запустите соответствующую утилиту

make

Затем проинсталлируйте его обычным способом. Полученная в результате про грамма httpd не содержит модуля mod_ssl или еще каких то стандартных модулей. Если ваш вариант программы httpd, кроме модуля mod_perl, будет включать и дру гие модули сторонних разработчиков, можно порекомендовать построить модуль mod_perl как динамический модуль.

perl Makefile.PL \ USE_APXS=1

WITH_APXS=/opt/apache/bin/apxs \

EVERYTHING=1

Запустите утилиту make и создайте модуль libexec. so, затем командой

make install

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

12.3. Программный интерфейс Apache API

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

•Транслирование запрошенного адреса в файл.

•Проверку пользователя.

•Проверку прав пользователя.

•Определение МIMЕ типов.

•Генерацию ответа.

•Регистрацию проделанных операций.

На протяжении всех этих фаз есть возможность вызова дескриптора с помощью директив модуля mod_perl. Сервер Apache передает всем дескрипторам в качестве аргумента структуру request_rec ($r). В приложении К, "Интерфейс mod_perl API" приводится полная распечатка методов и классов, имеющихся в модуле mod_perl.

12.4. Созданиедескрипторов

Нет сомнения, что после успешной установки модуля mod_perl, у вас возникнет желание создать свой собственный модуль сервера Apache. Это темаотдельной книги, но материала, приведенного здесь, будет вполне достаточно для того, чтобы попробо вать сделать это.

12.4.1. Размещение модуля Perl

Сервер Apache должен знать, где можно найти созданные вами модули. По умол чанию модуль mod_perl размещен в ServerRoot в каталоге lib/perl, находящемся в каталоге ServerRoot. Из двух вариантов лучшим, конечно же, будет lib/perl, ведь очевидно, что каталог ServerRoot к этому моменту уже переполнен. Если же вам не подходит ни один их этих каталогов, для изменения значения переменной PERL5LIB воспользуйтесь директивой PerlSetEnv.

PerlSetEnv PERL5LIB /some/other/location

Далее, так как большая часть операций будет производиться в пространстве имен Apache::, вам потребуется создать подкаталог Apache в каталоге, в котором находят ся ваши библиотеки.

mkdir /opt/apache/lib/perl/Apache

С другой стороны, для запуска с тартового файла может потребоваться создать Perl сценарий (расширение .pl).

#!/usr/bin/perl BEGIN {

use Apache();

use lib Apache$>server_root_relative ('lib/perl');

}

1;

Этот файл можно запустить с помощью директивы PerlRequire: PerlRequire conf/setup.pl

12.4.2. Объект запроса

Объект запроса представляет собой первичное средство обмена данными между сервером и его модулями. Детальное изложение его реализации и эксплуатации нахо дятся вне пределов этой книги, но из приложения К, "Интерфейс mod_perl API" можно увидеть, с чем придется работать, и пример, приведенный ниже, позволит вам получить общее представление об их использовании. В общих чертах объект запроса используется в следующих целях:

•Получение информации о соединении (метод get_server_port ( ) ) и пользова теле (метод get_remote_host () ).

•Получение данных методом POST или загрузка данных (метод read ( ) ) .

•Пересылка данных на броузер пользователя (метод print ( ) ) .

•Получение или модифицирование заголовков HTTP (метод header_out ()) .

•Запись информации в регистрационный журнал (метод log error ()) .

12.4.3. Основной модуль

Модуль, описанный ниже, связан с определенным <Location>. Этот модуль при запуске создает простейший HTML файл.

1.package Apache::BasicModule;

2.use Apache::Constants qw(OK);

3.sub handler {

4.my $req_obj=shift;

5.$req_obj$>content_type('text/html') ;

6.$req_obj$>send_http_header;

7.$req_obj$>print(

8."<HTMLXHEAD>",

9."<TITLE> Basic Handler </TITLE>",

10."</HEADXBODY>" ,

11."<H1> This is a test handler.</Hl>",

12. "</BODYX/HTML>") ;

13.return OK;

14.}

15.1;

Встроке 1 делается объявление, что это будет часть пространства имен сервера Apache. В строке 2 предоставляется доступ к классу Apache::Constants, в котором

содержатся константы, методы, коды ответа и т.д.

Со строки 3 начинается собственно тело мини модуля, подпограммы, handler. Эта подпрограмма вызывается сервером Apache по запросу к каталогу <Lo cation>, который будет задан в следующей части. В строке 4 объект запроса, переданного сер вером, сохраняется в переменной $req_obj.

Строка 5 устанавливает MIME тип в text/html, и строка 6 с помощью функции send_http_header () объекта запроса посылает заголовки http. Строки от 1 до 12 с помощью метода print объекта запроса записывают несколько строк HTML кода для передачи его клиенту.

12.4.4. Вызов основного модуля

В этом частном случае мы попытаемся связать только что созданный дескриптор с каталогом размещения perl demo.

<Location /perl demo> SetHandler perl script

PerlHandler Apache::BasicHandler </Location>

Директива <Location> предупреждает сервер Apache о том, что каталог /perl demo особенный. Директива SetHandler сообщает серверу Apache о необходимости использо вать модуль mod_perl для обработки всех запросов, которые были адресованы к этому ка талогу. Наконец, директива PerlHandler сообщает mod_perl о том, что все запросы, ад ресованные к этому каталогу, должны обрабатываться модулем BasicHandler.

Задавая в броузере адрес perl demo, вы увидите на своем экране картинку, ана логичную изображенной на рис. 12.1.

Рис. 12.1. Вывод основного модуля

12.5. Директивы настройки Perl API

Директивы, перечисленные в таблице 12.3, связаны с программным интерфейсом Perl API.

Таблица 12.3. Директивы программного интерфейса Perl API

12.6. Директивы дескриптора

Перечисленные в табл. 12.4 директивы, используются для запуска модулей в опре деленные моменты жизненного цикла сервера Apache. Каждая из них принимает в качестве параметра имя модуля (например Apache::BasicHandler).

Таблица 12.4. Директивы запуска модулей

12.7. Соображения на тему производительности

Модуль mod_perl отличается большим размером и соответственно требует много памяти. Несмотря на все возможные предосторожности, с большой вероятностью можно сказать, что увеличение размера процесса httpd приведет к обмену данными между процессами httpd и областью подкачки. Этот обмен только изредка будет пре рываться для осуществления полезной работы. Идеальным способом избежать этого является создание двух отдельных физических серверов на одном из которых будет работать сервер, поддерживающий работу модуля mod_perl, и соответственно обраба тывающий запросы, связанные с обработкой модулем mod_perl, а на другом, менее мощном, модуля mod_perl не будет вообще. Направьте все запросы, связанные с об работкой модулем mod_perl, на соответствующий сервер.

Принимая во внимание то, что наличие двух серверов может не вписываться в рамки вашего бюджета, можно воспользоваться двумя имеющимися в распоряжении IP адресами. Это позволит ограничить масштаб загрузки памяти запуском двух серве ров на одной и той же машине. Воспользуйтесь директивой BindAddress для того, чтобы сервер, работающий с модулем mod_perl, обрабатывал запросы, поступающие на IP адрес А, а сервер, не работающий с модулем mod_perl, обрабатывал запросы, поступающие на IP адрес В.