1. mkdir システムコールを実行する。 2. ティレクトリの存在を確認する。 ( a ) ディレクトリがある場合にはエラーとなる。 (b) ディレクトリがない場合には作成する。 重要なのは、ディレクトリの存在を調べるのと実際に ディレクトリを作成する処理を、 mkdir システムコール 1 つで実現できることです。ちなみに、ディレクトリが 通常のファイルやシンポリック・リンクとして作成され ていても、 mkdir コマンドはエラーとなります。 ディレクトリの存在の確認と作成が別のシステムコー ルで実現されるならば、確認したときには目的のディレ クトリがなかったが、作成する際にはあったという状況 も考えられます。しかし、この 2 つの処理が 1 つのシ ステムコールで実現されているので、これらの処理にほ かのプロセスの処理が入り込むことはありません。した がって、 mkdir コマンドを使えは安全にロック機構を 実現できるのです。具イ勺には、ロック機構が必要なす べてのプログラムでロック用のディレクトリを決めてお き、そのディレクトリを作成できた場合にかぎり処理を if mkdir $LOCK 2>/dev/nu11 ; then FILE=/tmp/testdata LOCK=/tmp/10ck. dir # ! /bin/sh 続けられるようにします。たとえば、 vi $FILE rmdir $LOCK echo "file is locked" else f i exit 0 1 > & 2 というスクリプトを使っていれば、誰かがファイル /tmp/testdata を編集している最中にほかのユーサー は編集できません。このようにロック欟冓に使用できる ものとしては、 ln コマンドなどが挙げられます。シェ ル・スクリプトのなかでロック機構が必要になった場合 に利用するとよいでしよう。 rmdir コマンドも、 rmdir システムコーノレという 同し名前のシステムコールを用いて実現されています。 rmdir コマンドは、 rmdir ディレクトリ という形式で使います。 rmdir コマンドで削除できる のは、なかに何もないディレクトリだけです。、、なかに UNIX MAGAZINE 1994.12 LJN Ⅸ流プログラミング 50 何もない " というのは、 ls -a コマンドを実行したとき と、 .. " 以外の出力がないことを意味します。 rmdir システムコーノレは、 rmdir()€ス名 ) という形式で使用し、パス名に指定したディレクトリを 削除します。ただし、ディレクトリを削除するには、ル ートディレクトリからそのディレクトリへのパスに検索 の許可が、親ディレクトリに書込みの許可がそれぞれ出 ていることが必要です。これは rmdir コマンドの場合 と同様です。また、ルートディレクトリとカレントディ レクトリの削除はできません。 sync あまり一般ューザーが使うものではありませんが、メ モリ内凵尉寺されているディスクの情報をディスクに書 き出す sync コマンドか準備されています。普通は、メ モリ上に保存されている情報は定期的にディスクに書き 出されるので、このコマンドを使う必要はありません。 一般ューザーでも実行できるコマンドですが、実際には マシンを停止するときやトラブルか起こったときなどに 管理者が使用します。 この sync コマンドを実現しているのが、 sync シス テムコールです。 sync システムコールには引数はあり ません。このシステムコールを実行すると、情報がディ スクに書き出されます。ディスクの情報をメモリ内の情 報と合わせる必要がある fsck コマンドや df コマンドで は、このシステムコールが必要となります。 reboot reboot コマンドはシステム管理者が使用するコマン ドで、システムを停止して再起動するものです。もちろ ん、一般のユーザーはこのコマンドを実行できません。 このコマンドを実現しているのが、 reboot システムコ ールです。これは、 て eboot ( 実行方法 , プート時の引数 ) という形式で使用します。 167 ・システムの停止のみをおこなう ・システムの再起動をおこなう 実行ガ去としては、

