私の構築したステージング用のサーバにデザイナーさんの作ったコンテンツを置いてもらう必要があったので、「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

3ヶ月ほど前に、10年以上使い続けたCVSからMercurialにソース管理を移行しました。（Subversion は手になじまなかった。）

移行して不便に感じるのはViewVCが使えなくなった事くらいで、普段はあまり違いは感じていませんが、１つだけ直感的にやり方が分からなくて困る事があります。

ワーキングディレクトリで作業中に誤って必要なファイルを削除してしまった場合、例えば

$ ls -l
total 8
-rw-r--r--  1 user  staff  1345 Jan 16 22:33 Makefile
drwxr-xr-x  5 user  staff   170 Jan 16 22:45 help/
drwxr-xr-x  5 user  staff   170 Jan 16 22:33 tutorial/
$ rm Makefile

としてしまった場合、必要なファイルが存在しない事は hg status コマンドで調べる事ができます。

$ hg status
! Makefile

CVS(やSubversion)では、誤って削除したファイルはcvs update(svn up)で元に戻すことができますが、Mercurial ではそうはいきません。

$ hg update
ファイル状態: 更新数 0、マージ数 0、削除数 0、衝突未解決数 0
$ ls -l
total 0
drwxr-xr-x  5 user  staff  170 Jan 16 22:45 help/
drwxr-xr-x  5 user  staff  170 Jan 16 22:33 tutorial/

このように削除されたファイルはそのままです。

Mercurial では update コマンドはワーキングディレクトリのリビジョンを変更するコマンドなので、この動きで正しいらしいのですが、CVS等から乗り換えてくるとちょっとビックリします。

このような場合はhg revertを使うのが正しいらしいです。

$ hg revert Makefile
$ ls -l
total 8
-rw-r--r--  1 user  staff  1345 Feb  2 02:41 Makefile
drwxr-xr-x  5 user  staff   170 Jan 16 22:45 help/
drwxr-xr-x  5 user  staff   170 Jan 16 22:33 tutorial/

今回の秋の連休は有休も使って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 の容量がなくなるとリブートもできなくなる」のような話もあったので、タイムスライダー（自動スナップショット）はちょっと恐くて使えないなぁ。