証明書の取得

本来はSECOMやVeriSign等に有料で証明してもらうのですが、今回は以前にも紹介したCACertを載せときます。

• CAcertから証明書をもらおう！(その0:紹介)
• CAcertから証明書をもらおう！(その1:アカウントの登録)
• CAcertから証明書をもらおう！(その2:鍵と申請書の作成)
• CAcertから証明書をもらおう！(その3:CAcertから証明書をもらう)

ということで、証明書の取得は省略します。とりあえず、サーバーの秘密鍵 server.key と サーバーの証明書 server.cer が手に入った事にします。

nginxに設定

nginxでの設定は簡単で、既存の設定をコピーして、80番ではなく443番に変更し、SSLを有効にしてサーバーの鍵・証明書のファイルを指定してあげるだけです。

ちょっとその部分だけ書いてみます。

server {
	listen   443 default_server ssl;
	server_name	_;
	ssl_certificate /keys/server.cer;
	ssl_certificate_key /keys/server.key;

	location / {
		この辺は適当に
	}
}

リバースプロキシとしてnginxとして使っている場合も同様です。

名前ベースのバーチャルホストを使っている場合

ドメイン名を複数つかってバーチャルホストを使っている場合もあると思います。SSLではアクセスされたサーバー名がわかる前に証明書を渡さなければならないので、名前ベースのバーチャルホストでSSLは利用できませんでした。

が、SNI(Server Name Indication)というプロトコル拡張ができたので、名前ベースのバーチャルホストでも可能になりました。(ブラウザによっては対応してません)

設定は簡単で、httpと同じくserver_nameを設定するだけです。

リバースプロキシとして使っている場合は、証明書を変えるために、バーチャルホストの数だけServerディレクティブを作ってあげてください。

どう重いのかというと、Apacheは一つのプロセスが一つのHTTPリクエストを同期処理で裁いてるのでその間は他の処理をしません。なので、同時アクセス数が増えるとApacheはプロセスをどんどん生成します。(あるいは後からきたリクエストを待たせる)

なので、アクセス数が増えると急激にパフォーマンスが落ちるという問題を抱えてます。(ほかにもプロセスIDが足りなくなってどんなにリソースがあっても最大プロセスIDで制限されてしまう)

で、最近話題のハイパフォーマンスWebサーバーがnginx(えんじんえっくす)です。

nginxは一つのプロセスで複数のリクエストを非同期で同時に処理します。なので、アクセス数が増えてもパフォーマンスが落ちにくいという特性があります。特に静的ファイルの場合は処理のほとんどがI/O待ちなので効果が大きいです。

そこで、PHPとかSVNとか設定がめんどくさいものはApacheに任せておいて、静的なファイルだけをnginxに処理させてみると、Apacheへのリクエスト数は激減するはずです。

例えば、このブログのトップページの場合PHPで生成されるHTMLが一個にたいして、CSSや画像等の静的ファイルが20個近くあります。単純計算で21個のリクエストのうち1個だけがApacheで処理されるのでApacheへのリクエストは約95%削減されます。

では設定してみましょう。OSはUbuntu Server 10.04(64bit)です。Apacheは既にインストール済みで運用されているとします。設定後はnginxがポート80で待ち受けて、Apacheはポート8080で待ち受けるということにします。

(記事の最後でキャッシュファイルをRAMに置くというのもやってみます)

nginxのインストール

そのままaptitudeでインストールすると0.7.65がインストールされてしまうので、nginxのPPAを追加してからインストールします。

$ sudo add-apt-repository ppa:nginx/stable
$ sudo apt-get update
$ sudo install nginx

設定ファイルは /etc/nginx/ にあります。sites-enableとかApacheに似た構造になっています。

リバースプロキシの設定

ではこの sites-enabled/default をこのように設定しましょう。

upstream backend {
    server 127.0.0.1:8080;
}

server {
    listen   80;
    server_name _;
    location / {
        proxy_redirect                         off;
        proxy_set_header Host                $host;
        proxy_set_header X-Real-IP            $remote_addr;
        proxy_set_header X-Forwarded-Host    $host;
        proxy_set_header X-Forwarded-Server    $host;
        proxy_set_header X-Forwarded-For        $proxy_add_x_forwarded_for;
        proxy_pass http://backend;

    }
}

これはリバースプロキシに必要な設定だけです。すべてのアクセスをローカルのApacheに引き渡してます。

Apacheの方はports.confでリッスンポートを80から8080に変更し、各サイトの設定も80から8080に変更してください。そして、Apacheとnginxを再起動させます。(Apacheを先に8080にしてからnginxを起動させる)

$ sudo /etc/init.d/apache restart
$ sudo /etc/init.d/nginx restart

これでブラウザからアクセスすると、nginxを経由してApacheが処理します。ので、今までとかわらないはずです。

ところが、問題があって、Apacheのアクセスログを見るとアクセス元が127.0.0.1になっちゃってるはずです。これを解消するためにmod_rpafをインストールします。

$ sudo apt-get install libapache2-mod-rpaf

これでApacheを再起動すると正しくアクセス元が扱われているはずです。実はこのためにnginxの設定に X-Real-IP をHTTPヘッダに追加する設定やらを書いているのです。mod_rpafはプロキシサーバーが追加した X-Real-IP ヘッダをアクセス元として扱うモジュールです。

mod_rpafは127.0.0.1からのアクセスだけに対して処理をするのでもし、リバースプロキシが他のホストにあるのであれば /etc/apache2/mods-enabled/rpaf.conf の RPAFproxy_ips をリバースプロキシサーバーのIPアドレスに変更してください。(すべてのX-Real-IPを信用するとアクセス元の偽装ができてしまうためです)

プロキシキャッシュ

では、元々の目標であった静的ファイルをnginxでホストする設定をしましょう。本来はnginxが静的ファイルを直接ディスクから取ってくるのがいいのですが、nginxがApacheと違うホストにある場合も考えられますのでその場合でも対応できるように、静的ファイルへのアクセスをキャッシュしておき、2回目以降の同じファイルへのアクセスはApacheに引き渡さないように設定してみます。

defaultをこのように編集してみます。

proxy_cache_path /var/cache/nginx/static_file_cache levels=1:2 keys_zone=cache_static_file:128m inactive=7d max_size=512m;
proxy_temp_path /var/cache/nginx/temp;

upstream backend {
    server 127.0.0.1:8080;
}

