EPEL に RPM パッケージが用意されています。yum で EPEL を使えるようにして phpMyAdmin をインストールします。

# yum install phpMyAdmin

アクセス許可

初期状態では、サーバのローカルからしか許可されていません。これをローカルエリアネットワークからアクセスできるように許可するには、/etc/httpd/conf.d/phpMyAdmin.conf を編集します。

<Directory "/usr/share/phpmyadmin">
  Order Deny,Allow
  Deny from all
  Allow from 127.0.0.1
  Allow from 192.168.1.0/24 ←追加
</Directory>

これで http://サーバ名/phpmyadmin/ にアクセスして、ログイン画面が出ればOKです。

もちろん、インターネット側からアクセスできるような設定もできますが、その場合は IP アドレスを限定したり Digest 認証の設定をするなどセキュリティには注意を払いましょう。

「mcrypt 拡張をロードできません」のエラー

「mcrypt 拡張をロードできません。PHPの設定を確認してください」というエラーが出た場合は、php-mcrypt パッケージがインストールされていません。yum でインストールして、Apache を再起動します。

# yum install php-mcrypt
# service httpd graceful

blowfish_secret の設定

「設定ファイルが秘密のパスフレーズ（blowfis_secret）を必要とするようになりました」というエラーが出た場合は、/usr/share/phpmyadmin/config.inc.php ファイルを編集して、$cfg['blowfish_secret'] に秘密のパスフレーズを設定します。

$cfg['blowfish_secret'] = 'ここに秘密のパスフレーズを設定'; /* YOU MUST FILL IN THIS FOR COOKIE AUTH! */

サーバが応答しません (あるいはローカルの MySQL サーバのソケットが正しく設定されていません)のエラー

「サーバが応答しません (あるいはローカルの MySQL サーバのソケットが正しく設定されていません)」というエラーが出るときは、メッセージどおり、MySQL のサーバが動いていない可能性があります。phpMyAdmin と MySQL のホストが異なる場合は、/usr/share/phpmyadmin/config.inc.php の $cfg['Servers'][$i]['host'] を変更します。

$cfg['Servers'][$i]['host'] = '192.168.1.100';  //←localhost から変更

RPM インストールであれば問題ないはずですが、それでもつながらない場合、ソケットの場所を確認します。ターミナルから mysql コマンドで接続したら　statusコマンドでソケットのパスを確認します。

$ mysql -u root
mysql> status
--------------
UNIX socket:            /var/lib/mysql/mysql.sock

このパスを、phpMyAdmin の config.inc.php に記述します。また connect_type も確認しましょう。

$cfg['Servers'][$i]['connect_type']  = 'socket';       // ←tcpから変更
$cfg['Servers'][$i]['socket']        = '/var/lib/mysql/mysql.sock';

ログイン画面の前にブラウザのパスワードダイアログが表示される

ログイン画面の前にパスワードダイアログがでる場合、以下の方法でログイン画面の表示に変更できます。管理画面に別途 Digest 認証などをかけているときは干渉して都合が悪いです。

$cfg['Servers'][$i]['auth_type']     = 'cookie'; //←http から変更

ログイン画面が出たら、通常は mysql データベースのログインアカウントとパスワードで入れるはずです。MySQL の初期状態では root ユーザでパスワード無しでは入れてしまいますので、その場合は root のパスワードを設定しましょう。

CentOS 5での例ですが、まず /etc/httpd/conf/httpd.conf を編集します。

NameVirtualHost *:80

上記を有効にします。バーチャルホストはドメインごとに以下のように設定します。

# www.example1.org
<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/example1
    ServerName www.example1.org
    ServerAlias example1.org
    ErrorLog logs/example1.org-error_log
    CustomLog logs/example1.org-access_log combined
</VirtualHost>

http://www.example1.org/ にアクセスしたときに /var/www/vhosts/example1/ ディレクトリのファイルを表示する例です。エイリアスとして www なしの http://example1.org/ でも同じ設定を使うようになっています。また、ログも分けて出力するようにしています。

