Human: Новая: == Перышки вам в шляпу == ''Решили научить свой сервер Apache новым трюкам? Узнайте у '''Пола Хадсона''' про тр...

Human — Wed, 26 Mar 2008 15:22:08 GMT

Новая: == Перышки вам в шляпу == ''Решили научить свой сервер Apache новым трюкам? Узнайте у '''Пола Хадсона''' про тр...

Новая статья

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

[[Изображение:LXF-Apache-1.png|thumb|«Моя маман говаривала, что 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: квоты для виртуальных серверов ==

[[Изображение:LXF90-Apache-2.png|thumb|На странице статуса 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''' автоматически «душит» канал.

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

{{Врезка|right|Ширина=300px
|Заголовок=Как установить модуль
|Содержание=Каждый из рассматриваемых здесь модулей доступен через ''Synaptic'', если подключены репозитории Universe и Multiverse. Процесс активации установленных модулей полностью выполняется из командной строки: получите права root, перейдите в '''/etc/apache2''' и выполните эту команду:

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

Создастся символьная ссылка на активируемый модуль, так что для его запрета просто удалите файл-ссылку из '''mods-enabled'''. Активировав все модули, какие вы хотели, выполните команду '''apache2ctl restart''', чтобы Apache перезапустился и изменения вступили в силу. Перезапускать Apache нужно при каждом изменении конфигурации согласно этому описанию.}}
Модуль '''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 динамически ==

{{Врезка|right|Ширина=300px
|Заголовок=Почему mod_access есть зло?
|Содержание=Временно разрешать '''mod_access''', работая с '''mod_rewrite''', вполне нормально, поскольку это значительно снижает суммарное время отладки ваших регулярных выражений. Но закончив, сразу же запретите переопределение настроек, чтобы '''mod_access''' был капитально пресечен. Дело это хорошее, потому что '''mod_access''' спроектирован для поиска опций, которые следует установить в ваших каталогах, в файлах '''.htaccess'''. На вид безвредно, но представьте: если ваш каталог '''/foo''' требует пароль, как ''Apache'' догадается, что нужно спросить пароль, когда пользователь полезет в '''/foo/bar/baz.php'''?

Ответ заключается в том, что ''Apache'' просматривает .htaccess-файлы в запрошенном каталоге, а также во всех родительских каталогах, вплоть до корня вашей файловой системы. Так, в приведенном выше примере ''Apache'' ищет (и читает, если найдет) следующие файлы:
* /var/www/foo/bar/.htaccess
* /var/www/foo/.htaccess
* /var/www/.htaccess
* /var/.htaccess
* /.htaccess
...на что уходит уйма времени. Отключите это и используйте ваш процессор в полезных целях!}}
Всякий мастер-класс ''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, чтобы тот указывал на другое место – пользователь и не заметит, что произошло.

[[Изображение:LXF90-Apache-3.png|thumb|Работая с '''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
<nowiki>RewiteRule shortcut/([A-Za-z0-9]*) /foo/bar/baz/wobmat/$1</nowiki>

Правило '''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.

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

{{Врезка|right|Ширина=300px
|Заголовок=Идем дальше
|Содержание=Если вы проработали каждый из этих модулей, вот еще три рекомендации на пробу:
* '''mod_dnssd''' Публикует ваш сайт, используя протокол обнаружения сети Apple Bonjour.
* '''mod_musicindex''' Позволяет всему миру листать вашу музыкальную коллекцию, а также и прослушивать ее.
* '''mod_mono''' Apache встречается с Mono... Разместите C# на своем сервере и запускайте ASP.NET через Apache.
Итак, какой модуль Apache ваш любимый? У вас есть трюк с '''mod_rewrite''', который вам особо по душе? Напишите нам, а лучший мы опубликуем! letters@linuxformat.ru.}}
Не будем заострять внимание, но ваши правила перезаписи вряд ли заработают с первого раза. Обычно требуется не одна попытка, и вы, скорее всего, добьетесь их правильности, лишь вволю наскрежетавшись зубами. Так что, добавляя новые правила, вы можете предпочесть положиться (временно!) на файлы .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''' поможет горю, например, таким образом:

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

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

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

[[Изображение:LXF90-Apache-4.png|thumb|Использование файлов .htaccess для свежесоставленных правил mod_rewrite позволит
не перезапускать Apache при каждом мелком изменении.]]Опытные пользователи могут добавить себе через условия '''mod_rewrite''' большей мощности. Например, если ваш сайт размещает множество изображений, и вы не хотите, чтобы другие сайты высасывали ваш трафик, устанавливая ссылки непосредственно на ваш сервер, вы можете использовать что-нибудь наподобие
<nowiki>
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://www.yoursite.com/.*$
RewriteRule \.(jpg|png)$ - [F]
</nowiki>
Здесь три важных строки. Первая проверяет, не равен ли referrer значению '''^$''' – т.е. пустой строке. Учтите, что «referrer» пишется здесь с одной ‘r’ ('''HTTP_REFERER''') из-за исторической опечатки. Если первая проверка проходит, то выполняется вторая: не совпадает ли referrer с именем нашего сайта? Это вторая строка кода. Символы .* в конце означают «соответствует всему», так что будет совпадение с любым URL, размещенным на нашем сайте. Наконец, если обе строки '''RewriteCond''' выполняются, срабатывает строка '''RewriteRule'''. Она отбирает JPEG- и PNG-файлы и перезаписывает их в – '''<nowiki>[F]</nowiki>''', так в '''mod_rewrite''' сокращенно обозначено нечто невежливое вроде «запрещено – вали отсюда!».

Мы могли бы усовершенствовать второе rewrite-условие, добавив '''<nowiki>[NC]</nowiki>''' в конец этой строки, что велит ''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) – это гарантированное узкое место производительности. [http://www.linuxformat.ru LXF]

LXF90:Apache - История изменений

Human: Новая: == Перышки вам в шляпу == ''Решили научить свой сервер Apache новым трюкам? Узнайте у '''Пола Хадсона''' про тр...