ネクスト研究日記

中国が神舟７号を宇宙空間へ射出し、無事帰還。宇宙遊泳もした！と各メディアは伝えているが・・・・？

あ・・・あれ・・・？？？何か泡のようなものが・・・

PHPとJavaScriptのURIエンコードを比較
追記　: 2005.7.16 PHPのurlencode()が空白文字を「+」に変換する件

Ajaxでは、サーバーからデータを受信する際、生のテキスト文字列を使用すると、 responseText,responceXMLそれぞれに文字化けするブラウザがあります。[ 参考:->文字化け調査 ]

これは、Ajaxでの送受信時には、Formの時のようにブラウザが自動でURIエンコード/デコードをしてくれるわけではない、ということに起因すると言えるかもしれません。

一般的には、Formの動作に見られるように、URIエンコードして送受信することで、安全でない文字などが引き起こす、いろいろな問題を回避しようとするわけです。(AjaxでGETやPOSTでの送出時は、ブラウザが自動ではエンコードしてくれない以上、プログラマーの義務ではないかという気がしています。POSTならsetRequestHeader()で、GETなら自前で、、、。)この時、使えるメソッドとして、JavaScriptには、 escape()、encodeURI()、そして、encodeURIComponent() があります。

このうち、escape()は、古いメソッドで、ブラウザにより実装が異なるため使わない方が安全です。残りの、encodeURI()とencodeURIComponent()は、ECMAScriptの仕様に従ったメソッドで、現在流通しているブラウザなら共通に動作するはずです。

ありがたいことに、この２つのメソッドは、ページのcharset(Shift_JIS,EUC,UTF-8,,,)が何であっても、UTF-8 としてエンコードしてくれます。つまり、「Shift_JISからEUCへ」など異なったcharset環境間でデータを受け渡す場合にも必ず「UTF- 8」として明示的にエンコードされたデータとして受け渡せるので安心です。

したがって、もし、サーバーから静的ファイルを取ってくるだけなら、JavaScriptのURIエンコードメソッドで変換した文字列をサーバーにおいておけば、JavaScriptによるAjaxでの受信は、どのブラウザでも同じ種類のデコードメソッドを使えるので文字化けしなくなります。

ところが、サーバーから動的に受信する場合は、あらかじめJavaScriptによるエンコードができません。つまり、サーバー側のPHPなど他の言語でURIエンコードされたものをJavaScriptでデコードしないといけないのです。でも、URIエンコードの実装は、実は、言語によって異なっています。。。そこで、他の言語でのエンコードとJavaScriptエンコード、そしてデコードの違いを実際に確認してみます。今回はPHPです。

もし、問題なくAjaxで受信してデコードされるならそれを使えば良いし、もし、多少の違いがあるなら、そこを修正すれば良いと、いうわけで、、。