連載 / 転ばぬ先のセキュリティー① 例として、 SunOS 4.1. x にインストールしてみます。 私は、 Makefi1e . WIDE. sun を選びました。 Makefile を 修正する前に、安全のためコピーをとっておきましよう。 % cp Makefi1e. WIDE. Sun Makefi1e. WIDE. Sun-dist Makefile の修正で漢隹しいのは、データベースとネーム サーバーに関する設定です。 UNIX に付属するデータベースとしては、旧いデー タベースである dbm 、 dbm の下位関数である ndbm 、 BSD の新しいデータベースである db があります。 Send- mail の Makefile では、マクロ NDBM が ndbm 、マクロ NEWDB が db を意味します。 db は SunOS 4.1. x では 提供されていないので、マクロ NEWDB を外す必要があり ます。 BSD/386 1.1 では db 1.73 カ甘是供されています。 Sun で db を使いたい場合は、最新の 1.79 を入手して ください。 db. 1.79 をキーにして、 archie などて験索す るとよいでしよう。 db をインストールしていない場合は /usr/lib/libdb. * がありませんから、マクロ LIBS か ら -ldb を除去します。 ネームサ→ヾーのライプラリには、 ・ SunOS 4.1. x イ寸属のリゾノレヾ /usr/lib/libresolv . a ・ BIND 4.9.2 ( bind. 4.9.2 ー 940221 ) のリゾノレヾ ・ BIND 4.8.3 をもとにしたリゾルバ resolv 十 を使うガ去が考えられます。 SunOS 4.1. x のリゾノレヾをリンクするには、変更は不 要です。実際には、 RESLIB= -lresolv となっています。 BIND 4.9.2 のリゾルバを利用する場合は、いくつか の作業が必要です。 BIND 4.9.2 のトップディレクト リを以下 $BIND と呼ぶことにします。ます、 $BIND/res でコンノヾイルした libresolv. a を、 /usr/lib ヘイ ンストールしておいてください。また、 $BIND/inc1ude にあるインクルード・ファイルを、 /usr/include と /usr/include/arpa へ適宜インストールします。たん なるファイルの置換えでなく、旧いインクルード・ファ イルの言聢が消えないように、きちんとマージしてくださ い。たとえば、 $BIND/inc1ude/netdb. h には、 SunOS 4.1. x の /usr/include/netdb. 五で定義されている ( 図 7 に示す ) 構造体の定義や関数宣言がありません。そこで、 116 これらの定義や宣言か鞘えないように気をつけなけれはな りません。また、 Makefile の RESLIB= -lresolv は修 正する必要がありません。 4.4BSD べースでない言 fr. 算機に BIND 4.9.2 をインス トールして利用する場合は、 $BIND/compat ディレクト リに置かれている 1ib44bsd. a を作って一緒にリンクす る必要があります。この場合、 RESLIB に一 144bsd を追 加します。 セキュリティを考慮して resolv 十を使う場合は、 re- so ⅳ十のトップディレクトリで make を実行して lib- resolv. a を作ります。 1994 年 10 月号では、共有ライ プラリのインストールガ去のみを紹介しました。リゾルバ は、 Sendmail に静的にリンク 2 されますから、 こでは res 。ⅳ十のスタティック・ライプラリが必喫です。ファイ ル名 libresolv. a としてできあがったリゾルバを、た とえば /usr/lib/libresolv +. a としてインストーノレし ます。この場合、 RESLIB= ー lres 。 lv + のように修正して ください。 resolv 十のリゾルバをリンクした場合は、うま くいかないことがあるようです。インクルード・ファイル に関しては BIND 4.9.2 と同様です。 私が変更した Makefi1e. WIDE. sun の一部を表 3 に示します。データベース関係の修正に加えて、 Send- mail をインストールするディレクトリを / usr / 1 土 b から /usr/local/etc に変えてみました。通常は / us て / lib のままで問題ありません。 いよいよ make です。 -f オプションで MakefiIe . WIDE. Sun を指定します。 % make -f Makefi1e . WIDE. Sun オプジェクトと実行ファイルは、 $SM8/src の下のデ ィレクトリ 'arch'-'uname -r' ( たとえば sun4-4.1.3 ) にできあがります。 make がうまくいったら、 Sendmail やその里ファイルを所定のディレクトリにインストール します。 —f Makefi1e . WIDE . Sun insta11 % make ーⅡ—f Makefi1e . WIDE. Sun install # make % su 2 Makefile のなかに -Bstatic という文字列があることから、均にリ ンクされるのが分かります。 UNIX MAGAZINE 1994 ユ 2

