Примечания при обновлении Apache 2.2 до Apache 2.4

На сегодняшний день Apache является самым популярным веб-сервером благодаря своей гибкости и производительности.

Многие пользователи знакомы с синтаксисом конфигурационных файлов Apache 2.2, но некоторые дистрибутивы поставляются с Apache 2.4 по умолчанию (например, Ubuntu 14.04 LTS). В большинстве случаев синтаксис Apache 2.2 и Apache 2.4 совпадает, однако у них есть несколько существенных отличий.

Данное руководство расскажет об этих отличиях, о некоторых устаревших директивах и остальных изменениях в синтаксисе Apache. Для демонстрации примеров используется Ubuntu 14.04 (дистрибутив, поставляемый с Apache 2.4 по умолчанию) и Ubuntu 12.04 (Apache 2.2).

Настройки авторизации

Одним из главных отличий синтаксиса Apache 2.4 является способ авторизации пользователей.

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

Этим авторизация отличается от аутентификации (которая происходит сначала). Процедура аутентификации определяет, как пользователь распознаётся на сервере. Аутентификация в Apache 2.2 и 2.4 почти не изменилась, чего нельзя сказать о процедуре авторизации.

Во-первых, в Apache 2.4 компоненты авторизации могут использовать синтаксис Require, ранее доступный для аутентификации. Это позволяет определить порядок авторизации, не полагаясь на сложный набор правил. Теперь вы можете настроить процесс авторизации, указав настройки по умолчанию, а затем исключения из них.

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

Require all granted
Require not ip 111.111.111.111

Это установит стандартную политику приёма всего трафика, исключив из неё заведомо вредоносный IP-адрес 111.111.111.111. Чтобы эти настройки работали, нужно включить их при помощи блока директив RequireAll.

Авторизация может происходить не только на основе данных о пользователе или группе, но и руководствуясь такими факторами, как env, host, ip и all.

  • all: пропускает весь трафик, подходит для настроек по умолчанию.
  • env: проверяет, установлены ли переменные окружения.
  • host: проверяет имя хоста подключающегося клиента.
  • ip: проверяет IP-адрес подключающегося пользователя.

Трафик будет проверяться по этим факторам в зависимости от их порядка в конфигурации сервера. Как правило, эти настройки находятся в следующих блоках:

  • RequireAll: для получения доступа должны быть выполнены все без исключения требования авторизации.
  • RequireAny: для получения доступа должно быть выполнено хотя бы одно требование, заданное в данном блоке настроек.
  • RequireNone: для получения доступа трафик не должен соответствовать заданным требованиям авторизации.

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

<RequireAny>
<RequireAll>
Require user root
Require ip 123.123.123.123
</RequireAll>
<RequireAll>
<RequireAny>
Require group sysadmins
Require group useraccounts
Require user anthony
</RequireAny>
<RequireNone>
Require group restrictedadmin
Require host bad.host.com
</RequireNone>
</RequireAll>
</RequireAny>

Таким образом Apache позволяет настроить тщательно продуманные пути авторизации. Вышеприведённый код авторизует пользователя, если он – root и его IP-адрес 123.123.123.123, а также пользователей по имени anthony и состоящих в группах sysadmins и useraccounts. Пользователи, которые состоят в группе restrictedadmin или чьё имя хоста отмечено на bad.host.com, не будут авторизованы.

Такие блоки настроек авторизации гораздо проще понять, чем стандартные директивы для управления доступом; как помните, в предыдущих версиях Apache для этого использовались директивы Order, Allow from, Deny from и Satisfy. Они всё ещё могут быть использованы в конфигурациях, но по сравнению с новым, более понятным синтаксисом они устарели.

Эти директивы перемещены в отдельный блок по имени mod_access_compat, потому его нужно включить, чтобы получить доступ к ним. Конечно, лучше всё-таки пользоваться новыми возможностями синтаксиса, поскольку они позволяют определить гораздо более гибкую политику.

Другие изменения в синтаксисе Apache

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

Некоторые из них требуют изменить имена или переопределить новые значения по умолчанию. Более полный список изменений можно найти здесь; данный раздел охватывает только наиболее сложные из них.

Подключения и ограничения дочерних процессов

Некоторые директивы были переименованы, чтобы лучше описать их функциональность.

  • MaxConnectionsPerChild используется для замены MaxRequestsPerChild. Новое имя директивы гораздо лучше описывает её предназначение, поскольку директива позволяет ограничить количество соединений (а не запросов).
  • Директива MaxClients заменила MaxRequestWorkers. При использовании асинхронных многопроцессорных модулей количество клиентов не должно совпадать с количеством рабочих потоков. Это помогает более точно определить часть конфигурации, которая зависит от этой директивы.

