シリアルポートを使うには? [2000.8]

ワークステーションやパソコンのシリアルポートはいまも RS-232-C 規格で使用できる.1969年発表だからずいぶん長命だ.最新のギガレベルのルータやスイッチにも最大200Kbit/秒のこのインタフェースが装備されているのは,ルータに最初の IP アドレスを与えるといった最小限の設定,障害でネットワークでの接続ができないときの保守,といった最後の手段が必要だからだ. UNIX では,シリアルを,外からログインする端末やモデムを接続する場合と,シリアルポートに接続した機器,例えばモデム,無停電電源装置 (UPS) やビデオデッキを制御する場合,の二方向の使い方がある.

外部からログインする設定は,伝統的 UNIX では /etc/ttys といったファイルにログイン許可の設定を書いて,kill -1 1 (プロセス番号1番は常に init プロセスだ) とする.これで init がポートごとにログインを受け持つプロセスを用意してくれる.ビットマップコンソールを備えていないサーバ機などで使われる.モデムを接続しておけば遠隔保守も可能となる.

内側から使うには古いものでは,cu (Call Unix),BSD になってからの tip (Terminal Interface Program) といったコマンドでシリアルポートに接続した機器に接続できる.cu や tip はモデムを制御して遠隔のマシンにログインする使用法を想定したコマンドで,電話番号を引数に与えることができるが,この機能は今はあまり使われない.使うときには,回線スピード,パリティ設定を正しく設定しよう.9600bps, 8ビットパリティ無し,が最近の標準設定だ.設定を確かめるには,cu/tip を動かしているのと別にログインして root になって

stty -a < /dev/ttya

のように打ってみよう.端末に関係する詳細な設定が表示される.baud は速度,cs8 (character size) が見えれば8ビット通信だ.cu/tip 以外にシリアルポート経由のファイル転送を目的とした kermit (KL-10 Error Free Reciprocal Micro Interconnect over TTY lines) も便利だ.もちろんファイル転送だけでなく tip のようにも使える.UNIX の標準には備わっていないが,メインフレームからパソコンまで非常に多くの機種に移植されているので,操作法を覚えておいて損はない.


プログラムソースを読むと参考になりますか? [2000.10]

プログラミング能力を高めるのにソースを読むのは大変に参考になる.例えば,自分の知らなかったプログラムのスタイルが見えるし,UNIX のプログラム上の約束事を知るのにもよい.ここでは,言語は C としよう.プログラムのスタイルとは,データ構造やアルゴリズムを C で表現するときの,自分なりのお決まりのパターン,といった意味である.ごく簡単な例では,配列の先頭の10個を操作するときの for 文なら

for (i=0; i<10; i++) { … } と書き,決して

for (i=0; i<=9; i++) { … } とは書かない

と決めればそれがスタイルである.どちらも正しいし,動作も同じだが,それでもスタイルを守れば間違いが減る.古典なら「プログラム書法」最近なら「The Practice of Programming」の本も参考になる. スタイルの点でソースを読むなら,こんなところに注意してみよう.ユーザに優しいエラーメッセージ,名前の付け方,-Wall に耐える cast の方法,いざというときの goto 文の使い方,malloc と free の組合せ,利用者入力の解析手法,ヘッダファイルのまとめ方,ファイルの分け方,関数の分け方,など. 関数は30行から40行が良いスタイルと主張するものがあるが,何がなんでもこの行数にするのはおかしい.機能を吟味して,本質的に大きなものには行数を使おう.1988年頃の BSD UNIX のカーネル内の C 関数 tcp_input は約1,000行あった.FreeBSD4の tcp_input はひとつの関数で2,000行ある.これはちょっと大きすぎるかもしれない.

プログラムは言語だけでは書けない. OS とのやりとり,ライブラリの使い方,GUI であれば,ツールキットとのインタフェースなど,約束事がある.ライブラリの使い方などは,ソースを読めば非常に参考になる.UNIX での約束事といえば,関数 main での引数文字列の受け取り方,exit status の返し方,stdout, stderr の使い分け,といった基本的なことから,ファイルロックの方法,ネットワーク通信,tty の扱い,などに進めばよいだろう.

プログラムではないが,Makefile の書き方も人のものを見ると便利な機能が発見できたりする.注意して読んで目から鱗が落ちる体験をたくさんしてほしい.


ネットワークを監視したいのですが? [2000.11]

まず,ネットワーク機器を監視する,ネットワークを流れているデータを監視する,の二つがある.機器監視の手法は規格になっている SNMP/RMON がまずあげられる.これを備えているルータやスイッチについては,機器の設定や状況を見ることはもちろん,インタフェースのアップダウン,コンフィギュレーションの変更があったときなどに設定したホストに通知 (trap) が送られる.単に機器がダウンしていないかを監視するのには,定期的に ping を送るのが簡単で,しかもかなり実用的だ. ping の応答がないときに携帯電話にメールを送る,といったことはシェルスクリプトでも簡単に実現できる.

データ監視には,流量監視とパケット内容そのものの監視がある.前述の SNMP でインタフェースごとにパケット数,オクテット (バイト) 数が入出別に得られる.MRTG は定期的に SNMP でこのデータを取得してグラフにして HTML にしてくれるソフトウェアで,流量の変化や時間的傾向を見るのに大変便利である.サーバのサービスごとの流量を見るには,IP ファイアウォール機能 (ipfw など) を使おう.サービス (ポート番号) ごとに許可のルールを作れば流量カウントが得られる.社内サーバなどでパケットのフィルタの必要はなくても流量カウントに使えるわけだ.この出力を SNMP 経由で得られるようにすれば MRTG でグラフにもなる.