server {
    listen   80;
    server_name _;
    location / {
        proxy_redirect                         off;

        set $do_not_cache 0;
        if ($request_method != GET) {
            set $do_not_cache 1;
        }
        if ($uri !~* "\.(jpg|png|gif|jpeg|css|js|swf|pdf|html|htm)$") {
            set $do_not_cache 1;
        }
        proxy_no_cache     $do_not_cache;
        proxy_cache_bypass $do_not_cache;
        proxy_cache cache_static_file;
        proxy_cache_key $scheme$host$uri$is_args$args;
        proxy_cache_valid  200 2h;
        proxy_cache_valid  any 1m;

        proxy_set_header Host                $host;
        proxy_set_header X-Real-IP            $remote_addr;
        proxy_set_header X-Forwarded-Host    $host;
        proxy_set_header X-Forwarded-Server    $host;
        proxy_set_header X-Forwarded-For        $proxy_add_x_forwarded_for;
        proxy_pass http://backend;
    }
}

この設定ではメモリ128M,ファイル最大512Mで、7日間キャッシュするファイルを /var/cache/nginx/static_file_cache に作成してます。

そして、do_not_cache 変数を用意して、0にしておき、GETでのアクセスでない場合と、静的ファイルでは無い場合にキャッシュしないようにその場合は do_not_cache を1にして、proxy_no_cacheを有効にしてます。静的ファイルの判断は正規表現でURLの拡張子を見ています。(注意しなければいけないのが、WordPressのページをパーマネントリンクで.htmlにしている場合です。その場合はキャッシュされないように外しておく必要があります。)

つまり、静的ファイルにGETでアクセスしたものだけキャッシュされます。

proxy_cache_valid はどのステータスのレスポンスをどの期間キャッシュするかを設定する項目で、この場合200なら2
時間、それ以外なら1分キャッシュすることになります。

あとは /var/cache/nginx/ ディレクトリを作成し nginx を再起動するだけです。

$ sudo mkdir /var/cache/nginx
$ sudo /etc/init.d/nginx restart

それでしばらくブラウザからアクセスしてみると、キャッシュディレクトリの容量が増えているはずです。

$ sudo du -ch /var/cache/nginx/static_file_cache
(中略)
91M	/var/cache/nginx/static_file_cache
91M	合計

本当にApacheへのアクセスが減っているのかは、Apacheのアクセスログをみてみてください。

さらに一歩

もう一歩高速化してみましょう。いまキャッシュファイルは/var/cache/nginxに置かれているので、結局キャッシュからの呼び出しのためにHDDアクセスすることになります。こいつを全部メモリ上においてしまいましょう。

間違えたり、問題が発生するとシステムに問題が起きるかもしれないのでわからないor不安ならやらないほうがいいです。

tmpfsを使えば、メモリ上の領域をファイルシステムにマウントすることができます。

/etc/fstab に次の一行を追加してOSを再起動します。

tmpfs	/var/cache/nginx	tmpfs	defaults,noatime,mode=1777	0	0

そうすると、/var/cache/nginx ディレクトリはRAM上に配置されます。

が、うちのサーバーはSSDにしてあったので効果はわかりませんでした。が、SSDの寿命を延ばす効果はあると思います。

が、その記事に書いた通りLinux(Debian)では正しく動作していたのにLeopard Serverにしてからうまく行かなくなっていました。

しかも「ディレクトリが見つかりません」というようなわかりやすいエラーではなく「ファイルをコピーできませんでした」というエラー…
表示されるパスには間違いはないし、パーミッションも777にしてみても(すでになっている)駄目。

ちなみに「ファイルをコピーできませんでした」というエラーはPHPがセーフモードで動いている場合によく出るそうですが、今回はセーフモードで動かしてはいません。

で、諦めていたのですが、いっそのことFTP_BASEやFTP_CONTENT_DIRやFTP_PLUGIN_DIRの定義をコメントアウト(削除)してみるとなんとすんなり成功。

（下部の追記参照）

ということで、セーフモードでもないのに「ファイルをコピーできませんでした」と言われた時は一度FTPのディレクトリ設定を削除してみるのも手かもしれません。

追記

どうやらCodexのFTP_BASE等の説明には「インストールした WordPress のベースフォルダへのフルパス。」と書いてあるので”サーバー内でのフルパス”だと思っていたのですが、少なくともOSXでは”FTPでアクセスした時のパス”が正しいようです。（OSの問題では無いようなな気もしますが）

Codexにも「FTPユーザとしてサーバ上にある各フォルダへのパスが分かっていれば…」とあるので”FTPでアクセスした時のパス”が正しいようです。

つまり「/Users/name/Sites/wp-content/」ではなくFTPから見た時のパスなので「/Sites/wp-content/」とするとFTP_BASE等を定義しても自動アップデートできました。

そんな場合は「wp-config.php」に以下の三行を追加するだけで直ります。
上から順番に「FTPのルートディレクトリ」「wp-contentディレクトリ」「pluginsディレクトリ」へのパスです。

define('FTP_BASE', '/path/to/wordpress/');
define('FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/');
define('FTP_PLUGIN_DIR', '/path/to/wordpress/wp-content/plugins/');

長いことあきらめていたのですが公式サイトの「wp-config.php_の編集」に説明がありました。

明日は前期入試です

追記（2010年1月11日）
どうやらFTP_BASE等でのフルパスというのはFTPから見た時のパスのような気がします。
Codexの説明には「インストールした WordPress のベースフォルダへのフルパス。」としか書いてないのでどちらかわかりませんが、試してダメならFTPで接続したときのパスを入れてみてください。

Codexにも「FTPユーザとしてサーバ上にある各フォルダへのパスが分かっていれば…」とあるのでこれで正しいと思われます。

もちろん上記のような本当にセキュアな通信が必要な場面では使えませんが、以前この投稿でApacheでSSLを有効にする際には「個人で勝手に作った認証局」から発行された（発行した？）「えせ証明書」を利用しましたが、それとは比較してはいけないぐらい十分すぎる証明書が頂け、利用できます。

ということで記事は長くなりそうなので、シリーズに分けて以下の順に進めていきたいと思います。
ついでにProFTPDもSSL対応にしてしまいます。メールサーバーは設定しません。
(「＊一部内容を変更してお届けしています」という注記がいつ入るかわかりませんが…)

1.CAcertにアカウントを登録する。
2.証明書を発行してもらうための「申請書」(CSR)を作成する。
3.証明書をもらう。
4.Apacheに証明書を登録する。
5.ProFTPDに証明書を登録し、FTPのSSLを有効にする。

