LXF90:Apache

Материал из Linuxformat.

Перышки вам в шляпу

Решили научить свой сервер Apache новым трюкам? Узнайте у Пола Хадсона про три его любимых модуля Apache для web-суперобслуживания.

«Моя маман говаривала, что Synaptic похож на коробку шоколада» – модули с какой начинкой вы предпочтете?

Приспособить Apache для обслуживания web-страниц может каждый, а при известной сноровке можно установить и использовать mod_php или mod_perl, но Apache способен на большее. Стандартная установка Ubuntu Edgy (с подключенными репозиториями Universe и Multiverse) дает перечень свыше сорока модулей Apache 2, с которыми ваш сервер Apache натворит такого, чего вы и представить не могли.

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

mod_userdir: Домашние страницы – народу!

Дистрибутивы, основанные на Debian, стандартно используют виртуальный хостинг, он превосходен для настройки большого числа сайтов на коммерческой основе. А если вы просто хотите выделить своим друзьям местечко на вашем сервере? Лучший способ сделать это – модуль mod_userdir, дающий каждому пользователю с учетной записью на вашем сервере возможность размещать свой собственный контент.

Откройте файл конфигурации /etc/Apache2/sites-available/default в текстовом редакторе (как суперпользователь) и добавьте такую строку:

UserDir public_html

Пользователи теперь смогут создавать подкаталог public_html в своем домашнем каталоге и получать к нему доступ по адресу http://www.yoursite.com/~username. У кого не будет каталога public_html, тот не будет представлен в Интернете – при попытке зайти на его страничку возникнет ошибка 404.

Для определения полного пути, например, /var/www, можно использовать директиву UserDir: в этом случае http://www.yoursite.com/~hudzilla будет искать страницы в /var/www/hudzilla. Но в принципе, лучше оставить ее в домашнем каталоге пользователя, так как это упрощает настройку прав доступа – пользователи смогут создавать и удалять свой собственный контент в public_html без вашего содействия. Вы можете также использовать директиву UserDir, чтобы разрешать или запрещать работу модуля mod_userdir пользователям индивидуально. Например, сейчас каждый может публиковать пользовательские данные в личном web-пространстве, даже root – зайдите на http://www.yousite.com/~root, и поймете, что мы имеем в виду.

Как правило, разумнее пресечь подобный доступ, так что добавьте в конфигурацию такую строку:

UserDir disabled root

Здесь можно указать столько пользователей, сколько хотите. Вариант – настроить «белый список» mod_userdir, запретив доступ всем и разрешив только тем, кому нужно:

UserDir disabled
UserDir enabled bill ted

mod_cband: квоты для виртуальных серверов

На странице статуса mod_cband дана детальная информация по всем квотам и ограничениям, но уж больно крошечным шрифтом!

Некоторые модули Apache могут ограничивать использование канала во времени; некоторые – ограничивать число запросов, обслуживаемое доменом в секунду; а некоторые накладывают постоянное ограничение на исходящий трафик вашего сервера. Второй из нашего трио модулей, mod_cband, делает все это и даже больше – что сокращает время обучения, упрощает долгосрочное администрирование и снижает требования к ресурсам вашего сервера.

Для тестирования модуля создайте текстовый файл побольше, этак на 16 МБ, набитый абракадаброй, в каталоге /var/www. Простейший способ это сделать – ввести команду

sudo dd if=/dev/urandom of=/var/www/myfile bs=16M count=1

Прежде чем применять ограничения, скоренько проверим, читается ли этот файл. Запустите wget http://localhost/myfile, и он должен загрузиться в текущий каталог. Обратите внимание на скорость, которой достигнет wget – наша составила 44,15 Мбит/сек, для локального файла нормально.

Откройте /etc/Apache2/sites-available/default как root в любимом текстовом редакторе и взгляните на директиву DocumentRoot. Она будет установлена в /var/www – нам того и надо, только добавим еще две строки прямо под ней:

ServerName localhost
CBandSpeed 1024 5 30

Именно в строке CBandSpeed и происходит самое интересное: она ограничивает наш сервер до 1024 Кбит/сек, при максимуме в 5 запросов в секунду и 30 одновременно открытых соединений. Если вы теперь запустите wget (файл конфигурации не закрывайте – он скоро вам снова понадобится), то увидите изрядное снижение скорости, поскольку mod_cband автоматически «душит» канал.

Ограничение использования за период

ln -s mods-available/somemod.so mods-enabled/

Модуль mod_cband вполне способен распределять ограничение ширины канала сайта во времени. Находясь в /var/www, запустите для начала следующие две команды:

sudo mkdir scoreboard
sudo chown www-data scoreboard

mod_cband будет хранить информацию о суммарном трафике, использованном каждым сайтом, в каталоге scoreboard, так что он должен быть доступен на запись пользователю, с правами которого работает Apache (www-data). Вернувшись в файл конфигурации, добавьте следующие четыре строки:

CBandLimit 40M
CBandScoreboard /var/www/scoreboard
CBandExceededURL http://www.linuxformat.co.uk
CBandPeriod 1M

