OpenSolaris – bluegold

OpenSolaris 134b で php-cgi が動作しない

bg — Tue, 23 Nov 2010 14:58:03 +0000

Oracle Solaris 11 Expressがようやく公開されました。このブログを動かしている OpenSolaris 2009.06 の次のバージョンは、当初 OpenSolaris 2010.02 になるはずだったので、9ヶ月遅れてのバージョンアップとなりました。

Sun が Oracle に買われて以降、Solaris がどうなるのかハッキリしない状態が続いていたので、新しいバージョンがリリースされた事は良かったと思います。OpenSolais の体制のままで新バージョンがリリースされていれば最高だったんですけどね。

リリースはされましたが、Oracle Solaris 11 Express は snv_151 で、OpenSolaris 2009.06 の snv_111b からは大きく変わっているらしく、一回でアップグレードはできません。一度 snv_134b（キャンセルされていた OpenSolaris 2010.06 になるはずだったバージョンですね）に上げた後で、パッケージリポジトリ（パブリッシャ？）を変更して再度アップグレードを行う必要があるようです。

最終的に Oracle Solaris 11 Express（毎回書くのは長いな、略称は何だろ？）を使うか、OpenIndiana を使うようになるかは分かりませんが、どちらにしろ 134b にアップデートしておく必要はあるみたいです。

134b へのアップデート方法

アップデートはpkg image-updateコマンドで行いますが、先に SUNWipkg パッケージを更新しておく必要があるみたいです。

pfexec pkg install SUNWipkg
pfexec pkg image-update -v --be-name snv_134b

いろいろとパッケージをインストールして遊んでいたので、2時間くらいかかりました。

本番環境をアップグレードする前に VirtualBox に OpenSolaris 2009.06 をインストールして、アップデートの実験は何度もしていたので、この手順自体は問題なく終わりました。svcsコマンドでサービスの起動状況を確認して、maintenance になっているものも無かったので、アップグレードは無事終わったかと思っていましたが、ブログを表示させようとするとこんな感じになっていました。

お使いのサーバーの PHP では WordPress に必要な MySQL 拡張を利用できないようです。

問題の調査

php-cgi コマンドが正常に動いていないのか、と思い直接実行してみると

# /usr/php/bin/php-cgi -v
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/php/5.2/zts-modules/apc.so' - ld.so.1: php-cgi: 重大なエラー: 再配置エラー: ファイル /usr/php/5.2/zts-modules/apc.so: シンボル compiler_globals_id: 参照シンボルが見つかりません。 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/php/5.2/zts-modules/bz2.so' - ld.so.1: php-cgi: 重大なエラー: 再配置エラー: ファイル /usr/php/5.2/zts-modules/bz2.so: シンボル core_globals_id: 参照シンボルが見つかりません。 in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/php/5.2/zts-modules/curl.so' - ld.so.1: php-cgi: 重大なエラー: 再配置エラー: ファイル /usr/php/5.2/zts-modules/curl.so: シンボル core_globals_id: 参照シンボルが見つかりません。 in Unknown on line 0
PHP Warning:  PHP Startup: ftp: Unable to initialize module
Module compiled with module API=20060613, debug=0, thread-safety=1
PHP    compiled with module API=20060613, debug=0, thread-safety=0
These options need to match
 in Unknown on line 0
（略）
PHP 5.2.12 (cgi-fcgi) (built: Apr  5 2010 20:00:17)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies

マルチスレッドでない PHP のプロセスから、マルチスレッドを有効にしたモジュールを読み込もうとして失敗しているようです。php コマンドは正常に動作していましたが、nginx は CGI を使えない。そもそも zts-modules なんてディレクトリは php.ini で指定していないのに、どこから出てきたのかがわかりません。

しばらく悩みましたが、phpinfo() の出力を見て、ようやく気がつきました。

Loaded Configuration File	/etc/php/5.2/nsapi/php.ini

これまでは/etc/php/5.2/php.ini を読んでいたのが、バージョンアップ時に変わってしまっていたようです。NSAPI 用の php.ini ならスレッドセーフのモジュールを読むのは自然です。（NSAPI が現役なのかは知りませんが。自分で最後に NSAPI モジュールを書いたのは13年くらい前か。）

原因は分かれば修正は簡単で、/etc/php/5.2/nsapi/php.ini を以下のように修正して問題解決。

543c547
< extension_dir=/usr/php/5.2/zts-modules
---
> extension_dir = "/usr/php/5.2/modules:/var/php/5.2/modules"

nginx を SMF で管理する

bg — Mon, 02 Aug 2010 16:36:59 +0000

もう1年以上前に書いていた下書きをようやく公開。

