あーありがち

過去の日記 2012-12 2012-01 2011-12 2011-11 2011-10 2011-09 2011-08 2011-07 2011-06 2011-05 2011-04 2011-03 2011-02 2011-01 2010-12 2010-11 2010-10 2010-09 2010-08 2010-07 2010-06 2010-05 2010-04 2010-03 2010-02 2010-01 2009-12 2009-11 2009-10 2009-09 2009-08 2009-07 2009-06 2009-05 2009-04 2009-03 2009-02 2009-01 2008-12 2008-11 2008-10 2008-09 2008-08 2008-07 2008-06 2008-05 2008-04 2008-03 2008-02 2008-01 2007-12 2007-11 2007-10 2007-09 2007-08 2007-07 2007-06 2007-05 2007-04 2007-03 2007-02 2007-01 2006-12 2006-11 2006-10 2006-09 2006-08 2006-07 2006-06 2006-05 2006-04 2006-03 2006-02 2006-01 2005-12 2005-11 2005-10 2005-09 2005-08 2005-07 2005-06 2005-05 2005-04 2005-03 2005-02 2005-01 2004-12 2004-11 2004-10 2004-09 2004-08 2004-07 2004-06 2004-05 2004-04 2004-03 2004-02 2004-01 2003-12 2003-11 2003-10 2003-09 2003-08 2003-07 2003-06 2003-05 2003-04 2003-03 2003-02 2003-01 2002-12 2002-11 2000-08

_ 一区切り

ネタでもなんでもなく。

区切りがついた。あー別に転職したとかでもないです。

ただただ普通に区切りがついたぞと。

そんだけ。

_ で、ないわーって何？

わっかんね。

とりあえずまとめっぽいところへリンク。

2008-04-07 - 404 ないわー Not Found 3.0

様子を見ることに。

_ OpenSSH にできること（の一部）ヒストリ

全面的に OpenSSH情報 頼みです！ 5.0 から 3.9 までのリリースノート中の変更点の和訳からつまみ食いしました。

自分の興味ないところ、分からないところはスルーしてしまいました。

5.0

bug fix のみ

4.9

• chroot対応
  • shell session が必要な場合は従来の方法通り /dev の設定とか必要
  • chroot するディレクトリは root 所有で permission を緩めちゃダメ
• internal-sftp が実装され*1、これを chroot と組み合わせて使う場合、chroot ディレクトリ以下に特別なセットアップが必要なくなる
  • scponly, rssh を使う面倒から解放される！(?)
• no-user-rc キーワード*2が authorized_keys 内で使えるように
• PermitRootLogin で Match ブロックを利用できるようになり、例えばローカルネットワークからのみ root 接続許可という形が実現可能に
• ProxyCommands が $SHELL を優先して実行するように

4.8

OpenBSD のみのリリース。

4.7

• デフォルトの接続受付 protocol を 2 のみに（これまでは 1, 2 両方）
• scp で表示できないファイル名をエンコードして "protocol error" によるコピー中断を防ぐようになった
• LocalCommand うにゃうにゃ
  • ごめんなさい、よく分かりませんorz

4.6

• Match ブロックを利用してユーザー、グループ、ホスト、ネットワークごとに認証方法の有効/無効を設定できるようになった

4.5

bug fix のみ

4.4

• sshd_config の Match の追加
  • Match にどの設定が対応するのかはバージョンによって異なるらしい
• sshd_config に ForceCommand 追加。これは authorized_keys の command="" と同等
• sshd_config に PermitOpen 追加。転送できる port を制限できるようになった。
• sftp-server がトランザクションログを取れるように
• ExitOnForwardFailure で指定のポートフォワード接続が失敗したときに終了する設定が可能に（クライアント側の設定）
• SubSystem がコマンドライン引き数を指定できるように
• SELinux サポートが configure 時の --with-selinux オプションとして追加された
• Solaris の proccess contracts サポートが configure 時の --with-solaris-contracs オプションとして追加された
• configure 時の --with-ssl-engine オプションで OpenSSL のハードウェアアクセラレーションサポートが追加された

4.3

bug fix のみ

4.2

• Compression delayed の追加。
  • これはユーザーが認証を通るまでzlib圧縮の開始を遅らせることで zlib の脆弱性を突く攻撃を防ぐためのもの。
  • OpenSSH 3.5 より古いバージョンのクライアントと組み合わせて使うにはクライアント側で Compression no にするかサーバ側で Compression yes にする必要がある。