バーチャルホストの設定がたくさんあるときは、それぞれのサイトごとにファイルを分けた方が良い場合もあります。（特に複数の管理者で触るような場合）まず httpd.conf で

Include conf.d/vhosts/*.conf

のようにして、/etc/httpd/conf.d/vhosts/*.conf ファイルを読み込むように設定します。ドメインごとに example1.org.conf や example2.net.conf などのファイルを作っていきます。

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/example2
    ServerName example2.net
    ServerAlias www.example2.net
    AddDefaultCharset euc-jp
    <Directory "/var/www/vhosts/example2">
      Options Includes ExecCGI FollowSymLinks MultiViews
    php_value mbstring.language Japanese
    php_value mbstring.internal_encoding EUC-JP
    php_value mbstring.http_input auto
    php_value mbstring.http_output EUC-JP
</VirtualHost>

上記は、サーバ全体の文字コード指定は UTF-8 だが、example2.net だけは EUC-JP で稼動させたいときの設定です。HTML だけでなく PHP の内部コードと出力文字コードも EUC-JP にしています。

設定を有効にするには、Apahce をリロードします。

# service httpd relaod

CentOS 5.x では、PHP 5.1.6 をベースにしています。手順としては Oracle Instant Client をインストールし、CentOS の PHP の SRPM をダウンロードし、SPEC ファイルを編集し、ビルドという手順になります。

Oracle Instant Client の インストール

Oracle Instant Client 10.2.0.4 の RPM をダウンロードします。ダウンロードには OTN の登録が必要です。ここでは Linux x86版(32bit版)の 10.2.0.4 の RPM をダウンロードします。最低限、oracle-instantclient-basic と oracle-instantclient-devel のパッケージはインストールが必要です。jdbc ドライバは不要です。

次に /etc/ld.so.conf.d/oracle-instant-client.conf というファイルを作成し、ライブラリパスを追加します。

# echo '/usr/lib/oracle/10.2.0.4/client/lib/' >> /etc/ld.so.conf.d/oracle-instant-client.conf

64bit 版の場合は次のようになります。

# echo '/usr/lib/oracle/10.2.0.4/client64/lib/' >> /etc/ld.so.conf.d/oracle-instant-client.conf

ライブラリパスを再読込します。

# ldconfig

いまは PHP をビルドするのが目的なので、Oracle データベースへの接続確認は割愛します。

PHP の SRPM のダウンロード

なぜか yumdownloader コマンドではうまく行かなかったので、理化学研究所のミラーから直接ダウンロードしました。

  wget http://ftp.riken.go.jp/Linux/centos/5.4/os/SRPMS/php-5.1.6-23.2.el5_3.src.rpm

この RPM をインストールすると、/usr/src/redhat/SPECS/ に php.spec ファイルが置かれます。また、/usr/src/redhat/SOURCES/ 配下にビルドに必要な PHP のソースファイルと、各種パッチファイルや設定ファイルなどが置かれます。

パッチファイルのダウンロード

php-5.1.6-oci8conf.patch をダウンロードして SOURCES ディレクトリに配置してください。Oracle が提供する SRPM や、他のパッチを元に、私が作ったものです。

SPEC ファイルの編集

こちらも、oci8 のために変更が必要です。変更箇所が多いので、php.spec (php-5.1.6.23.2.el5_3 用 32bit)に置きました。これをダウンロードして php.spec と差し替えてください。変更点は diff を取ればわかると思います。64bit 環境では、ライブラリパスを /usr/lib/oracle/%{ociver}/client/lib から /usr/lib/oracle/%{ociver}/client64/lib に変更する必要があります。

RPM のビルド

  $ rpmbuild -ba php.spec --target i686  --define 'oracle 1'

開発ライブラリなどがないと、コンパイルエラーとなります。事前に php.spec の BuildRequires セクションに書かれている RPM 群を yum コマンドでインストールしておきましょう。bzip2-devel, curl-devel, libstdc++-devel などです。

  # yum install bzip2-devel curl-devel libstdc++-devel

ビルドにはかなり時間がかかります。RPM ファイルは上記の例では /usr/src/redhat/RPMS/i686/ に配置されます。 php-oci8-5.1.6-23.2.ora.i686.rpm というファイルが PHP の OCI8 関数のモジュールを含んだ RPM です。 このモジュールを含む PHP の RPM をインストールしたら Apache を再起動します。phpinfo() コマンドで oci8 パッケージが有効になっていることを確認してみてください。

無料とはいえ、Firefox や Safari であれば、認証局として登録されているので、これらのブラウザで警告は出ません。残念ながら IE は対応していないようです。私の場合は Firefox で試しました。なお、私が試した内容を参考程度に書いているだけですので、この記事をもとに何か損害が発生しても、責任が取れません。くれぐれも自己責任でお願いします。

StartSSL に登録

まず StartSSL に登録します。StartSSL Free を選択し、「Register」を選択します。

住所、氏名、メールアドレスなどを入力します。「Zip, Locality/Place」には郵便番号と市町村名（もちろんローマ字で）を入力します。「State/Region」は都道府県名を選択します。「Phone」 は海外か日本国内へかける要領で、03-1234-5678 であれば +81-3-1234-5678 のようになります。Continue を押します。

すぐに登録したメールアドレスに認証用のコードが送られてきますので、これを貼り付けて「continue」を押します。ちなみに最初メールが届いてから15分くらい経って入力したら、すでにキーが破棄されていて最初からやり直しになりましたので、すぐに作業しましょう。

なぜか日本語化されている「高強度の暗号化」を選んで、「Continue」を押します。

ブラウザに証明書がインストールされました。今後は StartSSL へのログインは、この証明書を使って行なわれます。そのため、パスワードはありません。

クライアント証明書のバックアップ

StartSSL には、クライアント証明書がインストールされたブラウザでなければアクセスできなくなりますので、万が一に備えて証明書をバックアップしましょう。次の例は Firefox 3 の場合です。

「ツール」-「オプション」でオプション画面を出して、「詳細」タブを選択します。「証明書を表示」ボタンを押します。

StartCom Free ……という証明書を選択し、「バックアップ」ボタンを押します。

バックアップ用パスワードを訊かれますので入力します。このパスワードは後で証明書をインポートする際に必要となるものです。

ドメインを認証する

Web サーバの証明書作成の前に、ドメインの所有者であることを確認するためのプロセスがあります。

タブの Validations Wizard をクリックします。

Type として Domain Name Validation を選択します。

自分の所有するドメイン名を指定します。この時点では、www をつける必要はありません。

ドメインの正当な所有者であることを確認するためのキーが送られてくるメールアドレスを選択します。こちらで任意のアドレスを指定することはできません。「continue」を押すと、メールにキーが送られてきます。このキーを入力すると、ドメインの所有者であることが確認され、Web サーバ用の証明書などが作成できるようになります。

Webサーバ用の証明書を作成する

いよいよ Webサーバ用の証明書を作成します。

「Certificates Wizard」のタブを押して、SSL/TLS Web Serber Certificate を選択します。

自分で作成した秘密鍵ファイルが無い場合は、ここで作成することもできます。10文字以上32文字以下のパスフレーズを入力して continue を押します。パスフレーズにはアルファベットと数字のみが使えます。（自分で作成した秘密鍵ファイルがある場合は、Skip を押して先に進みます。）

このファイルをサーバに保存します。説明文では ssl.key という名前で保存と書かれていますが、ここでは /etc/httpd.conf/ssl.key/server.key に保存します。

サーバのサブドメインを指定します。ここではサブドメインとして www を指定しています。サブドメインを使わないについても証明書には含まれますので、とりあえず www を指定しておきましょう。なお、無料では複数のサブドメインや、ワイルドカード (*.example.org) の指定はできません。

CSR ファイルが作成されました。CSR ファイルは署名の要求をするためのもので、StartSSL がこの内容に署名をして証明書として発行してくれるものです。通常は同じサーバ・ドメインでも証明書の発行ごとに毎回異なる秘密鍵を生成して CSR ファイルを生成するものなので、特に保存の必要はないと思います。必要であればダウンロードして保存します。次に「continue」をクリックします。

PEM エンコードされた CRT ファイルができます。これが Web サーバの証明書ファイルです。これを /etc/httpd/conf/ssl.crt/server.crt として保存します。保存したら「continue」をクリックします。これで証明書の作成は終了です。

Apache + mod_ssl で設定

次に Apache + mod_ssl の環境で、これらの証明書を使うように設定します。通常、httpd.conf は変更する必要はありません。CentOS で PRM から入れていれば、/etc/httpd/conf.d/ssl.conf というファイルがありますので、これを編集します。

<VirtualHost _default_:443>
DocumentRoot "/var/www/html
ServerName example.org:443
ServerAlias www.example.org:443

ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn

SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP

SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key
……
</VirtualHost>

SSL は NameNameVirtualHost を利用している場合でも利用できます。保存したら httpd を再起動します。

# service httpd configtest
Syntax OK
# service httpd restart
httpd を停止中:                                            [  OK  ]
httpd を起動中: Apache/2.0.52 mod_ssl/2.0.52 (Pass Phrase Dialog)
Some of your private key files are encrypted for security reasons.
In order to read them you have to provide the pass phrases.
Server example.org:443 (RSA)
Enter pass phrase: //←パスフレーズを入力
OK: Pass Phrase Dialog successful. [  OK  ]

再起動時に、秘密鍵作成時に入力したパスフレーズを入力すれば Apache が起動します。この作業を毎回しないと Apache が起動しなくなり不便です。秘密鍵のパスフレーズを解除しておくには、openssl コマンドを使って次のようにします。

# openssl rsa -in server.key -out server.key

なお、秘密鍵ファイルは root と apache 以外の第三者が閲覧できないようなパーミッションに設定しておきましょう。

Web ブラウザでアクセスしてみる

Firefox でサーバに https://～ でアクセスしてみます。設定に問題がなければ、何も警告が出ずに SSL 通信ができるはずです。

ブラウザでアクセスできない場合、Port 443 がファイアウォールで遮断されていないか確認してください。

ssl_error_rx_record_too_long のエラーが出る場合は、httpd.conf か ssl.conf でバーチャルホストの設定が正しくされていない可能性がありますので、設定を確認してください。

大きなファイルがアップロードできない

php.ini の upload_max_filesize と post_max_size の値がどのようになっているか確認。あと、memory_limit は上記の2つの値より大きくなっている必要があります。php.ini が直接覗けない場合は

  echo ini_get('upload_max_filesize');
  echo ini_get('post_max_size');
  echo ini_get('memory_limit');

のようにして確認することもできます。まあ、php.ini を編集できないと回避できないのですが。

上記の設定に問題ない場合、HTML で MAX_FILE_SIZE を指定していないか確認します。

  <input type="hidden" name="MAX_FILE_SIZE" value="1000000" />

HTML のフォームに MAX_FILE_SIZE を設定することが推奨されていますが、この値をセットしていることを忘れて、変更が漏れているかもしれません。

Apache 側の設定の可能性もあります。httpd.conf や /etc/httpd/conf.d/php.conf などで、LimitRequestBody の値を制限しているかどうか確認してください。

そもそもアップロードできない

大きいファイルだけでなく小さいファイルもアップロードできない場合は、php.ini で file_uploads が Off になっているかもしれません。

また、form 要素の enctype 属性が multipart/form-data に設定されていない可能性があります。

  <form method="post" enctype="multipart/form-data">

それ以外では、サーバのテンポラリディレクトリが存在しなかったり、apache を実行しているユーザで書き込みできなくなっている可能性があります。php.ini の upload_tmp_dir に設定されているディレクトリが有効かどうか確認してください。

突然アップロードできなくなった

サーバのディスク容量が不足しているかもしれません。

エラーコードを調べる

PHP の変数 $_FILE["input_name"]["error"] にエラーコードが格納されています。エラーコードの説明 を参照すると、より原因が絞り込めます。

ORA-00911: invalid character in hogehoge.php on line X

しかし、SQL には誤りはなく sqlplus で実行できますし、しばらく時間が経過すると、Apache + PHP 上でもエラーかでなくなります。PHP のコード中では

putenv("NLS_LANG=Japanese_Japan.UTF8");

として、NLS_LANGの値を設定していますが、どうもこの設定が反映されないようです。いろいろ調べると、apache の起動スクリプト中で環境変数を設定すればよいということでした。

/etc/rc.d/init.d/httpd を直接編集しても良いのですが、Red Hat 系(Fedora や CentOS) では、それは避けた方が良さそうです。起動スクリプト中では /etc/sysconfig/httpd がユーザが編集するファイルとして読み込まれ、実行されますので、こちらに記述します。

# vi  /etc/sysconfig/httpd

export NLS_LANG=Japanese_Japan.UTF8

これで Apache を再起動後すれば、起動直後でも NLS_LANG の値が有効になっており、エラーは発生しなくなりました。

この記事は Netcraft の統計を元に書かれていますが、こちらで、シェアだけでなくアクティブなサイト数も見ることができます。その値が衝撃的。

Netcraft: October 2007 Web Server Survey

これを見ると Google というウェブサーバが 9.76% も存在しています。これは Google のカスタム Linux 上で動作する独自の HTTP サーバのことでしょうが、それにしても多すぎます。1社で全世界のウェブサーバの1割を占めているのですから。素晴らしいというか、ちょっと恐ろしくなりますね。

昨年読んだ記事では Google のサーバ数は世界に数十万台ということなので、今は100万台を超えていてもおかしくありませんが、それを遙かに上回っている模様。Google が Gmailの増量ペースを加速とうニュースもありましたが、これだけのサーバがあるからこそ Gmail の容量を6Gにもできるわけですね。

“HMSE_Robot” ですが、アクセス元の IP は 222.239.220.194～222.239.220.198 で、韓国の IP です。詳細は分かりませんが、世界的に迷惑をかけまくっているようなので、Apache の設定で拒否するようにしました。

  deny from 222.239.220.192/29

この IP の割り当てが 韓国の Hanaro Telecom の割り当て範囲（222.232.0.0 – 222.239.255.255）　に含まれるため、222.232.0.0/13 を丸ごと拒否する設定をしているサーバもあるようですが、さすがにそれはやり過ぎのような気がします。

とりあえずこれで様子を見ることと、これを機にメインメモリの増設、mod_dosdetector の導入を検討することにします。

  httpd: apr_sockaddr_info_get() failed for server_name
  httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName

のようなエラーが。どうもサーバ名が見あたらないらしい。

原因は /etc/sysconfig/network に書いてある HOSTNAME が見つからないこと。もちろん自分自身なので /etc/hosts の 127.0.0.1 の部分に記述したらエラーは出なくなりました。

LogWatch に含まれてくる大量の URL は次のようなものです。

  GET /2005/08/extensions/feed HTTP/1.1 with response code(s) 200 1 responses
  GET /2004/03/rss_atom HTTP/1.1 with response code(s) 200 1 responses
  GET /2004/02/tzone HTTP/1.1 with response code(s) 200 5 responses
  GET /2004/11/vaio-type-u HTTP/1.1 with response code(s) 200 2 responses
  GET /category/portal/page/2 HTTP/1.1 with response code(s) 200 1 responses
  GET /images/kotoba_bn HTTP/1.0 with response code(s) 200 16 responses

これらはステータスコード 200 を返していますが、URL が .html や .php などの拡張子で終わっていないために出力されています。Apache の設定で Option MultiViews を有効にして Content Negotiation を使っていたり、WordPress のようなブログを使っている場合に記録されますが、おかしなログではありません。

# vi /etc/log.d/scripts/services/http

としてログを正規表現で検査するときの条件を 113 行目付近につけ加えます。

   $content_types =  $content_types.'|\.htm|\.html|\.jhtml|\.phtml|\.shtml|\/';
   $content_types =  $content_types.'|\.html#.*|\/[a-zA-Z0-9\-_\/\!]+|\/[a-zA-Z0-9\-_\/\!]+#.*|\/';
   $content_types =  $content_types.'|\.inc|\.php|\.php3|\.asp|\.pl|\.wml|\/';

これで、すべてとは言いませんが、LogWatch の内容が減って軽くなったはずです。

独自ドメインでサイトを運営する際に、http://www.example.com/ のように “www” を頭につけるか、http://example.com/ のように “www” をつけないか、どちらかにしていると思います。しかし、設定によってどらちでもアクセス可能で同じ内容が表示されているという場合も多いです。（www の有無で別内容を表示することもできますが、普通はしませんよね。）

このとき、www の有り無しどちらでアクセスさせるかを統一しておかないと、検索エンジンの結果に二重に表示されたり、ソーシャルブックマークサービスで別々の URL としてカウントされたりしますので、SEO の観点でいうと好ましくありません。

そこで、Apache であれば .htaccess ファイルを使ってリダイレクトさせることができます。

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com
RewriteRule (.*) http://example.com/$1 [R=301,L]

これは www 有りから無しへリダイレクトさせる場合です。http://www.example.com/foo/bar にアクセスすると http://example.com/foo/bar に飛びます。うまく行かない場合は、.htaccess の利用が禁止・制限されている、mod_rewrite モジュールが入っていないなどの理由が考えられます。

追記: WordPress での注意点

WordPress では最初から .htacces ファイルが置かれています。このファイル中の # BEGIN WordPress から # END WordPress までは管理画面の「パーマリンク構造を更新」ボタンを押すと上書きされてしまいます。.htaccess ファイルに設定を書く場合は、これらの前後にします。

RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.example\.com
RewriteRule (.*) http://example.com/$1 [R=301,L]

RewriteEngine on
RewriteRule (.*)\.html$ $1 [R=301,L]

# BEGIN WordPress
<IfModule mod_rewrite.c>
この間は上書きされる
</IfModule>
# END WordPress

実際にどのように使うかと HTTP のレスポンスヘッダ内にて、次のように出力します。

文書をインデックスさせたくない場合

X-Robots-Tag: noindex

文書をキャッシュさせず、スニペットも表示しない（インデックスはされる）

X-Robots-Tag: noarchive, nosnippet

指定期間後にインデックスから削除させたい時

X-Robots-Tag: unavailable_after: 27 Jul 2007 19:30:00 GMT

これをどこで指定するかというと、たとえば Apache ならば .htaccess ファイルでの指定が考えられます。

<Files "hogehoge.pdf">
Header set X-Robots-Tag "noarchive, nosnippet"
</Files>

HTTP ヘッダを確認に X-Robots-Tag: noarchive, nosnippet が付加されるはずです。mod_headers モジュールが有効になっている必要がありますが、たいていは有効になっているでしょう。

原因はどうも Apache のコンテント・ネゴシエーション (Content Negotiation) とぶつかっているようです。リダイレクトされないだけならまだしも、404 Not Found になってしまうので困ります。httpd.conf の Options から MultiViews を外したらうまく Redirect されるようになりました。

以前は同じ設定をしていてもうまくリダイレクトされた記憶があるので、Apache の特定のバージョンによるものなのかわかりませんが、Apache 2.0.46 で試しても同様でした。ファイルが存在しているといけないようで、ファイルを削除してしまえばよいようです。たとえば .htaccess で

Redirect permanent /hoge http://example.com/newhoge/

の様に指定した場合、 /hoge.html などのファイルが残っていると、404 Not Found になります。/hoge.html を削除またはリネームすれば良さそうです。ハマりました。

不正なファイルです。 使用可能なものをアップロードしてください。

のエラーメッセージが出ている場合です。しかしファイル自体が不正なのでも、壊れているわけでもない場合、メモリ不足の可能性があります。サーバ自体にはメモリがたくさん積まれていても、通常は PHP で利用できるメモリが制限されています。

初期値は 8MByte なのですが、サムネイル作成には足りないのです。おそらく Apache のエラーログに

Allowed memory size of 8388608 bytes exhausted (tried to allocate 0 bytes)

のように出ているはずです。そこで、php.ini の memory_limit 値を編集します。

;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;

memory_limit = 32M      ; Maximum amount of memory a script may consume (8MB)

これで Apahce を再起動して、画像をアップロードしてみてください。たぶんサムネイルがうまく生成されるはずです。これでもうまくいかないというときは小さいサイズの画像で試してみましょう。あまりに大きすぎる画像はあらかじめ縮小してアップロードするというのが良いでしょう。

<?php /* Short and sweet */
define('WP_USE_THEMES', true);
require('./wp-blog-header.php'); >