前回（と言っても1年半前か）までで nginx と PHP の fast-cgi のビルドと設定が終わったので、OS の起動時に自動的に起動するようにサービスとして登録を行います。

OpenSolaris ではサービスの管理に SMF という仕組みを使用しています。SMF はサービスの依存関係を記述できたり、サービスの起動を監視して自動的に再起動してくれたりと、Linux などで使われている /etc/init.d の rc スクリプトに比べるとメリットがありますが、コマンドが独自だったり、自分で SMF にサービスを登録するには manifest と呼ばれる XML ファイルを書く必要があるので、慣れるまではハードルがあります。（この辺は Mac OS X の launchd と似ている。）

以下が、私が nginx を管理するために作成した nginx.xml です。

このファイルを以下のように SMF に登録します。

# svccfg -v import nginx.xml

同様に PHP の FastCGI のプロセスも SMF に登録します。

この xml も同じように svccfg コマンドで登録します。

起動用の shell スクリプトはこちらのサイトのものを、ほぼそのまま使っています。

#!/bin/bash

LC_ALL=ja_JP.UTF-8

#FastCGI Webserver path
FCGI_WEB_SERVER_ADDRS="127.0.0.1"

## ABSOLUTE path to the PHP binary
PHPFCGI="/usr/php/bin/php-cgi"

## tcp-port to bind on
FCGIPORT="9000"

## IP to bind on
FCGIADDR="127.0.0.1"

## number of PHP children to spawn
PHP_FCGI_CHILDREN=5

## number of request before php-process will be restarted
PHP_FCGI_MAX_REQUESTS=1000

# allowed environment variables sperated by spaces
ALLOWED_ENV="PATH"

## if this script is run as root switch to the following user
USERID=webservd

################## no config below this line

ALLOWED_ENV="$ALLOWED_ENV PHP_FCGI_CHILDREN"
ALLOWED_ENV="$ALLOWED_ENV PHP_FCGI_MAX_REQUESTS"
ALLOWED_ENV="$ALLOWED_ENV FCGI_WEB_SERVER_ADDRS"

if test x$UID = x0; then
  EX="/bin/su -m -c \"$PHPFCGI -q -b $FCGIADDR:$FCGIPORT\" $USERID"
else
  EX="$PHPFCGI -b $FCGIADDR:$FCGIPORT"
fi

echo $EX

# copy the allowed environment variables
E=

for i in $ALLOWED_ENV; do
  E="$E $i=${!i}"
done

# clean environment and set up a new one
nohup env - $E sh -c "$EX" &

サービスが SMF に登録できれば、svcadm コマンドで起動停止を切り替える事ができます。

起動

# svcadm enable nginx
# svcadm enable php-fastcgi

停止

# svcadm disable nginx
# svcadm disable php-fastcgi

Snow Leopard で IP alias を設定する

bg — Fri, 04 Jun 2010 01:57:32 +0000

Snow Leopard でNICにIP aliasを設定する方法のメモ。

IP alias の追加

sudo ifconfig en0 alias 192.168.0.1 255.255.255.0

IP alias の削除

sudo ifconfig en0 -alias 192.168.0.1

ついでに Linux と OpenSolari での設定方法もメモ。

Linux の場合

IP alias の追加

# /sbin/ifconfig eth0:1 192.168.0.1/24

IP alias の削除

# /sbin/ifconfig eth0:1 down

OpenSolaris の場合

IP alias の追加

pfexec ifconfig gbe0:1 plumb
pfexec ifconfig gbe0:1 192.168.0.5 netmask 255.255.255.0 up

IP alias の削除

pfexec ifconfig gbe0:1 down
pfexec ifconfig gbe0:1 unplumb

Snow Leopard のやり方のほうが、何個目のエイリアスなのかを考えなくてもいいので楽なのかなぁ。
エイリアス単位でインターフェースの UP/DOWN はできなそうだけど。

Redmine を監視して再起動する

bg — Tue, 20 Apr 2010 16:35:50 +0000

正確には Redmine が原因なのかどうかは判明していませんが、OpenSolaris 上に構築した Redmine が起動後何時間かすると500 Internal Errorを返すようになってしまいました。

Redmine は以下のような環境で動かしています。

Redmine 0.9.3
OpenSolaris 2009.06
Ruby 1.8.7-p249
Rails 2.3.5
Unicorn 0.97.0
nginx 0.7.65

Ruby は /opt/sunstudio12.1/bin/cc(Sun Studio Express 12)でビルドしています。

OpenSolaris に付属の /usr/bin/ruby を使っていた時には問題なく動作していたんですが、Redmine 0.9.3 にバージョナップした所、致命的な問題が発生したため、Ruby を自分でビルドするように変更していました。

落ちているの気がついたら手動で再起動をしていたのですが、さすがにメンドウになってきたのでスクリプトを書きました。

