Cronでサービスの死活監視

最近仕事でVPSにWeb、メール(Postfix、Dovecot)、Webメール、メーリングリスト(Mailman)とインストールしたのだが・・・
本番が始まると突然のサービス停止に時々見舞われて、極めて不安定な状態です。
どうもメーリングリストの設定なのか相性なのか、ここが起因になって他のサービスが停止するようです。
ということで、死活監視を行うことになったのですが、今回はCronのみで死活監視を行うことに挑戦しました。
cronの編集は「# vi /etc/crontab」を前提としています。
Webの死活監視
0 * * * * root wget -O – (URL) > /dev/null 2>&1 || echo `date +\%Y/\%m/\%d_\%H:\%M:\%S` > /dev/null | tee -a /var/log/service_watch.log | service httpd restart > /dev/null | tee -a /var/log/service_watch.log
毎時0分に起動します。Wgetコマンドにより(URL)に指定したコンテンツを取得、取得できなかった場合は、ログファイル(/var/log/service_watch.log)に時刻とサービス再起動状態を記録します。「tee」コマンドの「-a」はファイルに追記するオプションです。
smtpの死活監視
1,11,21,31,41,51 * * * * root (sleep 2;echo “quit”) | `telnet 127.0.0.1 25 >& smtp_status`;if [ `grep -c ‘220’ smtp_status` != 1 ]; then service postfix restart; logger -t smtp “crond check – smtp service restart”; fi; > /dev/null 2>&1
1分から10分おきに実行します。quit入力を2秒後にセットし、ローカルの25番ポートに接続します。正常に接続できれば、エコーの中に「220」が入るので、それがない場合は接続できなかったと判断して、Postfixの再起動をします。ログは標準のmessageログに指定したメッセージ(crond check – smtp service restart)で書き込まれます。
pop3の死活監視
2,12,22,32,42,52 * * * * root (sleep 2;echo “quit”) | `telnet 127.0.0.1 110 >& pop3_status`;if [ `grep -c ‘Welcome’ pop3_status` != 1 ]; then service dovecot restart; logger -t pop3 “crond check – dovecot service restart”; fi; > /dev/null 2>&1
2分から10分おきに実行します。quit入力を2行後にセットし、ローカルの110番ポートに接続します。正常に接続できれば、エコーの中に「Welcome」(独自のバナーメッセージ)が入るので、それがない場合に接続できなかったと判断して、Dovecotの再起動をします。ログは標準のmessageログに指定したメッセージ(crond check – dovecot service restart)で書き込まれます。
メーリングリストはサービスが起動していても、キューが詰まる現象があったので、1時間ごとに強制的に再起動させるようにしました。
10 * * * * root service mailman restart > /dev/null 2>&1

CakePHPサイトでSSL制御をhtaccessで行う方法

mod_rewriteモジュールでサイト全体をSSL対応(https)する「.htaccess」ファイルの書き方は・・・

RewriteEngine On
RewriteCond %{HTTP_HOST} ^free-style.biz$
RewriteCond %{HTTPS} off
RewriteRule ^(.*) https://free-style.biz/$1 [R=301,L]

条件として2行目の「HTTP_HOST」はあってもなくてもよいです。
3行目の「%{HTTPS} off」により「http://で始まっている」=「https://で始まっていない」という条件になります。
4行目で絶対表示でURLを指定し、ルート以下のパスを「$1」として追加します。
さて、CakePHPサイトで「www」で始まるURLを「wwwなし」に変更してアクセスする場合の書き方を説明します。(/app/webroot/.htaccess)

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.free-style.biz$
RewriteCond %{HTTPS} on
RewriteRule ^(.*) https://free-style.biz/$1 [R=301,L]
RewriteCond %{HTTP_HOST} ^www.free-style.biz$
RewriteCond %{HTTPS} off
RewriteRule ^(.*) http://free-style.biz/$1 [R=301,L]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]