たとえば .htaccess の中に AddType "text/html;charset=utf-8" .php のような記述があれば、間違いなくそれが原因です。 これを削除・コメントしてみましょう。

また、mod_ssl の 2.8.24 以前の SSLVerifyClient ディレクティブに欠陥も発見されています。(CVE-2005-2700
) この欠陥は、仮想ホストが SSLVerifyClient optional として設定され、さらに SSLVerifyClient required が特定のロケーション用に設定されている場合に発生に、攻撃者がクライアント証明書なしにアクセス制限を回避できる可能性があるというものです。

これらへの対策はパッチを取り込んだ Red Hat 9 向けの RPM が Fedora Legacy Project からリリースされています。ほかにも Red Hat 7.3、Fedora Core 1、2 向けのパッケージもリリースされています。

例によって rpm.fumika.jp にて公開している Apache の RPM を、新しいパッケージをベースにビルドし直しました。バージョンは 2.0.40-21.20.1 です。IE6 の Digest 認証エラー対応パッチを適用し、i686 向けに最適化したものです。ご入り用の方は（自己責任で）どうぞ。

少し前のことですが、今月に入って glibc、Apache (httpd、mod_ssl)、bzip2、rp_pppoe、xchat のセキュリティアップデートが公開されています。

この攻撃（CAN-2005-2088）への対策は Apache 2.0.55 でなされていますが、このパッチを取り込んだ Red Hat 9 向けの RPM が Fedora Legacy Project からリリースされました。ほかにも Red Hat 7.3、Fedora Core 1、2 向けのパッケージもリリースされています。CAN-2005-2088 以外にも CAN-2005-1344、CAN-2005-1268 の欠陥が修正されています。

