今朝、大学の僕のサーバー(ar)を自宅の Plan 9 端末(pc)にマウントしようと思ったら思わぬトラブルが発生した。
term% 9fs ar post... mounting as arisawa /bin/mount: mount /n/ar: EOF receiving fversion replycpu コマンドでの接続は?
term% cpu cpu: negotiating authentication method: ar: rejected R term%つまりこれもダメ。しかし僕のサーバーは確かに動いているのだ。
今回と良く似た現象は数年前に経験した事がある。それは Plan 9 システムの通信プロトコルが 9p2000 に変わった時期で、UNIX に u9fs を使ってマウントしようとした時に、バージョンのミスマッチが発生して fversion メッセージが出た(注1)。
しかし今回は原因が思いつかない。ar と pc との接続は昨夜まで問題がなかったのだ。昨夜から今朝までに発生したシステム上の変化は、僕の pc の電源が切られたことぐらいだ。何が起こったのだろう?
原因を探るために MacBook から接続を試みた。ar も pc も OK. ちなみに pc は Plan 9 端末であるが、サーバー的な編成を行っている。また pc へ接続する場合の認証は、大学の Plan 9 の認証サーバーには依拠していない。どうやら pc が ar に接続する時に認証が巧く行っていないらしい。
思い出して来た。多分原因は factotum だ。今回のトラブルは CPU サーバーに接続して、その中で、cpu コマンドで認証サーバに接続しようとして、パスワードを入れた後発生したのだ。これと同じ現象は前にも発生した。この時には factotum が問題を引き起こしていたのだ。factotum の disabled は魔物だ。認証のような重要な部分に「自動的判断」は禁物なのだ。関連ページ
僕のサーバーは、ファイルサーバーを通じて CPU サーバーをリセットできるように作られている。リセットで問題は解決した。