「保存」は動作確認。
「公開」も動作確認。
あれ？

追記
原因
同じタイトルの記事を新規投稿(保存ではなく公開)すると発生するらしい。
だから「新規投稿テスト」とテストしたときは問題なかったのだ。
こちらに報告も発見。

対処
今後新規記事を作る際に投稿できない場合はタイトルを変更して投稿。
どうしてもそのタイトルにしたい場合は一度公開してから変更。

ダウンロードはこちらの公式サイトから。
Teddy Hwang » Leopard Admin

インストールしてプラグインを有効にするだけです。
これをみるとつくづくMacOSX Serverを導入したいと思うわけです…

前回にPHPを5にバージョンアップしたのでPHP5にインストールすることになりますがPHP4でもあまり相違点はないと思われます。

コンパイル環境がない場合はまずそれらをインストール

$sudo aptitude install libtool
$sudo aptitude install libguile-dev
$sudo aptitude install automake
$sudo aptitude install g++

まずは「eAccelerator」のソースのダウンロードからインストールまで、

$ cd /tmp
$ wget http://nchc.dl.sourceforge.net/sourceforge/eaccelerator/eaccelerator-0.9.5.2.tar.bz2
$ tar jxf eaccelerator-0.9.5.2.tar.bz2
$ su
# cd eaccelerator-0.9.5.2
# export PHP_PREFIX="/usr/"
# $PHP_PREFIX/bin/phpize
# ./configure --enable-eaccelerator=shared --with-php-config=$PHP_PREFIX/bin/php-config
# make
# make install

とすると

Installing shared extensions: /usr/lib/php5/20060613+lfs/

のようにインストール先が出力されます。
次にキャッシュフォルダーの作成と「extensions」フォルダー、リンクの作成を行います。

# mkdir /usr/lib/php5/extensions
# mkdir /var/cache/eaccelerator
# chown www-data:www-data /var/cache/eaccelerator
# ln -s /usr/lib/php5/20060613+lfs/eaccelerator.so /usr/lib/php5/extensions/eaccelerator.so

次にPHPの設定を変更します。

# vim /etc/php5/apache2/php.ini

としエディタで「/etc/php5/apache2/php.ini」を開き、以下の記述を最後の行の「; End:」の上に追記します。

[eaccelerator]
zend_extension="/usr/lib/php5/extensions/eaccelerator.so"
eaccelerator.shm_size = "32"
eaccelerator.cache_dir = "/var/cache/eaccelerator"
eaccelerator.enable = "1"
eaccelerator.optimizer = "1"
eaccelerator.check_mtime = "1"
eaccelerator.debug = "0"
eaccelerator.filter = ""
eaccelerator.shm_max = "0"
eaccelerator.shm_ttl = "0"
eaccelerator.shm_prune_period = "0"
eaccelerator.shm_only = "0"
eaccelerator.compress = "1"
eaccelerator.compress_level = "9"
eaccelerator.keys = "shm_and_disk"
eaccelerator.sessions = "shm_and_disk"
eaccelerator.content = "shm_and_disk"

保存し、最後にApache2を再起動します。

# /etc/init.d/apache2 restart

以前PHPの確認で使用したphpinfo();を実行してみます。(こちらを参照)

の様に「eAccelerator」の項目ができており、キャッシュフォルダーである「/var/cache/eaccelerator」にファイルが生成されてるのを確認できれば成功。

キャッシュフォルダの確認方法

# ls /var/cache/eaccelerator
0  1  2  3  4  5  6  7 8  9  a  b  c  d  e  f　//このようなファイルができていれば成功

WordPressなども少し速くなったような気がします。
細かい比較はまた今度。

まず、PHP4現在何を使っているかをリストアップします。

$ su
# dpkg -l

インストールされていたのは以下のものでした。

ii php4 4.4.4-8+etch4
ii php4-common 4.4.4-8+etch4
ii php4-dev 4.4.4-8+etch4
ii php4-gd 4.4.4-8+etch4
ii php4-mysql 4.4.4-8+etch4
ii php4-pear 4.4.4-8+etch4
ii php5-cli 5.2.0-8+etch7
ii php5-common 5.2.0-8+etch7
ii libapache2-mod-php4 4.4.4-8+etch4

次にPHPを使用しているページです
言うまでもなく「WordPress ME2.2.3」
「phpMyAdmin」
友達に貸している「XOOPS 2.0.16a JP」
アクセス解析「mogura」
です。どれもPHP5で利用できそうです。「XOOPS 2.0.16a JP」は少し不安でしたが…

とりあえず「php5」をインストールします。

# apt-get install php5

すると

パッケージリストを読み込んでいます… 完了
依存関係ツリーを作成しています… 完了
以下の特別パッケージがインストールされます:
libapache2-mod-php5
以下のパッケージは「削除」されます:
libapache2-mod-php4 php4 php4-gd php4-mysql phpmyadmin
以下のパッケージが新たにインストールされます:
libapache2-mod-php5 php5
アップグレード: 0 個、新規インストール: 2 個、削除: 5 個、保留: 0 個。
2414kB のアーカイブを取得する必要があります。
展開後に 12.0MB のディスク容量が解放されます。
続行しますか [Y/n]?

と聞かれるので「Y」。「phpmyadmin」はインストールし直しみたいです。
「libapache2-mod-php5」は勝手にインストール。
そしてphp4の時に使っていたモジュールのインストール。

# apt-get install php5-dev
# apt-get install php5-gd
# apt-get install php5-mysql
# apt-get install php5-pear
# apt-get install phpmyadmin

ところが「PEAR」が

パッケージリストを読み込んでいます… 完了
依存関係ツリーを作成しています… 完了
パッケージ php5-pear はデータベースには存在しますが、利用できません。
おそらく、そのパッケージが見つからないか、もう古くなっているか、
あるいは別のソースからのみしか利用できないという状況が考えられます
E: パッケージ php5-pear にはインストール候補がありません

と出てインストールできません。
このパッケージを利用しているのは「mogura」です。
調べてみると
http://pear.php.net/package/PEAR
からダウンロードしてきて「mogura」のフォルダーに丸ごと入れておけばいいらしいのでそうします。
http://pear.php.net/package/PEARに行ってファイルのパスを調べると

http://download.pear.php.net/package/PEAR-1.6.2.tgz

