Юникс и другие

Apache - это очень популярный и широко используемый web-сервер. Есть множество альтернатив, но по возможностям настройки, гибкости и количеству доступных расширений Apache прочно держится в топе. В этой небольшой статье я расскажу как можно контролировать фактически все аспекты работы вашего web-сервера при помощи Perl и mod_perl

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

Установка mod_perl
Все примеры показаны для ОС Linux Debian
Устанавливаем пакет libapache2-mod-perl2

lenny:~# apt-get install libapache2-mod-perl2
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libapache2-reload-perl libbsd-resource-perl libperl5.10
The following NEW packages will be installed
  libapache2-mod-perl2 libapache2-reload-perl libbsd-resource-perl libperl5.10
0 upgraded, 4 newly installed, 0 to remove and 2 not upgraded.
Need to get 1201kB of archives.
After this operation, 3891kB of additional disk space will be used.
...
Processing triggers for man-db ...
Setting up libperl5.10 (5.10.0-19) ...
Setting up libapache2-mod-perl2 (2.0.4-5) ...
Enabling module perl.
Run '/etc/init.d/apache2 restart' to activate new configuration!
Setting up libapache2-reload-perl (0.10-2) ...
Setting up libbsd-resource-perl (1.28-1+b1) ...

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

lenny:~# a2enmod perl
Module perl already enabled
lenny:~# /etc/init.d/apache2 restart
Restarting web server: apache2 ... waiting .

Модуль установлен, давайте займемся его настройкой. Самое простое - это добавить хендлер perl-status и посмотреть, что же происходит с нашим сервером. Создайте файл /etc/apache2/conf.d/perl-status со следующим содержимым:

 #
 # make status information available at
 #   http://example.com/perl-status/
 #
 <Location /perl-status>
    SetHandler perl-script
    PerlHandler +Apache2::Status
</Location>

 #
 # But only from the local host, and our trusted
 # remote IP.
 #
 <Location /perl-status>
    order deny,allow
    deny from all
    allow from 127.0.0.1
    allow from your.ip.address
</Location>

Перезапустите сервер и зайдите на адрес /perl-status. Узнаете несколько интересных вещей об окружении сервера и о загруженных модулях Perl
Внимание! Эта информация содержит много такого, что не стоило бы показывать всем и каждому. Поэтому не стоит делать ее доступной для всех. Ограничьте доступ!

Ускорение Perl CGI-скриптов
Так как mod_perl уже содержит встроенный интерпретатор Perl, то мы можем использовать его для запуска CGI-скриптов, вместо вызова внешней команды. Это позволит снизить накладные расходы на вызов отдельной копии интерпретатора при поступлении запроса на обработку скрипта. Есть способы добиться более внушительного ускорения, но это потребует внесения изменений в исходный код сценариев. В Debian CGI-скрипты по умолчанию располагаются в /usr/lib/cgi-bin Мы укажем Apache, что хотели бы запускать встроенный интерпретатор вместо внешнего для сценариев из этой директории.

  PerlModule Apache::Registry
  Alias /cgi-bin/ /usr/lib/cgi-bin
  <Location /cgi-bin>
    SetHandler perl-script
    PerlHandler Apache::Registry
    PerlSendHeader On
    Options +ExecCGI
  </Location>

Перезапустите сервер (/etc/init.d/apache2 restart) и посмотрите, насколько быстрее стали работать скрипты :)

Загрузка модулей
Продолжим. Давайте напишем код, который Apache мог бы использовать в процессе обработки страницы и пересылки ее клиенту. Нам необходимо разместить этот код так, чтобы встроенный интерпретатор смог загрузить его. По умолчанию в путь для поиска уже включены большинство системных директорий, но я считаю, что имеет смысл расположить его в очевидном месте :) /etc/apache2/perl Для добавления директории в путь поиска добавьте следующую директиву в /etc/apache2/conf/00-mod-perl

#
# Load the startup script
#
PerlRequire /etc/apache2/perl/startup.pl

Теперь при старте севера будет запускаться указанный скрипт. Давайте создадим его и поместим туда вот такой код

#
# Add /etc/apache2/perl to the mod_perl search path.
#
use lib qw( /etc/apache2/perl );

#
# This script had no errors (?!)
#
1;

После перезапуска сервера путь для поиска будет обновлен и будет включать в себя нужную нам директорию.

Сделаем что-то полезное?
Очень часто я вижу на своих проектах “пауков”, которые методично обшаривают страницу за страницей, качая содержимое. Вообщем я не возражаю против “зеркалирования” своих сайтов, но пока это все происходит незаметно для меня, в один поток и без съедания львиной доли ресурсов. А плохие “пауки” очень часто делают запросы, подобные следующим:

1.2.3.4 - [30/Apr/2009:19:36:29 +0100] “GET /articles/535#comment_2 HTTP/1.0″
1.2.3.4 - [30/Apr/2009:19:36:30 +0100] “GET /articles/535#comment_3 HTTP/1.0″
1.2.3.4 - [30/Apr/2009:19:36:30 +0100] “GET /articles/535#comment_5 HTTP/1.0″
1.2.3.4 - [30/Apr/2009:19:36:31 +0100] “GET /articles/535#comment_4 HTTP/1.0″

Т.е. по якорям методично и многократно вытягивают одну и туже страницу, съедая ресурсы и трафик. Чтоже делать, будем их ловить с помощью вот такого модуля на Perl: DropClients
Это сценарий на Perl, который обрабатывается mod_perl. Он выполняется для каждого входящего запроса и делает следующее:

• Выделяет из запроса IP-адрес и User-Agent
• Если UA и IP - “плохие”, то отклоняет запрос
• В нашем случае запрос отклоняется и тогда, когда в нем содержится “#”

Если все хорошо, то запрос проходит

Чтобы запустить этот сценарий мы должны

1. Загрузить его
2. И заставить его выполняться :)

Сохраним модуль как /etc/apache2/perl/DropClients.pm и создадим файл /etc/apache2/conf/dropclients со следующим содержимым:

#
# Load the module
#
PerlModule DropClients

#
# Ensure it is invoked as an access handler
#
<Location />
PerlAccessHandler DropClients
</Location>

После перезапуска метод DropClients::request() будет выполняться для каждого входящего запроса и нежелательные запросы будут отклоняться.

Нормальный запрос

user@notebook:~$ echo -e “GET / HTTP/1.0\n” | nc lenny 80 |grep ^HTTP
HTTP/1.1 200 OK

“Плохой” запрос

user@notebook:~$ echo -e “GET /#foo HTTP/1.0\n” | nc lenny 80 |grep ^HTTP
HTTP/1.1 403 Forbidden

Поскольку мы только что сделали “плохой” запрос, дальнейший доступ к серверу будет закрыт

user@notebook:~$ echo -e “GET / HTTP/1.0\n” | nc lenny 80 |grep ^HTTP
HTTP/1.1 403 Forbidden

Если заглянете в код модуля, то увидите, что эта блокировка очень просто и снимается командой rm -rf /tmp/blah

Различные типы обработчиков
Для нашего модуля мы использовали обработчик PerlAccessHandler, который запускал скрипт при входящих соединениях. Но это лишь один из многих типов обработчиков. Есть также, например:

• PerlResponseHandler - запускает сценарий после прохождения запроса
• PerlOutputFilterHandler - позволяет выполнить фильтрацию контента, отдаваемого пользователю (заменить слова, добавить футер… Сфера применения ограничена лишь вашей фантазией)

Полный список обработчиков доступен в документации к mod_perl и здесь Там же можно найти и примеры кода