パケット監視は,ネットを流れるすべてのパケットを取り込んで,ヘッダや場合によっては送られている利用者データそのものを見ることになる.専用のネットワークアナライザに加えて etherfind, tcpdump , ethereal といったソフトウェアでも見えるようになってきた.パケット送出の間隔,TCP/IP 以外のプロトコルのパケットの様子,ネットワークプログラムのデバッグなどに効果的だ.クラッカーの手口を探るのにも欠かせない.だが,利用者データには,telnet/ftp のログインパスワードなど個人情報がそのまま含まれている.ノートパソコンにソフトをいれれば,誰でも見られる時代なので,通信の暗号化や,基本的には他の通信が見えないインテリジェントスイッチの導入が必要だ.


コマンドラインインタフェースは面倒ですね…!? [2001.1]

一時期の Macintosh コンピュータは,本体を購入するとマウスは付属していたが,キーボードは別売だった.確かに,キーボードが無いとハイスコアに自分の名前をいれるのに不便なくらいだが,マウスが無いと本当に何もできない.今の UNIX マシンも,デスクトップにブラウザが上がっているだけなのをよく見かける.確かに,机上を模倣したデスクトップは直観的で多くの人が特に学習をしなくても使うことができる.いわゆるグラフィカルユーザインタフェース (GUI) の大きな利点だ.だが,マシン本来の計算,蓄積,繰り返しの能力は机の模倣だけでは活かされない.お絵書きツールを使っても誰もがうまい絵が描けるようになるわけではない.当然だ.だが,せっかくツールを使っているのだから,楕円の焦点を通る線分を描くとか,正6角形を30個すきまなく並べる,といった正確性を要求されるが退屈な仕事は計算機にやらせよう.円の内側に線分が飛び出しているような絵なら,計算機で描くこともない.

GUI の欠点は人間が操作しなければいけないことだ.共通の項目をマウスでひとつひとつクリックしていくのは,機械に使われているとしか言いようがない.コマンドラインインタフェース (CLI) は,自動化,繰り返し,再利用といった機械的作業を機械にやらせるのに使う.GUI が得意そうに思える画像の変換でも,例えば,jpeg の絵を2倍に拡大してスムース処理するという処理なら,PBM (Portable Bitmap ファイル形式) を扱う一連のプログラム netpbmjpeg のユーティリティ を使って,

djpeg -pnm < in.jpg | pnmenlarge 2 | pnmsmooth | cjpeg > out.jpg

とする.画像がたくさんあるのなら,この行を並べたファイルを作ろう.行が多くなってきたら,繰り返しに変更しよう.jpeg 以外の画像も扱いたいなら,条件判定をいれよう.そう,これはプログラムを書いていることに他ならない.

GUI やブラウザの出現で計算機の利用が大きく広がった.これ以上計算機に使われたくない人は,メニューの奥の端末ツールをひっぱり出して,CLI を使い,そしてプログラムを書こう.


リブートは必要ですか? [2001.2]

UNIX マシンは,リブートが必要となる場面がとても少ない.OS そのものが安定していること,プロセスの独立性が高いことが主な理由だ.最近,身の回りの UNIX マシンをリブートしたのは,CPU を交換した,メモリを追加したなどで電源を切断したとき,それから,UNIX kernel そのもののバージョンアップをしたときぐらいだ.普段持ち歩いている UNIX いりノートパソコンも,サスペンドは繰り返すが,数ケ月はログインしたままだ.

ディスク増設もホットスワップデバイスであれば電源切断はいらないし,SCSI なら,rescan を実行して接続したデバイスを認識させることができる. 無停止性と,かなりのスケーラビリティがもともと備わっているのだ.IP アドレスの変更程度でリブートが必要になるソフトウェアシステムは,構成要素が互いに入り組んでいて,ほんの一部を変更したときも,全体の整合性をとり直すため簡便な手段としてリブートさせるのであろう.具合が悪くなったら電源の切り / 入りをする安っぽい電気製品のようだ.

UNIX では,プロセスに HUP シグナルを送ることで,そのプロセスの設定ファイルを読み直し,設定が変更されるという慣例がある.UNIX Version 5 の init (pid = 1) には HUP シグナルを受けて /etc/ttys を読み直すコードが含まれているから,歴史は長い.端末管理やログインといった OS に近い仕事を,ユーザ空間で走る普通のプロセスでまかなうので,リブートせずとも,HUP シグナルかせいぜいプロセスの立ち上げ直しでシステム調節ができるのだ.ファイルをちょっと修正したくらいでリブートするのはやめてほしい.

sendmail はずいぶん長いあいだ HUP での設定ファイルの読み直しができなかった.最近のものは HUP を受けつけるが,HUP によって,別プロセスが再起動する.UNIX の中では珍しいといえる.

さて,1969年5月号,bit 創刊第3号 にはじまった連載「bit 単語帖」の後をうけ,1993年1月号にスタートしたこの FAQ も bit の休刊とともに停止状態となる.これが,リブートコマンドを打たれて,新たに立ち上がるまでのつかの間のブラックアウトと信じる.33年間の無停止運転は,その洗練された内容と,読者の期待,支持で成り立っていたのだから.


 タイトル一覧  ホーム
webmaster