Если вы точно следовали нашим инструкциям, то обнаружите, что при запуске команды wget никакой разницы не наблюдается. Фактически, вы можете запустить ее трижды и ничего не увидеть. Что же изменилось? А магия-то начинается с четвертой попытки: вы обнаружите, что wget не скачает файл myfile по новой, а перейдет на http://www.linuxformat.co.uk. Наш файл имеет размер 16 МБ, а директива CBandLimit настроена на запрет доступа после достижения предела в 40 МБ. Так что первое скачивание работает, поскольку уже скачано 0 МБ, второе работает, поскольку скачано 16 МБ (размер первой закачки), третье скачивание тоже работает, потому что скачано 32 МБ (сумма двух первых закачек), а вот четвертая и последующая закачки завершатся неудачей, поскольку к тому времени будет скачано уже 48 МБ, что на 8 МБ превышает лимит для вашего сайта.

Тут в дело вступает директива CBandExceededURL: как только будет достигнут предел трафика, любые запросы, поступающие в наш домен, автоматически перенаправятся на http://www.linuxformat.co.uk. Примечание: если вы попробуете это дома, то, мы уверены, осчастливите Майка, администратора сайта Команды LXF, увеличив посещаемость его детища! Хотя вы, видимо, захотите сослаться на какую-нибудь другую страницу, разъясняющую, что был превышен лимит трафика, и как можно докупить еще.

Наконец, директива CBandPeriod – это суммарное время между сбросами счетчиков трафика. Мы указали 1M, то есть каждую минуту счетчик использования трафика нашего локального сайта будет сбрасываться на ноль, и пользователи смогут скачать следующие 40 МБ контента. Да, mod_cband использует M и для мегабайтов, и для минут, но это единственная реальная накладка. Для скоростей закачки можно также использовать K и G (если у вас действительно быстрый интернетканал!), а для периодов времени можно использовать S (секунды), H (часы), D (дни), и W (недели).

Есть две альтернативы директиве CBandExceededURL. Одна – полностью удалить эту строку, тогда mod_cband будет выдавать сообщение об ошибке HTTP 503 «Сервис временно недоступен». А можно применить директиву CBandExceededSpeed, она переопределяет CBandSpeed в случае превышения лимита трафика. Например, вы хотите, чтобы сайт поддерживал 1024 Кбит/сек, пока не будет достигнут порог в 5 ГБ, а затем – лишь 128 Кбит/сек до конца месяца. Вот как это можно сделать:

CBandSpeed 1024 5 30
CBandLimit 5G
CBandScoreboard /var/www/scoreboard
CBandExceededSpeed 128 5 30
CBandPeriod 4W

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

Отчеты о состоянии

Можете проверять состояние mod_cband в любое время, используя особое место на вашем сайте. Допустим, вы хотите разрешить пользователям просматривать свои лимиты и узнавать, сколько уже выбрано. Отредактируйте файл конфигурации таким образом:

 <Location /bandwidth-status>
  SetHandler cband-status-me
 </Location>

Вы можете теперь зайти на http://localhost/bandwidth-status, да и любой тоже может – советуем установить пароль на каталог, чтобы сюда попадали только свои люди.

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

 <Location /bandwidth-status>
   SetHandler cband-status
</Location>

mod_rewrite: Перезапись URL динамически

Всякий мастер-класс Linux Format был бы неполон без разборки регулярных выражений, и данный – не исключение. Модуль Apache mod_rewrite придуман для проверки на соответствие строк запросов и их изменения на лету. Очень популярно использовать mod_rewrite для сокращения длинных URL, чтобы их легче было запоминать и набирать. Например, если вы хотите, чтобы www.example.com/shortcut молча перенаправлялся на www.example.com/foo/bar/baz/wombat, воспользуйтесь mod_rewrite.

Тут вы, верно, подивитесь: а чем отличается mod_rewrite от отсылки HTTP-заголовка Location для перенаправления браузера? Действительно, разница невелика: оба переключают один URL на другой. Однако mod_rewrite в общем удобнее для пользователя, поскольку заголовок Location говорит браузеру прекратить загрузку текущей страницы и вместо этого загрузить другой URL, а mod_rewrite ничего клиенту не сообщает, просто молча переписывает URL, чтобы тот указывал на другое место – пользователь и не заметит, что произошло.

Работая с mod_rewrite, знайте, что «Internal Server Error» на языке Apache значит «напортачил ты в регулярном выражении, балда!»

Иначе говоря, mod_rewrite делает то же, что и Location, только прозрачно для конечного пользователя. Единственная издержка использования mod_rewrite – процессорное время, потому что Apache проверяет каждый входящий запрос на соответствие имеющемуся списку правил перезаписи, но это влияние довольно незначительно.

Итак, возвращаясь к примеру, где www.example.com/shortcut должен молча превратиться в www.example.com/foo/bar/baz/wombat – вот как это можно сделать с помощью mod_rewrite:

RewriteEngine On
RewiteRule shortcut/([A-Za-z0-9]*) /foo/bar/baz/wobmat/$1

Правило mod_rewrite имеет пять важных моментов:

• Запрос на www.yoursite.com/shortcut покажет содержимое каталога www.yoursite.com/foo/bar/baz/wombat.
• Запрос на www.yoursite.com/shortcut/hello отобразит файл www.yoursite.com/foo/bar/baz/wombat/hello.
• Фрагмент $1 ссылается на группу регулярного выражения (часть, заключенная в скобки) и использует ее в перезаписываемом URL.
• Пользователь и не заподозрит, что просматривает /foo/bar/baz/wombat, а не /shortcut – Apache все делает тишком.
• Каталог /foo/bar/baz/wombat по-прежнему доступен напрямую.

Теперь вы видите, чем хороша прозрачность: все, что соответствует URL www.yoursite.com/shortcut, будет автоматически перезаписано. Немного изменив правило (предусмотрев символы /, ., = и &), вы даже сможете перезаписывать целые URL, преобразуя www.yoursite.com/shortcut/gubbins/foo.php?bar=baz в www.yoursite.com/foo/bar/baz/wombat/gubbins/foo.php?bar=baz.

Перезапись – углубленно

Не будем заострять внимание, но ваши правила перезаписи вряд ли заработают с первого раза. Обычно требуется не одна попытка, и вы, скорее всего, добьетесь их правильности, лишь вволю наскрежетавшись зубами. Так что, добавляя новые правила, вы можете предпочесть положиться (временно!) на файлы .htaccess: они временно изменяют установки конфигурации Apache для конкретного каталога. Чтобы разрешить использование файлов .htaccess, загляните в конфигурацию Apache (ту, что мы уже используем), и для каталога /var/www измените ‘AllowOverride None’ на ‘AllowOverride All’. Перезапустите Apache, и файлы .htaccess готовы к работе!

Пора попробовать что-нибудь поинтереснее. Да, укорочение длинного URL – типовое применение mod_rewrite, но еще популярнее приведение уродских URL к виду, простому для запоминания. Например, www.yoursite.com/index.php?Section=Bugs&User=Hudzilla – URL ужасный, а www.yoursite.com/users/hudzilla/bugs и запомнить легче, и для глаза приятнее! mod_rewrite поможет горю, например, таким образом:

 RewriteRule ^users/([A-Za-z0-9_])+/bugs$ index.php?Section=bugs&User=$1

Символы ^ и $ означают «начало строки запроса» и «конец строки запроса» соответственно, они избавят Apache от обработки чего-то типа www.yoursite.com/users/hudzilla/bugs/monkeybutts.

Использование точных правил очень полезно, когда нужно проверять соответствие множества различных вещей. Например, вам может потребоваться загружать страницу поиска пользователя, когда на www.yoursite.com/users зайдет посетитель, а значит, строка RewriteRule должна явно игнорировать все, что добавляет имя пользователя в конец запроса. Можете написать столько строк RewriteRule, сколько потребуется, но помните, что Apache прогоняет каждый запрос через каждую из строк RewriteRule, и неаккуратные правила потребуют довольно интенсивной работы процессора!

Использование файлов .htaccess для свежесоставленных правил mod_rewrite позволит не перезапускать Apache при каждом мелком изменении.

  RewriteEngine on
  RewriteCond %{HTTP_REFERER} !^$
  RewriteCond %{HTTP_REFERER} !^http://www.yoursite.com/.*$
  RewriteRule \.(jpg|png)$ - [F]
 

Здесь три важных строки. Первая проверяет, не равен ли referrer значению ^$ – т.е. пустой строке. Учтите, что «referrer» пишется здесь с одной ‘r’ (HTTP_REFERER) из-за исторической опечатки. Если первая проверка проходит, то выполняется вторая: не совпадает ли referrer с именем нашего сайта? Это вторая строка кода. Символы .* в конце означают «соответствует всему», так что будет совпадение с любым URL, размещенным на нашем сайте. Наконец, если обе строки RewriteCond выполняются, срабатывает строка RewriteRule. Она отбирает JPEG- и PNG-файлы и перезаписывает их в – [F], так в mod_rewrite сокращенно обозначено нечто невежливое вроде «запрещено – вали отсюда!».

Мы могли бы усовершенствовать второе rewrite-условие, добавив [NC] в конец этой строки, что велит Apache игнорировать регистр символов в запросе, рассматривая www.YOURSITE.com и www.yoursite.com как один и тот же путь.

Если вы озверели от безуспешной борьбы с mod_rewrite, можете либо расслабиться, глубоко вдохнуть и попробовать снова, либо поступить как все: взреветь от ярости и пнуть свой компьютер через всю комнату. Но что бы вы ни сделали, утешайтесь фактом, что проблемы бывают даже у профи. Брайан Белендорф [Brian Behlendorf], основатель Apache Software Foundation, как-то сказал: «mod_rewrite замечателен тем, что дает вам всю настраиваемость и гибкость Sendmail. Оборотная сторона медали – он дает вам всю настраиваемость и гибкость Sendmail.» Будьте упорны, и все получится!

Учтите: как только вы закончите с mod_rewrite, советуем изменить ‘AllowOverride All’ обратно на ‘AllowOverride None’: mod_access (модуль, который работает с файлами .htaccess) – это гарантированное узкое место производительности. LXF