連載 / 転ばぬ先のセキュリティー① 図 3 Sendmail に関するパー : 、、ぐ 、ノ / ョン narayama: ~ % ls —ld /etc /etc/sendmail. cf 所有者モト drwxr—sr—x 9 bin 1 root 2560 Oct 11 12 : 04 /etc/ 15168 Apr 17 18 : 28 /etc/sendmail . cf この対策としてコウモリ本には、次のようなルールカ甘曷 載されています。 ・所有者がルートであるファイルへのパス上のディレクト リは、かならずルートの所有で、カつ、ルートだけが書 込み可能でなければならない。 ・ルートが所有しているファイルは、ルートだけが書込み 可能でなければならない。 以上は SendmaiI にかぎらす、すべてのファイルを守 るための一イ難勺な大原則です。推奨されているパーミッ、 ョンの一部を表 1 に示します。 SunOS 4.1. x のパーミッションの多くが不適切な値 に設定されているというのは、 CERT Advisory CA- 93 : 03 で長告されています。これは、 sun-dist の 100103 . tar. z に含まれているスクリプトを実行することで正 しい値に変更することができます。 SunOS 4.1.3U ー 1 で もこれらのパーミッションを修正する必要があります。 このアーカイプは本誌 1994 年 5 月号で示したサイ トから、 anoymous FTP により入手できます。また、 SunOS 4.1.3U ー 1 の CD-ROM のなかに、 patches/ su Ⅱ os ー 4 ー 1 ー 3 1 / patch ー 100103 ー 11 とうファイノレ名で 納められています。 . forward これもハーミッションに関連しますが、各個人の . forward がほかのユーザーに書き込める状態であった場 合、別のユーサーがその人になりすますことができます。 たとえは、図 4 のように、ユーザー kazu の . forward に グループ student の書込み権が発行されていたとします。 グループ student に属するユーザーは、図 5 のように kazu の . forward を書き換えます。ここで、 kazu にメー . というファイル名で kazu ルを送ると、 /home/kazu/. UNIX MAGAZINE 1994 ユ 2 —rwsr-xr—x 1 kazu 106496 Oct 11 12 : 50 % ls -IC /home/kazu/. % mail kazu く /dev/null に setuid された sh かできあがります。 表 1 推奨されるパーミ ノヾス /usr /usr/lib /usr/lib/sendmail /etc /etc/sendmail . cf /etc/sendmail . fd /etc/sendmail . st /etc/sendmail . hf /etc/aliases /etc/aliases ・ pag /etc/aliases . dir /etc/aliases . db /var /var/spool /var/spool/mqueue タイプ ディレクトリ ディレクトリ ディレクトリ ファイノレ ディレクトリ ファイル ファイノレ ファイノレ ファイノレ ファイノレ ファイノレ ファイル ファイル ディレクトリ ディレクトリ ディレクトリ root root root root root root root root root root root root 0755 0755 0755 6511 0755 0644 0644 0644 0444 0644 0644 0644 0644 0755 0755 0700 つまり、次に /home/kazu/... と入力するだけで、誰 でも kazu になりすませるのです。 コウモリ本では、 . forward の対策として以下の 2 点 を挙げています。 ・ bin やルートなどの径ユーサーは、 . forward をも ってはならない。代わりに /etc/aliases などて対処 すべきである。 ・一般ユーサーの . forward は、所有者だけが書き込め るようになっていなければならない。 みてください。 最近のセキュリティ・ホール 去も丘のセキュリティ・ホールの詳細な解説は、 2 つの理 由から割愛します。 1 つは新しいセキュリティ・ホールを まだ寒いでいない糸目織が多いため、ルートになりすます方 法の解説にもなりかねないし、もう 1 つの理由は、最近 報告されているセキュリティ・ホールのすべてを私か理解 しているわけではないからです。なかには熟知しているセ キュリティ・ホールもありますが、キーワードだけ知って いるものも少なくありません。そこで、 こでは上如勺最 ぜひ、自分の . forward のノヾーミッションを確かめて 113

演算子は、上の値が 1 で下の値が 0 の場合にのみ 1 と なり、それ以外は 0 となるような演算をおこないます。 モードを m 、ファイル作成モードマスクをⅡとして C 言語の式で表すと、次のようになります。 通常は、ファイル作成モードマスクの値には、 022 が 設定されています。この値は、作成するファイルやディ レクトリのモードのうち、グルーフ。やそのほかのユーザ ーの書込みを許可しないものです。つまり、「ファイル は読んでもらってけっこう、ディレクトリも検索しても らってけっこう、ただし、僕のファイルを編集すること はしないでね」というかなり寛容な設定です。 このほかによく使う設定には、グループで共同作業す る際にグループに対する書込みを許可する 002 や、グ ループまでは信用するがほかのユーザーはまったく信用 しないという 027 などがあります。 ちなみに、 umask コマンドは、シェルの内部コマン ドとして実現されています。これは、 umask システム コールの景彡響する範囲が、システムコールを実行したプ ロセスに限られるためです。シェルが作成するファイル のモードを操作するには、別のプロセスとして処理され ないように内部コマンドにしておく必要があります。前 回、 cd コマンドの説明をしたときにも詳しく述べまし たが、同しように um k コマンドが内部コマンドとし て実現されていなければ、起動したコマンドのファイル 作成モードマスクが変更されても、シェル自身のファイ ル作成モードマスクは変更されないため、これ以降に起 動するコマンドに対してはなんの意味もないことになっ てしまいます。 シェルから起動されるプロセスには、この設定か継承 されます。したがって、シェルのプロセスでファイル 作成モードマスクを設定しておけば、作成されるすべて のプロセスのファイル作成モードマスクを設定したこと になります。厳密には、シェルはコマンドを起動するた めに vfork システムコールにより新しくプロセスを作 成し、作成したプロセスで execve システムコールをお こないコマンドを実行します。 vfork システムコールで は、まったく同しプロセスが作成されるので、シェルの ファイル作成モードマスクの値がそのまま渡されます。 execve システムコールにおいてもファイル作成モード マスクの値は変更されません。したがって、シェルか起 m & -u 166 動するプログラムが作成するファイルに対しても、ファ イル作成モードマスクが正しく適用されます。リダイレ クトなどにより、シェル自身が作成するファイルに対し て正しく使えることは明らかでしよう。 mkdir 、 rmdir mkdir コマンドは、ディレクトリを作成するための コマンドです。 mkdir ′くス名 とすれば、パス名で指定したディレクトリが作成されま す。 mkdir コマンドを実現しているのが mkdir システ ムコールです。これは、 mkdir()< ス名 , モード ) という形式で使います。パス名には作成したいディレク トリを指定し、モードには作成するディレクトリのモー ドを指定します。 mkdir システムコールの戻り値は、デ ィレクトリを作成できた場合には 0 が、作成できなかっ た場合には一 1 カ区されます。これは、ほかの多くのシ ステムコールと同じ戻り値です。 ここで指定するモードも、ファイル作成モードマスク の景彡響を受けます。つまり、モードとして 0777 を指定 しても、 umask の値が 022 であれば作成されるディレ クトリのモードは 0755 となります。 mkdir コマンド を使ってディレクトリを作成する場合、モードとして 0777 が使われます。つまり、特別な処理をすることな く umask で設定した値にもとづいてディレクトリが作 成されます。 mkdir コマンドの特徴として、ロック機構に利用でき る点か挙げられます。最初に述べたように、 mkdir コマ ンドは mkdir システムコールを使って実現されていま す。 mkdir コマンドでは実際の処理のほとんどを mkdir システムコールを用いておこなうため、呼び出すシス テムコールはこれ以外にははとんどありません。以前 ( 1994 年 8 月号 ) にも説明したことがありますが、シ ステムコールは基本的には不可分操作として扱われるた め、 mkdir コマンドをロック機構の実現に用いることが できるのです。 ちょっと分かりにくかったかもしれません。たとえは、 ディレクトリを作成する場合は、次のように処理されま す。 UNIX MAGAZINE 1994 ユ 2