#!/bin/sh

while `/bin/true`
do
    http_code=`curl --insecure -w "%{http_code}" -s -o /dev/null https://redmine/login`
    ts=`date +"%Y/%m/%d %H:%M:%S"`

    if [ $http_code -eq 200 ]; then
        echo $ts OK
        sleep 300
        continue
    fi

    cd /var/www/redmine
    pid=`cat tmp/pids/unicorn.pid`

    kill -USR2 $pid
    sleep 5
    kill $pid

    echo $ts unicorn $pid reloaded.
done

exit 0

手順としては、5分おきに curl で HTTP のステータスコードのみを受け取り、200 OKが帰ってこない場合は再起動、という流れです。

Unicorn は SIGUSR2 を送ると自分自身を fork() してから終了するはずなのですが、終了せずに残るので子プロセスの起動を待ってから SIGTERM を送っています。

とりあえずは、これで気にはならなくなりましたが。。。

そのうち、God あたりに切り替えよう。

OpenSolarisのftpdでファイル一覧の表示に問題

bg — Mon, 22 Feb 2010 17:31:57 +0000

外部のデザイナーさん（HiGash.Net の中の人だけど）と仕事をしたときの話です。

私の構築したステージング用のサーバにデザイナーさんの作ったコンテンツを置いてもらう必要があったので、「sftp でいいですか？」と聞いたら「ftpの方がいい」と言われたので、急遽 ftp サーバの用意をすることになりました。

軽く「いいよ」と答えたものの、自分で最後に ftpd をたてたのはもう１０年近く前のことで何も覚えてません。
Solaris なのでSMFで管理されているftpdがあるだろうと思い、試してみると

$ pfexec svcadm enable ftp
$ svcs -l ftp
fmri         svc:/network/ftp:default
name         FTP server
有効         true
状態         online
next_state   none
state_time   Tue Feb 23 02:02:15 2010
リスタータ   svc:/network/inetd:default
contract_id

無事に起動できました。簡単簡単。

念のため、ファイアウォール越しに ftp コマンドで接続テストを行い、passive mode が on でも off でも問題がなかったので、使ってもらいました。

しかし、しばらくすると「FTPサーバに接続は出来たけど、ファイルが何も表示されない」との報告が。。。

使っている ftp のクライアントソフトはFFFTPだという事なので、同じトラブルにあっている人がいるだろうと思いGoogleに聞いてみたところ、このページで原因と思われる記述を発見しました。

「タイムスタンプに含まれる日本語文字列の処理の問題」

ftpコマンドで接続して確認すると、ファイルの更新日付が確かに日本語で返ってきています。これなら in.ftpd のロケールを変えてあげれば問題は解決しそうです。

また、Googleに聞いてみるとこのページに回答がそのまま書いてありました。

SMF なので svccfg を使うのかと思ったら、in.ftpd は inetd に管理されているので、inetadmというコマンドを使うんですね。初めて知った。

以下のコマンドで、FFFTPでも正常にファイル一覧が表示されるようになりました。

$ pfexec inetadm -m ftp inherit_env=FALSE
$ pfexec svcadm restart ftp

OpenSolarisで64bitのnginxをビルドする

bg — Thu, 04 Feb 2010 09:05:29 +0000

nginxの新しいバージョン(0.7.65)がリリースされていたので，バージョンアップしてみました。

しばらく前に見つかっていたSSLの脆弱製の実験をやろうと、久しぶりに SSL を有効にしたバイナリを作ろうとしたのですが，オプションの設定の仕方を忘れていて苦労しました。また、忘れても大丈夫なようにメモ。

OpenSolaris 2009.06 に含まれるOpenSSLは 0.9.8a と古いので、現時点での最新バージョンであるopenssl-0.9.8lをダウンロードしてきて使いました。今回はSNI(Server Name Indication)を有効にしたいのでenable-tlsextオプションを渡しています。

./config --prefix=/usr/local no-shared enable-tlsext
make
pfexec make install

これだけでもビルドは出来るのですが，OpenSolaris 2009.06 のデフォルトの GCC 3.2.3 ではなく新しい /usr/bin/gcc-4.3.2 を使いたいので，少し手を入れています。

export CC=/usr/bin/gcc-4.3.2
export CFLAGS='-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -march=native -O3 -Wall -DL_ENDIAN -DMD32_REG_T=int -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM' 
./Configure --prefix=/usr/local no-shared enable-tlsext solaris64-x86_64-gcc
make
pfexec make install

export CC=/usr/bin/gcc-4.3.2した後にconfigスクリプトを実行すると，solaris64-x86_64-gcc-4.3.2 みたいな os:compiler になってエラーになってしまうんですよね。回避方法を探すのに手間取ってしまいました。

