特集ドン一ときたら困るけど、ネットワーク卸里・・ 6 monkey: まあ、それも一興。また、戻って働いたらよ ろしいですやん。 sarumata: なにゆうてるんや。それから、マシンごと にちごてるぞ。 monkey: それも個生ちゅうもんで・・ sarumata : 困ったやつやな。時引・がマシンでおうてな かったら、困るんやぞ。ちょっと、なんであかんか考え てみ。 UNIX では多くのツールが、、日該リ " に依存した処理をし ています。 cron は決められた日駭リに指定された処理をお こなってくれるし、 make はソースとオプジェクトの変 ー処刻をくらべます。システムのログにも日骸擶幸師ゞ入っ ているので、、、マシンにいつトラブルが発生したか " を知 ることができます。 時刻は個々のマシンに内蔵される時計によって管理さ れていますが、ネットワーク竟ではマシン間の日該リの誤 差によるトラブルが発生することがあります。たとえは、 ソースファイルを NFS でマウントしていて、オプジェク ト・ファイルをローカルなディスク上に置いている場合、 ローカルな日朸ゞサーバーの日より進んでいると、ソー スに変更があっても make コマンドが認識しない可育旨生 があります。あるいは、あまりに時間カ駐っていると、シ ステムのログを見てもわけが分からない、なんてこともあ ります。 このため、 UNIX ではネットワーク上て嗣該リの同期を とる ( つまり、マシン間の時刻を合わせる ) ツールがい くつか用意されています。ここでは、 rdate 、 timed 、 NTP を紹介します。 rdate rdate には、、、 Sun 独自の rdate" と、、フリー・ソフト ウェアの rdate" があります。オプションなどの細かな遼 いはありますが、いすれも日該リを引数て指定したマシンに 合わせてくれます。たとえば、 sun の rdate の場合、 rdate banana とするだけで、ローカルな時計をマシン banana の日 に合わせてくれます 14 。通常は、 14 フリー・ソフトウェアの rdate では、 UNIX MAGAZINE 1993.11 —S て -す- ・ネットワーク内てマスターとなるマシンを決める ・ほかのマシンは、マスターに対して rdate を実行する という構成にするようです。このため、マスターとなるマ シンの日れ罫飾寉さを求められます。 Sun の /etc/rc. local を見ると、自分がディスクレ ス・マシンであれば、 rdate を実行してサーバーの時刻に 合わせているのが分かります。通常は、 cron から rdate を実行し、 1 日に 1 度だけ日喆 t を合わせることが多いよう ただし、 rdate には、、時刻をいっきに変更する " という 問題点があります。このため、日該リに景グされる処理の最 中に rdate を実行すると、その処理がおかしくなる場合が あります。 また、 rdate では通信にかかる時間までは考慮されてい ないため、これがそのまま誤差となります。ここて紹介す るツールのなかではもっとも手軽ですが、さらにきっちり 時刻を合わせたいときには次に挙げる timed や NTP を 使ったはうか賢明でしよう。 timed timed は、 4.3BSD 系の UNIX に標準で付いてくる ツールで、マシン間の日該リの誤差を数十ミリ秒に保つこと ができます。ソースファイルは FTP で公開されています が、機種によっては利用できない場合があります 15 timed は名前からも分かるように、、、時刻の管理をお こなうデーモン " で、ネットワークてつながれたほかのマ シンの timed と通信をおこないながら日該リを調整します。 ネットワーク上の timed は大きく分けて、 ・マスター timed ・スレーフ・ timed という 2 つの不頁があります。マスター timed はいわ ば、、親玉 " で、スレープの timed はマスターとの通信に よって時刻をします。ゲートウェイ上に timed を仕 掛けることで、独立したネットワークどうしで骸リを同期 させることもできます。 15 timed で一与亥合せに adjtime ( ) というシステムコールを用いてい るため、これを備えていない欟重で ( リ用できません。 35
ロ NFS の運用 sarumata : おお ~ い monkey! わしのプロジェクトの ディレクトリがないぞ ! monkey: おかしいなあ、ちゃんと見ました ? sarumata : どのマシンて、 hostname したらええんや monkey : あれ ? どのマシンで見てます ? たとおり、 /project/X にいったぞ ! sarumata: なにゆうてんるんや。おまえに教えてもう osaru-3 や。 しばらく経って・・ す /project/x て使ってください。 こはひとつ、穏便に。とりあえ monkey : まあまあ、 sarumata : なんやと ! ? /x はなくて、 /project/x ですねん。 monkey : osaru-3 はちょっと子どもなんで、 /project sarumata . イ可カゞや。 monkey : そこですがな。 sarumata : どれや。 monkey: ああ、それや。 monkey: おかしいなあ、ちゃんと見ました ? ディレクトリがないぞ ! sarumata : おお ~ い monkey! わしのプロジェクトの sarumata : ええやないか、あるんやから。 monkey: また違うマシン、つこうて。 osaru- 7 や。 sarumata : どのマシンて、 hostname したらええんか。 monkey : あれ ? どのマシンで見てます ? たとおり、 /project/x にいったぞ ! sarumata: なにゆうてんるんや。おまえに教えてもう 18 monkey: ( ぎくっ . レクトリ、ちょっとすっ違ってるんとちゃうやろな。 して、こらへんにあるマシンのプロジェクト用のディ sarumata . また違うんか、困ったやつやなあ。もしか /project/x はなくて、 /proj/x ですねん。 monkey : osaru-7 は、ちょっと気難しい子なんですう。 sarumata : おまえに言われんでもええ。で、どこや。 monkey: ひととこにしっとしとられへんのですか ! sarumata. もしかして、もしかして、その原因は /etc /fstab にうろ覚えでいいカ成な設定を入れたからとち ゃうやろな ! ? monkey : ( ぎくっ ! ぎくっ ! ) sarumata : なんとかせんかい ! またまた、 monkey 君、怒られてしまいました。 こで、 NFS によるフティルの共有について、 mon- key 君のような失敗をしないようにちょっと考えてみまし よっ。 どうしよう ? NFS を使えば、ネットワークで結ばれた複数の計算機 のあいだで簡単にファイルを共有することカきます。ュ ーザーのホームディレクトリを例に、ちょっと考えてみま しよう。このホームディレクトリを言算機ごとにすべて 別々に置くとすると、 ・各ューサーがあちこちのマシンにあるホームディレクト リを管理しなければならない 管理者は言 t 算機ごとにユーサーを求しなければならな ・ファイルを共有できないので、ディスクがむだになる ことになります。このようなシステムは、ユーザーにとっ ても管理者にとってもきわめて使いにくいものになってし まいます。 また、あるプロジェクトに関係するディレクトリが、特 定の言 t 算機からしか見えない、中途半端な共有になってい るとします。そのようなシステムでは、そのプロジェクト にかかわる作業、たとえは、 ・エデイタを起動してファイルを編集し、コンパイル、実 行する テンヾッグをおこなう プリンタに出力する ・ファイルのバックアップをとる などがすべて、ファイルを共有する計算機でしかできない ことになります。これでは、 ・ CPU の負荷が分散できない ・特定の言 1 算機に専用の周辺装置を接続しなければならな くなる可能性がある UNIX MAGAZINE 1993 ユ 1
足より、瞬速 & 3 グラフィックスを加速する、 Sun 。 ・ーおら 30 ひとりひとりに、 3 次元のカ 2 R な / ん″ ZX microSPARC 、 32M バイト・メイン・メモリ、 1 .05G ノヾイト HDC 19 インチ・カラー・モニタ、ほか各種インターフェース、 S 引 aris ライセンスを含む 標準最小構成価格 : 3 , 590 , 000 円 ( 消費税別 ) ハイエンドマシンの 3D パフォーマンスをテスクトッフで。 SPARCstation ZX シリーズ。 高速 3D グラフィックスは高い。その壁が、多くの企業から競争力を高めるチャ グーロー・シェーティンク、ハードウェアによるイン・アンチェリアシン久テう ンスを奪っていました。 3D グラフィックス・パワーをテスクトッフで使える環境 ス・キューイン久トランスへアレンシー、ファームウェアによる、 URBS 動 へ。 Sun は、性能と価格の常識をまた破りました。 ZX アクセラレータ。 24 ヒット・ダ 分割生成、ステレオなどの先進機能を備え、 MCAD 、 MCAE 、インダスト 1 フルバッファリン久 24 ビット Z パッフアを SPARCstation 10 や LX などの身 アル・デザイン、分子構造モデリング、ビジュアル・シミュレーション、アニメー 近なマシンに装着。 3D で 75 万べクタ / 秒、 31 万トライアングル・メッシュ / 秒という、 ションまで多彩にサホートします 3D 専用マシンの能力をテスクトッフのネヅ このクラス最高速の 3D グラフィックス性能を実現しました。さらに 32 光源までの ワークでひとりひとりの力にするのも、 Sun です 高速の 2D も高度な 3D も、 Sun ならデスクトッフでできる。 RCs 0 〃 G る襯み
Daemons and Dragons 1 台あたり 2 つがよい、という法則がある ( 詳細は、 Stern[2] の NFS に関する項を参照 ) 。 システム いくっかの対策を施せは、システムがうまく機能する ように合理化できる。以下に挙げるプログラムのうち、 いくっかは不要なものかもしれない。わざわざ、そのた めに貴重なコンピュータ資源を使う必要はない。 アカウンティンク記事の後半でアカウンティングを 利用する方法を紹介するが、この情報が不要ならば使 わないほうがよい。 biod このプロセスは、 NFS のファイルシステムを マウントするシステム以外では不要である。ファイル サーバーがほかのマシンからファイルシステムをマウ ントしないのならば、 /etc/rc. 10ca1(SunOS) や /etc/netnfsrc(HP-UX) 、 /etc/rc. nfs(AlX) な どの適当な行をコメントアウトし、 biod を使わない ようにすることができる。 comsat ューサーに新たなメールの到着を知らせる biff サーバーである。、、 bi 仕 n " の実行で、ユーザー とに使用 / 不使用を決めることができる。システム全 体で使わないようにするなら、 /etc/inetd. conf の 該当する行をコメントアウトすればよい。 mountd NFS のファイルサーバー以外では不要なフ ロセスである。 nfsd このデーモンも、 NFS ファイルサーバー以外で は不要である。 quotas ディスクの割当て制限は、誰かから脅されな いかぎり設定しないはうがよい。冗談はさておき、あ なたが大学に勤めていて学生が使うディスク空間を制 限する必要がなけれは、この機能の利用によって性能 を低下させるよりも、このところかなり安くなってき たディスクを買うほうか有意義である。クオータの管 理に時間を費やすくらいなら、ディスクの使用状態を 監視するのに役立つようなスクリプトを書いたはうが rwhod 、 talkd 私は、これらのプロセスはすべての システムで使わないようにするほうがよいと思う。シ ステムの利用に不可欠なものではないし、使って得ら れる利益にくらべてコストが高すぎるからである。 64 カーネル カーネルの設定がシステムの規模に応して描商化され ているかどうか、確かめるべきである。私は、システム を次のように分類している。多数のディスクを接続した 大規模ファイルサーバー、ディスクレスの Sun3 、そし てスタンドアローンの Sun4 などである。次に、カーネ ルを作るために使う適当なマシン群を選ぶ。理由は 2 つ ある。 ・カーネルを作るマシンを選び、カーネル作成に必要な ソフトウェアのインストールをこれらのマシンだけに 限定する。これはディスク空間の節約につながる。 ・カーネルのパッチが特定のマシン群に集中していれ ば、容易に把握できる。カーネルを作るだけならば、 パッチをすべてのシステムにインストールする必要は 必要なテンヾイスだけに対応するようにカーネルを設定 すれば、カーネルのサイズが小さくなって必要なメモリ か減るため、性能が改善できる。このように設定すれは、 いくっかのテープルのサイズを減らして、より効率的な カーネルを作ることができる。図 1 は、 SunOS 4.1.2 のカーネル設定ファイルである。 SCSI バスが 1 つしかなけれは、後半の 8 行のテンヾイ スは利用できないので記述を削除してもよい。 Sun には GENERIC-SMALL というカーネノレの設定ファイノレカゞある が、これならメモリの消費量が少なくてすむ。 カーネルの設定ファイルからエントリを削除するとき は、十分に注意すべきである。私は、一度に削除するの は 1 ~ 2 行にとどめている。この方法なら、何かがうま くいかなくてもすぐに修正できる ( 削除する代わりにコ メントアウトしておけば、簡単に元に戻せる ) 。 システムの監視 トラブルを効率的に解決するためには、日常的なシス テム性能を把握しておかねばならない。システムにと って、どのような状態が正常なのか ? システムの負荷 が、、 2 " だと高すぎるのか、それとも正常なのか ? シス テムやネットワークを定期的に監視し、言算機資源の利 用状況を記録しておくとよい。そうしておけば、トラブ UNIX MAGAZINE 1993.11
図 2 マシン banana の /etc/fstab 0 0 0 0 0 0 0 0 coconut : /home coconut : /prOJ coconut: /usr/local /home /proj /usr/local coconut : /usr/share/man /usr/man nf s nf s nf s nf s rw , hard , intr rw , hard , ro , hard , て 0 , hard , intr intr intr んなあ」 「ふーん、 ディレクトリを automount て管理するときによく使 われます。 直接マップ (direct map) マウントボイントを糸寸パスて指定します。 1 つのマッ プに複数のマウントボイントを記できます。 . マスターマップ (master map) automount が用いるおおもとのマップで、マウントボ イントごとにどのマップファイルを用いるかを指定し ます。 弸妾マップと茁妾マップの違いは、、、相対パス " と、、絶 対パス " の違いだけではありません。間接マップを用いた 場合、マウントボイント以下は automount の支配下に 入り、既存のディレクトリは隠されてしまいます。たとえ ば、さきほどのん s ツ 1 。 cal を間接マッフて管理しよう として /usr をマウントボイントにすると、 automount を起動したとたんに / Ⅱ s ツ 1 。 cal 以外のディレクトリ (/usr/bin や /usr/lib 、 /usr/etc など ) は見えなく なり、アクセス不能になります。ですから、 /usr をマウ ントボイントにして /usr/local を automount て管理 し、 /usr/bin や / us て / 1 土 b などをそのまま使いたいとき には、直接マップに日己しなけれは・なりません。 もう 1 つの違いは、マッフ。の修正がいつデーモンに反 映されるかです。マウントするディレクトリの追加などに よってマップを修正する場合、間接マップであればすぐ にデーモンに反映されます。直接マッフ。の場合は、 auto- mount デーモンを再起動しなければ変更が反映されませ ん。マシンをリプートできれば簡単ですが、周りに仕事を している人がいるとそうもいきません。かといって、 au- tomount デーモンだけを下手に殺して (kill して ) しま うと、マシンの動きがおかしくなることがあります。弸妾 マップが使えるなら、できるだけそちらを設定したはうが よいでしよう。 このように、管理するマウントボイントの状況によっ て、間接マップと直接マップを使い分ける必要がありま す。 22 マップかあ。でも、なんかイメージカヾ勇かへ それでは、 monkey 君のネットワークを例に挙げなが ら、実際の設定を紹介していくことにしましよう。マシン banana をセットアップして、ファイルサーバー coconut のディレクトリをマウントすることにします。マシン ba ー nana の /etc/fstab には、 NFS マウントとして図 2 の ようなエントリがありました。これを automount で管理 してみます。 マップの記述 間接マップ automount における間接マップは、マウントボイント ごとに 1 つのファイルを用意し、エントリを 1 行につき 1 っ書きます。それぞれのエントリは、次のように言己し ます。 ん e リ 0 0 れ loca 0 れ ん e リはマウントボイントから相対パスで示されるディ レクトリ名で、叩。れはマウント・オプション ( 省略 可 ) 、あ c 。。れはマウントするディレクトリの場所をん。 s れ。 me : 四という形式で記述します。さきはどの例で、 /home と /proj を間接マップで管理する場合はそれぞ れ別のファイルに記述しなければなりません。 /home は auto. home 、 /proj は auto ・ proj というファイル名にす ると、 auto. home は次のようになります 7 。 # key monkey OOSaru kozaru J ou— 0 opt ion location coconut : /home/monkey coconut : /home/oosaru coconut : /home/kozaru coconut : /home/jou—o monkey 君の竟では、ホームディレクトリは、 / ome / 社 ~ 07 れ e 7 、 # " て始まる行はコメントとみなされます。 UNIX MAGAZINE 1993.11
Xkernel & Sun3 図 8 ps -aux で rarpd の乍を確認 200 pO S $ ps aux ー grep rarpd root root 130 0 . 0 0 . 0 133 0 . 0 0 . 0 134 0 . 0 0 . 0 131 0.0 0 . 0 36 48 24 24 16 0 0 0 0 ? IW ? IW ? IW ? IW May 1 May 1 May 1 May 1 16 : 21 0 : 01 rarpd -a 0 : 01 rarpd -a ・ 00 rarpd —a 0 : 00 rarpd —a ・ 00 grep rarpd 0 . 0 . sirasaki 15733 0.0 0 . 7 図 9 /tftpboot のシンポリック・リンク $ 1s ー 1 8598500C * lrwxrwxrwx 1 て 00t 1 rwxrwxrwx 1 root 21 Mar 30 14 : 52 8598500C ー > boot . sun3. su Ⅱ os . 4 . 1 . 1 21 Mar 30 14 : 52 8598500C . SUN3 ー > boot . sun3. sunos .4 . 1 . 1 うまく立ち上がらない はどこに間題があるのか見当がつきます。 ROM モニター レス・マシンが立ち上がらないときは、メッセージを見れ X 端末にしようとしているマシン、あるいはディスク EEPROM boot device . . le ( 0 , 16 , 0 ) > b le ( ) の状態から順番に見ていきましよう。 こで止まる場合は、 RARP はうまくいったが、 tftpd Using IP Address 133.152.80.12 = 8598500C で make を実行してみましよう。 は、 NIS サーバー上のファイルを編集してから、 /var/yp はなりません。 /etc/hosts に書いたのに動かないとき マシンのエントリをみつけることができるようにしなけれ ですから、 rarpd が ethers と hosts からディスクレス・ 待ってから RARP 応答を返します ( 理由は彳あ をもっていればすぐに応答し、もっていなければすこし ートイメージ (/tftpboot/boot.sun3.sunos.4.1.1 ) 決定します。そして、自分のホストがクライアントのプ と /etc/hosts を用いてクライアントの IP アドレスを ます。この要求を受け取った rarpd は、 /etc/ethers ernet アドレスを含む RARP 要求をプロードキャストし ディスクレス・クライアントは、ます 48 ビットの Eth- 糸口カ月國めるかもしれません。 か起動しないときは、 rarpd の動き方を理解すれは解決の rarpd が走っているのにディスクレス・クライアント ンドを入力して、 rarpd か動いているか石忍しましよう。 走っていない可能性があります。サーバー上で図 8 のコマ このメッセージからさきに進まない場合は、 rarpd が 114 からの返事がないときです。ディスクレス・クライアント は、 RARP 応答を返してきたマシンをプートサーバーと みなし、そのマシンに tftp 要求を送出します。プートイ メージをもっていない rarpd が、 RARP 応答をすこし 待ってから送出するのはこのためです。プートイメージを もっているサーバーがなんらかの理由 ( 負荷か高い、など ) で RARP 施を出せない場合、ディスクレス・クライア ントはいつまでもプロードキャストを送出し続けます。そ こで、プートイメージをもっていなくても、とりあえす RARP に応えてやるのです。もちろん、この間に合わせ の RARP 応答を受け取ったクライアントは、このサー バーをプートサーバーだと思うのですが、プートイメージ をもっていないサーバーはプートイメージを送ることがで きません。そこで、クライアントはふたたび tftp 要求を プロードキャストするのです。 その要求を受け取るデーモンはⅲ etd により起動される ので、 /etc/inetd. conf に次のエントリがあることが必 要です ( 誌面の都合上、行の途中で折り返しています ) 。 tftp dgram udp wait root /usr/etc/in. tftpd in. tftpd —s /tftpboot inetd により起動された tftpd は、 /tftpboot にある プートイメージを送出します。しかし、プートサ→ヾーは クライアントのカーネル・アーキテクチャを知りません。 分かっているのは、クライアントの IP アドレスだけです。 したがって、 /tftpboot には図 9 のようなシンポリック・ リンクが必要です。 8598500C と 8598500C. SUN3 の 2 つのエントリカゞあ るのは、 tftpd のバージョンの違いを吸収するためです。 booting from tftp server at 133.152.80.1 こで起動時にお馴染みの、、ぐるぐる " が表示され、 UNIX MAGAZINE 1993.11
Xkernel & Sun3 表 1 xbench の実行結果 ( 単位 : vector/s) 改造後 テスト名 己気造月リ line10 24 , 268.80 25 , 036.80 ⅱ ne100 10 , 752.00 11 , 904.00 1ine400 4 , 454.40 3 , 916.80 dline10 9 , 676.80 9 , 146.18 dline100 3 , 686.40 3 , 532.80 dline400 1 , 117.09 1 , 088.00 wline 10 1 , 885.09 1 , 996.80 wline100 708.92 704.00 wline400 256.00 240.00 部を表 1 に示します。直にあまりこだわらすに、 っとよくなってるな " というくらいに捉えてください ( そ もそも、完璧なテスト竟で実行したものではありません 図 1 UNIX の 1 プロセスであるときの X とカーネルの系 び び し コンテクスト・スイッチ KERNEL (pr«x:ess) 図 2 Xkernel でカーネルと X の系か 3 色車云 つ小 0 0 Xkernel 0 0 KERNEL X 端末化の仕組み さて、 X だけか動く Sun3 はいったいどのような仕組 みで実現されているのでしようか。 UNIX のネットワー ク・プートの過程から、順番にみていきましよう。 ROM モニターのプロンプトが出ている状態でネット ワークから立ち上げるには、次のコマンドを入力します。 > b le ( ) UNIX の 1 プロセスであるときの X とカーネルの関係 は図 1 、 Xkernel によってこの関係が逆転すると図 2 のよ うになります。 したごしらえ le は Ethernet カードのデバイス名で、 ie となって Sun3 を X 端末にする前に必要な竹喋をおこないます。 いるものもあります。周りの人に訊くなりマニュアルを読 X 端末にする Sun3 用にカーネルを叫冓築しなければ むなりして、確認しましよう。もっとも、 2 つに 1 つで ならないので、 Sun3 をディスクレスとして立ち上げます。 すし、間違えれば工ラーメッセージカ咄るので、失敗は 1 X 端末にする Sun3 と同しカーネル・アーキテクチャの 回ですむはずです。 マシンがもう 1 台あれば、そのマシンでカーネルを作れば ネットワーク・プートを指定されたマシンは rarpd に よいでしよう。その場合は、次の節に進んでください。 自分の IP アドレスを教えられ、 tftpd からプートイメー ところで、この Sun3 のカーネル・アーキテクチャは何 ジ ( プーター ) を受け取ります。そして、プーターがルー でしよう ? そもそもカーネル・アーキテクチャとは ? とい ト・ファイルシステムをマウントし、 UNIX が立ち上が う人は、先輩に訊いてください。 Sun3 のカーネル・アー ります。このときの vmun ⅸは X さえ動けはよいのです キテクチャは、表 2 のようになっています ( 以降では、マ から、 SCSI などのデバイスドライバは不要です。ディス シンを指すときは、、 Sun3 " と記し、カーネル・アーキテク プレイとキーポード、マウス、 Ethernet カードが制御で チャは、、 sun3 " のように表記します ) 。 きるだけで十分なのです。次に、 /etc/fstab を読んで NFS マウントを実行すると、本来ならばⅲ it プロセスが こで、マシン構成を定義しておきましよう俵 3 ) 。 立ち上がります。しかし、この XkerneI では、 init は X kotengu が今回 X 端末にする Sun3 です。これに、ディ を起動する準備をして、 X を立ち上げるだけのシェル・ス スクレスの異機種サーバーとなる tengu 、 CD-ROM デ クリプトです。 バイスを接続した ootengu の 3 台でイ乍業をおこないます。 109 UNIX MAGAZINE 1993.11
特集ドン一ときたら困るけど、ネットワーク卸里・・ 6 など、なにかと不便なことか起こりかねません。つまり、 どのようなファイルシステムにするかによって、ファイ ルシステム自体だけでなくはかのさまざまな計算機資源の 有俐用にも大きな景些をおよはすのです。 使いやすくするには、 「どの計算機からもファイルシステムが同じ構成に見え というのか理想でしよう。 つまり、さきはどの sarumata さんのように、ある引算 機では /project/x で、別の計算機では /proj/x 、また また別の引・算機では共有していないなどということになっ ていると、とても不便です。 どの計算機からもファイルシステムか祠し構成に見える ようになっていると、 やや乱暴な言い方かもしれませんが、 NFS 共有につい を共有すればよいのかについて考えてみます。 はよいのでしようか。具イ勺に、何が共有できるのか、何 見えるという目標を挙げましたが、そのためにはどうすれ さて、どの計算機からもファイルシステムか伺じ構成に 何を賄するか ていなければなりません。これは、 NIS を用いて実現できます。 は、ネットワーク全体でユーザー ID とグループ ID カ充一され ルシステムカ祠じ構成に見えるようにファイルを共有するために 等しくなけれは不都合か起こります。すべてのマシンからファイ イアントのあいだで、各ューサーのユーサー ID 、グループ ID が NFS でファイルを共有する場合、 NFS サーバーと NFS クラ NIS と NFS 滋意 1 あるので、この方針に固執することはありません。 クセスは特定のマシンだけという設定が必要になる場合も もちろん、管 E の都合で、特定のディレクトリへのア などの利点があります。 ・管理者は言算機ごとに異なる管理をしなくてもよい 荷う靖攵か図れる ・特定の計算機にユーザーが集中しないので、 CPU の負 ・ユーサーはどの計算機も同しように利用できる UNIX MAGAZINE 1993.11 ・共有できないもの以外はすべて共有できる。 ての基本原則は次の 2 つです。 共有できるものはすべて共有してよい。 できないもの これには、次のものカ考えられます。 1. スタンドアローンでの動作に必要なもの 2. 各計算機に固有の設定に里するファイル 19 のちょい " で終る作業も、 10 台あるいはそれ以 - ヒになる ます。というのは、マシンか嗷台のあいだは、、ちょちょい の実現は、マシンの増加に比例してだんだんと難しくなり 「どの計算機からもファイルシステムが同じ構成に見え monkey 君の言うとおり、初めに挙げた方針、 やで」 けど、どないしたらええんやろ ? それにめんどくさそう 「方針は立派やし、共有はしたほうがええに決まってる マウントおまかせデーモン 上共有してはいけない場合もあるので注意が必要です。 ないイ督はみになっていたり、ライセンス ( 使用本の契約 ただし、アプリケーションによっては NFS で共有でき 共有するようにします。 リケーションなどについても同様で、できるだけ NFS で 量の節約にもなります。オプション・ソフトウェアやアプ 間が大変なことになってしまいます。これは、ディスク容 のインストールやバージョンアップなどにかかる管理の手 で共有するようにします。共有しないと、新しいコマンド ラムについても、共通に重川乍する計算機のあいだで NFS 算機や、 OS バージョンでしか動かないバイナリ・プログ 題なく NFS で共有できます。特定のアーキテクチャの計 シェル・スクリプトなどによるコマンドは、もちろん間 ことになります。 上に挙げた以外のものは NFS で共有してもかまわない できるもの 異なりますから共有してもかえって管理を複雑にするだけ ものを参照することは可能ですが、言 - 巐によって内容が ばならす、共有することはできません。 2 も、 NFS 上の 1 についてはかならすローカルな引・算機ーヒに置かなけれ
Xkernel & Sun3 表 2 Sun3 のカーネル・アーキテクチャ システムモデノレ 3 / 50 、 3 / 60 、 3 / 75 、 3 / 110 、 3 / 140 、 3 / 150 、 3 / 80 、 3 / 460 、 3 / 470 、 3 / 480 3 / 160 、 3 / 180 、 3 / 260 、 3 / 280 カーネル・アーキテクチャ sun3 表 3 マシン ホスト名 ( 彳難リ ) kotengu (X 端末 ) tengu ( 異機種サーバー ) ootengu (CD-ROM を利用 ) SOFTWARE FORM 図 3 add -services の実行 カーネル・アーキテクチャ sun3 sun4C sun3x IP アドレス 133.152.80.10 133.152.80.1 133.152.80.2 Et hernet アドレス 8 : 0 : 20 : 1 : ca : a7 [?=help] [DEL=erase one char] [RET=end of input data] Software Architecture Operations [edit existing release] x [add new release] Architecture types [sun4c. sunos .4 . 1 . 3 ] Media lnformation Media Device Media Location Mediahost CstO] [stl] [st2] [ 10Ca1 ] x [remote] ootengu [st-] [xtO] [mtO] [fd0] x CsrO] 133. 152.80.2 Mediahost ) s lnternet Address Ok to use these values to read the table 0f contents [y/n] ? ← y と答える 図 4 カーネル・アーキテクチャ尺 ARCHITECTURE FORM P1ease Se1ect An Architecture [sun4c . sunos . 4 . 1 . 1 ] Csun4. sunos .4.1.1 ] [sun3x . sunos . 4 . 1 . 1 ] + [sun3. sunos .4.1.1 ] [exit architecture menu] これを選ぶ 次はこれ ←ます、 [?=help] ls this ok? [y/n] ← y と答える You have the sunos 4 . 1 . 1 sun3 media loaded . add-services による追加インスト ーノレ カーネル・アーキテクチャが sun3 のマシンが 1 台しか ない場合は、ほかのマシン (tengu) に異機種サーバーとな ってもらわなければなりません。そのためには、 tengu 上 で /usr/etc/install/add-services を実行し、サー バーになるために必要なファイルをインストールします。 こでは SunOS の CD-ROM があり、 CD-ROM テンヾ イスは ootengu に接続されているので、図 3 のように入 力します。入力はスペースを押してエントリを選び、 x を 110 入力して確定します。 テープを利用するときは stx を選びます。 次に、図 4 の画面でアーキテクチャを選択します。 図 5 の画面の Choice では、。 0 土 ce を選択し ます。 Executab1es path は、デフォルトで /export/ exec/sun3. sunos. 4.1.1 か表小されますが、 /export に十分な空き領域がなければ /usr/local/export でもかまいません。 次に何をインストールするのかお尺する画面になりま UNIX MAGAZINE 1993 ユ 1
図 10 NTP の階層橢告 ロードキャスト受信モード " で動かしておけば、設定も簡 単です。私たちの研究室もそうですが、末端のサイトでは このガ去を使っていることが多いようです。 NTP のパッケージは国内の FTP サイトにも置かれて います。入手可能な方はコンパイルにチャレンジしてみて はいかがでしよう。、マシンの日お 1 ガ遅れてたから " なん て言い訳をしなくてもよいように UTC stratum 1 stratu m 2 ☆ stratum 3 第ィを、 . プロードキャスト 以上、 rdate 、 timed 、 NTP について簡単に紹介しま した。もっと詳しい使い方や設定方法などを知りたい方 は、オンライン・マニュアルの rdate(8C) や、「 UNIX timed 、 NTP 」 ( 山口英、 Communicati011 Notes UNIX MAGAZINE 1992 年 1 ~ 2 月号 ) などが参考に なります。 、あるネットワーク . ・ NTP NTP(Network Time ProtocoI) はフリー・ソフト ウェアであり、現在もっとも注目されている、、日駭リ管理 " ツールです。 NTP はその名のとおり、、ネットワーク上で 今回はファイルに関係する話題を集めてみました。さま 日該リを管理するためのプロトコルで、実際は xntpd ざまなマシンでファイルを共有するときには、その方法や と呼はれるサーバーか処理をします。 イ督はみなどはあらかしめちゃんと考えておいたほうがよい xntpd も timed と同様にサーバーどうしが通信をおこ でしよう。また、時刻の問題は関係なさそうで、しつは重 ないますが、階層的な構造を作るように言 t されています 要な問題です。終電に乗り遅れないようにするためにも、 ( 図 10 ) 。階層は、、 stratum" と呼は舸立のサーバーが 時刻はきちんと合わせておきましよう。 1 つ上位のサーバーに日該呼情報を問い合わせます。複数の それから、どんなシステム管理の参考書にも注意されて サーバーに問い合わせてもっとも精度のよいものを選ぶこ いるように ( もちろんこの特集でも今回とりあげました ) ともできます。 ちゃんとバックアップはとりましよう。 ・最」 :. イ立の stratum 1 のサーノヾーは、 UTC (Univer- ( おかやま・きよひこ、かたやま・よしあき躑反大学 sal Time Coordinated: 協定世界啣と同期しています。 さかした・しゅう ASTEC) UTC は、よ厩 ) 自転をもとに定められている UT1(Uni- versal Time 1 : 世界時 ) の時刻との差をつねに一疋範囲 内に保つように管理されている人工的な日係です。私た ちに似合わない難しい言葉で定義してしまいましたが、簡 単にいえば、、世界の標準となる時言 t " です。 NTP では通 信にかかる時間も考慮されるため、精度のよい日該リを得る ことが可能です。 xntpd は、、プロードキャスト・モード " で動かすこと もできます。上位のサーバーとの通信で得られた時劾辭長 を、ネットワーク内にプロードキャストします。このた め、ネットワーク内のはかのマシンでは、 xntpd を、、プ 16 プロトコルのム斤バージョンは Version3 ですが、夫陽 ) 運用は Ver- sion2 でおこなわれています。 16 " 36 UNIX MAGAZINE 1993 ユ 1