• 接続の多重化周りであれこれ書いてあるんだけど自分が理解できてませんorz

4.1

bug fix のみ

4.0

• LocalForward, RemoteForward の書式拡張、GatewayPorts の設定項目拡張によりポートフォワードするアドレスの制限などができるように
• sshd でのアカウント期限のサポートが改善され、警告されるように
• allow, deny で拒否した接続元をログに残すように
• AddressFamily の追加
• sftp クライアントで ls コマンドの最適化や libedit による編集の強化
• ssh 接続の多重化の改善

3.9

• IdentitiesOnly の追加
  • ssh-agent よりも ssh_config で指定された鍵を優先して使うべきか否かの指定
• ssh_config を厳しくチェック
• AcceptEnv, SendEnv の追加
• MaxAuthTries 追加
  • ※ 同一ユーザーの認証の try に対する制限
• セッションの多重化 ( ControlMaster, ControlPath )

端折りまくって

3.7

• dynamic forward に SOCKS5 サポートが追加された

---

なんでこんなもん作ったかと言うと

OpenSSH ってすっげー便利で、おかげで最近の大半の Linux じゃ標準で入ってるんだけど、おかげでいつまでも古いバージョン使わされるハメになることがよくある。

つまり、あーそういえば ssh ってこんなことできなかったっけ？ と思うんだけどサーバ側が古くて使えないという状況が往々にしてあるよね、ということでどのバージョンで何ができるようになったか一覧がほしいなと思ったわけです。

これを見ると 4.5 以上が使えると結構便利だなーと思うんだけど、今使ってる sshd は自宅の FreeBSD 以外 4.3 が最新という状況…。うーんなんだかなんだかな。

_ OpenSSH を Zebedee 代わりに使う

Zebedee は便利なソフトである。wakatonoさんやただただしさんの紹介、何より、えーすいませんお名前を忘れましたが man を和訳してくださっている方によって我々日本語ネイティブにも馴染みのトンネリングツールである。

しかし今回の話はこの Zebedee をやめて ssh によるトンネルにしましたという話。

なお、お前これでほんとに運用してるの？というひどい勘違いがある可能性もあります。その場合は怒濤の勢いで突っ込んでください。

なぜ Zebedee でなく ssh なのか？

某所で使っている Zebedee トンネルの調子がずいぶん前から悪く、rsync が転送途中で何も言わなくなり、それだけなら timeout を設定して何回かトライすることで対処できるが、サーバが突然落ちたり、動いてるけど全然機能しなくなっていたりしたのに業を煮やして Zebedee をやめることにした。*1

なおこれは恐らく経路とホスト環境が絡んだ複雑な問題であり、クライアント側が同じネットワークで別なサーバに向かって張っているトンネルについては支障なく利用できているなど謎な部分が多く、

Zebedee そのものがタコだからやめるわけではない

ということは一応断っておく。

Zebedee をやめて ssh を使うことについては別に ssh が大好きだからという理由ではなく、

• ssh 越しの rsync は途中で切れないことを確認済み
• ssh 以外に別なトンネルソフトを発掘して調べて設定するのが面倒

という理由による。特に「切れないことを確認済み」というのが大きい。これ以前から ssh は session 開始に掛かる時間や転送速度の問題はあるものの「通信が強い」*2という印象を抱いていたので、「切れるのが問題ならもう ssh にしちまおう」と思った次第である。

※ しかし特にシステムアカウントを一つ用意しなければいけない ssh トンネルは正直あまり使いたくなく、他によいアプリがあるなら教えていただけると嬉しいです。あと rsync したいだけなら別にこんな面倒なことしなくてよくね？と思われるかもしれませんが、「詰まる」という現象が rsync の際によく起きるというだけで rsync しかしてないわけじゃないです。iptables などで接続元を制限するだけでなく通信路の暗号化も必須要件です。

ssh のデメリット

まず Zebedee のメリットを確認しておこう。

• システムアカウントを用意する必要がない
• 転送できるホスト、ポートをサーバ側で細かく制御できる
• Zebedee C/S 間の通信は暗号化される
• IPアドレスによる接続制限だけでなく公開鍵認証が利用できる
• Zebedee クライアントを動かしているホストだけでなく、他のホストも Zebedee のトンネルに相乗りできる（アプリケーションレベルではあるけれど LAN 間のトンネルに使える）
• TCP も UDP も転送できる
• 実際にトンネルを利用するアプリが通信を始めるまではトンネルを張らない（通信の節約）

このうち ssh にないメリットは以下になる。

