カイワレの大冒険 Third

技術的なことや他愛もないことをたまに書いてます

sshで入れなくなっても精神的ダメージを食らわない素敵な方法

トラブルシューティング トラブルシューティング-ssh

sshって制限かけなければどこからでもアクセスできてすごく便利だし、サーバの近くで作業するとホコリやファンの音でうるさいから、よほどの精神力を持った人じゃなければ通常はsshを使って作業をしていると思う。

だけど、iptablesの設定をいじっていて葬ってしまったり、ネットワークの設定いじっていたら急にコマンド受け付けなくなったりすることもその分多かったりする。

しかも仮想コンソールとかなければ遠隔じゃどうしようもないから、現場に行かなきゃいけないわけですよ。

そんな精神的ダメージを避けるためにも、事前に対策しておきましょうぜというお話し。

検証環境

検証環境はこんな感じ。

(192.168.1.3) ---------- (192.168.1.5)
(getty等立ち上げ) (cu, screen, jerm, minicomによるアクセス)

同一ネットワーク内にある2台のサーバ(CentOS5)をシリアルケーブル（クロス）でつなぎ、シリアル経由でログインするということをします。IPは適当につけてます。

方法

まず、接続先である192.168.1.3サーバにおいて、受け入れ用の端末を立ち上げておきます。それによってlisten状態を作り、クライアント側はそこにアクセスすることでシリアル経由の接続が可能となる感じ。
まずinitabを編集する。

192.168.1.3# vi /etc/initab

以下の記述を追加する。

S0:234:respawn:/sbin/agetty -L ttyS0 9600 vt100

意味は、以下のようになる。
名称：ランレベル：ログイン後有効にするかどうか：サーバ側エージェントの指定 -L 通信速度(ボーレートとも言う) デバイス名 エミュレータ
agettyだったり、mingettyだったり色々端末はあるけど、デフォルトで入っているもので十分だと思う。

何十台何百代も管理しているところは各サーバで文字コードや設定が大きく変わることはないと思うし、デフォルトで入っているもので十分だと思うので。

ttyはテレタイプ端末という昔の名残な名前だが、要は入出力用端末。
gettyはttyをgetするためのコマンド
agettyはgettyの簡易プログラムだそうです。ちなみにgettyはfedora7には入ってないです。
mingettyはもっとちっこいプログラムで、コンソール用(キーボードとモニタが入出力装置)としてinittabに登録されてます。
シリアルでアクセスしてきた人にttyS0という入出力装置を渡してあげることで、consoleでの作業ができるようになる、という形です。
引用：http://www.isokiti.tv/~isobetti/sabakan/index.php?e=169

ということで、色々ありますが、使えるものを指定しましょう。
そして、initabを読み込み直します。OSの再起動でも構わないかと。

192.168.1.3# /sbin/telinit q

そして、setserialコマンドが入っているのなら、デバイスの情報を確認する。

192.168.1.3# setserial /dev/ttyS0 –a

最後に、以下のコマンドで受け端末が立ち上げっていることを確認する。設定が書き換わらないようなら、以前に残っている端末プロセスをkillなどして、initabを呼び直す。

192.168.1.3# ps aux | grep getty

接続元の設定

次に接続元の設定です。シリアル経由で入る場合、多くはUSB切替器を用いてwindowsマシンから接続することが多いかもしれない。その場合はteratermなどを用いると思うんだけど、今回はlinuxから入ることにするので、ちょっといくつか手を打ちます。

現在使用しているCentOS5系で調べる限り、特にインストールを必要としなかったのはminicomのみ。screenやcuはyumで入れる必要があるし、jermもソースから入れる必要があったけど、とりあえず、何か入れてそれを使って接続します。

minicomの場合

minicomの場合は、以下のコマンドで設定を行う。

192.168.1.5#minicom –s

このコマンドを実行すると設定画面が現れるので、"Serial port
setup"を選択して[Enter]キーを押します。デバイス名やボーレートなどを接続先に合わせて設定し、保存してminicomを出る。
そして、以下のコマンドを実行する。

192.168.1.5#minicom

これで、接続先(192.168.1.3)のログイン画面が出れば大丈夫。

jermの場合

次にjermの例を示す。jermの場合はIndex of /jermからソースをダウンロードする。

展開後、インストールを行うとjermコマンドがあるので、それを用いる。

オプションは複数あるけど、使っていて特に支障がなければ単にデバイス名を指定するだけで問題ない。以下にある2番目の例は行末のコードを変換する例であり、３番目はデバイスのオプションを指定する例である。

192.168.1.5$ jerm /dev/ttyS0
192.168.1.5$ jerm -r tnrn /dev/ttyS0
192.168.1.5$ ./jerm -b 9600 -p none -d 8 -s 1 -f none /dev/ttyS0

これらのコマンドで接続先のログイン画面が出たら大丈夫。

cuの場合

cuの場合は、デフォルトで入っていないので、yumで入れる。uucpというパッケージのなかに入っているので、「# yum install uucp」で入れましょう。

> 192.168.1.5$cu -l /dev/ttyS0

これでログイン画面がでれば大丈夫。

screenの場合

scrrenは非常にシンプルで、仮想端末として立ち上げて、さらにログも残すことができるのでオススメだったりする。エンジニアだったら使ってる人多いだろうし。ただ、cuと同じでデフォルトでは入ってないと思うので、yumで入れておきましょう。んで、以下のコマンドで仮想端末を立ち上げる。

192.168.1.5$ screen

ログの残し方は色々書かれているので、そちらに譲るとして、
基本的には、「.screenrc」に作業ログを残す設定を書けばよい。
そして、screenで新端末を立ち上げた上で、シリアル経由で接続先にアクセスする。

> 192.168.1.5$ screen /dev/ttyS0 9600

これで接続出来れば大丈夫である。

終わりに

ログを残すという意味でscreenはすごく大事だし、デバッグという意味でも推奨すべきものだと思う。しかしながら使い慣れてないと、デタッチできずそのままプロセスが残って、端末がbusy状態になってしまい、新しくウィンドウが開かなかったりするので、そこは注意すべき点かも。接続元がネットワークに繋がらない環境にいるときなどはminicomでアクセスするのが現時点ではよいように思うかな。

とりあえず、ssh以外の接続方法も覚えておくと精神的に楽だよ！ということを主張してみる。