大まかな流れは
1.www付きをwwwなしにして再アクセスする(http://の場合)
2.www付きをwwwなしにして再アクセスする(https://の場合)
3.ディレクトリやフォルダが実在しない場合はindex.phpを実行する
となります。3は通常のCakePHPのままです。
条件(RewriteCond)とルール(RewriteRule)は何個も重ねて定義されますが、「[R=301,L]」により正常に再アクセスされた場合はここで一旦終了するようになります。
http://www.free-style.biz/でアクセスされた場合は、1番目で「http://free-style.biz/」に再アクセスされて一度終了し、「http://free-style.biz/」でアクセスされて3番目でindex.phpが実行されます。
この仕組みが理解できれば、htaccessを使いこなせるようになりますよ!

CakePHPのhtaccessファイル解説

普段CakePHP(v1.3)を利用するにあたり、あまり考えずに使用している「.htaccess」ファイルについて解説します。
/(ルート)

RewriteEngine on
RewriteRule ^$ app/webroot/ [L]
RewriteRule (.*) app/webroot/$1 [L]

1行目「RewriteEngine on」はmod_rewriteモジュールを使用するためのスイッチです。
2、3行目はともに「RewriteRule」なので、書き換えルールの適用となります。意味は「app/webroot/ に移動する」となります。
/app/

RewriteEngine on
RewriteRule ^$ webroot/ [L]
RewriteRule (.*) webroot/$1 [L]

ここはルートとほぼ変わりないですが、書き換えルールが「webroot/に移動する」となっています。
/app/webroot/

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]

一般公開するときはここをルートにすることが推奨となっています。その理由はこのファイルにあります。
1行目「RewriteEngine on」はmod_rewriteモジュールを使用するためのスイッチです。
2、3行目の「RewriteCond」は書き換えルールを適用するための条件を定義しています。2行目はパラメータ「-d」により、実際にディレクトリが存在しない場合、3行目はパラメータ「-f」により、実際にファイルが存在しない場合となり、両方合わせて、指定されたURLパスに実際にディレクトリもファイルも存在しない場合となります。
4行目で書き換えルールが指定されています。「^(.*)$ index.php?url=$1」は同フォルダ内の「index.php」を実行するという意味ですが、「?url=$1」の「$1」が何なのか?よくわかりませんでした。
Perlを使用するには当たり前の正規表現らしいのですが、「$1」の「$」は末尾を示すわけではなく、「$1」で「要素の1番目を適用する」ということになります。
要素の1番目とは「^(.*)$」のことです。index.phpの前に半角スペースがあり、半角スペースでつなげていくことにより要素を複数定義できます。「^(.*)$」は「先頭から0文字以上の文字列を末尾まで」という意味です。つまり、ルート以下のパスがここに入ります。
CakePHPでは必ずindex.phpから始まると誤解している人がいますが、これはある意味で正しく、ある意味で間違っています。
CakePHPのフレームワーク内の制御としてはindex.phpが常に実行されます(正しい部分)が、webwoot配下に実際に配置されたhtmlファイルや画像ファイルはそのまま表示され、index.phpは実行されません(間違っている部分)。
静的なhtmlファイルのみではなく、phpファイルであっても、webroot配下に配置すれば実行することができます。ただし、ルートが「/app/webroot/」まで下げられていないと、CakePHPのフレームワーク外ではURLに「/app/webroot/」が表示されてしまうことがあります。

すべてのWEBサイトがSSL化される時代は近い?

ベリサインと契約している会社に不定期に送信されてくる「VeriSign Letter」、その7月号に気になることが書かれていました。


Googleのhttps化がおよぼす影響とは?
ウェブサイト運営者の多くはアクセスログ解析ツールを使って訪問者がどのサイトから来るのか、どんなキーワードで検索してくるのかを日々確認されていると思います。そこで本日はGoogle社が新しく開始したSSL暗号化対応の検索サイトの登場によって、これまでのログ解析結果にどのような影響が出てくるのか少し触れてみたいと思います。
5月21日よりGoogle社はエンドユーザのプライバシーを保護するため、SSL暗号化対応のベータ版検索サービスを立ち上げました。エンドユーザの検索キーワードと検索結果はSSL暗号化によって通信経路上の第三者から守られます。その一方で、非SSL(URLがhttp://から始まる)のサイト運営者には、このサイトからの訪問者がどこから来たのか、どんなキーワードを検索したのかが分からなくなってしまい、ウェブマーケティング活動に支障をきたす恐れがあります。
通常Internet ExplorerやFirefoxなどのブラウザは、サイト訪問者が直前に訪問していたURLをリファラと呼ばれる情報としてウェブサーバに送信します。ところが直前のURLがhttpsから始まるSSLサイトの場合、非SSLサイトへ遷移してもリファラを送信しない仕様となっています。これはブラウザのセキュリティ仕様による動作です。例えばプログラムが稼動しているサイト上ではURLにセッションIDなどプライバシー情報につながりやすいパラメータを含むことがしばしばあります。そのような場合でも、前出の仕様によってSSL暗号化されたサイトのセッションIDなどが通信経路上の第三者に渡ってしまう事を防げます。
しかし、サイト運営者にとってリファラはSEOやレコメンド機能などウェブマーケティング活動の重要な基礎データとなります。そこでこれまで通りリファラを取得するためにはサイト全体をSSL化するがひとつの解決手段となります。
Google社のSSL検索サイトの利用者の数はまだまだ多いわけではないと思いますので対応を急ぐ必要はなさそうですがプライバシー意識の高まりによって今後SSLがどのように利用されてゆくようになるのか、気に留めてみるのも良いかもしれません。
–>> Google社のSSL検索サイトを試してみる
   http://vmail.verisign.co.jp/c?c=9229&m=37718&v=a8328336


SSL証明書購入しないといけないのか?お金かかるな。
というぐらいにしか思わないかもしれませんが、SSL導入するときは、
・SSL証明書をドメイン1つにつき、1つ購入する
・ドメイン1つにつき、1つのグローバルIPアドレスを取得する
という2つの難関を突破しないといけません。
マルチドメイン対応のSSL証明書があるではないか?
と思う方もいると思いますが、マルチドメイン対応証明書は携帯電話には対応しません。今時、モバイル対応できない証明書に意味があるとは思えません。
もっと深刻なのは、グローパルIPの問題です。現在IPv4のIPアドレス枯渇問題が間近に迫る中で、すべてのWEBサイトにグローバルIPアドレスを準備することは到底無理です。
この問題に対応しないデメリットは・・・
リファラが取得できないことにより、アクセス解析ができなくなることです。Google Analyticsではサイトに来た経緯として。「検索エンジン」があり、さらにどのような「キーワード」で検索されて訪問したのかが分かります。
しかし、SSL対応のGoogleから来たユーザーは「https」から「http」にリファラ情報を引き継げないことにより、直接訪れたユーザーのように見えるということです。検索された「キーワード」もわからないので、どうページを変更していくか方針が立てづらくなります。
そもそもGoogleの意図はどこにあるのか?
建前は「エンドユーザのプライバシーを保護するため」となっていますが、途中で解読できなくなるため「自社検索サイトで入力された単語も含めた情報の独占」なのか、それとも自社広告を介しての「Google CAの販売」なのか、後者は話が飛躍しすぎですが、かなり影響は大きいでしょうね。
いずれにしてもプライバシー保護の流れは止まらないでしょうから、近い将来すべてのWEBサイトはSSL化することになりそう!?です。
それともうひとつ、


携帯電話でSSL通信ができないと何が起こるのか?
~ケータイSSL接続検証サービスを開始しました~

携帯電話端末からインターネットアクセスをする際に、SSLで通信を暗号化する場面は多々あります。しかし、携帯電話端末に組み込まれた“ルート証明書”によってはSSLサーバ証明書との暗号化通信ができず、携帯電話端末の画面にエラーが表示されます。エラーの内容は各携帯電話端末の通信方式や機種によって異なり、接続を終了してしまう機種もあります。また、SSLサーバ証明書や中間証明書のサーバ設定を間違った場合にもエラーが表示されます。
弊社では各種携帯電話端末からお客様指定の携帯電話向けサイトにアクセスをして、SSL暗号化通信が正しく行えることを検証するサービスを開始しました。接続検証に関しては、多数の携帯電話端末機種を保有する必要があり検証を正確に実施するための専門的な知識が必要になります。携帯電話向けサイトオープン前の実機検証、お客様からの問い合わせに即時回答するために対応機種を特定しておきたいなどのニーズに応えるサービスです。詳しは以下をご覧ください。
–>> 日本ベリサインの「ケータイSSL接続検証サービス」の詳細はこちら
   http://vmail.verisign.co.jp/c?c=9230&m=37718&v=c6af2618


なんかおかしな気分です。証明書の携帯端末への対応度調査は日本ベリサイン社自身が実施して発表するべき作業です。
自社サイトの証明書がベリサインであれば、サイトのコンテンツにより証明書が影響を受けるわけではないでしょう。
と思っていたら、ベリサイン以外のSSL証明書を使用していても申し込みはできようです。ということは、結果が悪いから自分ところの証明書に替えましょう!と営業かけられるためにお金払う人はいるでしょうか?

SSL証明書 ベリサインの2048bitへの移行日が決まりました

日本のSSL証明書として最も影響のある、日本ベリサイン社の公開鍵長2048bitへの仕様変更日が決まりました。
2010年10月11日(月)
祝日を選んだのは企業の移行に一番支障を来たさないようにという配慮でしょうが、思っていたよりも早いですね。営業情報としては少し前に10月の早い時期という話は聞いていましたが・・・
ベリサイン サーバIDおよびコードサイニング証明書製品における公開鍵長などの仕様変更について(続報)https://www.verisign.co.jp/ssl/about/20100128b.html
それにしても、今回気になるのは、
「5. 旧来仕様のサーバIDの発行継続について」
の内容についてです。
「米国NISTでは1024bit RSAの公開鍵暗号方式の利用を、一定の条件下において2013年末までこれを延長して利用を認めるガイドラインのドラフトを発表しており、現時点では(2010年7月15日時点)パブリックコメントが受け付けられております。この結果が反映された新しいガイドラインは、近い将来に発表される見込みです(詳細時期は現時点では未定)。
弊社では引続き、お客様のセキュリティへのご要望にお応えするために、2048bitRSAへの移行を、上記の通り進めさせていただきますが、同時に、上記のNISTガイドラインのアップデートを踏まえ、「1024bitRSAのCSRの受付期間の延長」および「旧来仕様のサーバIDの受付・発行期間」を延長し、お客様のセキュリティポリシーおよびニーズによっていずれかを選択いただける様にすることを検討しております。」
どういうこと!?でしょうか。
今までは2048bitに完全移行するようなアナウンスでしたが、従来の1024bitも選択できるように検討中に変更されています。ということは、結局しばらくは両方購入できるということのようです。
サイバートラスト社はこの件について、話し合いで1024bitの延長をしたいようなアナウンスを流していますが、ベリサイン社も近い話になってきました。
日本で最も早く2048bitへ仕様変更を表明していたジオトラスト社(販売は日本ベリサイン社)は先週21日と予告された切替日が23日に直前に変更されました。
http://www.geotrust.co.jp/news/2010/20100129.html
今日確認して更新されていないところを見ると、完全に2048bitへ切替が終了したようです。

Apache アクセスログを目的別に分けて出力する方法

携帯サイトで、「Flash待ち受け」「画像待ち受け」「デコメテンプレート」の3種類のダウンロード回数をカウントするサイトを作成したときの話。
それぞれのダウンロード回数をアクセスログの行数(つまり画面に表示した時点でダウンロード)で判断することになった。
その適用方法を紹介します。
# vi /etc/httpd/conf/httpd.conf


#
# For a single logfile with access, agent, and referer information
# (Combined Logfile Format), use the following directive:
#
SetEnvIf Request_URI “decome\.dmt” decome
SetEnvIf Request_URI “decome\.hmt” decome
SetEnvIf Request_URI “decome\.khm” decome
SetEnvIf Request_URI “flash0\.swf” flash
SetEnvIf Request_URI “waiting0\.gif” waiting
CustomLog logs/decome1_log combined env=decome
CustomLog logs/flash_log combined env=flash
CustomLog logs/waiting_log combined env=waiting
CustomLog logs/access_log combined             
→mod_setenvif を使用して該当のファイル名がアクセスログに記録されるタイミングに、各個別ファイルと「access_log」に記録されるようにします。一番後ろにつけた名前(env)によって振分をおこないます。

・・・
CustomLog “| /usr/sbin/rotatelogs /home/fs/www/accesslog/access_log.%Y%m%d 86400 540” combined
CustomLog “| /usr/sbin/rotatelogs /home/fs/www/accesslog/decome0_log.%Y%m%d 86400 540” combined env=decome
CustomLog “| /usr/sbin/rotatelogs /home/fs/www/accesslog/flash_log.%Y%m%d 86400 540” combined env=flash
CustomLog “| /usr/sbin/rotatelogs /home/fs/www/accesslog/waiting_log.%Y%m%d 86400 540” combined env=waiting

→バーチャルホストを使用している場合は、ここにも「CustomLog 」を追加します。最後に「env」を忘れると、うまく振分られないことがありますので、忘れずにつけましょう。


後はできたファイルの行数を数えれば各ダウンロード回数となります。
(注)Basic認証をかけた場合は1回のアクセスで2行追加される場合があります。

米マイクロソフトがWindows XPの販売可能期間をまた延長

米マイクロソフトは2010年7月12日(米国時間)、OEM版Windows 7に付随する「ダウングレード権」の提供期限を延長する方針を明らかにした。
ダウングレード権とは、最新OSのライセンスによって、過去のOSを利用する権利のこと。パソコンにプリインストールされるOEM版Windows 7の場合、Professional以上のエディションでダウングレード権が付与され、Windows Vista BusinessやWindows XP Professionalなどへのダウングレードが可能になる。
現在もなお、メーカーから「Windows XP Professional搭載パソコン」の販売が続いているのは、このダウングレード権を行使しているためだ。こうしたWindows XP搭載パソコンの販売期間が、大幅に延長されることになる。


原因は今に至っても企業のWindowsXPの利用率が80%を越えることがあるようだ。しかし、また延長してマイクロソフトはどうしたいのでしょうね?

CakePHP 1.3.2 接続できるデータベースの種類のはなし

CakePHP バージョン1.3.2をインストールしてみました。
データベース設定ファイルのテンプレート(config/database.php.default)には、バージョン1.2.Xと同様のデータベースが記載されています。


* Database configuration class.
* You can specify multiple configurations for production, development and testing.
*
* driver => The name of a supported driver; valid options are as follows:
* mysql – MySQL 4 & 5,
* mysqli – MySQL 4 & 5 Improved Interface (PHP5 only),
* sqlite – SQLite (PHP5 only),
* postgres – PostgreSQL 7 and higher,
* mssql – Microsoft SQL Server 2000 and higher,
* db2 – IBM DB2, Cloudscape, and Apache Derby (http://php.net/ibm-db2)
* oracle – Oracle 8 and higher
* firebird – Firebird/Interbase
* sybase – Sybase ASE
* adodb-[drivername] – ADOdb interface wrapper (see below),
* odbc – ODBC DBO driver


MySQL、SQLite、PostgreSQL、SQL Server、DB2、Oracle、Firebird、Sybase、ADODB接続、ODBC接続
さてさて、実際にデータソースを覗いてみましょうか。
cake/libs/model/datasources/dbo/
接続できるデータベースの種類のはなし
SQL Server、MySQL、Oracle、PostgreSQL、SQLite ・・・・・・・
・・・・・・・
なんか少なくなったぞ??
調べてみると、他のデータソースはインターネットからダウンロードして入れるようです。
接続できるデータベースの種類のはなし
http://github.com/cakephp/datasources/tree/master/models/datasources/dbo/
ADODB接続、DB2、Firebird、ODBC接続、SQLite3、SQL Server、Sybase ・・・ と。
SQL Serverは「dbo_mssql.php」のほかに「dbo_sqlsvr.php」が新しく用意されたようですね。
全部入れると、かなりにぎやかな状態になりました。
接続できるデータベースの種類のはなし
しかし、標準でインストールされていないデータソースについては、今後データソースがバージョンアップされてもCakePHP本体に入っていないということになりますので、自分で時々のぞきに来る必要がありそうですね。
今回は、CentOS上のCakePHPからWindowsServer上のSQL Serverにネイティブ接続してみたかったのですが、新しいデータソースが出たのも役立たず・・・、結局LinuxにはSQL Serverに接続するネイティブドライバが容易されていませんから。
そう考えると、「SQL Server (dbo_mssql.php)」「SQL Server (dbo_sqlsvr.php)」「ADODB接続」については、Windows専用ということですね。まぎらわしいなあ・・・もう。

NTPサーバの設定

RTX1100の設定不足でNTP同期できなかった問題が解決したところで、NTPサーバの設定をまとめておきます。
OS:CentOS 5.5 最小インストール
NTPサーバ:ビジネスぷらら
プライマリ:ntp2.plala.or.jp
セカンダリ:ntp1.plala.or.jp
NTPをインストールします。
# yum install ntp
今日現在インストールされるバージョンは「4.2.2p1-9.el5.centos.2.1」となります。
設定ファイルを編集します。
# vi /etc/ntp.conf
既存のIPv4、IPv6用の問い合わせをコメントアウトし、すべての外部からの問い合わせの拒否を追加します。
# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
#restrict default kod nomodify notrap nopeer noquery
#restrict -6 default kod nomodify notrap nopeer noquery
restrict default ignore

IPv6用のループバックアクセスをコメントアウトします。
# Permit all access over the loopback interface. This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1
#restrict -6 ::1

今回使用するビジネスぷららのNTPサーバを追加します。
# Hosts on local network are less restricted.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
restrict 219.164.211.137 mask 255.255.255.255 nomodify notrap noquery
restrict 219.164.211.129 mask 255.255.255.255 nomodify notrap noquery

既存のNTPサーバをコメントアウトし、ビジネスぷららのNTPサーバを追加します。
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
#server 0.centos.pool.ntp.org
#server 1.centos.pool.ntp.org
#server 2.centos.pool.ntp.org
server ntp2.plala.or.jp
server ntp1.plala.or.jp

最後にローカルで同期するのを停止します。
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
#server 127.127.1.0 # local clock
#fudge 127.127.1.0 stratum 10

自動起動するようにデーモンを設定します。
# chkconfig –level 3 ntpd on
デーモンを起動する
# service ntpd start
10分後ぐらいに同期を確認します。
# ntpq -p
remote refid st t when poll reach delay offset jitter
=============================================================
+ntp2.plala.or.j 202.234.233.109 4 u 30 64 377 14.117 23.350 7.381
*ntp1.plala.or.j 202.234.233.109 4 u 33 64 377 13.983 29.240 3.461
先頭に「*」が付いたNTPが現在の同期サーバーとして、「+」が付いたNTPが予備サーバーとして正常に同期したことを示しています。
現在の時刻を確認して終了です。
# date