例によって rpm.fumika.jp にて公開している Apache の RPM を、新しいパッケージをベースにビルドし直しました。バージョンは 2.0.40-21.18.1 です。IE6 の Digest 認証エラー対応パッチを適用し、i686 向けに最適化したものです。ご入り用の方は（自己責任で）どうぞ。

Apache、gzip、SpamAssassin、mc のアップデートがリリースされました。yum でダウンロードできますがミラーサイトによっては行き渡るまでに時間が掛かると思います。FTP サーバから入手することもできます。まだ Advisory は掲載されていません。

• Apache httpd。CAN-2005-1268 CAN-2005-1344 CAN-2005-2088 の修正。RH7.3、RH9、FC1、FC2 が対象
• gzip。CAN-2005-0758 CAN-2005-0988 CAN-2005-1228 の修正。RH7.3、RH9、FC1、FC2 が対象
• mc(Midnight Commander)。AN-2004-0226 CAN-2004-0231 CAN-2004-0232 CAN-2004-0494 CAN-2004-1004 CAN-2004-1005 CAN-2004-1009 CAN-2004-1090 CAN-2004-1091 CAN-2004-1092 CAN-2004-1093 CAN-2004-1174 CAN-2004-1175 CAN-2004-1176 CAN-2005-0763 の修正。RH7.3、RH9、FC1、FC2 が対象
• spamassassin。CAN-2004-0796 の修正。FC2 のみが対象

