Поиск по сайту:

Как перенести конфигурацию Apache с версии 2.2 на синтаксис версии 2.4.

Введение

Веб-сервер Apache в настоящее время является самым популярным веб-сервером в мире. Он используется для обслуживания веб-контента всех видов и представляет собой мощное приложение с широкими возможностями настройки.

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

В этом руководстве мы обсудим некоторые из нового синтаксиса и некоторые другие изменения, о которых вам следует знать, когда вы переходите с фона Apache 2.2. Мы будем использовать Ubuntu 14.04 в качестве примера дистрибутива с Apache 2.4 и сравнить его с версией Apache 2.2, которая поставляется с такими выпусками, как Ubuntu 12.04.

Изменения авторизации

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

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

Это отличается от аутентификации, которая должна произойти в первую очередь. Процедуры аутентификации определяют, как пользователь может идентифицировать себя на сервере. Аутентификация не сильно изменилась по сравнению с 2.2, а авторизация претерпела значительные изменения.

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

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

Require all granted
Require not ip 111.111.111.111

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

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

  • все: этот провайдер сопоставляет весь трафик. Это полезно для установки значений по умолчанию.
  • env: проверяет, установлена ли переменная окружения.
  • хост: используется для проверки имени хоста подключающегося клиента.
  • 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>

Как видите, мы можем определить довольно сложные пути авторизации. В приведенном выше примере авторизация будет выполнена, если пользователь является пользователем root и исходит с IP-адреса 123.123.123.123. Это также будет авторизовать пользователя с именем \anthony или любых членов групп \sysadmins или \useraccounts, но ТОЛЬКО если они не являются частью группы \restrictedadmin или приходят с помеченного хоста в bad.host.com.

Эти блоки аутентификации гораздо проще понять, чем классические директивы, которые использовались для управления доступом. В предыдущих версиях Apache вы должны были использовать директивы Order, Allow from, Deny from и Satisfy. Они не были удалены, но устарели в пользу нового синтаксиса, который легче понять и более последователен.

Однако они были перемещены в отдельный модуль под названием mod_access_compat. Убедитесь, что вы включили этот модуль, если вам требуются устаревшие директивы авторизации. Тем не менее, я бы предложил реализовать ваши условия в новом синтаксисе, как для будущей поддержки, так и потому, что значительно проще понять последствия выбранных вами политик.

Другие изменения в Apache

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

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

Соединение и ограничение детей

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

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

Разрешить переопределение изменений

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

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

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

Значение по умолчанию SendFile изменено

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

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

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

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

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

Один из примеров этого — в выпусках Debian и Ubuntu, основной файл конфигурации Apache 2.4 в /etc/apache2/apache2.conf теперь обрабатывает включение дополнительных файлов немного по-другому.

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

Include conf.d/
Include sites-enabled/

Сопоставление с подстановочными знаками — это новая функция, которая позволяет вам включать определенные шаблоны файлов вместо того, чтобы передавать весь каталог целиком. Это означает, что, хотя традиционно вы могли бы обойтись чем-то вроде приведенного выше, вы могли бы иметь больше гибкости, используя:

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

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

Чтобы обойти это, была создана новая директива IncludeOptional. Это работает точно так же, но не приведет к сбою, если подстановочный знак не соответствует ни одному файлу.

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

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

Как видите, здесь добавлена дополнительная настройка реализации: создание отдельных каталогов conf-enabled и conf-available для зеркалирования сайтов. -* и 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 в последних версиях Ubuntu, поскольку они должны быть установлены в любой конфигурации. Они были обновлены для использования директив 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 не составит труда. Функционально он должен предоставлять те же возможности с дополнительными функциями и делать все это с более простым для понимания синтаксисом.

Джастин Эллингвуд