今日のネタではないのだが、落ち着いたので。 シリアルコンソールって何じゃらほいって人は最後の方へ。
遠隔地で完全な操作ができないシステムはサーバとしてはうんこだ。 CPUやマザーボード、電源がイカれたとかいう深刻なハードウェアトラブルなら しゃーないが、ファイルシステム関係のオペミスなんかでハングしたときに リセットボタンを押しに行かなきゃならんようでは安心してサーバ運用できない。
という意味で、やっぱりSunなんかのワークステーションは基本的に シリアルデバイス(RS-232Cって書かないと最近はシリアルATAだと思われるらし い)で全てのBIOS関連操作ができるのでハードウェアが壊れない限り、 全ての操作を遠隔地からできて偉いのだ。Intelアーキテクチャの「ぱそこん」 では、*BSDの機能としてシリアルコンソールは使えるものの、BIOSにアクセスす る手段がない(つまりリセットボタンを押せることに相当するほど強力でない) のでどっちかっちゅーと「ついてるだけまし」的な印象を持ってい たのだが、最近立て続けにシリアルコンソールに助けられたことを受けて、 実質的に「カーネルデバッガに下りられるシリアルコンソール」なら問題ないん ちゃうか、と思えるようになったのでちょっと啓蒙する立場に移行してみよか と考えるようになったのだ。
広い意味でいうと、COMポートにぶら下がった端末からアクセスできるように することなのだが、細かく分けると
の3段階になる。「遠隔サーバ管理」という目的では2と3ができなければ意 味がない。1は重要そうに見えて、じつはSSHログインができなくなっちゃったよ うな状態なら1すらもできないことが多いので、1の設定はしてもあまり役に立つ 機会がないのだ。ということで2と3の方法について述べる。
i386-PCの場合、RS-232Cは9ピン(オス)になっている。 サーバマシンと端末マシンのRS-232Cをクロスケーブルで繋ぐ。家電量販店なん かじゃ9ピンメス同士のクロスケーブルなんて売ってやしない。9←→25ピンの 変換アダプタなんかを組み合わせて買うべし。もしくはぷらっとほーむで 買うべし。
(2006/3/29 追記)いやいや、千石電商とかで通販で買う方が もっとずっと安いですぜ。
FreeBSDは4がよかたねえ。ド安定、1年でも2年でも平気で稼動してそうな 感じ。5はどうも怪しい気がする。ってな気がしてダメ元でFreeBSD5をシリアル コンソール化したのがきっかけだった。大体ハングするときは、ファイルシステ ムまわりで刺さってることが多いので、カーネルデバッガにはちゃんと下りられ ることがほとんどなのだ。そうでなければ、そもそも安心して使えない。
はい、手順。ちうても ハンドブック を見れば全て分かるじゃろ。というかそこ見れ。なに、めんどいとな。じゃ かいつまんで。
→ /boot.config に -h または、-hD オプションを書い
ておく。これでブートメニューに出てくるデーモン君ASCIIアートなんか
がシリアル回線に流れて来る。
カーネルを作り直す必要がある。configファイルに以下のオプション を追加する。
options BREAK_TO_DEBUGGER options DDB
ついでだが、PANICしてもカーネルデバッガに下りずリブートしちゃえ ってときは
options KDB_UNATTENDED
も追加しておくとよい。
これも、manページの boot_cosole(8) みれば一発。 なんだが、ついgoogleに頼ると古い情報に翻弄されることになるので 手短にNetBSD3のやり方をば(これもそのうち古い情報になるんだな)。
NetBSD3のブートプログラムではコンソールデバイスをオプションで 選べるので、ブートプログラムをコンパイルし直す必要はない。 例えば wd0 がブートデバイスならこんな感じ。
# cp /usr/mdec/boot /boot # installboot -v -o console=com0kbd \ /dev/rwd0a /usr/mdec/bootxx_ffsv1
console= の右辺に与えるキーワードについては installboot(8) 参照のこと。
デフォルトではコンソールデバイスがシリアル回線なら、 そこにブレーク信号が来たときに自動的にデバッガに入る。 ので設定不要。
FreeBSDの場合と同様のついで、PANICしたときにデバッガに下りず
即リブートがかかるようにするにはsysctl変数ddb.onpanicを0にしておく。
つまり/etc/sysctl.confに以下を追加。
ddb.onpanic=0
「シリアルの先にぶら下がった端末」は、おそらく別のBSDマシンなんかを 使うはず。なので、tipでアクセスできるようにする設定。っつっても デフォルトの9600bpsでいいならちょ簡単。
/etc/remote の末尾に以下のようなデフォルト値があるはず。
【FreeBSDの場合】 sio0|com1:dv=/dev/cuaa0:br#9600:pa=none: 【NetBSDの場合】 dty0c|dty0:dv=/dev/dty00:br#9600:pa=none:dc:
要はCOM1のデバイスを9600bps、パリティなし、でアクセスする設定の エントリがあればこれを利用する。ただし、FreeBSDの場合も、NetBSDの エントリのようにdc(direct connection)は追加しておいた方が良い(2005/1/11 加筆)。続いてクロスのシリアルケーブルで親子を繋いだのち
【FreeBSDの場合】 # tip com1 【NetBSDの場合】 # tip dty0c
などとすればよいだけ。サーバマシンをリブートしてブートメニューなんか が端末側に流れて来ればOK。リターンを押してから ~# を タイプするとブレーク信号が送られる(tipの場合)。それで カーネルデバッガに下りられればもう、遠隔であぶない操作しまく り、きゃー。デバッガから復帰するには「c リターン」でよろし(FreeBSD、 NetBSDとも)。実際に遠隔値からシングルユーザモードに落としたり、OSアップ グレードしたり、ファイルシステムの危険な操作をしたり間違えたりしてハング させたりしてみよう。ハングしていても、シリアルコンソールを繋げたマシンか らブレーク信号を送っちゃえばほぼ確実にデバッガに入れるだろう。
端末とする機械がパソコンだとしたら、いっぺんそいつをリブートしてみよ う。もしかしたらリブートしたり、RS-232Cを初期化するタイミングでブレーク 信号を送っちゃったりすることがあるそうな。
もいっこ、端末とする機械はサーバマシンがハングしても独立して 動くようにしていないと意味がない。サーバマシンを落とした状態で 外部から端末側ホストにログインできるか確かめておこう。
Unixマシンの操作はどこで行なう? キーボード? kterm? SSHで? どれも正解だがどれも不正解。基本的に操作を受け付け、メッセージ出力を 吐き出す場所は「コンソール」と決められている。普通はキーボードとディスプ レイ。が、シリアル回線もコンソールになり得る。何がうれしいか。昔は キーボード・ディスプレイを繋げないものが主流だった。というか、 いまでもラックマウントして10台20台とか設置するものにいちいちディスプレイ なんか繋げてられん。さらには、シリアル回線で繋げて端末としているマシンに 遠隔地からログインできれば、サーバマシンをシングルユーザモードに落とした りする作業がどこからでもできる。本来ワークステーションであればBIOS操作も シリアル回線から行なえるように設計されているので、BIOSの設定やらリセット コマンドなんかも別のマシンから操作できる。
残念ながら「ぱそこん」はそんな風には設計されていないので、BIOS操作は できない(BIOS画面をシリアルに流せる機械もあるが10万円以上!)。けれども、 *BSDの場合カーネルデバッガがすぐに使えて、シリアルコンソールからも入れる ようになっているので遠隔地からリセット操作くらいはできる。リセット操作な んてのはハングっちゃったりした「最悪の自体」の場合に役に立つので「不安定 なこと自体がない方がいい」って話でもあるのだが、そうでなくてもシングルユー ザモードに落とす処理を遠隔から行なえるのでOSのバージョンアップ的な コアな作業を出先からできる。てことで安心して帰省できる。
サーバの他にもう一台Unixマシンを用意し、それ一台だけでネットに繋がる ように設定する。これを端末機とする。次に、ルータの特定のポートを端末 機のSSHポートにフォワードして、外からも端末機にログインできるようにする。 端末機とサーバをクロスのシリアルケーブルで繋ぐ。端末機ではroot以外は tipを使えないようにする(重要、デフォルトはそうなってるはず)。
と、ここまで設定してから最初の方に書いた、サーバのシリアルコンソール 化の設定をする。おしまい。
叱咤激励感想ツッコミはゲストブックへ
Generated with mkdiary.rb
Fingerprint16 = FF F9 FF CC E0 FE 5C F7 19 97 28 24 EC 5D 39 BA