また、zlib が updates-testing 入りしています。

ダウンロード

まず、Another HTML-lint をダウンロードします。最新の zip 版をダウンロードし、/var/www/html/htmllint/ に解凍します。ディレクトリ名は htmllint にする必要性はありませんが、ここでは便宜上そのようにしてあります。

必要パッケージの確認

Another HTML-lint は Perl の LWP(libwww-perl)、CGI および Jcode モジュールが必要です。

  $ rpm -qa | grep perl

として必要なモジュールがインストールされているかどうかを確認してください。Red Hat Linux 9 には Jcode の RPM は含まれていませんが、私がパッケージしたものを公開していますので、こちらをインストールしても良いかと思います。（もちろん自己責任でお願いします。）

また、Another HTML-lint はテキストブラウザでの見栄えを出力してくれる機能があります。これを利用するために Lynx パッケージも入っているかどうかチェックしておいてください。

  $ rpm -q lynx
  lynx-2.8.5-11

設定

解凍した中に htmllintenv というファイルがあります。これを htmllint.env に名前を変更した上で、開いて修正します。

  $ mv htmllintenv htmllint.env
  $ vi htmllint.env

  #コメントを外す
  $KANJICODE = 'EUC';
  #コメントを外してパスを修正
  $LYNX = '/usr/bin/lynx -dump -nolist -force_html';

