こんにちは、担当上岡です。

さて、今日は実際にハマった(?)話で、解決させるときの情報が少なかった例を一つご紹介します。

あるRedhat Enterprise LinuxサーバでVirtualHostを2-3個載せるWebサーバを構築していたときの話です。

こんな環境のサーバでした。主要なアプリケーションはパッケージまたはSRPMで導入。

Dell PE1420
Redhat Enterprise Linux 4 ES プリインストール
Apache2.0 (パッケージ)
PHP4.3 (パッケージ)
MySQL4.1 (SRPMから)
などなど…

要は「Redhatプリインストールのマシン」でした(これが後々ポイントに…)。

だいたい、自分でインストールの場合でも、プリインストールのマシンの場合でも、共通して基本セットアップでやる主な作業は、

・ホスト名の設定
・ネットワークの設定(必要に応じてiptablesの設定)
・一般ユーザーアカウントの作成
・起動サービスの確認(あわせて自動起動の取捨選択作業)
・インストール済みパッケージの大まかな確認
・ハードウエア関連の設定(必要に応じて)

ぐらいです。今回のサーバでもこの辺りをまず整理してから、Apacheの設定に取りかかりました。

ちなみに、取りかかる前、デフォルトの状態では、IPアドレスで http://172.16.0.1/ (仮) を開くと、RedhatのApacheテストページが開けていました。

さて、本題。このサーバではVirtualHostを複数立て、それぞれにおいてログ分析を行う必要があったため、NameVirtualHostのディレクティブに次のような記述をしました(一部情報を隠してあります)。

NameVirtualHost 172.16.0.1

ServerAdmin kamioka@test.local
DocumentRoot /var/www.virtual1.local/webroot
ServerName www.virtual1.local/
ErrorLog "|/usr/sbin/rotatelogs /var/www.virtual1.local/logs/error_%Y%m%d.log 86400 540"
CustomLog "|/usr/sbin/rotatelogs /var/www.virtual1.local/logs/access_%Y%m%d.log 86400 540" combined env=!nolog

ScriptAlias /cgi-bin/ "/var/www.virtual1.local/cgi-bin/"

Options None
AllowOverride AuthConfig
Order allow,deny
Allow from all

(以下CGIディレクトリの設定など)

こんな感じで。CustomLogにrotatelogsを使ってますが、特に変なところないですよね？

さて、これでhttpdを再起動。問題なく立ち上がったように見えます。

しかし、http://www.virtual1.local/ を叩いてみても、出るのはredhatのapacheテスト画面。もちろん、このテスト画面は /var/www.virtual1.local/webroot には置いてありません。/var/www/htmlにあるもの。

何かおかしい。まずはApacheのログを調べてみます。すると、、デフォルトサーバにもバーチャルサーバにもアクセスログが出ていません。エラーログだけが出力されています。そのエラーログの出力がこちら。

[Fri Apr 22 14:58:50 2007] [notice] Apache/2.0.52 (Red Hat) configured -- resuming normal operations
1 Previous file handle doesn't exists /var/www.virtual1.local/logs/error_20070422.log
1 Previous file handle doesn't exists /var/www.virtual1.local/logs/access_20070422.log
piped log program '/usr/sbin/rotatelogs /var/www.virtual1.local/logs/access_%Y%m%d.log 86400 540' failed unexpectedly

file handle doesn't exists。ファイルが開けないと言われています。ディレクトリ名などが間違っていないことも確認、また、ログの書き込みディレクトリの権限も問題ありませんでした。

試しにrotatelogsを使わずに直接ファイルに書かせる設定にしてもダメでした。

ここがハマリポイントでした。

次に、システム全体のログといえば、/var/log/messagesですね。httpdを再起動→バーチャルホストに接続しながらこのログをtail -fで流してみました。すると…

Apr 22 14:48:30 testhost kernel: audit(1179812910.938:5): avc: denied { write } for pid=25079 comm="httpd" name="mibs" dev=dm-1 ino=608447 scontext=root:system_r:httpd_t tcontext=system_u: object_r:usr_t tclass=dir Apr 22 14:49:38 testhost kernel: audit(1179812978.021:6): avc: denied { getattr } for pid=25087 comm="httpd" name="index.html" dev=dm-0 ino=6210537 scontext=root:system_r:httpd_t tcontext= root:object_r:var_t tclass=file Apr 22 14:49:38 testhost kernel: audit(1179812978.021:7): avc: denied { getattr } for pid=25087 comm="httpd" name="index.html" dev=dm-0 ino=6210537 scontext=root:system_r:httpd_t tcontext= root:object_r:var_t tclass=file Apr 22 14:49:38 testhost kernel: audit(1179812978.022:8): avc: denied { write } for pid=25083 comm="rotatelogs" name="logs" dev=dm-0 ino=6210538 scontext=root:system_r:httpd_t tcontext=roo t:object_r:var_t tclass=dir Apr 22 14:49:38 testhost kernel: audit(1179812978.023:9): avc: denied { write } for pid=25085 comm="rotatelogs" name="logs" dev=dm-0 ino=6210538 scontext=root:system_r:httpd_t tcontext=roo t:object_r:var_t tclass=dir Apr 22 14:49:38 testhost kernel: audit(1179812978.150:10): avc: denied { write } for pid=25119 comm="rotatelogs" name="logs" dev=dm-0 ino=6210538 scontext=root:system_r:httpd_t tcontext=ro ot:object_r:var_t tclass=dir

(以下略)

！！！！

なんと犯人(?)はSELinuxでした。audit: avc: deniedがたくさん出ています。

/etc/sysconfig/selinuxを覗いてみると

SELINUX=enforcing

が書いてありました。はじめの方にも書きましたが、Redhat Enterprise 4, 5やFedora　Core3以降など、油断しているとインストール時にSELINUXがenforcingで入っていることがあります。

もちろん、セキュリティ強化のためにSELINUXをenforcingモードで利用するのもいいのですが、ファイアウォール内である程度安全が確保されていて、しかもほぼ非公開のサーバにするのに、SELinuxの運用はToo Muchです。

なので、解決方法としては、この例ではSELinuxの無効化を行いました。

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=disabled
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted

で、OSごと再起動( # init 6 )。晴れてVirtualHostも見えて、ログもきちんと書き込まれるようになりました。

ちなみに、SELinuxで運用する場合、正統にこの例で解決をしようとするなら、

$ /sbin/restorecon -R /var/www.virtual1.local/webroot $ /sbin/restorecon -R /var/www.virtual1.local/logs

またはchconコマンドを使って、適切にセキュリティコンテキストを変更してあげれば良かったかということかもしれません。

そうそう、SELinuxは、いきなりdisabledにしなくても、permissiveモードを使うと、いろいろと勉強になります。

ともあれ、今回の要点としては、SELinuxはきちんと把握して管理できないと、思わぬところで困らされてしまう、ということでした。

---

さて、今日の記事はSELinux原理主義の方に怒られてしまいそうですが、匠システムではSELinux有効で運営されているサーバももちろんお預かりできます。サーバ管理サポートのご用命は「匠の見張り番」や匠のサーバコンサルティング「Dr.サーバ」をぜひご利用ください。お問い合わせもお待ちしております。