|
|
2005/05/21 改訂
以下は一般的な解説というよりも、筆者が遭遇したトラブルを解説している。同じような現象でもトラブルの原因は多数あるので、この記事は単なるヒントと見なすべきである。
また各記事には日付が書かれている。古い記事(1年を経過した記事)は全く参考にならない可能性があるので気をつけて欲しい。
2005/05/08
筆者はシステムの変更、特にファイルサーバの変更は長期の休みの期間中にしかやれない。正しく言えばやる気になれない。なぜなら筆者のシステムは教育に使用され、筆者以外にも利用者が何人かいるからである。これが講義期間中にトラブったら大事である。
さて今年の2月初旬にシステムを更新した。この時は大変であった。システムが1日しかもたないのである。仕方がないのでファイルサーバのカーネルを古いものに戻して、それでも不安定なので、徹底的にチェックした。その結果ファイルサーバを運用する時の鉄則を忘れていた事に気がついた。
fossil は良くできたファイルサーバである。そのためかファイルサーバが立ち上がる時に UNIX のように fschk をやらない。それだけの信頼性を持っているとの自負があるのだろうか? しかし筆者のシステムは Bell-lab のように恵まれてはいない。突然の電源のオフも発生する。
全てのファイルを総なめにチェックして行くと、いくつかのファイルに不具合が発生していた。例えば内容が消えていたとか、ls では見えるのに実際には存在しないとか、と言った具合である。そうしたファイルのいくつかがシステムサービスに使用されていた。これらを完全に復旧して現在に至っている。現在はファイルサーバに関しては安定している。3ヶ月間近く、トラブルなしのノンストップで運転し続けている。
どんなに良くできたファイルサーバでも、「完全」はありえない。ファイルサーバが不正常な終了をした場合に、サービスを開始する前に、ファイルシステムを完全にチェックすべきであろう。またチェックを可能にするデザインが望まれる。問題のあるファイルを空のファイルにするよりも open エラーにしてくれた方が有り難いのである。
当時の不安定の主たる原因は、ファイルサーバがアーカイブをとる時とスナップショットをとる時にファイルシステムをロックしていたからではないかと思う。実際、当時の fossil はロックしていた気配はあった。ロックしている最中にもアクセスは発生するので、それらが溜まることになり、サーバが保たなくなる。現在の fossil はロックしていない。少なくともロックされている事を感じさせない。あるいはロック時間を微小にする工夫が凝らされたのかもしれない。
2005/05/08
最近どうしたわけか突然CPUサーバのコンソールがプロンプトを表示しなくなった。rc が動いている事はコマンドを受け付ける事から分かる。カーネルを古いバージョンに戻すと表示する。バイナリで配布されているカーネル(9pccpu)のバグだと思う。
このカーネルは会話モードで rc を起動していない。CPU サーバのコンソールで
ps -a とやればその事が分かる。
コンソールで
rc -i を一回実行する。
cpurc をいじる方法もあるが、このバグはそのうち修正されるだろうから、いじらない方が良いと思う。
2005/05/09 改訂
2005/05/08
CPU サーバのブート時に
単に改行を与えれば先に進むが自動ブートはできない。
root is from (tcp, il)[tcp]: secstorefetch: password mistyped? Enter an empty password to quit. secstore password: version...time...
認証サーバの secstore は正しく働いている。この事は
auth/factotum -g factotum を実行してみれば分かる。
今回の問題は2つが重なっていた。
第1の現象(secstorefetch)は古い nvram が使用されていたこと
第2の現象は(secstore password)は plan9.ini を書き換えた時に auth=... の項を入れ忘れた事
P:! hera# auth/wrkey authid: bootes authdom: aichi-u.ac.jp secstore key: password: hera#
auth=202.250.160.71 2005/05/08
最近 CPU サーバが長持ちしない。一週間程度でリブートされる。(昨年の秋には何ヶ月もリブート無しに続いたと思うが...)
不明。
reboot(8) によればファイルサーバとの接続が途切れた場合の対策として
aux/reboot が準備されているが、何故こんなによく途切れるか筆者には分からない。
不明。
2005/05/08
Plan 9 端末で telnet サービスを行っているにも関わらず、telnet で Plan 9 端末にアクセスできない。
hera# telnet -r al connected to tcp!al!telnet on /net/tcp/29 user: arisawa authentication failure:needkey dom? proto=p9sk1 user? hera#
つまり challenge が出ない。
様々な原因が考えられるが、今回の原因は Plan 9 端末の hostowner の secstore キーが使用停止になっていた。つまり
term% cat /mnt/factotum/ctl
... disabled=by.factotum ... となっていたことが原因である。これは Plan 9 端末から他のホストにアクセスする際に、正しくないパスワートを入れた、あるいは認証サーバの認証サービスが停止している時にパスワードを入れた時に起こるはずである。
2005/05/18
Plan 9 端末(9pc 9pcf) にtelnet や rx では入る事ができるが、 cpu コマンドでアクセスすると拒否され、そして端末の画面が乱れる。
これまで、端末への cpu コマンドはサポートされていないのかと思っていたが...
/rc/bin/service/tcp17010 が古かった
2005/05/21
Plan 9 端末の factotum は通常
al% cat /mnt/factotum/ctl key proto=p9sk1 dom=aichi-u.ac.jp user=arisawa !password? al%
筆者の Plan 9 端末 al の factotum
のようなものである。これが、al でコマンドを実行する事なく
al% cat /mnt/factotum/ctl key proto=p9sk1 dom=aichi-u.ac.jp user=arisawa disabled=by.factotum !password? al%
となる。例えば alice がシステムのユーザであれば
# term is terminal in my home term% cat /mnt/factotum/ctl key proto=p9sk1 dom=aichi-u.ac.jp user=alice !password? term%
の下で
term% cpu -h al -u alice cpu: waiting for FS: : term%
これは明らかに factotum のバグである。
2005/05/21
具体的には
term% cat /mnt/factotum/ctl key proto=p9sk1 dom=outside.plan9.bell-labs.com user=arisawa !password?
つまり端末側の factotum には outside.plan9.bell-labs.com のアカウントだけを登録して
term% cpu -h hera hera% echo $sysname hera hera% echo $user arisawa hera% cat /mnt/factotum/ctl hera%
筆者のサーバ hera (ファイルサーバ+認証サーバ)へのログインにまんまと成功した。
hera の bootes の factotum に outside.plan9.bell-labs.com のアカウントが登録されている。そして、これが "role=client" に設定されていない。
システムファイルの更新を行えば hera の bootes の factotum に outside.plan9.bell-labs.com のアカウントが自然に登録される。これには role が指定されていないので "role=client" を指定しておく。
サーバにアクセスした時に factotum はキーを自動登録するが、現在の仕様では role が指定されない。"role=client" の下に自動登録されるべきであろう。