Category Archives: Webサーバー

nginxでSSL/TLSを使う

今回はSSL(https)を使えるようにするような設定をnginxにしてみようと思います。

証明書の取得

本来はSECOMやVeriSign等に有料で証明してもらうのですが、今回は以前にも紹介した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ディレクティブを作ってあげてください。

 

 

nginxでプロキシ&キャッシュサーバー

(多分)一般的なWebサーバーであるApacheは複雑な設定も可能で便利なのですが、その分重いのです。

どう重いのかというと、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に置くというのもやってみます)

Read more …

Mac OS X Leopard Server で WordPress の自動アップデート

以前の記事で、WordPressでの自動アップデートを成功させるためには、FTP_BASEやFTP_CONTENT_DIRやFTP_PLUGIN_DIRを定義すればよいと記事に書きました。

が、その記事に書いた通り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等を定義しても自動アップデートできました。

WordPressの自動アップデートエラーについて

WordPressにはプラグインや本体をFTP経由で自動でアップデートする機能がありますが、だいたいは「ディレクトリが見つかりません」といわれてしまいます。

そんな場合は「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ユーザとしてサーバ上にある各フォルダへのパスが分かっていれば…」とあるのでこれで正しいと思われます。

CAcertから証明書をもらおう!(その0:紹介)

CAcertとはこちらの記事が詳しいですが簡単に言うと無料でX.509セキュリティ証明書を発行してくれる認証機関です。
CAcertロゴマーク
本来証明書は「Verisign」や「セコム」などに多くの費用を払わないともらえず、どうしてもその費用を払ってでもセキュリティを必要とするサーバー(本社と支店を接続したり、Amazonなどのネットショッピングサイト、あるいは銀行のネットバンキングなど)にしか導入できないものですが、CAcertボランティアによってすすめられている無料の認証局です。

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

同一タイトルでの新規投稿不可問題

なぜか、他のWordPressの動作テストをしていたら「公開」ができなくなったので(詳細は割愛)こっちのも確認。

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

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

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

WordPressの管理画面をLeopard風に

Leopardぽいスキンを探しているときに見つけたものです。
おもしろそうだったので入れてみました。
「LepardAdmin」をインストールすると管理画面が以下のような感じになります。

LeopardAdmin導入例

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

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

eAcceleratorの導入

複数あるPHPのアクセラレータの一つである「eAccelerator」を導入してみました。

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

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

<code>
$sudo aptitude install libtool
$sudo aptitude install libguile-dev
$sudo aptitude install automake
$sudo aptitude install g++
</code>

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

<code>
$ 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
</code>

とすると
Read more …

PHP5にバージョンアップ

前回PHP5にアップデートしたいと書きましたが成功したのでメモをしておきます。

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

<code>
$ su
# dpkg -l
</code>

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

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」をインストールします。

<code>
# apt-get install php5
</code>

すると
Read more …

MediaWikiとPHP4とPHP5

Wikipediaの為に作成されたMediaWikiを試してみようと思ったが、PHP4には対応していないそうだ。
一度サーバーのバックアップを取ってPHP5にバージョンアップができるか試してみようと思う。

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