1. システムアカウントを用意する必要がない
2. 転送できるホスト、ポートをサーバ側で細かく制御できる
   • （これは OpenSSH でも 4.4 以降なら可能）
3. TCP も UDP も転送できる
4. 利用するときにだけトンネルを作成する

この Zebedee にあって ssh にないメリットは、逆に言うと ssh のデメリットなわけだけれど、このうちシステムアカウントについてはあれこれ対策を盛り込むことで、UDP の転送は基本的に必要ないので我慢することで、転送ホスト、ポートの制御は結局のところ信用できないユーザーに解放するわけではないので我慢、というなんだか消極的な判断を重ねたことをまずお断りしておく。これが我慢できない人にはオススメできない。

port forward 用の ssh の設定

でまぁなんとか我慢できる状態に落ち着いたので以下その設定を紹介しておく。

• 専用のアカウントを作る（クライアント / サーバ）
• shell を制限する（サーバ側）
• chroot jail（サーバ側）
• GatewayPorts yes（クライアント側）
• ssh -N で転送以外何もしない接続（クライアント側）
• autossh で接続や ssh クライアントアプリの不調を回復（クライアント側）

結構やることが多い。ほんと、Zebedee が安定して動くなら絶対に Zebedee の方がいい。

その前に確認事項

• 利用した OpenSSH は 4.3
• プロトコル 2 だけ使おう
  • 一部のオプションはプロトコル 2 でしか動きません
• 利用したプラットフォームはクライアント/サーバともに Linux だけど、クライアント側は cygwin を使えば Windows でも実現可能
• 認証は空パスフレーズの公開鍵認証を利用
  • 秘密鍵の管理はちゃんとすること。共用する秘密鍵にパスフレーズがあるかないかはもう気休め程度の問題だと思う。
• これを port forward 用の機械にセットして、他の機械はこの forward 用の機械に接続にいく

例えば今回の目的の一つは rsyncd との間での通信なので

+----------------+
| USER -> PROXY -+-(暗号化)--> SERVER
+----------------+

という繋ぎ方で

rsync rsync://PROXY:PORT/MODULE LOCAL

みたいな使い方を想定。

※ 完全に余談だけど公開鍵認証を使うと authorized_keys で no-port-forwarding を指定することで port forward を禁止するなど、Match を使えないバージョンでもある程度ユーザーの権限の制御ができるし、絶対に公開鍵認証にしておいた方がいいですよ。詳しくは man sshd.

専用のユーザーを作る（クライアント / サーバ）

今回の目的は特定の人間が port forward を利用することではなく、できたトンネルはみんなで利用するものなので、それ用のアカウントを用意してしまった方が設定を分離、集約できて便利。

※ 実際にはサーバ側は後で触れる scponly の chroot_setup.sh でユーザーを作ったので今回は何もしていないんだけど。

クライアント側は普通にユーザーを作って ~/.ssh/ に config, 秘密鍵を置けるようにしておく。クライアント側でユーザーを作るのはこの鍵と設定ファイルの置き場所を作る以上の意味はないと言ってもいいかも。

port forward 用のユーザーの shell を制限する（サーバ）

ssh は Secure Shell であり、基本的には ssh アカウントはシステムの操作を行うために作成するものである。しかし今回の目的は port forward のみ。やはりそれ以外には利用できない状態にしておきたい。LAN 内にこのアカウントを悪用する人がいないとも限らないし、万が一鍵が漏れたらエラいことである*3。しかし remote shell が terminal でアレコレ作業するのを許さない制限 shell であればとりあえずこのアカウントで余計な作業はできなくなる。*4制限 shell として自分が知っているのは

• rssh (本家)
• scponly

で、どちらも chroot に対応している。

rssh は最近あまりブログなどで話題になっているのを見ないが、scponly と違ってあまり場当たり的に機能追加を行わないことでセキュリティを保つことを意識して作られており、また sshd とは別個に rssh.conf によってユーザーごとに細かく設定を調整できる柔軟性を持つ。

scponly は便利な機能を使いたいという要求に次々応えているような印象。scp, sftp だけでなく現在のバージョンは rsync も unison も svn にも対応している。（rsync は rssh でも利用できる。が、いずれにせよ今回 rsync は rsyncd への接続という形を利用するので制限 shell での対応もそのための設定も必要ないけど。）

chroot環境の構築（サーバ）

shell を制限しておいても scp や sftp でシステム全体へアクセスできてしまえば危険なのに変わりはない。そこで chroot 環境に閉じ込める。

