開発者ドキュメント

Apache構成を2.2から2.4構文に移行する方法。

getdocs

序章

Apache Webサーバーは、現在、世界で最も人気のあるWebサーバーです。 あらゆる種類のWebコンテンツを提供するために使用され、高度にカスタマイズ可能な強力なアプリケーションです。

多くの人がApache2.2構成構文に精通していますが、一部のディストリビューションは現在、デフォルトでApache2.4とともに出荷されています。 この移行の例は、Ubuntu12.04LTSからのUbuntu14.04LTSです。 ほとんどの場合、構文は同じですが、いくつかの重要な違いがあり、いくつかの一般的なディレクティブは非推奨になっています。

このガイドでは、Apache 2.2のバックグラウンドから取得するときに知っておく必要のある、いくつかの新しい構文とその他の変更について説明します。 Apache2.4を使用したディストリビューションの例としてUbuntu14.04を使用し、Ubuntu12.04などのリリースに同梱されているApacheの2.2バージョンと比較します。

承認の変更

Apache 2.4が行う主な変更の1つは、ユーザーを承認するための推奨される方法です。

承認とは、認証されたユーザーが実行できることを定義するディレクティブを指します。 操作またはアクセスを許可するかどうかを決定するための基準を示します。

これは、最初に行わなければならない認証とは異なります。 認証手順は、ユーザーがサーバーに対して自分自身を確実に識別できる方法を定義します。 認証は2.2からあまり変わっていませんが、承認は見直されています。

まず、認証コンポーネントで使用できるようになりました Require 以前に認証に使用できるようになった構文。 これにより、複雑なルールセットに依存するのではなく、承認順序を定義する簡単な方法が作成されます。 代わりに、デフォルトを指定してから例外を指定して、論理的な方法でそれらを並べ替えることができます。

たとえば、トラフィックを受け入れるためのデフォルトを設定できますが、特定の悪意のあるユーザーをブロックしたい場合は、次のようなものを追加できます。

Require all granted
Require not ip 111.111.111.111

これにより、全員を受け入れるというデフォルトのポリシーが設定され、リクエストがから来ていないという修飾子が指定されます。 111.111.111.111 IPアドレス。 これを行うには、これらの両方が真である必要があります。これは、 RequireAll ディレクティブブロック。

承認は、ユーザーまたはグループ自体に基づいて選択できるだけでなく、他の要素を考慮して選択することもできます。 env, host、 また ip、またはキャッチオール値を使用 all.

これらは、指定された順序に基づいて制御できます。 通常、これらは次の特別なブロックの1つの中に表示されます。

これにより、承認の設定方法に関してかなりの柔軟性が得られます。 これらのディレクティブブロックは、次のように相互にネストできます。

<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のその他の変更

構成ファイルの作成方法に影響を与えることに注意する必要のある他のさまざまな変更があります。

これらの中には、名前を変更したり、新しいデフォルトを上書きしたりする必要がある場合があります。 ここに変更の完全なリストがありますが、つまずく可能性のあるもののいくつかについて説明します。

接続と子の制限

いくつかのディレクティブは、それらの機能をよりよく説明するために名前が変更されました。

AllowOverrideの変更

The AllowOverride ディレクトリ固有の構成ファイルがデフォルト設定を変更できるようにするために使用されるディレクティブは、構成に影響を与える可能性のあるわずかな変更が加えられています。

デフォルトでは、この設定の値は現在 None. これにより、デフォルトでよりロックダウンされた状態になり、サーバーをより簡単に保護できるようになります。 それを指定するのはまだ非常に簡単です .htaccess ファイルは、それを必要とするディレクトリで読み取られて処理される必要がありますが、必要なグローバルで大規模なものは少なくて済みます。 AllowOverride None これを達成するための宣言。

デフォルトでサーバーをロックダウンし、セキュリティをオーバーライドしてディレクトリベースの設定の特定のインスタンスを許可するという戦略は、ほとんどのユーザーがすでに行っていることです。 この変更は、ユーザーがこれらを手動で実装するのを忘れた場合に、ユーザーが簡単に攻撃を受けないようにするためにのみ役立ちます。

SendFileのデフォルトが変更されました

The EnableSendfile 内容を読み取らずにサーバー上のファイルをクライアントに送信するために使用されるディレクティブがデフォルトで設定されるようになりました Off.

これは、問題のシステムが操作を正しくサポートすることを保証するために使用されるセキュリティ対策です。 誤った実装は責任を負うか、操作が失敗する原因となる可能性があります。 これらは、オペレーティングシステム固有、特定のハードウェアに依存する場合、またはコンテンツへのアクセス方法（リモートファイルシステムなど）によって異なる場合があります。

このディレクティブをデフォルトで無効にすると、管理者はシステムの互換性を確認し、有効にする前に適切な機能を確認するためのテストを行うことができます。

実装の詳細

これらはApache2.4リリースに正確に固有のものではありませんが、ディストリビューションに同梱されているデフォルトの構成ファイルの一部は、移行が行われたときに変更されています。

この一例は、DebianおよびUbuntuリリースにあります。Apache2.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

ただし、この新しい構文は、以前とまったく同じように機能することを期待している場合にも、いくつかの問題を引き起こす可能性があります。 The 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 操作、これは一部の人々にとってより自然かもしれない追加の方法です。 また、古い作業ファイルを有効なディレクトリに保持します。これは、正確には意味がありませんが、古いバージョンに戻す必要がある場合は、再実装するのが簡単な場合があります。

構成で気付く可能性のあるもう1つの変更は、一部のディレクティブが移動され、一部のデフォルトの仮想ホストディレクティブが変更されたことです。 以前はデフォルトの仮想ホストファイルにあったこれらの3つのブロックは、もう存在しません。

<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>

上位2つのブロックが 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>

The 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>

ご覧のとおり、これはサイト固有の構成ファイルを削減するのに非常に役立ちます。

結論

既存の構成を監査し、特定の手順を更新して新しいディレクティブとベストプラクティスを活用することにより、Apache2.4への移行はそれほど難しくありません。 機能的には、追加機能を備えた同じ機能を提供し、構文を理解しやすくする必要があります。

ジャスティン・エリングウッド
モバイルバージョンを終了