ーの 連載 /UNIX Communication Notes リスト 2 csd. conf の設定例 # # SITE DEPENDENT SETT 工 NGS # # directory for WWFS WWFSDIR=/work3/wwfs DOMAIN=is . aist—nara. ac ・」 p ントボイント ) を指定する。このディレクトリは、事前 ルのファイルシステム内のどこにマウントするか ( マウ ・ mountdir には、 WWFS で提供される情報をローカ 指定する。 ・ cshost には、 csd か稼動しているホストのホスト名を ・ mountcmd に、 wwmount のノヾスを言当する。 のファイルでは、次の指定をおこなう。 ション・ファイルは、 wwfs . conf である ( リスト 3 ) 。 wwmount/wwumount に関 : 連するコンフィギュレー 境のドメイン名を指定する。 もう 1 つが DOMAIN である。これは、 csd か稼動する環 ディレクトリ以下の領域がキャッシュとして利用される。 連するすべてのファイルがセットされる。さらに、この リ ( 以降では、 WWFSDIR と表記する ) に WWFS に関 1 つは WWFSDIR であり、 ここに指定されたディレクト のファイルでは、次の 2 つの項目を設定する。 て、 csd. conf の準備をする。リスト 2 を見てはしい。 csd に関連するコンフィギュレーション・ファイルとし る。ます、 config ディレクトリに移重丿ける。 最初に、コンフィギュレーション・ファイルを準 ( す - コンフィギュレーション・ファイルの準備 ていなければならない。 須である。すくなくとも、 DNS のリゾルバカ醍供され ネット上の情報をアクセスするには、 DNS の竟は必 るシステムで csd を稼動させるほうがよい。インター る。したがって、インターネットに直接アクセスでき ざまな情幸をのアクセスを前提に作られたシステムであ WWFS は、インターネット上で公開されているさま ・インターネットに妾アクセスできる カルのファイルシステムを用いたはうがよい。 領域 ) にとってもかまわないが、イ頁性からいえばロー をリモートのファイルシステム ( NFS でマウントした 44 に用意しておかなければならない。 リスト 3 ww . co Ⅱ f の言聢例 # pat hname 0 f wwf s mount c ommand mountcmd=/usr/local/vw/etc/wwmount # The machine runnxng csd cshost=fsa2 # mount point mountdir=/ww/fs 次に、トップディレクトリにある Makefi1e. com の 内容をチェックする。このファイルには、生成したバイ ナリのインストール先などカ当されている。そこに言当 されたインストール先のディレクトリがインストールの実 状と合わないときは、 Makefi1e. com を書き換えるので はなく、 config ディレクトリに Makefi1e.10Ca1 と いうファイルを用意し、そこに新たなインストール先を 指定する。コンパイル・オプションを変更したい場合は、 config/Makefi1e. config に新たなオプションを指定 する。なお、 config/Makefi1e ・ config には、予想さ れるコンパイル・オプションの変更例がいくつかコメント として書かれているので、これを参考にしてもよい。 コン / ヾイルの実行 準備か整ったら、 make を実行する。トップディレク トリで make を実行すると、関連するすべてのコマンド が生成される。 WWFS では ANSI C を前提として実装 されているため、 ANSI C に対応していない C コンパイ ラを利用すると膨大なワーニング・メッセージカ咄力され る。しかし、これはそれほど気にする必はない。表 1 ~ 2 に示したプラットホームでは、確実に重川乍する。事実、筆 者が BSD / 386 1.1 で付属の C コンパイラを使ってコン パイルしたときにもかなりの数のワーニング・メッセージ が出力されたが、問題なく動いている。 Ⅵ TFS 用アカウントの準備 コンパイルカ鮗了したら、 WWFS で使うアカウントを csd か稼動する計算機で用意する。 csd では、アカウント 名 s というューザー・アカウントで csd か利用する ファイルを管理する。したがって、アカウント wwfs の UID ははかのユーザーと重複しないものを使うべきであ る。 GID は、 operator などの管理者用のグループを使 用すればよい。たとえば、 wwfs : * : 40 : 5 : WWFS manager : /var/wwfs : /bin/csh UNIX MAGAZINE 1994 ユ 2