今回自分は scponlyc*5 で chroot jail を作成した。これは

付属の chroot_setup.sh が扱いやすい

ということに尽きる。rssh にも source tarball の中には chroot setup 用のスクリプトが付属しているのだが、これだけではどうにもうまくいかない。*6rssh そのもののアップデートが活発でないことから、この辺りの問題をツール側の更新を待って解決に当てるというアプローチの採用は難しく、自分なりに rssh のノウハウを身につけて対処するしかない。ちょっと面倒なのでこれはパス*7。

ただし扱いやすいとは言え chroot_setup.sh も source tarball の中にあるものであり、configure 時に必要なパラメータをセットして作られる sh スクリプトであり、かつ完全に動作する sh スクリプトが全自動でできるとは限らないので注意は必要である。

しかし、それでも rssh のセットアップツールよりは楽。うまく動けばアカウントの作成、ホームディレクトリの作成、必要なバイナリのコピー、permission の設定まで自動で行ってくれる。Linux でも *BSD でもうまく動く。useradd にも pw にも対応しており、passwd データベースの取り回しに気が利いている。rssh はユーザーごとに設定を柔軟に変更したい場合や umask を設定したい場合には便利だが、port forward 目的に制限したいのであれば scponly の方が楽だと思う。

なお、chroot jail を作成したときに /etc/localtime をコピーしておかないとログの時間がずれるのと、FreeBSD では chroot jail の中に /dev/null を作っておかないと動かないのは注意が必要な点。Linux では /dev/null はなくても動いた。

GatewayPorts yes（クライアント）

これは Zebedee と対比させると以下のような設定の意味である。

	Zebedee	ssh
localhostに限定	localsource true	GatewayPorts no（デフォルト）
他のホストも利用可能	localsource false（デフォルト）	GatewayPorts yes

ssh はもともとトンネル用のツールではないので、デフォルトでは実際に ssh の接続を行っているホスト以外からは port forward は利用できない。これを利用できるようにするのが GatewayPorts yes の設定である。

others --(ここの可否)--> ssh client --> ssh server

ssh -N で接続（クライアント）

これは

• OpenSSH は scp, sftp での接続時に自動的に port forward の設定をクリアしてしまうので port forward 目的では ssh クライアントで接続しなければならない。
• shell が rssh の場合は ssh で普通に接続してもすぐに切れてしまう。scponly の場合は WinSCP 互換モードというものがあり、これで session を維持してくれる。が、どちらにしろ tty を解放しないとサービス化できないので、-N は必要。

という理由による。ssh -N の意味は man を読むこと。

ssh_config

というわけでできあがった ssh_config はこんな感じ。以下のような感じのファイルを ~/.ssh/config に置く。

Host PROXY
  Hostname PROXYHOST
  User ACCOUNT FOR PROXY
  GatewayPorts yes
  LocalForward PORT HOST:PORT
  LocalForward PORT HOST:PORT
  LocalForward PORT HOST:PORT

autossh

Zebedee はトンネルを利用した通信の要求が発生したときに初めて Zebedee 自体のコネクションが結ばれる。ssh にはそんな機能がないので*8、autossh を使って繋ぎっぱなしにする。autossh は ssh コマンドを叩き、かつその ssh の接続を監視し、切れたりすると自動的に再起動してくれるもので、ssh でトンネルを掘るという話で調べるとたいてい autossh がセットで出てくる。ということで恐らくこれが標準的に使われているものなのだろう。

この使い方は

autossh -M [port] -f [SSH OPTIONS]

で、例えば

• port forward 用のアカウントが forwarder
• ~forwarder/.ssh/config に設定がある

場合はこんな感じで叩く。

sudo -u forwarder autossh -M 0 -f -F ~forwarder/.ssh/config -N PROXY

ここで