ほかにもプロキシサーバの設定などが必要でしたら行なってください。

Red Hat Linux では、通常 perl のパスは /usr/local/bin/ ではなく /usr/bin/ です。htmllint（というファイルがあります）、htmllint.cgi、tagslist.cgi、および parsedtd.plファイルを開き、先頭行の Perl のパスを修正します。

  #!/usr/bin/perl

*.cgi ファイルのパーミッションを 755 などに変更し、CGI が動作するようにします。

  $ chmod 755 htmllint.cgi tagslist.cgi

また、Lynx の設定を変更し、出力が EUC になるようにします。

  # vi /etc/lynx.cfg

  #CHARACTER_SET:iso-8859-1
  CHARACTER_SET:euc-jp

httpd.con の設定

Red Hat Linux の Apache のデフォルト設定では、CGI が cgi-bin ディレクトリ以外では動きません。そこで htmllint ディレクトリでも CGI が動作するようにします。また、htmllint.env ファイルが第三者に見られないようにします。

これらの設定は .htaccess ファイルで行なう方法もありますが、今回は httpd.conf ファイルに直接書いてみました。

  # /etc/httpd/conf/httpd.conf
  <Directory "/var/www/html/htmllint">
    Options MultiViews ExecCGI
    AllowOverride None
    AddHandler cgi-script .cgi .env
    AddCharset ISO-2022-JP .html
    Order allow,deny
    Allow from all
  </Directory>