連載 . / UN Ⅸ Communication Notes¯O 表 4 ポリューム記述ファイル内てイ吏用するキーワード あいだの通信回線に依存する。自分のサイトが 19.2Kbps の SLIP など妾続されている場合には、ファイル中応に長嗤間 ポリューム ID volume—id: を要するので、ディレクトリ・リストや実際のファイルの内容 FTP サイトク旨定 ftp—server : を得るのに日判がかかる。 WWFS は、 anonymous FTP サ サーバー内でのディレクトリ ftp—directory : イトにアクセスする煩雑な手間を省き、ユーザーが簡単にアク ポリュームの説明 description : セスできるようにするシステムであり、通信回線の速度改善を 目孑嗣ーものではない。 volume-id: は、そのポリュームの番号 ( 正の整印で ポリューム管理 ある。この番号は、 csd が扱うすべてのポリュームで一 WWFS の運用にあたっては、ポリューム管理か重要で になっていなければならない。ポリュームが少ないときは ある。前回も説明したように、 WWFS では anonymous 手動に管理してもよいが、数が多くなってくると相当な手 FTP で提供される情報をポリュームと考え、これを単 間がかかる。これを簡便化するために、 map ・ pl という 位としてアクセスを管理する。具イ勺には、ある anony- PerI スクリプトが用意されている。 mous FTP サイトカ甘是供するディレクトリ空間の、ある このプログラムを利用する場合は、まず volume-id: サプディレクトリ以下が 1 つのポリュームとなる。 という行を付けないでポリューム・ファイルを言当する。 csd は、 WWFSDIR/voI にあるポリューム当ファイ こでは、このポリューム・ファイルを f 。 0. V01 とす ルをもとに anonymous FTP サイトにアクセスする。し る。ルートの権限で以下のように実行すると、自重加勺にポ たがって、管理者はどの anonymous FTP サイトにアク リューム番号カ寸けられる。 セスしたらよいかを決め、その FTP サイトの報を記し # WWFSDlR/bin/map ・ pl f00. V01 たポリューム言己ファイルを用意しなければならない。さ f00 . V01 : v01ume—id=1000 was generated f00 . V01 : OK いわい、現在のⅥーⅥ TFS のリリースには、 164 ポリューム の言当ファイルが含まれている。この言己ファイル群は、 世界各地の著名な anonymous FTP サイトを中心にまと 定意 6 められているため、そのまま使ってもかなりの報にアク map. pl では、 WWFSDIR/v01/seq というファイルに セスできる。 書かれている番号を新たな番号として採用し、さらに seq に 記主された番号を 1 増やす処理をおこなう。したがって、自分 新しいポリュームの追加 でマップファイルを言己して map. pl を使ったときは、トラ プルを避けるために、そオ tJ ユ降はかならす m 叩 . pl を用いてポ あらかしめ用意された anonymous FTP サイト以外 リューム・ファイルを生成する。 にアクセスできるようにするためには、新たなポリューム ftp-server : と ftp-directory : は対で使わオ 定義ファイルを用意しなければならない。 の順で言己しなけれはならない。前者では、アクセスする その場合は、ますポリューム名を決める。 WWFS- anonymous FTP サイトのホスト名を指定する。後者で D 旧 / V01 にあるポリューム定義ファイルは、 は、 ftp-server : て才旨定したサーバーのどのディレクト / 0060r. V01 リをアクセスするか言する。たとえば、 という名前になっているに刎列では、ル。 r がポリュー ftp ・ iij ・ ad ・ jp ftp—server : ム名 ) 。このポリューム名は、すでに使用しているポリュー ftp—directory : pub/X/contrib ムの名前と重複してはならない。 とすると、サ→ヾーとして ftp ・ⅱ j ・ ad ・ jp を使用し、そ 次に、ポリューム・ファイルの内容を言当する。ポリ のディレクトリ -ftp/pub/x/contrib 以下をポリュ ューム・ファイルの文法はきわめて単純で、各行にキー ムとして扱うように指定できる (ftp-directory: の記 ワードとそれに対応する値を記述するだけである。 # 記号 述では、最初の、、 / " ( スラッシュ ) は不要 ) から行末まではコメントとして扱われる。空行はいっさい 言刊面されないので、読みやすくするために使ってもよい。 表 4 に、使用できるキーワードを示す。 通常、 ftp-server: にはホスト名を言当するが、 IP アド 47 UNIX MAGAZINE 1994 ユ 2

図 3 ネットワーク構成図 (BGP MIB より得られた AS レクトリ・システムは、このようなネットワーク情報を イ尉寺するための一嚇甫の 1 つである。このシステムを利用 すれは、各管理者が自分の権限の範囲でネットワークの 情報を登録することによって、世界中の管理システムで 情報を共有できる ( 図 2 ) 。そのために、ますディレクト リ側のネットワーク情報を保持する本咎はを作成した。さ らに、そもそも世界的な標準とならなけれは未をなさな いのて才是案をおこない ( RFC1608 、 RFC1609 ) 、 IETF OSI-DS (Directory Service) グルーフ。で言侖しながら 実験を進めている [ 2 , 3 ] 。 情報の取得 こで問題となるのは、どのようにしてデータを収集 アプリケーションの管理 するかである。ネットワーク管理を専任とする人が少な い状況にあって、データベースの更新作業を管理者に求 ネットワーク上で、さまざまなアプリケーション ( メー めることは難しい。このような状態のデータをもとに正 ル、ニュース、 DNS 、ディレクトリ・サーヒ、スなど ) が 確な構成地図を作成し、更新していくのは困難である。 動くようになってきた。これらは広範囲に分散しており、 そこで、構成情報収集の方法を検討した。現状では、 景彡響の大きさからも各アプリケーションに応じた管理が DNS (Domain Name System) からホスト名と IP ア 必要である。それには、以下のことを監視しなければな ドレス、 Mail Exchanger を、さらに ping や tracer- らない。 oute で接続関係や芯答時間を調べることができる。しか し、これらの情報だけでは不十分である。また、世界中 ・切断、障害、滞留など広い範用に景グする現象 ( たとえ のノード 1 つ 1 つに ping などをかけるのは現実的では は、メールのスプールカヾ益れるとか、ある糸哉のメール システムがダウンして下イ立に流れないなど ) そこで、本来は経路制御をおこなうルータが MIB と 勺な生能や利用率 して経路情報をイ尉寺している点に着目し、それを SNMP これらの管理のために、メールや DNS 、その他の一イ受 によって機本勺に集め、属性 ( 速度など ) や接続関係など 的な NSA (Network Service Application) について を角斤することにした。インターネットのルーティング・ MIB 化が進んでいる。我々は、ディレクトリを構成情 プロトコルには、 AS (Autonomous System) 間として 報の提供システムと位置づける立場から新たに MIB [ 7 ] BGP [ 4 ] など、 AS 内として OSPF [ 5 ] や RIP [ 6 ] な を定義し、 IETF MADMAN(Mail And Directory どがあり、それぞれについて MIB が用意されている。現 MANagement) グルーフ。て活動をおこなっている。 時点でもっともよく実装されているのは MIB -2 である。 図 3 ~ 5 に、それぞれの MIB から得られるネットワーク 情報のモニタリング 構成を示す。なお、 MIB-2 からは本の言岩田な接続関係 カ碍られるので、 1 つの図として見やすくするために階層 的に表現する処理を施している。その結 WIDE 本 では数十の図になるが、ここではそのうちの 1 つを掲げ 、、インターネット本で汎用的に使用で た。このように、 き、しかも自重加勺に構わ也図を表示する " という譲題を解 決した。 構成 ) 為 11 CSI 110 乃 1 価リ C S に一 11867 工ージェントの監視にあたり、多くのネットワーク管 理システムでは、 SNMP による定期的なポーリングによ って管理オプジェクトを収集している。この SNMP の ポーリングの問題点として、 ・管理トラフィックによるほかの通信への景グ 140 UNIX MAGAZINE 1994 ユ 2

連載 . / UN Ⅸ Communication Notes—の レスを直孑旨定することもできる。これにより、 DNS を使っ ていない環境でもサーバーの言当が可能になる。しかし、サー バーの IP アドレスは変更されることがあるので、こク旨定方 法は可能なかぎり避けたほうがよい。 アクセスするサーバーは複数定義できる。 csd では、フ ァイルの先頭から記偵にアクセスの優頂位をつける。 たとえば、 ftp—server : ftp—directory : ftp—server: ftp—directory : pub/f 00 /bar pub/mirror/bar とすれば、プライマリ・サーバーとして A を、セカンダ リ・サ→ヾーとして B を指定できる。このようにしてお くと、サーバー A からの反芯がなくなった場合、 csd は 自重加勺にサーバー B にアクセスする。これによって、信 頼性の高いサービスカ甘是供できる。 複数のサーバーを指定する場合には、提供する情報が同し ものを尺する。去も匠は、多数の anonymous FTP サイトが 互いに内容をミラーしている。このようなミラーサーバーをセ カンダリ・サーバーとして〕尺すればよい。もちろん、 3 つ以 十マ旨定も可能である。 description: には、そのポリュームの説明を書く。 れは、クライアントの WWFS がマウントされているデ ィレクトリにできる INDEX での説明に使われる。ユー サーの利便を図るためにも、特別な事情がないかぎり記 しておくほうがよい。 このような手順に従って用意したポリューム・ファイ ルを WWFSDlR/v01 にコピーする。そして、ルートの 権限で次のように make を実行すると、 # cd -wwfs # make load volume=foo csd がポリューム定義ファイルを読み込み、 リュームか有効になる。 意 7 追加したポ こでは、 csd. conf て寸旨定した WWFSDIR とユ ーサ wwfs のホームディレクトリが同一であると仮定している。 これ力なる場合は、 WWFSDIR に移り、 make を実行する。 以降でも、同様の耐是の下に説明する。 48 ポリューム記述内容の変更 既存のポリュームの言当内容を変更したときは、 csd に 再度ポリューム言当ファイルを読み込ませなければならな い。更新したファイルが f 。。 . v 。 1 の場合、ルートの権限 で次のように make を実行すると、 # cd -wwfs # make reload volume=foo csd は指定したポリューム定義ファイルを再度読み込み、 変更した内容か有効になる。 ポリュームの削除 場合によっては、定義しておいたポリュームを削除す ることもある。そのような場合は、ま $WWFSDIR/voI からポリューム言己ファイルを削除する。続いて、 csd に 読み込まれている情報を次のようにして削除する。削除し たポリューム言当ファイルが f 。。 . v 。 1 だとすると、ルー # make unlo ad volume =f 00 # cd -wwfs トの権限で、 とすれはよい。 # make index # cd -wwfs INDEX を更新するには、ルートの権限で、 INDEX の鹹 とすればよい。 ☆ UNIX MAGAZINE 1994 ユ 2 ( やまぐち・すぐる奈良先立物斗学オ支術大学ギ完大学 ) WWFS に里したツール群について解説する。 次回は、 Emacs の環境で WWFS を使う方法や、 れるであろう。 すると、 anonymous FTP をするのがもどかしく感じら UNIX コマンドが使用できる。いったんこの環境を手に るものの ) WWFS で提供されたディレクトリでも通常の ( ローカルのファイルシステムとは多少違った振舞いをす 光る " システムを楽しんでほしい。前回説明したように になるはすだ。筆者のグループが開発した、、、キラリと こまでの説明で、 WWFS の基本機能が使えるよう

・再起重圻麦はシングルューサー・モードにする ・システムのコアダンプを作成する ・起重加の引数を渡す mount ( タイプ , ディレクトリ , フラグ , データ ) mount システムコーノレは、 ムコールから紹介しましよう。 umount システムコーノレです。ますは、 mount システ で、 umount コマンドを実現しているシステムコールが 見しているシステムコーノレカゞ mount システムコーノレ もうお分かりだと思いますが、 mount コマンドを実 備している場合もあります。 般ューサーでも使用できるように、特別なコマンドを準 や CD-ROM などに格納されたファイルシステムを一 す。ただしシステムのなかには、フロッピー・ディスク のコマンドも、システム管理者だけか利用できるもので る場合には、 umount コマンドを使用します。これら ンドです。いったんつなぎあわせたイ冓造を別々に分け ます。このつなぎあわせを実現するのが mount コマ をつなぎあわせることにより大きなイ哥冓造を実現してい ていますが、実際には小さなファイルシステムの冓造 UNIX ではファイルシステムは大きな木構造となっ mount 、 が異なるので紹介しません。 こでは、おこなう処理 めに準備されているものです。 ムコールがありますが、こちらはまったく別の目的のた のです。システムコールにも shutdown というシステ テムを停止する時刻を指定できるなどの機能が付いたも ンしているユーザーに対して通知をおこなったり、シス に、 shutdown コマンドがあります。これは、ログイ 管理者が使用する reboot コマンドとよく似たもの 数がないものもあります。 処理をしてかまいません。システムによっては、この引 まり、 reboot システムコールの引数は 1 つだと思って には、プート時の引数を指定する必要はありません。っ ログラムに渡されます。はかの実行方法を指定した場合 ここで指定した値は、システムのプートストラップ・プ す " とした場合にのみ、プート時の引数を指定できます。 により異なります。実行方法として、、起第芋の引数を渡 。ここで指定できる値は、システム る ) を指定します などを示す記号定数 (sys/reboot. 五で定義されてい 168 という形式で使用します。タイプには文字列でシステム が処理可能なファイルシステムの形式を指定します。た とえば、 NFS マウントの場合には nfs を指定します。 次のディレクトリは、実際につなぎあわせる場所を指定 します。これは、すでに存在するディレクトリでなけれ は・なりません。フラグには、マウントする際のオプショ ンを指定します。オプションには、読出し専用にするた めのものなどか準備されています。最後のデータは、タ イプに何を指定したかにより異なります。どんなタイプ を指定した場合にも、実際につなぎあわせるための小さ な : 料冓造がどこにあるかを示す情報だけはかならす指定 します。ただし、指定方法はタイプにより異なるので、 mount システムコールのマニュアルなどを参照してく ださい。 mount システムコールを実行すると、指定したディ レクトリの下にデータで指定したディスクなどに格納さ れている : 料冓造が展開されます。いったんイ冓造がつな ぎあわせられたあとは、ユーサーにとっては大きな冓 造が 1 つだけ存在しているように見えます 2 。 umount システムコーノレは、 umount ( ディレクトリ ) という形式で使用します。引数として指定するディレク トリは、 mount システムコールでオ旨定したディレクトリ です。つまり、ルートディレクトリをもつ料冓造と小さ な : 料冓造がつなぎあわせられているディレクトリです。 umount システムコールを実行すると、そのディレク トリに対して mount システムコールを実行する前の状 態に戻ります。 今回は、 UNIX コマンドと同名のシステムコール、 kill 、 umask 、 mkdir 、 rmdir 、 sync 、 reboot 、 mount 、 umount をとりあげました。これらのシステムコール は、重要なものです。「シェル・プログラムならディレ クトリを作れるのに、 C 言語ではディレクトリを作れな い」ではちょっと悲しいですよね。次回は、今回紹介し た mkdir システムコールのように、 UNIX 上の基本コ マンドの処理を実現するシステムコールを紹介するつも りです。 mv コマンドはどう処理されるか知りたくあり ませんか ? ( いまいすみ・たかし東京工業大学 ) 2 実際には、いくっかのコマンドで景彡響が出ます。これについては、次 回にとりあげるつもりです。 UNIX MAGAZINE 1994 ユ 2

連載 . / も N Ⅸ Communication N0tes¯O 表 3 WWFSDIR 以下に作られるサプディレクトリ bin C ache etc lib 10g sta1e ongo V01 実行可能なファイル群 (csd 自身のはか、 Perl などの管理用プログラムもこのディレクトリ ロタされる ) キャッシュ情報 Perl スクリプトのための設定ファイル Perl スクリプトカイ吏用するライプラリ csd が生成するログファイル csd の作業用ディレクトリ csd が ( 乍業をおこなうディレクトリ ポリューム・ファイル群 といったアカウントにする。このとき、ユ—*ff—wwfs の ホームディレクトリを csd. conf でオ旨定した WWFSD 旧 にすると以降の作業が進めやすい。 意 1 アカウント wwfs の UID は、絶対にはかのユーサーと同 しものにしてはならない。これまでの WWFS の運用経験か らいえば、 csd の実装はたいへん安定しており、異常な挙動は まったくといってよいほどみられない。しかし、とくにファイ アウォール上で csd を運用する場合は、セキュリティの保全に wwfs@hostname 他サイトからの間合せなどに対応して、 WWFS では、運用を通して発生する各種のレポートや とは異なる UID にしておいたほうか安全である。 十分な注意を払う必要がある。その意味でも、はかのユーサー UNIX MAGAZINE 1994.12 # make install—client これは、 クライアントのインストール conf としてインストールされる。 さらに、 csd の重川乍を決める csd. conf は /etc/csd. れる。 た WWFSD 旧以下に表 3 のようなディレクトリ群が作ら をルートの権限で実行する。すると、 csd. conf で指定し # make install—server csd を下力させる計機で、 csd のインストール 実際の管理者に転送されるようにしておくべきである。 たメールを正しく処理できるようにアカウントを設定し、 にメーノレが送られる。したがって、このアドレスに送られ をルートの権限で実行すればよい。 注意 2 現在の WWFS の / ヾッケージでは、 AMD のようにアー ポリューム管理に分けられる。以ード、順に説明する。 WWFS の運用は、 csd の管理、クライアントの管理、 WWFS の運用 以 E で、インストールは終了である。 が /etc にインストールされる。 wwfs. conf とクライアントの起動ワログラム wwclient がそれぞれ LIBDIR と INCDIR に格納される。さらに libww. a とそれを使うためのヘッダファイル libww. 五 に記述されている ETCDIR に、 WWFS のライプラリ これで、 wwmount と wwumount カゞ Makefi1e . com できない。 パイルだけしておいて、あとで一気にインストールすることは ストールを繰り返さなければならない。 AMD のように、コン ストールするときは、アーキテクチャごとにコンパイルとイン い。したがって、クライアントを複数のアーキテクチャにイン ト・ファイルや実行可育彡式のファイルカ非られるわけではな キテクチャごとにディレクトリが作らオし、そこにオプジェク csd は、 csd-nanny という Perl スクリプトて力す おこなわなければならない。 csd の管理では、起動と停止、キャッシュ領域の管理を csd の管理 45 を事前にインストールしておく。 よい。このプログラムでデバッガとして使われている gdb 純で小さな PerI スクリプトなので、目をとおしておくと csd-nanny は WWFSDlR/bin にイ褓内されている。単 として起動する。 # WWFSDlR/bin/csd-nanny る。ルートの権限で、 メールで送る。そして、 csd を再起動しサーピスを継続す した場合はコアファイルを角斤して、その情報を管理者に る。このプログラムは、 csd を起動し、 csd がコアダンプ