リスト 1 ntp. C0Ⅱf8」 server driftfile AA . BB . CC . DD /var/run/ntp ・ drift リスト 2 resolv. confØf51, 」 doma in nameserver mycompany ・ co ・ JP AA . BB . CC . DD 場合、どのような被害をどういう順番で受けたのかを把屋 するために日骸ー牘報は必頭です。 日駭リをい期させるガ去はいくつかありますが、 こでは NTP (Network Time Protocol) を使います。 たとえば、 IP アドレスが AA. BB ℃ C. DD のホストを NTP のサーバーとして参照する場合は、リスト 1 のよう な内容の /etc/ntp. conf というファイルを作成します。 ℃ eBSD の場合 FreeBSD を使っているのなら、 /etc/sysconfig を次 のように変更します。 xntpdf1ags="NO" # xntpdf1ags="NO " リゾルバの設定 最糸勺にはファイアウォール上でネームサーバーを立ち 上げますが、構築イ 1 業の段階では、とりあえすほかのホス ト上で漣用しているネームサーバーを参照します。 たとえば、ファイアウォールのドメインが、 mycom- pany ・ co ・ jp 、ネームサーノヾーの lP アドレスが AA. BB. CC. DD の場合、リスト 2 のような /etc/resolv. conf を 作成します。 /etc/inetd. conf の変更 /etc/inetd. conf から、すべてのエントリを削除しま す。ばっさりときれいさつばり削除してください。 ネットワーク経由でログインして作業をしている場合 は、 telnet のエントリだけを残し、その他はすべて削除 します。 そして、 inetd にシグナル SIGHUP を送ります。 /etc/rc の変更 多くの OS では、いろいろなデーモンか動いています。 しかし、たとえ tirwhod や nfsiod はファイアウォール 88 にとっては不要です。そこで、これらのデーモンか起動さ れないように /etc/rc を編集します。 FreeBSD を使っている場合は末尾のリスト 3 に示した 行を、 BSD/OS 2.1 ではリスト 4 に示した行を、そして BSD/OS 3.1 ではリスト 5 に示した行をそれぞれ削除し ます。 sendmail の起動オプションの変更 標準の設定では、 sendmail はデーモンモードで起動さ れます。しかし、 FWTK のパッケージには SMTP コネ クションを受け付ける専用のデーモンカ哈まれています。 そこで、 sendmail の起動時 = のオプションを以下のように 変更します。 FreeBSD の場合 /etc/sysconfig を次のように変更します。 sendmail—flags="-bd ー q30m ” sendmai1—f1ags="—q30m' BSD/OS の場合 /etc/rc を次のように変更します。 /usr/sbin/sendmail —bd —q30m /usr/sbin/sendmail —q30m /etc/hosts. equiv の設定 次のコマンドを実行し、 /etc/hosts. equiv の設定をお こないます。 # rm —f /etc/hosts. equiv # touch /etc/hosts. equiv # chown root . wheel /etc/hosts . equiv # chmod 400 /etc/hosts . equiv その他の設定 BSD/OS の場合は、 BSD/OS 2.1 の場合 こオ山外に次のような設定が必要 ファイル /etc/netstart を次のように変更します。 rstatd=NO rwhod=NO rst at d=YES rwhod=YES UNIX MAGAZINE 1998.1

