第 9章NFS(Network File System)

NFS (Network File System)を利用すると、ホストはあるリモートシステムのパーティションを マウントし、それらのパーティションがローカルファイルシステムであるかのように使用できます。これにより、 システム管理者はネットワーク上の中央にリソースを設置して、許可を持つユーザーがそこにあるファイルにいつでも アクセスすることができます。

2つのバージョンのNFSが現在使用されています。NFSバージョン2(NFSv2)は、ここ数年間にわたる実績があり、 各種オペレーティングシステムによって広くサポートされています。NFSバージョン3(NFSv3)には機能がさらに 追加されており、可変ファイル処理サイズやエラー報告機能の向上が含まれています。Red Hat Linuxは、NFSv2と NFSv3の両方をサポートし、NFSv3をサポートしているサーバーと接続するときはデフォルトでNFSv3を使用します。

この章では、NFSバージョン2を主に取り扱いますが、紹介する概念の多くはバージョン3にも適用されます。 ここでは、基本的なNFSの概念と補足情報だけ示します。クライアントマシンとサーバーマシン上でのNFSの 設定と動作に関する詳しい説明については、Red Hat Linux カスタマイズガイドNFS (ネットワーク ファイルシステム)の章を参照してください。

9.1. 方法論

Linuxはカーネルレベルのサポートと常時稼働しているデーモンプロセスの組み合わせを使用して NFSファイル共有機能を提供します。しかし、LinuxカーネルのNFSサポートが機能するように有効に なっていなければいけません。NFSはRPC(Remote Procedure Call)を使用して クライアント、サーバー間で要求をルーティングします。つまり、portmapサービスが有効で、 NFS通信を行うために適正なランレベルでアクティブでなければならないということを意味します。 以下のさまざまなプロセスがportmapと共に動作して、既知のNFS接続が許可をうけ エラーなしに処理されることを確実にします:

これらのプログラムのすべてがNFSサービスに必要なわけではありません。有効にしなければならないサービスは、 rpc.mountdrpc.nfsdportmapだけです。他の デーモンは追加の機能を提供しますが、サーバー環境がそれらを要求する場合にのみ使用すべきものです。

NFSバージョン2はUDP(User Datagram Protocol)を使用して、クライアントとサーバーの間で statelessネットワーク接続を提供します。NFSバージョン3はUDP又はIP上で動作するTCPを使用します。クライアントが 共有ボリュームにアクセスすることを許可された後にNFSサーバーはクライアントにクッキーを送信する為、 stateless UDP接続はネットワークトラフィックを最小限に抑えます。このクッキー、つまりサーバー側に格納される 乱数値はクライアントからサーバーへのRPC要求と共に渡されます。NFSサーバーはクライアントに影響を与えることなく 再起動でき、クッキーはそのまま残ります。

NFSは、クライアントシステムがリモートファイルシステムをマウントしようとする時にのみ、 認証を実行します。アクセスを制限する為に、NFSサーバーは先ずTCPラッパーを使用します。 TCPラッパーは、/etc/hosts.allowファイルと/etc/hosts.deny ファイルを読み込み、ある特定のクライアントがNFSサーバーへのアクセスを許可されるか拒否されるかを 決定します。TCPラッパーのアクセス制御の設定に関する情報は第15章で確認して 下さい。

TCPラッパーによってクライアントがアクセスを認可された後は、NFSサーバーがその 設定ファイル/etc/exportsを参照して、このクライアントが エクスポートのファイルシステムをマウント出来るかどうかを決定します。認可が 出た後は、どんなファイルやディレクトリの操作もRPC(Remote Procedure Call)を 使用してサーバーに送ることができます。

警告警告
 

NFSマウント権限はユーザーではなく、クライアントに限定して許可しています。 エクスポートされたファイルシステムは、リモートシステム上のどの ユーザーからでもアクセスが可能です。

/etc/exportsを設定する時には、エクスポートしたファイルシステムの 読み込み/書き込み権限の許可には充分に注意して下さい。

9.1.1. NFSとportmap

NFSは、RPC(remote procedure calls)に依存しながら機能します。portmapサービスは RPC要求を正しいサービスにマッピングするのに必要となります。RPCプロセスはスタートしたことを portmapに対し通知し、モニターしているポート番号とサービスする予定のRPCプログラム を表します。クライアントシステムは、その後、特定のRPCプログラム番号を持つサーバー上のportmapに 連絡を取ります。そして、portmapは、目的のサービスと通信をする為に、クライアントを正しい ポート番号にリダイレクトします。

RPCベースのサービスは着信するクライアント要求とすべての接続をするportmapに依存しているので、 portmapはこれらのサービスが開始される前に利用可能になっていなければいけません。何らかの理由で portmapサービスが不意に停止したときは、portmapと、起動したときに稼働していた すべてのサービスを再起動してください。

portmapサービスはTCPラッパーのホストアクセスファイル(/etc/hosts.allow及び /etc/hosts.deny)と共に使用することが出来て、どのリモートシステムがサーバー上のRPCベースの サービスを使用する許可をもつか制御します。詳細は第15章を御覧下さい。portmapの 為のアクセス制御ルールは全てのRPCベースのサービスに影響します。又は、特定のアクセス制御ルールが各NFS RPCデーモンを影響する ように指定することも可能です。rpc.mountdrpc.statdのmanページには、これらのルールの 為の正確な構文に関する情報が含まれています。

9.1.1.1. portmapでNFSのトラブルシューティング

portmapは、RPCサービスとそれらの間の通信で使用されるポート番号の調整を提供しますので、 トラブルシューティングをする時点でportmapを使用して現在のRPCサービスのステータスを 表示するために役に立ちます。rpcinfoコマンドは、各RPCベースのサービスをポート番号、 RPCプログラム番号、バージョン、及び IPプロトコルタイプ(TCP 又は UDP)と共に表示します。

適正なNFS RPCベースのサービスがportmapに有効になっているかを確かめるには、 rpcinfo -pを使用します:

   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp   1024  status
    100024    1   tcp   1024  status
    100011    1   udp    819  rquotad
    100011    2   udp    819  rquotad
    100005    1   udp   1027  mountd
    100005    1   tcp   1106  mountd
    100005    2   udp   1027  mountd
    100005    2   tcp   1106  mountd
    100005    3   udp   1027  mountd
    100005    3   tcp   1106  mountd
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100021    1   udp   1028  nlockmgr
    100021    3   udp   1028  nlockmgr
    100021    4   udp   1028  nlockmgr

-pオプションは、指定されたホストのポートマッパーを見つけ出します。特定のホストが一覧表示されて いなければローカルホストをデフォルトとします。ほかのオプションはrpcinfoのmanページに記載されています。

上記の出力から、さまざまなNFSサービスが稼働していることがわかります。NFSの1つが正常に起動していなければ、 portmapはそのサービスのクライアントからのRPC要求を正しいポートにマッピングできなくなります。 多くの場合、rootとしてNFSを再起動する(/sbin/service nfs restart)と、これらのサービスは portmapに正しく登録され、稼働し始めます。