比較する文字列
;/?:@&=+$%-_!~*{}[].,()”あa^# ‘
(#の後ろに空白文字があります)
PHP

$data  = ‘;/?:@&=+$%-_!~*{}[].,()”あa^# ‘.”‘”;

mb_http_output ( ‘UTF-8′ );
$data = mb_convert_encoding($data,”UTF-8″,mb_internal_encoding());

$html  = “<br><b>urlencode() : </b><br>”.urlencode($data);
$html .= “<br><b>rawurlencode() : </b><br>”.rawurlencode($data);

echo($html);

urlencode() :
%3B%2F%3F%3A%40%26%3D%2B%24%25-_%21%7E%2A%7B%7D%5B%5D.%2C%28%29%22%E3%81%82a%5E%23+%27
rawurlencode() :
%3B%2F%3F%3A%40%26%3D%2B%24%25-_%21%7E%2A%7B%7D%5B%5D.%2C%28%29%22%E3%81%82a%5E%23%20%27

–>PHPがエンコードしない文字列

-_.a

注意:urlencode()は、空白文字を「+」に変換し、rawurlencode()は「%20」に変換するという違いがあります。
JavaScript

var data = ‘;/?:@&=+$%-_!~*{}[].,()”あa^# ‘+”‘”;

var enchtml = ‘<br><b>encodeURI() : </b><br>’+encodeURI(data)
enchtml + ‘<br><b>encodeURIComponent() : </b><br>’+encodeURIComponent(data)

document.write(enchtml)

encodeURI() :
;/?:@&=+$%25-_!~*%7B%7D%5B%5D.,()%22%E3%81%82a%5E#%20′

–>encodeURI()がエンコードしない文字列

;/?:@&=+$-_!~*.,()a#’

encodeURIComponent() :
%3B%2F%3F%3A%40%26%3D%2B%24%25-_!~*%7B%7D%5B%5D.%2C()%22%E3%81%82a%5E%23%20′

–>encodeURIComponent()がエンコードしない文字列

-_!~*.()a’

結論1
つまり、PHPとJavaScript(ECMAScript)のURIエンコードは、違うのです。
では、デコードするとどうなるでしょう？

デコード : PHP urlencode() → JS decodeURIComponent()

<?php

$data  = ‘;/?:@&=+$%-_!~*{}[].,()”あa^# ‘.”‘”;

mb_http_output ( ‘UTF-8′ );
$data = mb_convert_encoding($data,”UTF-8″,mb_internal_encoding());

?>

<script>

//PHPでエンコード
datad = “<?php echo(urlencode($data)); ?>”

//JavaScriptでデコード
document.write(”<br>”+decodeURIComponent(datad))

</script>

PHP urlencode()でエンコード
%3B%2F%3F%3A%40%26%3D%2B%24%25-_%21%7E%2A%7B%7D%5B%5D.%2C%28%29%22%E3%81%82a%5E%23+%27

JS decodeURIComponent()でデコード
;/?:@&=+$%-_!~*{}[].,()”あa^#+’

–>encodeURIComponent()はエンコードしないが、decodeURIComponent()がデコードした文字列

!~*()’

(-_.aは、PHP がエンコードしません。)

おお、encodeURIComponent()でエンコード出来なかった文字までデコード出来てる!

てことは、PHP–>JS なら、「utf-8化してurlencode()」–>「decodeURIComponent()」で、使えるのでしょうか？
うーん、、、でも、これって、ECMAの仕様的にOKなんでしょうか？よくわかりません、、、。

この組み合わせの場合、最大の問題は、urlencode()によって「+」に変った空白文字がそのままなため普通の「+」と区別がつかなくなること。 ということで、次は、空白文字をencodeURIComponentと同じ「%20」に変換する、rawurlencode()で試してみましょう。

デコード : PHP rawurlencode() → JS decodeURIComponent()

<?php

$data  = ‘;/?:@&=+$%-_!~*{}[].,()”あa^# ‘.”‘”;

mb_http_output ( ‘UTF-8′ );
$data = mb_convert_encoding($data,”UTF-8″,mb_internal_encoding());

?>

<script>

//PHPでエンコード
datad = “<?php echo(rawurlencode($data)); ?>”

//JavaScriptでデコード
document.write(”<br>”+decodeURIComponent(datad))

</script>

PHP rawurlencode()でエンコード
%3B%2F%3F%3A%40%26%3D%2B%24%25-_%21%7E%2A%7B%7D%5B%5D.%2C%28%29%22%E3%81%82a%5E%23%20%27

JS decodeURIComponent()でデコード
;/?:@&=+$%-_!~*{}[].,()”あa^# ‘

–>encodeURIComponent()はエンコードしないが、decodeURIComponent()がデコードした文字列

!~*()’

(-_.aは、PHP がエンコードしません。)

おお、こんどこそデコード出来てる!
、、、他に問題ないかなぁ、、、(^^;。
結論2
PHPは、 utf-8化 + rawurlencode() → JS decodeURIComponent() この組み合わせで、行けそうかも？

実験してみました
Allabout Ajax/動的なテーブル書き換え2 (+PHP)
クライアント側のスクリプト
サーバー側のスクリプト

参考 ：
ECMA-262 3rd
15.1.3 URI 処理関数のプロパティ (URI Handling Function Properties)

HTML 4.0( 日本語訳 )
17.13.3 フォーム・データの処理
methodが”get”で、 actionがHTTP URIである場合は actionの値を取り、それに`?’を付け、次いで “application/x-www-form-urlencoded” content typeを使ってコード化されたフォーム・データ・セットを追加します。そしてリンクをURIにわたします。この過程でフォーム・データはASCIIコードに限定されます。
methodが”post”で actionがHTTP URIの場合は、 action属性を使ってHTTP “post”処理と enctype属性によって特定された 内容タイプに従って作成されたメッセージを伝えます。
：
application/x-www-form-urlencoded urlencoded
これは、初期内容タイプです。この内容タイプで転送されたフォームは、以下の様にコード化されなければなりません：

制御名と値は、入れ替え（エスケープ）られます。空白文字符号は `+’に置き代えられてから、貯えられた文字符号は [RFC1738]、セクション2.2に記載されている様に置き代えられます：非英数文字符号は`%HH’で、パーセント記号や十六進法数値はASCII コードに。強制改行は “CR LF”の組（例、 `%0D%0A’）で代表されます。 制御名前／値は文書に現われる順番にリストされます。名前は `=’で分けられ、名前／値は `&’でお互いに分けられます。

:
:
enctype = content-type [CI] この属性は、サーバーにフォームを転送するために使われる content typeを特定します（ methodの値が”post”の場合）。この属性の初期値は、 “application/x-www-form-urlencoded”です。 “multipart/form-data”値は、 type=”file”のある INPUT要素と組で使わなければなりません。

HTML 4.01( 日本語訳 )
17.13.3 フォーム・データの処理

RFC1738 Uniform Resource Locators (URL) ( 日本語訳 )
2.2. URL 文字エンコーディングの問題
＊これはRFC 1738とRFC 1808で定められた書き方を改めるものです。
2.2. 予約文字　Reserved Characters

URI 構成要素のデータが予約された目的と衝突するならば、対立するデータは、 URI を形成する前に回避されなければなりません。
reserved = “;” | “/” | “?” | “:” | “@” | “&” | “=” | “+” | “$” | “,”

2.3. 予約されていない文字　Unreserved Characters

URI で許されるが予約された目的がないデータ文字は、非予約文字と呼ばれます。これは大文字・小文字（のアルファベット）、十進法の数字、そして句読点や記号の限られた集合を含みます。
unreserved = alphanum | mark
mark = “-” | “_” | “.” | “!” | “~” | “*” | “‘” | “(” | “)”
非予約文字は、 URI の意味論を変えることなく回避することができます。しかし URI が現れるために、 unescape された文字を許さない文脈で使用されているのでなければ、これは行なわれるべきではありません。

2.4.1. 回避符号化　Escaped Encoding

略..パーセント文字”%”と、その後に続く..略..16進法による数字2桁から構成されています。例えば、”%20″はUS-ASCII空白文字の回避された符号化です。

2.4.2. 回避するときとしないとき　When to Escape and Unescape

(たとえば)　”%25″ を URI のデータとして使用する際は、これを回避しなければなりません。
reserved = “;” | “/” | “?” | “:” | “@” | “&” | “=” | “+” | “$” | “,”

2.4.3. 排除される US-ASCII 文字　Excluded US-ASCII Characters

空白を表す文字は排除されます。
space = <US-ASCII coded character 20 hexadecimal>

山形括弧 “<” と “>” そして二重引用符 (”) は排除されます。なぜなら、これらはしばしばURI周辺の区切り子として文書や作法の分野で使われるからです。 “#” 記号は排除されます。なぜなら、これはURIを、URI参照中のフラグメント識別子(第4項)から区切るのに使われるからです。百分率記号は排除されます。なぜなら、これは回避された文字の符号化に使われるからです。
delims = “<” | “>” | “#” | “%” | <”>

その他の文字は排除されます。なぜならそのような文字は、gatewaysなどの転送手先が往々にして書き変えたり、区切り子として使われたりすることがわかっているからです。
unwise = “{” | “}” | “|” | “\” | “^” | “[” | “]” | “`”
排除された文字に対応するデータは、URI内で適切に表示されるように、必ず回避されなくてはなりません。

RFC1738 Uniform Resource Locators (URL) ( 日本語訳 )
2.2. URL 文字エンコーディングの問題
8ビット文字は文字 “%” に続く 8ビット文字の 16進数値となる 2 つの 16進数 (”0123456789ABCDEF”) の 3文字により符号化される。(文字 “abcdef” も 16進数符号化で使われるだろう。)

8ビット文字は、もしそれらが US-ASCII コード文字セット内の印字可能な文 字でない場合、その文字の使用が安全でない場合、もしくはそれが特殊な URL スキーム内で何か別の処理のために予約されている場合に符号化されなければ ならない。

Ajaxで非同期通信をするときに待機中の暇な時間にアニメーションGIFを表示することが多いが、

そのアニメーションGIFをWeb上で作成できるサービスがこのサイト↓
http://www.ajaxload.info/

『標準偏差の本当の使い方』

標準偏差　その５

『標準偏差の本当の使い方』
実際のところここまで使いこなす必要があるかというとそうでもない、
なんとなく興味があってついつい調べ始めてしまったら止まらなくて標準偏差を極めてみただけ。

一般的な使い方は標準偏差σ、平均uでは

u－σ≦P≦u＋σ

の範囲では全体の68.27％が含まれているというものから、
この範囲を±２σにすると

u-2σ≦P≦u＋2σ

このときの値もエクセルの関数に代入すると求められて、
そのときの解は

P＝95.45％

平均50、σ＝10なら2σ＝20

50±20　30≦P≦70　この範囲に入る確率が95.45％となる。

ここまでいけば全数のほとんどが範囲内にはいっているということになる。
さらにさらに3σではどうなるのだろうか？

答えは

20≦P≦80　P＝99.73％

となり、0.3％以外すべてこの範囲に入っていることになる。

これらを図に表すとこのようになる。

さらにさらにさらに4σでは？10≦P≦90　P＝99.9937％となる全体の0.006％以外はすべてこの範囲になる。

さらにさらにさらにさらに・・・

ってどこまでいくねん！

とそろそろ付き合いきれなくなると思われるので、
ここでの意味を考えると、

工業製品では4σという規格値がある。
私もまったく知らなかったんだけど、ふとしたときに4σという規格がよく使われていることを知る。

この4σというのがまさにこの標準偏差の値なのです。

もし10cmの定規を作るのに誤差±0.1cmまでが規格値で製品として合格になるとする。

このときの標準偏差が0.1なら

1σ＝0.1　9.9≦P≦10.1　68.27％
2σ＝0.2　9.8≦P≦10.2　95.45％
3σ＝0.3　9.7≦P≦10.3　99.73％
4σ＝0.4　9.6≦P≦10.4　99.9937％

よって規格値にはいるレベルは1σなので68.27％しか製品として使えないことになる。

もし4σレベルで合格の製品を作りたいなら誤差0.1／4＝0.25

σ＝0.25のときに4σ＝0.1となり、
9.9≦P≦10.1　99.9937％
というレベルの製品合格率をだすことができる。

求めるレベルによって必要な標準偏差の値を決めることが製品規格における規格値となるのです。
そこで私がこの4σを知ることになったきっかけが6σという言葉から、
普通の会社は4σを基準にしているけどGE社（ゼネラルエレクトリック、世界最大の株式時価総額の会社）は6σを基準にすることにしたという話。

これは製品不良品率の話で普通の会社は4σで1000万個の製品を作ると
4σでは99.9937％の確率で不良品が発生することになり

10000000×(1－0.999937)＝630個

この数の不良品が発生する、
このなかで経営に深刻な影響を与える（全品回収など）確率が1%なら6.3個も存在することになる。
0.1%でも0.63個になり、1億個つくれば6.3個になり、作った分だけそのときの被害も極大になる。
そこで6σにするとどうなるか？

確率P＝99.9999998

100万個つくたったとすると

1000000×（1－0.999999998）＝0.02個

深刻な影響の確率が1%でも0.0002個しかなく、0.1％では0.00002個になる。
確率的には100億個作るとやっと2個の深刻な不良品が発生することになる。

さすがにこの確率ならもう深刻な不良品はないとみてもいい。

ソースFrom

http://www.nabe-scm.com/weblog/archives/calendar/2007/09/01-index.php

「.htaccess」を利用したアクセス制限は、私が利用している又は、利用するかもしれないアクセス制限のみを掲載いたします。
また、「.htaccess」を利用した場合、任意のアクセス制限を設けたいディレクトリに設置・以下ディレクトリが同様に設定されるなど「個別単位」での設定となります。
サーバー全体の設定をする場合には、「httpd.conf」にて設定を行ないます。
ここでは、「.htaccess」を利用した内容で掲載しています。
「.htaccess」を利用する場合は、「httpd.conf」へ設定有効にする指示をする必要がありますので、機能を利用する場合にはこちらにて設定指示を行なってください。
「.htsccess」記述後の最終行は必ず「改行」を行なっておいてください。

1. 特定の場所からのリクエストを拒否する
2. 特定の場所からのリクエストを許可する
3. Referer：自ドメインURLからのみアクセス許可
4. Referer：参照元によるアクセス制限
5. ブラウザ経由で特定のファイルへのアクセスを拒否する

---

【特定場所からのリクエストを拒否する】・・・招かざる客用に。

order allow,deny
allow from all
deny from aaa.bbb.ccc.ddd　　　　※特定したIPアドレスを拒否
deny from aaa.bbb.　　　　　　　　　※aaa.bbb.以下IPアドレスを拒否
deny from aaa.bbb.ccc.ddd/15　　※ネットマスク範囲を拒否
deny from .abc.co.jp　　　　　　　　※ .abc.co.jpのドメインを拒否

悪戯目的で不正アクセスを試みる輩や、小遣い目的でのBBS書き込みなどを頻繁に行なう場合等に。

【特定場所からのリクエストを許可する】

order deny,allow
deny from all
allow from aaa.bbb.ccc.ddd　　　　※特定したIPアドレスを許可
allow from aaa.bbb.　　　　　　　　　※aaa.bbb.以下IPアドレスを許可
allow from aaa.bbb.ccc.ddd/15　　※ネットマスク範囲を許可
allow from .abc.co.jp　　　　　　　　※ .abc.co.jpのドメインを許可

特定のディレクトリへ、LAN内からのみアクセス可能にする等に。

【Referer：自ドメインURLからのみアクセス許可】・・・他サイトからのリンク拒否

SetEnvIf Referer “^http://www\.aaa\.ne\.jp” ref_ok
order deny,allow
deny from all
allow from env=ref_ok

自分が使用しているドメインからのみアクセスがあった場合にページ表示させる。
Refererに登録URLが含まれている場合にのみページ・画像を表示するようになります。
但し、ブラウザRefererがNorton等によって遮断されている場合にも、ページ表示出来ない場合も考えられるので、予め説明ページなどを設けておく配慮が必要。
その為、TOPページからこの設定はあまり好まれないが、以下ディレクトリからの設定は有効と考えます。

【Referer：参照元によるアクセス制限】・・・画像直リンク防止などに

SetEnvIf Referer “^http://www\.aaa\.ne\.jp” ref_ng1
SetEnvIf Referer “^http://www\.bbb\.com” ref_ng2
order allow,deny
allow from all
deny from env=ref_ng1
deny from env=ref_ng2

他サイトからの画像に対する直リンクなどを防止。
画像をまとめて置いてあるディレクトリへ設置します。
Refererに登録URLが含まれている場合にのみ画像データ転送を拒否します。

【ブラウザ経由で特定のファイルへのアクセスを拒否する】・・・特定ファイル閲覧防止に。

<Files ~ “\.(dat|log)$”>
deny from all
</Files>

BBSのログ等、投稿者のグローバルIPアドレス情報保護等に。
直接ブラウザでファイル名などをURLとして指定された場合、対処していないと閲覧可能な状態になっています。
BBSのCGIスクリプトを利用した場合に、過去ログなどのデータの呼び出しは可能です。
「httpd.conf」にて設定をしている場合には、これは必要ありません。

---

ここまでの設定方法を見た通り、「allow」と「deny」が頻繁に出てきます。
allow・・・許可をする
deny・・・拒否をする
と言う意味を持っています。
記述の際、間違えて反対にならないように注意しましょう。

JPG,PNG、GIFに埋め込まれた攻撃コードを除去するには

・JPGの場合：JPG→PNG（TrueColor)→JPGと変換

・PNGの場合：PNG→PNG（TrueColor)→PNGと変換

・GIFの場合：GIF→PNG（TrueColor)→PNGと変換

上位の3つのファイルを扱うことが多いが、これで攻撃コードを削除できるようだ。

参考URL
http://d.hatena.ne.jp/butyricacid/20070820/1187561183

CERNでブラックホールを作るといった実験が本日9月10日の16時から行われているはずだが、

Live　WebCastにアクセスが集中しているのか全く見ることができない・・・。

きっと誰かがYoutubeかニコ動へうｐしてくれるはず！

Live中継

http://webcast.cern.ch/

PHPインストール時に暗号化モジュールのmcryptエラーと言うのが下に出るが、そのインストール方法

#yum -y install php-mcrypt.

端末で上記を実行してインストールするだけで消えます。

Tomcatでは、サーブレットをどこに配置すればいいのか？

それでは一通り設定が終わったところで、まずは簡単なサーブレットを作成して動作を確認してみましょう。まずは、Tomcatのドキュメントルートのディレクトリへ移動します。

cd /opt/tomcat6/webapps/ROOT/

ドキュメントルート以下には、classファイルやweb.xmlなどの外から直接アクセスさせないデータを格納しているWEB-INFディレクトリが存在しているので、WEB-INFディレクトリへと移動します。

cd WEB-INF

ディレクトリを移動してファイルを見てみると、サーブレットなどのクラスファイルを保存するためのディレクトリが存在せず、「web.xml」しか存在しないことが分かります。

「HelloWorld!」のコードを作成する前に、クラスファイルを格納するための「classes」ディレクトリを作成します。

mkdir classes

これでサーブレットを作成する準備が整いました。「classes」ディレクトリ配下に移動します。

cd classes

■ サンプルファイルの作成

エディタを用いて「HelloWorld.java」を作成します。

vi HelloWorld.java

ファイルの中身は以下のように記述します。

import java.io.*; import javax.servlet.*; import javax.servlet.http.*;public class HelloWorld extends HttpServlet { public void doGet(HttpServletRequest request ,HttpServletResponse response) throws IOException, ServletException{ response.setContentType(”text/html”); PrintWriter out = response.getWriter(); out.println(”<html>”); out.println(”<head>”); out.println(”<title>Hello World!</title>”); out.println(”</head>”); out.println(”<body>”); out.println(”<h1>Hello World!</h1>”); out.println(”</body>”); out.println(”</html>”); } }

■ サンプルファイルをコンパイルしよう

サーブレットを作成したら、コンパイルを行います。コンパイル時には必ずclasspathの指定を忘れないようにしてください。

javac -classpath /opt/tomcat6/lib/servlet-api.jar HelloWorld.java

これで一通り準備は完了しました。

■ web.xmlにサーブレットを登録

しかし、サーブレットを作成したとはいえ、この状態のままページへアクセスしてもHelloWolrdの実行結果は表示されません。「web.xml」への登録が必要です。

/opt/tomcat6/webapps/ROOT/WEB-INFの配下にあった「web.xml」をエディタで開きます。

vi /opt/tomcat6/webapps/ROOT/WEB-INF/web.xml

ファイル内部に書かれている<web-apps>と</web-apps>のタグの間へ次の行を追加します。

<servlet> <servlet-name>HelloWorld</servlet-name> <servlet-class>HelloWorld</servlet-class> </servlet><servlet-mapping> <servlet-name>HelloWorld</servlet-name> <url-pattern>/HelloWorld</url-pattern> </servlet-mapping>

これで初めてサーブレットとしてURLから呼び出すことができるようになります。

■ 表示をして確認

次のような画面が表示されれば、「Hello World!」サンプルの作成を通した設定確認は完了です。

図4　「Hello World!」を表示 ソースFrom http://www.atmarkit.co.jp/fjava/rensai4/safetomcat_01/safetomcat_01_2.html

Tomcatを自動的に起動するには？

■ 手動での起動は管理しづらいから

インストールしたままのTomcatには、起動用のスクリプトなどは用意されておらず、このままでは毎回手動で起動しなくてはなりません。毎回手動で起動するのは、担当者により気分でオプションが変わったり、コマンドを間違えたりする可能性も考えられ、管理も煩雑になります。

そこで、Tomcatを起動するための専用スクリプトを作成しましょう。

■ Apache Commons DaemonでTomcatをデーモン化

その前に、プロセスの管理を容易にするために、Apacheのトップレベルプロジェクトの1つのCommonsプロジェクトに含まれているDaemonコンポーネントを利用して、Tomcatをデーモン（自動プロセス）化します。

注意！

Commons-DaemonプロジェクトのファイルはインストールしたTomcatの配下にある「/bin」ディレクトリ内に「jsvc.tar.gz」として格納されています。

まず、このファイルを一時的に/tmpなどの一時ディレクトリへ移動します。

mv -f /opt/tomcat6/bin/jsvc.tar.gz /tmp/

ファイルを移動したら先ほどの一時ディレクトリへ移動してファイルを解凍します。

cd /tmp tar -xzf jsvc.tar.gz

ファイルを解凍すると、「jsvc-src」というディレクトリが作成されます。その「jsvc-src」のディレクトリへ移動します。

cd jsvc-src

ディレクトリを移動したらautoconfを利用してconfigureスクリプトを作成します。

autoconf

configureスクリプトを作成したら、configureスクリプトを実行します。

sh configure

configureが完了したら、ビルドに取り掛かります。

make

ビルド後には「jsvc」というファイルが作成されます。作成されたjsvcの所有権をtomcatへと変更し、tomcatのインストールされているディレクトリ以下のbinディレクトリへと移動します。

chown tomcat. jsvc mv -f jsvc /opt/tomcat6/bin

後は、ビルドに利用したディレクトリとファイルを削除して、ビルドは完了です。

rm -rf /tmp/jsvc-src/ /tmp/jsvc.tar.gz

これで、Tomcatをデーモン化して動作させることができるようになりました。

■ 自動起動させるためのスクリプトを作成

それでは、今度は自動起動させるためのスクリプトを作成します。エディタを用いて「/etc/rc.d/init.d/」以下にjsvcという名前の起動スクリプトを作成します。

vi /etc/rc.d/init.d/jsvc

スクリプトの中身は以下のとおりです。

#!/bin/sh # # chkconfig: - 80 20 # description: jsvc # Source function library. . /etc/init.d/functions JAVA_HOME=/usr/java/jdk1.5.0_12 CATALINA_HOME=/opt/tomcat6 TOMCAT_USER=tomcat TMP_DIR=/tmp CATALINA_OPTS= CLASSPATH=\ $JAVA_HOME/lib/tools.jar:\ $CATALINA_HOME/bin/commons-daemon.jar:\ $CATALINA_HOME/bin/bootstrap.jar PIDFILE=/var/run/tomcat.pid LOCKFILE=/var/lock/subsys/tomcat DAEMON=$CATALINA_HOME/bin/jsvc start(){  # # Start Tomcat # echo -n “Starting jsvc: ” $DAEMON \ -pidfile $PIDFILE \ -user $TOMCAT_USER \ -home $JAVA_HOME \ -Dcatalina.home=$CATALINA_HOME \ -Djava.io.tmpdir=$TMP_DIR \ -outfile $CATALINA_HOME/logs/catalina.out \ -errfile ‘&1′ \ $CATALINA_OPTS \ -cp $CLASSPATH \ org.apache.catalina.startup.Bootstrap # # To get a verbose JVM #-verbose \ # To get a debug of jsvc. #-debug \ RETVAL=$? if [ $RETVAL = 0 ]; then echo_success touch $LOCKFILE else echo_failure fi echo } stop(){  # # Stop Tomcat # echo -n “Shutting down jsvc: ” $DAEMON \ -stop \ -pidfile $PIDFILE \ org.apache.catalina.startup.Bootstrap RETVAL=$? if [ $RETVAL = 0 ]; then echo_success rm -f $PIDFILE $LOCKFILE else echo_failure fi echo } case “$1″ in start) start ;; stop) stop ;; restart) stop start ;; status) status $DAEMON RETVAL=$? ;; *) echo $”Usage: jsvc {start|stop|restart|status}” exit 1 ;; esac

注意！

スクリプトの作成が終わったら、ファイルに実行権限を与えます。

chmod +x /etc/init.d/jsvc

スクリプトに実行権限を与えたら、最後にchkconfigを実行して起動時のON／OFF設定を行って終了です。

chkconfig jsvc on

以上で、Tomcatの自動実行の設定が完了しました。これで、サーバを再起動したときに自動的にTomcatが起動するようになります。

TomcatとApacheを連携させるmod_proxy_ajp

■ 8080番ポートと80番ポートの謎

Tomcat には、簡易Webサーバとしての機能も有しているため、デフォルトの状態では8080番ポートを利用して通常のHTMLページを含んださまざまなWeb ページの表示ができます。しかし、インターネットを利用していてもWebページ閲覧中に8080番ポートへと転送されるようなケースには巡り合うことはあ りません。

ということは、Tomcatを80番ポートに変更してサーバを運用しているのでしょうか？ 恐らくほとんどどのケースはこれに当てはまりません。

TomcatのWebサーバ機能は簡易機能しか有しておらず、専用のWebサーバに比べると機能やパフォーマンスの面で劣ります。それでは、どのようにして80番ポートだけでWebサーバとTomcatの両方を利用しているのでしょうか？

■ TomcatとWebサーバを連携させて解決

Tomcatは、ほかのWebサーバと連携する機能が充実しているため、Webサーバと連携させて利用できるようになっています。この連携の仕組みを利用することでWebページの表示パフォーマンスの改善やさまざまな制御を行っているのです。

特に、WebサーバのApacheとは同じ団体が管理していることもあり親和性に優れています。バージョンによって異なるいくつかの連携の方法がありますが、今回は「CentOS 5.0」をOSとして利用しているため、最新のApache 2.2系列での連携方法を取り上げます。

いままでのApache 2.0系列やApache 1.3系列では、Tomcatとの連携にmod_jkと呼ばれるコネクタモジュールを必要としていました。Apache 2.2系列では、いままでのバージョンとは異なり、Apacheの基本コンポーネントとして連携用の機能を備えているため、モジュールを追加する必要がなくなりました。

編集部注：Apache 2.2について詳しく知りたい読者は、Linux Square の記事「Apache 2.2でWebサイトをパフォーマンスアップ！」Apache 2.0については、同じく「Apache 2.0の新機能とその実力」をご参照ください。

■ mod_proxy_ajpを利用するには？

通常、TomcatとApacheの通信は“AJPコネクタ”という機能を利用して実現しています。Apache 2.2系列では、mod_proxy_ajpと呼ばれるモジュールを利用することで簡単にTomcatとの連携を実現しています。

Apacheの設定ファイル（httpd.confなど）において以下の2つのモジュールを読み込ませることでこの機能を利用できるようになります。

LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_ajp_module modules/mod_proxy_ajp.so

CentOS 5.0では、初期状態でこれらの設定ファイルは読み込まれるようになっているので、特に変更の必要はありません。

それでは、実際に「/tomcat」というディレクトリにアクセスする場合と通常のTomcatのトップページへアクセスする場合と同じ設定を行ってみましょう。

そのためには、エディタを用いてApacheの設定ファイル（httpd.confなど）へ以下の行を追加します。

ProxyPass /tomcat/ ajp://localhost:8009/

CentOS 5.0では、ajpの設定は専用のファイル「/etc/httpd/conf.d/proxy_ajp.conf」が存在しているので、このファイルにまとめて書くのが好ましいでしょう。

vi /etc/httpd/conf.d/proxy_ajp.conf

注意！

この設定を行いApacheの再起動を行えば、以下のようなページへのアクセスが可能となります。

図3　Tomcatのサンプルページ

以上で、ApacheとTomcatの連携設定は完了です。いよいよ次ページではセットアップした環境でサーブレット／JSPを表示させます。