でした。
ということで、

# cd /home/www/chibiegg/mogura
# wget http://download.pear.php.net/package/PEAR-1.6.2.tgz
# tar -zxvf PEAR-1.6.2.tgz
# mv ./PEAR-1.6.2/* ./
# rm -R PEAR-1.6.2/
# rm PEAR-1.6.2.tgz

最後にApache2を再起動

# /etc/init.d/apache2 restart

最後にページの動作確認をします。
「WordPress ME2.2.3」
「phpMyAdmin」
「XOOPS 2.0.16a JP」
「mogura」
どれも設定を全くいじることなく動作しました。
「WordPress」に関してはプラグインも確認しました。
「Akismet」関係する設定ページなどを開きエラーのでないことを確認
「Cimy Swift SMTP」メール送信テスト
「Dunstan-style Error Page」存在しないページを指定し表示されるか確認
「Mobile Eye+」携帯から接続確認
「Search Hilite」何か検索してみる
「Smart Update Pinger」この記事の投稿のときに確認
すべてOKでした。

ちょっと今日は学校で会議があったりして帰るのが遅かった。

WordPressは標準で記事のアドレスが
「http://chibiegg.homeip.net/wordpress/?p=3」
のように番号だけになっています。これを
「http://chibiegg.homeip.net/wordpress/2007/11/10_213.htm」
のようにしたいと思います。これによって各記事が別のファイルと検索エンジンに認識され検索の対象になりやすくなります。

まず、wordpressのあるフォルダのパーミッションを777にします。

今回は「/home/www/chibiegg」がドキュメントルートで「/home/www/chibiegg/wordpress」にWordPressがあるとします。

$ su
# chmod 777 /home/www/chibiegg/wordpress/

次にWordPressの管理画面の「オプション」の「パーマリンク設定」を開きます。
ここで好きなようにファイル名を変更することができます。
既に選択肢にあるものを利用してもいいですし、「独自表記を以下の入力欄に記述」を使用して自由に決めることもできます。ここを
「/%year%/%monthnum%/%day%_%hour%_%post_id%.htm」
のようにすると
「/年(4桁)/月(2桁)/日付_時間_記事のID.html」となります。
ここには必ず「%post_id%」を含むようにします。
その他使用できるタグは

http://codex.xwd.jp/index.php/Using_Permalinks

を参照してください。

そして、「パーマリンク構造を更新」をクリックします。
上の方に「パーマリンク構造が更新されました。」が表示されればOK

しかしこれだけでは有効にならないためApache2の設定を変更します。
パーマリンクはApache2の拡張機能である「rewrite_module」と設定を追加する「.htaccess」を使用しているためこれを有効にします。
まずはrewrite_moduleを有効にします。

# a2enmod rewrite
# /etc/init.d/apache2 force-reload

次に「/etc/apache2/sites-available」内のサイトの設定を編集し「.htaccess」を有効にします。
編集するファイルは各自の状況にあわせてください。今回は「chibiegg-homeip」という設定ファイルを使用しているとします。

# vi /etc/apache2/sites-available/chibiegg-homeip

として設定ファイルをviエディタなどで開きます。
設定ファイルにすでに「/home/www/chibeigg/wordpress/」(ここも各自のWordPressの存在するフォルダに読み替えてください)についてのDirectory設定がある場合はその<Directry>の「AllowOverride None」を「AllowOverride All」に変更します。
「<Directory /home/www/chibiegg/>」
がない場合は以下のように追加しましょう。重要なのは「AllowOverride All」です。そのほかの部分は変更していただいても構いません。

<Directory /home/www/chibiegg/>
	Options -Indexes FollowSymLinks MultiViews
	AllowOverride All
	Order allow,deny
	Allow from all
</Directory>

以上のように変更を保存します。
もう一度Apache2を再起動しましょう

# /etc/init.d/apache2 restart

確認方法としてはWordPressのトップページを開き何かの記事をクリック。
そのときのアドレスが正しく変更されていればOKです。

Pathのログを途中でURLデコードし、文字コードをEUC-JPに変換するようにします。
具体的には続きで…

222行目あたりを以下のように修正します。
編集前