• -M 0 は autossh 自体の監視ポートを消費しないための設定
• -f は autossh をバックグラウンドに回すためのオプション
• -F は ssh の config ファイルを指定するオプション
• -N は上で触れましたね
• `PROXY' の意味は上の config 参照

これでうまく動くなら起動時に動くようにするまでもう一息。Linux だと /etc/init.d/ 以下に template があったりするのでそれを使ってシコシコ書いていく。システムの起動スクリプトに書く場合は

-F ~forwarder/.ssh/config

の記述はフルパスにしておいた方がいいと思う。

補足

サーバに localhost からの接続と思わせる

tunnel サーバと転送先のサーバが同じ場合、サービスを提供しているデーモンから見たときに接続元が localhost として見えるかそうでないかは意外に大事だったりする。例えば外部からの TCP/IP 接続は許していないが、localhost からのみ許可するような場合である。図にするとこういう形。

               +------------------------+
ssh client --> | ssh server --> service |
               +------------------------+

これ、service に localhost からの接続として見せるための設定が Zebedee と ssh で違う。

Zebedee の場合

serverhost xxx.example.com

tunnel III:xxx.example.com:JJ
tunnel MMMM:xxx.example.com:NNNN

という具合に serverhost と tunnel の行の host を合わせておく。

ssh の場合

Hostname xxx.example.com
LocalForward III localhost:JJ
LocalForward MMMM localhost:NNNN

と、転送先を localhost にしておく。

OpenSSH 4.4 以降を使ってさらに安全に

OpenSSH は 4.4 以降で PermitOpen という設定項目が追加されている。これは転送先の制限をするもので、sshd_config 上で

PermitOpen HOST:PORT[ HOST:PORT HOST:PORT ...]

のように指定する。複数書く場合はホワイトスペースで区切って列挙する。`any' と書けばすべての転送が許可される。デフォルトは any.

GatewayPorts のときと同じように Zebedee と比較すると以下のような形だ。

	Zebedee	OpenSSH
パラメータ	target	PermitOpen
デフォルト	すべて禁止	すべて許可*9

Zebedee では target で明示した転送先にしか転送できない。対して OpenSSH の方では AllowTCPForwarding yes で転送そのものを許可してしまえばどこへでも転送可能である。PermitOpen という設定の方が後から登場しているのだから当然なのだけど。

また authorized_keys 上で

permitopen="HOST:PORT[,HOST:PORT,...]" key

と指定しておけばその鍵で認証された接続はここに書かれた転送先にしか繋がらなくなる。つまり、全体の設定と接続ごとの設定を別々にできるのだ。

通常、クライアントはこの PermitOpen で転送先が制限されているかどうかに関係なくサーバに接続し、forward 用の port を開いて listen する。しかし実際にはその port に繋いでも何も起きない。こうした事態を防ぐにはクライアント側で

ExitOnForwardFailure yes

と設定しておく。こうしておくと tunnel が確立されなかった場合に ssh クライアントは異常終了する。

---

注にも書いたけど、PermitOpen と同じく 4.4 以降で登場する Match を利用すると、例えばこの転送用の鍵を特定のネットワークからの接続にしか使えないように制限できるんじゃないかと思っているんだけど、サンプルが全然見つからなくてまだ分かっていません。制限できるなら例えこの鍵は漏れても平気ってことになるんだけど、そういうのは無理なんですかね？

_ Rsync 3 を試す

ネットワーク越しのファイルコピーにおなじみの rsync.

今回、クライアントもサーバも 3 に移行できた組み合わせがあったので試してみた。使ったのはクライアントもサーバも rpmforge の rsync 3.0

単純に軽い

ベンチとかないんですけど、

バージョン	CPU使用率(目測)
rsync 2 同士	20 〜 40 %
rsync 3 同士	1%未満 〜 3%

残念ながらCPU性能も変わっているのでこの数字を出しても比較にならないんだけど、さすがに10倍も性能向上はしていないので、それを差し引いてもやはり CPU 負荷は数分の一以下になっていると見て間違いないと思う。

今までは結構簡単に跳ね上がっていた CPU 使用率が、ほんとに rsync は動いているのか？と疑いたくなるくらいに大人しいまま。これはすごい。

--iconv での文字コード変換

※ 文字コードなのかエンコーディングなのかというのはここでは問わないでください。

rsync --iconv=SOURCE,DEST

という形で文字コードを指定する*1。例えばこんな感じ。

rsync --iconv=utf8,iso88591

と、マニュアルには書いてある。でもこのハイフン抜きの表記って iconv --list には出てこないんだけど大丈夫かなぁと気になったらどうもハイフンはあってもなくてもいいみたい*2。

rsync --iconv=.

でシステムのデフォルトの文字コードを locale から推測する。

変換を無効にするには

rsync --iconv=-

や

rsync --no-iconv

とする。もちろん iconv 関連のオプションを付けないという方法でもいいんだけど、動的にオプションを生成することを考えると --iconv=- がいちばん楽かな。

daemon として動かす場合は module に charset 指定が必要

[MODULE]
  path = /path/to/rsyncd_root
  charset = REMOTE_CHARSET

って感じ。これを指定していない MODULE に対して