次に nginx のビルドですが，普通に configure を実行すると 32bit のバイナリが出来てしまいますので、gcc に渡すオプションも configure に渡します。

./configure --prefix=/usr/local --with-http_stub_status_module --with-http_gzip_static_module --with-http_ssl_module --with-cc=/usr/bin/gcc-4.3.2 --with-cc-opt='-m64 -march=native -O3 -I/usr/local/include ' --with-cpu-opt=amd64 --with-ld-opt='-m64 -L/usr/local/lib -L/usr/lib/amd64'
make
pfexec make install

ビルドした内容を確認

$ file /usr/local/sbin/nginx
/usr/local/sbin/nginx:  ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, stripped

$ /usr/local/sbin/nginx -V
nginx version: nginx/0.7.65
built by gcc 4.3.2 (GCC) 
TLS SNI support enabled
configure arguments: --prefix=/opt/local --with-http_stub_status_module --with-http_gzip_static_module --with-http_ssl_module --with-cc=/usr/bin/gcc-4.3.2 --with-cc-opt='-m64 -march=native -O3 -I/usr/local/include' --with-cpu-opt=amd64 --with-ld-opt='-m64 -L/usr/local/lib -L/usr/lib/amd64'

SNIも有効になっています

zfsとタイムスライダーでハマった事

bg — Tue, 29 Sep 2009 10:09:41 +0000

今回の秋の連休は有休も使って9連休にしていました。
休み明けのボケた頭では仕事にならないので、午前中は開発用サーバたちのパッケージのアップデートをしていたところ、その中の１つにログインできませんでした。

そのホストは OpenSolaris 2009.06 の中に立てた Linux Branded Zone（BrandZ と書いた方がいいのかな）にインストールした CentOS3 でした。Solaris の Zone なので、ホストOS の方からは自由に Linux のファイルシステムに入っていけます。中のファイルを調べたところ、ログファイルの１つが46GB以上に肥大化してしまってディスクの残り容量が無くなってしまっているのが原因のようでした。

これなら、巨大化したログファイルを削除すれば問題解決だな、と軽い気持ちでrm ログファイル を実行したところ、意外な結果が戻ってきました。

cannot delete file: no space left on device.

ディスクに空き領域が無いからファイルを消したいのに、空き領域が無いからファイルを消せないと言われても。。。

ファイルシステムが壊れているのかと zpool scrub を実行してもエラーは無し。

Google 先生に質問してみたところ、zfs の既知のバグのようでした。曰く、ディスクの残り容量が無くなるとスナップショットが存在するファイルは削除できない。スナップショットの無いファイルを消して空き領域を作るか、スナップショットを削除すればよいようです。

が、zfs は使っているもののスナップショットなんて取ったことはありません。
不思議に思い zfs list -t snapshotを実行したところ、以下のように大量のスナップショットが存在していました。

rpool/ROOT/OpenSolaris-200906-090928@2009-07-10-00:41:02                      17.4M      -  2.85G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-10-17:54     39.5K      -  6.93G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:weekly-2009-07-10-17:54      40K      -  6.93G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:monthly-2009-07-10-17:54   1.11M      -  6.93G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-11-00:00     3.67M      -  6.94G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-12-00:00     2.86M      -  7.14G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-13-00:00     5.29M      -  7.14G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-14-00:00     21.1M      -  7.26G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:weekly-2009-07-15-00:00    1.29M      -  7.26G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-16-00:00      528K      -  7.26G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-17-00:00     3.73M      -  7.26G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-18-00:00     1.67M      -  7.35G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-19-00:00     1.05M      -  7.35G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-20-00:00     1.08M      -  7.35G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-21-00:00     1.22M      -  7.35G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:weekly-2009-07-22-00:00    1.35M      -  7.35G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-23-00:00     1.35M      -  7.35G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-24-00:00     5.91M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-25-00:00     5.93M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-26-00:00     5.87M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-27-00:00     6.60M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-28-00:00     6.42M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:hourly-2009-07-28-11:00    1.73M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:hourly-2009-07-28-12:00    1.71M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:hourly-2009-07-28-13:00    1.93M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:hourly-2009-07-28-14:00    1.88M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:hourly-2009-07-28-15:00    1.79M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:hourly-2009-07-28-16:00    1.26M      -  7.40G  -
...

犯人（？）は zfs の自動スナップショット機能でした。たしかにインストール直後に試しにタイムスライダーを有効にしたことがありましたが、こんな事になるとは。

大量のスナップショットを削除するようにシェルスクリプトを作成して問題は解決しました。ただ、ググっている時に「rpool の容量がなくなるとリブートもできなくなる」のような話もあったので、タイムスライダー（自動スナップショット）はちょっと恐くて使えないなぁ。