NFS & NIS (NUTSHELL HANDBOOKS) [プログラミング]
1992年に発行されたNFSとNISの解説本。
今ではかわっているところもある。
大型コンピュータを何百人のユーザーが使用していた時代が終わり、ローカルエリアネットワークが使われだして10年。
ネットワークによる分散処理が普通になり、ファイルサーバー、計算サーバー、プリントサーバーといった専用システムを介して計
算機資源を共有する時代。
分散処理環境下では使いやすく有機的なネットワーク構築ができる反面、管理が複雑になる。
ネットワーク上の各マシンにすべてのファイルとコンフィギュレーション情報を一貫性をもって提供することが必要で、
それを意識しないで利用できる仕組みがNetwork File System(NFS) と Network Infoation service(NIS）
どちらもSun Microsystemsが開発したプロトコル。
NISを利用するとパスワードファイルなどの同一の内容を複製して維持すべきコンフィギュレーションファイルを、1台のホストで集
中管理できる。更新もホストのみですむ。
NFSを利用すると、ネットワークを意識しないで、リモートファイルシステムを使用できる。
すべてのマシンで１つのファイルセットを共有できるので、そのセットのための物理的なスペースがネットワーク上のどこか1か所にあ
ればいい。
NFSはファイルシステムの物理的な保管場所を意識しないで、ネットワーク上でファイルシステムを自由に使用できる仕組みだが
、ユーザー情報グループ情報がまちがっているとアクセスできない。
NISでサービスすることで、どのワークステーションからでもそれが自分のグループのものであれば、自分のホームディレクトリにログイ
ンできて、資源を利用できる。
またコンフィギュレーションやディスク資源を一括管理できることはシステム管理者にもありがたい。
NFSをつかえばなんでもかんでも手に入るが、それよりは簡潔なネットワーク構成を考えること。
必要なファイルやユーザアカウント情報、システムサービスに”だけ”アクセスできる簡潔さは、多くの利用者を扱い、システム管理
者の労力を軽減する役にたつ。
対象読者
NISやNFSを使用しているシステム管理者ネットワーク管理者。
これから導入を検討している人。
UNIXのシステム管理やTCP/IPネットワーキングの基礎知識がある人。
目的
NFSやNISを使用して分散処理環境下でしばしば遭遇する問題の解決方法を紹介すること。
個々のベンダーのユーティリティーなどにはふれない。
対象バージョン
SunOS4.1 NFSとNISの実装に準拠。SunOS4.0でもあてはまる。
PC/NFS3.5準拠
第1章から9章
NFSとNISの実装と操作の解説
第1章 ネットワーキングの概要
NIS・・・共通コンフィギュレーションファイルを分散データベース化してNISが管理する。NISクライアントはローカルなコピーを使
用しないでNISサーバーに要求する。
NFS・・・分散ファイルシステム、NFSクライアントはNFSサーバにあるファイルシステムをマウントしてローカルディスクのように使う
。
ISOの7階層モデル
層７ アプリケーション NFSおよびNIS
層６ プレゼンテーション XDR 異質なネットワークで有効。
層5 セッション RPC ネットワーク接続の設定と維持の定義
層4 トランスポート TCPまたはUDP ネットワーク層にあわせてデータ分割。着信の信頼性を確保。ポート番号
層3 ネットワーク IP データフォーマットの互換性をとる。データグラム。 IPアドレス
層2 データ・リンク ネットワークのデータフォーマットが定義される 「パケット」 MACアドレス
層1 物理 イーサネット
下位層のレベルが正常に動いているのが前提でNFSとNISは動作する。
IPアドレスの予約番号
０・・・ネットワーク番号を作成するためにプレースホルダーとして使用される。またIPブロードキャストアドレスとして使用される
ことがある。
１２７・・・ホストのループバックインターフェースに使用される。
２５５・・・IPブロードキャストアドレスに使用。
RPC・・・リモートプロシージャコール。ローカルシステム内で処理されるように見せながら実際にはネットワーク上の別のマシンで
プロシージャ・コールを実行する仕組み。
XDR・・・カノニカル形式と呼ばれる固定ネットワーク・バイトおーだリングに基づいて構築されている。個々のマシンの特異性と
は無関係に構造体データ（バイトストリームと対比した場合）の受け渡しが簡単にできる。
コネクションレスサービス・・・接続時間の長いconnectionをクライアントサーバーで生成する必要がない。
RPCはコネクションレスサービス。要求を送信し、応答を受信するためにサーバーと交信するが、そのための接続手続きは必要
ない。RPCサーバーはブートプロセス時に起動され、シングルスレッドで実行される。２つたてられることもあるが、sの場合要求は
待ち行列に入る。ポートやスーパーサーバは使わず、etc/rpcのサービス番号が指定されている。RPCプログラム番号からポート
番号へのマッピングには、ポートマッパデーモンを使用する。よってクライアントからのRPC呼出にはポートマッパデーモンが走ってい
る必要がある。
第2章 ネットワーク・インフォメーション サービス機能
ＮＩＳを使って分散型コンピュータ環境で、共通コンフィギュレーションのファイルを個々のマシンで持たず、一括で管理することで
、大規模なネットワークでも一貫性を確保できる。管理するのはパスワードファイルやグループファイル、ホストファイルといった、共
通するもので、ホスト固有の情報を含むもの etc/ftab などは含まない。
２．１マスター、スレーブ、およびクライアント
ＮＩＳはクライアント・サーバーモデルで構築されている。
ＮＩＳサーバーはマップと呼ばれるＮＩＳデータファイルをもつホストのことで、クライアントはこれらのマップにデータを要求するホス
トである。
ＮＩＳの一つのマシンだけがマスターとなり実体＝ＮＩＳマップをもち、それがスレーブ・サーバーにコピーされ、ＮＩＳクライアントは
自分のローカルファイルでなく、ＮＩＳのマップをみにいく。変更はマスタだけで行う。扱うマップはドメインと考えられる。
マップごとにドメインをつくることができる。各マシンはディフォルトドメインがあり、参照するＮＩＳマップが特定されている。小規模
ネットワークでは通常ドメインは一つである。
２．２ＮＩＳ管理の基本
ＮＩＳの動かし方。ＮＩＳサーバーを設定して、クライアント・ホスト上でＮＩＳが稼働するようにすること。
NISサーバーは可用性と要求処理能力が十分なものを選ぶ。サーバーからの応答がおそければクライアントはスレーブ・サー
バーを探す。各マスターサーバーにはすくなくとも一つスレーブ・サーバーをもたせたほうがいい。スレーブ・サーバーとのマップファイル
の同期も重要。
サーバー作業
・新規のＮＩＳ環境をインストールし、マスターおよびスレーブ・サーバーを構築する。
・システムをＮＩＳのサーバーとして働かせるypserveデーモンを起動
・ネットワークの規模が拡大したりＮＩＳの性能向上のためサーバーの処理能力がさらに必要になった際に、新規のスレー
ブ・サーバーを追加する。
クライアント作業
・クライアントの管理ファイルを修正し、クライアントがＮＩＳを利用できるようにする
・ypbindデーモンを起動し、クライアントがNISに要求を送出できるようにする。
マスター・サーバーの設定説明。
NISで管理されるファイル（UNIX標準ファイルの他に/etc/netgroup）
インストール方法は、まずドメイン名を決めて、/etc/passwordファイルに+::0:0::が無いのを確認して、初期化コマンド
（/uer/etc/yp/ypinit -m）実行。ドメインにマスターは一つだけ。NISサービスを起動(ypserve）。普通サービス起動はドメイン
名が設定されているば行われるようにrc.localに書いてある。
スレーブ・サーバーの設定説明
初期化コマンド（/uer/etc/yp/ypinit -s NISマスターサーバー名）実行。
自動でマスター・サーバーからマップファイルをコピーする。
スレーブ・サーバーはマスタのypserversマップに追加される。ypcatでダンプして追加する。
クライアント・ホストの設定説明
クライアント上のコンフィギュレーションファイルにNIS「マーカ」のエントリ（/etc/password や /etc/groupのLではじまる
行）が必ず含まれているのを確認。これがないとNISマップ情報をローカルファイルに組み込めない。
domainnameユーティリティでクライアント上のNISドメイン名を設定する。
NISサーバを決定しドメイン名からサーバーをさがし、バインドを行うypbindデーモン起動。
NISが動いて、もローカルのコンフィギュレーションファイルが参照されなくなっても、は消さない方が良い。単体でたちあがれ
なくなるので。特に/etc/hostはNISが動きだすまでに必要なので消してはいけない。
NISサーバーをクライアントとしても動作させるのは、やったほうがいいといっていた。
ただし、セキュリティが弱くなるので別のパスワードファイルを使うなどの対策をとった方がいいといっていた。
２．３NISにおけるファイルの管理
NISで管理されているファイル中でとくに共通性の高いもののリスト。マップ名、ニックネーム、アクセス方法（検索キー）、内
容（ファイル名） マップの利用形式（追加、置換など、ローカルファイルに対する操作）の順にのっていた。マップとファイルは1対1
ではない。
netgroupはNIS管理のための新規のデータベース。/etc/groupとは異なり、記述の簡略化やニックネームを作成するため
の仕組み。
NISマップとローカルファイルの統合。NISマップのオーバライド。
＋記号を使うとNISマップまたはマップの一部をNISにより補てんされるファイルに組み込むことができる。passwordファイルな
どで説明していた。
２．４ NISの設計と実装
NISはRPCプロトコル上に構築され、クライアント・ホストからサーバーへの要求転送にはUDPトランスポートを使用している
。NISサービスは標準UNIXライブラリコールに組み込まれている。例えば/etc/paswordを読み込むのに使われるのは既存の
getpwuid()である。そのためNISを使用するために既存のソフトウェアを変更する必要はいっさいない。
マップファイル
DBMデータベースファイル（UNIXに実装されたもの）で構成されている。
キーワードと値の組み合わせのテーブルをもち、高速検索する。
マップ構成や名前、DMSデータベースの生成方法などが解説されていた。
NISドメイン・・・同一セットのマップを使用するホストのグループ。ドメインに属するすべてのマシンはパスワードファイル、ホス
トファイル、およびグループファイルに関して同じ情報を共有する。
ホストが属するデフォルトドメイン名を設定するにはdomainnameコマンドを使う。
Internetドメイン・・Internetworkネームサービスにより管理されているホスト・グループを指す。共通の管理下におかれたホ
ストのグループとして厳密に定義されている。
ypservデーモンが起動していればNISサーバである。このデーモンが要求を処理する仕組みを解説。
ypbindデーモンが起動していればNISクライアント 。クライアントプロセスとサーバをバインドする、あとはサーバとやりとりしな
い。
NISサーバとクライアントのイベントシーケンスをgetpwuid()ライブラリコールを例に説明。ローカルでみつからないとNISを使用
して探す。まずypbindがサーバ情報を返し、NISサーバーに要求をおくるとｙｐservが処理して返す。タイムアウトが発生すると
ypbindが以前つないでいたサーバ情報をつかって再接続をこころみる。何回か失敗すると他のサーバを探す。
NISを使用しているマシンは、NISとのバインドが切れるとほとんど使えない。信頼性のなるNISサービスが必要である。
３章 NISを用いたシステム管理
NISを使っても、マップ参照の負荷や、NISのメンテナンスツールの負荷で、ユーザの通常の作業を邪魔しないようにしなけ
ればならない。
NISドメインをいくつ使用するかは、計算機資源をどのように分割したいかによる。よく使われるのは管理用のドメインとネッ
トワーク用のドメインの２つに分割する方法。
上記の判断基準は
・独自のネットワークを持つ分離されたグループのために別個のドメインを用意する。
・独自のシステム管理者を持つシステムのグループには、各グループごとに別個のNISドメインを用意する。
ただし、特定のマシンへのアクセスを一部のユーザに与える為の手段としてNISドメインを確保してはならない。特定の分割
グループを作成するための最善策はネットグループを使用してドメインの部分集合を作成する方法。
ドメイン名のつけ方例、ユニークであれば制約がないが、例として階層的な名前などをあげていた。
NIS要求を延々と生成するタイプの作業はまれなので、NISドメインに能力が同等のクライアントとサーバがあるなら、クライ
アント３０-４０にサーバ一つくらいが目安になる。もちろんブリッジされているなどの状況によって変わる。
マップファイルの管理は、マスターでmakefileとNISのMakefileを利用してスレーブに送りつける（PUSHする）方法と、ypxfrを
使用してスレーブ・サーバからマップを取り出す（PULLする）方法がある。
他にcronを使ってypxfrの機能を使って、定期的にマップを転送するようにすべき。
恒久的な変更はマスターで行わないとできない。スレーブを変更しても上書きされる。
管理者が複数いてマスタの変更を同時に加えて矛盾が発生しないように、、SCCSまたはRCCを利用する。
パスワードファイルの更新を例にマップの管理を説明。
SCCSでの管理方法を説明。
標準以外のマップ作成方法を、/etc/password 意外のファイルからパスワードマップを生成する例で説明。
NISサーバ管理
プリンタスプーラの変更など、サーバを移動させるような場合の記述がマニュアルにないらしい。
スレーブサーバの移動方法・・・そのマシンのホスト名をypserverマップから取り除き、そのマシンの上のNISを止める。
マスターサーバの移動・・・新規にマスターにするマシンにスレーブをたちあげる。ここで新しいマスターの構成の新規マップを
作成。これをマスターにypxfrで吸い上げる。これをすべてのマシンに配布。元マスターをNISサービスからはずす場合はypservers
からはずす。
マルチドメイン・・・単一のサーバーが複数のマスターのスレーブになっているとか、マスターでありながら、他のマスターのスレ
ーブだとか。
ypserversマップでドメインごとに設定される。例として、host,alias,rpc,servicesは共有しながら、異なるpasswordと
groupをもつマルチドメイン構成があげられていた。
NISとDNS
DNSの利点は、名前管理が分散されること。自分の管理下の名前をどう変更しようとも、中央に通知する必要がな
い。もちろん同じ名前がついていても区別される。
NISをDNSの最下位構造に組み込むことができる。いくつかのネットワークがDNSドメイン内に存在し、複数のシステム
管理者により管理されている＝NIS
NISとDNSの統合方法
・NISをDNS抜きで走らせる＝ディフォルト
・NISマップを参照して解決できない時にはDNS使用する。NISのhost関連のマップを-bフラグをいれて生成する。
・ホスト名についてはNISを無視してDNSを使用する。ホスト名を検索するライブラリルーチンを再構築してNISのラ
イブラリコールを取り除く必要がある。
NISとDNSを同時に使うときはNISのドメイン名とDNSのドメイン名を対応させる。DNSドメイン名.NISドメイン名にして
おくとよい。
第4章 ＮＩＳを使用したアプリケーション
ＮＩＳを利用したカスタムアプリケーション。
方法は３つ
１．ypmachやypcatなどのNISクライアントツールを利用する方法。
例としてASCIIファイルをNISファイルに変化し、電話番号のNISマップを参照する。
２．NIS固有のツールを使い、rdistなどのUNIXのユーティリティ機能を拡張したりエミュレートしたりする。
コンフィギュレーションファイルからクライアントが必要な情報を取り出す方法。
rdistとgrepの機能を合わせたようなホスト固有の集中管理をつくる。
３．NISクライアント・ライブラリを使い、CプログラムからNISドメインのすべてのマップにアクセスする方法。
NISのライブラリコールの紹介。例としてSunが寄付で作っている株価情報サービスで、寄付者のNISマップとユーザー名
を照合するプログラムをあげていた。
第5章 NFSを用いたシステム管理
Network File System(NFS)は、分散型ファイルシステム。
NISがユーザやホスト情報を集中管理できるように、NFSはいくつものディスクを集中管理できる。
/user/localのような共通ディレクトリを全システム上に重複してコピーするかわりに、NFSでは１つのコピーを1か所に保管す
る。
NFSを利用することによって、ホストはリモートとローカルの区別なくファイルを利用できる。
NISとNFSはいっしょに利用されることが多い
NFSもRPCプロトコル上に構築されている。ホスト間にはクライアント・サーバー関係が成り立つ。
NFSサーバーは１つまたは複数のファイルシステムを持ち、ネットワーク上の各ホストに対しそれらのファイルシステムを利用可
能にするホストのこと
NFSクライアントは、１つまたは複数のサーバーからファイルシステムをマウントするホスト。
NFSの資源は、すべてのクライアントによって共有されるサーバー上の物理的んディスクドライブのこと。
NFSを介してシステムを管理するには、ファイルシステムの名前付けとマウントの枠組みを考える必要がある。
枠組みが決定したら、それにあわせてサーバーとクライアントをどのように配置するか考えなければならい。
名前付け規則はネットワーク自体の存在を意識せずに、ネットワークから利用できるようなものにするのが目標。
ユーザーがNFS自体の存在を意識しないのがよい状態。
何百台ものクライアントがつくと複雑で手に負えなくなりがち、上手に管理するには標準的な手順に若干の知性を加味す
る必要がある。ネットワークの一貫性を維持するコストが大きな管理オーバーヘッドとなってはならない。管理ツールオートマウンタ
などを使う。
NFSの設定
クライアントとサーバーでNFSを設定するにはNFSRPCプロトコルのデーモン、ファイルロッキングなどの補助的サービスのデー
モンをを起動。その後NFSサーバーからファイルシステムを公開（export）し、クライアント上でマウント。
クライアントでNFSを使用するには、biod rpc.lockd rpc.statdデーモンを起動(ブート起動が一般的）
ネットワークに公開されるファイルシステムを持つホストがNFSサーバー。
サーバーは現在公開しているファイルシステムとファイルシステムのアクセス制約情報をファイルテーブルとしてもち、NFSマウン
トの要求があればｍ要求されたファイルシステムをテーブルに登録されているエントリと比較する。
サーバーはブート時に/etc/exporttsの存在をチェックして実行。その後nfsd epc.mountdのデーモンを起動。
公開の法則と、オプションを解説。
NFSクライアントはNFSサーバーが公開したファイルシステムであれば、どのようなものでも、一部でもマウントできる。
方法は/etc/fstabファイルに登録するか、mount(8)コマンドを使用する。
両方の方法の詳細を解説。
マウントは普通すべてhardで行われ、タイムアウトしてしまったRPCはサーバーが応答するまで再実行される。
マウントでよく起こるエラーメッセージの解説。RPCが何回もタイムアウトしていたり、別のクライアントにファイルが削除された
りする事態が想定できる。
NFSにおけるシンボリックリンクの解釈。サーバーで解決されて返されたパス名が、クライアントのファイルシステムの範囲外の
場合エラーになる。相対的シンボリックリンクは、クライアントのファイルシステム上のリンクが置かれた位置から解釈され、サーバー
上のファイルシステムでは解釈されない。マウントしようとしたサーバー上のファイルシステムがシンボリックりんくだった場合奇妙なこ
とがおこるかもしれない。
名前付け規則
簡潔で効率的な方法で名前が管理されているファイルシステムは使い勝手がよい。そのための規則
・ユーザのホームディレクトリは/home/hostnameを使用する。
・各ユーザのホームディレクトリのマウントで/home/homenameでなく/home/usernameを利用する方法がある。こ
の方法だと/etc/fstabが大きくなるが、NFSオートマウンタを使用しているなら、この方が楽
・クライアントとサーバーの双方で同一のパス名を使用すること。
・システムの拡張性を念頭に入れておく。例サードパーティのプログラム用のシステムファイルを１つ用意する。
多機能ワークステーションで構成されているネットワークで/user/local/binに適切な実行ファイルだけを置く方法とし
て、個々のバイナリディレクトリに名にマシンの型を拡張子とつける方法を紹介。
各ユーザのホームディレクトリを指しているシンボリックリンクを/uというNFSファイルシステムにおいて、たとえホスト名がパ
ス中にあったとしても、ホームディレクトリやプロジェクトディレクトリを容易に見つけられる方法を解説。
6章 NFSの仕組み
NFSは実装上の設計や仕組みを知らなくてもインストールして使うことができる。しかし、動作不良や性能低下がおこったとき(
実際よくおこる）動作の仕組みをしらないと対処できない。
透過性のレベル
１ NFSがファイルの位置を隠ぺいしすべてのファイルがローカルであるようにみえる
２ ファイルシステム間のアーキティクチャの違いを隠ぺいする。
VFSで１を、v-nodeで２を実現している。
VFS・・・ファイルインターフェースのスイッチボード。
VFSオペレーションス・・・ファイルシステムの空き容量を調べるなど、全体に対する操作を行う・
V-nodeオペレーション・・・ファイルやディレクトに対する操作。
オブジェクトを指定する仕組み・・・UNIXは拡張子でおこなっているが、NFSはファイルハンドルで行っている。
NFSはPRCプロトコル型の通信なので、クライアントとサーバーが存在する。
NFSサーバー側ではnfsdデーモンがクライアントからのRPC要求を受け取る。
NFSサーバーがマウント要求を処理するために、パス名変換用のrc.mountdデーモンを起動する
biodデーモンはNFSの性能向上のためで、必須ではない。
クライアントからみるとread()やwrite()をしているだけで、NFSはこれらのシステムコールの拡張にすぎない。
NFSのRPCプロシージャは１６個。UNIXのシステムコールがどのようにマップされるかという視点で解説。
NFSのプロトコルはUDP（状態をもたないので、パケットの到着や到着順を保証しない）である。
このため、クライアントからのNFS要求はすべての情報を持つ必要がある。ファイルに書き込むなら、ファイルファンドル、オフセッ
ト、書き込みブロック数が必要。ここがwrite()システムコールとは異なる。
idempotentであり、同じ操作をなんど繰り返して要求しても有害な副作用は発生しない。NFSサーバーは最近の要求を履
歴して、同じ操作をよける処理をおこなっている。
ステートレスなので、サーバーやクライアントどちらがクラッシュしてもリブートすれば何事もなかったかのようにNFSが利用できる。
ここがデータベースなどと違うところ。
RPC要求はクライアントからサーバーに同時に１つずつ送出される。このときタイムアウトをつけており、タイムアウトになると再送
する。これを繰り返す。クラッシュなのか過負荷なのかの判別はしない。
サーバーは到着順にRPCを処理する。
サーバーがRPC要求の履歴を保持する期間は短めに設定されている。
NFSではVFSの定義によってすべてのファイルシステムにおいて同一のセマンティクスを保証している。
VFSを使ってファイルシステムを非UNIXセマンティクスとして実装することも簡単にできる。
オープンしているファイルが削除(remove)された場合の、NFSクライアントはrenameNFS要求をだして、一時.nfs.XXXX
というファイルをつくり、close(）されてから削除するという手順で対応する。
ファイルのパス名は下からLookup される。そうでないと間違ったサーバーにNFS要求を送ってしまうことがあるから。
例 cliantA% mount server1:/usr/local /usr/local
cliantA% mount server2:/usr/local/bin.mips /usr/local/bin
カーネルのディレクトリ核検索キャッシュ（DNLC)により、すべてのルックアップがNFSサーバーにいくわけではない。
多くのUNIXマシンのNFSの実装ではファイルのi-node番号、ディスクデバイス番号、およびi-node世代番号をコード化したも
のをファイルハンドルとして使用している。その他のマシン上でのNFSの実装ではそのマシン固有のファイルシステム情報をコード
化している。どちらの場合もファイルハンドルの構造を解釈できるのはNFSサーバだけである。クライアントからは見えない。存在
するのもサーバだけ。
よってクライアントからおかしくなったファイルハンドルに操作しようとRPCが実行されるとNFSサーバーは「stale file handle」を返
す。
ファイルハンドルがおかしくなって問題となるのは、あるユーザの作業が他のユーザが使用中のエリアを侵してしまったり、ダンプテ
ープからファイルをフルリストアするなどしたときである。このようなときはNFSクライアントをリブートする必要がある。
NFSがサーバー・クライアント・モデルと異なるのは、
クライアントプロセス自体が呼び出すだけでなく、クライアントのブロック入出力デーモンbiodからも実行されること。
性能を向上させるため、NFS九ランとおよびサーバのコードはサーバーデーモンの実行可能ファイルではなくカーネルにすべて
含まれている。
がある。
すべてのNFSコードがカーネルに実装されてはいるが、デーモンがいないと複数のNFS要求を並列に処理できない。
UNIXにおけるバッファキャッシュ・・・最近参照されたファイルブロックを格納しておくためのシステムメモリの一部。SunOS4.xや
System Release 4ではバッファキャッシュはページマッピングシステムに置き換えられいる。
NFSクライアント側のbiodデーモンはNFSの性能を向上させるためにNFSクライアント側のバッファキャッシュの補填と吐きだしを
おこなっている。先読みをするのでNFSクライアントの性能があがる。書き込みも一時バッファキャッシュに書き出しいっぱいになっ
たらNFSサーバーにRPC要求をおくる。
NFSデーモンプロセスはカーネル内にあるNFSコードをスケジュールを行うためのハンドルにすぎない。
read()システムコールの動きをクライアントとサーバのカーネルをとおして追跡。
・NFSマウントされたファイルに対してユーバープロセスがread()を実行。プロセスにはファイルの存在場所はわからない。
・VFSがファイル記述子を対応するv-nodeに変換、タイプに従った読み込み操作を呼び出す。VFSタイプはNFS。
システムコールはNFSクライアント読み込みルーチンを呼び出す。ファイルディスクリプタはファイルハンドルに変換。
クライアントはファイルシステム上でファイルの位置を示す仮想ノード(v-node)をローカルにもつ。ファイルがローカルならこの
ポインタはi-node NFSふぁいるであればNFSファイルハンドルを含む構造体を指している。
・クライアントの読み込みルーチンがローカルなバッファまたはページキャッシュ内でのデータ有無を返し、データがあればただち
に返す。
・データがない場合、クライアント・プロセスはNFS read RPCを実行。readは8KバイトのNFSバッファ全体を要求する。RPC
要求が完了するまで、クライアント・プロセスがスリープ。
・RPCパケットを受け取ったサーバはそれを処理するためにnfsdを１つ割り当てる。
nfsdコードはパケットを受け取り、実行すべきRPCを決定し、ディスク操作を開始。
nfsdプロセスはディスク読み込みの終了まち、スリープ。
ディスクの読み込みが終了した時点でカーネルはデータおよびRPC応答をクライアントに送り返すためにnfsdの処理を再開
。
・クライアント上の読み込みプロセスが再開。
NFS read RPC要求が返した8Kバイトバッファからデータを取り出される。データはキャッシュされる。
プロセスが呼び出したread()システムコールがリターンしプロセスの処理が続行される。
上記に平行してbiodデーモンにより送出されたRPCの先行読み込みファイルの先読みを行っている。プロセスがシーケンシャ
ルに読み込んでいれば、バッファキャッシュに必要なデータがなくなるまで、そうとう多くのread()システムコールを実行できる。
キャッシュ・・・頻繁に必要とされるデータを必要とされるところの近くに保持しておくこと。または将来必要とされることを見越して
データをまえもってロードしておくこと。
NFSのデータキャッシングとは、ネットワークを介してサーバにRPC要求を送出しないことを意味する。
分散型システムでは、複数のプロセスが同一のファイルに対して入出力を行っている場合のデータの整合性と一貫性を保証
することが重要。NFSのキャッシュ・ポリシーはクライアント・サーバ関係に状態遷移情報を組み込まずに性能を向上させること。
NFSではファイル属性情報はクライアント側にキャッシュされる。そして最小有効期間（通常3秒間）存在する。クライアントが
ファイルを書き換えると（ファイル属性を変更されると）それに伴う変更はキャッシュ上の情報に対して行われ、キャッシュの有効期
間もさらに最小有効期間の長さだけ延長される。最大有効期間(通常60秒）変更されなければ、キャッシュからフラッシュされる
。その際キャッシュ上のファイル属性情報が変更されていれば、サーバに書き込まれる。ディレクトリ属性情報も同様。
biodが先読みしたキャッシュ内容の一貫性を保証するには、ファイルの属性情報が使用される。
キャッシュ内容の一貫性自体が、キャッシュされているファイルの属性情報を使って行われる。
読み込まれたデータブロックをクライアント上にキャッシュしてもNFSシステムに状態遷移情報をもちこまない。
キャッシュ期間が長くなると、データの一貫性に問題が生じるの有効期間を限定する。
書き込みもクライアントにキャッシュするのは、サーバにキャッシュすると状態遷移情報が必要になるから。
write RPC要求の完了がクライアントに通知されるまえに、ディスクへの書き出しが必ず完了するようにするために、NFSの
write操作には大きなボトルネックが発生する。3回のディスク書き込み（inode 間接的ブロックポインタを更新するため、データブ
ロックの書き込みのため）があるので。そのためできるだけ大きい単位で書きだす。一度スピード・メモリに書き込むなどのボトルネ
ック解消策が使われている。
flush-on-close・・・同じファイルに対する入出力が複数のユーザによって実行されてもファイルの一貫性がそこなわれないよう
にする。ファイルがクローズされた時点ですべてのNFSバッファの内容をNFSサーバーに描きだす。
サーバのキャッシュ
・ファイル属性情報のためのi-nodeキャッシュ。ディスクから読み込まれたi-nodeエントリは可能な限り主記憶に格納されて
いる。メモリ上でファイルの属性情報が読み書きできるのでger-attributeなどが高速化される。
・最後に読み込まれたディスクエントリのためのディレクトリ名ルックアップキャッシュ(DNLC)パス名のと合わせのたびにサーバが
ディレクトリを参照しなくてよい。ディレクトリ検索はディス上で特定の名前を線形に検索するので、比較的コストの高い操作。
・ファイルから読み込まれるデータのためのサーバのバッファキャッシュ。NFSクライアントにとって効果的な読み込みキャッシュと
して機能する。
ファイルロッキング
複数のクライアントが同じファイルにアクセスする際のファイル内容の一貫性をより厳密に制御する。複数のプロセスが同時に
同じファイルにアクセスするのを禁止できる。ロッキングは状態遷移情報を使用する操作でNFSの設計思想とはうまく適合しな
い。しかしUNIXファイルシステムのセマンティックスをすべてのファイルについて維持するという目標に適合する。
UNIXのファイルロッキングスタイル
BSDスタイル・・・システムコールflock()ローカルの実を対象。
SystemVスタイル・・システムコールfcntl()とlock()ライブラリルーチンによって実装。
RPCのロックデーモンrpc.lockd
クライアントとサーバ双方で起動。/etc/sm と /etc/sm.bak陵ディレクトリでロック状況を記憶。サーバのリブートの通知
も行われ、同じファイルロック状況をサーバ上に再構築する。
クライアントが停止しているときは、ステータスデーモンプロセスを終了し、/etc/sam/bakから当該ファイルを削除して
rpc.statdを再起動。
クライアントがリブートすると、rpclockdはクライアントのロック情報を回復しようとすると、リブートされたクライアントには情報
は残っていないので、結果的にサーバー上のロック情報も消去される。
NFSの今後
・繰り返し要求のサーバ上でのキャッシング。また、クライアント側での再送アルゴリズムのさらなる高速化
・AppleShareプロトコルコンバータを介してのNFSの使用。
・IBMのMVSなど、非UNIX系プラットフォームへのNFSサーバーコード実装。
など
第7章 ディスクレス・クライアント
SunOSまたはSunOS系サーバのディスクレスクライアントについて説明。
ルートファイルシステムとスワップファイルシステムのサービスに関してNFSを、ホストのコンフィギュレーション情報はNIS
を介して行うのが前提。
ローカルな資源を持たないマシンを、ネットワークの一員として稼働させるのは、NFS、NISでもっともやっかいな部分。
ディスクレス・クライアントのためのNFSサポート
SunOS4.0以前はディスクレス・クライアントはNDと呼ばれる分散型ファイルシステムプロトコルを課して別個にサポートされて
いた。
SunOS4.0ではディスクレス・クライアントのサポートはすべてNFSを介して実行される。これはSunオペレーティングシステムのフ
ァイルへのスワッピング機能（ページングでの仮想記憶管理システムでファイルをスワップエリアとして使用できる）と、NFSプロトコル
のNFSファイルシステムをルートディレクトリとしてマウントできる機能のおかげである。
ディスクレス・クライアントはVFSオペレーションのmount_root()を使って、マシンのルートデバイスにする。このため別のプロトコ
ルを使用してルートファイルシステムとスワップファイルシステムのための物理的ディスクブロックをサーバファイルシステムブロックにマッ
プする必要がなくなった。
ディスクレス・クライアントの設定
適切なオペレーティングシステムをブートサーバ上にロードする。
クライアントとサーバのアーキテクチャが同じであれば、/usrと/usr/kvm両ファイルシステムをクライアントとサーバが共有する。
異なっていればクライアント用の適切な/usr と /usr/kvmがサーバに必要。稼働中のマシンのカーネルアーキティクチャを調べ
るには % arch -k コマンドを使う。
クライアント洋のルートファイルシステムとスワップファイルシステムは サーバーの/export にあるのが一般的。
オペレーティングシステムがロードされていれが、追加するクライアントのホスト名とIPアドレスをNISのhostsマップに登録
追加するクライアント用のブートパラメータを設定 /etc/bootparams
追加するクライアント・システムのMACアドレスとホスト名をNISの ethersマップに登録。クライアントのMACはネットワークケー
ブルを抜いて起動するとわかる。
追加するクライアントのエントリをサーバの /tfpbootディレクトリに登録
追加するクライアントのルートファイルシステムとスワップファイルシステムをブートサーバ上に作成 /etc/exports（マウントでき
ること）
exportsファイルの具体的な例。
ディスクレス・クライアントのブートプロセス
ディスクレス・クライアントは電源投入時にもっているのは48ビットのイーサネットアドレスのみ、これをブロードキャストでリバース
ARP要求するのがブートプロセスの仕事、このとき飛ばすRARP要求はTCP層やUDP層ではなく、Netwrok Interface Tap
（NIT)デバイスで検出される。よってサーバ側に/dev/nitがなかったり、カーネルにNITデバイスが組み込まれていないとディスクレ
ス・クライアントは起動できない。サーバーは受け取ったRARP要求をrarpdでIPアドレスとホスト名に変換して返す。このとき
/tfpboot をチェックして自分がサーバを起動するのに最適でないと判断すると応答をおくらせる。
ちなみにRARP要求に応答するホストは一つではない。
次にブートブロックをftp(trivial ftp)を使って取得する。これは最小限度のファイル転送用ユーディリティでユーザやパスワード
のチェックをしない。ダウンロードは/tfpbootから行われる。
サーバはクライアントのアーキティクチャについて/tfpboot ファイルから得る。
RARP要求を返したホストにブートブロックがなければクライアントはｔｆｔｐ要求をブロードキャストする。
/tftpbootに登録する最後のエントリは自分自身へのシンボリックリンク。これを取り除くと古いタイプのディスクレス・クライアン
トが正しいブートブロックをダウンロードできなくなる。
ブートブロックがロードされうとディスクレス・クライアントはPROMのモニタからブートコードにジャンプする。
ファイルシステムの情報を入手するためにbootはブロードキャストでブートパラメータを要求する。
これに応答するのはrpc.bootprarad を実行しているサーバ。ルートファイルシステムの場所。クライアントのホスト名。ディフォ
ルト経路、NISドメイン名、およびブートサーバ名をひとまとめで返す。この情報は/etc/bootprarams か bootpraram NISマッ
プに登録されている。クライアントに渡されるNISドメイン名はサーバのディフォルトドメインである。異なるNISドメインに属するクラ
イアントの情報を同一のbootpraramasマップに登録はできない。
ディスクレス・クライアントは指定されたブートサーバから自分のルートファイルシステムをマウントして、そこに置かれたカーネルイ
メージをブートする。カーネルもスワップファイルシステムを決定するのにブートパラメータを要求し、これに答えるのも
rpc.bootpraramd である。そしてクライアントは起動する。ちなみにrpc.bootpraramdデーモンが返す名前およびアドレス情報は
クライアントのコンフィギュレーションファイルの情報と一致していなければならない。コンフィギュレーションファイルの情報はNISマッ
プの内容と一致していなければならない。
クライアントが起動して/usrファイルシステムがマウントされてからは、ブートスクリプトの問題で、ディスクレス・クライアントのブー
トプロセスの問題ではない。
/etc/bootpraramsファイルの最後に+があれば NIS bootpraramsマップが追加される。追加されるのはすべてで一部を混
み込むことはできない。
NISを使用しているときには、ブートパラメタはbootpraramsマップ上で管理すること。
複数のNISドメインに複数のディスクレス・クライアントが存在するのであれば、ドメインごとに別個のbootpraramsマップがある
ことを確認する。そうでないとクライアントが間違ったNISドメインを受け取る可能性がある。
多機種のディスクレス・クライアントを有するネットワークでは、各機種が同一の形式でブートパラメタ情報を使用していること
を確認すること。
NISマスター・サーバー以外のサーバ上にあるブートパラメータ情報のコピーはなるべく削除しておく。コンフィギュレーションの変
更後に使用不適当な情報がブートサーバ上に存在する可能性を減少できる。
クライアントのスワップエリアは、通常実メモリの4倍、少なくとも24メガから32メガ必要。
もっと必要になったとき、増やす方法は、クライアントをシャットダウンしてから、旧スワップファイルを削除する、ブートサーバ上
に新規にスワップファイルをmkfileを使って作成する。このときのオプションなど解説。
スワップファイルには先行読み込みを実行しない。
クライアント名の変更
クライアントをシャットダウンして、ルートファイルシステムとNISマップを変更する方法。
クライアントのシャットダウン以外は実際にはスクリプトで実行するのがよいといっていた。
トラブルシューティング
ディスクレス・クライアントがブートできないときは、まずホスト名、IPアドレス、およびイーサネットアドレスのすべてがブートサー
バとNISサーバ上で正しく登録されていることを確認。
次にブートできなくなった箇所。ブートブロックの決定ができなければブート情報が、シングルユーザモードで立ち上がれない
マシンは/usrファイルシステムがないことが考えられる。
クライアント情報が必要なファイルにかけていたりすれば、止まったところでどのファイルを確認すればいいかわかる。
わかりずらいのはブート要求に応答したrpc.bootparamd が不適当なマップである場合。
クライアントまたはブートサーバ上でデバッグモードを蔭位するとブートパラメータの内容をチェックできる b -v
/usrがない場合のよくある原因は、
/usrがマウントされるまでNISは起動されないので ディスクレス・クライアントの小さな/etc/hostsに、自分のホスト名、
localhostエントリ、ブートサーバ名、および/usrサーバ名をもつ必要がある。これがない。
機種ごとのアーキティクチャの問題で間違った/usrをマウントしようとしている。
コンフィギュレーションのオプション
ローカルクライアントにディスクをとりつけて、スワップエリアとして使用する方法と
ブート可能なシステム全体を構築し、ルートファイルシステムとスワップファイルシステムファイルを構築する＝データレス・ク
ライアントにする方法を解説。
ローカルファイルを追加する場合はディス容量を小さくしないとユーザファイルの格好の住処になってバックアップが必要にな
る。
ディスクレス・クライアントにローカルディスクをつけても、サーバーからブートできてかつ、ローカルディスクをファイル格納に使用
するには、Genericカーネルのコンフィギュレーションとして明示的に指定する必要がある /sys/srch/conf/name archはカーネ
ルアーキティクチャ、nameはカーネル名を指定。例をあげて解説。
クライアントとサーバの比率
クライアントとサーバーの分散具合のテスト方法
・一台のディスクレス・クライアントあるいはデータレス・クライアントをサーバとともに設定し負荷を測る
・クライアントにスクリプトで通常の負荷をかけ点綴的ネットワーク・トラフィック・パターンを実現する。サーバ側で数時間平
均トラフィックを計測、クライアントからの要求がピークに達したときのレートも計測、サーバーが秒あたりに処理するNFS要求回
数を測定（nfsstat)
・これをクライアントまたはユーザのタイプごとに繰り返し実行。
・AppendexDの方法でサーバをチューニングしてベンチマーク実行。
・サーバ能力をクライアント要求レートの平均値で割って大雑把なクライアント/サーバ比率を決める。個々のクライアント
が実行するNFSオペレーションの回数とクライアント数を掛け合わせるとサーバーをチューニングする際の目標になる。
でも。あくまで目安と言っていた。プリンタの駆動などもあるので。
第8章 ネットワークのセキュリティ
NISやNFSがもつマシンやファイルシステムへのアクセスを制限する仕組みを解説。
ただしすべてのセキュリティ対策を網羅したものではない。
＊ユーザレベルのネットワーク・セキュリティ
ローカルなマシンへのログインの制限はローカルホストのパスワードファイル、NISのパスワードマップ、ネットグループで定義され
る。
ネットワーク上のアクセスは、信頼できるホストと信頼できるユーザとう概念で決定される。
信頼されているホストとは、信頼されているマシンと、信頼しているマシンで表される。どのユーザやホストが信頼されているか
はホスト同士の関係がどのようになっているかにより定義される。
ホストとサーバの信頼関係
サーバとサーバ・・・一般的にサーバ同士は信頼しあう。NISパスワードマップのサブセットを含むパスワードファイルが各サー
バにあれば限られたユーザが信頼される。サーバ同士の信頼を拡大すれば、１つのセキュリティがやぶられれば他のサーバセキュ
リティも破れる。
サーバーからクライアント・・・ほとんどのクライアントがサーバとサーバのユーザを信頼する。
クライアントからサーバ・・・もっとも制約をうける。サーバの管理をまかされているユーザにだけ無制限のアクセスが与えられる
のが一般的。
クライアントとクライアント・・・ディスクがどのように管理されているかによる。いくつかのファイルサーバで全ファイルを取り扱って
いる場合、クライアント同士の制限は緩やかになる。独自のデータを格納している場合、クライアント同士の関係はクライアント
とサーバの関係に近い。
rloginとrshはruserok()を使って通常のログインとパスワードによるセキュリティチェックを回避している。
ruserok()は指定されたユーザやホストがローカルホスト上で信頼されているか否か決定する。信頼がなければパスワード入
力をもとめるか、rshなら「Permisson denied」を返す。
hosts.equivファイルの定義方法。ネットグループごと許可をあたえたり、特定のホストやユーザごとに許可をあたえたり、ここで
も＋でNISマップが組み込まれる。
.rhostsよりもhosts.equivが優先されるが、rootの場合は.rhostが先に参照される。
自分のマシンと他のホストで異なるユーザネームを使っている場合は、自分の.rhostsで指定すると変換できる。または rlogin
するとき指定する。
ネットワーク管理者は許可を与えすぎている.rhostsファイルに気をつけるべき。NISで管理されていないプライベートなエントリ
を含むパスワードファイルが数多くあるときには、.rhostsの使用状況を監視する必要がある。パスワードファイルをマージして無秩
序なユーザを排除してしまうほうが、監視より簡単。
ネットグループは大きなNISドメインを複数のグループに分割するために利用するのが最も適切。
NISマップとかhostsファイルやパスワードファイルにないホストやユーザ名を使用してネットグループの定義をしてはならない。
ネットグループの設定方法と、間違えやすいところの解説。
＊パスワードとNISのセキュリティ
パスワードを使用してのごく常識的なセキュリティ保護
簡単に推測できなくする。設定条件(ナン文字以上など）をつける。辞書にでている単語は必ずみつかる。パスワードを
推測できるプログラムがあったら使用してみよう。同じ土俵で勝負できる。
NISを使用してrootのパスワードを管理する。
サーバのルート特権はできるかぎり慎重にほごされなればならない。ローカルのマシンの管理者たちに安易使わせれば、か
ならずシステム管理者に跳ね返ってくる。教えないのは信頼していないからではないと伝えて、全権は掌握しておくべき。
システム管理者がすべてのマシンでスーパーユーザになるためにNIマップの設定方法解説。
NISをさらに安全にする
・NISマップをプライベートにするなら、２つ以上のネットワークにつながっているホストをNISサーバにしない。
・マスターNISサーバ上では、サーバのパスワードファイルとNISパスワードファイルを別にする。
・awkスクリプトを使ってパスワードの設定されていないエントリを定期的にチェックする.
・マシンのコンソールについてsecureパラメータを削除すると、ルートパスワードを示さないとシングルユーザモードではブートで
きなくなる。SunOSならブートPROMにセキュリティを設定できるが、ただしパスワードを忘れると新しいPROMを買う羽目になる
「Intruder alart」メッセージ
よくある原因としてはパスワードファイルのUIDフィールドの数字を削除してしまい、その壊れたマップを分配してしまうこと。
UIDが同一でないのにNISパスワードファイルエントリをローカルなパスワードファイルエントリで差し替えてしまった場合もIDのミスマ
ッチを引き起こす。このようなときwhoamiコマンドを実行すると「Intruder alart」メッセージが表示される。
また、rcp、rlogin、ｒｓｈが実行されるとパスワードマップ中にユーザのUIDがないと「who are you?」と表示される。
＊NFSのセキュリティ
ファイルシステムのセキュリティは、ファイルアクセスとファイル操作を制限することと、ファイルの内容を関係者以外の目から保
護すること。
リモートファイルへのアクセスを制限する＝UNIXのふぃある操作のセマンティクスをNFSシステムにマップすること。
ほかにも、NFS要求に含まれるUNIXスタイルの権限の正当性を、チェックしたり、ファイルを暗号化するなどのより強いセキュ
リティがある。
なによりも漏えいを防ぐにはNFSマウントされるところに置かないことが一番である。
NFSのRPCにおける認証
すべてのNFS要求には、ユーザの認証情報(credential)が含まれる。これはUIDおよびUIDが属するグループID（GID)のリ
スト。この情報でNFSサーバではUNIXでファイルアクセスする際のパーミッションチェックをする。
NFSの認証情報とユーザのローカルな認証情報の構造がマッチしない場合が３つある
・ユーザの属するグループが多すぎる。RPC人商標法構造体のクライアントのグループ数の上限がサーバのグループ数の
上限より大きい。
・スーパーユーザのマッピング
rootアクセスの付与は各マシンで行うことになっているため、スーパーユーザにはNFSマウントされたファイルに対して通常
のファイルアクセス許可があたえられていない。あるマシン上のrootになれるユーザでもファイルサーバのファイルを修正する許可が
あるわけでない。ルート特権を取得するsetuidプログラムもリモートファイルに使用しても通常の機能や期待した通りの機能を示
さない。
スーパーユーザでのアクセスはrootのUIDをNFSの認証情報構造体でぇあ匿名ユーザであるnobody（-2）にマップするこ
とで制限している。サーバのカーネル中でマップされるnododyのUIDを変更してrootUIDマッピングを無効にすればサーバから公
開されたファイルをすでてスーパーユーザとしてアクセスできるが、これは危険。
ほとんどのNFSサーバでは公開したファイルシステムに対するrootパーミッションは、root=exportオプションを使用すること
で各ホストごとにあたえられているようになっている。/etc/exportsファイルにこのオプションを指定して登録されているホストに対
しては、ファイルシステムを公開するサーバがrootアクセス権限を付与することになっている。その例。
NFSファイルシステムにrootパーミッションを与えても問題ないのは、ディスクレス・クライアントのルートとスワップのパーティ
ションに対してだけであり、当然でもある。
NFSマウントされた実行ファイルで、setuidビットがたっているものは信用しない方がいい。また侵入者がsetuidをたてた
実行可能ファイルが置いていくことも考えられる。正規のスーパーユーザがこのファイルを実行すると被害が発生する。nosuidオプ
ションを指定してマウントを行うと、NFSマウントされていてもsetuidビットが設定されている実行可能ファイルの実行でもsetuid
機能は作動しなくなる。これを/etc/ftabのエントリに登録しておくこともできる。
正体不明のユーザマッピング
NFS要求に認証情報が欠けている場合
・Secure PRCを利用しているが、クライアント側のユーザが正しい認証情報をSecure RPCシステムに提供していない。
・クライアントがPC/NFSを実行しているPCで、PCユーザが正当なユーザ命とパスワードを示していない。
・クライアントがUNIXマシンでなく、UNIXスタイルの認証情報を作成できない
・要求が偽物。
ディフォルトでは匿名ユーザはnododyとして扱われる（rooｔも） 公開のオプションとしてanonを指定して匿名要求のサーバ
ー上でのマッピングを変更できる。/etc/exportsに匿名ユーザのIDを設定して、正体不明のユーザを既知のローカルユーザにマ
ップできる。ただしスーバーユーザにしてはいけない。
ファイルシステムへのアクセス
特にソースファイルのあるマシンは特定のホストからのアクセスからもほごされなければならない。サーバの/etc/exportsファイ
ルに-accessオプションを指定するとアクセスが許されているホストを記述できる。
読み出し専用でのアクセス
/etc/exportsにｒｗオプションを指定することで書き込み許可でファイルシステムをマウントできるホストを指定できる。
ポートチェッキング
spoofing・・・正当な権限が与えられていないユーザプロセスから手作りで模倣した正当なNFS要求を送出すること。
NFS要求が正当なNFSクライアントから送られた場合はクライアント上の特権UDP/IPポートから送られているはずなので、
ポートモニタを有効にしてチェックすることができる。
ディフォルトでNFSポートモニタが有効になっている場合もある。カーネル変数で管理されているのが一般的。変数自体は
ブート時にスクリプトのadbを使用して設定できる。
echo "nfs_portmon/W1" | adb -w /vmunix /dev/kmem
ポートモニタをオフにするにはブートスクリプトでデーモンを呼び出している行に -n フラグを加える。 rpc.mountd -n
ただし、NFSクライアントコードをPC用に実装したものなど、特権ポートからの要求を送出しないものもあるので注意。
SecureRPCとSecureNFS
SecureRPC・・・標準のRPCシステムに認証情報の正当性をチェックする仕組みを加えたもの。DES暗号化と公開鍵
暗号化の二種類をくみあわせている。秘密鍵にはユーザのパスワードなどが良く使われる。この対話手順を解説。
SecureNFS・・・NFSにSeureRPCを使っているもの。ファイルシステムを公開してマウントする際に、secureオプションを
指定する。（クライアントでも）。
この仕組みに使う公開鍵と秘密鍵はNISマップのpublickey.bynameで管理されている。このマップはNISマスタサーバ
の/etc/publickeyから構築されるので、NISを実行していなければ鍵を作成できない。ディフォルトの鍵はnobodyのためだけ。マ
ップ内の識別子について解説。
鍵の作成はスーパーユーザが「newkey -u user」で生成できる(NISマスタサーバ上）このコマンドについて解説。
対話鍵の生成方法
SecureNFSが適切に動作するためのデータとデーモンファイルの解説。
kerverosシステム
MITのAthenaプロジェクトで開発されたNFSサービスをSecureにするための仕組み。SecureNFSとの違いを解説
＊ウイルス
コンピュータウィルス・・・オペレーティングシステムやシステムユーティリティを変更して危害を加えるプログラムコード。
自己増殖し、ベクトルあるいはキャリアを通じて広がる。ネットワーク上のすべてのコンピュータが汚染されることもある。
UNIXはrootでなければカーネルの書き換えができないので、DOSよりセキュリティが高いと言えるが注意も必要。cronの
エントリ、パブリックドメインから入手した実行コード、root権限で得体のしれない実行ファイルを走らせるのはしてはらないない。
第9章 NFSとNISによる電子メールサービスの集中化
メール設定はDNSによる設定が多くなっているが、ここではNFSとNISを利用したメール設定を解説。
サイトのメール管理を簡潔にするため、メールhubとよばれる1台のマシンにメールの転送とスプールを割り当てている。
＊共有メールスプール作成
個別スプールではユーザは特定のマシンからしかメールの送信できないし、返信は送ったマシンにきてしまう。またワークステ
ーションのないユーザのメールスプールはどうするか、すべてのワークステーションにsendmailデーモンがが起動していなければならな
い、すべてのバックアップが必要など、あまりよいことはない。
メールhubで集中処理することで、ローカルに変更があってもメールの不達などがおこらないようにする、外部には名前を隠
ぺいして、すべてのメールがよくしられているホストから送られてくるようにみせかけて、内部の変更に影響されないようにする。
NFSでメールhubマシンのスプールディレクトリをマウントして実現する。
ただし全ユーザのメールがはいるのでファイルが大きくなる欠点がある。スプールエリアは大きくもとう。
具体手にはexportsで/usr/spool/mail か /var/spool/mailを公開する。このときシンボリックりんくであればリンクのターゲ
ットもexportsファイルに登録しないといけない。その後メールスプールのクライアントでｒｗおよびhardオプションでメールスプールをマ
ウントする。 wahoo:/var/spool/mail /var/spool/mail nfs rw,hard 0 0。クライアントのsendmailデーモンはコメントアウトして
停止しえかまわない。
すべてのメールをメールhubから配送するときはsendmailのリモートモードを使うか、エイリアスを使用する。その詳細解説。
メールの到着を通知する仕組みbiffはすべてのメールがメールhub上で配送されている場合には作動しない。
一般的にメールの通知はcomsatデーモンがbiff設定されているかチェックして行われる。NFSでメールスプールをマウントして
いる場合でも、通知をうけれるようにCシェルのmail変数を利用する方法と、ネットワーク経由でuunet.uu.netなどのアーカイブサ
ーバからxbiffを入手して利用する方法がある。その設定方法解説。
＊名前の隠ぺい
sendmailのリモートを利用するときには名前の隠ぺいは暗黙裡に行われるが、エイリアスの場合は明示的な実行が必要。
メールが送信される前にメールhub上のsendmailに差出人アドレスに適用されるアドレス書き換え規則と受取人アドレスに適用
されるアドレス書き換え規則が必ず含まれている。ローカルのメールを処理するmailerが利用する規則を変更することでhostがロ
ーカルネットワークにある場合、差出人アドレスの形式をuser@hostからuserに書き換えられる。その方法
＊NISエイリアスの展開
通称ユーザ名を定義するシステム、自動メールハンドラ、ローカルおよび高域用のメーリングリスト作成のためにエイリアスが
使用される。NISでのエイリアスの展開または/etx/aliasesファイルからの展開は以下のようになる。user1とuser2の名前は同
一でも構わない。
user1: user2@host
ベンダーによっては、/usr/lib/aliasesや/usr/lib/mail.aliasesにおくこともある。
自分のエイリアスファイルがどこにあるかはsendmail.cfファイルの前半部のOAオプションを参照するとわかる。
＊広域エイリアス
広域エイリアス・・・複数のネットワークやNISドメインにまたがったエイリアスの意味。例このサイトのすべての従業員など。
広域メーリングリストの設定
階層化されたメーリングリストの最上位に位置するマシンを1台選択する。メーリングリスト管理者は、このマシンへのスー
パーユーザアクセスを持っていなければならない。ここでメール配布の名前とメール投降の名前がリストで定義される。エイリアスが
２つ使用されるのはフィードバックループを発生させないため。この階層構造の解説。
存在しなくなったユーザ名がリストに残っていたり、ユーザの自分のメール転送をおかしく指定してしまう、ホスト・マシンが停
止してリストの配布が不能になるなどの問題が考えられる。エイリアスにowner-listを定義すると、これらのエラーはこのエイリアス
に送られる。リストの所有者はNISドメインをリストから外すことができるローカルシステムの管理者がなるべき。
アーカイブと管理
配布リスト中にローカルファイルを名を記述しておくと、リスト宛てのメッセージを全部マシンにアーカイブしておくことができる
。管理者はときどき、ファイルをリネーム、圧縮してスプールエリアがオーバーフローしないようにするべき。
＊NISエイリアスとローカルエイリアスの統合
ローカルのaliasファイルとNISエイリアスマップを統合してつかうことができるが、これはsendmailデーモンがローカルで起動されて
いてリモートになっていない場合。具体的な例を解説。
＊メールの転送
共有されたメールスプールとメール敗走機構によってメールサービスを集中化させる枠組みとしてNFSとNISは最適だが、メー
ルの転送は逆に複雑になる。
メールがユーザ当てに配送されるとき、mailerはユーザのホームディレクトリに.fowardがないかチェックして、他のユーザに転送
したり、シェルスクリプトや実行可能ファイルにパイプでメッセージをおくることができる。vacationユーティリティもこの一種。
メールhubがユーザのホームディレクトリをみつけて、転送のスクリプトやフィルタはメールhub上で実行可能でないといけない。
ディレクトリやファイルが参照される場合、それらはメールhubに存在しないといけない（コンフィギュレーションが異なるから）
第10章から第14章は応用編。
ネットワーク環境下のシステム管理やデバッグ技術について解説。
性能の測定やチューニング方法を紹介。
第10章 診断用および管理用ツール
分散型のアーキティクチャが予想通りの能力を発揮するには、ネットワークがきちんと整備され、サーバが適切にコンフィギュレー
ションされていることが必要。
ネットワークを変更する際はつねに影響が複数のマシンに及ぶことを考慮すべき。
NFSクライアントを追加するなら、接続が増える、ノードが増える、ネットワーク処理の能力などを考慮。
サーバ資源を増やすなら、もっともきびしい状態の資源はなにか認識しておく、CPU速度、ディスク速度、ディスク容量など。
単にサーバーを追加すればネットワークの効率がよくなるのではない。
NFSやNISネットワークで問題を解析するためのツール、手順、および評価基準を解説。
NISが稼働していることが前提であり、一般的なNISマップ(下記）を基準とする
マップ名 ニックネーム ローカルファイル
password.byname passwd /etc/passwd
group.byname group /de/groupe
hosts.byname hosts /etc/hosts
rpc.byname rpc /etc/rpc
services.byname services /etc/services
＊ブロードキャストアドレス
ブロードキャストアドレスはローカルエリアネットワークのすべてのマシンにパケットを送出する。
MAC層とIP層があり、MAC層のブロードキャストアドレスは ff:ff:ff:ff:ff:ffのみ、IP層はいくつかの表し方があるので、ネットワ
ーク全体で揃えておかないと混乱する。
＊MAC層とIP層の操作を行うツール
ifconfig・・・インターフェース・コンフィギュレーション。IPアドレス設定や設定状況の確認 使い方詳細解説。複数のネットワ
ーク・インターフェースに接続するときにはifconfigを複数回使う。
ホストの情報の誤り・・・ポートマップのエラー「portmap: Non-local attempt to unset prog 100105」などがでる。原因は
NISのホストマップとローカルのhostsファイル、ホストのブートスクリプトのに登録されているホスト名とIPアドレスに一貫性がないこ
とが多い。
サブネットワーク・マスクはNISのnetmasksマップでどうなているとよいのか
IPアドレスからMACアドレスへの変換はARP（アドレス・リゾリューション・プロトコル）が使われる。ARP要求でネットワークのトラ
フィックが異常に高くなる状態をARPストームと呼ぶが、まちがって設定されたパケットをブロードキャストパケットを勘違いしたホス
トが異常なパケットを最初に送出したホストのイーサネットアドレスをARP要求で得ようとするためにおきる。トランシーバの電気
系統に問題がある場合が多い。「arp -a」でARPテーブルのエントリがみれる。その解説。
ping・・・ネットワーク上のホストの情報を得る。ネットワークの物理的な接続状況をチェックできるツール。ICPM
（Internetwork Control Message Protocol)を使っている。コマンドの結果の説明。
イーサネットインターフェースの処理能力の測定・・・ネットワークが適切に設定されていて、ホストのコンフィギュレーションが正
しくても、ネットワーク・インターフェースに負荷がかかりすぎて交信がうまくいかないことがある。sprayユーティリティでネットワーク・イ
ンターフェースの能力を大まかに測定できる。sprayはリモートホスト上のprc.spraydデーモンにRPCを送出することで、ホストに固
定長のパケットを連続的に送信し、最後のパケットが送出された時点で、受信されたパケット数が、rpc.spraydデーモンから報
告される。これでクライアント・サーバ間のパケット転送レートを算出する。ただし原因の特定は難しい。sprayでわかること（遠い
マシンと近いマシンへうってみるなど）詳細解説。
＊リモートプロシージャ・コールに関するツール
ネットワークに問題があるとすぐに気が付くが、ネットワーク・プロトコル・スタックのような上位の層にあるときは、少数のマシンに
しか影響を与えないので気が付きにくい。
RPC層からNFSやNISのアプリケーション層までの機能を調べる為のツール紹介。
RPCはネットワーク上のマシンにクライアント・サーバ関係を与える。
NFSサービス用に公開されたディスクやNISマップといった共有資源を物理的に所有しているのがサーバ、サーバの資源を
RPCで要求するのがクライアント。
RPCサービスの識別は、プログラム番号、バージョン番号、プロシージャ番号、プロトコル（UDPまたはTCP）で行う。
この仕組みを詳細に解説。
rpcinfo・・・pingのようにRPCサーバに対してポートマッパーが持っているRPCに関するマッピング情報を確認できる。ただし、
セッション層には利用できない。このコマンド結果の詳細解説。
RPCの問題点をデバッグする
最初にブートされたブートパラメータがまちがっている場合を調べる為に「rpcinfo-b」を実行する方法解説。
rpcinfo要求に対して応答するホストがなければ、ブロードキャストパケットがいずれのNISサーバにも到達していないのが原
因。NISドメイン名とブロードキャストアドレスが正しいのなら、ブロードキャストでサーバを探すことはやめて、ypbindデーモンに正し
いNISサーバのホスト名とアドレスを直接渡すようにしてやればいい。
＊NISツール
使うには下位レベルに問題がないことが前提。
ypmatch・・・NISマップ用のgrepに相当するもの。使い方解説。
ypcat・・・同じくcatに相当
クライアントのバインド状況の表示と解析
ypwhich・・・引数なしだとクライアントがその時点でバインドしているNISサーバホスト名が表示されるなど、シェルスクリプトを
使った使い方解説。
NISのマップ情報をypwhichで調べる方法。
ypset・・・クライアントのバインド変更。使い方解説。
＊NFSツール
NFSの操作はどちらかというと静的で結局ファイルシステムをマウントするかしないかの話で、うまく走るのか、まったくだめなのか
という話でもある。
NFSが動作していないと、ファイルシステムの公開がうまくいかない、パーミッションがおかしい、データが古くなったり分いsつした
りする、サーバの性能が制限されてしまうといった問題が発生する。
マウント情報の管理ファイル
ファイル ホスト 内容
/etc/xtab server 現在公開されているファイルシステム
/etc/rmtab server このサーバのクライアントのためのホスト：ディレクトリのペア
/etc/mtab client 現在マウントされているファイルシステム
公開しているファイルシステムとそのファイルシステムをマウントしているクライアントはどれかは/etc/exportsと/etc/xtabの対
応でわかる。
サーバは/etc/exportsに従ってrpc.mountdを起動して/etc/xtabを長さ0にする。
/etc/xtabの管理にはexportfsユーティリティを使う。/etc/xtabの最終変更時刻がファイルシステムの航海情報が最後に
変更された時刻となる。
exportfsを引数なしで実行するとマウントされているかわかる。＝cat /etc/xtabでも同じ出力が得られる。
mountdデーモンはクライアントからのマウント要求を受理すると、マウント要求で指定されたディレクトリ名とクライアントのホス
ト名を/etc/rmtabに記録する。unmountがくるまで記録されている。サーバがリブートされてもパージされない。普通クライアント
がシャットダウンするときリモートファイルシステムをアンマウントするはずだが、それを行わないとここに誤った情報が残る。
showmountはrpc.mountdデーモンに対して現在のリモートマウントテーブルを要求する。このとき参照されるの
は/etc/rmtabである。コマンドのオプションと見方解説。
dtコマンドはクライアント上で現在のマウントしているふぃあるシステムをレビューできる。オプションと使い方解説。多機種のマ
シンを使っている環境ではdfコマンドは紛らわしい情報や矛盾した情報を表示することがある。
mountコマンドを引数なしで実行すると、mtabの内容が表示される。オプションと使い方解説。
＊NFSの統計情報
クライアント側とサーバ側でNFSサービスの利用量が手続きの呼び出し単位でRPC層とアプリケーション層各々について収
集されている。
nfsstat -c はクライアント側の統計情報を、nfsstat -s はサーバ側の統計情報を表示する。オプションと結果の見方解説
。
＊システムクロックの合わせ方
複数のサーバ上にファイルを分散させる場合、サーバとクライアント間でシステムクロックの同期をとることが重要。
rdate ホスト名でそのホストに時間を合わせられる（スーパーユーザ権限が必要）
ネットワーク上の現在時刻はタイムキーパホストに管理させるのが一般的。
NISのhostsファイルにtimehostというホスト名のエイリアスをつくってrdateで指定するのが一般的。
ネットワーク上のマシンの時刻同期はまず、/etc/rc.localに指定してブートシーケンス中に行う。
それ以降はcronで定期的に行う。crontabで一定間隔を指定する。
各ホストのrdateの時間が重ならないようにする。
ミリ秒単位で同期をとれるNTP（Network Time Protocol）もあるが、解説はない。
第11章 ネットワーク障害の修正
ネットワーク・ケーブルが物理的におかしいときの診断法からまちがったドメインのNISサーバとして機能してしまうマシンへの対応
まで幅広くとりあげる。
ネットワーク障害を上手にデバッグするには手順が重要。プロトコルスタックの下位レベルから上位レベルへ診断する。
例 NISサーバにバインドできない
pingでネットワークをテスト→rpcinfoでypservプロセスが正常かテスト→ypsetでバインドをしてみる。
＊正しく終端されていないネットワーク
マシンによって接続で来たりせつぞくできなかったり、あるいは、マシンの接続が時としておかしくなるのは、ネットワーク・ケーブ
ルの配線状態が悪いか、正しく終端されていないことが原因であることが多い。こんなときには隣のマシンへのpingに20ミリ秒もか
かたりする。例をあげて解決方法を解説。信号が反射されるとどうなるかはAppendixAの伝送線路理論で詳細に解説。
終端されていないネットワークを壁に背を向けて立っている友達にゴムボールをなげて、キャッチして跳ね返さないようにしない
といけないところを取りこぼしていると説明していた。跳ね返りの信号から遠いところのマシンはあまり影響を受けない。
またイーサネット同軸ケーブル内での信号反射を回避するには、トランシーバをできるだけケーブルの近くに配置すること。
信号吸収を電気信号が厚いレンガ塀に突き当たるのではなく、ビルの曲がり角に入り込むようなものといっていた。
例としてあがっていたのは、
ゲートウェイを介したネットワーク・アクセスの障害、
リピータを介した場合にネットワークがおかしくなる。
＊複数のARP応答がある場合
IPアドレスからMACアドレスの変換がおかしくなった場合の悪影響について述べる。
例として
マシンが時に遅くなる。すべてのマシンが同時に遅くなるわけではない。
マシンが突如数分間行方不明になる。
症状が散発的で時間が経過すると治るという特徴がある。
このときのARP要求の診断方法を解説。
＊NISサーバをかたるマシン
ある日クライアントマシンからログインできなくなって、マシンをリブートしたらマウントもできなくなった例。
シングルユーザモードで立ち上げて、ypbind、ypwhichでバインド先を確かめる。すると、そのドメインのなかにNISサーバをかた
るゲートウェイがいたため、ypservがまちがったドメインにバインドされていた。ゲートウェイをちがうドメインに移してもらい、NISマッ
プを含むサブディレクトリ/var/yp/ドメイン名を削除してリブートすると正常に動くようになった。
NISサーバのマップがおかしくなっていたり、不完全でも似たような症状がでる。ypwhichで出力されるNISサーバがただしけれ
ば、この可能性が高い。マップの整合性をチェックするにはypcatですべてのキーをダンプし、変更漁にあわせて、初期化したり修
正したりする。
＊ブートパラメータの混乱
ディスクレスマシンSun3/50をブートしようとしたところエラーになった。
近くのマシンからブートシーケンスのブロードキャストをエミュレートしたところ（rpcinfo -b bootparam 1）異なるベンバーのブー
トサーバがみつかって、そこが応答していることがわかった。ブロードキャストの要求に対する応答形式がベンダーで異なっているこ
とがあるのである。このマシンのrpc.bootparamdをコメントアウトする方法が考えられるが、もしこのサーバが別のディスクレス・クライ
アントを持つ場合はそれはでいないので、自分のクライアントを記述したリストをもたせる（/etc/bootpraramsファイルからプラス
記号をとりのぞく）ことで解決する。
＊NFSエラーメッセージ
NFSは実装の方法で性能やチューニングが微妙に異なることが多い。
NFSマウントされたディスクに対する書き出しエラーはその仕組みのゆえに多い。
NFSの書き出しが頻繁に失敗するような場合、どのファイルが実際に書き込まれているかを調べることで、書き込みを実際に
実行しているユーザやプロセスをみつけることができる。SunOS4.0 ではshowfhユーティリティを使う。そのためにはサーバ上で
RPCサーバデーモンrpc.showfhdを起動して、クライアントでshowfhを実行する。
クライアントの書き込みが遅いなら、NFSの負荷を効率よく設定する必要がある。
第12章 性能の測定とチューニング
取扱い範囲は、性能のボトルネックを識別する方法や性能を向上させるためのさまざまなオプションを解説。
ネットワーク資源の使い方や、ネットワーク構成がまずい場合はシステムの応答も悪い。特に重要な部分がおかしいなら、時
間をかけても対処した方が見返りは大きくなる。
チューニングの過程では最初は性能が大きく向上するが、やがてあまり上がらなくなる。こうなると手間ばかりかかって、性能の
向上率はたいしたことはないので「だいたいチューンされていればそれでよし」のジャズ流精神で解説する。
ユーザは自分のマシンが早くなればそれでよいと考えている。システム管理者は常にネットワーク全体を考えなければならない。
NFSよりrpを利用したほうが早い。NFSをチューニングする必要はないという考えに反論。NFSの利点は自分のマシンのファイ
ルシステムにアクセスするようにアクセスできることで、ｒｃｐコマンドでは相手のサーバ名とディレクトリ名が必要になるといっていた。
＊NFSはどのように動作するのか
チューニング前にしっておくべきこと。どれだけのことがサーバに要求されているのか？＝どのくらい調整がいるのか。
コンフィギュレーションのオプションとしてどのようなものが利用できるのか？＝変更で事態が改善したと知る方法。
NFSの任意性。NFS要求はバーストである。そしてバーストの間は頻繁だが、そのあとは静かになる。
負荷の高いNFS要求・・ディスへの入出力をサーバに要求するもの(シンボリックリンクの展開も）
負荷の低いNFS要求・・・ファイル属性情報やディレクトリ名のlook-upキャッシュに単にアクセスする要求など。
NFS RPC mixture ・・・サーバに対して発行されたすべてのRPCを各タイプごとの平均比率で表したもの。
＊性能の診断
上手にチューニングできたかの目安はクライアントから見てサーバの処理が速くなること。
具体的には標準的なクライアントからの要求に対するサーバの応答時間の平均値を割り出すこと。ここではディスクレスクラ
イアントなら２５－３０ミリ、NFSクライアントであれば５０-７０ミリが一般的としていた。あとはクライアント１台で応答値をはかって
、最小時間をわりだしその２倍以上ならサーバに負荷がかかりすぎていると考える方法もある。
クライアント上でサーバの応答時間の平均値を計算するには、クライアントが発行したNFSのRPCの総数を所要時間で割
る。あくまで平均なので、あまり細かいことは考えない。詳細な方法を解説。
＊ベンチマーク
ベンチマークをテストするときには、NFSコールの受診率とRPCのばらつきを現実に近づけないと意味がない。規則的な間隔
のものは、あまり意味がない。留意点と、Heisenbergの不確定性原理（何かを観察するプロセス自体が観察の対象をへんかさ
せてしまう）ことをあげて、性能を測る方法を考えるように促す。
＊NFS性能・ボトルネックの識別方法
NFSは状態遷移情報がないのでクラッシュからの復旧が容易であるが、逆に負荷でタイムアウトなのか、サーバダウンなのか
判断がつきにくい。
過負荷のサーバはnfsdデーモン待ちになっているので、新たなパケットは受信できないが、受信したパケットには応答できる。
でもそのころにはクライアントはパケットを再送してしまっている。
サーバクライアント関係でボトルネックになりやすところ
・クライアントのネットワーク・インターフェース
・ネットワークの処理能力
・サーバのネットワーク・インターフェース
・サーバのCPU負荷状態
・サーバのメモリ使用状況
・サーバのディスクの転送能力
・システム構成の及ぼす影響・・・サーバのカーネルコンフィギュレーションが悪い、ディスクのバランスが悪い。マウントポイント
を指定するのに使用している名前付け規則が効果的でないが考えられる。
ボトルネックをみつけるには
ネットワークの問題かサーバの問題か切り分ける。
典型的NFSクライアントでnetstatツールを使用して、再送率と複製応答率をみる。これでパケットがサーバに達しているな
らネットワークは問題ないと考える。NFSは下位レベルのプロトコルがわからないのでこのような全体的なチェックが必要になる。
＊ネットワークの混雑とネットワーク・インターフェース
便利なネットワークは拡張を繰り返す。しかし、ネットワークは拡張をされると負荷が高くなりすぎたりホストのネットワーク・イ
ンターフェースがおかしくなったりして性能が低下するものである。
ネットワークの設計と、容量をどのように評価していくか考える。
・「netstat -i」を使ってイーサネットのネットワークインターフェースが正常に働いているかを確認する方法。
・「netstat -i」で衝突回数をしらべる。イーサネットはパケットを送信するときキャリアセンスをだして、送路があいているか確
認するのだが、つながるマシンが増えれば当然衝突も増える。ネットワーク使用率が３０-４０％を超えるとイーサネット自体がボ
トルネックになる。
＊ネットワークを分割するための機器
ネットワークの分割は１本のバックボーンを複数のセグメントに分岐することで行う。セグメントはパーティション用の機器を介し
て接続される。この機器には、リピータ（中継器）、ブリッジ、ルータ、ゲートウェイがある。
リピータ・・・２つのセグメントを物理層で接続。信号とパルスの整形をするだけで、ネットワーク混雑回避にならない。
ブリッジ・・・セグメントをデータリンク層で接続。MACアドレスで転送すべきパケットを選択する。学習型でない場合MACアド
レスを各ネットワークごとに登録してやる手間がかかる。セグメントの混雑は緩和するはずだが、もっとも使用頻度が高い伝送路
が新しいブリッジを通過していないことが前提。
ルータ・・複数のIPネットワークの接続に用いられる。イーサネットアドレスでなく、ソースIPアドレスとディスティネーションIPアドレ
スに従ってパケット転送を行う。
ゲートウェイ・・ネットワーク・プロトコルスタックの最上位。アプリケーションレベルでの転送機能を実行する。トラフィックの転送
においてプロトコル変換も同時に行うことが多い。異なる通信プロトコルを用いる複数のネットワーク接続に用いられることが多い
。
プロトコルフィルタリング
IPプロトコルと無関係なデータが大量に取り扱われるなら、IPプロトコルのパケット比率を調べる。LANアナライザやSunの
trafficユーティリティを使う。そしてプロトコルでパケットの選択転送を行うブリッジやルータを使うようにする。
ブリッジによる分割
NFSで通信を行うクライアントとサーバをグループにしてブリッジで分ける。NISはブリッジがブロードキャストトラフィックを阻止
しないので普通に使える。またNISはNFSに比べ通信量が少ない。
ネットワーク中のノードの理想的な分割を行うために各ホストをノードとするようなグラフで自分のネットワークを表現する方
法を解説。マウントの重みづけをする。FordとFulkersonのmax-flowmin-cau理論（ネットワークにおける最大量量は１つ以上
のボトルネックによって制限される）によるもの。
冗長な回路が必要な場合も解説。
分割されたネットワークでのNISの利用
間にルータがあるとypbindのRPC要求がブロードキャストされないという問題が発生する。
またブリッジがあると通過に時間がかかるので、構成によっては一部のNISサーバの負荷があがることが考えられる。
ディスクレス・ノードの影響
よほどの事情がない限り、ディスクレス・ノードは物理的にも論理的にもサーバと同じネットワーク上に設置されるべき。
どうしてもそうならないときのための対処法が解説してあった。
＊サーバのチューニングをするには
まずはサーバの何が原因で性能が向上しないのか調べる。
CPU負荷を調べる
CPUの負荷が高すぎると、NFSデーモンがスケジュールされるまでの待ち時間が長くなる。同時にサーバ上で実行されてい
るCPU依存のプロセスの性能が低下する。
すべてのnfsdデーモンは同一のUDPソケットから要求を受け取るので、デーモンが他のプロセスと競合してCPUサイクルを書
くとしなければならないとサーバの応答時間が余計にかかる。そうなると下位レベルのネットワーク・ドライバがパケットを落としてし
まう。Berkely版のvmstatはCPU統計情報を表示するコマンド。
NFSサーバに端末を接続するのはやめる。
NFSサーバをゲートウェイにしない。
NFSサーバ・デーモン
標準仕様のブート時に起動されるnfsdデーモンは通常の使用状況での性能が得られるようにベンダーが適当にきめたもの
。nfsdの数を８個にするには「nfsd 8 & echo -n 'nfsd'」とスクリプトで指定する。
最善の数を試してみよう。
ただしどのnfsdデーモンも要求をうけとるソケットは同じ。nfsdデーモンの数が極端に少なくソケットがオーバフローしていると
きには「netstat -s」でわかる。
nfsdデーモンが多くなりすぎるとコンテキストスイッチングとスケジューリングのオーバヘッドが問題になる。思わぬ悪影響でメ
ールが配信されないなどの事態が考えられる。nfsdデーモンは最低で４つ。UDPソケットがオーバーフローしなくなるまで増やすの
がよい。
メモリ使用量
NFSはサーバのバッファ・キャッシュを使用してNFSのread要求に伴うファイルブロックの読み込みを実行する。このバッファキ
ャッシュを増やすことができる。ただしリブートが必要。サーバがNFS専用でないなら、すべてのプロセスが実行できるだけのメモリを
用意してページングを起こさないようにすべき。
ディスクとファイルシステムのスループット
NFSの場合ネットワークより、サーバがディスクとファイルシステムを効率よく利用するようにした方が全体の性能は上がる。
ディスク・アクセスを最適にして、カーネルのテーブルサイズを最適にして、ディスクにまんべんなく要求を分散する。
UNIXのファイルシステムは小さなファイルを扱うには理想的だが、大きなファイルには向かない。ディレクトリが大きすぎると
NFSにむかない。ファイルシステムのフラグメンテーションも効率低下をまねく。これを直すにはダンプして再構築するしかない。
ディスクのデータ転送速度をあげるにはシーク時間を短くすること。難題もあるディスクのなかの１・２ぢに要求が集中するの
は好ましくない。
ディスクの負荷分散は頻繁に利用されるファイルシステムを複数のディスクに移し、それらのファイルシステムに対する要求を
同時処理することで行われる。ディスクレス・クライアントの場合はとくに重要。「iostat -D」でディスク待ちしている要求の数の偏
りがわかる。
カーネルのコンフィギュレーション
ファイルのi-node情報だけで事足りる要求は多いのでi-nodeテーブルのサイズを最適化する方法解説。
サーバー間でファイルをマウントするとデッドロックが発生しやすくなるのでやらないこと。どうしてもというときは「bg」オプションを
使う。
マルチホームサーバ
サーバからNFSファイルシステムが複数のネットワークインターフェースに対して公開されている場合、インターフェース間でパ
ケットがなるべく転送されないようにマウントをする。
*クライアントのチューニング
クライアントのチューニングはサーバに劣らず重要。サーバの能力には限界があるが、クライアントはそれを考慮して要求をし
てこないので、サーバがいっぱいになってしまう。このような場合クライアントに調整弁をつける。
遅いサーバの補償
RPC再送アルゴリズムでは、遅いサーバとネットワークの混雑の区別ができない。
「nfsstart -rc」でサーバが遅いのかがわかる。しかし両方だと見分けはつきにくい。すべてのサーバに同じディスク操作をし
てみて、他より遅いか見る方法もある。
遅いサーバに対応するために/etc/fstabでtimeoパラメタを調整する方法解説。
「netstat -m」でNFSサーバの応答時間がわかる。タイムアウト時間を増やすときはいきなり３００とかにしない。
再送率の閾値の考え方と設定値の解説。
ファイルシステムがソフトマウントされている場合
RPC要求の再送サイクルが繰り返されるのは、ファイルシステムがハードマウントされている場合だけ。
softオプションでマウントされているとRPCの再送シーケンスは最初のmajor timeout発生時点で停止。
そのため、中途半端なところできれてしまうと、書き込みかけたファイルをそのままにしてしまったりするので、読み書き可能の
マウントはハードで行うべき。retransマウントオプションで再送回数を増やせる。
タイムアウト時間の算出
ハードマウントの短所はサーバが復帰するまでクライアントがハングしてしまうこと。ファイルシステムをハードマウントする際に
「intr」オプションを指定するとキーボードからの割り込みが可能になって再送ループを停止できる。NFS再送アルゴリズムのタイム
アウト期間の求め方を示し、あまり長いのはいけないと解説。
ネットワークの信頼性の問題
パケットがブリッジやルータを通る際に欠落するような信頼性に欠ける場合にもNFSの性能は低下する。
「ntsstat -rc」のRPC統計情報を検討するとこのような事態もわかるとして解説。信頼性が低いネットワークではNFSバッ
ファサイズ小さくしろと書いてあった。またサーバとクライアントでそろえるといいとか書いてあった。
広域ネットワークでのNFSの利用
広域ネットワークでもNFSは利用可能。その際はバッファサイズを小さめにもっとも遅いリンクのMTUに揃える。RPCタイムア
ウトは長めにとる。
biodのチューニング
サーバが原因で機能が悪くなっているときに、クライアントマシン上で起動するbiodを増やすとNFS要求が増えて性能が悪
化する。biodを減らしても性能は向上しない、閃光読み出しや地縁書き込みが実行されなくなるのでスループットが落ちる。サ
ーバー上でbiodデーモンが４つ起動している場合書き込み要求が５つくると４つまでbiodがほかはプロセス自体がうけもつ。biodは
ブート時に数を指定される。
ファイル属性情報のキャッシング
NFSクライアントはファイル属性のキャッシュをもっている。（あまり変更されないので）
ファイル属性情報キャッシュのパラメータを解説、ベンダーによりディフォルト値は異なる。
マウントオプションで「noac」でキャッシュしないように設定できる。ただしファイル情報にアクセスするすべての場合サーバにつ
ながないといけない。こうなるとサーバが処理するNFSコールの６０％が属性情報で占められる可能性がある。
一つのディレクトリで複数のクライアントが同時にファイルを作成している場合は、どのようなファイルが作成されたかをすべて
のクライアントができるだけ早く知りたい場合がある、このときキャッシュの時間を短くすべき。
「ls ファイル名」と「ls ファイル名の一部＋＊」ではワイルドカードをつかうとキャッシュが検索される可能性があるといっていた
。
マウントポイントの構成
非効率的なマウントポイントの構成の代表は、マウントポイントが飛び石的になっている場合と、サーバが中間にはいるシ
ンボリックリンク。理由を解説。
ルーティング情報
小規模ネットワークや、１台のルータで他のネットワークとの接続を行っているようなネットワークでは、ネットワークルーティン
グデーモンroutedの動的経路制御よりも、静的経路制御の方が適している。動的経路制御ではゲートウェイやルータホストが
３０秒ごとに経路情報をブロードキャストするが、ネットワークの出口がひとつしかないなら無駄だから。
ファイルのハンドル異常
あるクライアントがオープンしているファイルやディレクトリを他のクライアントが削除したりすると、そのファイルのファイルハンドル
が必ずおかしくなってしまう。このときのメッセージは「stale file handle」これがしょっちゅう発生しているならディレクトリを共有して
いるユーザやコピーされたプログラムを使用しているユーザをチェックしてみるべき。スクラッチ領域を別のユーザが消していることもあ
る。NFSファイルをユーザがどのように利用しているか知ることが大切。
第13章 自動マウント
オートマウンタ・・・NFSファイルを自動的にマウントするツール。NISでNFSコンフィギュレーションファイルを管理している。したがっ
てNISのマップひとつでネットワーク上のクライアントのマウント情報を管理できる。/etc/fstabの管理を自分でおこなわなくていい
というメリットもある。
オートマウンタを使うメリット
共通エントリを各/etc/fstabにいれなくていい。
マウントテーブルの管理が簡素化され、ユーザアカウント情報の管理が簡素化できる
オートマウンタが参照していないファイルシステムをアンマウントするので、NFSサーバがクラッシュしてもプロセスがハングしたまま
になる確率を大幅に下げられる。
NFSのマウントプロトコルを拡張しており、ネットワーク上に分散されている読み出し専用のファイルシステムをマウントするときに
「もっとも近い」サーバからマウントするようになっている。ネットワークの負荷が分散される。
rootにならなくてもマウントできる。
NFSサーバの追加や再構築にともなう管理作業が単純になる。
マウントするときに複数のサーバを探すので、クラッシュに強くなる、負荷分散できる。
*オートマウンタ・マップ
クライアント側からみて共通のパス名のプレフィックスで複数のファイルシステムをマウントするときは間接マップが
マウントポイントに共通のプレフィックスが存在しないとき直接マップが便利。
間接マップと直接マップの働きを例で説明。
オートマウントの構造
オートマウンタはシンボリックリンクをエミュレートする機能。
エミュレータ機能を実現しているオートマウンタの仕組み解説。カーネルがオートマウンタをNFSサーバと勘違いさせると書い
てあった。
直接マップ解説
絶体パス名でマウントポイントを指定。
＊オートマウンタの起動とマスターマップ
オートマウンタのマップ選択、起動を解説
オートマウンタは起動されるとNISのauto.masterマップをマスターマップとして読み込む。
マスターマップにはすべての直接・間接マップとそれに対応するディレクトリがリストされている。
マスターマップのエントリは、ディレクトリ名、マップ名、マウントオプションで構成されている。具体例をあげて、オプションやタイム
アウト時間（何分マウントしていなかったらアンマウントするか）を解説。
＊NISの利用
オートマウンタで使用する3種類のマップをNISで管理する。NISマスターサーバのMakefileにオートマウンタマップのエントリを追
加する方法を解説。
マップの変更はプッシュされた時点で行われる。
現在マウントしているファイルシステムのパラメータを変更するには、一度アンマウントしてからオートマウンタにSIGHUP(kill -l
）シグナルを送る。
直接マップだと書き換えてから再起動が必要。
＊キーや環境変数による置換
キーによる置換
＆はマップのキーに対応する文字列で置き換えられる。などの解説。
オートマウンタの右側の要素を環境変数（＄ではじまる文字列）で置き換えられるなど解説。
＊高度なマップファイルの利用
サーバーを複数指定し、一番近いサーバーを選択する機能解説
階層マウント・・・同一のサーバから複数のファイルシステムを階層的にマウントする機能。解説。
直接マップの間接マップへの変換解説。
＊オートマウンタの副作用
検索パスに多数のディレクトリが入っていて、これらのディレクトリのいくつかに自動マウントがはいっていると、ログインが完了す
るまで時間がかかる
ローカルマウントしている場合、ファイルを指定をローカルホストのパス名で行うか、オートマウンタのパス名で行うかでpwdで表
示されるディレクトリのパス名が異なる。
夜中に起動されるfind作業や、claenderユーティリティなどcronによって起動されるユーティリティはオートマウンタを用いると無
駄な処理を行うことがある。
pwdコマンドはカレント・ディレクトリを順にさかのぼっていくことでシンボリックリンクの展開をおこなうので、オートマウントされたデ
ィレクトリで用いると予期しない結果がでる。シェル変数のcwdを使うとよい。
オートマウンタを kill -9で停止しないこと。SIGTERMを使うと問題なく停止できる。
第14章 PC/NFS
PC/NFSは、DOSをオペレーティングシステムとするIBM互換機上で動作するNIFプロトコルのクライアント専用の実装。
これによってNFSファイルシステムを論理ディスクとしてマウントし、大容量DOSディスクとして使用することができる。
PCが常にNFSの実行主体となる。転送の種類や方向は限定されない。
＊PC/NFS設定
PCの設定、nfsconfというプログラムで行うのがよい。
起動ファイルにコマンドを追加する方法、PC/NFSの設定ユーティリティが追加した行を書き換えるための情報について述べ
る。
＊PC/NFSの起動
ブートの時点でNISが利用できるように、NETWORK.BATが最初に実行されるようにする。
net ypdomain コマンドでドメイン名を設定。
net ypset コマンドで、設定されたドメイン名でNISマップを扱うサーバをみつける。
PC/NFSではUNIXマシンでPC/NFSユーザの認証情報を確認している。標準設定できはNISサーバと認証サーバは同一
マシン。
最後はネットワーク・リダイレクタを起動させる。 net start rdr 普通NETWORK.BATの最後に書いてある。Reverse ARP
をブロードキャストしてPCのIPアドレスを得る。
サーバの設定
PC/NFS用のサーバデーモンが一つ必要pcnfsデーモン。
＊PC/NFSの利用
ファイルシステムのマウント ダブル・バックスラッシュに続くサーバ名とファイル名をつかう、例で解説。
ファイルパーミッション確認 PCユーザーがUNIXの認証サーバにログインすることで、制限の厳しいパーミッションから解放され
る。
ファイル名の変換。
UNIXのファイル名の長さは通常14文字、システムによって最大256文字。大文字小文字混在可能、バンクチュエーション
記号利用できる。
DOSは8文字と拡張子。大文字だけ。ドットではじまるファイル名は不可。
この二つのファイル形式の変換法則を解説。
シンボリックリンクはDOSでサポートされていないが、PC/NFSは若干の制限つきで利用できる。
ファイル内容の変換法則解説。
＊プリンタサービス
PC/NFSによるプリント作業は、プリントファイルをホストにコピーし、そこからプリントするのと同じ。
net use lpt1: サーバのパス名として指定したUNIXプリンタ名 でプリンタ指定。
出力のリダイレクトで、ファイルの内容を直接プリンタに送る場合、DOSはすぐに送る（シングルタスクだから）がUNIXでは魔う
ちタスクなので一旦スプールする。
PC/NFSのプリントメカニズムをpcnfsdデーモンなどの動きとともに解説。
＊ネットワーク・リダイレクタの動作
PCのディスクをUNIXにマウントすることはできない。DOSがシングルタスクだから。
ネットワーク・リダイレクタは通常DOSの入出力に送られる要求を横取りして適当なNFSサーバに送出するためにRPC要求
に加工する仕組み。UNIXのbiodデーモンと同等のもの。
＊PC/NFSネットワークの管理
PC/NFSのネットワーク管理用ツールを使うことでリモートUNIXサーバへの経路の指定、PC/NFSの統計情報表示。PCク
ライアントの性能の最適化を行うためのネットワーク・ドライバの設定を行える。
PC/NFSでのルーティング DOSではディフォルト回路が一つだけ設定されている。「net route ホスト名」引数なしだとディ
フォルト経路がでる。
ネットワーク上のサーバへの経路を調べる 「netstat -r」
PC/NFSで提供されているネットワーク診断ツールと解説。UNIXでのものとあまり変わらない。netsat arp nfsstat nfsping
PC/NFSでは、NFSバッファサイズも小さく、バッファやキャッシュの管理が制限されているので、NFSサーバに対する要求も
異なる。PC/NFSのクライアントがネットワークに追加された場合の観察は、10章、12章を参照しておこなう。
マウントパラメータのチューニングはCONFIG.SYSファイルのPC/NFSドライバの行で設定を行う。「DEVICE=C:\NFS
\PCNFS.SYS オプション」オプションの解説。エラーの解説。
AppendixA 伝送経路理論
物理層の特性をきめるもの。ＮＦＳなどの上位レベルプロトコルとは直接会関わりはないが、物理層の制約を守らないと断続
的で奇妙な問題が上位層でおこることがある。
伝送経路輪・・・通信線路を移動する信号の波長よりも長い線路のこと。
信号の周波数が高ければ高いほど、波長は短くなる。よって、高いほど短い線路での信号特性について解析しなければらな
ない。イーサネットで使用される波長は約１メートル。だから２台以上のワークステーションがあれば、伝送経路理論の適応対象
。
どのような信号導体にも、導体固定の静電容量とインダクタンスがある。イーサネットのバックボーンケーブル長に制限があるの
は容量負荷効果のためである。周波数がひくいとケーブルが理想的でなくても無視できるが、イーサネットがデータ転送に使用
している10MHzの周波数では無理。
イーサネットケーブルを同じふるまいをする電気回路で説明。電圧の移動や終端について解説。
イーサネットケーブルのインピーダンスは50オームでこれはターミネータの抵抗値。
ネットワークの使用中は行えないが、テスタを「抵抗測定レンジ」にして同軸ケーブル芯とアース間の抵抗値を測れば25オーム
になるはずである。
ネットワーク・ケーブルを調べておくことで、潜在的問題を解決することができる。
AppendexB IPパケットの線路制御
ルータはユニークなIPアドレスを持つ複数のネットワークインターフェースを持っている。またIPアドレスにはユニークなホスト名が対
応している。一般にセカンドネットワークインターフェースに対応するホスト名には-gwを使加えたホスト名が持ちいられる。
「netstat -i」で双方のインターフェースとそれに対応するネットワークとホスト名を表示できる。
ローカルネットワークが他のネットワークにどよように接続されているかとう情報を変更する方法
１ 動的経路情報はホストから定期的に宗主されin.routedなどのデーモンがその情報を解釈してルーティングテーブルを更
新する。
２ 静的経路情報はコマンドで手動で設定される。ネットワークにルータが1台しかない場合などに使う
３ 別のネットワークにパケットを転送するために選択されたルータが最適でない場合、選択されたルータが経路のリダイレク
ションメッセージ要求を実行。このICMPリダイレクトメッセージでルーディングケーブルが更新される。
現在のルーティングテーブルの状況を調べる「netstat -r」とその結果の解説。
ARPブロードキャストが同一ローカルネットワーク内しかいかないが、リモートのIPのホストと通信できるわけ解説。（MACアドレス
が変換されていく）
通常２つ以上のネットワークに接続されたホストは、自分のルーティングテーブルを参照しながらIPパケットの転送を行うように
設定されているが、通信はおこなってもネットワーク間の転送を行わないようにしておくと、セキュリティが増す。「adbを用いてカー
ネル変数のip-forwardingの値を変更する」
AppendexC NFSのトラブルシューティング（本編のまとめてきに）
NFSサーバの問題
netstat -s の出力について
badcalls>0 ユーザ認証の問題
nullrecv>0 NFSサーバデーモンの数を減らす。
symlink>10% サーバが公開しているファイルシステムのシンボリックが多すぎる
getattr>60% NFSクライアントのファイル属性情報キャッシュの大きさが小さすぎるか０になっている。
null > 1% オートマウンタからマウント要求が頻繁に発行されている。マウントタイムアウトのパラメータ値を増やす。
NFSクライアントでの問題
netstat -cの出力について確認
timeout >5% サーバが応答するまえにクライアントのRPC要求がタイムアウトしているか、サーバに到達していない。bacxid
フィールドを調べる。
badxid-timeout 再送した要求もサーバで処理され、クライアントがサーバからの応答を重複してうけとっている。要求の再
送を短くする。
badxid=0 タイムアウトが多い場合NFS要求や応答の一文がクライアントとサーバの間のネットワーク上で落ちてしまってい
る可能性がある。rsize, wsizeのマウントパラメータをつかってNFSのバッファサイズを小さくすることで解決することがある。
badcalls>0 ソフトマウントされたファイルシステムに対するRPCがタイムアウトしている。サーバクラッシュの直後は問題ない。
NFSのエラーコード解説
EINTR ハードマウントされたファイルシステムでintrオプションが設定されていて、システムコールが中断された。
EACCES 妥当なユーザ権限をもたないユーザがファイルにアクセスしようとした。
EBUSY NFSクライアントで使用中のファイルシステムをスーパーユーザがアンマウントしようとした。
ENOSPC クライアントがNFSのwriteオペレーションを実行しようとしたが、ファイルサーバのディスクスペースが足りなくなって
いた。
ESTALE NFSクライアントが参照しようとしてサーバに要求を発行したi-ノードが別のクライアントによりすでに削除されて
いた。
EREMOTE サーバにNFSマウントされているファイルシステムをNFSマウントすることは許されていない。
AppendexD NFSのベンチマーク
クライアントからの負荷を生成する方法
Legato Systems社のnhfsstoneユーティリティ
シェルスクリプトにファイル操作をさせる
二つの方法について解説
どちらにしても現実実況をそっくりシュミレートするのは難しい。
末尾に索引。
今ではかわっているところもある。
大型コンピュータを何百人のユーザーが使用していた時代が終わり、ローカルエリアネットワークが使われだして10年。
ネットワークによる分散処理が普通になり、ファイルサーバー、計算サーバー、プリントサーバーといった専用システムを介して計
算機資源を共有する時代。
分散処理環境下では使いやすく有機的なネットワーク構築ができる反面、管理が複雑になる。
ネットワーク上の各マシンにすべてのファイルとコンフィギュレーション情報を一貫性をもって提供することが必要で、
それを意識しないで利用できる仕組みがNetwork File System(NFS) と Network Infoation service(NIS）
どちらもSun Microsystemsが開発したプロトコル。
NISを利用するとパスワードファイルなどの同一の内容を複製して維持すべきコンフィギュレーションファイルを、1台のホストで集
中管理できる。更新もホストのみですむ。
NFSを利用すると、ネットワークを意識しないで、リモートファイルシステムを使用できる。
すべてのマシンで１つのファイルセットを共有できるので、そのセットのための物理的なスペースがネットワーク上のどこか1か所にあ
ればいい。
NFSはファイルシステムの物理的な保管場所を意識しないで、ネットワーク上でファイルシステムを自由に使用できる仕組みだが
、ユーザー情報グループ情報がまちがっているとアクセスできない。
NISでサービスすることで、どのワークステーションからでもそれが自分のグループのものであれば、自分のホームディレクトリにログイ
ンできて、資源を利用できる。
またコンフィギュレーションやディスク資源を一括管理できることはシステム管理者にもありがたい。
NFSをつかえばなんでもかんでも手に入るが、それよりは簡潔なネットワーク構成を考えること。
必要なファイルやユーザアカウント情報、システムサービスに”だけ”アクセスできる簡潔さは、多くの利用者を扱い、システム管理
者の労力を軽減する役にたつ。
対象読者
NISやNFSを使用しているシステム管理者ネットワーク管理者。
これから導入を検討している人。
UNIXのシステム管理やTCP/IPネットワーキングの基礎知識がある人。
目的
NFSやNISを使用して分散処理環境下でしばしば遭遇する問題の解決方法を紹介すること。
個々のベンダーのユーティリティーなどにはふれない。
対象バージョン
SunOS4.1 NFSとNISの実装に準拠。SunOS4.0でもあてはまる。
PC/NFS3.5準拠
第1章から9章
NFSとNISの実装と操作の解説
第1章 ネットワーキングの概要
NIS・・・共通コンフィギュレーションファイルを分散データベース化してNISが管理する。NISクライアントはローカルなコピーを使
用しないでNISサーバーに要求する。
NFS・・・分散ファイルシステム、NFSクライアントはNFSサーバにあるファイルシステムをマウントしてローカルディスクのように使う
。
ISOの7階層モデル
層７ アプリケーション NFSおよびNIS
層６ プレゼンテーション XDR 異質なネットワークで有効。
層5 セッション RPC ネットワーク接続の設定と維持の定義
層4 トランスポート TCPまたはUDP ネットワーク層にあわせてデータ分割。着信の信頼性を確保。ポート番号
層3 ネットワーク IP データフォーマットの互換性をとる。データグラム。 IPアドレス
層2 データ・リンク ネットワークのデータフォーマットが定義される 「パケット」 MACアドレス
層1 物理 イーサネット
下位層のレベルが正常に動いているのが前提でNFSとNISは動作する。
IPアドレスの予約番号
０・・・ネットワーク番号を作成するためにプレースホルダーとして使用される。またIPブロードキャストアドレスとして使用される
ことがある。
１２７・・・ホストのループバックインターフェースに使用される。
２５５・・・IPブロードキャストアドレスに使用。
RPC・・・リモートプロシージャコール。ローカルシステム内で処理されるように見せながら実際にはネットワーク上の別のマシンで
プロシージャ・コールを実行する仕組み。
XDR・・・カノニカル形式と呼ばれる固定ネットワーク・バイトおーだリングに基づいて構築されている。個々のマシンの特異性と
は無関係に構造体データ（バイトストリームと対比した場合）の受け渡しが簡単にできる。
コネクションレスサービス・・・接続時間の長いconnectionをクライアントサーバーで生成する必要がない。
RPCはコネクションレスサービス。要求を送信し、応答を受信するためにサーバーと交信するが、そのための接続手続きは必要
ない。RPCサーバーはブートプロセス時に起動され、シングルスレッドで実行される。２つたてられることもあるが、sの場合要求は
待ち行列に入る。ポートやスーパーサーバは使わず、etc/rpcのサービス番号が指定されている。RPCプログラム番号からポート
番号へのマッピングには、ポートマッパデーモンを使用する。よってクライアントからのRPC呼出にはポートマッパデーモンが走ってい
る必要がある。
第2章 ネットワーク・インフォメーション サービス機能
ＮＩＳを使って分散型コンピュータ環境で、共通コンフィギュレーションのファイルを個々のマシンで持たず、一括で管理することで
、大規模なネットワークでも一貫性を確保できる。管理するのはパスワードファイルやグループファイル、ホストファイルといった、共
通するもので、ホスト固有の情報を含むもの etc/ftab などは含まない。
２．１マスター、スレーブ、およびクライアント
ＮＩＳはクライアント・サーバーモデルで構築されている。
ＮＩＳサーバーはマップと呼ばれるＮＩＳデータファイルをもつホストのことで、クライアントはこれらのマップにデータを要求するホス
トである。
ＮＩＳの一つのマシンだけがマスターとなり実体＝ＮＩＳマップをもち、それがスレーブ・サーバーにコピーされ、ＮＩＳクライアントは
自分のローカルファイルでなく、ＮＩＳのマップをみにいく。変更はマスタだけで行う。扱うマップはドメインと考えられる。
マップごとにドメインをつくることができる。各マシンはディフォルトドメインがあり、参照するＮＩＳマップが特定されている。小規模
ネットワークでは通常ドメインは一つである。
２．２ＮＩＳ管理の基本
ＮＩＳの動かし方。ＮＩＳサーバーを設定して、クライアント・ホスト上でＮＩＳが稼働するようにすること。
NISサーバーは可用性と要求処理能力が十分なものを選ぶ。サーバーからの応答がおそければクライアントはスレーブ・サー
バーを探す。各マスターサーバーにはすくなくとも一つスレーブ・サーバーをもたせたほうがいい。スレーブ・サーバーとのマップファイル
の同期も重要。
サーバー作業
・新規のＮＩＳ環境をインストールし、マスターおよびスレーブ・サーバーを構築する。
・システムをＮＩＳのサーバーとして働かせるypserveデーモンを起動
・ネットワークの規模が拡大したりＮＩＳの性能向上のためサーバーの処理能力がさらに必要になった際に、新規のスレー
ブ・サーバーを追加する。
クライアント作業
・クライアントの管理ファイルを修正し、クライアントがＮＩＳを利用できるようにする
・ypbindデーモンを起動し、クライアントがNISに要求を送出できるようにする。
マスター・サーバーの設定説明。
NISで管理されるファイル（UNIX標準ファイルの他に/etc/netgroup）
インストール方法は、まずドメイン名を決めて、/etc/passwordファイルに+::0:0::が無いのを確認して、初期化コマンド
（/uer/etc/yp/ypinit -m）実行。ドメインにマスターは一つだけ。NISサービスを起動(ypserve）。普通サービス起動はドメイン
名が設定されているば行われるようにrc.localに書いてある。
スレーブ・サーバーの設定説明
初期化コマンド（/uer/etc/yp/ypinit -s NISマスターサーバー名）実行。
自動でマスター・サーバーからマップファイルをコピーする。
スレーブ・サーバーはマスタのypserversマップに追加される。ypcatでダンプして追加する。
クライアント・ホストの設定説明
クライアント上のコンフィギュレーションファイルにNIS「マーカ」のエントリ（/etc/password や /etc/groupのLではじまる
行）が必ず含まれているのを確認。これがないとNISマップ情報をローカルファイルに組み込めない。
domainnameユーティリティでクライアント上のNISドメイン名を設定する。
NISサーバを決定しドメイン名からサーバーをさがし、バインドを行うypbindデーモン起動。
NISが動いて、もローカルのコンフィギュレーションファイルが参照されなくなっても、は消さない方が良い。単体でたちあがれ
なくなるので。特に/etc/hostはNISが動きだすまでに必要なので消してはいけない。
NISサーバーをクライアントとしても動作させるのは、やったほうがいいといっていた。
ただし、セキュリティが弱くなるので別のパスワードファイルを使うなどの対策をとった方がいいといっていた。
２．３NISにおけるファイルの管理
NISで管理されているファイル中でとくに共通性の高いもののリスト。マップ名、ニックネーム、アクセス方法（検索キー）、内
容（ファイル名） マップの利用形式（追加、置換など、ローカルファイルに対する操作）の順にのっていた。マップとファイルは1対1
ではない。
netgroupはNIS管理のための新規のデータベース。/etc/groupとは異なり、記述の簡略化やニックネームを作成するため
の仕組み。
NISマップとローカルファイルの統合。NISマップのオーバライド。
＋記号を使うとNISマップまたはマップの一部をNISにより補てんされるファイルに組み込むことができる。passwordファイルな
どで説明していた。
２．４ NISの設計と実装
NISはRPCプロトコル上に構築され、クライアント・ホストからサーバーへの要求転送にはUDPトランスポートを使用している
。NISサービスは標準UNIXライブラリコールに組み込まれている。例えば/etc/paswordを読み込むのに使われるのは既存の
getpwuid()である。そのためNISを使用するために既存のソフトウェアを変更する必要はいっさいない。
マップファイル
DBMデータベースファイル（UNIXに実装されたもの）で構成されている。
キーワードと値の組み合わせのテーブルをもち、高速検索する。
マップ構成や名前、DMSデータベースの生成方法などが解説されていた。
NISドメイン・・・同一セットのマップを使用するホストのグループ。ドメインに属するすべてのマシンはパスワードファイル、ホス
トファイル、およびグループファイルに関して同じ情報を共有する。
ホストが属するデフォルトドメイン名を設定するにはdomainnameコマンドを使う。
Internetドメイン・・Internetworkネームサービスにより管理されているホスト・グループを指す。共通の管理下におかれたホ
ストのグループとして厳密に定義されている。
ypservデーモンが起動していればNISサーバである。このデーモンが要求を処理する仕組みを解説。
ypbindデーモンが起動していればNISクライアント 。クライアントプロセスとサーバをバインドする、あとはサーバとやりとりしな
い。
NISサーバとクライアントのイベントシーケンスをgetpwuid()ライブラリコールを例に説明。ローカルでみつからないとNISを使用
して探す。まずypbindがサーバ情報を返し、NISサーバーに要求をおくるとｙｐservが処理して返す。タイムアウトが発生すると
ypbindが以前つないでいたサーバ情報をつかって再接続をこころみる。何回か失敗すると他のサーバを探す。
NISを使用しているマシンは、NISとのバインドが切れるとほとんど使えない。信頼性のなるNISサービスが必要である。
３章 NISを用いたシステム管理
NISを使っても、マップ参照の負荷や、NISのメンテナンスツールの負荷で、ユーザの通常の作業を邪魔しないようにしなけ
ればならない。
NISドメインをいくつ使用するかは、計算機資源をどのように分割したいかによる。よく使われるのは管理用のドメインとネッ
トワーク用のドメインの２つに分割する方法。
上記の判断基準は
・独自のネットワークを持つ分離されたグループのために別個のドメインを用意する。
・独自のシステム管理者を持つシステムのグループには、各グループごとに別個のNISドメインを用意する。
ただし、特定のマシンへのアクセスを一部のユーザに与える為の手段としてNISドメインを確保してはならない。特定の分割
グループを作成するための最善策はネットグループを使用してドメインの部分集合を作成する方法。
ドメイン名のつけ方例、ユニークであれば制約がないが、例として階層的な名前などをあげていた。
NIS要求を延々と生成するタイプの作業はまれなので、NISドメインに能力が同等のクライアントとサーバがあるなら、クライ
アント３０-４０にサーバ一つくらいが目安になる。もちろんブリッジされているなどの状況によって変わる。
マップファイルの管理は、マスターでmakefileとNISのMakefileを利用してスレーブに送りつける（PUSHする）方法と、ypxfrを
使用してスレーブ・サーバからマップを取り出す（PULLする）方法がある。
他にcronを使ってypxfrの機能を使って、定期的にマップを転送するようにすべき。
恒久的な変更はマスターで行わないとできない。スレーブを変更しても上書きされる。
管理者が複数いてマスタの変更を同時に加えて矛盾が発生しないように、、SCCSまたはRCCを利用する。
パスワードファイルの更新を例にマップの管理を説明。
SCCSでの管理方法を説明。
標準以外のマップ作成方法を、/etc/password 意外のファイルからパスワードマップを生成する例で説明。
NISサーバ管理
プリンタスプーラの変更など、サーバを移動させるような場合の記述がマニュアルにないらしい。
スレーブサーバの移動方法・・・そのマシンのホスト名をypserverマップから取り除き、そのマシンの上のNISを止める。
マスターサーバの移動・・・新規にマスターにするマシンにスレーブをたちあげる。ここで新しいマスターの構成の新規マップを
作成。これをマスターにypxfrで吸い上げる。これをすべてのマシンに配布。元マスターをNISサービスからはずす場合はypservers
からはずす。
マルチドメイン・・・単一のサーバーが複数のマスターのスレーブになっているとか、マスターでありながら、他のマスターのスレ
ーブだとか。
ypserversマップでドメインごとに設定される。例として、host,alias,rpc,servicesは共有しながら、異なるpasswordと
groupをもつマルチドメイン構成があげられていた。
NISとDNS
DNSの利点は、名前管理が分散されること。自分の管理下の名前をどう変更しようとも、中央に通知する必要がな
い。もちろん同じ名前がついていても区別される。
NISをDNSの最下位構造に組み込むことができる。いくつかのネットワークがDNSドメイン内に存在し、複数のシステム
管理者により管理されている＝NIS
NISとDNSの統合方法
・NISをDNS抜きで走らせる＝ディフォルト
・NISマップを参照して解決できない時にはDNS使用する。NISのhost関連のマップを-bフラグをいれて生成する。
・ホスト名についてはNISを無視してDNSを使用する。ホスト名を検索するライブラリルーチンを再構築してNISのラ
イブラリコールを取り除く必要がある。
NISとDNSを同時に使うときはNISのドメイン名とDNSのドメイン名を対応させる。DNSドメイン名.NISドメイン名にして
おくとよい。
第4章 ＮＩＳを使用したアプリケーション
ＮＩＳを利用したカスタムアプリケーション。
方法は３つ
１．ypmachやypcatなどのNISクライアントツールを利用する方法。
例としてASCIIファイルをNISファイルに変化し、電話番号のNISマップを参照する。
２．NIS固有のツールを使い、rdistなどのUNIXのユーティリティ機能を拡張したりエミュレートしたりする。
コンフィギュレーションファイルからクライアントが必要な情報を取り出す方法。
rdistとgrepの機能を合わせたようなホスト固有の集中管理をつくる。
３．NISクライアント・ライブラリを使い、CプログラムからNISドメインのすべてのマップにアクセスする方法。
NISのライブラリコールの紹介。例としてSunが寄付で作っている株価情報サービスで、寄付者のNISマップとユーザー名
を照合するプログラムをあげていた。
第5章 NFSを用いたシステム管理
Network File System(NFS)は、分散型ファイルシステム。
NISがユーザやホスト情報を集中管理できるように、NFSはいくつものディスクを集中管理できる。
/user/localのような共通ディレクトリを全システム上に重複してコピーするかわりに、NFSでは１つのコピーを1か所に保管す
る。
NFSを利用することによって、ホストはリモートとローカルの区別なくファイルを利用できる。
NISとNFSはいっしょに利用されることが多い
NFSもRPCプロトコル上に構築されている。ホスト間にはクライアント・サーバー関係が成り立つ。
NFSサーバーは１つまたは複数のファイルシステムを持ち、ネットワーク上の各ホストに対しそれらのファイルシステムを利用可
能にするホストのこと
NFSクライアントは、１つまたは複数のサーバーからファイルシステムをマウントするホスト。
NFSの資源は、すべてのクライアントによって共有されるサーバー上の物理的んディスクドライブのこと。
NFSを介してシステムを管理するには、ファイルシステムの名前付けとマウントの枠組みを考える必要がある。
枠組みが決定したら、それにあわせてサーバーとクライアントをどのように配置するか考えなければならい。
名前付け規則はネットワーク自体の存在を意識せずに、ネットワークから利用できるようなものにするのが目標。
ユーザーがNFS自体の存在を意識しないのがよい状態。
何百台ものクライアントがつくと複雑で手に負えなくなりがち、上手に管理するには標準的な手順に若干の知性を加味す
る必要がある。ネットワークの一貫性を維持するコストが大きな管理オーバーヘッドとなってはならない。管理ツールオートマウンタ
などを使う。
NFSの設定
クライアントとサーバーでNFSを設定するにはNFSRPCプロトコルのデーモン、ファイルロッキングなどの補助的サービスのデー
モンをを起動。その後NFSサーバーからファイルシステムを公開（export）し、クライアント上でマウント。
クライアントでNFSを使用するには、biod rpc.lockd rpc.statdデーモンを起動(ブート起動が一般的）
ネットワークに公開されるファイルシステムを持つホストがNFSサーバー。
サーバーは現在公開しているファイルシステムとファイルシステムのアクセス制約情報をファイルテーブルとしてもち、NFSマウン
トの要求があればｍ要求されたファイルシステムをテーブルに登録されているエントリと比較する。
サーバーはブート時に/etc/exporttsの存在をチェックして実行。その後nfsd epc.mountdのデーモンを起動。
公開の法則と、オプションを解説。
NFSクライアントはNFSサーバーが公開したファイルシステムであれば、どのようなものでも、一部でもマウントできる。
方法は/etc/fstabファイルに登録するか、mount(8)コマンドを使用する。
両方の方法の詳細を解説。
マウントは普通すべてhardで行われ、タイムアウトしてしまったRPCはサーバーが応答するまで再実行される。
マウントでよく起こるエラーメッセージの解説。RPCが何回もタイムアウトしていたり、別のクライアントにファイルが削除された
りする事態が想定できる。
NFSにおけるシンボリックリンクの解釈。サーバーで解決されて返されたパス名が、クライアントのファイルシステムの範囲外の
場合エラーになる。相対的シンボリックリンクは、クライアントのファイルシステム上のリンクが置かれた位置から解釈され、サーバー
上のファイルシステムでは解釈されない。マウントしようとしたサーバー上のファイルシステムがシンボリックりんくだった場合奇妙なこ
とがおこるかもしれない。
名前付け規則
簡潔で効率的な方法で名前が管理されているファイルシステムは使い勝手がよい。そのための規則
・ユーザのホームディレクトリは/home/hostnameを使用する。
・各ユーザのホームディレクトリのマウントで/home/homenameでなく/home/usernameを利用する方法がある。こ
の方法だと/etc/fstabが大きくなるが、NFSオートマウンタを使用しているなら、この方が楽
・クライアントとサーバーの双方で同一のパス名を使用すること。
・システムの拡張性を念頭に入れておく。例サードパーティのプログラム用のシステムファイルを１つ用意する。
多機能ワークステーションで構成されているネットワークで/user/local/binに適切な実行ファイルだけを置く方法とし
て、個々のバイナリディレクトリに名にマシンの型を拡張子とつける方法を紹介。
各ユーザのホームディレクトリを指しているシンボリックリンクを/uというNFSファイルシステムにおいて、たとえホスト名がパ
ス中にあったとしても、ホームディレクトリやプロジェクトディレクトリを容易に見つけられる方法を解説。
6章 NFSの仕組み
NFSは実装上の設計や仕組みを知らなくてもインストールして使うことができる。しかし、動作不良や性能低下がおこったとき(
実際よくおこる）動作の仕組みをしらないと対処できない。
透過性のレベル
１ NFSがファイルの位置を隠ぺいしすべてのファイルがローカルであるようにみえる
２ ファイルシステム間のアーキティクチャの違いを隠ぺいする。
VFSで１を、v-nodeで２を実現している。
VFS・・・ファイルインターフェースのスイッチボード。
VFSオペレーションス・・・ファイルシステムの空き容量を調べるなど、全体に対する操作を行う・
V-nodeオペレーション・・・ファイルやディレクトに対する操作。
オブジェクトを指定する仕組み・・・UNIXは拡張子でおこなっているが、NFSはファイルハンドルで行っている。
NFSはPRCプロトコル型の通信なので、クライアントとサーバーが存在する。
NFSサーバー側ではnfsdデーモンがクライアントからのRPC要求を受け取る。
NFSサーバーがマウント要求を処理するために、パス名変換用のrc.mountdデーモンを起動する
biodデーモンはNFSの性能向上のためで、必須ではない。
クライアントからみるとread()やwrite()をしているだけで、NFSはこれらのシステムコールの拡張にすぎない。
NFSのRPCプロシージャは１６個。UNIXのシステムコールがどのようにマップされるかという視点で解説。
NFSのプロトコルはUDP（状態をもたないので、パケットの到着や到着順を保証しない）である。
このため、クライアントからのNFS要求はすべての情報を持つ必要がある。ファイルに書き込むなら、ファイルファンドル、オフセッ
ト、書き込みブロック数が必要。ここがwrite()システムコールとは異なる。
idempotentであり、同じ操作をなんど繰り返して要求しても有害な副作用は発生しない。NFSサーバーは最近の要求を履
歴して、同じ操作をよける処理をおこなっている。
ステートレスなので、サーバーやクライアントどちらがクラッシュしてもリブートすれば何事もなかったかのようにNFSが利用できる。
ここがデータベースなどと違うところ。
RPC要求はクライアントからサーバーに同時に１つずつ送出される。このときタイムアウトをつけており、タイムアウトになると再送
する。これを繰り返す。クラッシュなのか過負荷なのかの判別はしない。
サーバーは到着順にRPCを処理する。
サーバーがRPC要求の履歴を保持する期間は短めに設定されている。
NFSではVFSの定義によってすべてのファイルシステムにおいて同一のセマンティクスを保証している。
VFSを使ってファイルシステムを非UNIXセマンティクスとして実装することも簡単にできる。
オープンしているファイルが削除(remove)された場合の、NFSクライアントはrenameNFS要求をだして、一時.nfs.XXXX
というファイルをつくり、close(）されてから削除するという手順で対応する。
ファイルのパス名は下からLookup される。そうでないと間違ったサーバーにNFS要求を送ってしまうことがあるから。
例 cliantA% mount server1:/usr/local /usr/local
cliantA% mount server2:/usr/local/bin.mips /usr/local/bin
カーネルのディレクトリ核検索キャッシュ（DNLC)により、すべてのルックアップがNFSサーバーにいくわけではない。
多くのUNIXマシンのNFSの実装ではファイルのi-node番号、ディスクデバイス番号、およびi-node世代番号をコード化したも
のをファイルハンドルとして使用している。その他のマシン上でのNFSの実装ではそのマシン固有のファイルシステム情報をコード
化している。どちらの場合もファイルハンドルの構造を解釈できるのはNFSサーバだけである。クライアントからは見えない。存在
するのもサーバだけ。
よってクライアントからおかしくなったファイルハンドルに操作しようとRPCが実行されるとNFSサーバーは「stale file handle」を返
す。
ファイルハンドルがおかしくなって問題となるのは、あるユーザの作業が他のユーザが使用中のエリアを侵してしまったり、ダンプテ
ープからファイルをフルリストアするなどしたときである。このようなときはNFSクライアントをリブートする必要がある。
NFSがサーバー・クライアント・モデルと異なるのは、
クライアントプロセス自体が呼び出すだけでなく、クライアントのブロック入出力デーモンbiodからも実行されること。
性能を向上させるため、NFS九ランとおよびサーバのコードはサーバーデーモンの実行可能ファイルではなくカーネルにすべて
含まれている。
がある。
すべてのNFSコードがカーネルに実装されてはいるが、デーモンがいないと複数のNFS要求を並列に処理できない。
UNIXにおけるバッファキャッシュ・・・最近参照されたファイルブロックを格納しておくためのシステムメモリの一部。SunOS4.xや
System Release 4ではバッファキャッシュはページマッピングシステムに置き換えられいる。
NFSクライアント側のbiodデーモンはNFSの性能を向上させるためにNFSクライアント側のバッファキャッシュの補填と吐きだしを
おこなっている。先読みをするのでNFSクライアントの性能があがる。書き込みも一時バッファキャッシュに書き出しいっぱいになっ
たらNFSサーバーにRPC要求をおくる。
NFSデーモンプロセスはカーネル内にあるNFSコードをスケジュールを行うためのハンドルにすぎない。
read()システムコールの動きをクライアントとサーバのカーネルをとおして追跡。
・NFSマウントされたファイルに対してユーバープロセスがread()を実行。プロセスにはファイルの存在場所はわからない。
・VFSがファイル記述子を対応するv-nodeに変換、タイプに従った読み込み操作を呼び出す。VFSタイプはNFS。
システムコールはNFSクライアント読み込みルーチンを呼び出す。ファイルディスクリプタはファイルハンドルに変換。
クライアントはファイルシステム上でファイルの位置を示す仮想ノード(v-node)をローカルにもつ。ファイルがローカルならこの
ポインタはi-node NFSふぁいるであればNFSファイルハンドルを含む構造体を指している。
・クライアントの読み込みルーチンがローカルなバッファまたはページキャッシュ内でのデータ有無を返し、データがあればただち
に返す。
・データがない場合、クライアント・プロセスはNFS read RPCを実行。readは8KバイトのNFSバッファ全体を要求する。RPC
要求が完了するまで、クライアント・プロセスがスリープ。
・RPCパケットを受け取ったサーバはそれを処理するためにnfsdを１つ割り当てる。
nfsdコードはパケットを受け取り、実行すべきRPCを決定し、ディスク操作を開始。
nfsdプロセスはディスク読み込みの終了まち、スリープ。
ディスクの読み込みが終了した時点でカーネルはデータおよびRPC応答をクライアントに送り返すためにnfsdの処理を再開
。
・クライアント上の読み込みプロセスが再開。
NFS read RPC要求が返した8Kバイトバッファからデータを取り出される。データはキャッシュされる。
プロセスが呼び出したread()システムコールがリターンしプロセスの処理が続行される。
上記に平行してbiodデーモンにより送出されたRPCの先行読み込みファイルの先読みを行っている。プロセスがシーケンシャ
ルに読み込んでいれば、バッファキャッシュに必要なデータがなくなるまで、そうとう多くのread()システムコールを実行できる。
キャッシュ・・・頻繁に必要とされるデータを必要とされるところの近くに保持しておくこと。または将来必要とされることを見越して
データをまえもってロードしておくこと。
NFSのデータキャッシングとは、ネットワークを介してサーバにRPC要求を送出しないことを意味する。
分散型システムでは、複数のプロセスが同一のファイルに対して入出力を行っている場合のデータの整合性と一貫性を保証
することが重要。NFSのキャッシュ・ポリシーはクライアント・サーバ関係に状態遷移情報を組み込まずに性能を向上させること。
NFSではファイル属性情報はクライアント側にキャッシュされる。そして最小有効期間（通常3秒間）存在する。クライアントが
ファイルを書き換えると（ファイル属性を変更されると）それに伴う変更はキャッシュ上の情報に対して行われ、キャッシュの有効期
間もさらに最小有効期間の長さだけ延長される。最大有効期間(通常60秒）変更されなければ、キャッシュからフラッシュされる
。その際キャッシュ上のファイル属性情報が変更されていれば、サーバに書き込まれる。ディレクトリ属性情報も同様。
biodが先読みしたキャッシュ内容の一貫性を保証するには、ファイルの属性情報が使用される。
キャッシュ内容の一貫性自体が、キャッシュされているファイルの属性情報を使って行われる。
読み込まれたデータブロックをクライアント上にキャッシュしてもNFSシステムに状態遷移情報をもちこまない。
キャッシュ期間が長くなると、データの一貫性に問題が生じるの有効期間を限定する。
書き込みもクライアントにキャッシュするのは、サーバにキャッシュすると状態遷移情報が必要になるから。
write RPC要求の完了がクライアントに通知されるまえに、ディスクへの書き出しが必ず完了するようにするために、NFSの
write操作には大きなボトルネックが発生する。3回のディスク書き込み（inode 間接的ブロックポインタを更新するため、データブ
ロックの書き込みのため）があるので。そのためできるだけ大きい単位で書きだす。一度スピード・メモリに書き込むなどのボトルネ
ック解消策が使われている。
flush-on-close・・・同じファイルに対する入出力が複数のユーザによって実行されてもファイルの一貫性がそこなわれないよう
にする。ファイルがクローズされた時点ですべてのNFSバッファの内容をNFSサーバーに描きだす。
サーバのキャッシュ
・ファイル属性情報のためのi-nodeキャッシュ。ディスクから読み込まれたi-nodeエントリは可能な限り主記憶に格納されて
いる。メモリ上でファイルの属性情報が読み書きできるのでger-attributeなどが高速化される。
・最後に読み込まれたディスクエントリのためのディレクトリ名ルックアップキャッシュ(DNLC)パス名のと合わせのたびにサーバが
ディレクトリを参照しなくてよい。ディレクトリ検索はディス上で特定の名前を線形に検索するので、比較的コストの高い操作。
・ファイルから読み込まれるデータのためのサーバのバッファキャッシュ。NFSクライアントにとって効果的な読み込みキャッシュと
して機能する。
ファイルロッキング
複数のクライアントが同じファイルにアクセスする際のファイル内容の一貫性をより厳密に制御する。複数のプロセスが同時に
同じファイルにアクセスするのを禁止できる。ロッキングは状態遷移情報を使用する操作でNFSの設計思想とはうまく適合しな
い。しかしUNIXファイルシステムのセマンティックスをすべてのファイルについて維持するという目標に適合する。
UNIXのファイルロッキングスタイル
BSDスタイル・・・システムコールflock()ローカルの実を対象。
SystemVスタイル・・システムコールfcntl()とlock()ライブラリルーチンによって実装。
RPCのロックデーモンrpc.lockd
クライアントとサーバ双方で起動。/etc/sm と /etc/sm.bak陵ディレクトリでロック状況を記憶。サーバのリブートの通知
も行われ、同じファイルロック状況をサーバ上に再構築する。
クライアントが停止しているときは、ステータスデーモンプロセスを終了し、/etc/sam/bakから当該ファイルを削除して
rpc.statdを再起動。
クライアントがリブートすると、rpclockdはクライアントのロック情報を回復しようとすると、リブートされたクライアントには情報
は残っていないので、結果的にサーバー上のロック情報も消去される。
NFSの今後
・繰り返し要求のサーバ上でのキャッシング。また、クライアント側での再送アルゴリズムのさらなる高速化
・AppleShareプロトコルコンバータを介してのNFSの使用。
・IBMのMVSなど、非UNIX系プラットフォームへのNFSサーバーコード実装。
など
第7章 ディスクレス・クライアント
SunOSまたはSunOS系サーバのディスクレスクライアントについて説明。
ルートファイルシステムとスワップファイルシステムのサービスに関してNFSを、ホストのコンフィギュレーション情報はNIS
を介して行うのが前提。
ローカルな資源を持たないマシンを、ネットワークの一員として稼働させるのは、NFS、NISでもっともやっかいな部分。
ディスクレス・クライアントのためのNFSサポート
SunOS4.0以前はディスクレス・クライアントはNDと呼ばれる分散型ファイルシステムプロトコルを課して別個にサポートされて
いた。
SunOS4.0ではディスクレス・クライアントのサポートはすべてNFSを介して実行される。これはSunオペレーティングシステムのフ
ァイルへのスワッピング機能（ページングでの仮想記憶管理システムでファイルをスワップエリアとして使用できる）と、NFSプロトコル
のNFSファイルシステムをルートディレクトリとしてマウントできる機能のおかげである。
ディスクレス・クライアントはVFSオペレーションのmount_root()を使って、マシンのルートデバイスにする。このため別のプロトコ
ルを使用してルートファイルシステムとスワップファイルシステムのための物理的ディスクブロックをサーバファイルシステムブロックにマッ
プする必要がなくなった。
ディスクレス・クライアントの設定
適切なオペレーティングシステムをブートサーバ上にロードする。
クライアントとサーバのアーキテクチャが同じであれば、/usrと/usr/kvm両ファイルシステムをクライアントとサーバが共有する。
異なっていればクライアント用の適切な/usr と /usr/kvmがサーバに必要。稼働中のマシンのカーネルアーキティクチャを調べ
るには % arch -k コマンドを使う。
クライアント洋のルートファイルシステムとスワップファイルシステムは サーバーの/export にあるのが一般的。
オペレーティングシステムがロードされていれが、追加するクライアントのホスト名とIPアドレスをNISのhostsマップに登録
追加するクライアント用のブートパラメータを設定 /etc/bootparams
追加するクライアント・システムのMACアドレスとホスト名をNISの ethersマップに登録。クライアントのMACはネットワークケー
ブルを抜いて起動するとわかる。
追加するクライアントのエントリをサーバの /tfpbootディレクトリに登録
追加するクライアントのルートファイルシステムとスワップファイルシステムをブートサーバ上に作成 /etc/exports（マウントでき
ること）
exportsファイルの具体的な例。
ディスクレス・クライアントのブートプロセス
ディスクレス・クライアントは電源投入時にもっているのは48ビットのイーサネットアドレスのみ、これをブロードキャストでリバース
ARP要求するのがブートプロセスの仕事、このとき飛ばすRARP要求はTCP層やUDP層ではなく、Netwrok Interface Tap
（NIT)デバイスで検出される。よってサーバ側に/dev/nitがなかったり、カーネルにNITデバイスが組み込まれていないとディスクレ
ス・クライアントは起動できない。サーバーは受け取ったRARP要求をrarpdでIPアドレスとホスト名に変換して返す。このとき
/tfpboot をチェックして自分がサーバを起動するのに最適でないと判断すると応答をおくらせる。
ちなみにRARP要求に応答するホストは一つではない。
次にブートブロックをftp(trivial ftp)を使って取得する。これは最小限度のファイル転送用ユーディリティでユーザやパスワード
のチェックをしない。ダウンロードは/tfpbootから行われる。
サーバはクライアントのアーキティクチャについて/tfpboot ファイルから得る。
RARP要求を返したホストにブートブロックがなければクライアントはｔｆｔｐ要求をブロードキャストする。
/tftpbootに登録する最後のエントリは自分自身へのシンボリックリンク。これを取り除くと古いタイプのディスクレス・クライアン
トが正しいブートブロックをダウンロードできなくなる。
ブートブロックがロードされうとディスクレス・クライアントはPROMのモニタからブートコードにジャンプする。
ファイルシステムの情報を入手するためにbootはブロードキャストでブートパラメータを要求する。
これに応答するのはrpc.bootprarad を実行しているサーバ。ルートファイルシステムの場所。クライアントのホスト名。ディフォ
ルト経路、NISドメイン名、およびブートサーバ名をひとまとめで返す。この情報は/etc/bootprarams か bootpraram NISマッ
プに登録されている。クライアントに渡されるNISドメイン名はサーバのディフォルトドメインである。異なるNISドメインに属するクラ
イアントの情報を同一のbootpraramasマップに登録はできない。
ディスクレス・クライアントは指定されたブートサーバから自分のルートファイルシステムをマウントして、そこに置かれたカーネルイ
メージをブートする。カーネルもスワップファイルシステムを決定するのにブートパラメータを要求し、これに答えるのも
rpc.bootpraramd である。そしてクライアントは起動する。ちなみにrpc.bootpraramdデーモンが返す名前およびアドレス情報は
クライアントのコンフィギュレーションファイルの情報と一致していなければならない。コンフィギュレーションファイルの情報はNISマッ
プの内容と一致していなければならない。
クライアントが起動して/usrファイルシステムがマウントされてからは、ブートスクリプトの問題で、ディスクレス・クライアントのブー
トプロセスの問題ではない。
/etc/bootpraramsファイルの最後に+があれば NIS bootpraramsマップが追加される。追加されるのはすべてで一部を混
み込むことはできない。
NISを使用しているときには、ブートパラメタはbootpraramsマップ上で管理すること。
複数のNISドメインに複数のディスクレス・クライアントが存在するのであれば、ドメインごとに別個のbootpraramsマップがある
ことを確認する。そうでないとクライアントが間違ったNISドメインを受け取る可能性がある。
多機種のディスクレス・クライアントを有するネットワークでは、各機種が同一の形式でブートパラメタ情報を使用していること
を確認すること。
NISマスター・サーバー以外のサーバ上にあるブートパラメータ情報のコピーはなるべく削除しておく。コンフィギュレーションの変
更後に使用不適当な情報がブートサーバ上に存在する可能性を減少できる。
クライアントのスワップエリアは、通常実メモリの4倍、少なくとも24メガから32メガ必要。
もっと必要になったとき、増やす方法は、クライアントをシャットダウンしてから、旧スワップファイルを削除する、ブートサーバ上
に新規にスワップファイルをmkfileを使って作成する。このときのオプションなど解説。
スワップファイルには先行読み込みを実行しない。
クライアント名の変更
クライアントをシャットダウンして、ルートファイルシステムとNISマップを変更する方法。
クライアントのシャットダウン以外は実際にはスクリプトで実行するのがよいといっていた。
トラブルシューティング
ディスクレス・クライアントがブートできないときは、まずホスト名、IPアドレス、およびイーサネットアドレスのすべてがブートサー
バとNISサーバ上で正しく登録されていることを確認。
次にブートできなくなった箇所。ブートブロックの決定ができなければブート情報が、シングルユーザモードで立ち上がれない
マシンは/usrファイルシステムがないことが考えられる。
クライアント情報が必要なファイルにかけていたりすれば、止まったところでどのファイルを確認すればいいかわかる。
わかりずらいのはブート要求に応答したrpc.bootparamd が不適当なマップである場合。
クライアントまたはブートサーバ上でデバッグモードを蔭位するとブートパラメータの内容をチェックできる b -v
/usrがない場合のよくある原因は、
/usrがマウントされるまでNISは起動されないので ディスクレス・クライアントの小さな/etc/hostsに、自分のホスト名、
localhostエントリ、ブートサーバ名、および/usrサーバ名をもつ必要がある。これがない。
機種ごとのアーキティクチャの問題で間違った/usrをマウントしようとしている。
コンフィギュレーションのオプション
ローカルクライアントにディスクをとりつけて、スワップエリアとして使用する方法と
ブート可能なシステム全体を構築し、ルートファイルシステムとスワップファイルシステムファイルを構築する＝データレス・ク
ライアントにする方法を解説。
ローカルファイルを追加する場合はディス容量を小さくしないとユーザファイルの格好の住処になってバックアップが必要にな
る。
ディスクレス・クライアントにローカルディスクをつけても、サーバーからブートできてかつ、ローカルディスクをファイル格納に使用
するには、Genericカーネルのコンフィギュレーションとして明示的に指定する必要がある /sys/srch/conf/name archはカーネ
ルアーキティクチャ、nameはカーネル名を指定。例をあげて解説。
クライアントとサーバの比率
クライアントとサーバーの分散具合のテスト方法
・一台のディスクレス・クライアントあるいはデータレス・クライアントをサーバとともに設定し負荷を測る
・クライアントにスクリプトで通常の負荷をかけ点綴的ネットワーク・トラフィック・パターンを実現する。サーバ側で数時間平
均トラフィックを計測、クライアントからの要求がピークに達したときのレートも計測、サーバーが秒あたりに処理するNFS要求回
数を測定（nfsstat)
・これをクライアントまたはユーザのタイプごとに繰り返し実行。
・AppendexDの方法でサーバをチューニングしてベンチマーク実行。
・サーバ能力をクライアント要求レートの平均値で割って大雑把なクライアント/サーバ比率を決める。個々のクライアント
が実行するNFSオペレーションの回数とクライアント数を掛け合わせるとサーバーをチューニングする際の目標になる。
でも。あくまで目安と言っていた。プリンタの駆動などもあるので。
第8章 ネットワークのセキュリティ
NISやNFSがもつマシンやファイルシステムへのアクセスを制限する仕組みを解説。
ただしすべてのセキュリティ対策を網羅したものではない。
＊ユーザレベルのネットワーク・セキュリティ
ローカルなマシンへのログインの制限はローカルホストのパスワードファイル、NISのパスワードマップ、ネットグループで定義され
る。
ネットワーク上のアクセスは、信頼できるホストと信頼できるユーザとう概念で決定される。
信頼されているホストとは、信頼されているマシンと、信頼しているマシンで表される。どのユーザやホストが信頼されているか
はホスト同士の関係がどのようになっているかにより定義される。
ホストとサーバの信頼関係
サーバとサーバ・・・一般的にサーバ同士は信頼しあう。NISパスワードマップのサブセットを含むパスワードファイルが各サー
バにあれば限られたユーザが信頼される。サーバ同士の信頼を拡大すれば、１つのセキュリティがやぶられれば他のサーバセキュ
リティも破れる。
サーバーからクライアント・・・ほとんどのクライアントがサーバとサーバのユーザを信頼する。
クライアントからサーバ・・・もっとも制約をうける。サーバの管理をまかされているユーザにだけ無制限のアクセスが与えられる
のが一般的。
クライアントとクライアント・・・ディスクがどのように管理されているかによる。いくつかのファイルサーバで全ファイルを取り扱って
いる場合、クライアント同士の制限は緩やかになる。独自のデータを格納している場合、クライアント同士の関係はクライアント
とサーバの関係に近い。
rloginとrshはruserok()を使って通常のログインとパスワードによるセキュリティチェックを回避している。
ruserok()は指定されたユーザやホストがローカルホスト上で信頼されているか否か決定する。信頼がなければパスワード入
力をもとめるか、rshなら「Permisson denied」を返す。
hosts.equivファイルの定義方法。ネットグループごと許可をあたえたり、特定のホストやユーザごとに許可をあたえたり、ここで
も＋でNISマップが組み込まれる。
.rhostsよりもhosts.equivが優先されるが、rootの場合は.rhostが先に参照される。
自分のマシンと他のホストで異なるユーザネームを使っている場合は、自分の.rhostsで指定すると変換できる。または rlogin
するとき指定する。
ネットワーク管理者は許可を与えすぎている.rhostsファイルに気をつけるべき。NISで管理されていないプライベートなエントリ
を含むパスワードファイルが数多くあるときには、.rhostsの使用状況を監視する必要がある。パスワードファイルをマージして無秩
序なユーザを排除してしまうほうが、監視より簡単。
ネットグループは大きなNISドメインを複数のグループに分割するために利用するのが最も適切。
NISマップとかhostsファイルやパスワードファイルにないホストやユーザ名を使用してネットグループの定義をしてはならない。
ネットグループの設定方法と、間違えやすいところの解説。
＊パスワードとNISのセキュリティ
パスワードを使用してのごく常識的なセキュリティ保護
簡単に推測できなくする。設定条件(ナン文字以上など）をつける。辞書にでている単語は必ずみつかる。パスワードを
推測できるプログラムがあったら使用してみよう。同じ土俵で勝負できる。
NISを使用してrootのパスワードを管理する。
サーバのルート特権はできるかぎり慎重にほごされなればならない。ローカルのマシンの管理者たちに安易使わせれば、か
ならずシステム管理者に跳ね返ってくる。教えないのは信頼していないからではないと伝えて、全権は掌握しておくべき。
システム管理者がすべてのマシンでスーパーユーザになるためにNIマップの設定方法解説。
NISをさらに安全にする
・NISマップをプライベートにするなら、２つ以上のネットワークにつながっているホストをNISサーバにしない。
・マスターNISサーバ上では、サーバのパスワードファイルとNISパスワードファイルを別にする。
・awkスクリプトを使ってパスワードの設定されていないエントリを定期的にチェックする.
・マシンのコンソールについてsecureパラメータを削除すると、ルートパスワードを示さないとシングルユーザモードではブートで
きなくなる。SunOSならブートPROMにセキュリティを設定できるが、ただしパスワードを忘れると新しいPROMを買う羽目になる
「Intruder alart」メッセージ
よくある原因としてはパスワードファイルのUIDフィールドの数字を削除してしまい、その壊れたマップを分配してしまうこと。
UIDが同一でないのにNISパスワードファイルエントリをローカルなパスワードファイルエントリで差し替えてしまった場合もIDのミスマ
ッチを引き起こす。このようなときwhoamiコマンドを実行すると「Intruder alart」メッセージが表示される。
また、rcp、rlogin、ｒｓｈが実行されるとパスワードマップ中にユーザのUIDがないと「who are you?」と表示される。
＊NFSのセキュリティ
ファイルシステムのセキュリティは、ファイルアクセスとファイル操作を制限することと、ファイルの内容を関係者以外の目から保
護すること。
リモートファイルへのアクセスを制限する＝UNIXのふぃある操作のセマンティクスをNFSシステムにマップすること。
ほかにも、NFS要求に含まれるUNIXスタイルの権限の正当性を、チェックしたり、ファイルを暗号化するなどのより強いセキュ
リティがある。
なによりも漏えいを防ぐにはNFSマウントされるところに置かないことが一番である。
NFSのRPCにおける認証
すべてのNFS要求には、ユーザの認証情報(credential)が含まれる。これはUIDおよびUIDが属するグループID（GID)のリ
スト。この情報でNFSサーバではUNIXでファイルアクセスする際のパーミッションチェックをする。
NFSの認証情報とユーザのローカルな認証情報の構造がマッチしない場合が３つある
・ユーザの属するグループが多すぎる。RPC人商標法構造体のクライアントのグループ数の上限がサーバのグループ数の
上限より大きい。
・スーパーユーザのマッピング
rootアクセスの付与は各マシンで行うことになっているため、スーパーユーザにはNFSマウントされたファイルに対して通常
のファイルアクセス許可があたえられていない。あるマシン上のrootになれるユーザでもファイルサーバのファイルを修正する許可が
あるわけでない。ルート特権を取得するsetuidプログラムもリモートファイルに使用しても通常の機能や期待した通りの機能を示
さない。
スーパーユーザでのアクセスはrootのUIDをNFSの認証情報構造体でぇあ匿名ユーザであるnobody（-2）にマップするこ
とで制限している。サーバのカーネル中でマップされるnododyのUIDを変更してrootUIDマッピングを無効にすればサーバから公
開されたファイルをすでてスーパーユーザとしてアクセスできるが、これは危険。
ほとんどのNFSサーバでは公開したファイルシステムに対するrootパーミッションは、root=exportオプションを使用すること
で各ホストごとにあたえられているようになっている。/etc/exportsファイルにこのオプションを指定して登録されているホストに対
しては、ファイルシステムを公開するサーバがrootアクセス権限を付与することになっている。その例。
NFSファイルシステムにrootパーミッションを与えても問題ないのは、ディスクレス・クライアントのルートとスワップのパーティ
ションに対してだけであり、当然でもある。
NFSマウントされた実行ファイルで、setuidビットがたっているものは信用しない方がいい。また侵入者がsetuidをたてた
実行可能ファイルが置いていくことも考えられる。正規のスーパーユーザがこのファイルを実行すると被害が発生する。nosuidオプ
ションを指定してマウントを行うと、NFSマウントされていてもsetuidビットが設定されている実行可能ファイルの実行でもsetuid
機能は作動しなくなる。これを/etc/ftabのエントリに登録しておくこともできる。
正体不明のユーザマッピング
NFS要求に認証情報が欠けている場合
・Secure PRCを利用しているが、クライアント側のユーザが正しい認証情報をSecure RPCシステムに提供していない。
・クライアントがPC/NFSを実行しているPCで、PCユーザが正当なユーザ命とパスワードを示していない。
・クライアントがUNIXマシンでなく、UNIXスタイルの認証情報を作成できない
・要求が偽物。
ディフォルトでは匿名ユーザはnododyとして扱われる（rooｔも） 公開のオプションとしてanonを指定して匿名要求のサーバ
ー上でのマッピングを変更できる。/etc/exportsに匿名ユーザのIDを設定して、正体不明のユーザを既知のローカルユーザにマ
ップできる。ただしスーバーユーザにしてはいけない。
ファイルシステムへのアクセス
特にソースファイルのあるマシンは特定のホストからのアクセスからもほごされなければならない。サーバの/etc/exportsファイ
ルに-accessオプションを指定するとアクセスが許されているホストを記述できる。
読み出し専用でのアクセス
/etc/exportsにｒｗオプションを指定することで書き込み許可でファイルシステムをマウントできるホストを指定できる。
ポートチェッキング
spoofing・・・正当な権限が与えられていないユーザプロセスから手作りで模倣した正当なNFS要求を送出すること。
NFS要求が正当なNFSクライアントから送られた場合はクライアント上の特権UDP/IPポートから送られているはずなので、
ポートモニタを有効にしてチェックすることができる。
ディフォルトでNFSポートモニタが有効になっている場合もある。カーネル変数で管理されているのが一般的。変数自体は
ブート時にスクリプトのadbを使用して設定できる。
echo "nfs_portmon/W1" | adb -w /vmunix /dev/kmem
ポートモニタをオフにするにはブートスクリプトでデーモンを呼び出している行に -n フラグを加える。 rpc.mountd -n
ただし、NFSクライアントコードをPC用に実装したものなど、特権ポートからの要求を送出しないものもあるので注意。
SecureRPCとSecureNFS
SecureRPC・・・標準のRPCシステムに認証情報の正当性をチェックする仕組みを加えたもの。DES暗号化と公開鍵
暗号化の二種類をくみあわせている。秘密鍵にはユーザのパスワードなどが良く使われる。この対話手順を解説。
SecureNFS・・・NFSにSeureRPCを使っているもの。ファイルシステムを公開してマウントする際に、secureオプションを
指定する。（クライアントでも）。
この仕組みに使う公開鍵と秘密鍵はNISマップのpublickey.bynameで管理されている。このマップはNISマスタサーバ
の/etc/publickeyから構築されるので、NISを実行していなければ鍵を作成できない。ディフォルトの鍵はnobodyのためだけ。マ
ップ内の識別子について解説。
鍵の作成はスーパーユーザが「newkey -u user」で生成できる(NISマスタサーバ上）このコマンドについて解説。
対話鍵の生成方法
SecureNFSが適切に動作するためのデータとデーモンファイルの解説。
kerverosシステム
MITのAthenaプロジェクトで開発されたNFSサービスをSecureにするための仕組み。SecureNFSとの違いを解説
＊ウイルス
コンピュータウィルス・・・オペレーティングシステムやシステムユーティリティを変更して危害を加えるプログラムコード。
自己増殖し、ベクトルあるいはキャリアを通じて広がる。ネットワーク上のすべてのコンピュータが汚染されることもある。
UNIXはrootでなければカーネルの書き換えができないので、DOSよりセキュリティが高いと言えるが注意も必要。cronの
エントリ、パブリックドメインから入手した実行コード、root権限で得体のしれない実行ファイルを走らせるのはしてはらないない。
第9章 NFSとNISによる電子メールサービスの集中化
メール設定はDNSによる設定が多くなっているが、ここではNFSとNISを利用したメール設定を解説。
サイトのメール管理を簡潔にするため、メールhubとよばれる1台のマシンにメールの転送とスプールを割り当てている。
＊共有メールスプール作成
個別スプールではユーザは特定のマシンからしかメールの送信できないし、返信は送ったマシンにきてしまう。またワークステ
ーションのないユーザのメールスプールはどうするか、すべてのワークステーションにsendmailデーモンがが起動していなければならな
い、すべてのバックアップが必要など、あまりよいことはない。
メールhubで集中処理することで、ローカルに変更があってもメールの不達などがおこらないようにする、外部には名前を隠
ぺいして、すべてのメールがよくしられているホストから送られてくるようにみせかけて、内部の変更に影響されないようにする。
NFSでメールhubマシンのスプールディレクトリをマウントして実現する。
ただし全ユーザのメールがはいるのでファイルが大きくなる欠点がある。スプールエリアは大きくもとう。
具体手にはexportsで/usr/spool/mail か /var/spool/mailを公開する。このときシンボリックりんくであればリンクのターゲ
ットもexportsファイルに登録しないといけない。その後メールスプールのクライアントでｒｗおよびhardオプションでメールスプールをマ
ウントする。 wahoo:/var/spool/mail /var/spool/mail nfs rw,hard 0 0。クライアントのsendmailデーモンはコメントアウトして
停止しえかまわない。
すべてのメールをメールhubから配送するときはsendmailのリモートモードを使うか、エイリアスを使用する。その詳細解説。
メールの到着を通知する仕組みbiffはすべてのメールがメールhub上で配送されている場合には作動しない。
一般的にメールの通知はcomsatデーモンがbiff設定されているかチェックして行われる。NFSでメールスプールをマウントして
いる場合でも、通知をうけれるようにCシェルのmail変数を利用する方法と、ネットワーク経由でuunet.uu.netなどのアーカイブサ
ーバからxbiffを入手して利用する方法がある。その設定方法解説。
＊名前の隠ぺい
sendmailのリモートを利用するときには名前の隠ぺいは暗黙裡に行われるが、エイリアスの場合は明示的な実行が必要。
メールが送信される前にメールhub上のsendmailに差出人アドレスに適用されるアドレス書き換え規則と受取人アドレスに適用
されるアドレス書き換え規則が必ず含まれている。ローカルのメールを処理するmailerが利用する規則を変更することでhostがロ
ーカルネットワークにある場合、差出人アドレスの形式をuser@hostからuserに書き換えられる。その方法
＊NISエイリアスの展開
通称ユーザ名を定義するシステム、自動メールハンドラ、ローカルおよび高域用のメーリングリスト作成のためにエイリアスが
使用される。NISでのエイリアスの展開または/etx/aliasesファイルからの展開は以下のようになる。user1とuser2の名前は同
一でも構わない。
user1: user2@host
ベンダーによっては、/usr/lib/aliasesや/usr/lib/mail.aliasesにおくこともある。
自分のエイリアスファイルがどこにあるかはsendmail.cfファイルの前半部のOAオプションを参照するとわかる。
＊広域エイリアス
広域エイリアス・・・複数のネットワークやNISドメインにまたがったエイリアスの意味。例このサイトのすべての従業員など。
広域メーリングリストの設定
階層化されたメーリングリストの最上位に位置するマシンを1台選択する。メーリングリスト管理者は、このマシンへのスー
パーユーザアクセスを持っていなければならない。ここでメール配布の名前とメール投降の名前がリストで定義される。エイリアスが
２つ使用されるのはフィードバックループを発生させないため。この階層構造の解説。
存在しなくなったユーザ名がリストに残っていたり、ユーザの自分のメール転送をおかしく指定してしまう、ホスト・マシンが停
止してリストの配布が不能になるなどの問題が考えられる。エイリアスにowner-listを定義すると、これらのエラーはこのエイリアス
に送られる。リストの所有者はNISドメインをリストから外すことができるローカルシステムの管理者がなるべき。
アーカイブと管理
配布リスト中にローカルファイルを名を記述しておくと、リスト宛てのメッセージを全部マシンにアーカイブしておくことができる
。管理者はときどき、ファイルをリネーム、圧縮してスプールエリアがオーバーフローしないようにするべき。
＊NISエイリアスとローカルエイリアスの統合
ローカルのaliasファイルとNISエイリアスマップを統合してつかうことができるが、これはsendmailデーモンがローカルで起動されて
いてリモートになっていない場合。具体的な例を解説。
＊メールの転送
共有されたメールスプールとメール敗走機構によってメールサービスを集中化させる枠組みとしてNFSとNISは最適だが、メー
ルの転送は逆に複雑になる。
メールがユーザ当てに配送されるとき、mailerはユーザのホームディレクトリに.fowardがないかチェックして、他のユーザに転送
したり、シェルスクリプトや実行可能ファイルにパイプでメッセージをおくることができる。vacationユーティリティもこの一種。
メールhubがユーザのホームディレクトリをみつけて、転送のスクリプトやフィルタはメールhub上で実行可能でないといけない。
ディレクトリやファイルが参照される場合、それらはメールhubに存在しないといけない（コンフィギュレーションが異なるから）
第10章から第14章は応用編。
ネットワーク環境下のシステム管理やデバッグ技術について解説。
性能の測定やチューニング方法を紹介。
第10章 診断用および管理用ツール
分散型のアーキティクチャが予想通りの能力を発揮するには、ネットワークがきちんと整備され、サーバが適切にコンフィギュレー
ションされていることが必要。
ネットワークを変更する際はつねに影響が複数のマシンに及ぶことを考慮すべき。
NFSクライアントを追加するなら、接続が増える、ノードが増える、ネットワーク処理の能力などを考慮。
サーバ資源を増やすなら、もっともきびしい状態の資源はなにか認識しておく、CPU速度、ディスク速度、ディスク容量など。
単にサーバーを追加すればネットワークの効率がよくなるのではない。
NFSやNISネットワークで問題を解析するためのツール、手順、および評価基準を解説。
NISが稼働していることが前提であり、一般的なNISマップ(下記）を基準とする
マップ名 ニックネーム ローカルファイル
password.byname passwd /etc/passwd
group.byname group /de/groupe
hosts.byname hosts /etc/hosts
rpc.byname rpc /etc/rpc
services.byname services /etc/services
＊ブロードキャストアドレス
ブロードキャストアドレスはローカルエリアネットワークのすべてのマシンにパケットを送出する。
MAC層とIP層があり、MAC層のブロードキャストアドレスは ff:ff:ff:ff:ff:ffのみ、IP層はいくつかの表し方があるので、ネットワ
ーク全体で揃えておかないと混乱する。
＊MAC層とIP層の操作を行うツール
ifconfig・・・インターフェース・コンフィギュレーション。IPアドレス設定や設定状況の確認 使い方詳細解説。複数のネットワ
ーク・インターフェースに接続するときにはifconfigを複数回使う。
ホストの情報の誤り・・・ポートマップのエラー「portmap: Non-local attempt to unset prog 100105」などがでる。原因は
NISのホストマップとローカルのhostsファイル、ホストのブートスクリプトのに登録されているホスト名とIPアドレスに一貫性がないこ
とが多い。
サブネットワーク・マスクはNISのnetmasksマップでどうなているとよいのか
IPアドレスからMACアドレスへの変換はARP（アドレス・リゾリューション・プロトコル）が使われる。ARP要求でネットワークのトラ
フィックが異常に高くなる状態をARPストームと呼ぶが、まちがって設定されたパケットをブロードキャストパケットを勘違いしたホス
トが異常なパケットを最初に送出したホストのイーサネットアドレスをARP要求で得ようとするためにおきる。トランシーバの電気
系統に問題がある場合が多い。「arp -a」でARPテーブルのエントリがみれる。その解説。
ping・・・ネットワーク上のホストの情報を得る。ネットワークの物理的な接続状況をチェックできるツール。ICPM
（Internetwork Control Message Protocol)を使っている。コマンドの結果の説明。
イーサネットインターフェースの処理能力の測定・・・ネットワークが適切に設定されていて、ホストのコンフィギュレーションが正
しくても、ネットワーク・インターフェースに負荷がかかりすぎて交信がうまくいかないことがある。sprayユーティリティでネットワーク・イ
ンターフェースの能力を大まかに測定できる。sprayはリモートホスト上のprc.spraydデーモンにRPCを送出することで、ホストに固
定長のパケットを連続的に送信し、最後のパケットが送出された時点で、受信されたパケット数が、rpc.spraydデーモンから報
告される。これでクライアント・サーバ間のパケット転送レートを算出する。ただし原因の特定は難しい。sprayでわかること（遠い
マシンと近いマシンへうってみるなど）詳細解説。
＊リモートプロシージャ・コールに関するツール
ネットワークに問題があるとすぐに気が付くが、ネットワーク・プロトコル・スタックのような上位の層にあるときは、少数のマシンに
しか影響を与えないので気が付きにくい。
RPC層からNFSやNISのアプリケーション層までの機能を調べる為のツール紹介。
RPCはネットワーク上のマシンにクライアント・サーバ関係を与える。
NFSサービス用に公開されたディスクやNISマップといった共有資源を物理的に所有しているのがサーバ、サーバの資源を
RPCで要求するのがクライアント。
RPCサービスの識別は、プログラム番号、バージョン番号、プロシージャ番号、プロトコル（UDPまたはTCP）で行う。
この仕組みを詳細に解説。
rpcinfo・・・pingのようにRPCサーバに対してポートマッパーが持っているRPCに関するマッピング情報を確認できる。ただし、
セッション層には利用できない。このコマンド結果の詳細解説。
RPCの問題点をデバッグする
最初にブートされたブートパラメータがまちがっている場合を調べる為に「rpcinfo-b」を実行する方法解説。
rpcinfo要求に対して応答するホストがなければ、ブロードキャストパケットがいずれのNISサーバにも到達していないのが原
因。NISドメイン名とブロードキャストアドレスが正しいのなら、ブロードキャストでサーバを探すことはやめて、ypbindデーモンに正し
いNISサーバのホスト名とアドレスを直接渡すようにしてやればいい。
＊NISツール
使うには下位レベルに問題がないことが前提。
ypmatch・・・NISマップ用のgrepに相当するもの。使い方解説。
ypcat・・・同じくcatに相当
クライアントのバインド状況の表示と解析
ypwhich・・・引数なしだとクライアントがその時点でバインドしているNISサーバホスト名が表示されるなど、シェルスクリプトを
使った使い方解説。
NISのマップ情報をypwhichで調べる方法。
ypset・・・クライアントのバインド変更。使い方解説。
＊NFSツール
NFSの操作はどちらかというと静的で結局ファイルシステムをマウントするかしないかの話で、うまく走るのか、まったくだめなのか
という話でもある。
NFSが動作していないと、ファイルシステムの公開がうまくいかない、パーミッションがおかしい、データが古くなったり分いsつした
りする、サーバの性能が制限されてしまうといった問題が発生する。
マウント情報の管理ファイル
ファイル ホスト 内容
/etc/xtab server 現在公開されているファイルシステム
/etc/rmtab server このサーバのクライアントのためのホスト：ディレクトリのペア
/etc/mtab client 現在マウントされているファイルシステム
公開しているファイルシステムとそのファイルシステムをマウントしているクライアントはどれかは/etc/exportsと/etc/xtabの対
応でわかる。
サーバは/etc/exportsに従ってrpc.mountdを起動して/etc/xtabを長さ0にする。
/etc/xtabの管理にはexportfsユーティリティを使う。/etc/xtabの最終変更時刻がファイルシステムの航海情報が最後に
変更された時刻となる。
exportfsを引数なしで実行するとマウントされているかわかる。＝cat /etc/xtabでも同じ出力が得られる。
mountdデーモンはクライアントからのマウント要求を受理すると、マウント要求で指定されたディレクトリ名とクライアントのホス
ト名を/etc/rmtabに記録する。unmountがくるまで記録されている。サーバがリブートされてもパージされない。普通クライアント
がシャットダウンするときリモートファイルシステムをアンマウントするはずだが、それを行わないとここに誤った情報が残る。
showmountはrpc.mountdデーモンに対して現在のリモートマウントテーブルを要求する。このとき参照されるの
は/etc/rmtabである。コマンドのオプションと見方解説。
dtコマンドはクライアント上で現在のマウントしているふぃあるシステムをレビューできる。オプションと使い方解説。多機種のマ
シンを使っている環境ではdfコマンドは紛らわしい情報や矛盾した情報を表示することがある。
mountコマンドを引数なしで実行すると、mtabの内容が表示される。オプションと使い方解説。
＊NFSの統計情報
クライアント側とサーバ側でNFSサービスの利用量が手続きの呼び出し単位でRPC層とアプリケーション層各々について収
集されている。
nfsstat -c はクライアント側の統計情報を、nfsstat -s はサーバ側の統計情報を表示する。オプションと結果の見方解説
。
＊システムクロックの合わせ方
複数のサーバ上にファイルを分散させる場合、サーバとクライアント間でシステムクロックの同期をとることが重要。
rdate ホスト名でそのホストに時間を合わせられる（スーパーユーザ権限が必要）
ネットワーク上の現在時刻はタイムキーパホストに管理させるのが一般的。
NISのhostsファイルにtimehostというホスト名のエイリアスをつくってrdateで指定するのが一般的。
ネットワーク上のマシンの時刻同期はまず、/etc/rc.localに指定してブートシーケンス中に行う。
それ以降はcronで定期的に行う。crontabで一定間隔を指定する。
各ホストのrdateの時間が重ならないようにする。
ミリ秒単位で同期をとれるNTP（Network Time Protocol）もあるが、解説はない。
第11章 ネットワーク障害の修正
ネットワーク・ケーブルが物理的におかしいときの診断法からまちがったドメインのNISサーバとして機能してしまうマシンへの対応
まで幅広くとりあげる。
ネットワーク障害を上手にデバッグするには手順が重要。プロトコルスタックの下位レベルから上位レベルへ診断する。
例 NISサーバにバインドできない
pingでネットワークをテスト→rpcinfoでypservプロセスが正常かテスト→ypsetでバインドをしてみる。
＊正しく終端されていないネットワーク
マシンによって接続で来たりせつぞくできなかったり、あるいは、マシンの接続が時としておかしくなるのは、ネットワーク・ケーブ
ルの配線状態が悪いか、正しく終端されていないことが原因であることが多い。こんなときには隣のマシンへのpingに20ミリ秒もか
かたりする。例をあげて解決方法を解説。信号が反射されるとどうなるかはAppendixAの伝送線路理論で詳細に解説。
終端されていないネットワークを壁に背を向けて立っている友達にゴムボールをなげて、キャッチして跳ね返さないようにしない
といけないところを取りこぼしていると説明していた。跳ね返りの信号から遠いところのマシンはあまり影響を受けない。
またイーサネット同軸ケーブル内での信号反射を回避するには、トランシーバをできるだけケーブルの近くに配置すること。
信号吸収を電気信号が厚いレンガ塀に突き当たるのではなく、ビルの曲がり角に入り込むようなものといっていた。
例としてあがっていたのは、
ゲートウェイを介したネットワーク・アクセスの障害、
リピータを介した場合にネットワークがおかしくなる。
＊複数のARP応答がある場合
IPアドレスからMACアドレスの変換がおかしくなった場合の悪影響について述べる。
例として
マシンが時に遅くなる。すべてのマシンが同時に遅くなるわけではない。
マシンが突如数分間行方不明になる。
症状が散発的で時間が経過すると治るという特徴がある。
このときのARP要求の診断方法を解説。
＊NISサーバをかたるマシン
ある日クライアントマシンからログインできなくなって、マシンをリブートしたらマウントもできなくなった例。
シングルユーザモードで立ち上げて、ypbind、ypwhichでバインド先を確かめる。すると、そのドメインのなかにNISサーバをかた
るゲートウェイがいたため、ypservがまちがったドメインにバインドされていた。ゲートウェイをちがうドメインに移してもらい、NISマッ
プを含むサブディレクトリ/var/yp/ドメイン名を削除してリブートすると正常に動くようになった。
NISサーバのマップがおかしくなっていたり、不完全でも似たような症状がでる。ypwhichで出力されるNISサーバがただしけれ
ば、この可能性が高い。マップの整合性をチェックするにはypcatですべてのキーをダンプし、変更漁にあわせて、初期化したり修
正したりする。
＊ブートパラメータの混乱
ディスクレスマシンSun3/50をブートしようとしたところエラーになった。
近くのマシンからブートシーケンスのブロードキャストをエミュレートしたところ（rpcinfo -b bootparam 1）異なるベンバーのブー
トサーバがみつかって、そこが応答していることがわかった。ブロードキャストの要求に対する応答形式がベンダーで異なっているこ
とがあるのである。このマシンのrpc.bootparamdをコメントアウトする方法が考えられるが、もしこのサーバが別のディスクレス・クライ
アントを持つ場合はそれはでいないので、自分のクライアントを記述したリストをもたせる（/etc/bootpraramsファイルからプラス
記号をとりのぞく）ことで解決する。
＊NFSエラーメッセージ
NFSは実装の方法で性能やチューニングが微妙に異なることが多い。
NFSマウントされたディスクに対する書き出しエラーはその仕組みのゆえに多い。
NFSの書き出しが頻繁に失敗するような場合、どのファイルが実際に書き込まれているかを調べることで、書き込みを実際に
実行しているユーザやプロセスをみつけることができる。SunOS4.0 ではshowfhユーティリティを使う。そのためにはサーバ上で
RPCサーバデーモンrpc.showfhdを起動して、クライアントでshowfhを実行する。
クライアントの書き込みが遅いなら、NFSの負荷を効率よく設定する必要がある。
第12章 性能の測定とチューニング
取扱い範囲は、性能のボトルネックを識別する方法や性能を向上させるためのさまざまなオプションを解説。
ネットワーク資源の使い方や、ネットワーク構成がまずい場合はシステムの応答も悪い。特に重要な部分がおかしいなら、時
間をかけても対処した方が見返りは大きくなる。
チューニングの過程では最初は性能が大きく向上するが、やがてあまり上がらなくなる。こうなると手間ばかりかかって、性能の
向上率はたいしたことはないので「だいたいチューンされていればそれでよし」のジャズ流精神で解説する。
ユーザは自分のマシンが早くなればそれでよいと考えている。システム管理者は常にネットワーク全体を考えなければならない。
NFSよりrpを利用したほうが早い。NFSをチューニングする必要はないという考えに反論。NFSの利点は自分のマシンのファイ
ルシステムにアクセスするようにアクセスできることで、ｒｃｐコマンドでは相手のサーバ名とディレクトリ名が必要になるといっていた。
＊NFSはどのように動作するのか
チューニング前にしっておくべきこと。どれだけのことがサーバに要求されているのか？＝どのくらい調整がいるのか。
コンフィギュレーションのオプションとしてどのようなものが利用できるのか？＝変更で事態が改善したと知る方法。
NFSの任意性。NFS要求はバーストである。そしてバーストの間は頻繁だが、そのあとは静かになる。
負荷の高いNFS要求・・ディスへの入出力をサーバに要求するもの(シンボリックリンクの展開も）
負荷の低いNFS要求・・・ファイル属性情報やディレクトリ名のlook-upキャッシュに単にアクセスする要求など。
NFS RPC mixture ・・・サーバに対して発行されたすべてのRPCを各タイプごとの平均比率で表したもの。
＊性能の診断
上手にチューニングできたかの目安はクライアントから見てサーバの処理が速くなること。
具体的には標準的なクライアントからの要求に対するサーバの応答時間の平均値を割り出すこと。ここではディスクレスクラ
イアントなら２５－３０ミリ、NFSクライアントであれば５０-７０ミリが一般的としていた。あとはクライアント１台で応答値をはかって
、最小時間をわりだしその２倍以上ならサーバに負荷がかかりすぎていると考える方法もある。
クライアント上でサーバの応答時間の平均値を計算するには、クライアントが発行したNFSのRPCの総数を所要時間で割
る。あくまで平均なので、あまり細かいことは考えない。詳細な方法を解説。
＊ベンチマーク
ベンチマークをテストするときには、NFSコールの受診率とRPCのばらつきを現実に近づけないと意味がない。規則的な間隔
のものは、あまり意味がない。留意点と、Heisenbergの不確定性原理（何かを観察するプロセス自体が観察の対象をへんかさ
せてしまう）ことをあげて、性能を測る方法を考えるように促す。
＊NFS性能・ボトルネックの識別方法
NFSは状態遷移情報がないのでクラッシュからの復旧が容易であるが、逆に負荷でタイムアウトなのか、サーバダウンなのか
判断がつきにくい。
過負荷のサーバはnfsdデーモン待ちになっているので、新たなパケットは受信できないが、受信したパケットには応答できる。
でもそのころにはクライアントはパケットを再送してしまっている。
サーバクライアント関係でボトルネックになりやすところ
・クライアントのネットワーク・インターフェース
・ネットワークの処理能力
・サーバのネットワーク・インターフェース
・サーバのCPU負荷状態
・サーバのメモリ使用状況
・サーバのディスクの転送能力
・システム構成の及ぼす影響・・・サーバのカーネルコンフィギュレーションが悪い、ディスクのバランスが悪い。マウントポイント
を指定するのに使用している名前付け規則が効果的でないが考えられる。
ボトルネックをみつけるには
ネットワークの問題かサーバの問題か切り分ける。
典型的NFSクライアントでnetstatツールを使用して、再送率と複製応答率をみる。これでパケットがサーバに達しているな
らネットワークは問題ないと考える。NFSは下位レベルのプロトコルがわからないのでこのような全体的なチェックが必要になる。
＊ネットワークの混雑とネットワーク・インターフェース
便利なネットワークは拡張を繰り返す。しかし、ネットワークは拡張をされると負荷が高くなりすぎたりホストのネットワーク・イ
ンターフェースがおかしくなったりして性能が低下するものである。
ネットワークの設計と、容量をどのように評価していくか考える。
・「netstat -i」を使ってイーサネットのネットワークインターフェースが正常に働いているかを確認する方法。
・「netstat -i」で衝突回数をしらべる。イーサネットはパケットを送信するときキャリアセンスをだして、送路があいているか確
認するのだが、つながるマシンが増えれば当然衝突も増える。ネットワーク使用率が３０-４０％を超えるとイーサネット自体がボ
トルネックになる。
＊ネットワークを分割するための機器
ネットワークの分割は１本のバックボーンを複数のセグメントに分岐することで行う。セグメントはパーティション用の機器を介し
て接続される。この機器には、リピータ（中継器）、ブリッジ、ルータ、ゲートウェイがある。
リピータ・・・２つのセグメントを物理層で接続。信号とパルスの整形をするだけで、ネットワーク混雑回避にならない。
ブリッジ・・・セグメントをデータリンク層で接続。MACアドレスで転送すべきパケットを選択する。学習型でない場合MACアド
レスを各ネットワークごとに登録してやる手間がかかる。セグメントの混雑は緩和するはずだが、もっとも使用頻度が高い伝送路
が新しいブリッジを通過していないことが前提。
ルータ・・複数のIPネットワークの接続に用いられる。イーサネットアドレスでなく、ソースIPアドレスとディスティネーションIPアドレ
スに従ってパケット転送を行う。
ゲートウェイ・・ネットワーク・プロトコルスタックの最上位。アプリケーションレベルでの転送機能を実行する。トラフィックの転送
においてプロトコル変換も同時に行うことが多い。異なる通信プロトコルを用いる複数のネットワーク接続に用いられることが多い
。
プロトコルフィルタリング
IPプロトコルと無関係なデータが大量に取り扱われるなら、IPプロトコルのパケット比率を調べる。LANアナライザやSunの
trafficユーティリティを使う。そしてプロトコルでパケットの選択転送を行うブリッジやルータを使うようにする。
ブリッジによる分割
NFSで通信を行うクライアントとサーバをグループにしてブリッジで分ける。NISはブリッジがブロードキャストトラフィックを阻止
しないので普通に使える。またNISはNFSに比べ通信量が少ない。
ネットワーク中のノードの理想的な分割を行うために各ホストをノードとするようなグラフで自分のネットワークを表現する方
法を解説。マウントの重みづけをする。FordとFulkersonのmax-flowmin-cau理論（ネットワークにおける最大量量は１つ以上
のボトルネックによって制限される）によるもの。
冗長な回路が必要な場合も解説。
分割されたネットワークでのNISの利用
間にルータがあるとypbindのRPC要求がブロードキャストされないという問題が発生する。
またブリッジがあると通過に時間がかかるので、構成によっては一部のNISサーバの負荷があがることが考えられる。
ディスクレス・ノードの影響
よほどの事情がない限り、ディスクレス・ノードは物理的にも論理的にもサーバと同じネットワーク上に設置されるべき。
どうしてもそうならないときのための対処法が解説してあった。
＊サーバのチューニングをするには
まずはサーバの何が原因で性能が向上しないのか調べる。
CPU負荷を調べる
CPUの負荷が高すぎると、NFSデーモンがスケジュールされるまでの待ち時間が長くなる。同時にサーバ上で実行されてい
るCPU依存のプロセスの性能が低下する。
すべてのnfsdデーモンは同一のUDPソケットから要求を受け取るので、デーモンが他のプロセスと競合してCPUサイクルを書
くとしなければならないとサーバの応答時間が余計にかかる。そうなると下位レベルのネットワーク・ドライバがパケットを落としてし
まう。Berkely版のvmstatはCPU統計情報を表示するコマンド。
NFSサーバに端末を接続するのはやめる。
NFSサーバをゲートウェイにしない。
NFSサーバ・デーモン
標準仕様のブート時に起動されるnfsdデーモンは通常の使用状況での性能が得られるようにベンダーが適当にきめたもの
。nfsdの数を８個にするには「nfsd 8 & echo -n 'nfsd'」とスクリプトで指定する。
最善の数を試してみよう。
ただしどのnfsdデーモンも要求をうけとるソケットは同じ。nfsdデーモンの数が極端に少なくソケットがオーバフローしていると
きには「netstat -s」でわかる。
nfsdデーモンが多くなりすぎるとコンテキストスイッチングとスケジューリングのオーバヘッドが問題になる。思わぬ悪影響でメ
ールが配信されないなどの事態が考えられる。nfsdデーモンは最低で４つ。UDPソケットがオーバーフローしなくなるまで増やすの
がよい。
メモリ使用量
NFSはサーバのバッファ・キャッシュを使用してNFSのread要求に伴うファイルブロックの読み込みを実行する。このバッファキ
ャッシュを増やすことができる。ただしリブートが必要。サーバがNFS専用でないなら、すべてのプロセスが実行できるだけのメモリを
用意してページングを起こさないようにすべき。
ディスクとファイルシステムのスループット
NFSの場合ネットワークより、サーバがディスクとファイルシステムを効率よく利用するようにした方が全体の性能は上がる。
ディスク・アクセスを最適にして、カーネルのテーブルサイズを最適にして、ディスクにまんべんなく要求を分散する。
UNIXのファイルシステムは小さなファイルを扱うには理想的だが、大きなファイルには向かない。ディレクトリが大きすぎると
NFSにむかない。ファイルシステムのフラグメンテーションも効率低下をまねく。これを直すにはダンプして再構築するしかない。
ディスクのデータ転送速度をあげるにはシーク時間を短くすること。難題もあるディスクのなかの１・２ぢに要求が集中するの
は好ましくない。
ディスクの負荷分散は頻繁に利用されるファイルシステムを複数のディスクに移し、それらのファイルシステムに対する要求を
同時処理することで行われる。ディスクレス・クライアントの場合はとくに重要。「iostat -D」でディスク待ちしている要求の数の偏
りがわかる。
カーネルのコンフィギュレーション
ファイルのi-node情報だけで事足りる要求は多いのでi-nodeテーブルのサイズを最適化する方法解説。
サーバー間でファイルをマウントするとデッドロックが発生しやすくなるのでやらないこと。どうしてもというときは「bg」オプションを
使う。
マルチホームサーバ
サーバからNFSファイルシステムが複数のネットワークインターフェースに対して公開されている場合、インターフェース間でパ
ケットがなるべく転送されないようにマウントをする。
*クライアントのチューニング
クライアントのチューニングはサーバに劣らず重要。サーバの能力には限界があるが、クライアントはそれを考慮して要求をし
てこないので、サーバがいっぱいになってしまう。このような場合クライアントに調整弁をつける。
遅いサーバの補償
RPC再送アルゴリズムでは、遅いサーバとネットワークの混雑の区別ができない。
「nfsstart -rc」でサーバが遅いのかがわかる。しかし両方だと見分けはつきにくい。すべてのサーバに同じディスク操作をし
てみて、他より遅いか見る方法もある。
遅いサーバに対応するために/etc/fstabでtimeoパラメタを調整する方法解説。
「netstat -m」でNFSサーバの応答時間がわかる。タイムアウト時間を増やすときはいきなり３００とかにしない。
再送率の閾値の考え方と設定値の解説。
ファイルシステムがソフトマウントされている場合
RPC要求の再送サイクルが繰り返されるのは、ファイルシステムがハードマウントされている場合だけ。
softオプションでマウントされているとRPCの再送シーケンスは最初のmajor timeout発生時点で停止。
そのため、中途半端なところできれてしまうと、書き込みかけたファイルをそのままにしてしまったりするので、読み書き可能の
マウントはハードで行うべき。retransマウントオプションで再送回数を増やせる。
タイムアウト時間の算出
ハードマウントの短所はサーバが復帰するまでクライアントがハングしてしまうこと。ファイルシステムをハードマウントする際に
「intr」オプションを指定するとキーボードからの割り込みが可能になって再送ループを停止できる。NFS再送アルゴリズムのタイム
アウト期間の求め方を示し、あまり長いのはいけないと解説。
ネットワークの信頼性の問題
パケットがブリッジやルータを通る際に欠落するような信頼性に欠ける場合にもNFSの性能は低下する。
「ntsstat -rc」のRPC統計情報を検討するとこのような事態もわかるとして解説。信頼性が低いネットワークではNFSバッ
ファサイズ小さくしろと書いてあった。またサーバとクライアントでそろえるといいとか書いてあった。
広域ネットワークでのNFSの利用
広域ネットワークでもNFSは利用可能。その際はバッファサイズを小さめにもっとも遅いリンクのMTUに揃える。RPCタイムア
ウトは長めにとる。
biodのチューニング
サーバが原因で機能が悪くなっているときに、クライアントマシン上で起動するbiodを増やすとNFS要求が増えて性能が悪
化する。biodを減らしても性能は向上しない、閃光読み出しや地縁書き込みが実行されなくなるのでスループットが落ちる。サ
ーバー上でbiodデーモンが４つ起動している場合書き込み要求が５つくると４つまでbiodがほかはプロセス自体がうけもつ。biodは
ブート時に数を指定される。
ファイル属性情報のキャッシング
NFSクライアントはファイル属性のキャッシュをもっている。（あまり変更されないので）
ファイル属性情報キャッシュのパラメータを解説、ベンダーによりディフォルト値は異なる。
マウントオプションで「noac」でキャッシュしないように設定できる。ただしファイル情報にアクセスするすべての場合サーバにつ
ながないといけない。こうなるとサーバが処理するNFSコールの６０％が属性情報で占められる可能性がある。
一つのディレクトリで複数のクライアントが同時にファイルを作成している場合は、どのようなファイルが作成されたかをすべて
のクライアントができるだけ早く知りたい場合がある、このときキャッシュの時間を短くすべき。
「ls ファイル名」と「ls ファイル名の一部＋＊」ではワイルドカードをつかうとキャッシュが検索される可能性があるといっていた
。
マウントポイントの構成
非効率的なマウントポイントの構成の代表は、マウントポイントが飛び石的になっている場合と、サーバが中間にはいるシ
ンボリックリンク。理由を解説。
ルーティング情報
小規模ネットワークや、１台のルータで他のネットワークとの接続を行っているようなネットワークでは、ネットワークルーティン
グデーモンroutedの動的経路制御よりも、静的経路制御の方が適している。動的経路制御ではゲートウェイやルータホストが
３０秒ごとに経路情報をブロードキャストするが、ネットワークの出口がひとつしかないなら無駄だから。
ファイルのハンドル異常
あるクライアントがオープンしているファイルやディレクトリを他のクライアントが削除したりすると、そのファイルのファイルハンドル
が必ずおかしくなってしまう。このときのメッセージは「stale file handle」これがしょっちゅう発生しているならディレクトリを共有して
いるユーザやコピーされたプログラムを使用しているユーザをチェックしてみるべき。スクラッチ領域を別のユーザが消していることもあ
る。NFSファイルをユーザがどのように利用しているか知ることが大切。
第13章 自動マウント
オートマウンタ・・・NFSファイルを自動的にマウントするツール。NISでNFSコンフィギュレーションファイルを管理している。したがっ
てNISのマップひとつでネットワーク上のクライアントのマウント情報を管理できる。/etc/fstabの管理を自分でおこなわなくていい
というメリットもある。
オートマウンタを使うメリット
共通エントリを各/etc/fstabにいれなくていい。
マウントテーブルの管理が簡素化され、ユーザアカウント情報の管理が簡素化できる
オートマウンタが参照していないファイルシステムをアンマウントするので、NFSサーバがクラッシュしてもプロセスがハングしたまま
になる確率を大幅に下げられる。
NFSのマウントプロトコルを拡張しており、ネットワーク上に分散されている読み出し専用のファイルシステムをマウントするときに
「もっとも近い」サーバからマウントするようになっている。ネットワークの負荷が分散される。
rootにならなくてもマウントできる。
NFSサーバの追加や再構築にともなう管理作業が単純になる。
マウントするときに複数のサーバを探すので、クラッシュに強くなる、負荷分散できる。
*オートマウンタ・マップ
クライアント側からみて共通のパス名のプレフィックスで複数のファイルシステムをマウントするときは間接マップが
マウントポイントに共通のプレフィックスが存在しないとき直接マップが便利。
間接マップと直接マップの働きを例で説明。
オートマウントの構造
オートマウンタはシンボリックリンクをエミュレートする機能。
エミュレータ機能を実現しているオートマウンタの仕組み解説。カーネルがオートマウンタをNFSサーバと勘違いさせると書い
てあった。
直接マップ解説
絶体パス名でマウントポイントを指定。
＊オートマウンタの起動とマスターマップ
オートマウンタのマップ選択、起動を解説
オートマウンタは起動されるとNISのauto.masterマップをマスターマップとして読み込む。
マスターマップにはすべての直接・間接マップとそれに対応するディレクトリがリストされている。
マスターマップのエントリは、ディレクトリ名、マップ名、マウントオプションで構成されている。具体例をあげて、オプションやタイム
アウト時間（何分マウントしていなかったらアンマウントするか）を解説。
＊NISの利用
オートマウンタで使用する3種類のマップをNISで管理する。NISマスターサーバのMakefileにオートマウンタマップのエントリを追
加する方法を解説。
マップの変更はプッシュされた時点で行われる。
現在マウントしているファイルシステムのパラメータを変更するには、一度アンマウントしてからオートマウンタにSIGHUP(kill -l
）シグナルを送る。
直接マップだと書き換えてから再起動が必要。
＊キーや環境変数による置換
キーによる置換
＆はマップのキーに対応する文字列で置き換えられる。などの解説。
オートマウンタの右側の要素を環境変数（＄ではじまる文字列）で置き換えられるなど解説。
＊高度なマップファイルの利用
サーバーを複数指定し、一番近いサーバーを選択する機能解説
階層マウント・・・同一のサーバから複数のファイルシステムを階層的にマウントする機能。解説。
直接マップの間接マップへの変換解説。
＊オートマウンタの副作用
検索パスに多数のディレクトリが入っていて、これらのディレクトリのいくつかに自動マウントがはいっていると、ログインが完了す
るまで時間がかかる
ローカルマウントしている場合、ファイルを指定をローカルホストのパス名で行うか、オートマウンタのパス名で行うかでpwdで表
示されるディレクトリのパス名が異なる。
夜中に起動されるfind作業や、claenderユーティリティなどcronによって起動されるユーティリティはオートマウンタを用いると無
駄な処理を行うことがある。
pwdコマンドはカレント・ディレクトリを順にさかのぼっていくことでシンボリックリンクの展開をおこなうので、オートマウントされたデ
ィレクトリで用いると予期しない結果がでる。シェル変数のcwdを使うとよい。
オートマウンタを kill -9で停止しないこと。SIGTERMを使うと問題なく停止できる。
第14章 PC/NFS
PC/NFSは、DOSをオペレーティングシステムとするIBM互換機上で動作するNIFプロトコルのクライアント専用の実装。
これによってNFSファイルシステムを論理ディスクとしてマウントし、大容量DOSディスクとして使用することができる。
PCが常にNFSの実行主体となる。転送の種類や方向は限定されない。
＊PC/NFS設定
PCの設定、nfsconfというプログラムで行うのがよい。
起動ファイルにコマンドを追加する方法、PC/NFSの設定ユーティリティが追加した行を書き換えるための情報について述べ
る。
＊PC/NFSの起動
ブートの時点でNISが利用できるように、NETWORK.BATが最初に実行されるようにする。
net ypdomain コマンドでドメイン名を設定。
net ypset コマンドで、設定されたドメイン名でNISマップを扱うサーバをみつける。
PC/NFSではUNIXマシンでPC/NFSユーザの認証情報を確認している。標準設定できはNISサーバと認証サーバは同一
マシン。
最後はネットワーク・リダイレクタを起動させる。 net start rdr 普通NETWORK.BATの最後に書いてある。Reverse ARP
をブロードキャストしてPCのIPアドレスを得る。
サーバの設定
PC/NFS用のサーバデーモンが一つ必要pcnfsデーモン。
＊PC/NFSの利用
ファイルシステムのマウント ダブル・バックスラッシュに続くサーバ名とファイル名をつかう、例で解説。
ファイルパーミッション確認 PCユーザーがUNIXの認証サーバにログインすることで、制限の厳しいパーミッションから解放され
る。
ファイル名の変換。
UNIXのファイル名の長さは通常14文字、システムによって最大256文字。大文字小文字混在可能、バンクチュエーション
記号利用できる。
DOSは8文字と拡張子。大文字だけ。ドットではじまるファイル名は不可。
この二つのファイル形式の変換法則を解説。
シンボリックリンクはDOSでサポートされていないが、PC/NFSは若干の制限つきで利用できる。
ファイル内容の変換法則解説。
＊プリンタサービス
PC/NFSによるプリント作業は、プリントファイルをホストにコピーし、そこからプリントするのと同じ。
net use lpt1: サーバのパス名として指定したUNIXプリンタ名 でプリンタ指定。
出力のリダイレクトで、ファイルの内容を直接プリンタに送る場合、DOSはすぐに送る（シングルタスクだから）がUNIXでは魔う
ちタスクなので一旦スプールする。
PC/NFSのプリントメカニズムをpcnfsdデーモンなどの動きとともに解説。
＊ネットワーク・リダイレクタの動作
PCのディスクをUNIXにマウントすることはできない。DOSがシングルタスクだから。
ネットワーク・リダイレクタは通常DOSの入出力に送られる要求を横取りして適当なNFSサーバに送出するためにRPC要求
に加工する仕組み。UNIXのbiodデーモンと同等のもの。
＊PC/NFSネットワークの管理
PC/NFSのネットワーク管理用ツールを使うことでリモートUNIXサーバへの経路の指定、PC/NFSの統計情報表示。PCク
ライアントの性能の最適化を行うためのネットワーク・ドライバの設定を行える。
PC/NFSでのルーティング DOSではディフォルト回路が一つだけ設定されている。「net route ホスト名」引数なしだとディ
フォルト経路がでる。
ネットワーク上のサーバへの経路を調べる 「netstat -r」
PC/NFSで提供されているネットワーク診断ツールと解説。UNIXでのものとあまり変わらない。netsat arp nfsstat nfsping
PC/NFSでは、NFSバッファサイズも小さく、バッファやキャッシュの管理が制限されているので、NFSサーバに対する要求も
異なる。PC/NFSのクライアントがネットワークに追加された場合の観察は、10章、12章を参照しておこなう。
マウントパラメータのチューニングはCONFIG.SYSファイルのPC/NFSドライバの行で設定を行う。「DEVICE=C:\NFS
\PCNFS.SYS オプション」オプションの解説。エラーの解説。
AppendixA 伝送経路理論
物理層の特性をきめるもの。ＮＦＳなどの上位レベルプロトコルとは直接会関わりはないが、物理層の制約を守らないと断続
的で奇妙な問題が上位層でおこることがある。
伝送経路輪・・・通信線路を移動する信号の波長よりも長い線路のこと。
信号の周波数が高ければ高いほど、波長は短くなる。よって、高いほど短い線路での信号特性について解析しなければらな
ない。イーサネットで使用される波長は約１メートル。だから２台以上のワークステーションがあれば、伝送経路理論の適応対象
。
どのような信号導体にも、導体固定の静電容量とインダクタンスがある。イーサネットのバックボーンケーブル長に制限があるの
は容量負荷効果のためである。周波数がひくいとケーブルが理想的でなくても無視できるが、イーサネットがデータ転送に使用
している10MHzの周波数では無理。
イーサネットケーブルを同じふるまいをする電気回路で説明。電圧の移動や終端について解説。
イーサネットケーブルのインピーダンスは50オームでこれはターミネータの抵抗値。
ネットワークの使用中は行えないが、テスタを「抵抗測定レンジ」にして同軸ケーブル芯とアース間の抵抗値を測れば25オーム
になるはずである。
ネットワーク・ケーブルを調べておくことで、潜在的問題を解決することができる。
AppendexB IPパケットの線路制御
ルータはユニークなIPアドレスを持つ複数のネットワークインターフェースを持っている。またIPアドレスにはユニークなホスト名が対
応している。一般にセカンドネットワークインターフェースに対応するホスト名には-gwを使加えたホスト名が持ちいられる。
「netstat -i」で双方のインターフェースとそれに対応するネットワークとホスト名を表示できる。
ローカルネットワークが他のネットワークにどよように接続されているかとう情報を変更する方法
１ 動的経路情報はホストから定期的に宗主されin.routedなどのデーモンがその情報を解釈してルーティングテーブルを更
新する。
２ 静的経路情報はコマンドで手動で設定される。ネットワークにルータが1台しかない場合などに使う
３ 別のネットワークにパケットを転送するために選択されたルータが最適でない場合、選択されたルータが経路のリダイレク
ションメッセージ要求を実行。このICMPリダイレクトメッセージでルーディングケーブルが更新される。
現在のルーティングテーブルの状況を調べる「netstat -r」とその結果の解説。
ARPブロードキャストが同一ローカルネットワーク内しかいかないが、リモートのIPのホストと通信できるわけ解説。（MACアドレス
が変換されていく）
通常２つ以上のネットワークに接続されたホストは、自分のルーティングテーブルを参照しながらIPパケットの転送を行うように
設定されているが、通信はおこなってもネットワーク間の転送を行わないようにしておくと、セキュリティが増す。「adbを用いてカー
ネル変数のip-forwardingの値を変更する」
AppendexC NFSのトラブルシューティング（本編のまとめてきに）
NFSサーバの問題
netstat -s の出力について
badcalls>0 ユーザ認証の問題
nullrecv>0 NFSサーバデーモンの数を減らす。
symlink>10% サーバが公開しているファイルシステムのシンボリックが多すぎる
getattr>60% NFSクライアントのファイル属性情報キャッシュの大きさが小さすぎるか０になっている。
null > 1% オートマウンタからマウント要求が頻繁に発行されている。マウントタイムアウトのパラメータ値を増やす。
NFSクライアントでの問題
netstat -cの出力について確認
timeout >5% サーバが応答するまえにクライアントのRPC要求がタイムアウトしているか、サーバに到達していない。bacxid
フィールドを調べる。
badxid-timeout 再送した要求もサーバで処理され、クライアントがサーバからの応答を重複してうけとっている。要求の再
送を短くする。
badxid=0 タイムアウトが多い場合NFS要求や応答の一文がクライアントとサーバの間のネットワーク上で落ちてしまってい
る可能性がある。rsize, wsizeのマウントパラメータをつかってNFSのバッファサイズを小さくすることで解決することがある。
badcalls>0 ソフトマウントされたファイルシステムに対するRPCがタイムアウトしている。サーバクラッシュの直後は問題ない。
NFSのエラーコード解説
EINTR ハードマウントされたファイルシステムでintrオプションが設定されていて、システムコールが中断された。
EACCES 妥当なユーザ権限をもたないユーザがファイルにアクセスしようとした。
EBUSY NFSクライアントで使用中のファイルシステムをスーパーユーザがアンマウントしようとした。
ENOSPC クライアントがNFSのwriteオペレーションを実行しようとしたが、ファイルサーバのディスクスペースが足りなくなって
いた。
ESTALE NFSクライアントが参照しようとしてサーバに要求を発行したi-ノードが別のクライアントによりすでに削除されて
いた。
EREMOTE サーバにNFSマウントされているファイルシステムをNFSマウントすることは許されていない。
AppendexD NFSのベンチマーク
クライアントからの負荷を生成する方法
Legato Systems社のnhfsstoneユーティリティ
シェルスクリプトにファイル操作をさせる
二つの方法について解説
どちらにしても現実実況をそっくりシュミレートするのは難しい。
末尾に索引。
NFS & NIS (NUTSHELL HANDBOOKS)
- 作者: ハル ストーン
- 出版社/メーカー: アスキー
- 発売日: 1992/12
- メディア: 単行本
タグ：ハル ストーン
コメント 0