rsync --iconv=eucjp,utf8 rsync://HOST/MODULE

みたいに指定するとそんなオプションは許可されてねぇ、と怒られ、転送そのものに失敗する。

charset が指定したものに対して invalid である場合

[sender] cannot convert filename: FILENAME (Invalid or incomplete multibyte or wide character)

このようなエラーが出て該当ファイルの転送に失敗する。

分かりやすく言い換えると、charset の指定に失敗していると

日本語ファイル名のものだけ転送されなくなる

ということ。この動作は恐らく誰も期待していないと思う。

結論として

ファイル名の文字コードが「確実にこれになる」と言い切れない path を rsyncd の対象としている場合、iconv のオプションは利用しない方が無難。

例えば WinSCP で日本語ファイル名を転送する可能性のある領域には Shift JIS(たぶんCP932?) の名前のファイルができる。同じ場所を Netatalk 2 や Samba 3 でマウントしている場合、これらのサービス経由では普通 UTF-8 のファイル名で保存される。つまり、「Shift JIS の名前と UTF-8 の名前が混ざっている」状態になる。

この領域に対して rsyncd.conf で

[MODULES]
  path = /path/to/rsyncd_root
  charset = UTF8

と指定しても、

[MODULES]
  path = /path/to/rsyncd_root
  charset = CP932

と指定しても転送漏れが起きる可能性がある。

余談 - rsync の制限は rsyncd.conf で

いつも自動化している rsync を使ったファイルの転送は remote shell 上で rsync コマンドを叩く

rsync REMOTE LOCAL -e ssh
rsync LOCAL REMOTE -e ssh

という形ではなく、daemon として待機している rsync プロセスに接続する方法

rsync rsync://REMOTE LOCAL
rsync LOCAL rsync://REMOTE

を利用している。これならアクセスできるパスや read only にするなどの制限を簡単に掛けられるし、制限 shell の方の扱いも単純化できるし、rsync を叩く機械と ssh や Zebedee でトンネルを作る機械の分離も簡単にできる。個人的にはバッチ処理で rsync をトンネル越しに動かす場合は rsync --daemon + rsyncd.conf を使った方がいいんじゃないかと思っている。

_ なかったわー

ないわー祭に乗り遅れ、@wiki の使い方を調べるのが面倒だったのでタイトルを正しいものに戻しました。

_ MacBook げと

ちょっと時間が取れるようになったので環境を変えることにした。*1

• PowerBook G4 12" 1GHz*2 + 768MB -> MacBook 13" 2.4GHz + 2GB
• MacOSX 10.3.9 -> 10.5.2

今の機械は中古で買って4年、HDD交換1回、バッテリ交換2回。まぁ頑張ったんじゃないか。

AppleStore なんてない田舎なので量販店で。特にオプションはなし。以下、気づいたこととか。

本体

• でかい。15" じゃなければまぁいいかと思ったけどいざ使い始めるとでかい。画面がでかいのはいいけどモノとしてでかい。
• 質感がよくない。やっぱ Pro の筐体の方が全体的に触っていて気持ちいい。特にキーボードとトラックパッドは確実に落ちる。15" なんて邪魔で使えないと思い込んで我慢しているが意外にストレス。全体的に入力の感度が悪いのかキーの戻りが悪い*3のか、自分の思っている強さ、スピードで普通に入力すると漏れがいくつも出る。
• 上と関係して、細かいことだけど、打鍵時の音が少しうるさい。キーボードユニット自体へ伝わった振動であちこちのキートップから音が発生している。この安物め。
• もうちょっとだけ開いてくれないか。前から感じてるんだが、Mac のノートはもう少しだけ開くと扱いやすいんだよな。
• テカテカ液晶は思ったより悪くないかも。まぁ外で使う機会はほとんどないのでその辺は分からないんだけど、画面の明るさも上がってるし、全体的に見やすくなってるとは思う。
• 速い。さすがにこれだけ性能差があれば当たり前。feed消化がぐっと楽になった。*4
• アダプタはほんの少し変わっている。今回買い替えたいちばんの理由は実は現行機の PowerBook のアダプタの断線なんだけど、断線した部分はほんの少し強度が上がっているようだった。でもやっぱ ThinkPad の方が断然よくできてるね、この辺は。MagSafe はいいんだけど、こういうところに気を配らないのはやはり Apple クオリティか。
• function キーの配置が変わって、頭を使わないと expose できない。慣れるまで時間が掛かりそう。

OSX 10.5

