version 4 の NFS プロトコル (RFC3530) では、クライアントとサーバーの間でユーザー識別子またはグループ識別子を交換する方法が変更されました。このプロトコルは、NFS Version 4 クライアントと NFS Version 4 サーバーとの間で、ファイルの所有者とグループ属性がそれぞれ user@nfsv4-domain または group@nfsv4-domain 形式の文字列として交換されることを要求します。
たとえば、完全修飾ホスト名が system.example.com の NFS Version 4 クライアント上で、ユーザー known_user に UID 123456 が割り当てられているとします。クライアントが NFS Version 4 サーバーに要求を行うには、クライアントは UID 123456 を known_user@example.com にマッピングしてから、この属性を NFS Version 4 サーバーに送信する必要があります。サーバーがクライアントから known_user@example.com を受け取ると、サーバーはこの文字列をローカル UID 123456 にマッピングし、これが配下のファイルシステムによって認識されます。この機能では、ネットワーク内のすべての UID と GID が一意であること、およびクライアント上の NFS Version 4 ドメインがサーバー上の NFS Version 4 ドメインと一致していることを前提としています。
NFS Version 4 クライアントおよびサーバーは、整数-文字列および文字列-整数変換の両方に対応しています。たとえば、NFS Version 4 サーバーは GETATTR 操作に応答して、配下のファイルシステムから取得された UID および GID をそれぞれの文字列表現にマッピングし、この情報をクライアントに送信します。またクライアントでも、UID と GID を文字列表現に割り当てる必要があります。たとえば、クライアントは chown コマンドに応答して、新しい UID および GID を文字列表現にマッピングしてから、SETATTR 操作をサーバーに送信します。
ただし、クライアントとサーバーでは、文字列が認識されない場合の対処が異なることに注意してください。
ユーザーがサーバー上に (同じ NFS Version 4 ドメイン構成内にも) 存在しない場合は、サーバーはリモートプロシージャー呼び出し (RPC) を拒否し、クライアントにエラーメッセージを返します。このような場合は、リモートユーザーが実行できる操作が制限されます。
ユーザーがクライアントおよびサーバーの両方上に存在するけれども、それらのドメインが一致しない場合は、サーバーが着信ユーザー文字列を配下のファイルシステムが認識できる整数値にマッピングすることを要求する属性変更操作 (SETATTR など) を、サーバーは拒否します。NFS Version 4 クライアントおよびサーバーを正常に機能させるには、それらの NFS Version 4 ドメイン (文字列の、@ 記号のあとの部分) が一致するようにしてください。
NFS Version 4 クライアントがサーバーからのユーザーまたはグループ名を認識しない場合、クライアントは文字列をその一意 ID (整数値) にマッピングできません。そのような場合は、クライアントは着信ユーザー文字列または着信グループ文字列を nobody ユーザーに割り当てます。nobody に割り当てられると、さまざまなアプリケーションでさまざまな問題が発生します。NFS Version 4 では、ファイル属性を変更する操作は失敗します。
指定されたユーザーまたはグループ名をサーバーが認識しない場合 (NFS Version 4 ドメインが一致している場合でも)、サーバーはユーザーまたはグループ名をその一意 ID (整数値) にマッピングできません。そのような場合は、サーバーは着信ユーザー名または着信グループ名を nobody ユーザーに割り当てます。このようなことが発生するのを避けるために、管理者は NFS Version 4 クライアントにのみ存在する特殊アカウントの作成を避けるようにしてください。
クライアントおよびサーバーのドメイン名は、sharectl コマンドを nfsmapid_domain オプション付きで使用することで変更できます。このオプションはクライアントとサーバーの共通ドメインを設定します。ローカル DNS ドメイン名を使用するデフォルト動作をオーバーライドします。タスク情報については、NFS サービスの設定を参照してください。
nfsmapid デーモンは、svc:system/name-service/switch および svc:/network/dns/client 内で見つかる SMF 構成情報を次のように使用します。
nfsmapid は、標準の C ライブラリ関数を使用して、バックエンドネームサービスにパスワードおよびグループ情報を要求します。これらのネームサービスは、svc:system/name-service/switch SMF サービスの設定によって制御されます。サービスのプロパティーへの変更は、nfsmapid の動作に影響します。svc:system/name-service/switch SMF サービスの詳細は、nsswitch.conf(4) のマニュアルページを参照してください。
NFS Version 4 クライアントがさまざまなドメインからファイルシステムをマウントできることを保証するために、nfsmapid は DNS TXT リソースレコード (RR) _nfsv4idmapdomain の構成に依存します。_nfsv4idmapdomain リソースレコードの構成の詳細については、nfsmapid と DNS TXT レコードを参照してください。また、次の点にも注意してください。
DNS TXT RR は、必要なドメイン情報を使って、DNS サーバー上で明示的に構成するようにしてください。
svc:system/name-service/switch SMF サービスは、resolver が DNS サーバーを検出してクライアントおよびサーバー NFS Version 4 ドメイン用の TXT レコードを検索できるように構成するようにしてください。
詳細については、次を参照してください。
resolv.conf(4) のマニュアルページ
nfsmapid が正しく動作するには、NFS Version 4 クライアントおよびサーバーが同じドメインに割り当てられている必要があります。NFS Version 4 ドメインの一致を保証するために、nfsmapid はこれらの厳密な優先順位規則に従います。
デーモンは、nfsmapid_domain パラメータに割り当てられている値を SMF リポジトリで最初に確認します。値が検出された場合、その割り当てられている値は他の設定よりも優先されます。割り当てられている値は、発信属性文字列に追加され、着信属性文字列と比較されます。手順については、NFS サービスの設定を参照してください。
値が nfsmapid_domain に割り当てられていなかった場合、デーモンは DNS TXT RR からのドメイン名を確認します。nfsmapid は、resolver 内のルーチンセットによって使用される /etc/resolv.conf ファイル内の指令に依存します。resolver は、構成されている DNS サーバーから _nfsv4idmapdomain TXT RR を検索します。DNS TXT レコードを使用する方がよりスケーラブルです。このため、SMF リポジトリにパラメータを設定するよりも、TXT レコードを継続して使用することをお勧めします。
ドメイン名を提供する DNS TXT レコードが構成されていない場合、nfsmapid デーモンは /etc/resolv.conf ファイル内の domain または search 指令で指定された値を使用します。このとき、最後に指定された指令が優先されます。
次の例では、domain と searchの両方の指令が使用されています。nfsmapid デーモンは、search指令のあとにリストされている最初のドメイン (example.com) を使用します。
domain company.example.com search example.com abc.def.com
/etc/resolv.conf ファイルが存在しない場合、nfsmapid は domainname コマンドの動作に従って NFS Version 4 ドメイン名を取得します。具体的には、/etc/defaultdomain ファイルが存在する場合には、nfsmapid は NFS Version 4 ドメインにその内容を使用します。/etc/defaultdomain ファイルが存在しない場合には、nfsmapid はネットワークに構成されているネームサービスから渡されるドメイン名を使用します。詳細は、domainname(1M) のマニュアルページを参照してください。
DNS は広く普及しているので、NFS Version 4 ドメイン名にとって効率的な保存および配布メカニズムです。さらに、DNS は本質的に拡張性が高いので、大規模に配備するために NFS Version 4 ドメインを構成する場合には DNS TXT リソースレコードを使用することが推奨されます。エンタープライズレベル DNS サーバーでは、_nfsv4idmapdomain TXT レコードを構成することをお勧めします。このような構成することで、NFS Version 4 クライアントまたはサーバーが DNS ツリーをトラバースすればその NFS Version 4 ドメインを見つけられることが保証されます。
次の例は、DNS サーバーが NFS Version 4 ドメイン名を提供するために推奨されるエントリを示しています。
_nfsv4idmapdomain IN TXT "abc.def"
この例では、構成するドメイン名は二重引用符で囲まれている値です。ttl フィールドの指定がなく、_nfsv4idmapdomain にドメインが付加されていないことから、これは owner フィールドの値です。この構成により、TXT レコードは Start-Of-Authority (SOA) レコードからゾーンの ${ORIGIN} エントリを使用できます。たとえば、さまざまなレベルのドメイン名前空間で、レコードは次のように読み取ることができます。
_nfsv4idmapdomain.subnet.example.com. IN TXT "abc.def" _nfsv4idmapdomain.example.com. IN TXT "abc.def"
この構成では、DNS クライアントが DNS ツリー階層を検索するときに、resolv.conf ファイルを使用して柔軟に検索することができます。resolv.conf(4) のマニュアルページを参照してください。この機能により、TXT レコードの検索での確率がより高くなります。さらに柔軟性を高めるために、低レベル DNS サブドメインは独自の DNS TXT リソースレコード (RR) を定義できます。この機能により、低レベル DNS サブドメインは高レベル DNS ドメインで定義された TXT レコードをオーバーライドできます。
ネットワークの NFS Version 4 ドメインに値を割り当てる前に、NFS Version 4 ドメインがネットワーク用にすでに構成されているかどうかを確認してください。次の例は、ネットワークの NFS Version 4 ドメインを識別する方法を示しています。
NFS Version 4 ドメインを DNS TXT RR から識別するには、nslookup または dig コマンドを使用します。
次の例は、nslookup コマンドのサンプル出力を示しています。
# nslookup -q=txt _nfsv4idmapdomain Server: 10.255.255.255 Address: 10.255.255.255#53 _nfsv4idmapdomain.company.example.com text = "example.com"
次の例は、dig コマンドのサンプル出力を示しています。
# dig +domain=company.example.com -t TXT _nfsv4idmapdomain ... ;; QUESTION SECTION: ;_nfsv4idmapdomain.company.example.com. IN TXT ;; ANSWER SECTION: _nfsv4idmapdomain.company.example.com. 21600 IN TXT "example.com" ;; AUTHORITY SECTION: ...
DNS TXT RR の設定方法については、nfsmapid と DNS TXT レコードを参照してください。
ネットワークが NFS Version 4 DNS TXT RR で設定されていない場合は、次のコマンドを使用して NFS Version 4 ドメインを DNS ドメイン名から識別します。
# egrep domain /etc/resolv.conf domain company.example.com
/etc/resolv.conf ファイルがクライアントの DNS ドメイン名を提供するように構成されていない場合は、次のコマンドを使用してネットワークの NFS Version 4 ドメイン構成からドメインを識別します。
# cat /system/volatile/nfs4_domain example.com
NIS などの別のネームサービスを使用している場合は、次のコマンドを使用して、ネットワークに構成されているネームサービスでドメインを確認します。
# domainname it.company.example.com
詳細は、次のマニュアルページを参照してください。
このセクションでは、ネットワークがどのようにして目的のデフォルトドメインを取得するかについて説明します。
最新リリースについては、Oracle Solaris 11 リリースで NFS version 4 のデフォルトドメインを構成するを参照してください。
初期 Solaris 10 リリースの場合は、Solaris 10 リリースで NFS version 4 のデフォルトドメインを構成するを参照してください。
Oracle Solaris 11 リリースでは、次のコマンドを入力することでデフォルト NFS ドメインバージョンを設定します。
# sharectl set -p nfsmapid_domain=example.com nfs
NFS Version 4 の初期 Solaris 10 リリースでは、ネットワークが複数の DNS ドメインを含んでいるけれども、単一 UID および GID 名前空間しか持たない場合には、すべてのクライアントが nfsmapid_domain に 1 つの値を使用する必要がありました。DNS を使用するサイトでは、nfsmapid が、_nfsv4idmapdomain に割り当てられた値からドメイン名を取得して、この問題を解決します。詳細は、nfsmapid と DNS TXT レコードを参照してください。ネットワークが DNS を使用するように構成されていない場合は、最初のシステムブート時に、オペレーティングシステムは sysidconfig ユーティリティーを使用して NFS Version 4 ドメイン名のために次のプロンプトを提供します。
This system is configured with NFS Version 4, which uses a domain name that is automatically derived from the system's name services. The derived domain name is sufficient for most configurations. In a few cases, mounts that cross different domains might cause files to be owned by nobody due to the lack of a common domain name. Do you need to override the system's default NFS version 4 domain name (yes/no)? [no]
デフォルトの応答は [no] です。[no] を選択すると、次のメッセージが表示されます。
For more information about how the NFS Version 4 default domain name is derived and its impact, refer to the man pages for nfsmapid(1M) and nfs(4), and the System Administration Guide: Network Services.
[yes] を選択すると、次のプロンプトが表示されます。
Enter the domain to be used as the NFS Version 4 domain name. NFS Version 4 domain name []:
nfsmapid の詳細は、次を参照してください。
nfsmapid(1M) のマニュアルページ
nfs(4) のマニュアルページ
http://www.ietf.org/rfc/rfc1464.txthttp://www.ietf.org/rfc/rfc1464.txt