//Path
if(isset($_GET["path"])){
	$w3a_buf["path"] = $_GET["path"];
	$w3a_buf["path"] = str_replace ("_P_", "%", $w3a_buf["path"]);
	$w3a_buf["path"] = str_replace ("_A_", "&", $w3a_buf["path"]);

編集後

//Path
if(isset($_GET["path"])){
	$w3a_buf["path"] = $_GET["path"];
	$w3a_buf["path"] = urldecode($w3a_buf["path"]);
	$w3a_buf["path"] = @mb_convert_encoding($w3a_buf["path"], "EUC-JP", constant("TO_ENCODING"));
	$w3a_buf["path"] = str_replace ("_P_", "%", $w3a_buf["path"]);
	$w3a_buf["path"] = str_replace ("_A_", "&", $w3a_buf["path"]);

ついでに、標準では取得する画像サイズがブラウザのウインドウサイズなのでモニターの解像度を取得するようにします。
「w_js.php」と「w.php」の以下の部分のコメントアウトを外します。

編集前

/* モニターサイズ */
//w = screen.width;
//h = screen.height;

編集後

/* モニターサイズ */
w = screen.width;
h = screen.height;

ということで以前のようにこのコードの中の128と96を4:3の比率の好きな値にすることによってサムネイルのサイズ変更ができるようになりました。今回は400と300にしました。

今回参考にさせていただいたページ
cyocyo.biz

やってみると、
「ビジュアルエディタとソースエディタを行き来すると改行がすべて消える」
ということでビジュアルエディタは使いません。
せっかく便利なのに。

作業は簡単ですぐ終わります(笑)
とりあえずファイル全部とMySQLのデータベースはphpMyAdminからバックアップしてあると仮定します。
そしてプラグインはすべて無効にしましょう。

WordPress Japanから2.2.3MEをダウンロードしてきて解凍します。
ファイルをすべて既存のWordPressに上書きします。
このとき注意しないといけないのはMacを使っている場合普通に上書きするとフォルダがマージされないのでここ(フォルダー同士の更新コピー)を参考にマージしながらコピーします。
あるいはサーバー上でやるか、Windowsからすればいいのですが。以前はこれを忘れていたので失敗しました。

そしてwp-admin/upgrade.phpに節夫くしアップデート作業をします。
最後に必要なプラグインを有効化します。設定などはすべて引き継がれます。
以前変更したサムネイルのサイズもそのままでした。
すいません間違いでした。サムネイル作成機能が移動しています。こちらを参考にしてください。

一応問題なく動作していますが、リッチテキストエディタで<pre><code>タグのある記事を開いて保存すると改行がすべてなくなりめちゃくちゃになってしまったのでgoogleのキャッシュから読んできて保存し直しました。<pre><code>って重ねたら駄目なのかな。<code>だけでいいような。なんで最初に両方書いてしまったのか…

「search-hilite wordpress 設定」でgoogleから開いた例

ということでそれは大変なので探すとメール送信を外部のSMTPサーバーから送ることのできるようになるプラグイン「Cimy Swift SMTP」を見つけました。
ダウンロードはここから。

いつもの通り「plugins」フォルダーにいれて管理画面から有効化します。
すると「オプション」に「Cimy Swift SMTP」ができるのでSMTPの送信設定をします。
ところがなぜかK-OPTI.COMのメールサーバーではエラーになったので他サイトで実績のある「GMail」を使うことにしました。
設定例を挙げておきます。

Sender name:適当に
Sender e-mail:これはGMailのアドレス

SMTP server address:smtp.gmail.com
Port:465(Use for SSL/TLS/GMAIL)
Username:GMailのアドレス
Password:GMailのパスワード
Use SSL or TLS?: TLS(Use For Gmail)

この設定でTest Connectionからのテストメール送信やコメント通知機能のメールは送信できるようになりました。
しかし「Dunstan-style Error Page」のメールは送信されません。
「Cimy Swift SMTP」Test ConnectionのPHPファイルと「wp-content/plugins/afdn_error_page.php」を比べると送信関数が「wp_mail(…);」ではなく「mail(…);」になっていました。
とりあえず送信できるほうに合わそうと、「wp-content/plugins/afdn_error_page.php 」の２カ所「mail(…..」を「wp_mail(…..」に修正することで送信できるようになりました。

「Search Hilite」
このサイトより「search-hilite_1.9.zip (15.07.2006 00:47)」をダウンロードしてきて解凍します。解凍してできた「search-hilit」フォルダをフォルダごと「wp-content/plugins」フォルダーにコピーします。
そして管理メニュの「プラグイン」から「Search_Hilite」の有効化リンクをクリックします。
インストールはこれだけで設定もなにもありません。
検索ウインドウから検索すると以下のようにキーワードがハイライトされました。

「Smart update pinger」
これは参考にさせていただいたブログの方が日本語にしたバージョンをここからダウンロードし「smart-update-pinger.php」を「wp-content/plugins」にコピーします。
これも同じように管理メニュの「プラグイン」から有効化します。
設定は「オプション」の「Smart update pinger」から行います。

「Dunstan-style Error Page」
こちらもここから日本語化されたバージョンをダウンロードします。
(と思ったのですがダウンロードリンクがおかしかったのですが直リンクは失礼なのでアドレスを書いておきます。http://plasticdreams.org/uploads/projects/afdn_error_page.php.zip)
解凍してできた「afdn_error_page.php」を「wp-content/plugins」にコピーし管理メニュの「プラグイン」から有効化します。
このプラグインはそれだけでは反映されないので「表示」の「テーマエディタ」から「404 ページ」を開きます。
そして内容をすべて削除し(バックアップを取ってから)「<?php afdn_error_page(); ?>」の一行だけのファイルにします。
ほんとはこれでいけるのですが現在使用しているテーマではデザインが崩れてしまったので以下のように修正しました。
まずは「404 ページ」から。

元のソース

<?php get_header(); ?>
  <div id="content">

    <div class="post">
        <h2>Error 404 - ページがありません</h2>

		<div class="entry">
		<p>申し訳ありません、指定されたページは存在しません。リンク切れの場合はご連絡いただけると幸いです。</p>
		</div><!--/entry -->

	</div><!--/post -->

  </div><!--/content -->

  <div id="footer"></div>
</div><!--/left-col -->

<?php get_sidebar(); ?>

<?php get_footer(); ?>

編集後

<?php get_header(); ?>
  <div id="content">

    <div class="post">
		<div class="entry">
<?php afdn_error_page(); ?>
		</div><!--/entry -->

	</div><!--/post -->

  </div><!--/content -->

  <div id="footer"></div>
</div><!--/left-col -->

<?php get_sidebar(); ?>

<?php get_footer(); ?>

次に「afdn_error_page.php」も編集します。
346行目付近「<?php get_header(); ?>」
427行目付近「<?php get_footer(); ?>」
の２行を削除しました。
これで以下のように正しく表示されました。

今回は以上です。

今回はこちらの「Sidebar Widgets」の日本語化バージョンを使用しました。
ダウンロードしてきたら「widgets」フォルダーごと「wp-content/plugins」フォルダにアップロードします。
そしてWordPress管理メニューの「プラグイン」から「Sidebar Widgets」を有効にします。
これでは標準のままなので、後はお好きなように「表示」の「サイドバーウィジェット」から設定変更しましょう。

Sidebar Widgets Plugin 日本語版

編集するのは「wp-includes/js/quicktags.js」です。
まず、「function edToolbar() {」の行の上に以下のように追加します。

function edEscapeString(strOld)
{
    var strNew = "";

    for(var i = 0; i < strOld.length; i++){
        var c = strOld.charAt(i);

        switch(c){
        case '<':
            c = "&lt;";
            break;
        case '>':
            c = "&gt;";
            break;
        case '&':
            c = "&amp;";
            break;
        case '    ':
            c = "    ";
            break;
        }
        strNew += c;
    }
    return strNew;
}
function edEscapeChars(myField) {
    //IE support
    if (document.selection) {
        myField.focus();
        sel = document.selection.createRange();
        strTmp = sel.text;
        strTmp = edEscapeString(strTmp);
        sel.text = strTmp;
        myField.focus();
    }
    //MOZILLA/NETSCAPE support
    else if (myField.selectionStart || myField.selectionStart == '0') {
        var startPos = myField.selectionStart;
        var endPos = myField.selectionEnd;
        var strTmp = myField.value.substring(startPos, endPos);
        var strPos = myField.value.substring(endPos, myField.value.length);
        var strPre = myField.value.substring(0, startPos);
        strTmp = edEscapeString(strTmp);
        myField.value = strPre + strTmp + strPos;
        myField.focus();
        myField.selectionStart = startPos + strTmp.length;
        myField.selectionEnd = startPos + strTmp.length;
    }
}

次に「function edToolbar() {」の中の「document.write(‘<input type=”button” id=”ed_spell” class=”ed_button” onclick=”edSpell(edCanvas);” title=”Dictionary lookup” value=”lookup” />’);」の上に以下の行を追加します。

document.write('<input type="button" id="ed_escape" class="ed_button" onclick="edEscapeChars(edCanvas);" title="escape characters" value="escape" />');

これで「escape」というボタンができるので変換したい部分を選択しこのボタンをクリックすると変換してくれます。

今回参考にさせていただいたサイト
エディターのボタンを増やす -2

$ su
# apt-get install libapache-mod-ssl

これから「/etc/apache2/ssl」に鍵などを作っていきます。

# cd /etc/apache2
/etc/apache2# mkdir ssl
/etc/apache2/ssl# cd ssl
/etc/apache2/ssl# cp /usr/lib/ssl/misc/CA.sh ./CA.sh
CA certificate filename (or enter to create)  (空欄のままEnter)
Enter PEM pass phrase:(パスフレーズを決める。一時的なものなので何でもよいが覚えておくこと)
Verifying - Enter PEM pass phrase:(もう一度パスフレーズ)
Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Kyoto(都道府県)
Locality Name (eg, city) []:Kyoto(市区町村)
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Personal(個人なので)
Organizational Unit Name (eg, section) []:web(ここは組織単位らしい)
Common Name (eg, YOUR name) []:hogehoge(ニックネームでも入れましょう)
Email Address []:(メールアドレス)
A challenge password []:(空欄)
An optional company name []:(空欄)
Enter pass phrase for ./demoCA/private/./cakey.pem:(最初に決めたパスフレーズ)

これで認証局の証明書関係ができます。
続いて鍵の作成。

/etc/apache2/ssl# /usr/bin/openssl genrsa -rand /var/log/apache2/access.log -des3 -out ./serverkey.pem 1024
1407562 semi-random bytes loaded
Generating RSA private key, 1024 bit long modulus
...++++++
.........++++++
e is 65537 (0x10001)
Enter pass phrase for ./serverkey.pem:(決めたパスフレーズ)
Verifying - Enter pass phrase for ./serverkey.pem:(もう一度)

以下のコマンドで作成した鍵のパスフレーズを削除します。

/usr/bin/openssl rsa -in ./serverkey.pem -out ./serverkey.pem
Enter pass phrase for ./serverkey.pem:(決めたパスフレーズ)

/usr/bin/openssl rsa -in ./demoCA/private/cakey.pem -out ./demoCA/private/cakey.pem
Enter pass phrase for ./demoCA/private/cakey.pem:(決めたパスフレーズ)

「writing RSA key」とでれば成功。
証明書を発行する為の申請書ファイル「CSR」の作成。質問は基本的に上と同じ。
コマンド中の365は有効日数。変更可能。

/usr/bin/openssl req -new -days 365 -key ./serverkey.pem -out ./csr.pem
Country Name (2 letter code) [AU]:JA
State or Province Name (full name) [Some-State]:Kyoto(都道府県)
Locality Name (eg, city) []:Kyoto(市区町村)
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Personal(個人なので)
Organizational Unit Name (eg, section) []:web
Common Name (eg, YOUR name) []:(ニックネームでも)
Email Address []:(メールアドレス)
A challenge password []:(ここはちゃんとパスワードを決める)
An optional company name []:(空欄)

証明書を作成。

/usr/bin/openssl ca -in ./csr.pem -keyfile ./demoCA/private/cakey.pem -cert ./demoCA/cacert.pem -out ./cert.pem

「/etc/apache2/ssl」に「cert.pem」ができてればOK。
(なぜか参考にしたページのような質問はなかった。)

続いてApache2の設定。
既に「/etc/apache2/sites-available」あるサイト設定(以下の例は(default))を「default-ssl」(ファイル名は使用するサイト設定にあわせてください)コピーします。SSLを有効にしたいサイトはすべて行ってください。
そのファイルを以下のように編集します。

NameVirtualHost * => NameVirtualHost *:443
virtualhost * => virtualhost *:443
ServerName(あるいはServerAliasも) hogehoge.com => ServerName hogehoge.com:443

以下を追加

SSLEngine on
SSLCertificateFile /etc/apache2/ssl/demoCA/cacert.pem
SSLCertificateKeyFile /etc/apache2/ssl/demoCA/private/cakey.pem

このサイト設定を有効にする為に(このコマンドは最近知った。自動でsites-enabledにシンボリックリンクを作成してくれる。)

#a2ensite default-ssl

さらにポート443からの接続を受けるために「/etc/apache2/ports.conf」に「Listen 443」を追加して保存。

そしてApache2の再起動

# /etc/init.d/apache2 restart

これで「https://」で接続できれば成功。この証明書は信頼されていませんとでますがこれはどうしようもありません、お金を払って「VeriSign」などから証明書をもらえばこの問題も解決します。

ついでにphpMyAdminへの接続を「http」からは接続できないようにすることもできます。セキュリティーを考えていろいろ設定しましょう。基本的にSSLなしとSSLありの設定は別サイトとして扱われるので共通の編集はどちらにもしましょう。

今回参考にさせていただいたサイト。
mod_sslの設定
暗号化通信の有効化 [mod_ssl]

        Alias /phpmyadmin/ /var/www/phpmyadmin/
        <directory "/var/www/phpmyadmin">
                AuthType Basic
                AuthName "phpMyAdmin"
                AuthUserFile /var/.htpasswd
                Require user hogehoge
                AllowOverride All
        </directory>

と編集しドキュメントルートにあるphpMyAdminへのシンボリックリンクは削除しておきましょう。
ちゃんとApache2は再起動しましょう。
これでちゃんと接続できるようになりました。

P.S.
はやくApache2をSSL通信に対応させたいのですが、なかなかうまくいかなくて…
でき次第投稿します。

$ su
# apt-get install php4-pear
# /etc/init.d/apache2 restart

次にMoguraをダウンロードし、説明通り/inc/config.phpの設定を編集します。
このときデータベースの名前を決めWordPressのインストール時のようにphpMyAdminからその名前のデータベースを作っておきます。
Moguraフォルダをドキュメントルートにコピーします。
ブラウザから「http://サーバーのアドレス/mogura/setup.php」にアクセスします。
セットアップが完了したら説明通りsetup.phpは削除しておきましょう。
「http://サーバーのアドレス/mogura/w3a.php」が今後アクセス解析を確認するページです。

次にログを取得するためのタグを追加しましょう。
Moguraのトップページの左のメニューの「コントロールパネル」をクリックし「ログ取得用」をクリックします。

使うのは「WriteType:JavaScript and Image （拡張子がPHP以外のページ）」です。このタグをコピーしておきます。
これをテーマファイルの「header.php」の「div id=”left-col”」の行の下に貼付けて保存します。
これでOKです。

まずはユーザーを作成します。
トップページの「特権」をクリックします。

次に「ユーザを追加する」をクリック

ログイン情報を入力

ユーザー名に「wordpress」(自由に変更してください)
ホストをローカル／localhost
パスワードも決めて入力してください。
グローバル特権は「データ」と「構造」に関する権限にすべてチェックしてください。

「実行する」ボタンをクリックしユーザー登録を完了します。

次にトップページから新しくデータベースを作成します。

データベース名を決めて「utf8_unicode_ci」を選択し作成します。

次に「WordPress」をダウンロードし、ドキュメントルートに配置します。
WordPress JapanのダウンロードからWordPress のversion2.0系列あるいは2.3系列の最新版のmultilingual-editionをダウンロードします。
今回は「wordpress-2.0.11-multilingual-edition」をダウンロードし、解凍しフォルダーを好きな名前に変更しておきます。今回は「wordpress」というフォルダ名にしドキュメントルート(以下の例では/home/www/chibiegg/)にフォルダーごとコピーしました。
そしてこのフォルダー以下のパーミッションを777に変更します。

$ su
# chmod -R 777 /home/www/chibiegg/wordpress/

次にブラウザからインストール作業を行うため
「http://サーバーのIPアドレス/さっき決めたフォルダ名/」を開きます。先ほどのフォルダ名「wordpress」にすると「http://サーバーのIPアドレス/wordpress/」を開くことになります。以下のページが出ます。

「ウィザード」をクリック

「こちらをクリック」をクリック

設定画面が出るので
データベース名を先ほど作った「wordpress」
ユーザー名も先ほど作った「wordpress」
パスワードはそのときのSQLのパスワード
ホスト名とテーブル接頭語はそのまま
ブログの文字エンコードは「UTF-8」
にして「submit」ボタンをクリックします。

「インストール」をクリック
次に「First Step »」をクリック。文字化けしている場合はブラウザのエンコードを「UTF-8」にする。
First Stepでブログ名とメールアドレスの設定
Second Stepに進むとユーザー名とパスワードが発行されるのでメモしておきます。
ログインして「マイアカウント」メニューからパスワードを好きなものに変更しておきましょう。
最後にパーミッションを755にします。

$ su
# chmod -R 755 /home/www/chibiegg/wordpress/

これでWordPressのインストールは終了です。

現在のデフォルトの状態では「/etc/apache2/sites-available」に「default」というサイト設定が。有効にするために「/etc/apache2/sites-enabled」に「000-default」という「default」のシンボリックリンクが作成されており、有効になっています。
では新しく「http://chibiegg.homeip.net/」というサイトを作ってみましょう。
しかしここで注意です。「chibiegg.homeip.net」という名前を自分のサーバーにただ登録すればそのアドレスが使えるようになる訳ではありません。
どこかのサービスを利用して(例:http://www.dyndns.com/やhttp://ddo.jp/)DDNSサービスやDNSサービスに登録する必要があります。
これについては今度言及しようと思いますので、googleなどで検索してみてください。「ddo.jp」は日本語なのでおすすめです。今回は「dyndns」で「chibiegg.homeip.net」を取得したとします。

それでは新しいサイト情報を「chibiegg-homeip」として作りましょう。このファイル名やアドレスは今後各自の情報にあわせてください。
このサイトのドキュメントルートは「/home/www/chibiegg」とします。このフォルダーも自由に変えていただいて構いません。

$ su
# mkdir /home/www/chibegg/
# cd /etc/apache2/sites-available
# vi chibiegg-homeip

とし新規作成します。
そして以下のように書きます。

NameVirtualHost *
<VirtualHost *>
	ServerAdmin webmaster@chibiegg.homeip.net
	DocumentRoot /home/www/chibiegg
	ServerAlias chibiegg.homeip.net
	<Directory />
		Options -Indexes FollowSymLinks
		AllowOverride None
	</Directory>
	<Directory /home/www/chibiegg/>
		Options -Indexes FollowSymLinks MultiViews
		AllowOverride None
		Order allow,deny
		Allow from all
	</Directory>
	ErrorLog /var/log/apache2/error.log
	# Possible values include: debug, info, notice, warn, error, crit,
	# alert, emerg.
	LogLevel warn
	CustomLog /var/log/apache2/access.log combined
	ServerSignature On
</VirtualHost>

「ServerAdmin」にメールアドレス
「ServerAlias」に取得したドメイン
「DocumentRoot」にドキュメントルート
2つめの「Directory」にドキュメントルート
にするということです。
さらにこのアドレスからも「phpMyAdmin」に接続したければ以前の記事をもとにドキュメントルートに「phpMyAdmin」のシンボリックリンクを作成し、必要であればこのサイト設定にもBASIC認証の設定をつけてください。

続いてこの作成したサイト設定のシンボリックリンクを「/etc/apache2/sites-enabled」に「001-chibiegg-homeip」という名前で作成し、最後にapache2を再起動します。

# cd /etc/apache2/sites-enabled
# ln -s /etc/apache2/sites-available/chibiegg-homeip ./001-chibiegg-homeip
# /etc/init.d/apache2 restart

確認するために新しいサイトのドキュメントルートに以下のような「index.htm」をつくります。

  <html>
    <body>
      <h1>It works! on chibiegg.homeip.net</h1>
    </body>
  </html>

確認のために「http://chibeigg.homeip.net/index.htm」(取得したドメイン)でブラウザから接続しましょう。

It works! on chibiegg.homeip.net

と出ればOK

今回は「MySQL」の確認のついでに「phpMyAdmin」をインストールします。
phpMyAdminはブラウザ経由で「MySQL」の管理ができるツールです。
まずは「phpMyAdmin」をインストールします。

$ su
# apt-get install phpmyadmin

phpMyAdminは「/usr/share/phpmyadmin」にインストールされるのでこのフォルダーをApache2でブラウザ経由でみれるようにしましょう。
今回は「/usr/share/phpmyadmin」へのシンボリックリンクを「/var/www」に作成することで実現したいと思います。

# cd /var/www
/var/www# ln -s /usr/share/phpmyadmin ./

では、ブラウザから「http://サーバーのIPアドレス/phpmyadmin」を開いてみましょう。以下のような画面がでれば「phpMyAdmin」のインストールは成功です。

ユーザー名は「root」
パスワードは前回設定したMySQLのrootのパスワード
を入力しログインします。
ここでエラーがなくログインできれば「MySQL」のインストールも成功です。
このままでは「phpMyAdmin」のログイン画面まで誰でも開くことができてしまいます。これを防ぐためにログイン前にもパスワードを設定しましょう。以下のようなWebサーバーのBASIC認証を使用します。

まずはBASIC認証に必要なユーザー名とパスワードのリスト(.htpasswd)を「/var」（どこでも構いません）に作ります。以下の例では新しく.htpasswdを作成しhogehogeというユーザーを作るということです。

# cd /ver
/var# htpasswd -c .htpasswd hogehoge
New password: ここにパスワードを入力（実際は表示されない）
Re-type new password: もう一度入力（実際は表示されない）

「New password」「Re-type new password」を入力するときはキーを押しても表示されませんが入力されていますので注意。
二回目以降ユーザーを登録する場合は[-c]オプションを外して以下のように。

# cd /ver
/var# htpasswd .htpasswd hogehoge2
New password: ここにパスワードを入力（実際は表示されない）
Re-type new password: もう一度入力（実際は表示されない）

次にこのパスワードを使って「phpMyAdmin」のアドレスに「BASIC認証」をかけましょう。そのためにはApache2のサイト設定を変更します。
「/etc/apache2/sites-available/default」を編集します。

# vi /etc/apache2/sites-available/default

以下のものをどこかの「」の後にでも追記します。

        <Directory "/var/www/phpmyadmin">
                AuthType Basic
                AuthName "phpMyAdmin"
                AuthUserFile /var/.htpasswd
                Require user hogehoge
        </Directory>

「/var/.htpasswd」と「hogehoge」のところは適時変更してください。
これによって

実ディレクトリの「/var/www/phpmyadmin」への接続には「BASIC認証」が必要で「/var/.htpasswd」のユーザー「hogehoge」がログインできます。

ということになります。

複数のユーザー名でログインできるようにするには
「Require user hogehoge hogehoge2」のようにスペースでユーザーを区切ってください。

さらに設定を有効にするためにApache2を再起動します。

# /etc/init.d/apache2 restart

もう一度phpMyAdminを開くと

のように認証を求められログインできれば成功です。

$ su
# apt-get install php4-gd
# /etc/init.d/apache2 restart

これで投稿画面にあるアップロードから画像をアップロードするとサムネイルが作成されるようになりました。

次にサムネイルのサイズを変更しようともいます。
標準では128×96のうち小さい方にあわせられるようになっているが、ちょっと小さいので400×300にしようとおもいます。これはソースの関係上4:3がいいです。
編集するファイルは「WordPressフォルダ/wp_admin/inline-uploading.php」です。
90行目ぐらいに以下のような記述があります。

	if ( $imagedata['width'] * $imagedata['height'] < 3 * 1024 * 1024 ) {
		if ( $imagedata['width'] > 128 && $imagedata['width'] >= $imagedata['height'] * 4 / 3 )
			$thumb = wp_create_thumbnail($file, 128);
		elseif ( $imagedata['height'] > 96 )
			$thumb = wp_create_thumbnail($file, 96);

		if ( @file_exists($thumb) ) {
			$newdata = $imagedata;
			$newdata['thumb'] = basename($thumb);
			update_post_meta($id, '_wp_attachment_metadata', $newdata, $imagedata);
		} else {
			$error = $thumb;
		}
	}

この中の「128」と「96」をすべて以下のように「400」と「300」に変更しましょう。

	if ( $imagedata['width'] * $imagedata['height'] < 3 * 1024 * 1024 ) {
		if ( $imagedata['width'] > 400 && $imagedata['width'] >= $imagedata['height'] * 4 / 3 )
			$thumb = wp_create_thumbnail($file, 400);
		elseif ( $imagedata['height'] > 300 )
			$thumb = wp_create_thumbnail($file, 300);

		if ( @file_exists($thumb) ) {
			$newdata = $imagedata;
			$newdata['thumb'] = basename($thumb);
			update_post_meta($id, '_wp_attachment_metadata', $newdata, $imagedata);
		} else {
			$error = $thumb;
		}
	}

これでサムネイルのサイズも変更できます。

まずは「Apache2」から

$ su
# apt-get install apache2

続いて「PHP4」「MySQLServer」

# apt-get install php4 php4-dev
# apt-get install mysql-server
# apt-get install libapache2-mod-php4

これでインストールは完了。
このままでは「MySQL」 のrootパスワードが空なのでrootパスワードを設定します。この「root」ユーザーはDebianの「root」ユーザーとは関係ありません。（同じパスワードにしてもいいですが。）

# /usr/bin/mysqladmin -u root password '設定するパスワード'

としておきましょう。

ではそれぞれ確認をしていきます。
サーバー自身なら「http://localhost/」あるいはLANにつながっているコンピューターのブラウザから「http://サーバーのIPアドレス/」
に繋いでみましょう。
自動的に「http://サーバーのIPアドレス/apache2-default/」にリダイレクトされて

It works!

と出れば「Apache2」のインストールは成功しています。

次に「PHP4」の確認をしましょう。
Apache2では標準で「/var/www」をドキュメントルートとしています。
ドキュメントルートとは「http://サーバーのIPアドレス/」と接続されたときにこのフォルダーを示すということです。
つまり「http://サーバーのIPアドレス/index.htm」は「/var/www/index.htm」を示すということです。
「PHP4」の確認をするために実際に何か「php」のスクリプトを「/var/www」に作ってみましょう。

# vi /var/www/test.php

として新しく「test.php」を作成し

  <html>
  <head>
  <title>php information</title>
  </head>
  <body>
  <?php phpinfo(); ?>
  </body>
  </html>

と記述して保存します。
先ほどと同じようにブラウザから「http://サーバーのIPアドレス/test.php」へ接続し、PHPの情報が表示されれば成功です。

では「MySQL」の確認は「phpMyAdmin」のインストールとともに次回にしたいと思います。