• 全体的にメタル縛りになったっぽくて、少しいかつい印象を覚える。
• Finder のサイドバーがちょっと邪魔くさくなった。検索フォルダ（スマートフォルダ？）は便利なのかなぁ。Thunderbird で使うことはあるけど。
• Ruby 1.8.6, Perl 5.8.8, zsh 4.3.4, screen 4.0.3, Emacs 22.1 ステキ
  • と思ったけど Ruby も PHP も入ってるのに対応する elisp が入ってないのは相変わらずかよ。
• AirMac のインジケータが全然役に立ってない

全体的に Terminal とブラウザ中心の生活なのであんまり変化がよく分からない。Carbon アプリの文字の描画がよくなったって話を読んだ記憶があるんだけど、モニタそのものが違うのでうまく比較できません。

移行

今回は有線で rsync + ssh で今までのデータを転送しておいて*5、一つずつ使うアプリを入れて、Library 以下を必要な分だけ上書きするという方法で。昔からアレコレ試したりして無駄が多いので、最終的にそれを削るため。Mozilla アプリの移行は手慣れたものであっという間。拡張まで一気に復元できるのは楽だよなぁ。

入れたのは Camino, Thunderbird, Firefox, CarbonEmacs, CotEditor, LimeChat, EIJIRO Viewer, Flip4Mac, OmniGraffle*6, Gimp, MacPorts, MacPorts で shttpd*7, lv, nkf, gauche*8 くらいか。VLC とか ffmpeg とか NeoOffice とかはあとでいいや。あ、PixelCat はあった方がいいのか？ Preview で複数の画像をまとめて閲覧できるね。じゃあ要らない。PowerBook バンドルアプリだった GraphicConverter をほぼ写真の回転のためだけに使っていたけど、Preview でできるようになったから問題なし。おっと忘れていた。ClamXav も。

簡単なもんだ。

実はランチャは sh の alias を使っていて Terminal は開きっぱなしなので QuickSilver とか必要なかったりする。新しく使い始めたのは今のところ SpotLight くらいかな？ Panther -> Leopard で結構差のでかい upgrade だと思うんだけど、違和感なく使えるのは OSX のいいところだよなぁ。XP -> Vista でかなり悩んだのとはえらい違いだ。

ハマったのは無線のパスワードをいつの間にか変更していたのを忘れていたことと、X-Chat Aqua を捨てる*9に当たって代わりになる irc client がやっぱりなく、LimeChat に行き着いたがまだ納得できていない辺り*10か。

しかしアレだね。十分速いと思っていた Fastladder はさらに速くなってちょっとした感動。言うなれば時間を金で買ったって感じか。自分の処理能力はそう簡単に速くならないけど、まだまだ削れる時間があった。

_ フレッツ光プレミアムを約束した

NTTの代理店から工事費無料キャンペーンの案内*1がきてたんだけど、まぁ特に損はないかと思ってお願いした。電話の口約束しかない*2のが気持ち悪いが、いざとなったらゴネればいいと考えている。まぁゴネる予定はないけどね。

しかし

案内の際に光にするデメリットを説明しない

のはちょっと感心しないな。まぁこっちは知ってるからいちいち聞かないけどさ。最後の最後お願いしたあとには自発的に説明してくるわけで*3、ちょっとフェアじゃない感じ。

フレッツの良いところ悪いところは一応調べているけど、

さすがにどんな条件が絡んでも 数百kbps しか出ないってことはないだろう

と踏んでいる。うちの ADSL は遅いんだよ。この状態なら光にするのに悩む必要はないよね？

_ Retrospectivaを試してみた

実際に試したのは 4月29日。

Trac に対する不満

Trac からの移行を考えている。なんでかっていうと

• Trac は複数のプロジェクトを扱うことができない
• 1Trac : 1ユーザーDB になるのでプロジェクトが増えるとユーザー管理が面倒くさい

Trac は基本的に認証用のユーザー DB と権限管理のユーザー DB が分離している。デフォルトでは認証は HTTP サーバの BASIC 認証を利用していて、権限を Trac の DB に保存する形。この形のままプロジェクトごとに Trac が増えていくとかなり管理しにくいこと請け合い。

もしかするとリポジトリは1つにすべしという考え方に基づいているのかもしれない。でも自分の経験では適切に分割してある方がやはり扱いやすい。これは皮肉なことに(?)特に Trac を使い始めてから強く感じている。例えば複数のプロジェクトの branch が増えてくると Trac で browse するのも一苦労*1。開発プロジェクトと管理プロジェクトではチケットの設計だってずいぶん違う。

