|
HTTPサーバー |
2013年10月20日 開始 | 2014年2月17日 更新 |
旧サーバーのバージョンは2.2.3、今度のは2.2.15でメインバージョンは同じなのでさほど大きなちがいはないでしょう。
まずはそのまま立ち上げてみます。
...OKです。ブラウザで localhost にアクセスしますとApacheの初期ページが表示されます。
そのあと例によって、/etc/httpd/conf/httpd.conf を編集。編集とはいっても古いサーバーのをほとんどそのまま。
localhost にアクセスすると...何も表示されません。今度は自分のディフォルトページが表示されるはずなのですが。
それどころかなんとSELinuxの猛攻。
.htaccess にアクセスできない restorecon しろ、今度は index.html が読めない restorecon しろ、...指示されたとおりにやるとそれはOKになるのですが、次々と別のが出てきてきりがありません。
さらにSELinuxに阻止されなくても期待のページが表示されません。
結局以下の2つの原因がからんでいて2日間悪戦苦闘。
原因が2つ以上あるとだいたいわけがわからなくなるんだわ。
SELinuxの対応
コンテキストラベルを付けなおします。
さらにSELinux Managementで
httpd_enable_homedir
http_read_user_content
の2つのブーリアン値をON。
とりあえずこれで静的なページは表示できるようになりました。
httpd.confをIPv6対応に修正
そうか、サーバー内部ではIPv6でアクセスしてるんだ。今後のことも考えてと今はIPv6を無効にはしていません。
さっそくhttpd.confを確認。
........
</Virtualhost>
そこで、
........
</Virtualhost>
なんせここにはphpMyAdmin始め各種サーバー設定用ツールを入れておくので、アクセスできないと先へ進めません。
localhostだとIPv4でもIPv6でもどちらでもいいみたい。
IPv6を使うなら気をつけないといけないな。
後ほど気がついたのですが、今度のCentOS6の/etc/hostsの記述は、
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
::1 localhost6 localhost6.localdomain6
::1 の方のlocalhost localhost.localdomainは消して、<VirtualHost localhost:80>を以前の記述<VirtualHost 127.0.0.1:80>に戻してみると今度はOKです。
またjwhoisがIPv6を有効にしていると動作しないらしいことが判明。どうやらIPv6は無効にせざるをえないようなのでlocalhostはやめて元の127.0.0.1の記述で行きます。
どうせ今のプロバイダ回線はIPv6には対応してないし、さらにお金を払ってまでIPv6対応の回線を入れる気もさらさらないので、結局IPv6を有効にしても実質あまり意味はないのでした。
さらに逆引きにlocalhostなどと設定してあるIPもあるし。(たとえば222.253., 222.254.など)
とりあえず第一段階はここまで。
実際にはhttpサーバーはMySQLデータベースサーバーと連携して動かすので、MySQLも動くようにしないと。
で、MySQLを立ち上げ。→ サーバー構築メモ その3/データサーバー MySQL
phpMyAdminは無事立ち上がり、mysqlデータベースにユーザ登録などして準備OK。
ブラウザを立ち上げて自分のホームページにアクセスしてみると案の定SELinuxに阻まれました。トラブルシューターの言う通り修正。
# setsebool -P httpd_can_network_connect 1
# setsebool -P httpd_can_network_relay 1
などのブーリアン値の変更やいくつかのポリシー作成・インストール等。
それでも自分のホームページは表示されません。
エラーログを見るといくつかの関数がないと。
実を言うとホームページを作り始めて約10年。プログラムをいろいろ改良してきましたが最初のころ作った部分には今は非推奨だよー、もうじき使えなくなるよーと最近のマニュアルに書かれているものがありながら、不精をしてついそのままにしていたのでした。
特にデータベース関連の機能に最近削除されたものがあり、前回は強引な追加インストールで対応しましたが今回はプログラムを修正することに。すっかり忘れているので少し悪戦苦闘。
今回の教訓:不精をしてはいけない。必ずつけは回ってくるぞ。
...で、何とか完了。でも実をいうと一番心配だったのがデータベースの互換性でしたが、データファイルをそのままコピーしてOKでした。もしだめだったらパックアップも容易ではないしどうしようかと心配していたのでした。
アクセスカウンターの怪 (2014.2.17追記)
実はしばらく運用して自前のアクセスログを見ていたとき、ごくまれに同じアクセスカウンターの値がダブって付与されているのに気がつきました。アクセスカウンターなんてなくてもいいようなものだから別に実害もなくしばらく放っていおたのですが、時折おこるのでやっぱり気になりますし、今後のプログラミングの参考にもちゃんと対策した方がいいかなと。
アクセスカウントの値はカウンターファイルに保存されており、Cookieやアクセスログなどを参照して新規アクセスと判断すれば+1するというだけの単純な話。ちゃんと順番に処理されていればおかしくなるはずはありません。
しかし前のサーバーのCPUはシングルコア、今回はマルチコアです。シングルコアの場合多少タイムスライスしているとはいえ各瞬間に動いてプロセスはひとつだけですが、マルチコアの場合実際に複数ありえます。
どうもこれが原因らしい。
ほとんど同時のアクセスの場合前のプロセスの処理が完了しないうちに次のプロセスがアクセスカウンターを読み出してしまうことは充分考えられます。現におかしくなったときのアクセスタイムは必ず秒単位ですが一致しています。
さっそく対策。とはいっても簡単なこと。プロセスのデータ確認~書き換え処理の間本来やるべき?アクセスロックをちゃんとやるだけ。
ファイルデータに対しては flock(ファイルポインタ, LOCK_EX); で、SQLデータに関しては "LOCK TABLES テーブル名 WRITE" で各々書込ロックし終了時にロックを解除。この間他のプロセスは待たされますがへんな値を取得したり書き込んだりはしないはず。
... で、これ以降確かにへんな現象は出なくなりました。
でもプログラムがめんどうになるからうっかりするとここは大丈夫だろうとやらないこともありそうだし、古いプログラムはこんなこと全然考えてないかもしれんな。新しいサーバーになってから以前はなかったような変なエラーがまれにあるけどこんなのが原因なのかな。へたなプログラムを組むと問題が起きる可能性から言えばマルチコアはちと怖いな。