Изменения AllowOverride

Директива AllowOverride, которая разрешает определённым конфигурационным файлам переопределять настройки по умолчанию, претерпела небольшие изменения, которые могут повлиять на конфигурации.

Теперь по умолчанию значение этой директивы None, что позволяет защитить сервер от случайного переопределения настроек. Настройка файлов .htaccess, которые должны быть прочитаны и обработаны в определённых каталогах, по-прежнему проста, но теперь требует меньше глобальных и общедоступных объявлений AllowOverride None.

Такая стратегия (блокировка сервера по умолчанию и дальнейшее переопределение настроек) используется большинством пользователей. Это позволяет предотвратить некоторые атаки, поскольку многие забывают блокировать эту директиву вручную.

Изменения в SendFile

Директива EnableSendfile, которая отправляет файлы сервера клиенту без необходимости читать их, теперь по умолчанию имеет значение Off.

Эта мера безопасности используется для того, чтобы система корректно поддерживала операции. Неправильное выполнение некоторых операций может привести к сбоям и ошибкам. Они могут зависеть от системы, от конкретного оборудования или от способа доступа к контенту (удаленные файловые системы и т.д.).

Отключение этой директивы по умолчанию позволяет администратору предварительно убедиться в совместимости систем.

Детали реализации

Некоторые стандартные конфигурационные файлы дистрибутивов были изменены во время перехода.

В дистрибутивах Debian и Ubuntu главный конфигурационный файл Apache 2.4 (/etc/apache2/apache2.conf) теперь немного иначе обрабатывает дополнительные файлы.

В Apache 2.2 эти дистрибутивы использовали файлы conf.d и sites-enabled для поддержки дополнительных конфигурационных файлов (как правило, это нужно для настройки виртуальных хостов). Эти директивы выглядят так:

Include conf.d/
Include sites-enabled/

Сопоставление с безразличным символом (англ. wildcard matching) – новая функция, позволяющая включать определенные шаблоны файлов вместо передачи каталога в полном объеме.

То есть, вместо вышеприведённых настроек можно использовать следующее:

Include conf.d/*.conf
Include sites-enabled/*.conf

Однако этот новый синтаксис может вызвать проблемы, поскольку он не работает так, как предыдущий. Директива Include, используемая с сопоставлением с безразличным символом, не сработает и вызовет ошибку, если файл для сопоставления не найден.

Чтобы обойти это поведение, существует директива IncludeOptional, которая работает точно так же, но не выдаст ошибки, если не найдёт подходящий файл.

Для этого многие дистрибутивы начали использовать дополнительные каталоги:

IncludeOptional conf-enabled/*.conf
IncludeOptional sites-enabled/*.conf

Как видите, здесь используется дополнительная отладка: создание отдельных каталогов conf-enabled и conf-available, отражающих каталоги sites-* и mods-*. В этой настройке все действительные конфигурационные файлы должны закончиться расширением .conf.

К этому придётся привыкнуть, если вы обычно называете файлы  виртуальных хостов default, site1.com и т.п. Однако такой метод работы делает конфигурации более гибкими, поскольку теперь в конфигурационных каталогах можно хранить другие файлы (например, разные версии конфигураций, тестовые настройки, README и т.д.).

То есть, для тестирования можно просто использовать:

cd /etc/apache2/sites-enabled/
cp mainconfig.conf mainconfig.conf.bak
nano mainconfig.conf

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

Также вы могли заметить, что некоторые директивы были перемещены, а некоторые директивы виртуальных хостов изменились. Теперь файлы виртуальных хостов больше не содержат следующих трёх блоков:

<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>

Первые два блока теперь находятся в файле apache2.conf и обновлены до директив Require:

<Directory />
Options FollowSymLinks
AllowOverride None
Require all denied
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>

Определение каталога cig-bin было удалено из файла виртуальных хостов и реализовано в файле conf-available/serve-cgi-bin.conf. Теперь эти файлы отвечают только за уникальные директивы.

Новые раскомментированные файлы виртуальных хостов выглядят так:

<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Как видите, такой подход позволяет значительно сократить некоторые конфигурации.

В целом же, учитывая все обновления процедур, новые директивы и улучшенные методы, переход на Apache 2.4 не так уж сложен. Функционально он несколько лучше, чем Apache 2.2, поскольку предоставляет широкий ряд дополнительных функций и использует более простой синтаксис.

Tags: , , ,

1 комментарий

Добавить комментарий для Алексей Отменить ответ