.html に対して ISO-2022-JP の Charset を指定しないと、結果の解説ページなどが文字化けします。 設定が終わったら、Apache を再起動します。

  # service httpd configtest
  Syntax OK
  # service httpd graceful

テスト

ウェブブラウザで http://サーバ名/htmllint/ にアクセスして、テストしてください。CGI のソースコードが表示されてしまう場合は、httpd.conf の設定か、パーミッションの設定に誤りがあります。CGI のエラーが発生する場合は、Perl のパスの書き換えができてないか、httpd.conf の設定に誤りがあると思います。

ブックマークレット

HTML-lint の動作が確認できたら、ブックマークレットを作っておきましょう。次のリンクは Mozilla Suite / Firefox 用です。他のブラウザでは確認していません。

Another HTML-lint でチェック

このリンクをブックマークツールバーなどにドラッグ・アンド・ドロップします。初期状態では本家のサーバにチェックに行くようになっていますので、これを必ず自分で設置した URL に書き換えてください。チェックしたいページを開いた状態でブックマークレットを使います。

2009-11-12 追記

lynx.cfg で出力コードを EUC に変更してしまうと、HTMLlint 以外の目的で Lynx を使うときに困ります。その場合は lynx.cgi を変更せずに、htmllint.env 内の $LYNX に文字コードの指定を追加します。

  $LYNX = '/usr/bin/lynx -dump -nolist -force_html -display_charset=euc-jp';