Журнал LinuxFormat - перейти на главную

LXF90:Apache

Материал из Linuxformat
Версия от 18:22, 26 марта 2008; Human (обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск
Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)

Содержание

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

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

(thumbnail)
«Моя маман говаривала, что 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: квоты для виртуальных серверов

(thumbnail)
На странице статуса 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 автоматически «душит» канал.

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

Модуль 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, чтобы тот указывал на другое место – пользователь и не заметит, что произошло.

(thumbnail)
Работая с 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, и неаккуратные правила потребуют довольно интенсивной работы процессора!

(thumbnail)
Использование файлов .htaccess для свежесоставленных правил mod_rewrite позволит не перезапускать Apache при каждом мелком изменении.
Опытные пользователи могут добавить себе через условия mod_rewrite большей мощности. Например, если ваш сайт размещает множество изображений, и вы не хотите, чтобы другие сайты высасывали ваш трафик, устанавливая ссылки непосредственно на ваш сервер, вы можете использовать что-нибудь наподобие 
  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

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF90:Apache&oldid=3494»
Персональные инструменты
купить
подписаться
Яндекс.Метрика