Network Resource PIanning• きる。べースとなるトラフィックのサンフ。ルは、新しいア プリケーションが導入されるネットワークにおいて、その アプリケーションのトラフィックカリ用率にどの程度の変 化をもたらすかを算定する際に重要である。 新規アプリケーション導入のための基礎データを算定す るうえで重要なステップは、データ収集方法の決定にあた って次の項目を検詞することである。 ・どんな不頁のトラフィック・データ、利用率データ、ア プリケーション・データが必喫か。 ・アナライザやプロープをどこに配置すべきか。 ・データ収集の間隔と期間はどれくらいか。 ・平均データをもとに算定するのか、それとも最大負荷デ ータをもとにするか。 米国のデータベースを用いたアジア太平洋のプロジェク トでは、ネットワークの利用率と、使用されているアプリ ケーションの両方を知る必要があった。利用率は SNMP を使ってルータに再度問い合わせることで収集された。た だし、今回は、、イン " と、アウト " の両方のバイト数であ る。管理者たちは、一定間隔 ( たとえば 5 分 ) で全ルー タのサンプリングを実施して増分バイト数を言算し、それ を日判日間隔で割った。その結果が各サンプル期間のインと アウトの Kbps 測定値である。この値は、送信 ( アウト ) と受信 ( イン ) の両方向における各回線の利用率 ( 送信が 32Kbps なら、回線速度の 64Kbps て割った 50 % が送 信方向の回線利用率になる ) の計算に用いられた。すべて のルータを対象に 5 分間隔で 2 日から 3 日にわたって利 用率を収集した。それをもとに、アプリケーションがもた らす景を調査するための編データを算定した。 アプリケーションに関するデータは、アジア太平洋のネ ットワーク・ユーザーカリ用しているアプリケーションの タイフ。や質を調べるために必要だった。ほとんどの場合、 回糸泉速度は、米国につながる回線 (256Kbps) を除けば、 64Kbps から 128Kbps の示間用 ( 低帯域のものだった。 トラフィックのうちピジネスと無関係なもの ( インターネ ット・トラフィックなど ) の割合が多い場合、新しい SAP R/3 ューサーが必要とする品質のサービスを提供するに は、資金を投入して或幅を拡大するよりも、ネットワー ク・ポリシーの強化のはうが必喫性か高い。既存のトラフ ィックの一部か新しい SAPR / 3 のトラフィックに取っ 72 て代わられるため、両者を上交検討するためにアプリケー ションに関するデータが必要となる。 アプリケーションについてのデータは、今回の場合、米 国に戻ってくる 3 本の専用回線の経路にトラフィック・ アナライザか RMON Ⅱタイプのプロープをつなぐこと で収集された。 SAP R/3 導入以前の段階でも、アジア太 平洋のユーザーのためのネットワーク資源のほとんどすべ てが米国に置かれていたからである。利用率とアプリケー ションについてのデータの相関をみるため、両データは同 じ 2 ~ 3 日間、同し 5 分間隔で収集する必要があった。 両データの収集後、それらを分析して各経路の帯域巾リ 用率とそうした利用を生み出すアプリケーションのタイプ を調べるイ乍業に入った。非ビジネス型のトラフィックの割 合が大きい場合は、その点に着目する必要があった。 そして、このデータを用いて、新規アプリケーション (SAP R/3) のトラフィックカヾ充れるべースとなるネット ワークの利用率か求められた。 プロファイルの作成 UNIX MAGAZINE 1998 ユ R/3 アプリケーション開発者が使用する開発ラボの設置 アジア太平洋地域のプロジェクトでは、社内の SAP ネットワーク負荷を不職頁別にモデル化することができる。 ライザか集めたデータを用いて、トランザクションごとの データを収集しなくてはならない。トラフィック・アナ データベースとアプリケーション・サーバー間で、同時に る場合、クライアントとアプリケーション・サーバー間、 ス・サーバーの叫秀によってトランサクションが処理され クライアント、アプリケーション・サーバー、データベー なデバイスを用いて生きたデータを収集することである。 正確に予測する去は、トラフィック・アナライザのよう アプリケーション・トランザクションの特性をもっとも れる。 各方向におけるデータ総量、トランサクション率カ求さ イルには、ユーザーごとの活動として、バケットサイズ、 くるデータの量やタイプについての糸である。プロファ イルは、クライアントとサーバー間のデータや再度戻って ワーク利用を予測しておく必要がある。これらのプロファ ションのプロファイルを作成し、ユーサー単位でのネット NRP では、トランザクション・レベルでのアプリケー

NETWORKTECHNOLOGY 4 なお、 LEC は LE-ARP-REQUEST を LES に送信し たあと、 LE_ARP_RESPONSE メッセージ ( あるいは timeout) を待たず、即座にフレームを unknown フレー ムとして Multicast Send VCC を通して BUS に送信する ことが可能です。この場合、 LEC は LES から LE-ARP- RESPONSE メッセージを受信したあと Data Direct VCC を張り、後述する flush プロトコルを用いて当該 MAC ア ドレスに対するフレームの転送を BUS 経由から Data Di- rect VCC 経由に切り替えます。 BUS は MuIticast Forward VCC を通して ELAN 内の 全 LEC に unknown フレームを送信します。 unknown フ レームを受信した各 LEC は以下の処理をおこないます。 1. その LEC が non-proxy LEC の場合 unknown フレームに含まれる宛先 MAC アドレスが自 身の MAC アドレスに一致しない場合、 unknown フレ ームを廃棄する。 unknown フレームに含まれる宛先 MAC アドレスが自身の MAC アドレスに一致する場合 ( 通常は一致しない ) 、その unknown フレームを受信 し、上位層に渡す。 2. その LEC が proxy LEC の場合 unknown フレームをⅡ ooding する。ただし、自分が 送信したフレームは flooding しない。 このように、 BUS はプロードキャストおよびマルチキャス ト・フレームだけでなく unknown フレームの転送もおこなう ため、 Broadcast and Unknown Server と呼ばれます。 LE ARP キャッシュ フレームを送信するたびに、 LES に対して LE—ARP— REQUEST メッセージを送信するのは非効率的です。そ こで、 LANE では LEC に対して LE ー ARP キャッシュの実 装を義務づけています。 LE-ARP キャッシュは LE-ARP によって解決された MAC アドレス・ ATM アドレスの組を 保持する table です。 LEC はフレームを送信する際、ま ず最初にフレーム中の宛先 MAC アドレスをキーにして LE ー ARP キャッシュを検索します。宛先 MAC アドレスに 対応する ATM アドレスが LE ー ARP キャッシュに存在す る場合、 LEC は LES に対して LE_ARP_REQUEST メ ッセージを送信する必要はありません。その ATM アドレ スに対してすでに Data Direct VCC が張られている場合 36 図 8 れ ush プロトコルの仕組み BUS (1) LEC 1 LES ( 4 ) ( 2 ) LEC 2 ( 3 ) 1. LE FLUSH_REQUEST 、 MuIticast Send VCC 経由 2. LE FLUSH_REQUEST 、 MuIticast Send VCC/Multicast Forward VCC 経由 3. LE_FLUSH_RESPONSE 、 control Direct VCC 経由 4. LE ARP RESPONSE 、 Control Direct VCC ℃ 0 猷「 Distribute VCC 経由 UNIX MAGAZINE 1998.1 フレームと呼ぶのでした。 12 このようにして BUS に送信されたユニキャスト・フレームを unknown います。図 8 に flush プロトコルの仕組みを示します。 信路の変更に用いられるプロトコルをⅡ ush プロトコルとい ら Data Direct VCC 経由に切り替えます。このデータ送 なります。ここで、 LEC はフレームの送信を BUS 経由か 経由と Data Direct vcc 経由の 2 つが存在することに ます。この時点で送信先に対するデータの送信路は BUS すると、送信先 LEC に対して Data Direct VCC を張り もに、 LES から LE_ARP—RESPONSE メッセージを受信 この場合、 LEC はフレームを BUS に送信し続けるとと を待たすにフレームを BUS に送信することが可能です 12 。 述べたように、 LEC は LE—ARP—RESPONSE メッセージ 「 proxy LEC 、 non-proxy LEC とアドレス解決」の節で flush プロトコル います。 秒、デフォルトが 300 秒、最大値が 300 秒と規定されて LE_ARP キャッシュの aging time の値は最小値が 10 す。 Data Direct VCC を張ってからそこにフレームを送信しま はその VCC に、 Data Direct VCC が存在しない場合は

TCP wrapper ■ 図 7 /opt/transfer/transfer スクリプト cd /opt/progi/data/reports /usr/bin/tar cvf /opt/transfer/files prog?/early* rcp /opt/transfer/files servl : /the/web/directory/servl/ /usr/bin/rm /opt/progi/data/ reports/prog?/earlystats* 図 8 doservl cd /the/web/directory/prodl tar xvf files mv /the/web/directory/servl/progm/early* /web/progm/docs/stats/reports/ mv /the/web/directory/servl/progp/early* /web/progp/docs/stats/reports/ mv /the/web/directory/servl/progr/early* /web/progr/docs/stats/reports/ /usr/bin/chmod 644 /web/prog?/docs/stats/reports/early* /usr/bin/chown root . other /web/prog?/docs/stats/reports/early* 図 9 安全な finger を実行するためのホスト拒否ファイル (/on/disguised/server/safe-finger ー 1 @%h ー /usr/sbin/mail —s %u —%d —%h root) & in . rshd: . servl : ルは servl に上書きコピーされる。ファイアウォールは ゲートウェイから Web サーバーへの rsh のみを許可し、 さらに TCP wrapper プログラムかま行される。このプ ロセスがホスト許可 / 拒否ファイルを十正する。 中幻カ鮗了すると、ファイルは tar ファイルから取り出 されて正しい場所に移される。そして、これらのファイル に対して chmod 、 chown か夫行される。図 8 は doservl サ→ヾーの概観である。 doserv2 もまったく同じだが、 れは doservl の代わりとなるものである。 ログファイルは別の安全なサーバー上に置かれる。この ファイルには、成功 / 失敗か第当求される。許可されないリ モートシェルの使用もすべて言求される。 特殊な機能 UNIX MAGAZINE 1998 ユ トパターンの両方がマッチしてはしめて可能である。 情報を得られる。しかしこれは、デーモンリストとホス ザー名を調べると、接続をおこなった当人に関する追加 TCP wrapper プログラム経由でクライアント・ユー Makefile で言殳する。 ければアクセスは拒否される。この機能を使いたければ、 れによりホスト名とアドレスを照合し、マッチしていな には、 -DPARANOID を有効にしてコンパイルする。 アクセスしているのか、さらに詳しい情報を知りたい場合 はかにもいくつかある。誰が自分のサーバーやファイルに TCP wrapper を最大限活用するための重要な機能は、 の機能は、正確なユーザー名を石忍しようとする場合にと くに有用である。システムへの侵入やサーバー誤用のはと んどは糸内て起きているので、この機能を使えは容易に 人物の特定かできる。侵入者を本剱日し、損害を被る前にア クセスをプロックするもう 1 つのセキュリティ機能があ る。これはユーサーの ID を調べることでアドレス詐畋 撃 (address-spoofing attack) を検知する。結果が un- known@host として返ってきたら言乍称がおこなわれてい ることになる。 侵入か試みられた場合に対処できるような TCP wrap- per の成疋法がいくつかある。 侵入者がアクセスを試みたときに、そのユーザー名やホ ストを管理者にメールで連絡するようにできる。これは、 ホスト拒否ファイルに数行追加す川まよい。 その場でのアクセス拒否、安全な finger コマンドの実 行、管理者への情幸当言ができる。安全な finger コマン ドは、リモートホストから送信されたデータをふるいにか ける。通常の finger コマンドよりもはるかに安全なもの である。これは、図 9 のようにホスト拒否ファイルに記 述する。 たとえば、誰かが servl 上でⅲ . rsh を実行しようとす ると、 TCP wrapper は safe-finger を起動する。クラ イアントのユーザー名、ホスト名もしくはアドレス、呼び 出されたデーモンプロセスが root ューサーに送られる。 もっと速く簡潔なのは、侵入者に関する情報だけを取得し て管理者に送るガ去である。あるプロセスに限定された内 97

図 12 chdir の実行 ( 1 ) 図 13 chdir の実行 ( 2 ) dcwd 116 dhead の 2 つの要素があることが保証されるため、上の スタックに要素が 1 つしかなくても、かならす dcwd と ところが、 dhead を利用すると、たとえディレクトリ・ です。 ると、指す箱のない宙ぶらりんのリンクが残ってしまうの dp から dcwd へのポインタがあるので、 dcwd を削除す dcwd を削除して dp を dcwd にするだけのはすですが、 しかし、この状態には問題があります。残る処理は すると、図 13 のようになります。 されていません。このあと、さらに next と prev の値を まだ追加の準備をしただけで、 dp からのリンクしか設定 調整すると図 12 のような状態になります。この皆では、 この状態から chdir を実行し、 dp の prev と next を 図 14 dhead を啝囲した場合 ような間題は生じません。こちらも図解してみていきまし 図 14 は、要素が 1 つしかないディレクトリ・スタッ クに対して chdir コマンドを実行し、新たな要素を追加し てリンクを言各した段階です ( つまり、 dcwd を削除する 直前の状態です ) 。 この状態なら、安全に dcwd を削除することができま す。もちろん、要素が 1 っしかない場合に特別な処理を施 すようにすれば、 dheåd を使わないプログラムを書くこと もできます。しかし、プログラムに特別な牛を埋め込む のではなく、どの要素も統一的に扱える C シェルのよう なガ去は、誤りの少ないプログラムを作成するためにも必 要です。 C シェルが利用するリスト構造 C シェルでは、ヒストリーリスト、単語リスト、ディレ クトリ・スタック以外にもリスト構造が使われています。 その 1 つは、 csh. h で定義されている whyle 構造体 です。これは、 C シェルの糸ムみコマンドである while や foreach などの区し ( ルーフ ) を表現する制徊構造の 実現に利用されています。ループのなかにさらに別のルー フ。がある場合などは、一番外側のループから順番に whyle 構造体を使って単リスト構造を生成し、実行の缶剏に利用 します。 end 、 continue 、 break など、ループに対する 処理をおこなう糸ムみコマンドを扱う場合は、このデータ 構造に↑褓内された値を使います。また、 goto などでルー プを飛び出すときにもこの構造体か活用できます。 UNIX MAGAZINE 1998.1

FreeBSD ノート 浜田直樹 ファイルシステム ( 後編 ) 私は果実日未たっふりのポジョレー・ヌーヴォーか好きで ある。毎年、 11 月第 3 翆日の角食日に店頭に並ふ、が、 れは航空便で連はれているのでずいぶん高くつく。私は、 お祭りのご祝儀のつもりで 1 本だけ買って楽しむことに している。本誌が発売されるころには更のものが出回っ ているはすである。こちらのほうは、値段だけでなく味も 落ち着いているので、毎日の食卓の供としてふさわしい。 和食にも合い、島や照焼きなどのタレを使った料理には とくに馴染む。 ポジョレー・ヌーヴォーは特殊な造り方をするため早 く飲めるようになるのだが、それでもしばらく寝カせて熟 成させたはうか調和のとれた味わいになる。そのようなわ けで、正月過ぎに安売りしている売れ残りのポジョレー ヌーヴォーはお買い得である。 ソフトウェアにも同じことがいえる。新しく追加、改 良された要素が安定するまでには、リリースからある程 度の時間が必要である。 2.2 系列の FreeBSD は、 2.2 ー RELEASE から 1 年かかって 2.2.5-RELEASE まで たどり着き、かなりこなれたものになっているようだ。 今回紹介するソフトウェアや機能のなかにも、まだ未 熟で不具合のあるものがいくっか含まれている。しかし、 これらは成熟していく過程にあると考えることもできるの 最新情報 で、あせらす見守っていきたい。 144 FreeBSD-2.2.5-RELEASE の CD-ROM が出荷され WaInut Creek (http://www.cdrom.com/) から、 FreeBSD-2.2.5-RELEASE CD-ROM た。これは通信販売のほか、国内ではソフトウェアの販売 店や、一部の書店でも扱っているようである。 構成は、 CD-ROM 4 オ好はになった。順番にその内容 をみてみよう。 インストール・ディスク 1 枚目の CD-ROM には、インストールに必要なデー タがひととお求されている。ただし、従来は 1 枚目に 1 求されていた商用ソフトウェアの試用版や実験段階のソ フトウェア、 XEmacs や日本語フォントなどの容量の大 きいノヾッケージ・コレクションの一一部が 3 枚目に移って いる。 ライフ・ファイルシステム 2 枚目の CD-ROM には、 FreeBSD を動かす際に必 要なファイルが展開したかたち 0 求されている。さまざ まな利用法があるので、いくつか例を挙げてみよう。 ます思いっくのは、必要なファイルを誤って削除した 場合である。ファイルはすでに展開されているので、 CD- ROM をマウントしてコピーするだけでよい。 システムが壊れてプートしなくなった場合の修復にも 利用できる。インストーラ・ディスクから起動し、メニ ーから、、 Fixit—Enter repair mode with CDROM /flOPPY, or start a shell." を選択してライプ・ファイ ルシステムの CD-ROM をドライプに入れる。すると、 CD-ROM をルート・ファイルシステムとする FreeBSD か起測けるので、修復竹喋をおこなうことかできる。 1 枚目の CD-ROM の floppies/fixit.flp にイメージ が用意されている fixit ディスクでも同様の操作が可能だ が、こちらは容量が限られているので、使えるコマンドは 一都だけである。 UNIX MAGAZINE 1998.1

ロプログラミング・テクニック 2 重リンクリスト 3 多治見寿和 上にも書いたように、前回とりあげたのは、要素をつな ぐ、、リンク " が 1 つしかない屯な構造でした。この場合、 剏頁から要素を順番にみていく操作は簡単ですが、遡頂の 処理ではやや凝った操作が必要になります。これは、次の 要素を指すリンクしかないのが原因です。したがって、前 の要素を指すリンクも付けれは解決します。このような、 、、次 " と、、前 " という 2 つのリンクをもつ構造が、、 2 重リ ンクリスト " です。 則号を読んた者から、 「ソースプログラムを読みながら・・ はとんどないじゃないか」 と怒られてしまいました。 すこしだけ釈明すると、この連載の目的はプログラムを 読むことではなく、そのなかで使われているテクニックを 知ることにあります。ですから、できるかぎりソースファ イルをとりあげるのはもちろんですが、必喫とあれば前回 のような基本的な知識も紹介するつもりです。 前回は、データ構造を理解するための予備知識として C 言語のデータ型について説明しました。当初の予定よりも 誌面を費やしてしまい、リンクを 1 つだけ使う屯なリス ト構造 ( 、、単リスト " とも呼びます ) しか紹介できません でした。今回はもうすこし複雑なデータ構造として、 2 重 リンクリストをとりあげます。 リスト構造の復習 簡単に前回の復習をしておきましよう。再帰的データ構 造の 1 っとしてリスト構造を紹介しました。これは、構造 体のなかのあるフィールドに対して、定義しようとする構 造体自身へのポインタを使うものです。同しデータ型の値 ご覧のように、この構造体には 3 つのフィールドがあり を数珠つなぎにして扱えるので、配列のように同しデータ ます。 1 つはデータをオタするための word 、残りの 2 っ 型の値をまとめて扱う場合に利用します。配列を使うとき はリンクとして用いる prev と next です。 word フィ は最初に大きさを決めておかなければなりませんか : この ルドには文字列を保存します。通常は char * 型ですが、 1 構造を利用すれば、重加勺に大きさか変わるような 1 帯長もう バイトでは文字を表せないケースも考慮して、大文字で始 まく処理できます。要素の順番を入れ替えたり、途中に要 まる、、 Char " という型になっています。もちろん、この 素を挿入するといった操作がポインタの伺替えだけででき Char は別の場所で定義されていて、文字を 1 バイトて表 るので、とくにオ褓内するデータカ吠きいときは、配列の場 現できる卵竟であれば char に、 2 バイトが必要な竟で 合より処理か簡単です。 あれば short になるように ifdef を使って定義されてい の て っ と 2 重リンクリスト 今回は、 2 重リンクリストの例として、 csh のソースプ ログラムから wordent 構造体をとりあげます。前回紹介 したヒストリーリストと同様、ヘッダファイル csh. h で 定義されています ( ヒストリーリストの Hlex フィールド は、この wordent 構造体てす ) 。 構造体の定義は次のように言当されています。 struct wordent { Char *word; struct wordent *prev ; struct wordent *next ; 108 UNIX MAGAZINE 1998 ユ

企業本にわたるネットワークは、ネットワーク・サー ピスを利用している数千の個人の目からはみえないコスト がかかっている共有資源である。 NRP により、特定のネ ットワーク・アプリケーション寺定のユーザーグループ にかかるコストを定量化することかできる。 戦略的な糸変革 UNIX MAGAZINE 1998.1 NRP をよ引危に実施すれば、ネットワーク運用や財 発生するネットワーク停止の原因を特定できる。 トワーク・セグメントの利用を分析することで、繰り返し ト増大の抑制という耐妾の効果が生まれる。そして、ネッ 入できる。 1 つのネットワークを最商化すれは、伝送コス にネットワーク集約型のピジネス・アプリケーションを導 上のデータ・トラフィックを分析することで、より効勺 し、簡単なコスト成フランカイ乍成できる。ネットワーク ータの算定を通じて、機枷友や容量に関する問題を把屋 ワークのドキュメント作り、現行の WAN 利用の基礎デ なプロジェクトとして始めることができる。物理的ネット たすことができる。社内の NRP は、即効性のある小さ NRP は、これらの糸目織を結びつける接着剤の彳齬リを果 互作用から生じる実装上の要件を理解してはいない。 理解してはいても、アプリケーションとネットワークの相 ある。彼らは、業務変革窈俺というビジネス上の目標を ケーションのコスト、そして業務の成功を監督する責任が 任 (CIO) と財務主任 (CFO) は、ネットワークやアプリ ランニングか制限される。これらの組織を管理する情報主 れた場所にオフィスがある場合は、顔を突き合わせてのプ これら 2 つのグループが別々に管理されていたり、離 しているわけではない。 プリケーションか要求する資源やコストについて深く理解 リングや更新にかかるコストを理解していたとしても、ア ワークカえる間題や、ネットワーク資源のリエンジニア られる。情報技術担当スタッフ (IT) は、現行のネット ネットワーク上でどのように働くかを知らないことも考え トについての情報を知らなかったり、アプリケーションが るアプリケーション開発者が、ネットワークの性能やコス にある場合も多い。データベースやメニュー構造を言 t す く、単第各的な組織変革を実行しようとする企業の姿勢刎則 成功の鍵が、用いられる方法論やソフトウェアではな Network Resource PIanning ・ 務分野の責任者を含め、管理チーム本でネットワークと ネットワークがもたらすコストを先見的に管理できるよう になる。企業全体にわたるネットワークがその運用やビジ ネスの成功に与える予測不可能な景に際限なく対応し続 けて、莫大なイ面を支払う必要はなくなるのだ。 ロ NRP が必なのは誰か ? 世界中の企業が、利益を上げるのに欠カない業務プロ セスを麪爰するため、イントラネット上のミッション・ク リティカルなアプリケーションへの依存度を高めている。 SAP R / 3 、 BAAN 、 PeopleSoft 、 Oracle などをベース とする卓越したアプリケーション群は、重要なピジネス機 能を統合して、近代化を推進する。糸目系調里用、糸目織管理、 コミュニケーション、言当求管理、思決正のプロセスは、 情幸支術 ( アプリケーションと、ネットワークのインフラ ストラクチャ ) と不可分の関係となる。市場におけるこう したアプリケーションの規模 (SAP R/3 は世界に 5 , 000 の顧客をもっている ) とその成長の速度には、驚くべきも のがある。 NRP を採用すべきかを決めるための要素とし て重要なものを検討するのは意味のあることだ。 ロアプリケーション・アーキテクチャ NRP のターゲットとなるユーザーは、地理的に分散し ている企業に業務統合アプリケーションを導入しようとす る人たちである。 ッション・クリティカルなアプリケー ションがモジュール化されたアーキテクチャへと進化する と、ネットワークとの ; 叫秀がより重要になり、サーピスの 質に与える景より大きくなるだろう。いに、データ べースを地理的、系辟勺な道筋に沿って分散させることが 可能であれば、ネットワークとの柤圧作用についての調査 はさらに重要なものになる。 ロ ネットワーク利用の状況 大規模なクライアント・サーバー型アプリケーションを 配備する場合に NRP の価値を決める重要な要素として、 アプリケーションカイ吏用するネットワークの状況がある。 ネットワーク資源を専有するこれまでのアーキテクチャ (SNA など ) とは異なり、今日のネットワークははば常 75

NETWORKTECHNOLOGY 4 LANE 構成要素と VCC 図 6 LAN EmuIation Configuration Server (LECS) ブリッジ LAN Emulation CIient (LEC) ワークステーション LAN Emulation Client (LEC) っ 4 っ 4 LAN Emulation Server (LES) Broadcast and Unknown Server (BUS) legacy LAN LAN Emulation User Network lnterface ( LUNI) 1. Configuration Direct VCC 2. Control Direct VCC 3. Control Distribute VCC 4. Multicast Send VCC 5. Multicast Forward VCC 6. Data Direct VCC 決された送信先 LEC の ATM アドレスを得たあと、送信 に対応している。また、 non-proxy LEC の ATM アドレ スが複数の MAC アドレスを代表している場合には、 LEC 先 LEC に対して Data Direct VCC を張り、ユニキャス が管理するすべての MAC アドレスを LES に登録する。 ト・フレームを送信します。 proxy LEC 、 non-proxy LEC と 具体的には Ethernet などの legacy LAN のポートをも っプリッジが proxy LEC となります。これに対して ATM アドレス解決 NIC をもつホストは通常 non-proxy LEC です。 legacy LAN のポートをもつルータの場合、通常のルータは non - LANE では LEC を proxy LEC および non-proxy LEC proxy LEC でかまいませんが、 FORE Systems の Pow- の 2 つのカテゴリーに分類しています。この 2 種類の LEC erHub のように複数のポートを同一ネットワークに割り当て の相違点は以下のとおりです。 ることが可能なルータは proxy LEC になります。 「 LES 」の項で LANE における基本的なアドレス解決の proxy LEC 仕組みについて解説しました。これは宛先 MAC アドレス proxy LEC の ATM アドレスは複数の MAC アドレス が、 non-proxy LEC の場合については有効ですが、リ を代表しており、かっこれらの MAC アドレスは LES に登 モート MAC アドレスの場合には適用できません。 録されていない 10 。 Ethernet ポートと ATM ポートをもつプリッジ B を例に non-proxy LEC とって考えてみましよう ( 図 7 ) 。ホスト A 、ホスト C 、プ LEC の ATM アドレスは通常、単一の MAC アドレス リッジ B は ELAN "example" に属しています。また、 ホスト 1 、ホスト 2 は Ethernet を介してプリッジ B に接続 10 proxy LEC によって管理されている LES に登録されない MAC アド されています。ホスト A がプリッジ B を介してホスト 1 に レスを、リモート MAC アドレスといいます。 34 UNIX MAGAZINE 1998.1

連載 /FreeBSD ノート一- 図 4 プロセスの軈の読出し 0 .3 0 .0 0 . 1 1 . 2 0 .0 PID %CPU cat 15127 15100 15127 297 5 , 5 ctty 880359023 , 550040 0 , 0 0 , 2724 nochan 0 0 0 , 0 , 0 ayanami# cat /proc/curproc/status 図 5 ps の出力い ayanami # USER root root neWS root ayanami# ayanami# USER て 00t root neWS root PS auXWW PID %CPU %MEM 195 207 210 233 258 umount p S 258 233 210 207 195 0 . 0 0 . 0 0 . 0 0 . 0 0 . 0 /proc 0 . 0 0 . 0 0 .0 0 . 0 0 . 0 %MEM 0 . 3 0 . 0 0 . 1 1 . 2 0 . 0 VSZ 204 216 260 3924 164 164 3924 260 216 204 VS Z RS S 168 12 44 736 12 12 736 44 12 168 RS S TT v2 TT v2 図 6 カーネル・ファイルシステムのマウント ayanami# mkdir /kern ayanami# mount ¯t kernfs kernfs /kern ayanami# 1s /kern bootfile boottime copyright hostname 10 adavg STAT STARTED 220Ct97 220Ct97 220Ct97 220Ct97 220Ct97 ls 十 ls S I S STAT STARTED ls + ls physmem pageslze TIME COMMAND /usr/local/atalk/etc/atalkd /usr/local/atalk/etc/papd /usr/local/atalk/etc/afpd /usr/local/etc/innd -p4 —iO /usr/libexec/getty Pc ttyv2 0 : 00.01 6 : 21.57 0 : 03.93 0 : 00.33 0 : 15 . 51 (getty) (innd) (afpd) (papd) (atalkd) T IME COMMAND 0 : 00 .00 0 : 00.00 0 : 00.00 0 : 00.00 0 : 00.00 verSIOn time ネル・ファイルシステムを利用すると、通常のファイル操 作だけでこのような幸肋られるようになる。 stackable file system layer 4.4BSD は、前回紹介した VFS や vnode を採用した ことにより、ファイルシステムの実装か容易になった。そ のファイルシステムの及をさらに柔軟にするのが stack ー able file system layer である。これは、モジュール化し た個々のファイルシステムの層を、重ね合わせて利用でき るようにするものである。 たとえば、物理第勺なファイルシステムの前処理として圧 縮をおこなうイ瓦想的なファイルシステムを用意し、 2 つを 重ね合わせて利用することなどが考えられる。 stackable でないファイルシステムの場合は、このような前処理は ファイルシステムごとに用意しなけ川まならない。しかし 4.4BSD の場合は、前処理をおこなうイ瓦想的なファイルシ ステムを 1 っ用意すれば、どの物理ファイルシステムでも 利用することができる。同様に、暙号化をおこなうイ瓦想的 なファイルシステムを用意しておいて、日孫宿の層の上にさ 150 らに重ねるといった組合をも可能である。 4.4BSD では stackable file system layer の実例とし て、以下に挙げるファイルシステムを実装している。 このファイルシステムではおもしろい機能が比較的簡単 に実現できるので、ぜ兆戦してみてほしい。 NULL ファイルシステム NULL ファイルシステムは、既存のファイルシステ ムの任意のディレクトリを任意の場所にマウントでき る。コンフィギュレーション・ファイルのオプション は、、 NULLFS" である。シンポリック・リンクと似ている が、機能を実現しているレベルが違うので生質は異なる。 たとえは、ルート・ディレクトリの変更される anony- mous FTP などのユーザーでも利用することができる。 この例について説明しよう。 ディレクトリ /cdrom にマウントしている CD-ROM の内容を anonymous FTP でアクセスしたいとしよう。 ftp ユーザーのディレクトリが /home/ftp だとすると、 以下のようにシンポリック・リンクを張っても anony- UNIX MAGAZINE 1998.1