まぁそんな訳で複数のリポジトリ、複数のプロジェクトを一つの ITS で管理できたらいいなと思うようになってきていた。調べると Trac にも複数のプロジェクトを横断的に閲覧することを助けてくれる plugin はある。でもそれは目的と違うんだよなぁ。

ごく大雑把に特徴

というわけで Retrospectiva. ざっと調べたのと軽く動かしてみた印象での特徴は以下のような感じ。

• Ruby on Rails アプリ
• ということは ActiveRecord で扱えるすべての DBMS とともに動く
• 機能的には Trac + WebAdmin + blog
• 独自に認証の機構を持つ
• 複数プロジェクトを管理可能、これらをグループと関連づけて運用する
  • プロジェクトごとに参加メンバーが違うなど

この時点で複数プロジェクトのために複数 Trac を設置して、それぞれバラバラにユーザー管理しなければいけないという事態からは解放される。

インストール

Rails のインストールは省略。今回はFreeBSD上で、すでにOpenFL(Fastladder.org)のために構築してあった Rails 2.0.2 の環境でテスト。

試した時点ではアーカイブのダウンロードという選択肢はなく、svn co する以外にない。ちょっとビジネス寄りの人にはいやがられるかもね。

Rails 2.0.2 では stable 1.0 は動かなかった。trunk(Rev.495) は動いた。

リポジトリとの関連付けは任意

Trac と大きく違うのは、

• リポジトリとプロジェクトは必ずしも結びついていなくてよい
• リポジトリは local だけでなく remote でもよい
  • 試してないけどたぶん*2

つまり、リポジトリを使わないプロジェクト（開発以外）などにも使えるってことだ。これはなかなかいいと思う。メニューのカスタマイズもできるので Browse のメニューは必要なければ消しちゃえばいい*3。開発者と非開発者で同じ Retrospectiva を共有しやすいと思う。

subversion 以外とも連携できるようにということは配慮されているみたいだけど、今のところ subversion しか使えないように見える。*4

migration

trac からの移行用スクリプトはある。どれだけ双方のバージョンに追随しているのかは分からないけど。

「とりあえず見るだけ」ってどうやんの？

「Default」グループに各Viewの権限を、すべてのプロジェクトに対して割り振っておく。これやっておかないと（少なくとも試した rev. では）ログインしないと何にもできない状態になる。Trac に慣れているとここは面食らう。

redMineとの比較

ついでに redMine とも比較してみた。ただし gihyo.jp の記事を読んだだけ。これによると Trac, Retrospectiva に対する特徴としては

• 最近のバージョンはパッケージに Rails 同梱でインストール簡単
  • Rails との互換性の問題などは考える必要がない
• ロールによる権限管理
• ワークフローが定義可能
• Issue ごとに進捗率が設定可能
• svn commit メッセージ連携機能
  • Issue の close を commit だけで完了可能（たぶん Trac なんかでも plugin でできなくはないと思うけど、標準で用意されてるってのが大きいのかな？）
• Wiki, 文書、ニュース
  • ニュースが blog 的なものだとすると文書は？
  • Wiki は履歴が残る
• forum もある

個人的な印象だけど、

なんか全体的にグループウェア的で、Tracクローンとは呼べないと思う。

Trac の経験があるなら移行は Retrospectiva の方が楽。redMine の方がどちらかというと開発者よりもマネージャ寄りの機能が充実しているような気がするけど、それは単に Trac も Retrospectiva もそういうことをあまり考えていないだけかもしれない。

まとめ

いずれにせよ Retrospectiva も redMine も Trac のようには plugin も情報も充実していない。Trac のどこに不足を感じ、これらのどこに魅力を感じるのか考えて決めるべし。

余談 - API ってないの？

贅沢を言えば Retrospectiva を API で操作できればなーって感じ。例えば

Mylyn＆Tracでリズムに乗ってタスクを大掃除♪　(1/4) - @IT

では Trac に XmlRpcPlugin を追加して Eclipse との連携を実現している。こういうのが Retrospectiva にもあれば、eclipse に限らず外部のツールと連携させやすくなる。ブラウザさえあれば管理できるのがこれらのツールのメリットでもあるけれど、やはり HTML 上の UI には限度があると思う。Mozilla アプリの extension でも AIR でもいいけど、扱いやすい外部ツールを用意しやすくする仕組みは大事だよなーと、Twitter を irc クライアントで利用しながらつくづく思うのであった。