よみがな　あり｜なし

ＧＣＰでウェブサーバ構築(こうちく)チャレンジ、６ログ目(め)です。
前回(ぜんかい)はLinux/Debianのapache2のバーチャルホストの設定(せってい)方法(ほうほう)を確認(かくにん)しました。
今回(こんかい)は、CGIを動作(どうさ)させることを目指(めざ)します。

１．OptionsとAllowOverRideの設定(せってい)

前回(ぜんかい)のログで作成(さくせい)したexample.confに書(か)かれた＜Directory＞～＜／Directory＞の内部(ないぶ)には、ルートディレクトリ以下(いか)の動作(どうさ)設定(せってい)が記述(きじゅつ)されます。そのなかでも構成(こうせい)要素(ようそ)（ディレクティブ）OptionsとAllowOverRideの設定(せってい)がとくに大事(だいじ)です。

｜　Options

ディレクトリにさまざまな機能(きのう)をＯＮにしたりＯＦＦにしたりします。
設定(せってい)は＜Directory＞～＜／Directory＞の下(した)にあるすべてのディレクトリとファイルに適用(てきよう)されます。

None
特(とく)に何(なに)も設定(せってい)されず。特殊(とくしゅ)な機能(きのう)を一切(いっさい)使(つか)わないとき。

All
MultiViews を除(のぞ)いた全(すべ)ての機能(きのう)が有効(ゆうこう)。

ExecCGI
cgiの実行(じっこう)を許可(きょか)

FollowSymLinks
シンボリックリンクのリンク先(さき)をApacheがたどれるようにする

Includes
SSIの使用(しよう)を許可(きょか)

IncludesNOEXEC
SSIは許可(きょか)するが、SSIから外部(がいぶ)cgiを呼(よ)び出(だ)すexecを禁止(きんし)

Indexes
index.htmlが見当(みあ)たらないとき、ディレクトリ内(ない)ファイルの一覧(いちらん)を表示(ひょうじ)

MultiViews
ブラウザから送信(そうしん)されるヘッダにあわせてレスポンスを変(か)える機能(きのう)をＯＮにする。
たとえば、使用(しよう)言語(げんご)に合(あ)わせたファイルを返(かえ)すといった使(つか)い方(かた)が可能(かのう)になる。

スタジオムーンリーフの場合(ばあい)、使(つか)いたい機能(きのう)はExecCGIとIncludesです。

｜　AllowOverRide

.htaccessで使用(しよう)できる機能(きのう)を制限(せいげん)したりします。

None
.htaccessではなにも設定(せってい)できない

All
.htaccessで設定(せってい)可能(かのう)なものはすべて使用(しよう)可能(かのう)

AuthConfig
認証(にんしょう)関連(かんれん)の構成(こうせい)要素(ようそ)を使用(しよう)可能(かのう)に。
.htaccessを使(つか)って基本(きほん)認証(にんしょう)などをする場合(ばあい)はこの設定(せってい)が必要(ひつよう)

FileInfo
ドキュメントタイプやドキュメントのメタデータを制御(せいぎょ)する構成(こうせい)要素(ようそ)が使用(しよう)可能(かのう)に。
（よくわかりません）

Indexes
ディレクトリインデックス関連(かんれん)の構成(こうせい)要素(ようそ)が使用(しよう)可能(かのう)に。

Limit
アクセス制御(せいぎょ)関連(かんれん)の構成(こうせい)要素(ようそ)が使用(しよう)可能(かのう)に。
ＩＰアドレスでの制限(せいげん)を .htaccessで設定(せってい)するのに必要(ひつよう)

Options[=Option,...]
Options構成(こうせい)要素(ようそ)が使用(しよう)可能(かのう)に
.htaccessで設定(せってい)できるオプションをカンマ区切(くぎ)りで指定(してい)する事(こと)でも設定(せってい)可能(かのう)

.htaccessはapacheを再(さい)起動(きどう)せずに設定(せってい)を変更(へんこう)できてしまうという利便(りべん)性(せい)がありますが、第三者(だいさんしゃ)に書(か)き換(か)えられるととんでもないことになる諸刃(もろは)の剣(けん)。ホストの設定(せってい)で.htaccessの機能(きのう)を制限(せいげん)しておくと、リスクを低減(ていげん)できますし、.htaccessの使用(しよう)目的(もくてき)を明確(めいかく)にすることで管理(かんり)がスマートになると思(おも)います。

スタジオムーンリーフで.htaccessを使(つか)うとしたらＩＰアドレス制限(せいげん)ぐらいですかね。つまり、使(つか)うのはLimitだけ。

したがって、バーチャルホストの設定(せってい)は下(した)のように書(か)き換(か)えられました。

OptionsとAllowOverrideの設定(せってい)をしました。
書(か)き忘(わす)れていたLogLevelの行(ぎょう)を追加(ついか)しました。
コンソールのフォントサイズを大(おお)きくしました（見(み)やすい！）

２．DebianのCGI、SSI設定(せってい)

しかし、このままではCGIは動作(どうさ)しません。
CGIが動(うご)くようにするためには、これとは別(べつ)に「.cgiや.plといった拡張子(かくちょうし)を持(も)っているファイルならCGIとして認識(にんしき)する」という設定(せってい)をせねばならないのです。

RedHat系(けい)なら「httpd.confを」という話(はなし)になるんでしょうけど、Debianは違(ちが)います。
Debianは /etc/apache2/mods-available/ の下(した)にたくさんの設定(せってい)モジュールを抱(かか)えており、必要(ひつよう)に応(おう)じて***.confを編集(へんしゅう)することで設定(せってい)を行(おこな)います。

