RFC2055 日本語訳
2055 WebNFS Server Specification. B. Callaghan. October 1996. (Format: TXT=20498 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Callaghan Request for Comments: 2055 Sun Microsystems, Inc. Category: Informational October 1996
コメントを求めるワーキンググループB.キャラハン要求をネットワークでつないでください: 2055年のサン・マイクロシステムズ・インクカテゴリ: 情報の1996年10月
WebNFS Server Specification
WebNFSサーバ仕様
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document describes the specifications for a server of WebNFS clients. WebNFS extends the semantics of versions 2 and 3 of the NFS protocols to allow clients to obtain filehandles more easily, without recourse to the portmap or MOUNT protocols. In removing the need for these protocols, WebNFS clients see benefits in faster response to requests, easy transit of firewalls and better server scalability This description is provided to facilitate compatible implementations of WebNFS servers.
このドキュメントはWebNFSクライアントのサーバのための仕様を説明します。 WebNFSはクライアントが、より容易にfilehandlesを入手するのを許容するためにNFSプロトコルのバージョン2と3の意味論について敷衍しています、portmapか山のプロトコルへの償還請求なしで。 これらのプロトコルの必要性を取り除くのに、WebNFSクライアントは要求への、より速い応答、ファイアウォールの簡単なトランジットにおける利益を見て、WebNFSサーバのコンパチブル実装を容易にするために、より良いサーバスケーラビリティThis記述を提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2. TCP vs UDP . . . . . . . . . . . . . . . . . . . . . . . 2 3. Well-known Port . . . . . . . . . . . . . . . . . . . . . 2 4. Server Port Monitoring . . . . . . . . . . . . . . . . . . 3 5. Public Filehandle . . . . . . . . . . . . . . . . . . . . 3 5.1 Version 2 Public Filehandle . . . . . . . . . . . . . . 3 5.2 Version 3 Public Filehandle . . . . . . . . . . . . . . 4 6. Multi-component Lookup . . . . . . . . . . . . . . . . . . 4 6.1 Canonical Path vs. Native Path . . . . . . . . . . . . . 5 6.2 Symbolic Links . . . . . . . . . . . . . . . . . . . . . 6 6.3 Export Spanning Pathnames . . . . . . . . . . . . . . . 6 7. Location of Public Filehandle . . . . . . . . . . . . . . 7 8. Index Files . . . . . . . . . . . . . . . . . . . . . . . 7 9. Bibliography . . . . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . 9 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 9 12. Author's Address . . . . . . . . . . . . . . . . . . . . . 10
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 2 2。 TCP対UDP. . . . . . . . . . . . . . . . . . . . . . . 2 3 ウェルノウンポート. . . . . . . . . . . . . . . . . . . . . 2 4。 サーバポートモニター. . . . . . . . . . . . . . . . . . 3 5。 公共のFilehandle. . . . . . . . . . . . . . . . . . . . 3 5.1バージョン2の公共のFilehandle. . . . . . . . . . . . . . 3 5.2バージョン3の公共のFilehandle. . . . . . . . . . . . . . 4 6。 多成分系のルックアップ. . . . . . . . . . . . . . . . . . 4 6.1の正準な経路対パス名. . . . . . . . . . . . . . . 6 7にかかる経路.56.2の固有のシンボリックリンク. . . . . . . . . . . . . . . . . . . . . 6 6.3輸出 公共のFilehandle. . . . . . . . . . . . . . 7 8の位置。 ファイル. . . . . . . . . . . . . . . . . . . . . . . 7 9に索引をつけてください。 図書目録. . . . . . . . . . . . . . . . . . . . . . . 8 10。 セキュリティ問題. . . . . . . . . . . . . . . . . 9 11。 承認. . . . . . . . . . . . . . . . . . . . . 9 12。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . 10
Callaghan Informational [Page 1] RFC 2055 WebNFS Server Specification October 1996
[1ページ]RFC2055WebNFSサーバ仕様1996年10月の情報のキャラハン
1. Introduction
1. 序論
The NFS protocol provides access to shared filesystems across networks. It is intended to be machine, operating system, network architecture, and transport independent. The protocol currently exists in two versions: version 2 [RFC1094] and version 3 [RFC1813], both built on Sun RPC [RFC1831] and its associated eXternal Data Representation (XDR) [RFC1832]. This document assumes some familiarity with the NFS protocol and underlying RPC protocols.
NFSプロトコルはネットワークの向こう側に共有されたファイルシステムへのアクセスを提供します。 マシン、オペレーティングシステム、ネットワークアーキテクチャ、および輸送から独立しているのは意図しています。 プロトコルは現在、2つのバージョンに存在します: バージョン2[RFC1094]とバージョン3 [RFC1813]、両方がSun RPC[RFC1831]とその関連eXternal Data Representation(XDR)[RFC1832]に建てられました。 このドキュメントはNFSプロトコルと基本的なRPCプロトコルへの何らかの親しみを仮定します。
WebNFS servers implement semantic extensions to both versions of the NFS protocol to support a lightweight binding mechanism for conventional or web browser clients that need to communicate with NFS servers across the Internet. a WebNFS server supports the public filehandle and multi-component lookup features described herein, as well as meeting some additional requirements.
WebNFSサーバは、インターネットの向こう側にNFSサーバとコミュニケートする必要がある従来かウェブブラウザクライアントのために軽量の結合機構をサポートするためにNFSプロトコルの両方のバージョンに意味拡張を実装します。WebNFSサーバは、公共のfilehandleと多成分系のルックアップがいくつかの追加必要条件を満たすことと同様にここに説明された特徴であると、サポートします。
For a description of WebNFS client requirements, read RFC 2054.
WebNFSクライアント要件の記述には、RFC2054を読んでください。
2. TCP vs UDP
2. TCP対UDP
The NFS protocol is most well known for its use of UDP which performs acceptably on local area networks. However, on wide area networks with error prone, high-latency connections and bandwidth contention, TCP is well respected for its congestion control and superior error handling. A growing number of NFS implementations now support the NFS protocol over TCP connections.
ローカル・エリア・ネットワークに許容できて働くUDPの使用において、NFSプロトコルは最もよく知られています。 しかしながら、誤りは傾向がある広域ネットワーク、高潜在接続、および帯域幅主張のときに、TCPはその輻輳制御と優れたエラー処理のためによく尊敬されます。 増加している数のNFS実装が現在、TCP接続の上でNFSプロトコルをサポートします。
A WebNFS client will first attempt to connect to its server with a TCP connection. If the server refuses the connection, the client will attempt to use UDP. All WebNFS servers should support client use of TCP and must support UDP.
WebNFSクライアントは、最初に、TCP接続と共にサーバに接続するのを試みるでしょう。 サーバが接続を拒否すると、クライアントは、UDPを使用するのを試みるでしょう。 すべてのWebNFSサーバが、TCPの使用をクライアントにサポートするべきであり、UDPをサポートしなければなりません。
3. Well-known Port
3. ウェルノウンポート
While Internet protocols are generally identified by registered port number assignments, RPC based protocols register a 32 bit program number and a dynamically assigned port with the portmap service which is registered on the well-known port 111. Since the NFS protocol is RPC-based, NFS servers register their port assignment with the portmap service.
一般に、インターネットプロトコルが登録されたポートナンバー課題で特定されている間、RPCのベースのプロトコルは32ビットのプログラム番号とダイナミックに割り当てられたポートをウェルノウンポート111に登録されるportmapサービスに示します。 NFSプロトコルがRPCベースであるので、NFSサーバは彼らのポート課題をportmapサービスに登録します。
NFS servers are constrained by a requirement to re-register at the same port after a server crash and recovery so that clients can recover simply by retransmitting an RPC request until a response is received. This is simpler than the alternative of having the client repeatedly check with the portmap service for a new port assignment. NFS servers typically achieve this port invariance by registering a
クライアントが単に応答が受け取られているまでRPC要求を再送することによって回復できるようにサーバクラッシュと回復の後に同じポートに再登録するという要件によってNFSサーバは抑制されます。 これはクライアントに繰り返して新しいポート課題のためのportmapサービスに問い合わせさせる代替手段より簡単です。 NFSサーバは、aを登録することによって、このポートの不変性を通常実現します。
Callaghan Informational [Page 2] RFC 2055 WebNFS Server Specification October 1996
[2ページ]RFC2055WebNFSサーバ仕様1996年10月の情報のキャラハン
constant port assignment, 2049, for both UDP and TCP.
一定のポート課題、UDPとTCPの両方のための2049。
To avoid the overhead of contacting the server's portmap service, and to facilitate transit through packet filtering firewalls, WebNFS clients optimistically assume that WebNFS servers register on port 2049. Most NFS servers use this port assignment already, so this client optimism is well justified.
サーバのportmapサービスに連絡するオーバーヘッドを避けて、パケットフィルタリングファイアウォールを通したトランジットを容易にするために、WebNFSクライアントは、WebNFSサーバがポート2049の上に登録されると楽観的に仮定します。 ほとんどのNFSサーバが既にこのポート課題を使用するので、このクライアント楽観主義はよく正当化されます。
A WebNFS server must register on UDP port 2049 and TCP port 2049 if TCP is supported.
WebNFSサーバはUDPポート2049の上に登録されなければなりません、そして、TCPがサポートされるなら、TCPは2049を移植します。
4. Server Port Monitoring
4. サーバポートモニター
Some NFS servers accept requests only from reserved UDP or TCP ports, i.e. port numbers below 1024. These "privileged" ports are available only to Unix processes with superuser permissions. Requests that do not originate from the range of reserved ports are rejected. This an optimistic way of preventing direct access to the server from user processes that may attempt to spoof AUTH_UNIX RPC credentials.
いくつかのNFSサーバが要求を単に予約されたUDPかすなわち、TCPポート、ポートナンバーから1024の下に受け入れます。 これらの「特権がある」ポートは「スーパー-ユーザ」許容でUnixプロセスだけに利用可能です。 予約されたポートの範囲から発しない要求が拒絶されます。 これはユーザからのサーバへの直接アクセスがそれを処理するという防止の楽観的な方法で試みるかもしれません。AUTH_UNIX RPCが資格証明書であると偽造するのを試みてください。
Since WebNFS clients are not required to use reserved ports, a WebNFS server must not check the originating port for requests to filesystems made available to WebNFS clients.
クライアントが使用している必要はないWebNFSがポートを予約したので、WebNFSサーバは要求がないかどうかWebNFSクライアントにとって利用可能にされたファイルシステムに起因するポートをチェックしてはいけません。
5. Public Filehandle
5. 公共のFilehandle
The public filehandle is an NFS file handle with a reserved value and special semantics that allow an initial filehandle to be obtained. A WebNFS client can use the public filehandle as an initial filehandle without using the MOUNT protocol. Since NFS version 2 and version 3 have different filehandle formats, the public filehandle is defined differently for each.
公共のfilehandleは初期のfilehandleが入手されるのを許容する予約された値と特別な意味論があるNFSファイルハンドルです。 山のプロトコルを使用しないで、WebNFSクライアントは初期のfilehandleとして公共のfilehandleを使用できます。 NFSバージョン2とバージョン3には異なったfilehandle形式があるので、公共のfilehandleはそれぞれのために異なって定義されます。
The public filehandle is a zero filehandle. For NFS version 2 this is a filehandle with 32 zero octets. A version 3 public filehandle has zero length.
公共のfilehandleはfilehandleにaゼロです。 NFSバージョン2のために、32があるfilehandleは八重奏のゼロに合っています。 バージョン3の公共のfilehandleには、ゼロ・レングスがあります。
5.1 Version 2 Public Filehandle
5.1 バージョン2の公共のFilehandle
A version 2 filehandle is defined in RFC1094 as an opaque value occupying 32 octets. A version 2 public filehandle has a zero in each octet, i.e. all zeros.
バージョン2filehandleはRFC1094で32の八重奏を占領する不透明な値と定義されます。 バージョン2の公共のfilehandleはすなわち、各八重奏、すべてのゼロでゼロを持っています。
1 32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Callaghan Informational [Page 3] RFC 2055 WebNFS Server Specification October 1996
[3ページ]RFC2055WebNFSサーバ仕様1996年10月の情報のキャラハン
5.2 Version 3 Public Filehandle
5.2 バージョン3の公共のFilehandle
A version 3 filehandle is defined in RFC1813 as a variable length opaque value occupying up to 64 octets. The length of the filehandle is indicated by an integer value contained in a 4 octet value which describes the number of valid octets that follow. A version 3 public filehandle has a length of zero.
バージョン3filehandleはRFC1813で最大64の八重奏を占領する可変長の不透明な値と定義されます。 filehandleの長さは続く有効な八重奏の数について説明する4八重奏価値に含まれた整数値によって示されます。 バージョン3の公共のfilehandleには、ゼロの長さがあります。
+-+-+-+-+ | 0 | +-+-+-+-+
+-+-+-+-+ | 0 | +-+-+-+-+
6. Multi-component Lookup
6. 多成分系のルックアップ
Normally the NFS LOOKUP request (versions 2 or 3) takes a directory file handle along with the name of a directory member, and returns the filehandle of the directory member. If a client needs to evaluate a pathname that contains a sequence of components, then beginning with the directory file handle of the first component it must issue a series of LOOKUP requests one component at a time. For instance, evaluation of the Unix path "a/b/c" will generate separate LOOKUP requests for each component of the pathname "a", "b", and "c".
通常、NFS LOOKUP要求(バージョン2か3)は、ディレクトリメンバーの名前に伴うディレクトリファイルハンドルを取って、ディレクトリメンバーのfilehandleを返します。 クライアントが、コンポーネントの系列を含むパス名を評価する必要があるなら、最初のコンポーネントのディレクトリファイルハンドルでそれを始めると、一連のLOOKUP要求が一度に1つのコンポーネントに出されなければなりません。 例えば、「/b/c」が別々のLOOKUPを生成するUnix経路の評価はパス名の各成分のために“a"、「b」、および「c」を要求します。
A LOOKUP request that uses the public file handle can provide a pathname containing multiple components. The server is expected to evaluate the entire pathname and return a filehandle for the final component. The pathname syntax is assumed to be understood by the server, but the client must not make assumptions of the pathname syntax.
公共のファイルハンドルを使用するLOOKUP要求は複数のコンポーネントを含むパス名を提供できます。 サーバは、全体のパス名を評価して、最終的なコンポーネントのためにfilehandleを返すと予想されます。 パス名構文によってサーバに解釈されると思われますが、クライアントはパス名構文の仮定をしてはいけません。
A Unix server, for instance, uses a slash "/" character to separate components in a Unix pathname.
unixパス名のコンポーネントを切り離す「Unixサーバー、例えば、用途aは」 /をなでぎりする」というキャラクタ。
For example, rather than evaluate the path "a/b/c" as:
例えば、そして、むしろ、経路を評価する、以下としての「a/b/c」
LOOKUP FH=0x0 "a" --->
<--- FH=0x1
LOOKUP FH=0x1 "b" --->
<--- FH=0x2
LOOKUP FH=0x2 "c" --->
<--- FH=0x3
ルックアップFH=0x0“a"---><。--- FH=0x1ルックアップFH=0x1「b」---><。--- FH=0x2ルックアップFH=0x2「c」---><。--- FH=0x3
Relative to the public filehandle these three LOOKUP requests can be replaced by a single multi-component lookup:
公共のfilehandleに比例して、これらの3つのLOOKUP要求をただ一つの多成分系のルックアップに取り替えることができます:
LOOKUP FH=0x0 "a/b/c" --->
<--- FH=0x3
「/b/c」あたりのルックアップFH=0×0---><。--- FH=0x3
Callaghan Informational [Page 4] RFC 2055 WebNFS Server Specification October 1996
[4ページ]RFC2055WebNFSサーバ仕様1996年10月の情報のキャラハン
Multi-component lookup is supported only for LOOKUP requests relative to the public filehandle.
多成分系のルックアップはLOOKUP要求のためだけに公共のfilehandleに比例してサポートされます。
6.1 Canonical Path vs. Native Path
6.1 正準な経路対ネイティブの経路
If the pathname in a multi-component LOOKUP request begins with a printable ASCII character, then it must be a canonical path. A canonical path is a hierarchically-related, slash-separated sequence of components, <directory>/<directory>/.../<name>.
多成分系のLOOKUP要求におけるパス名が印刷可能なASCII文字と共に始まるなら、それは正準な経路であるに違いありません。 正準な経路がaである、階層的である、関連、コンポーネントのスラッシュで切り離された系列、<ディレクトリ>/<ディレクトリ>/…/<名前>。
Occurrences of the "/" character within a component will be escaped using the escape code %2f. Non-printable ascii characters (with values in the range 00-1F and 7f hexadecimal) will also be escaped using the "%" character to introduce a two digit hexadecimal code. Occurrences of the "%" character that do not introduce an encoded character will themselves be encoded with %25.
「発生、」 」 コンポーネントの中のキャラクタが逃げられた使用がエスケープコード%2fであったならそうする/。 非印刷可能なASCIIキャラクタ、(範囲00-1Fと7fでは、逃げられた使用が2ケタ16進コードを紹介する「%」キャラクタであったなら16進) 意志も評価します。 コード化されたキャラクタを紹介しない「%」キャラクタの発生があるために自分たちで%25でコード化されていた状態で望んでいます。
If the first character of a canonical path is a slash, then the canonical path must be evaluated relative to the server's root directory. If the first character is not a slash, then the path must be evaluated relative to the directory with which the public filehandle is associated.
正準な経路の最初のキャラクタがそうなら、スラッシュであり、そして、サーバのルートディレクトリに比例して正準な経路を評価しなければなりません。 最初のキャラクタがスラッシュでないなら、公共のfilehandleが関連しているディレクトリに比例して経路を評価しなければなりません。
Not all WebNFS servers can support arbitrary use of absolute paths. Clearly, the server cannot return a filehandle if the path identifies a file or directory that is not exported by the server. In addition, some servers will not return a filehandle if the path names a file or directory in an exported filesystem different from the one that is associated with the public filehandle.
すべてのWebNFSサーバが絶対パスの任意の使用をサポートすることができるというわけではありません。 明確に、経路がサーバによってエクスポートされないファイルかディレクトリを特定するなら、サーバはfilehandleを返すことができません。さらに、いくつかのサーバは公共のfilehandleに関連しているものと異なったエクスポートしているファイルシステムでaがパス名であるならfilehandleするどんなリターンにもファイルかディレクトリを望んでいません。
If the first character of the path is 0x80 (non-ascii) then the following character is the first in a native path. A native path conforms to the natural pathname syntax of the server. For example:
経路の最初のキャラクタが0×80(非ASCII)であるなら、以下のキャラクタはネイティブの経路で1番目です。 ネイティブの経路がサーバの自然なパス名構文に従う、例えば:
Lookup for Canonical Path:
正準な経路へのルックアップ:
LOOKUP FH=0x0 "/a/b/c"
ルックアップFH=0x0"/a/b/c"
Lookup for Native Path:
ネイティブの経路へのルックアップ:
LOOKUP FH=0x0 0x80 "a:b:c"
ルックアップFH=0x0 0x80「a:b:c」
Other introductory characters in the range 0x81 - 0xff may be added in future specifications. If the server receives any character in this range that it does not understand then it must return an error to the client: NFSERR_IO for NFS V2, NFS3ERR_IO for NFS V3.
範囲0x81の他の紹介しているキャラクタ--0xffは将来の仕様で加えられるかもしれません。 サーバがそれが理解していないこの範囲で何かキャラクタを受けるなら、誤りをクライアントに返さなければなりません: NFS V2のためのNFSERR_IO、NFS V3のためのNFS3ERR_IO。
Callaghan Informational [Page 5] RFC 2055 WebNFS Server Specification October 1996
[5ページ]RFC2055WebNFSサーバ仕様1996年10月の情報のキャラハン
6.2 Symbolic Links
6.2のシンボリックリンク
Servers that support symbolic links may encounter pathname components that are symbolic links. The server is expected to evaluate these symbolic links as a part of the normal pathname evaluation process. This is a different semantic from that of conventional component-at- a-time pathname evaluation by NFS clients, where the client is expected to do the evaluation.
シンボリックリンクをサポートするサーバはシンボリックリンクであるパス名コンポーネントに遭遇するかもしれません。 サーバが正常なパス名評価プロセスの一部としてこれらのシンボリックリンクを評価すると予想されます。 -1回のパス名では、NFSクライアントによる評価(クライアントは予想される)はそうします。これがa従来のコンポーネントのものから意味的に異なっている、評価。
However, if the final component is a symbolic link, the server must return its filehandle and let the client evaluate it.
しかしながら、クライアントは、最終的なコンポーネントがシンボリックリンクであるなら、サーバで、filehandleを返して、それを評価できなければなりません。
6.3 Export Spanning Pathnames
6.3 パス名にかかる輸出
The server may evaluate a pathname, either through a multi-component LOOKUP or as a symbolic link embedded in a pathname, that references a file or directory outside of the exported hierarchy.
サーバはパス名を評価するかもしれません、どちらか多成分系のLOOKUP、またはシンボリックリンクがエクスポートしている階層構造の外でパス名、その参照にファイルかディレクトリを埋め込んだので。
Clearly, if the destination of the path is not in an exported filesystem, then the server must return an error to the client.
明確に、エクスポートしているファイルシステムに経路の目的地がないなら、サーバは誤りをクライアントに返さなければなりません。
Many NFS server implementations rely on the MOUNT protocol for checking access to exported filesystems and NFS server does no access checking. The NFS server assumes that the filehandle does double duty: identifying a file as well as being a security token. Since WebNFS clients do not normally use the MOUNT protocol, a server that relies on MOUNT checking cannot automatically grant access to another exported filesystem at the destination of a spanning path. These servers must return an error.
多くのNFSサーバ実装が、アクセスが全くチェックしないで、サーバがそうするエクスポートしているファイルシステムとNFSへのアクセスをチェックするために山のプロトコルを当てにします。 NFSサーバは、filehandleが二つの任務を果たすと仮定します: セキュリティトークンであることと同様にファイルを特定します。 WebNFSクライアントが通常山のプロトコルを使用しないので、山の照合に依存するサーバは自動的にわたる経路の目的地の別のエクスポートしているファイルシステムへのアクセスを承諾できません。 これらのサーバは誤りを返さなければなりません。
For example: the server exports two filesystems. One is associated with the public filehandle.
例えば: サーバは2つのファイルシステムをエクスポートします。1つは公共のfilehandleに関連しています。
/export/this (public filehandle)
/export/this(公共のfilehandle)
/export/that
/export/that
The server receives a LOOKUP request with the public filehandle that identifies a file or directory in the other exported filesystem:
サーバはファイルシステムであるとエクスポートされたもう片方でファイルかディレクトリを特定する公共のfilehandleとのLOOKUP要求を受け取ります:
LOOKUP 0x0 "../that/file"
or
LOOKUP 0x0 "/export/that/file"
「ルックアップ0x0。」"/that/file"かルックアップ0x0"/export/that/file"
Even though the pathname destination is in an exported filesystem, the server cannot return a filehandle without an assurance that the client's use of this filehandle will be authorized.
エクスポートしているファイルシステムにはパス名の目的地がありますが、サーバはクライアントのこのfilehandleの使用が認可されるという保証なしでfilehandleを返すことができません。
Callaghan Informational [Page 6] RFC 2055 WebNFS Server Specification October 1996
[6ページ]RFC2055WebNFSサーバ仕様1996年10月の情報のキャラハン
Servers that check client access to an export on every NFS request have more flexibility. These servers can return filehandles for paths that span exports since the client's use of the filehandle for the destination filesystem will be checked by the NFS server.
あらゆるNFS要求のときに輸出品へのクライアントアクセスをチェックするサーバが、より多くの柔軟性を持っています。 これらのサーバはクライアントの目的地ファイルシステムのfilehandleの使用がNFSサーバによってチェックされるので輸出にかかる経路にfilehandlesを返すことができます。
7. Location of Public Filehandle
7. 公共のFilehandleの位置
A server administrator can associate the public filehandle with any file or directory. For instance, a WebNFS server administrator could attach the public filehandle to the root of an anonymous FTP archive, so that anonymous FTP pathnames could be used to identify files in the FTP hierarchy, e.g.
サーバアドミニストレータはどんなファイルやディレクトリにも公共のfilehandleを関連づけることができます。 例えば、WebNFSサーバアドミニストレータは公開FTPアーカイブの根に公共のfilehandleを取り付けることができました、例えばFTP階層構造でファイルを特定するのに公開FTPパス名を使用できるように
# share -o ro,public /export/ftp
# -o ro、公衆/輸出/ftpを共有してください。
On servers that support spanning paths, the public filehandle need not necessarily be attached to an exported directory, though a successful LOOKUP relative to the public filehandle must identify a file or directory that is exported.
わたるのに経路をサポートするサーバでは、公共のfilehandleは必ずエクスポートしているディレクトリに取り付けられなければならないというわけではありません、公共のfilehandleに比例したうまくいっているLOOKUPがエクスポートされるファイルかディレクトリを特定しなければなりませんが。
For instance, if an NFS server exports a directory "/export/foo" and the public filehandle is attached to the server's root directory, then a LOOKUP of "export/foo" relative to the public filehandle will return a valid file handle but a LOOKUP of "export" will return an access error since the server's "/export" directory is not exported.
「例えば、NFSサーバが、ディレクトリが"/export/foo"であるとエクスポートして、公共のfilehandleがサーバのルートディレクトリに取り付けられると、公共のfilehandleに比例した「輸出/foo」のLOOKUPは有効なファイルハンドルを返すでしょうが、「輸出」のLOOKUPはサーバのもの以来のアクセスエラーを返す」という」 ディレクトリがエクスポートされない/輸出。
/ (public filehandle is here)
/\
/ \
/ export (not exported)
/ /\
/ / \
/ / foo (exported)
/(公共のfilehandleがここにある)/\/\/輸出(エクスポートされない)//\//\//foo(エクスポートされます)
LOOKUP 0x0 "export" (returns an error)
ルックアップ0x0「輸出」(誤りを返します)
LOOKUP 0x0 "export/foo" (returns an filehandle)
ルックアップ0x0「輸出/foo」(filehandleを返します)
8. Index Files
8. 索引ファイル
Most HTTP servers support the concept of an index file. If a browser references a directory that contains an index file, then the server will return the contents of the index file rather than a directory listing. For instance if a browser requests "a/b/c" then the server might return the contents of "a/b/c/index.html".
ほとんどのHTTPサーバが索引ファイルの概念をサポートします。 ブラウザが索引ファイルを含むディレクトリに参照をつけると、サーバはディレクトリリストよりむしろ索引ファイルのコンテンツを返すでしょう。 例えば、ブラウザが「/b/c」を要求するなら、サーバは「/b/c/index.html」のコンテンツを返すかもしれません。
Callaghan Informational [Page 7] RFC 2055 WebNFS Server Specification October 1996
[7ページ]RFC2055WebNFSサーバ仕様1996年10月の情報のキャラハン
A WebNFS server may choose to emulate this feature for the benefit of clients using the NFS protocol to browse a Web hierarchy. On receiving a multi-component lookup for a canonical path that names a directory, the server can check that directory for the presence of an index file. If the file exists then the server may choose to return the filehandle of the index file instead of the directory. Index files are commonly called "index.html" though the name is usually configurable.
WebNFSサーバは、ウェブ階層構造をブラウズするのにNFSプロトコルを使用することでクライアントの利益のためのこの特徴を見習うのを選ぶかもしれません。 ディレクトリを命名する正準な経路に多成分系のルックアップを受けると、サーバは索引ファイルの存在がないかどうかそのディレクトリをチェックできます。 ファイルが存在しているなら、サーバは、ディレクトリの代わりに索引ファイルのfilehandleを返すのを選ぶかもしれません。 名前は通常構成可能ですが、索引ファイルは一般的に"index.html"と呼ばれます。
9. Bibliography
9. 図書目録
[RFC1831] Srinivasan, R., "RPC: Remote Procedure Call
Protocol Specification Version 2", RFC 1831,
August 1995.
http://www.internic.net/rfc/rfc1831.txt
[RFC1831]Srinivasan、R.、「RPC:」 遠隔手続き呼び出しプロトコル仕様バージョン2インチ、RFC1831、8月1995日の http://www.internic.net/rfc/rfc1831.txt
[RFC1832] Srinivasan, R., "XDR: External Data Representation
Standard," RFC 1832, August 1995.
http://www.internic.net/rfc/rfc1832.txt
[RFC1832]Srinivasan、R.、「XDR:」 「外部データ表現規格」、RFC1832、8月1995日の http://www.internic.net/rfc/rfc1832.txt
[RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC
Version 2", RFC 1833, August 1995.
http://www.internic.net/rfc/rfc1833.txt
[RFC1833] Srinivasan、R.、「ONC RPCでプロトコルをバージョン2インチ縛るRFC1833、8月1995日の http://www.internic.net/rfc/rfc1833.txt 」
[RFC1094] Sun Microsystems, Inc., "Network Filesystem
Specification", RFC 1094, March 1989. NFS
version 2 protocol specification.
http://www.internic.net/rfc/rfc1094.txt
[RFC1094]サン・マイクロシステムズ・インク、「ネットワークファイルシステム仕様」、RFC1094、1989年3月。 NFSバージョン2プロトコル仕様 http://www.internic.net/rfc/rfc1094.txt
[RFC1813] Sun Microsystems, Inc., "NFS Version 3 Protocol
Specification", RFC 1813, June 1995. NFS version
3 protocol specification.
http://www.internic.net/rfc/rfc1813.txt
[RFC1813]サン・マイクロシステムズ・インク、「NFSバージョン3プロトコル仕様」、RFC1813、1995年6月。 NFSバージョン3プロトコル仕様 http://www.internic.net/rfc/rfc1813.txt
[RFC2054] Callaghan, B., "WebNFS Client Specification",
RFC 2054, October 1996.
http://www.internic.net/rfc/rfc2054.txt
[RFC2054] キャラハン、B.、「WebNFSクライアント仕様」、RFC2054、10月1996日の http://www.internic.net/rfc/rfc2054.txt
[Sandberg] Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh,
B. Lyon, "Design and Implementation of the Sun
Network Filesystem," USENIX Conference
Proceedings, USENIX Association, Berkeley, CA,
Summer 1985. The basic paper describing the
SunOS implementation of the NFS version 2
protocol, and discusses the goals, protocol
specification and trade-offs.
[サンドベルイ]サンドベルイ、R.、D.ゴールドバーグ、S.Kleiman、D.ウォルシュ、B.リヨン、「太陽のデザインと実装はファイルシステムをネットワークでつなぎます」、USENIX会議の議事録、USENIX協会、バークレー(カリフォルニア)1985年夏。 NFSバージョン2のSunOS実装について説明する基本的な紙は、目標、プロトコル仕様、およびトレードオフを議定書の中で述べて、議論します。
Callaghan Informational [Page 8] RFC 2055 WebNFS Server Specification October 1996
[8ページ]RFC2055WebNFSサーバ仕様1996年10月の情報のキャラハン
[X/OpenNFS] X/Open Company, Ltd., X/Open CAE Specification:
Protocols for X/Open Internetworking: XNFS,
X/Open Company, Ltd., Apex Plaza, Forbury Road,
Reading Berkshire, RG1 1AX, United Kingdom,
1991. This is an indispensable reference for
NFS version 2 protocol and accompanying
protocols, including the Lock Manager and the
Portmapper.
[X/OpenNFS] X/Open会社Ltd.、X/Open CAE仕様: X/Openインターネットワーキングのためのプロトコル: XNFS X/Open会社Ltd.、頂点広場、フォーベリー道路がバークシャーを読むRG1 1AX、イギリスの1991。 これはLockマネージャとPortmapperを含むNFSバージョン2プロトコルと付随のプロトコルの不可欠の参照です。
[X/OpenPCNFS] X/Open Company, Ltd., X/Open CAE Specification:
Protocols for X/Open Internetworking: (PC)NFS,
Developer's Specification, X/Open Company, Ltd.,
Apex Plaza, Forbury Road, Reading Berkshire, RG1
1AX, United Kingdom, 1991. This is an
indispensable reference for NFS version 2
protocol and accompanying protocols, including
the Lock Manager and the Portmapper.
[X/OpenPCNFS] X/Open会社Ltd.、X/Open CAE仕様: X/Openインターネットワーキングのためのプロトコル: (PC)NFS開発者の仕様、X/Open会社Ltd.、頂点広場、フォーベリー道路がバークシャーを読むRG1 1AX、イギリスの1991。 これはLockマネージャとPortmapperを含むNFSバージョン2プロトコルと付随のプロトコルの不可欠の参照です。
10. Security Considerations
10. セキュリティ問題
Since the WebNFS server features are based on NFS protocol versions 2 and 3, the RPC security considerations described in RFC 1094, RFC 1813, and Appendix A of RFC 1831 apply here also.
WebNFSサーバ機能がNFSプロトコルバージョン2と3に基づいているので、また、RFC1831のRFC1094、RFC1813、およびAppendix Aで説明されたRPCセキュリティ問題はここに適用されます。
Clients and servers may separately negotiate secure connection schemes for authentication, data integrity, and privacy.
クライアントとサーバは別々に認証、データ保全、およびプライバシーの安全な接続体系を交渉するかもしれません。
Implementors must note carefully the implications of export spanning pathnames as described in section 6.3.
作成者は慎重にセクション6.3で説明されるようにパス名にかかる輸出の含意に注意しなければなりません。
11. Acknowledgements
11. 承認
This specification was extensively reviewed by the NFS group at SunSoft and brainstormed by Michael Eisler.
この仕様は、SunSoftでNFSグループによって手広く見直されて、マイケル・アイスラーによってブレインストーミングされました。
Callaghan Informational [Page 9] RFC 2055 WebNFS Server Specification October 1996
[9ページ]RFC2055WebNFSサーバ仕様1996年10月の情報のキャラハン
12. Author's Address
12. 作者のアドレス
Address comments related to this document to:
アドレスコメントは以下のことのためにこのドキュメントに関連しました。
nfs@eng.sun.com
nfs@eng.sun.com
Brent Callaghan Sun Microsystems, Inc. 2550 Garcia Avenue Mailstop Mpk17-201 Mountain View, CA 94043-1100
ブレントキャラハンサン・マイクロシステムズ・インク2550ガルシア・アベニューMailstop Mpk17-201マウンテンビュー、カリフォルニア94043-1100
Phone: 1-415-786-5067 Fax: 1-415-786-5896 EMail: brent.callaghan@eng.sun.com
以下に電話をしてください。 1-415-786-5067 Fax: 1-415-786-5896 メールしてください: brent.callaghan@eng.sun.com
Callaghan Informational [Page 10]
キャラハンInformationalです。[10ページ]
一覧
スポンサーリンク