拡張子(かくちょうし)に関(かん)する設定(せってい)は、MIME-TYPEの設定(せってい)を一手(いって)に引(ひ)き受(う)ける /etc/apache2/mods-available/mime.conf で行(おこな)います。


cd /etc/apache2/mods-available/
sudo vi mime.conf


219行目(ぎょうめ)、cgi-scriptに関(かん)する記述(きじゅつ)を修正(しゅうせい)します。
コメントアウトを解除(かいじょ)して、.plの拡張子(かくちょうし)を追加(ついか)します。

下線(かせん)のように修正(しゅうせい)

mime.confの一番下(いちばんした)にSSIで利用(りよう)する.shtmlの記述(きじゅつ)がありました。
SSIはこのままで動作(どうさ)しそうです。

.shtmlに関(かん)する設定(せってい)がデフォルトでありました。これはラッキー。

さて。
Debian系(けい)のサーバで忘(わす)れてはいけないことがあります。
Debian系(けい)のサーバは、デフォルトではapacheとcgi系(けい)のモジュールが結(むす)びついていません。
したがって「このサーバではCGIを動(うご)かすんだ！」と明示(めいじ)的(てき)にサーバに宣言(せんげん)してapacheとcgi系(けい)のモジュールを結(むす)びつけておく必要(ひつよう)があります。

それがこのコマンド。


sudo a2enmod cgid

cgidモジュールを有効(ゆうこう)化(か)するコマンド。
Debianのデフォルトはcgidモジュールが有効(ゆうこう)化(か)されていない。
ちなみに、モジュールを解除(かいじょ)するコマンドは
a2dismod。

SSIを有効(ゆうこう)にするときは、下(した)のコマンドも必要(ひつよう)なので注意(ちゅうい)

sudo a2enmod include


忘(わす)れられがちなコマンド。
はまる人(ひと)も多(おお)いようです。

cgidモジュールを有効(ゆうこう)化(か)する

already～とか表示(ひょうじ)されたら、すでにcgi系(けい)のモジュールとapacheが結(むす)びついているということです。

もういちど入力(にゅうりょく)すると「Module cgid already enabled」＝適用(てきよう)済(ず)み、というメッセージが出(で)る。安心(あんしん)安心(あんしん)♪

これでapacheを起動(きどう)（あるいは再(さい)起動(きどう)）すれば、すべての設定(せってい)がサーバーに反映(はんえい)されます。


sudo apachectl start


３．CGIの動作(どうさ)確認(かくにん)

さて、さっそくCGIが動(うご)くかどうか確認(かくにん)してみましょう。

/var/www/test/ の下(した)に cgiディレクトリを作(つく)って、その下(した)にtest.cgiを作成(さくせい)します。


cd /var/www/test/
sudo mkdir cgi
cd cgi
sudo vi test.cgi

test.cgiをこんな風(ふう)に編集(へんしゅう)。ＣＧＩを使(つか)って表示(ひょうじ)するメッセージといえば、やっぱりコレしかないでしょう！

保存(ほぞん)したあと、パーミッションを実行(じっこう)可能(かのう)な状態(じょうたい)に変更(へんこう)して、


sudo chmod 705 test.cgi


そしてそして、ブラウザからアクセスしてcgiが動(うご)くかどうか確認(かくにん)すれば……。

やった！

おおおおっ！
動(うご)いてますね動(うご)いてますね。
ばんざーい！

まだドメインをとっていないのでＩＰアドレスによるアクセスですが、ドキュメントルート/cgi/test.cgi による実行(じっこう)結果(けっか)が表示(ひょうじ)されました。

さあ、ＣＧＩが動(うご)くことが確認(かくにん)できればウェブサイト移転(いてん)の目処(めど)が立(た)ったと言(い)えると思(おも)います。ここまでくると気(き)が楽(らく)になります。

まだ多少(たしょう)の山場(やまば)があるとは思(おも)いますが（ドメインをとったあとのＤＮＳ登録(とうろく)あたりが次(つぎ)の山場(やまば)かと）、少(すこ)しずつ進(すす)めてまいりましょう。

４．まとめ（雑感(ざっかん)）

ＧＣＰのインスタンスでDebianを選(えら)んだのは偶然(ぐうぜん)ですが、多少(たしょう)クセがあるもののウェブサーバーとしてはRedHat系(けい)よりDebianの方(ほう)が保守(ほしゅ)管理(かんり)はかなりラクになりそうな印象(いんしょう)です。

ただ、インターネット上(じょう)であまり情報(じょうほう)が見(み)つけられないのもDebian系(けい)でした。RedHat系(けい)（CentOSとか）の情報(じょうほう)はぽんぽん見(み)つかるんですが、apacheの構造(こうぞう)が違(ちが)うのでDebianでは使(つか)えないんですよ。Debian系(けい)のなかでは比較的(ひかくてき)人気(にんき)のありそうなubuntuとかの情報(じょうほう)を参考(さんこう)にしながらここまで進(すす)めることができました。

個人(こじん)的(てき)にはLinuxのなかではシンプルな印象(いんしょう)のDebianのほうが性(しょう)に合(あ)ってるような印象(いんしょう)です。

≫ NEXT_LOG ＧＣＰでウェブサーバ構築(こうちく)チャレンジ・７【ブルータス、おまえもスマホか】(8 photos)

≪ PREV_LOG ＧＣＰでウェブサーバ構築(こうちく)チャレンジ・５【選(えら)んでよかったDebian】(6 photos)