[svnbook commit] r1602 - trunk/src/zh/book
rocksun
svnbook-dev at red-bean.com
Fri Aug 12 12:32:49 CDT 2005
Author: rocksun
Date: Fri Aug 12 12:32:48 2005
New Revision: 1602
Modified:
trunk/src/zh/book/ch06.xml
Log:
* zh/book/ch06.xml: Add UTF BOM, finished, need more check up.
Modified: trunk/src/zh/book/ch06.xml
==============================================================================
--- trunk/src/zh/book/ch06.xml (original)
+++ trunk/src/zh/book/ch06.xml Fri Aug 12 12:32:48 2005
@@ -1,23 +1,12 @@
-<chapter id="svn-ch-6">
- <title>Server Configuration</title>
+<chapter id="svn-ch-6">
+ <title>配置服务器</title>
<simplesect>
- <para>A Subversion repository can be accessed simultaneously by
- clients running on the same machine on which the repository
- resides using the <literal>file:///</literal> method. But the
- typical Subversion setup involves a single server machine being
- accessed from clients on computers all over the office—or,
- perhaps, all over the world.</para>
+ <para>一个Subversion的版本库可以和客户端同时运行在同一个机器上，使用<literal>file:///</literal>访问，但是一个典型的Subversion设置包括一个单独的服务器，可以被办公室的所有客户端访问—或者有可能是整个世界。</para>
- <para>This section describes how to get your Subversion repository
- exposed outside its host machine for use by remote clients. We
- will cover Subversion's currently available server mechanisms,
- discussing the configuration and use of each. After reading
- this section, you should be able to decide which networking
- setup is right for your needs, and understand how to enable such
- a setup on your host computer.</para>
+ <para>本小节描述了怎样使一个Subversion的版本库从主机暴露给远程客户端，我们会覆盖Subversion已存在的服务器机制，讨论各种方式的配置和使用。经过阅读本小节，你一定可以决定那种网络设置是你需要的，并且明白怎样在你的主机上进行配置。</para>
</simplesect>
@@ -26,115 +15,90 @@
<!-- ================================================================= -->
<sect1 id="svn-ch-6-sect-1">
- <title>Overview</title>
+ <title>概述</title>
- <para>Subversion was designed with an abstract network layer.
- This means that a repository can be programmatically accessed by
- any sort of server process, and the client <quote>repository
- access</quote> API allows programmers to write plugins that
- speak relevant network protocols. In theory, Subversion can use
- an infinite number of network implementations. In practice,
- there are only two servers at the time of writing.</para>
-
- <para>Apache is an extremely popular webserver; using the
- <command>mod_dav_svn</command> module, Apache can access a
- repository and make it available to clients via the WebDAV/DeltaV
- protocol, which is an extension of HTTP. In the other corner is
- <command>svnserve</command>: a small, standalone server
- program that speaks a custom protocol with clients. Table 6-1
- presents a comparison of the two servers.</para>
-
- <para>Note that Subversion, as an open-source project, does not
- officially endorse any server as <quote>primary</quote> or
- <quote>official</quote>. Neither network implementation is
- treated as a second-class citizen; each server has advantages
- and disadvantages. In fact, it's possible for different servers
- to run in parallel, each accessing your repositories in its own
- way, and each without hindering the other (see <xref
- linkend="svn-ch-6-sect-5"/>). Here's a brief overview and
- comparison of the two available Subversion servers—as an
- administrator, it's up to you to choose whatever works best for
- you and your users.</para>
+ <para>Subversion的设计包括一个抽象的网络层，这意味着版本库可以通过各种服务器进程访问，而且客户端<quote>版本库访问</quote>的API允许程序员写出相关协议的插件，理论上讲，Subversion可以使用无限数量的网络协议实现，实践中目前存在两种使用中的服务器。</para>
+
+ <para>Apache是最流行的web服务器，通过使用<command>mod_dav_svn</command>模块，Apache可以访问版本库，并且可以使客户端可以用HTTP的扩展协议WebDAV/DeltaV进行访问，在另一边是<command>svnserve</command>：一个小的，独立服务器，使用自己自定义的协议和客户端，表格6-1展现了这两种服务器的比较。</para>
+
+ <para>需要注意到Subversion作为一个开源的项目，并没有官方的指定何种服务器是<quote>主要的</quote>或者是<quote>官方的</quote>，没有那种网络实现被作为二等公民对待，没种服务器偶有自己的优点和缺点，事实上，允许不同的服务器并行工作，每一个通过自己的方式访问版本库，而且没有一个会阻碍其他的（见<xref
+ linkend="svn-ch-6-sect-5"/>）。以下是对两种存在的Subversion服务器的比较—作为一个管理员，你更加胜任给你和你的用户挑选服务器的职责。</para>
<table id="svn-ch-6-table-1">
- <title>Network Server Comparison</title>
+ <title>网络服务器比较</title>
<tgroup cols="3">
<thead>
<row>
- <entry>Feature</entry>
+ <entry>特性</entry>
<entry>Apache + mod_dav_svn</entry>
<entry>svnserve</entry>
</row>
</thead>
<tbody>
<row>
- <entry>Authentication options</entry>
+ <entry>认证选项</entry>
- <entry>HTTP(S) basic auth, X.509 certificates, LDAP, NTLM, or
- any other mechanism available to Apache httpd</entry>
+ <entry>HTTP(S) basic auth、X.509 certificates、LDAP、NTLM,或者任何Apache httpd已经具备的方式。</entry>
- <entry>CRAM-MD5 or SSH</entry>
+ <entry>CRAM-MD5或SSH</entry>
</row>
<row>
- <entry>User account options</entry>
+ <entry>用户帐号选项</entry>
- <entry>private 'users' file</entry>
+ <entry>私有的'users'文件</entry>
- <entry>private 'users' file, or existing system (SSH)
- accounts</entry>
+ <entry>私有的'users'文件，或存在的系统(SSH)帐户
+ </entry>
</row>
<row>
- <entry>Authorization options</entry>
+ <entry>授权选项</entry>
- <entry>blanket read/write access, or per-directory
- read/write control</entry>
+ <entry>整体的读/写访问，或者是每目录的读/写访问</entry>
- <entry>blanket read/write access, or per-directory write
- (but not read) control using a pre-commit hook</entry>
+ <entry>整体的读/写访问，或者是使用pre-commit钩子的每目录写访问（但不是读）</entry>
</row>
<row>
- <entry>Encryption</entry>
+ <entry>加密</entry>
- <entry>via optional SSL</entry>
+ <entry>通过选择SSL</entry>
- <entry>via optional SSH tunnel</entry>
+ <entry>通过选择SSH通道</entry>
</row>
<row>
- <entry>Interoperability</entry>
+ <entry>交互性</entry>
- <entry>partially usable by other WebDAV clients</entry>
+ <entry>可以部分的被其他WebDAV客户端使用</entry>
- <entry>not interoperable</entry>
+ <entry>不能被其他客户端使用</entry>
</row>
<row>
- <entry>Web viewing</entry>
+ <entry>Web浏览能力</entry>
- <entry>limited built-in support, or via 3rd-party tools
- such as ViewCVS</entry>
+ <entry>有限的内置支持，或者通过第三方工具，如ViewCVS</entry>
- <entry>via 3rd-party tools such as ViewCVS</entry>
+ <entry>通过第三方工具，如ViewCVS</entry>
</row>
<row>
- <entry>Speed</entry>
+ <entry>速度</entry>
- <entry>somewhat slower</entry>
+ <entry>有些慢</entry>
- <entry>somewhat faster</entry>
+ <entry>快一点</entry>
</row>
<row>
- <entry>Initial setup</entry>
+ <entry>初始化配置</entry>
- <entry>somewhat complex</entry>
+ <entry>有些复杂</entry>
- <entry>fairly simple</entry>
+ <entry>相当简单</entry>
</row>
</tbody>
@@ -148,9 +112,10 @@
<!-- ================================================================= -->
<sect1 id="svn-ch-6-sect-2">
- <title>Network Model</title>
+ <title>网络模型</title>
- <para>This section is a general discussion of how a Subversion
+ <para>这部分是讨论了Subversion客户端和服务器怎样互相交流，不考虑具体使用的网络实现，通过阅读，你会很好的理解服务器的行为方式和多种对客户端访问响应的配置方式。
+ This section is a general discussion of how a Subversion
client and server interact with one another, regardless of the
network implementation you're using. After reading, you'll have
a good understanding of how a server can behave and the
@@ -158,86 +123,31 @@
respond.</para>
<sect2 id="svn-ch-6-sect-2.1">
- <title>Requests and Responses</title>
+ <title>请求和响应</title>
+
+ <para>Subversion客户端花费大量的时间来管理工作拷贝，当它需要版本库信息，它会做一个网络请求，然后服务器给一个家当的回答，具体的网络协议细节用户不可见，客户端尝试去访问一个URL，根据URL模式的不同，会使用特定的协议与服务器联系（见<xref
+ linkend="svn-ch-2-sidebar-1"/>），用户可以运行<command>svn
+ --version</command>来查看客户端可以使用的URL模式和协议。</para>
+
+ <para>当服务器处理一个客户端请求，它通常会要求客户端确定它自己的身份，它会发出一个认证挑战给客户端，而客户端通过提供<firstterm>凭证</firstterm>给服务器，一旦认证结束，服务器会响应客户端最初请求的信息。注意这个系统与CVS之类的系统不一样，它们会在请求之前，预先提供凭证(<quote>logs
+ in</quote>)给服务器，在Subversion里，服务器通过挑战客户端适时地<quote>拖入</quote>凭证，而不是客户端<quote>推</quote>出。这使得这种操作更加的优雅，例如，如果一个服务器配置为世界上的任何人都可以读取版本库，在客户使用<command>svn
+ checkout</command>时，服务器永远不会发起一个认证挑战。</para>
- <para>The Subversion client spends most of its time managing
- working copies. When it needs information from a repository,
- however, it makes a network request, and the server responds
- with an appropriate answer. The details of the network
- protocol are hidden from the user; the client attempts to
- access a URL, and depending on the URL schema, a particular
- protocol is used to contact the server (see <xref
- linkend="svn-ch-2-sidebar-1"/>). Users can run <command>svn
- --version</command> to see which URL schemas and protocols the
- client knows how to use.</para>
-
- <para>When the server process receives a client request, it
- typically demands that the client identify itself. It issues
- an authentication challenge to the client, and the client
- responds by providing <firstterm>credentials</firstterm> back
- to the server. Once authentication is complete, the server
- responds with the original information the client asked for.
- Notice that this system is different from systems like CVS,
- where the client pre-emptively offers credentials (<quote>logs
- in</quote>) to the server before ever making a request. In
- Subversion, the server <quote>pulls</quote> credentials by
- challenging the client at the appropriate moment, rather than
- the client <quote>pushing</quote> them. This makes certain
- operations more elegant. For example, if a server is
- configured to allow anyone in the world to read a repository,
- then the server will never issue an authentication challenge
- when a client attempts to <command>svn
- checkout</command>.</para>
-
- <para>If the client's network request writes new data to the
- repository (e.g. <command>svn commit</command>), then a new
- revision tree is created. If the client's request was
- authenticated, then the authenticated user's name is stored as
- the value of the <literal>svn:author</literal> property on the
- new revision (see <xref linkend="svn-ch-5-sect-1.2"/>). If
- the client was not authenticated (in other words, the server
- never issued an authentication challenge), then the revision's
- <literal>svn:author</literal> property is empty.
- <footnote><para>This problem is actually a FAQ, resulting from
- a misconfigured server setup.</para></footnote></para>
+ <para>如果客户端请求往版本库写入新的数据（例如<command>svn commit</command>），这会新的修订版本树辉建立起来，如果客户端的请求是经过认证的，认证过的用户的用户名就会作为<literal>svn:author</literal>属性的值保存到新的修订本里（见<xref linkend="svn-ch-5-sect-1.2"/>）。如果客户端没有经过认证（换句话说，服务器没有发起过认证挑战），这时修订本的<literal>svn:author</literal>的值是空的，<footnote><para>这个问题实际上是一个FAQ，源自错误的服务器配置。</para></footnote></para>
</sect2>
<sect2 id="svn-ch-6-sect-2.2">
- <title>Client Credentials Caching</title>
+ <title>客户端凭证缓存</title>
- <para>Many servers are configured to require authentication on
- every request. This can become a big annoyance to users, who
- are forced to type their passwords over and over again.</para>
-
- <para>Happily, the Subversion client has a remedy for this: a
- built-in system for caching authentication credentials on
- disk. By default, whenever the command-line client
- successfully authenticates itself to a server, it saves the
- credentials in the user's private runtime configuration
- area—in <filename>~/.subversion/auth/</filename> on
- Unix-like systems or
- <filename>%APPDATA%/Subversion/auth/</filename> on Windows.
- (The runtime area is covered in more detail in <xref
- linkend="svn-ch-7-sect-1"/>.) Successful credentials are
- cached on disk, keyed on a combination of hostname, port, and
- authentication realm.</para>
-
- <para>When the client receives an authentication challenge, it
- first looks for the appropriate credentials in the disk cache;
- if not present, or if the cached credentials fail to
- authenticate, then the client simply prompts the user for the
- information.</para>
-
- <para>The security-paranoid people may be thinking to
- themselves, <quote>Caching passwords on disk? That's
- terrible! You should never do that!</quote> But please remain
- calm. First, the <filename>auth/</filename> caching area is
- permission-protected so that only the user (owner) can read
- data from it, not the world at large. If that's still not
- safe enough for you, you can disable credential caching. To
- disable caching for a single command, pass the
- <option>--no-auth-cache</option> option:</para>
+ <para>许多服务器配置为在每次请求时要求认证，这对一次次输入用户名和密码的用户是非常讨厌的事情。</para>
+
+ <para>令人高兴的是，Subversion客户端对此有一个修补：存在一个在磁盘上保存认证凭证缓存的系统，缺省情况下，当一个命令行客户端成功的在服务器上得到认证，它会保存一个认证文件到用户的自由运行配置区域—类Unix系统下会在<filename>~/.subversion/auth/</filename>，Windows下在<filename>%APPDATA%/Subversion/auth/</filename>（运行区域在<xref
+ linkend="svn-ch-7-sect-1"/>会描述更多细节）。成功的凭证会缓存在磁盘，以主机名、端口和认证域的混合作为唯一性区别。</para>
+
+ <para>当客户端接收到一个认证挑战，它会首先查找磁盘中的认证凭证缓存，如果没有发现，或者是缓存的凭证认证失败，客户端会提示用户需要这些信息。</para>
+
+ <para>十分关心安全的人们一定会想<quote>把密码缓存在磁盘？太可怕了，永远不要这样做！</quote>但是请保持冷静，首先，<filename>auth/</filename>是访问保护的，只有用户（拥有者）可以读取这些数据，不是整个世界，如果这对你还不够安全，你可以关闭凭证缓存，只需要一个简单的命令，使用参数<option>--no-auth-cache</option>：</para>
<screen>
$ svn commit -F log_msg.txt --no-auth-cache
@@ -258,26 +168,14 @@
[...]
</screen>
- <para>Or, if you want to disable credential caching permanently,
- you can edit your runtime <filename>config</filename> file
- (located next to the <filename>auth/</filename> directory).
- Simply set <literal>store-auth-creds</literal> to
- <literal>no</literal>, and no credentials will be cached on
- disk, ever.</para>
+ <para>或许，你希望永远关闭凭证缓存，你可以编辑你的运行<filename>配置</filename>文件（坐落在<filename>auth/</filename>目录），只需要把<literal>store-auth-creds</literal>设置为<literal>no</literal>，这样就不会有凭证缓存在磁盘。</para>
<screen>
[auth]
store-auth-creds = no
</screen>
- <para>Sometimes users will want to remove specific credentials
- from the disk cache. To do this, you need to navigate into
- the <filename>auth/</filename> area and manually delete the
- appropriate cache file. Credentials are cached in individual
- files; if you look inside each file, you will see keys and
- values. The <literal>svn:realmstring</literal> key describes
- the particular server realm that the file is associated
- with:</para>
+ <para>有时候，用户希望从磁盘缓存删除特定的凭证，为此你可以浏览到<filename>auth/</filename>区域，删除特定的缓存文件，凭证都是作为一个单独的文件缓存，如果你打开每一个文件，你会看到键和值，<literal>svn:realmstring</literal>描述了这个文件关联的特定服务器的域：</para>
<screen>
$ ls ~/.subversion/auth/svn.simple/
@@ -302,72 +200,37 @@
END
</screen>
- <para>Once you have located the proper cache file, just delete
- it.</para>
+ <para>一旦你定位了正确的缓存文件，只需要删除它。</para>
- <para>One last word about client authentication behavior: a bit
- of explanation about the <option>--username</option> and
- <option>--password</option> options is needed. Many client
- subcommands accept these options; however it is important to
- understand using these options <emphasis>does not</emphasis>
- automatically send credentials to the server. As discussed
- earlier, the server <quote>pulls</quote> credentials from the
- client when it deems necessary; the client cannot
- <quote>push</quote> them at will. If a username and/or
- password are passed as options, they will
- <emphasis>only</emphasis> be presented to the server if the
- server requests them.
-
- <footnote><para>Again, a common mistake is to misconfigure a
- server so that it never issues an authentication challenge.
- When users pass <option>--username</option> and
- <option>--password</option> options to the client,
- they're surprised to see that they're never used, i.e. new
- revisions still appear to have been committed
- anonymously!</para></footnote>
-
- Typically, these options are used when:</para>
+ <para>客户端认证的行为的最后一点：对使用<option>--username</option>和<option>--password</option>选项的一点说明，许多客户端和子命令接受这个选项，但是要明白这个选项<emphasis>不会</emphasis>主动地发送凭证信息到服务器，为了讨论的简单，服务器会在必须需要的时候才会从客户端<quote>拖</quote>如凭证，客户端不会随意<quote>推</quote>出。如果一个用户名和/或者密码作为选项传入，它们<emphasis>只会</emphasis>在服务器需要时展现给服务器。<footnote><para>在一次，一个常见的错误是把服务器配置为从不会请求认证，当用户传递<option>--username</option>和<option>--password</option>给客户端时，他们惊奇的发现它们没有被使用，如新的修订版本看起来始终是由匿名用户提交的！</para></footnote>通常，在如下情况下使用这些选项：</para>
<itemizedlist>
<listitem>
- <para>the user wants to authenticate as a different user
- than her system login name, or</para>
+ <para>用户希望使用与登陆系统不同的名字认证，或者</para>
</listitem>
<listitem>
- <para>a script wants to authenticate without using cached
- credentials.</para>
+ <para>一段不希望使用缓存凭证但需要认证的脚本</para>
</listitem>
</itemizedlist>
- <para>Here is a final summary that describes how a Subversion
- client behaves when it receives an authentication
- challenge:</para>
+ <para>这里是Subversion客户端在收到认证挑战的时候的行为方式：</para>
<orderedlist>
<listitem>
- <para>Check whether the user specified any credentials as
- command-line options, via <option>--username</option>
- and/or <option>--password</option>. If not, or if these
- options fail to authenticate successfully, then</para>
+ <para>检查用户是否通过<option>--username</option>和/或<option>--password</option>命令选项指定了任何凭证信息，如果没有，或者这些选项没有认证成功，然后</para>
</listitem>
<listitem>
- <para>Look up the server's realm in the runtime
- <filename>auth/</filename> area, to see if the user already
- has the appropriate credentials cached. If not, or if the
- cached credentials fail to authenticate, then</para>
+ <para>查找运行中的<filename>auth/</filename>区域保存的服务器域信息，来确定用户是否已经有了恰当的认证缓存，如果没有，或者缓存凭证认证失败，然后</para>
</listitem>
<listitem>
- <para>Resort to prompting the user.</para>
+ <para>提示用户输入。</para>
</listitem>
</orderedlist>
- <para>If the client successfully authenticates by any of the
- methods listed above, it will attempt to cache the credentials
- on disk (unless the user has disabled this behavior, as
- mentioned earlier.)</para>
+ <para>如果客户端通过以上的任何一种方式成功认证，它会尝试在磁盘缓存凭证（除非用户已经关闭了这些行为，在前面提到过。）</para>
</sect2>
@@ -379,148 +242,68 @@
<!-- ================================================================= -->
<sect1 id="svn-ch-6-sect-3">
- <title>svnserve, a custom server</title>
+ <title>svnserve，一个自定义的服务器</title>
- <para>The <command>svnserve</command> program is a lightweight
- server, capable of speaking to clients over TCP/IP using a
- custom, stateful protocol. Clients contact an
- <command>svnserve</command> server by using URLs that begin with
- the <literal>svn://</literal> or <literal>svn+ssh://</literal>
- schema. This section will explain the different ways of running
- <command>svnserve</command>, how clients authenticate themselves
- to the server, and how to configure appropriate access control
- to your repositories.</para>
+ <para><command>svnserve</command>是一个轻型的服务器，可以同客户端在TCP/IP基础上的自定义有状态协议通讯，客户端通过使用开头为<literal>svn://</literal>或者<literal>svn+ssh://</literal><command>svnserve</command>的URL来访问一个<command>svnserve</command>服务器，这部分将会解释运行<command>svnserve</command>的不同方式，客户端怎样实现服务器的认证，怎样配制版本库恰当的访问控制。</para>
<sect2 id="svn-ch-6-sect-3.1">
- <title>Invoking the Server</title>
+ <title>调用服务器</title>
- <para>There are a few different ways to invoke the
- <command>svnserve</command> program. If invoked with no
- options, you'll see nothing but a help message. However, if
- you're planning to have <command>inetd</command> launch the
- process, then you can pass the <option>-i</option>
- (<option>--inetd</option>) option:</para>
+ <para>有许多调用<command>svnserve</command>的方式，如果调用时没有参数，你只会看到一些帮助信息，然而，如果你计划使用<command>inetd</command>启动进程，你可以传递<option>-i</option>（<option>--inetd</option>）选项：</para>
<screen>
$ svnserve -i
( success ( 1 2 ( ANONYMOUS ) ( edit-pipeline ) ) )
</screen>
- <para>When invoked with the <option>--inetd</option> option,
- <command>svnserve</command> attempts to speak with a
- Subversion client via <emphasis>stdin</emphasis> and
- <emphasis>stdout</emphasis> using a custom protocol. This is
- the standard behavior for a program being run via
- <command>inetd</command>. The IANA has reserved port 3690
- for the Subversion protocol, so on a Unix-like system you can
- add lines to <filename>/etc/services</filename> like these (if
- they don't already exist):</para>
+ <para>当用参数<option>--inetd</option>调用时，<command>svnserve</command>会尝试使用自定义协议通过<emphasis>stdin</emphasis>和<emphasis>stdout</emphasis>来与Subversion客户端通话，这是使用<command>inetd</command>工作的标准方式，IANA为Subversion协议保留3690端口，所以在类Unix系统你可以在<filename>/etc/services</filename>添加如下的几行（如果他们还不存在）：</para>
<screen>
svn 3690/tcp # Subversion
svn 3690/udp # Subversion
</screen>
- <para>And if your system is using a classic Unix-like
- <command>inetd</command> daemon, you can add this line to
- <filename>/etc/inetd.conf</filename>:</para>
+ <para>如果系统是使用经典的类Unix的<command>inetd</command>守护进程，你可以在<filename>/etc/inetd.conf</filename>添加这几行：</para>
<screen>
svn stream tcp nowait svnowner /usr/bin/svnserve svnserve -i
</screen>
- <para>Make sure <quote>svnowner</quote> is a user which has
- appropriate permissions to access your repositories. Now, when
- a client connection comes into your server on port 3690,
- <command>inetd</command> will spawn an
- <command>svnserve</command> process to service it.</para>
-
- <para>On a Windows system, third-party tools exist to run
- <command>svnserve</command> as a service. Look on Subversion's
- website for a list of these tools.</para>
-
- <para>A second option is to run <command>svnserve</command> as a
- standalone <quote>daemon</quote> process. Use the
- <option>-d</option> option for this:</para>
+ <para>确定<quote>svnowner</quote>用户拥有访问版本库的适当权限，现在如果一个客户连接来到你的服务器的端口3690，<command>inetd</command>会产生一个<command>svnserve</command>进程来做服务。</para>
+
+ <para>在一个Windows系统，有第三方工具可以将<command>svnserve</command>作为服务运行，请看Subversion的网站的工具列表。</para>
+
+ <para><command>svnserve</command>的第二个选项是作为独立<quote>守护</quote>进程，为此要使用<option>-d</option>选项：</para>
<screen>
$ svnserve -d
$ # svnserve is now running, listening on port 3690
</screen>
- <para>When running <command>svnserve</command> in daemon mode,
- you can use the <option>--listen-port=</option> and
- <option>--listen-host=</option> options to customize the exact
- port and hostname to <quote>bind</quote> to.</para>
-
- <para>There's still a third way to invoke
- <command>svnserve</command>, and that's in <quote>tunnel
- mode</quote>, with the <option>-t</option> option. This mode
- assumes that a remote-service program such as
- <command>RSH</command> or <command>SSH</command> has
- successfully authenticated a user and is now invoking a
- private <command>svnserve</command> process <emphasis>as that
- user</emphasis>. The <command>svnserve</command> program
- behaves normally (communicating via <emphasis>stdin</emphasis>
- and <emphasis>stdout</emphasis>), and assumes that the traffic
- is being automatically redirected over some sort of tunnel
- back to the client. When <command>svnserve</command> is
- invoked by a tunnel agent like this, be sure that the
- authenticated user has full read and write access to the
- repository database files. (See <xref
- linkend="svn-ch-6-sidebar-1"/>.) It's essentially the same as
- a local user accessing the repository via
- <literal>file:///</literal> URLs.</para>
+ <para>当以守护模式运行<command>svnserve</command>时，你可以使用<option>--listen-port=</option>选项<option>--listen-host=</option>来自定义<quote>绑定</quote>的端口和主机。</para>
+
+ <para>也一直有第三种方式,使用<quote>管道模式</quote>,通过<option>-t</option>选项,这个模式假定一个分布式服务程序如<command>RSH</command>或<command>SSH</command>已经验证了一个用户，并且<emphasis>以这个用户</emphasis>调用了一个私有<command>svnserve</command>进程，<command>svnserve</command>运作如常（通过<emphasis>stdin</emphasis>通讯<emphasis>stdout</emphasis>），并且假定通讯转向到一种通道传递到客户端，当<command>svnserve</command>被这样的通道代理调用，确定认证用户对版本数据库有完全的读写权限。（见xref
+ linkend="svn-ch-6-sidebar-1"/>。）这对本地用户使用<literal>file:///</literal>URl访问版本库同样重要。</para>
<sidebar id="svn-ch-6-sidebar-1">
- <title>Servers and Permissions: A Word of Warning</title>
+ <title>服务器和许可：一个警告</title>
+
+ <para>首先需要记住，一个Subversion版本库是一组数据库文件，任何进程直接访问版本库需要对整个版本库有正确的读写许可，如果你不小心，这会很头痛，特别是当你使用BerkeleyDB数据库而不是FSFS时，详细信息可以阅读<xref linkend="svn-ch-6-sect-5"/>。</para>
- <para>First, remember that a Subversion repository is a
- collection of database files; any process which accesses the
- repository directly needs to have proper read and write
- permissions on the entire repository. If you're not
- careful, this can lead to a number of headaches, especially
- if you're using a BerkeleyDB database rather than FSFS. Be
- sure to read <xref linkend="svn-ch-6-sect-5"/>.</para>
-
- <para>Secondly, when configuring <command>svnserve</command>,
- Apache <command>httpd</command>, or any other server
- process, keep in mind that you might not want to launch the
- server process as the user <literal>root</literal> (or as
- any other user with unlimited permissions). Depending on
- the ownership and permissions of the repositories you're
- exporting, it's often prudent to use a
- different—perhaps custom—user. For example,
- many administrators create a new user named
- <literal>svn</literal>, grant that user exclusive ownership
- and rights to the exported Subversion repositories, and only
- run their server processes as that user.</para>
+ <para>第二点，当配制<command>svnserve</command>、Apache <command>httpd</command>或者其他任何服务器时，不要使用<literal>root</literal>用户（或者其他具备无限制权限的用户）启动服务器进程，依赖于所有权和版本库允许的权限，通常会创建一个新的用户叫做<literal>svn</literal>，赋予这个用户排他的拥有权和对Subversion版本库的导出权利，只让服务器以这个用户运行。</para>
</sidebar>
- <para>Once the <command>svnserve</command> program is running,
- it makes every repository on your system available to the
- network. A client needs to specify an
- <emphasis>absolute</emphasis> path in the repository URL. For
- example, if a repository is located at
- <filename>/usr/local/repositories/project1</filename>, then a
- client would reach it via <systemitem
+ <para>一旦<command>svnserve</command>已经运行，它会将你系统中所有版本库发布到网络，一个客户端需要指定版本库在URL中的<emphasis>绝对</emphasis>路径，举个例子，如果一个版本库是位于<filename>/usr/local/repositories/project1</filename>，则一个客户端可以使用<systemitem
class="url">svn://host.example.com/usr/local/repositories/project1
- </systemitem>. To increase security, you can pass the
- <option>-r</option> option to <command>svnserve</command>,
- which restricts it to exporting only repositories below that
- path:</para>
+ </systemitem>来进行访问，为了提高安全性，你可以使用<command>svnserve</command>的<option>-r</option>选项，这样会限制只输出指定路径下的版本库：</para>
<screen>
$ svnserve -d -r /usr/local/repositories
…
</screen>
- <para>Using the <option>-r</option> option effectively
- modifies the location that the program treats as the root of
- the remote filesystem space. Clients then use URLs that
- have that path portion removed from them, leaving much
- shorter (and much less revealing) URLs:</para>
+ <para>使用<option>-r</option>可以有效地改变文件系统的根位置，客户端可以使用去掉前部分的路径，留下的要短一些的（更加有提示性）URL：</para>
<screen>
$ svn checkout svn://host.example.com/project1
@@ -530,75 +313,40 @@
</sect2>
<sect2 id="svn-ch-6-sect-3.2">
- <title>Built-in authentication and authorization</title>
+ <title>内置的认证和授权</title>
- <para>When a client connects to an <command>svnserve</command>
- process, the following things happen:</para>
+ <para>如果一个客户端连接到<command>svnserve</command>进程，如下事情会发生：</para>
<itemizedlist>
- <listitem><para>The client selects a specific
- repository.</para></listitem>
+ <listitem><para>客户端选择特定的版本库。</para></listitem>
- <listitem><para>The server processes the repository's
- <filename>conf/svnserve.conf</filename> file, and begins to
- enforce any authentication and authorization policies defined
- therein.</para></listitem>
+ <listitem><para>服务器处理H本库的<filename>conf/svnserve.conf</filename>文件，并且执行里面定义的所有认证和授权信息。</para></listitem>
- <listitem><para>Depending on the situation and authorization
- policies,</para>
+ <listitem><para>依赖于位置和授权政策，</para>
<itemizedlist>
- <listitem><para>the client may be allowed to make requests
- anonymously, without ever receiving an authentication
- challenge, OR</para></listitem>
-
- <listitem><para>the client may be challenged for
- authentication at any time, OR</para></listitem>
-
- <listitem><para>if operating in <quote>tunnel
- mode</quote>, the client will declare itself to be
- already externally authenticated.</para></listitem>
+ <listitem><para>如果没有受到认证挑战，客户端可能被允许匿名访问，或者</para></listitem>
+
+ <listitem><para>客户端收到认证挑战，或者</para></listitem>
+
+ <listitem><para>如果操作在<quote>通道模式</quote>，客户端会宣布自己已经在外部得到认证。</para></listitem>
</itemizedlist>
</listitem>
</itemizedlist>
- <para>At the time of writing, the server only knows how to send
- a CRAM-MD5 <footnote><para>See RFC 2195.</para></footnote>
- authentication challenge. In essence, the server sends a bit
- of data to the client. The client uses the MD5 hash algorithm
- to create a fingerprint of the data and password combined,
- then sends the fingerprint as a response. The server performs
- the same computation with the stored password to verify that
- the result is identical. <emphasis>At no point does the
- actual password travel over the network.</emphasis></para>
-
- <para>It's also possible, of course, for the client to be
- externally authenticated via a tunnel agent, such as
- <command>SSH</command>. In that case, the server simply
- examines the user it's running as, and uses it as the
- authenticated username. For more on this, see <xref
- linkend="svn-ch-6-sect-3.4"/>.</para>
-
- <para>As you've already guessed, a repository's
- <filename>svnserve.conf</filename> file is the central
- mechanism for controlling authentication and authorization
- policies. The file has the same format as other configuration
- files (see <xref linkend="svn-ch-7-sect-1"/>): section names
- are marked by square brackets (<literal>[</literal> and
- <literal>]</literal>), comments begin with hashes
- (<literal>#</literal>), and each section contains
- specific variables that can be set (<literal>variable =
- value</literal>). Let's walk through this file and learn how
- to use them.</para>
+ <para>在撰写本文时，服务器还只知道怎样发送CRAM-MD5<footnote><para>见RFC 2195。</para></footnote>认证挑战，本质上讲，就是服务器发送一些数据到客户端，客户端使用MD5哈希算法创建这些数据组合密码的指纹，然后返回指纹，服务器执行同样的计算并且来计算结果的一致性，<emphasis>真正的密码并没有在互联网上传递。</emphasis></para>
+
+ <para>也有可能，当然，如果客户端在外部通过通道代理认证，如<command>SSH</command>，在那种情况下，服务器简单的检验作为那个用户的运行，然后使用它作为认证用户名，更多信息请看<xref
+ linkend="svn-ch-6-sect-3.4"/>。</para>
+
+ <para>像你已经猜测到的，版本库的<filename>svnserve.conf</filename>文件是控制认证和授权的中心机制，文件与其它的配置文件是同样的格式（见<xref linkend="svn-ch-7-sect-1"/>）：部分名称使用方括号标记（<literal>[</literal>和<literal>]</literal>），注释以井号（<literal>#</literal>）开始，每一部分都有一些参数可以设置（<literal>variable =
+ value</literal>），让我们浏览这个文件并且学习怎样使用他们。</para>
<sect3 id="svn-ch-6-sect-3.2.1">
- <title>Create a 'users' file and realm</title>
+ <title>创建一个用户文件和域</title>
- <para>For now, the <literal>[general]</literal> section of the
- <filename>svnserve.conf</filename> has all the variables you
- need. Begin by defining a file which contains usernames and
- passwords, and an authentication realm:</para>
+ <para>此时，<filename>svnserve.conf</filename>文件的<literal>[general]</literal>部分包括所有你需要的变量，开始先定义一个保存用户名和密码的文件和一个认证域：</para>
<screen>
[general]
@@ -606,16 +354,8 @@
realm = example realm
</screen>
- <para>The <literal>realm</literal> is a name that you define.
- It tells clients which sort of <quote>authentication
- namespace</quote> they're connecting to; the Subversion
- client displays it in the authentication prompt, and uses it
- as a key (along with the server's hostname and port) for
- caching credentials on disk (see <xref
- linkend="svn-ch-6-sect-2.2"/>.) The
- <literal>password-db</literal> variable points to a separate
- file that contains a list of usernames and passwords, using
- the same familiar format. For example:</para>
+ <para><literal>realm</literal>是你定义的名称，这告诉客户端连接的<quote>认证命名空间</quote>，Subversion会在认证提示里显示，并且作为凭证缓存（见<xref
+ linkend="svn-ch-6-sect-2.2"/>。）的关键字（还有服务器的主机名和端口），<literal>password-db</literal>参数指出了保存用户和密码列表文件，这个文件使用同样熟悉的格式，举个例子：</para>
<screen>
[users]
@@ -623,37 +363,14 @@
sally = barpassword
</screen>
- <para>The value of <literal>password-db</literal> can be an
- absolute or relative path to the users file. For many
- admins, it's easy to keep the file right in the
- <filename>conf/</filename> area of the repository, alongside
- <filename>svnserve.conf</filename>. On the other hand, it's
- possible you may want to have two or more repositories share
- the same users file; in that case, the file should probably
- live in a more public place. The repositories sharing the
- users file should also be configured to have the same realm,
- since the list of users essentially defines an
- authentication realm. Wherever the file lives, be sure to
- set the file's read and write permissions appropriately. If
- you know which user(s) <command>svnserve</command> will run
- as, restrict read access to the user file as necessary.</para>
+ <para><literal>password-db</literal>的值可以是用户文件的绝对或相对路径，对许多管理员来说，把文件保存在版本库<filename>conf/</filename>下的<filename>svnserve.conf</filename>旁边是一个简单的方法。另一方面，可能你的多个版本库使用同一个用户文件，此时，这个文件应该在更公开的地方，版本库分享用户文件时必须配置为相同的域，因为用户列表本质上定义了一个认证域，无论这个文件在哪里，必须设置好文件的读写权限，如果你知道运行<command>svnserve</command>的用户，限定这个用户对这个文件有读权限是必须的。</para>
</sect3>
<sect3 id="svn-ch-6-sect-3.2.2">
- <title>Set access controls</title>
+ <title>设置访问控制</title>
- <para>There are two more variables to set in the
- <filename>svnserve.conf</filename> file: they determine what
- unauthenticated (anonymous) and authenticated users are
- allowed to do. The variables <literal>anon-access</literal>
- and <literal>auth-access</literal> can be set to the values
- <literal>none</literal>, <literal>read</literal>, or
- <literal>write</literal>. Setting the value to
- <literal>none</literal> restricts all access of any kind;
- <literal>read</literal> allows read-only access to the
- repository, and <literal>write</literal> allows complete
- read/write access to the repository. For example:</para>
+ <para><filename>svnserve.conf</filename>有两个或多个参数需要设置：他们检验未认证（匿名）和认证用户可以做的事情，参数<literal>anon-access</literal>和<literal>auth-access</literal>可以设置为<literal>none</literal>、<literal>read</literal>或者<literal>write</literal>，设置为<literal>none</literal>会限制所有方式的访问，<literal>read</literal>允许只读访问，而<literal>write</literal>允许对版本库完全的读/写权限：</para>
<screen>
[general]
@@ -667,10 +384,7 @@
auth-access = write
</screen>
- <para>The example settings are, in fact, the default values of
- the variables, should you forget to define them. If you
- want to be even more conservative, you can block anonymous
- access completely:</para>
+ <para>实例设置是，实际上是参数的缺省值，你一定不要忘了设置他们，如果你希望更保守一点，你可以完全封锁匿名访问：</para>
<screen>
[general]
@@ -684,40 +398,17 @@
auth-access = write
</screen>
- <para>Notice that <command>svnserve</command> only understands
- <quote>blanket</quote> access control. A user either has
- universal read/write access, universal read access, or no
- access. There is no detailed control over access to
- specific paths within the repository. For many projects and
- sites, this level of access control is more than adequate.
- However, if you need per-directory access control, you'll
- need to use either use Apache with
- <command>mod_authz_svn</command> (see <xref
- linkend="svn-ch-6-sect-4.4.2"/>) or use a
- <command>pre-commit</command> hook script to control write
- access (see <xref linkend="svn-ch-5-sect-2.1"/>). The
- Subversion distribution comes with
- <command>commit-access-control.pl</command> and the more
- sophisticated <command>svnperms.py</command> scripts for use
- in pre-commit scripts.</para>
+ <para>注意<command>svnserve</command>只能识别<quote>blanket</quote>的访问控制，一个用户可以有全体的读/写权限，或者只读权限，或没有访问权限，没有对版本库具体路径访问的细节控制，很多项目和站点，这种 访问控制时完全足够了，然而，如果你希望单个目录访问控制，你会需要使用包括<command>mod_authz_svn</command>（见<xref linkend="svn-ch-5-sect-2.1"/>）的Apache，或者是使用<command>pre-commit</command>钩子脚本来控制写访问（见<xref linkend="svn-ch-5-sect-2.1"/>），Subversion的分发版本包含一个<command>commit-access-control.pl</command>和一个更加复杂的<command>svnperms.py</command>将本作为pre-commit脚本使用。</para>
</sect3>
</sect2>
<sect2 id="svn-ch-6-sect-3.4">
- <title>SSH authentication and authorization</title>
+ <title>SSH认证和授权</title>
+
+ <para><command>svnserve</command>的内置认证会非常容易得到，因为它避免了创建真实的系统帐号，另一方面，一些管理员已经创建好了SSH认证框架，在这种情况下，所有的项目用户已经拥有了系统帐号和有能力<quote>SSH到</quote>服务器。</para>
- <para><command>svnserve</command>'s built-in authentication can
- be very handy, because it avoids the need to create real
- system accounts. On the other hand, some administrators
- already have well-established SSH authentication frameworks in
- place. In these situations, all of the project's users
- already have system accounts and the ability to <quote>SSH
- into</quote> the server machine.</para>
-
- <para>It's easy to use SSH in conjunction with
- <command>svnserve</command>. The client simply uses the
- <literal>svn+ssh://</literal> URL schema to connect:</para>
+ <para>SSH与<command>svnserve</command>结合很简单，客户端只需要使用<literal>svn+ssh://</literal>的URL模式来连接：</para>
<screen>
$ whoami
@@ -732,137 +423,47 @@
…
</screen>
- <para>In this example, the Subversion client is invoking a local
- <command>ssh</command> process, connecting to
- <literal>host.example.com</literal>, authenticating as the
- user <literal>harry</literal>, then spawning a private
- <command>svnserve</command> process on the remote machine
- running as the user <literal>harry</literal>. The
- <command>svnserve</command> command is being invoked in tunnel
- mode (<option>-t</option>) and its network protocol is being
- <quote>tunneled</quote> over the encrypted connection by
- <command>ssh</command>, the tunnel-agent.
- <command>svnserve</command> is aware that it's running as the
- user <literal>harry</literal>, and if the client performs a
- commit, the authenticated username will be attributed as the
- author of the new revision.</para>
-
- <para>The important thing to understand here is that the
- Subversion client is <emphasis>not</emphasis> connecting to a
- running <command>svnserve</command> daemon. This method of
- access doesn't require a daemon, nor does it notice one if
- present. It relies wholly on the ability of
- <command>ssh</command> to spawn a temporary
- <command>svnserve</command> process, which then terminates
- when the network connection is closed.</para>
-
- <para>When using <literal>svn+ssh://</literal> URLs to access a
- repository, remember that it's the <command>ssh</command>
- program prompting for authentication, and
- <emphasis>not</emphasis> the <command>svn</command> client
- program. That means there's no automatic password caching
- going on (see <xref linkend="svn-ch-6-sect-2.2"/>). The
- Subversion client often makes multiple connections to the
- repository, though users don't normally notice this due to the
- password caching feature. When using
- <literal>svn+ssh://</literal> URLs, however, users may be
- annoyed by <command>ssh</command> repeatedly asking for a
- password for every outbound connection. The solution is to
- use a separate SSH password-caching tool like
- <command>ssh-agent</command> on a Unix-like system, or
- <command>pageant</command> on Windows.</para>
-
- <para>When running over a tunnel, authorization is primarily
- controlled by operating system permissions to the repository's
- database files; it's very much the same as if Harry were
- accessing the repository directly via a
- <literal>file:///</literal> URL. If multiple system users are
- going to be accessing the repository directly, you may want to
- place them into a common group, and you'll need to be careful
- about umasks. (Be sure to read <xref
- linkend="svn-ch-6-sect-5"/>.) But even in the case of
- tunneling, the <filename>svnserve.conf</filename> file can
- still be used to block access, by simply setting
- <literal>auth-access = read</literal> or <literal>auth-access
- = none</literal>.</para>
+ <para>在这个例子里，Subversion客户端会掉用一个<command>ssh</command>进程，连接到<literal>host.example.com</literal>，使用用户<literal>harry</literal>认证，然后会有一个<command>svnserve</command>私有进程以用户<literal>harry</literal>运行。<command>svnserve</command>是以管道模式调用的（<option>-t</option>），，它的网络协议是通过<command>ssh</command><quote>封装的</quote>，通道的代理<command>svnserve</command>会知道是以用户<literal>harry</literal>运行的，如果客户执行一个提交，认证的用户名会作为版本的参数保存到新的修订本。</para>
+
+ <para>这里要理解的最重要的事情是Subversion客户端<emphasis>不</emphasis>是连接到运行中的<command>svnserve</command>守护进程，这个访问方法不需要一个守护进程，也不会在需要时开放一个***，它依赖于<command>ssh</command>来发起一个<command>svnserve</command>进程，然后网络断开后终止进程。</para>
+
+ <para>当使用<literal>svn+ssh://</literal>的URL访问版本库时，记住是<command>ssh</command>提示请求认证，而<emphasis>不</emphasis>是<command>svn</command>客户端程序。这意味着密码不会有自动缓存（见<xref linkend="svn-ch-6-sect-2.2"/>），Subversion客户端通常会建立多个版本库的连接，但用户通常会因为密码缓存特性而没有注意到这一点，当使用<literal>svn+ssh://</literal>的URL时，用户会为<command>ssh</command>在每次建立连接时重复的询问密码感到讨厌，解决方案是用一个独立的SSH密码缓存工具，像类Unix系统的<command>ssh-agent</command>或者是Windows下的<command>pageant</command>。</para>
+
+ <para>党在一个管道上运行时，认证通常是基于操作系统对版本库数据库文件的访问控制，这同Harry直接通过<literal>file:///</literal>的URL直接访问版本库非常类似，如果有多个系统用户要直接访问版本库，你会希望将他们放到一个常见的组里，你应该小心的使用umasks。（确定要阅读<xref
+ linkend="svn-ch-6-sect-5"/>）但是如果是使用管道时，文件<filename>svnserve.conf</filename>还是可以阻止用户访问，如<literal>auth-access = read</literal>或者<literal>auth-access
+ = none</literal>。</para>
- <para>You'd think that the story of SSH tunneling would end
- here, but it doesn't. Subversion allows you to create custom
- tunnel behaviors in your run-time <filename>config</filename>
- file (see <xref linkend="svn-ch-7-sect-1"/>.) For example,
- suppose you want to use RSH instead of SSH. In the
- <literal>[tunnels]</literal> section of your
- <filename>config</filename> file, simply define it like
- this:</para>
+ <para>你会认为SSH管道的故事该结束了，但还不是，Subversion允许你在运行中文件<filename>config</filename>（见<xref linkend="svn-ch-7-sect-1"/>）创建一个自定义的管道行为方式，举个例子，假定你希望使用RSH而不是SSH，在<filename>config</filename>文件的<literal>[tunnels]</literal>部分如下定义：</para>
<screen>
[tunnels]
rsh = rsh
</screen>
- <para>And now, you can use this new tunnel definition by using a
- URL schema that matches the name of your new variable:
- <literal>svn+rsh://host/path</literal>. When using the new
- URL schema, the Subversion client will actually be running the
- command <command>rsh host svnserve -t</command> behind the
- scenes. If you include a username in the URL (for example,
- <literal>svn+rsh://username@host/path</literal>) the client
- will also include that in its command (<command>rsh
- username at host svnserve -t</command>.) But you can define new
- tunneling schemes to be much more clever than that:</para>
+ <para>现在你可以通过指定与定义匹配的URL模式来使用新的管道定义：<literal>svn+rsh://host/path</literal>。当使用新的URL模式时，Subversion客户端会实际上会在后面运行<command>rsh host svnserve -t</command>这个命令，如果你在URL中包括一个用户名（例如，<literal>svn+rsh://username@host/path</literal>），客户端也会在自己的命令中包含这部分（<command>rsh
+ username at host svnserve -t</command>），但是你可以定义比这个更加智能的新的管道模式：</para>
<screen>
[tunnels]
joessh = $JOESSH /opt/alternate/ssh -p 29934
</screen>
- <para>This example demonstrates a couple of things. First, it
- shows how to make the Subversion client launch a very specific
- tunneling binary (the one located at
- <filename>/opt/alternate/ssh</filename>) with specific
- options. In this case, accessing a
- <literal>svn+joessh://</literal> URL would invoke the
- particular SSH binary with <option>-p 29934</option> as
- arguments—useful if you want the tunnel program to
- connect to a non-standard port.</para>
-
- <para>Second, it shows how to define a custom environment
- variable that can override the name of the tunneling program.
- Setting the <literal>SVN_SSH</literal> environment variable is
- a convenient way to override the default SSH tunnel agent.
- But if you need to have several different overrides for
- different servers, each perhaps contacting a different port or
- passing a different set of options to SSH, you can use the
- mechanism demonstrated in this example. Now if we were to set
- the <literal>JOESSH</literal> environment variable, its value
- would override the entire value of the tunnel
- variable—<command>$JOESSH</command> would be executed
- instead of <command>/opt/alternate/ssh -p
- 29934</command>.</para>
+ <para>这个例子里论证了一些事情，首先，它展现了如何让Subversion客户端启动一个特定的管道程序（这个在<filename>/opt/alternate/ssh</filename>），在这个例子里，使用<literal>svn+joessh://</literal>的URL会以<option>-p 29934</option>参数调用特定的SSH程序—对连接到非标准端口的程序非常有用。</para>
+
+ <para>第二点，它展示了怎样定义一个自定义的环境变量来覆盖管道程序中的名字，设置<literal>SVN_SSH</literal>环境变量是覆盖缺省的SSH管道的一种简便方法，但是如果你需要为多个服务器做出多个不同的覆盖，每一个或许联系不同的端口或者传递不同的SSH选项集，你可以使用本例论述的机制。现在如果我们设置<literal>JOESSH</literal>环境变量，它的值会覆盖管道中的变量值—<command>$JOESSH</command>会执行而不是执行<command>/opt/alternate/ssh -p
+ 29934</command>。</para>
</sect2>
<sect2 id="svn-ch-6-sect-3.5">
- <title>SSH configuration tricks</title>
+ <title>SSH配置技巧</title>
- <para>It's not only possible to control the way in which the
- client invokes <command>ssh</command>, but also to control
- the behavior of <command>sshd</command> on your server
- machine. In this section, we'll show how to control the
- exact <command>svnserve</command> command executed
- by <command>sshd</command>, as well as how to have multiple
- users share a single system account.</para>
+ <para>不仅仅是可以控制客户端调用<command>ssh</command>方式，也可以控制服务器中的<command>sshd</command>的行为方式，在本小节，我们会展示怎样控制<command>sshd</command>执行<command>svnserve</command>，就像我们怎样让多给用户分享同一个系统帐户。</para>
<sect3 id="svn-ch-6-sect-3.5.1">
- <title>Initial setup</title>
+ <title>初始设置</title>
- <para>To begin, locate the home directory of the account
- you'll be using to launch <command>svnserve</command>. Make
- sure the account has an SSH public/private keypair
- installed, and that the user can log in via public-key
- authentication. Password authentication will not work,
- since all of the following SSH tricks revolve around using
- the SSH <filename>authorized_keys</filename> file.</para>
+ <para>作为开始，定位到你启动<command>svnserve</command>的帐号的主目录，确定这个账户有一个SSH公开/私有密钥对已经安装，用户可以通过公开密钥认证，因为所有如下的技巧关注于使用SSH<filename>授权密钥</filename>文件，密码认证不会工作。</para>
<para>If it doesn't already exist, create the
<filename>authorized_keys</filename> file (on Unix,
@@ -875,22 +476,13 @@
ssh-dsa AAAABtce9euch.... user at example.com
</screen>
- <para>The first field describes the type of key, the second
- field is the uuencoded key itself, and the third field is a
- comment. However, it's a lesser known fact that the entire
- line can be preceded by a <literal>command</literal>
- field:</para>
+ <para>第一个字段描述了密钥的类型，第二个字段时未加密的密钥本身，第三个字段是注释，然而，这是一个很少人知道的事实，可以使用一个<literal>command</literal>来处理整行：</para>
<screen>
command="program" ssh-dsa AAAABtce9euch.... user at example.com
</screen>
- <para>When the <literal>command</literal> field is set, the
- SSH daemon will run the named program instead of the
- typical <command>svnserve -t</command> invocation that the
- Subversion client asks for. This opens the door to a number
- of server-side tricks. In the following examples, we
- abbreviate the lines of the file as:</para>
+ <para>当<literal>command</literal>字段设置后，SSH守护进程运行命名的程序而不是通常Subversion客户端询问的<command>svnserve -t</command>。这样开启了许多服务器端的小技巧，在下面的例子里，我们会简写这个文件的这些行：</para>
<screen>
command="program" TYPE KEY COMMENT
@@ -899,61 +491,26 @@
</sect3>
<sect3 id="svn-ch-6-sect-3.5.2">
- <title>Controlling the invoked command</title>
+ <title>控制调用的命令</title>
- <para>Because we can specify the executed server-side command,
- it's easy to name a specific <command>svnserve</command>
- binary to run and to pass it extra arguments:</para>
+ <para>因为我们可以指定执行服务器端命令，我们很容易来命名一个<command>svnserve</command>程序来运行和传递给他额外的参数：</para>
<screen>
command="/path/to/svnserve -t -r /virtual/root" TYPE KEY COMMENT
</screen>
- <para>In this example, <filename>/path/to/svnserve</filename>
- might be a custom wrapper script
- around <command>svnserve</command> which sets the umask (see
- <xref linkend="svn-ch-6-sect-5"/>). It also shows how to
- anchor <command>svnserve</command> in a virtual root
- directory, just as one often does when
- running <command>svnserve</command> as a daemon process.
- This might be done either to restrict access to parts of the
- system, or simply to relieve the user of having to type an
- absolute path in the <literal>svn+ssh://</literal>
- URL.</para>
+ <para>在这个例子里，<filename>/path/to/svnserve</filename>也许会是一个<command>svnserve</command>程序的包裹脚本，会来设置umask（见<xref linkend="svn-ch-6-sect-5"/>）。它也展示了怎样在虚拟根目录定位一个<command>svnserve</command>，就像我们经常在使用守护进程模式下运行<command>svnserve</command>一样。这样也许会不仅限制了对系统的部分访问，也使用户不需要在<literal>svn+ssh://</literal>URL里输入绝对路径。</para>
- <para>It's also possible to have multiple users share a single
- account. Instead of creating a separate system account for
- each user, generate a public/private keypair for each
- person. Then place each public key into
- the <filename>authorized_users</filename> file, one per
- line, and use the <option>--tunnel-user</option>
- option:</para>
+ <para>多个用户也可以共享同一个帐号，作为为每个用户创建系统帐户的替代，我们创建一个公开/私有密钥对，然后在<filename>authorized_users</filename>文件里放置各自的公钥，一个用户一行，使用<option>--tunnel-user</option>选项：</para>
<screen>
command="svnserve -t --tunnel-user=harry" TYPE1 KEY1 harry at example.com
command="svnserve -t --tunnel-user=sally" TYPE2 KEY2 sally at example.com
</screen>
- <para>This example allows both Harry and Sally to connect to
- the same account via public-key authentication. Each of
- them has a custom command that will be executed;
- the <option>--tunnel-user</option> option
- tells <command>svnserve -t</command> to assume that the named
- argument is the authenticated user. Without
- <option>--tunnel-user</option>, it would appear as though
- all commits were coming from the one shared system
- account.</para>
-
- <para>A final word of caution: giving a user access to the
- server via public-key in a shared account might still allow
- other forms of SSH access, even if you've set the
- the <literal>command</literal> value
- in <filename>authorized_keys</filename>. For example, the
- user may still get shell access through SSH, or be able to
- perform X11 or general port-forwarding through your server.
- To give the user as little permission as possible, you may
- want to specify a number of restrictive options immediately
- after the <literal>command</literal>:</para>
+ <para>这个例子允许Harry和Sally通过公钥认证连接同一个的账户，每个人有自己的自定义命令将会执行。<option>--tunnel-user</option>选项告诉<command>svnserve -t</command>命令假定命名的参数是认证的用户，如果没有<option>--tunnel-user</option>，所有的提交会作为共享的系统帐户提交。</para>
+
+ <para>最后要小心：设定通过公钥共享账户进行用户访问时还会允许其它形式的SSH访问，即使你设置了<filename>authorized_keys</filename>的<literal>command</literal>值，举个例子，用户仍然可以通过SSH得到shell访问，或者是通过服务器执行X11或者是端口转移。为了给用户尽可能少的访问权限，你或许希望在<literal>command</literal>命令之后指定一些限制选项：</para>
<screen>
command="svnserve -t --tunnel-user=harry",no-port-forwarding,\
@@ -973,73 +530,23 @@
<!-- ================================================================= -->
<sect1 id="svn-ch-6-sect-4">
- <title>httpd, the Apache HTTP server</title>
+ <title>httpd，Apache的HTTP服务器</title>
- <para>The Apache HTTP Server is a <quote>heavy duty</quote>
- network server that Subversion can leverage. Via a custom
- module, <command>httpd</command> makes Subversion repositories
- available to clients via the WebDAV/DeltaV protocol, which is an
- extension to HTTP 1.1
- (see <systemitem class="url">http://www.webdav.org/</systemitem>
- for more information.) This protocol takes the ubiquitous HTTP
- protocol that is the core of the World Wide Web, and adds
- writing—specifically, versioned
- writing—capabilities. The result is a standardized,
- robust system that is conveniently packaged as part of the
- Apache 2.0 software, is supported by numerous operating systems
- and third-party products, and doesn't require network
- administrators to open up yet another custom port.
- <footnote>
- <para>They really hate doing that.</para>
- </footnote>
- While an Apache-Subversion server has more features than
- <command>svnserve</command>, it's also a bit more difficult
- to set up. With flexibility often comes more complexity.</para>
-
- <para>Much of the following discussion includes references to
- Apache configuration directives. While some examples are given
- of the use of these directives, describing them in full is
- outside the scope of this chapter. The Apache team maintains
- excellent documentation, publicly available on their website at
- <systemitem class="url">http://httpd.apache.org</systemitem>.
- For example, a general reference for the configuration
- directives is located at <systemitem class="url">
- http://httpd.apache.org/docs-2.0/mod/directives.html</systemitem>.</para>
-
- <para>Also, as you make changes to your Apache setup, it is likely
- that somewhere along the way a mistake will be made. If you are
- not already familiar with Apache's logging subsystem, you should
- become aware of it. In your <filename>httpd.conf</filename>
- file are directives that specify the on-disk locations of the
- access and error logs generated by Apache (the
- <literal>CustomLog</literal> and <literal>ErrorLog</literal>
- directives, respectively). Subversion's mod_dav_svn uses
- Apache's error logging interface as well. You can always browse
- the contents of those files for information that might reveal
- the source of a problem that is not clearly noticeable
- otherwise.</para>
+ <para>Apache的HTTP服务器是一个Subversion可以利用的<quote>重型</quote>网络服务器，通过一个自定义模块，<command>httpd</command>可以让Subversion版本库通过WebDAV/DeltaV协议在客户端前可见，WebDAV/DeltaV协议是HTTP 1.1的扩展（见<systemitem class="url">http://www.webdav.org/</systemitem>来查看详细信息）。这个协议利用了无处不在的HTTP协议是广域网的核心这一点，添加了写能力—更明确一点，版本化的写—能力。结果就是这样一个标准化的健壮的系统，作为Apache 2.0软件的一部分便利的打包，被许多操作系统和第三方产品支持，不需要网络管理员打开另一个自定义端口。 <footnote>
+ <para>他们讨厌这样做。</para>
+ </footnote>这样一个Apache-Subversion服务器具备了许多<command>svnserve</command>没有的特性，但是也有一点难于配置，灵活通常会带来复杂性。</para>
+
+ <para>下面的讨论包括了对Apache配置指示的引用，给了一些使用这些指示的例子，详细地描述不再本章的范围之内，Apache小组维护了完美的文档，公开存放在他们的站点<systemitem class="url">http://httpd.apache.org</systemitem>。例如，一个一般的配置参考位于<systemitem class="url">
+ http://httpd.apache.org/docs-2.0/mod/directives.html</systemitem>。</para>
+
+ <para>同样，当你修改你的Apache设置，很有可能会出现一些错误，如果你还不熟悉Apache的日志子系统，你一定需要认识到这一点。在你的文件<filename>httpd.conf</filename>里会指定Apache生成的访问和错误日志（<literal>CustomLog</literal>和<literal>ErrorLog</literal>指示，各自的）的磁盘位置。Subversion的mod_dav_svn使用Apache的错误日志接口，你可以浏览这个文件的内容查看信息来查找不一注意到的问题根源。</para>
<sidebar>
- <title>Why Apache 2?</title>
+ <title>为什么是Apache 2？</title>
- <para>If you're a system administrator, it's very likely that
- you're already running the Apache web server and have some
- prior experience with it. At the time of writing, Apache 1.3
- is by far the most popular version of Apache. The world has
- been somewhat slow to upgrade to the Apache 2.X series for
- various reasons: some people fear change, especially changing
- something as critical as a web server. Other people depend on
- plug-in modules that only work against the Apache 1.3 API, and
- are waiting for a 2.X port. Whatever the reason, many people
- begin to worry when they first discover that Subversion's
- Apache module is written specifically for the Apache 2 API.</para>
-
- <para>The proper response to this problem is: don't worry about
- it. It's easy to run Apache 1.3 and Apache 2 side-by-side;
- simply install them to separate places, and use Apache 2 as a
- dedicated Subversion server that runs on a port other than 80.
- Clients can access the repository by placing the port number
- into the URL:</para>
+ <para>如果你系统管理员，很有可能是你已经运行了Apache服务器，并且有一些高级经验。写本文的时候，Apache 1.3是Apache最流行的版本，这个世界因为许多原因而放缓升级到2.X系列：如人们害怕改变，如web服务器这种重要的变化，有些人需要一些在Apache 1.3 API下工作的插件模块，在等待2.X的版本。无论什么原因，许多人会在首次发现Subversion的Apache模块只是为Apache 2 API写的后开始担心。</para>
+
+ <para>对此问题的适当反应是：不需要担心，同时运行Apache 1.3和Apache 2非常简单，只需要安装到不同的位置，用Apache 2作为Subversion的专用服务器，并且不使用80端口，客户端可以访问版本库时在URL里指定端口：</para>
<screen>
$ svn checkout http://host.example.com:7382/repos/project
@@ -1049,71 +556,36 @@
<sect2 id="svn-ch-6-sect-4.1">
- <title>Prerequisites</title>
+ <title>必备条件</title>
- <para>To network your repository over HTTP, you basically need
- four components, available in two packages. You'll need
- Apache <command>httpd</command> 2.0, the
- <command>mod_dav</command> DAV module that comes with it,
- Subversion, and the <command>mod_dav_svn</command>
- filesystem provider module distributed with Subversion.
- Once you have all of those components, the process of
- networking your repository is as simple as:</para>
+ <para>为了让你的版本库使用HTTP网络，你可以基本上需要两个包里的四个部分。你需要Apache <command>httpd</command> 2.0和包括的<command>mod_dav</command> DAV模块，Subversion和与之一同分发的<command>mod_dav_svn</command>文件系统提供者模块，如果你有了这些组件，网络化你的版本库将非常简单，如：</para>
<itemizedlist>
<listitem>
- <para>getting httpd 2.0 up and running with the mod_dav
- module,</para>
+ <para>配置好httpd 2.0，并且使用mod_dav启动，</para>
</listitem>
<listitem>
- <para>installing the mod_dav_svn plugin to mod_dav, which
- uses Subversion's libraries to access the repository,
- and</para>
+ <para>为mod_dav安装mod_dav_svn插件，它会使用Subversion的库访问版本库，并且</para>
</listitem>
<listitem>
- <para>configuring your <filename>httpd.conf</filename>
- file to export (or expose) the repository.</para>
+ <para>配置你的<filename>httpd.conf</filename>来输出（或者说暴露）版本库。</para>
</listitem>
</itemizedlist>
- <para>You can accomplish the first two items either by
- compiling <command>httpd</command> and Subversion from
- source code, or by installing pre-built binary packages of
- them on your system. For the most up-to-date information on
- how to compile Subversion for use with the Apache HTTP Server,
- as well as how to compile and configure Apache itself for
- this purpose, see the <filename>INSTALL</filename> file in
- the top level of the Subversion source code tree.</para>
+ <para>你可以通过从源代码编译<command>httpd</command>和Subversion来完成前两个项目，也可以通过你的系统上的已经编译好的二进制包来安装。查看最新的编译为Apache HTTP服务器使用的Subversion的方法可以看Subversion源代码树根目录的<filename>INSTALL</filename>文件。</para>
</sect2>
<sect2 id="svn-ch-6-sect-4.2">
- <title>Basic Apache Configuration</title>
+ <title>基本的Apache配置</title>
- <para>Once you have all the necessary components installed on
- your system, all that remains is the configuration of Apache
- via its <filename>httpd.conf</filename> file. Instruct Apache
- to load the mod_dav_svn module using the
- <literal>LoadModule</literal> directive. This directive must
- precede any other Subversion-related configuration items. If
- your Apache was installed using the default layout, your
- <command>mod_dav_svn</command> module should have been
- installed in the <filename>modules</filename> subdirectory of
- the Apache install location (often
- <filename>/usr/local/apache2</filename>). The
- <literal>LoadModule</literal> directive has a simple syntax,
- mapping a named module to the location of a shared library on
- disk:</para>
+ <para>一旦你安装了必须的组件，剩下的工作就是在<filename>httpd.conf</filename>里配置Apache，使用<literal>LoadModule</literal>来加载mod_dav_svn模块，这个指示必须先与其它Subversion相关的其它配置出现，如果你的Apache使用缺省布局安装，你的<command>mod_dav_svn</command>模块一定在Apache安装目录（通常是在<filename>/usr/local/apache2</filename>）的<filename>modules</filename>子目录，<literal>LoadModule</literal>指示的语法很简单，影射一个名字到它的共享库的物理位置：</para>
<screen>
LoadModule dav_svn_module modules/mod_dav_svn.so
</screen>
- <para>Note that if <command>mod_dav</command> was compiled as a
- shared object (instead of statically linked directly to the
- <command>httpd</command> binary), you'll need a similar
- <literal>LoadModule</literal> statement for it, too. Be sure
- that it comes before the <command>mod_dav_svn</command> line:</para>
+ <para>注意，如果<command>mod_dav</command>是作为共享对象编译（而不是静态链接到<command>httpd</command>程序），你需要为它使用使用<literal>LoadModule</literal>语句，一定确定它在<command>mod_dav_svn</command>之前：</para>
<screen>
LoadModule dav_module modules/mod_dav.so
@@ -1121,24 +593,7 @@
</screen>
- <para>At a later location in your configuration file, you now
- need to tell Apache where you keep your Subversion repository
- (or repositories). The <literal>Location</literal> directive
- has an XML-like notation, starting with an opening tag, and
- ending with a closing tag, with various other configuration
- directives in the middle. The purpose of the
- <literal>Location</literal> directive is to instruct Apache to
- do something special when handling requests that are directed
- at a given URL or one of its children. In the case of
- Subversion, you want Apache to simply hand off support for
- URLs that point at versioned resources to the DAV layer. You
- can instruct Apache to delegate the handling of all URLs whose
- path portions (the part of the URL that follows the server's
- name and the optional port number) begin with
- <filename>/repos/</filename> to a DAV provider whose
- repository is located at
- <filename>/absolute/path/to/repository</filename> using the
- following <filename>httpd.conf</filename> syntax:</para>
+ <para>在你的配置文件后面的位置，你需要告诉Apache你在什么地方保存Subversion版本库（也许是多个），<literal>位置</literal>指示有一个很像XML的符号，开始于一个开始标签，以一个结束标签结束，配合中间许多的其它配置。<literal>Location</literal>指示的目的是告诉Apache在特定的URL以及子URL下需要特殊的处理，如果是为Subversion准备的，你希望可以通过告诉Apache特定URL是指向版本化的资源，从而把支持转交给DAV层，你可以告诉Apache代理所有路径部分（URL中服务器名称和端口之后的部分）以<filename>/repos/</filename>开头的URL，并且交由DAV服务提供者处理，DAV服务提供者的版本库位于<filename>/absolute/path/to/repository</filename>，使用如下的<filename>httpd.conf</filename>语法：</para>
<screen>
<Location /repos>
@@ -1147,19 +602,9 @@
</Location>
</screen>
- <para>If you plan to support multiple Subversion repositories
- that will reside in the same parent directory on your local
- disk, you can use an alternative directive, the
- <literal>SVNParentPath</literal> directive, to indicate that
- common parent directory. For example, if you know you will be
- creating multiple Subversion repositories in a directory
- <filename>/usr/local/svn</filename> that would be accessed via
- URLs like <systemitem
- class="url">http://my.server.com/svn/repos1</systemitem>,
- <systemitem
- class="url">http://my.server.com/svn/repos2</systemitem>, and
- so on, you could use the <filename>httpd.conf</filename>
- configuration syntax in the following example:</para>
+ <para>如果你计划支持多个具备相同父目录的Subversion版本库，你有另外的选择，<literal>SVNParentPath</literal>指示，来表示共同的父目录。举个例子，如果你知道你会在<filename>/usr/local/svn</filename>下创建多个Subversion版本库，并且通过类似<systemitem
+ class="url">http://my.server.com/svn/repos1</systemitem>，<systemitem
+ class="url">http://my.server.com/svn/repos2</systemitem>的URL访问，你可以用后面例子中的<filename>httpd.conf</filename>配置语法：</para>
<screen>
<Location /svn>
@@ -1170,89 +615,33 @@
</Location>
</screen>
- <para>Using the previous syntax, Apache will delegate the
- handling of all URLs whose path portions begin with
- <filename>/svn/</filename> to the Subversion DAV provider,
- which will then assume that any items in the directory
- specified by the <literal>SVNParentPath</literal> directive
- are actually Subversion repositories. This is a particularly
- convenient syntax in that, unlike the use of the
- <literal>SVNPath</literal> directive, you don't have to
- restart Apache in order to create and network new
- repositories.</para>
-
- <para>Be sure that when you define your new
- <literal>Location</literal>, it doesn't overlap with other
- exported Locations. For example, if your main
- <literal>DocumentRoot</literal> is <filename>/www</filename>,
- do not export a Subversion repository in <literal><Location
- /www/repos></literal>. If a request comes in for the URI
- <filename>/www/repos/foo.c</filename>, Apache won't know
- whether to look for a file <filename>repos/foo.c</filename> in
- the <literal>DocumentRoot</literal>, or whether to delegate
- <command>mod_dav_svn</command> to return
- <filename>foo.c</filename> from the Subversion
- repository.</para>
+ <para>使用前面的语法，Apache会代理所有URL路径部分为<filename>/svn/</filename>的请求道Subversion的DAV提供者，Subversion会认为<literal>SVNParentPath</literal>指定的目录下的所有项目是真实的Subversion版本库，这通常是一个便利的语法，不像是用<literal>SVNPath</literal>指示，我们在此不必为创建新的版本库而重启Apache。</para>
+
+ <para>请确定当你定义新的<literal>位置</literal>，不会与其他导出的位置重叠，例如你的主要<literal>DocumentRoot</literal>是<filename>/www</filename>，不要把Subversion版本库导出到<literal><Location
+ /www/repos></literal>,如果一个请求的URI是<filename>/www/repos/foo.c</filename>,Apache不知道是直接到<filename>repos/foo.c</filename>访问这个文件还是让<command>mod_dav_svn</command>代理返回<filename>foo.c</filename>到Subversion版本库。</para>
<sidebar>
- <title>Server Names and the COPY Request</title>
+ <title>服务器名称和拷贝请求Server Names and the COPY Request</title>
- <para>Subversion makes use of the <literal>COPY</literal>
- request type to perform server-side copies of files and
- directories. As part of the sanity checking done by the
- Apache modules, the source of the copy is expected to be
- located on the same machine as the destination of the copy.
- To satisfy this requirement, you might need to tell mod_dav
- the name you use as the hostname of your server. Generally,
- you can use the <literal>ServerName</literal> directive in
- <filename>httpd.conf</filename> to accomplish this.</para>
+ <para>Subversion利用<literal>COPY</literal>请求类型来执行服务器端的文件和目录拷贝，作为一个健全的Apache模块***，拷贝源和拷贝的目标通常坐落在同一个机器上，为了满足这个需求，你或许需要告诉mod_dav服务器主机的名称，通常你可以使用<filename>httpd.conf</filename>的<literal>ServerName</literal>指示来完成此目的。</para>
<screen>
ServerName svn.example.com
</screen>
- <para>If you are using Apache's virtual hosting support via
- the <literal>NameVirtualHost</literal> directive, you may
- need to use the <literal>ServerAlias</literal> directive to
- specify additional names that your server is known by.
- Again, refer to the Apache documentation for full
- details.</para>
+ <para>如果你通过<literal>NameVirtualHost</literal>指示使用Apache的虚拟主机，你或许需要<literal>ServerAlias</literal>指示来指定额外的名称，再说一次，查看Apache文档的来得到细节。</para>
</sidebar>
- <para>At this stage, you should strongly consider the question
- of permissions. If you've been running Apache for some time
- now as your regular web server, you probably already have a
- collection of content—web pages, scripts and such.
- These items have already been configured with a set of
- permissions that allows them to work with Apache, or more
- appropriately, that allows Apache to work with those files.
- Apache, when used as a Subversion server, will also need the
- correct permissions to read and write to your Subversion
- repository. (See <xref linkend="svn-ch-6-sidebar-1"/>.)</para>
-
- <para>You will need to determine a permission system setup that
- satisfies Subversion's requirements without messing up any
- previously existing web page or script installations. This
- might mean changing the permissions on your Subversion
- repository to match those in use by other things that Apache
- serves for you, or it could mean using the
- <literal>User</literal> and <literal>Group</literal>
- directives in <filename>httpd.conf</filename> to specify that
- Apache should run as the user and group that owns your
- Subversion repository. There is no single correct way to set
- up your permissions, and each administrator will have
- different reasons for doing things a certain way. Just be
- aware that permission-related problems are perhaps the most
- common oversight when configuring a Subversion repository for
- use with Apache.</para>
+ <para>在本阶段，你一定要考虑访问权限问题，如果你已经作为普通的web服务器运行过Apache，你一定有了一些内容—网页、脚本和其他。这些项目已经配置了许多在Apache下可以工作访问许可，或者更适当一点，允许Apache与这些文件一起工作。Apache当作为Subversion服务器运行时，同样需要正确的访问许可来读写你的Subversion版本库。（见<xref linkend="svn-ch-6-sidebar-1"/>。）</para>
+
+ <para>你会需要检验权限系统的设置满足Subversion的需求，同时不会把以前的页面和脚本搞乱。这或许意味着修改Subversion的访问许可来配合Apache服务器已经使用的工具，或者可能意味着需要使用<filename>httpd.conf</filename>的<literal>User</literal>和<literal>Group</literal>指示来指定Apache作为运行的用户和Subversion版本库的组。并不是只有一条正确的方式来设置许可，每个管理员都有不同的原因来以特定方式操作，只要意识到当使用Apache配置一个Subversion版本库时许可关联的问题通常会被疏忽。</para>
</sect2>
<sect2 id="svn-ch-6-sect-4.3">
- <title>Authentication Options</title>
+ <title>认证选项</title>
- <para>At this point, if you configured
- <filename>httpd.conf</filename> to contain something like</para>
+ <para>此时，如果你配置<filename>httpd.conf</filename>保存象下面的内容</para>
<screen>
<Location /svn>
@@ -1261,41 +650,24 @@
</Location>
</screen>
- <para>...then your repository is <quote>anonymously</quote>
- accessible to the world. Until you configure some
- authentication and authorization policies, the Subversion
- repositories you make available via the
- <literal>Location</literal> directive will be generally
- accessible to everyone. In other words,</para>
+ <para>这样你的版本库对全世界是可以<quote>匿名</quote>访问的，直到你配置了一些认证授权政策，你通过<literal>Location</literal>指示来使Subversion版本库可以被任何人访问，换句话说，</para>
<itemizedlist>
<listitem>
- <para>anyone can use their Subversion client to checkout a
- working copy of a repository URL (or any of its
- subdirectories),</para>
+ <para>任何人可以使用Subversion客户端来从版本库URL取出一个工作拷贝（或者是它的子目录），</para>
</listitem>
<listitem>
- <para>anyone can interactively browse the repository's
- latest revision simply by pointing their web browser to
- the repository URL, and</para>
+ <para>任何人可以在浏览器输入版本库URL交互浏览的方式来查看版本库的最新修订版本，并且</para>
</listitem>
<listitem>
- <para>anyone can commit to the repository.</para>
+ <para>任何人可以提交到版本库。</para>
</listitem>
</itemizedlist>
<sect3 id="svn-ch-6-sect-4.3.1">
- <title>Basic HTTP Authentication</title>
+ <title>基本HTTP认证</title>
- <para>The easiest way to authenticate a client is via the
- HTTP Basic authentication mechanism, which simply uses a
- username and password to verify that a user is who she says
- she is. Apache provides an <command>htpasswd</command>
- utility for managing the list of acceptable usernames and
- passwords, those to whom you wish to grant special access to
- your Subversion repository. Let's grant commit access to
- Sally and Harry. First, we need to add them to the password
- file.</para>
+ <para>最简单的客户端认证方式是通过HTTP基本认证机制，简单的使用用户名和密码来验证一个用户所自称的身份，Apache提供了一个<command>htpasswd</command>工具来管理可接受的用户名和密码，这些就是你希望赋予Subversion特别权限的用户，让我们给Sally和Harry赋予提交权限，首先，我们需要添加他们到密码文件。</para>
<screen>
$ ### First time: use -c to create the file
@@ -1311,24 +683,9 @@
$
</screen>
- <para>Next, you need to add some more
- <filename>httpd.conf</filename> directives inside your
- <literal>Location</literal> block to tell Apache what to do
- with your new password file. The
- <literal>AuthType</literal> directive specifies the type of
- authentication system to use. In this case, we want to
- specify the <literal>Basic</literal> authentication system.
- <literal>AuthName</literal> is an arbitrary name that you
- give for the authentication domain. Most browsers will
- display this name in the pop-up dialog box when the browser
- is querying the user for his name and password. Finally,
- use the <literal>AuthUserFile</literal> directive to specify
- the location of the password file you created using
- <command>htpasswd</command>.</para>
-
- <para>After adding these three directives, your
- <literal><Location></literal> block should look
- something like this:</para>
+ <para>下一步，你需要在<filename>httpd.conf</filename>的<literal>Location</literal>区里添加一些指示来告诉Apache如何来使用这些密码文件，<literal>AuthType</literal>指示指定系统使用的认证类型，这种情况下，我们需要指定<literal>Basic</literal>认证系统，<literal>AuthName</literal>是你提供给认证域一个任意名称，大多数浏览器会在向用户询问名称和密码的弹出窗口里显示这个名称，最终，使用<literal>AuthUserFile</literal>指示来指定使用<command>htpasswd</command>创建的密码文件的位置。</para>
+
+ <para>添加完这三个指示，你的<literal><Location></literal>区块一定像这个样子：</para>
<screen>
<Location /svn>
@@ -1340,18 +697,7 @@
</Location>
</screen>
- <para>This <literal><Location></literal> block is not
- yet complete, and will not do anything useful. It's merely
- telling Apache that whenever authorization is required,
- Apache should harvest a username and password from the
- Subversion client. What's missing here, however, are
- directives that tell Apache <emphasis>which</emphasis> sorts
- of client requests require authorization. Wherever
- authorization is required, Apache will demand
- authentication as well. The simplest thing to do is protect
- all requests. Adding <literal>Require valid-user</literal>
- tells Apache that all requests require an authenticated
- user:</para>
+ <para>这个<literal><Location></literal>区块还没有结束，还不能做任何有用的事情，它只是告诉Apache当需要授权时，要去向Subversion客户端索要用户名和密码。我们这里遗漏的，是一些告诉Apache<emphasis>什么样</emphasis>客户端需要授权的指示。哪里需要授权，Apache就会在哪里要求认证，最简单的方式是保护所有的请求，添加<literal>Require valid-user</literal>来告诉Apache任何请求需要认证的用户：</para>
<screen>
<Location /svn>
@@ -1364,78 +710,35 @@
</Location>
</screen>
- <para>Be sure to read the next section (<xref
- linkend="svn-ch-6-sect-4.4"/>) for more detail on the
- <literal>Require</literal> directive and other ways to set
- authorization policies.</para>
-
- <para>One word of warning: HTTP Basic Auth passwords pass in
- very nearly plain-text over the network, and thus are
- extremely insecure. If you're worried about password
- snooping, it may be best to use some sort of SSL encryption,
- so that clients authenticate via <literal>https://</literal>
- instead of <literal>http://</literal>; at a bare minimum,
- you can configure Apache to use a self-signed server
- certificate.
+ <para>一定要阅读后面的部分（<xref
+ linkend="svn-ch-6-sect-4.4"/>）来得到<literal>Require</literal>的细节，和授权政策的其他设置方法。</para>
+
+ <para>需要警惕：HTTP基本认证的密码几乎是用明文传输，但是非常不可靠的，如果你担心密码偷窥，最好是使用某种SSL加密，所以客户端认证使用<literal>https://</literal>而不是<literal>http://</literal>，为了方便，你可以配置Apache为自签名认证。
<footnote>
- <para>While self-signed server certificates are still
- vulnerable to a <quote>man in the middle</quote> attack,
- such an attack is still much more difficult for a casual
- observer to pull off, compared to sniffing unprotected
- passwords.</para>
+ <para>当使用自签名的服务器时仍会遭受<quote>中间人</quote>攻击，但是与偷取未保护的密码相比,这样的攻击对一个偶然的攻击者来说很难成功。</para>
</footnote>
- Consult Apache's documentation (and OpenSSL documentation)
- about how to do that.</para>
+ 参考Apache的文档（和OpenSSL文档）来查看怎样做。</para>
</sect3>
<sect3 id="svn-ch-6-sect-4.3.2">
- <title>SSL Certificate Management</title>
+ <title>SSL认证管理</title>
- <para>Businesses that need to expose their repositories for access
- outside the company firewall should be conscious of the
- possibility that unauthorized parties could be
- <quote>sniffing</quote> their network traffic. SSL makes
- that kind of unwanted attention less likely to result in
- sensitive data leaks.</para>
-
- <para>If a Subversion client is compiled to use OpenSSL, then
- it gains the ability to speak to an Apache server via
- <literal>https://</literal> URLs. The Neon library used by
- the Subversion client is not only able to verify server
- certificates, but can also supply client certificates when
- challenged. When the client and server have exchanged SSL
- certificates and successfully authenticated one another, all
- further communication is encrypted via a session key.</para>
-
- <para>It's beyond the scope of this book to describe how to
- generate client and server certificates, and how to
- configure Apache to use them. Many other books, including
- Apache's own documentation, describe this task. But what
- <emphasis>can</emphasis> be covered here is how to manage
- server and client certificates from an ordinary Subversion
- client.</para>
-
- <para>When speaking to Apache via <literal>https://</literal>,
- a Subversion client can receive two different types of
- information:</para>
+ <para>商业应用需要越过公司防火墙的版本库访问，防火墙需要小心的考虑非认证用户<quote>吸取</quote>他们的网络流量的情况，SSL可以那种形式的注意不会导致敏感数据泄露。</para>
+
+ <para>如果Subversion使用OpenSSL编译，它就会具备与Subversion服务器使用<literal>https://</literal>的URL通讯的能力，Subversion使用的Neon库不是仅仅可以用来提供客户端证书验证，也可以提供需要时提供客户端证书，如果客户端和服务器交换了SSL凭证并且成功地互相认证，所有剩下的交流都会通过一个会话关键字加密。</para>
+
+ <para>怎样产生客户端和服务器端证书以及怎样使用它们已经超出了本书的范围，许多书籍，包括Apache自己的文档，描述这个任务，现在我们<emphasis>可以</emphasis>覆盖的是普通的客户端怎样来管理服务器与客户端证书。</para>
+
+ <para>当通过<literal>https://</literal>与Apache通讯时，一个Subversion客户端可以接收两种类型的信息：</para>
<itemizedlist>
- <listitem><para>a server certificate</para></listitem>
- <listitem><para>a demand for a client certificate</para></listitem>
+ <listitem><para>一个服务器证书</para></listitem>
+ <listitem><para>一个客户端证书的要求</para></listitem>
</itemizedlist>
- <para>If the client receives a server certificate, it needs to
- verify that it trusts the certificate: is the server really
- who it claims to be? The OpenSSL library does this by
- examining the signer of the server certificate, or
- <firstterm>certifying authority</firstterm> (CA). If
- OpenSSL is unable to automatically trust the CA, or if some
- other problem occurs (such as an expired certificate or
- hostname mismatch), the Subversion command-line client will
- ask you whether you want to trust the server certificate
- anyway:</para>
+ <para>如果客户端接收了一个服务器证书，它需要去验证它是可以相信的：这个服务器是它自称的那一个吗？OpenSSL库会去检验服务器证书的签名人或者是<firstterm>核证机构</firstterm>（CA）。如果OpenSSL不可以自动取信任这个CA，或者是一些其他的问题（如证书过期或者是主机名不匹配），Subversion命令行客户端会询问你是否期望无论如何也要信任这个证书：</para>
<screen>
$ svn list https://host.example.com/repos/project
@@ -1452,46 +755,19 @@
(R)eject, accept (t)emporarily or accept (p)ermanently?
</screen>
- <para>This dialogue should look familiar; it's essentially the
- same question you've probably seen coming from your web
- browser (which is just another HTTP client like Subversion!).
- If you choose the (p)ermanent option, the server certificate
- will be cached in your private run-time
- <filename>auth/</filename> area in just the same way your
- username and password are cached (see <xref
- linkend="svn-ch-6-sect-2.2"/>.) If cached, Subversion will
- automatically remember to trust this certificate in future
- negotiations.</para>
-
- <para>Your run-time <filename>servers</filename> file also gives
- you the ability to make your Subversion client automatically
- trust specific CAs, either globally or on a per-host basis.
- Simply set the <literal>ssl-authority-files</literal>
- variable to a semicolon-separated list of PEM-encoded CA
- certificates:</para>
+ <para>这个对话看起来很熟悉，这是你会在web浏览器（另一种HTTP客户端，就像Subversion）经常看到的问题，如果你选择(p)ermanent选项，服务器证书会存放在你存放那个用户名和密码缓存（见<xref
+ linkend="svn-ch-6-sect-2.2"/>。）的私有运行域<filename>auth/</filename>中，缓存后，Subversion会自动记住在以后的交流中信任这个证书。</para>
+
+ <para>你的运行中<filename>servers</filename>文件也会给你能力使你可以让Subversion客户端自动信任特定的CA，包括全局的或是每主机为基础的，只需要设置<literal>ssl-authority-files</literal>为一组逗号隔开的PEM加密的CA证书列表：</para>
<screen>
[global]
ssl-authority-files = /path/to/CAcert1.pem;/path/to/CAcert2.pem
</screen>
- <para>Many OpenSSL installations also have a pre-defined set
- of <quote>default</quote> CAs that are nearly universally
- trusted. To make the Subversion client automatically trust
- these standard authorities, set the
- <literal>ssl-trust-default-ca</literal> variable to
- <literal>true</literal>.</para>
-
- <para>When talking to Apache, a Subversion client might also
- receive a challenge for a client certificate. Apache is
- asking the client to identify itself: is the client really
- who it says it is? If all goes correctly, the Subversion
- client sends back a private certificate signed by a CA that
- Apache trusts. A client certificate is usually stored on
- disk in encrypted format, protected by a local password.
- When Subversion receives this challenge, it will ask you for
- both a path to the certificate and the password which
- protects it:</para>
+ <para>许多OpenSSL安装包括一些预先定义好的可以普遍信任的<quote>缺省的</quote>CA，为了让Subversion客户端自动信任这些标准权威，设置<literal>ssl-trust-default-ca</literal>为<literal>true</literal>。</para>
+
+ <para>当与Apache，也就是Subversion客户端通话时也会收到一个客户端证书的要求，Apache是询问客户端来证明自己的身份：这个客户端是否是他所说的那一个？如果一切正常，Subversion客户端会发送回一个通过Apache信任的CA签名的私有证书，一个客户端证书通常会以加密方式存放在磁盘，使用本地密码保护，当Subversion收到这个要求，它会询问你证书的路径和保护用的密码：</para>
<screen>
$ svn list https://host.example.com/repos/project
@@ -1502,18 +778,9 @@
…
</screen>
- <para>Notice that the client certificate is a
- <quote>p12</quote> file. To use a client certificate with
- Subversion, it must be in PKCS#12 format, which is a
- portable standard. Most web browsers are already able to
- import and export certificates in that format. Another
- option is to use the OpenSSL command-line tools to convert
- existing certificates into PKCS#12.</para>
-
- <para>Again, the runtime <filename>servers</filename> file
- allows you to automate this challenge on a per-host basis.
- Either or both pieces of information can be described in
- runtime variables:</para>
+ <para>注意这个客户端证书是一个<quote>p12</quote>文件，为了让Subversion使用客户端证书它必须是运输标准的PKCS#12格式，大多数浏览器可以导入和导出这种格式的证书，另一个选择是用OpenSSL命令行工具来转化存在的证书为PKCS#12格式。</para>
+
+ <para>再次，运行中<filename>servers</filename>文件允许你自动为每个主机自动响应这种要求，单独或者两条信息可以用来描述运行参数：</para>
<screen>
[groups]
@@ -1524,15 +791,10 @@
ssl-client-cert-password = somepassword
</screen>
- <para>Once you've set the
- <literal>ssl-client-cert-file</literal> and
- <literal>ssl-client-cert-password</literal> variables, the
- Subversion client can automatically respond to a client
- certificate challenge without prompting you.
+ <para>一旦你设置了<literal>ssl-client-cert-file</literal>和
+ <literal>ssl-client-cert-password</literal>参数，Subversion客户端可以自动相应客户端证书要求而不会打扰你。
<footnote>
- <para>More security-conscious folk might not want to store
- the client certificate password in the runtime
- <filename>servers</filename> file.</para>
+ <para>更多有安全意识的人不会希望在运行中<filename>servers</filename>文件保存客户端证书密码。</para>
</footnote>
</para>
@@ -1541,30 +803,16 @@
</sect2>
<sect2 id="svn-ch-6-sect-4.4">
- <title>Authorization Options</title>
+ <title>授权选项</title>
- <para>At this point, you've configured authentication, but not
- authorization. Apache is able to challenge clients and
- confirm identities, but it has not been told how to allow or
- restrict access to the clients bearing those identities. This
- section describes two strategies for controlling access to
- your repositories.</para>
+ <para>此刻，你已经配置了认证，但是没有配置授权，Apache可以要求用户认证并且确定身份，但是并没有说明这个身份的怎样允许和限制，这个部分描述了两种控制访问版本库的策略。</para>
<sect3 id="svn-ch-6-sect-4.4.1">
- <title>Blanket Access Control</title>
+ <title>整体访问控制</title>
- <para>The simplest form of access control is to authorize
- certain users for either read-only access to a repository,
- or read/write access to a repository.</para>
-
- <para>You can restrict access on all repository operations by
- adding the <literal>Require valid-user</literal> directive
- to your <literal><Location></literal> block. Using
- our previous example, this would mean that only clients that
- claimed to be either <literal>harry</literal> or
- <literal>sally</literal>, and provided the correct
- password for their respective username, would be allowed to
- do anything with the Subversion repository:</para>
+ <para>最简单的访问控制形式是授权特定用户为只读版本库访问或者是读/写访问版本库。</para>
+
+ <para>你可以通过在<literal><Location></literal>区块添加<literal>Require valid-user</literal>指示来限制所有的版本库操作，使用我们前面的例子，这意味着只有客户端只可以是<literal>harry</literal>或者<literal>sally</literal>，而且他们必须提供正确的用户名对应密码，这样允许对Subversion版本库做任何事：</para>
<screen>
<Location /svn>
@@ -1581,34 +829,10 @@
</Location>
</screen>
- <para>Sometimes you don't need to run such a tight ship. For
- example, Subversion's own source code repository at
- <systemitem
- class="url">http://svn.collab.net/repos/svn</systemitem>
- allows anyone in the world to perform read-only repository
- tasks (like checking out working copies and browsing the
- repository with a web browser), but restricts all write
- operations to authenticated users. To do this type of
- selective restriction, you can use the
- <literal>Limit</literal> and <literal>LimitExcept</literal>
- configuration directives. Like the
- <literal>Location</literal> directive, these blocks have
- starting and ending tags, and you would nest them inside
- your <literal><Location></literal> block.</para>
+ <para>有时候，你不需要这样严密的运行这艘船，举个例子，Subversion自己在<systemitem
+ class="url">http://svn.collab.net/repos/svn</systemitem>的源代码允许全世界的人执行版本库的只读操作（就像检出我们的工作拷贝并且使用浏览器浏览版本库），但是限定只有认证用户可以执行写操作。为了执行特定的限制，你可以使用<literal>Limit</literal>和<literal>LimitExcept</literal>配置指示，就像<literal>Location</literal>指示，这个区块又开始和结束标签，你需要在<literal><Location></literal>中添加这个指示。</para>
- <para>The parameters present on the <literal>Limit</literal>
- and <literal>LimitExcept</literal> directives are HTTP
- request types that are affected by that block. For example,
- if you wanted to disallow all access to your repository
- except the currently supported read-only operations, you
- would use the <literal>LimitExcept</literal> directive,
- passing the <literal>GET</literal>,
- <literal>PROPFIND</literal>, <literal>OPTIONS</literal>, and
- <literal>REPORT</literal> request type parameters. Then the
- previously mentioned <literal>Require valid-user</literal>
- directive would be placed inside the
- <literal><LimitExcept></literal> block instead of just
- inside the <literal><Location></literal> block.</para>
+ <para>在<literal>Limit</literal>和<literal>LimitExcept</literal>中使用的参数是可以被这个区块影响的HTTP请求类型，举个例子，如果你希望禁止所有的版本库访问，只是保留当前支持的只读操作，你可以使用<literal>LimitExcept</literal>指示，并且使用<literal>GET</literal>，<literal>PROPFIND</literal>，<literal>OPTIONS</literal>和<literal>REPORT</literal>请求类型参数，然后前面提到过的<literal>Require valid-user</literal>指示将会在<literal><LimitExcept></literal>区块中而不是在<literal><Location></literal>区块。</para>
<screen>
<Location /svn>
@@ -1627,35 +851,18 @@
</Location>
</screen>
- <para>These are only a few simple examples. For more in-depth
- information about Apache access control and the
- <literal>Require</literal> directive, take a look at the
- <literal>Security</literal> section of the Apache
- documentation's tutorials collection at <systemitem
- class="url">http://httpd.apache.org/docs-2.0/misc/tutorials.html</systemitem>.</para>
+ <para>这里只是一些简单的例子，想看关于Apache访问控制<literal>Require</literal>指示的更深入信息，可以查看Apache文档中的教程集<systemitem
+ class="url">http://httpd.apache.org/docs-2.0/misc/tutorials.html</systemitem>中的<literal>Security</literal>部分。</para>
</sect3>
<sect3 id="svn-ch-6-sect-4.4.2">
- <title>Per-Directory Access Control</title>
+ <title>每目录访问控制</title>
+
+ <para>也可以使用Apache的httpd模块<command>mod_authz_svn</command>更加细致的设置访问权限，这个模块收集客户端欻递过来的不同不透明URL信息，询问<command>mod_dav_svn</command>来解码，然后根据在配置文件定义的访问政策来裁决请求。</para>
- <para>It's possible to set up finer-grained permissions using
- a second Apache httpd module,
- <command>mod_authz_svn</command>. This module grabs the
- various opaque URLs passing from client to server, asks
- <command>mod_dav_svn</command> to decode them, and then
- possibly vetoes requests based on access policies defined in
- a configuration file.</para>
-
- <para>If you've built Subversion from source code,
- <command>mod_authz_svn</command> is automatically built
- and installed alongside <command>mod_dav_svn</command>.
- Many binary distributions install it automatically as well.
- To verify that it's installed correctly, make sure it comes
- right after <command>mod_dav_svn</command>'s
- <literal>LoadModule</literal> directive in
- <filename>httpd.conf</filename>:</para>
+ <para>如果你从源代码创建Subversion，<command>mod_authz_svn</command>会自动附加到<command>mod_dav_svn</command>，许多二进制分发版本也会自动安装，为了验证它是安装正确，确定它是在<filename>httpd.conf</filename>的<literal>LoadModule</literal>指示中的<command>mod_dav_svn</command>后面：</para>
<screen>
LoadModule dav_module modules/mod_dav.so
@@ -1663,27 +870,14 @@
LoadModule authz_svn_module modules/mod_authz_svn.so
</screen>
- <para>To activate this module, you need to configure your
- <literal>Location</literal> block to use the
- <literal>AuthzSVNAccessFile</literal> directive, which
- specifies a file containing the permissions policy for paths
- within your repositories. (In a moment, we'll discuss the
- format of that file.)</para>
-
- <para>Apache is flexible, so you have the option to configure
- your block in one of three general patterns. To begin,
- choose one of these basic configuration patterns. (The
- examples below are very simple; look at Apache's own
- documentation for much more detail on Apache authentication
- and authorization options.)</para>
-
- <para>The simplest block is to allow open access to everyone.
- In this scenario, Apache never sends authentication
- challenges, so all users are treated as
- <quote>anonymous</quote>.</para>
+ <para>为了激活这个模块，你需要配置你的<literal>Location</literal>区块的<literal>AuthzSVNAccessFile</literal>指示，指定保存路径中的版本库访问政策的文件。（此刻，我们将会讨论这个文件的格式。）</para>
+
+ <para>Apache非常的灵活，你可以从三种模式里选择一种来配置你的区块，（下面的例子非常简单；见Apache自己的文档中的认证和授权选项来查看更多的细节。）</para>
+
+ <para>最简单的区块是允许任何人可以访问，在这个场景里，Apache决不会发送认证请求，，所有的用户作为<quote>匿名</quote>对待。</para>
<example id="svn-ch-6-sect-4.4.2-ex-1">
- <title>A sample configuration for anonymous access.</title>
+ <title>匿名访问的配置实例。</title>
<programlisting>
<Location /repos>
DAV svn
@@ -1695,12 +889,7 @@
</programlisting>
</example>
- <para>On the opposite end of the paranoia scale, you can
- configure your block to demand authentication from everyone.
- All clients must supply credentials to identify themselves.
- Your block unconditionally requires authentication via the
- <literal>Require valid-user</literal> directive, and defines
- a means to authenticate.</para>
+ <para>在另一个极端，你可以配置为拒绝所有人的认证，所有客户端必须提供证明自己身份的证书，你通过<literal>Require valid-user</literal>指示来阻止无条件的认证，并且定义一种认证的手段。</para>
<example id="svn-ch-6-sect-4.4.2-ex-2">
<title>A sample configuration for authenticated access.</title>
@@ -1723,21 +912,10 @@
</programlisting>
</example>
- <para>A third very popular pattern is to allow a combination
- of authenticated and anonymous access. For example, many
- administrators want to allow anonymous users to read certain
- repository directories, but want only authenticated users to
- read (or write) more sensitive areas. In this setup, all
- users start out accessing the repository anonymously. If
- your access control policy demands a real username at any
- point, Apache will demand authentication from the client.
- To do this, you use both the <literal>Satisfy Any</literal>
- and <literal>Require valid-user</literal> directives
- together.</para>
+ <para>第三种流行的模式是允许认证和匿名用户的组合，举个例子，许多管理员希望允许匿名用户读取特定的版本库路径，但希望只有认证用户可以读（或者写）更多敏感的区域，在这个设置里，所有的用户开始时用匿名用户访问版本库，如果你的访问控制策略在任何时候要求一个真实的用户名，Apache将会要求从客户端认证，为此，你可以一起使用<literal>Satisfy Any</literal>和<literal>Require valid-user</literal>指示。</para>
<example id="svn-ch-6-sect-4.4.2-ex-3">
- <title>A sample configuration for mixed
- authenticated/anonymous access.</title>
+ <title>一个混合认证/匿名访问的配置实例。</title>
<programlisting>
<Location /repos>
DAV svn
@@ -1759,34 +937,11 @@
</programlisting>
</example>
- <para>Once your basic <literal>Location</literal> block is
- configured, you can create an access file and define some
- authorization rules in it.</para>
-
- <para>The syntax of the access file is the same familiar one
- used by <command>svnserve.conf</command> and the runtime
- configuration files. Lines that start with a hash
- (<literal>#</literal>) are ignored. In its simplest form,
- each section names a repository and path within it, and the
- authenticated usernames are the option names within each
- section. The value of each option describes the user's
- level of access to the repository path: either
- <literal>r</literal> (read-only) or <literal>rw</literal>
- (read-write). If the user is not mentioned at all, no
- access is allowed.</para>
-
- <para>To be more specific: the value of the section-names are
- either of the form <literal>[repos-name:path]</literal> or
- the form <literal>[path]</literal>. If you're using the
- <literal>SVNParentPath</literal> directive, then it's
- important to specify the repository names in your sections.
- If you omit them, then a section like
- <literal>[/some/dir]</literal> will match the path
- <filename>/some/dir</filename> in <emphasis>every</emphasis>
- repository. If you're using the <literal>SVNPath</literal>
- directive, however, then it's fine to only define paths in
- your sections—after all, there's only one
- repository.</para>
+ <para>一旦你的基本<literal>Location</literal>区块已经配制了，你可以创建一个定义一些授权规则的访问文件。</para>
+
+ <para>访问文件的语法与<command>svnserve.conf</command>和运行中配置文件非常相似，以（<literal>#</literal>）开头的行会被忽略，在它的简单形式里，每一部分命名一个版本库和一个里面的路径，认证用户名是在每个部分可选择的名字。每个选项的值描述了用户的访问版本库的级别：<literal>r</literal>（只读）或者<literal>rw</literal>（读写），如果用户没有提到，访问是不允许的。</para>
+
+ <para>详细一点：这个部分名称是<literal>[repos-name:path]</literal>或者<literal>[path]</literal>的形式，如果你使用<literal>SVNParentPath</literal>指示，指定版本库的名字是很重要的，如果你漏掉了他们，<literal>[/some/dir]</literal>部分就会与<filename>/some/dir</filename>的所有版本库匹配，如果你使用<literal>SVNPath</literal>指示，然而，在你的部分只是定义路径—毕竟，只有一个版本库。</para>
<screen>
[calc:/branches/calc/bug-142]
@@ -1794,17 +949,9 @@
sally = r
</screen>
- <para>In this first example, the user <literal>harry</literal> has
- full read and write access on the
- <filename>/branches/calc/bug-142</filename> directory in the
- <literal>calc</literal> repository, but the user
- <literal>sally</literal> has read-only access. Any other
- users are blocked from accessing this directory.</para>
-
- <para>Of course, permissions are inherited from
- parent to child directory. That means that we can specify a
- subdirectory with a different access policy for
- Sally:</para>
+ <para>在第一个例子里，用户<literal>harry</literal>对<literal>calc</literal>版本库中<filename>/branches/calc/bug-142</filename>具备完全的读写权利，但是用户<literal>sally</literal>只有读权利，任何其他用户禁止访问这个目录。</para>
+
+ <para>当然，访问控制是父目录传递给子目录的，这意味着我们可以为Sally指定一个子目录的不同访问策略：</para>
<screen>
[calc:/branches/calc/bug-142]
@@ -1816,14 +963,9 @@
sally = rw
</screen>
- <para>Now Sally can write to the <filename>testing</filename>
- subdirectory of the branch, but can still only read other
- parts. Harry, meanwhile, continues to have complete
- read-write access to the whole branch.</para>
-
- <para>It's also possible to explicitly deny permission to
- someone via inheritance rules, by setting the username
- variable to nothing:</para>
+ <para>现在Sally可以读取<filename>testing</filename>子目录或者叫做分支，但对其他部分还是只可以读，同时，Harry对整个分支还继续有完全的读写权限。</para>
+
+ <para>也可以通过显式的拒绝继承规则来拒绝某人的访问，只需要设置用户名参数为空：</para>
<screen>
[calc:/branches/calc/bug-142]
@@ -1834,54 +976,22 @@
harry =
</screen>
- <para>In this example, Harry has read-write access to the
- entire <filename>bug-142</filename> tree, but has absolutely no
- access at all to the <filename>secret</filename>
- subdirectory within it.</para>
-
- <para>The thing to remember is that the most specific path
- always matches first. The <command>mod_authz_svn</command>
- module tries to match the path itself, and then the parent
- of the path, then the parent of that, and so on. The net
- effect is that mentioning a specific path in the accessfile
- will always override any permissions inherited from parent
- directories.</para>
-
- <para>By default, nobody has any access to the repository at
- all. That means that if you're starting with an empty file,
- you'll probably want to give at least read permission to all
- users at the root of the repository. You can do this by
- using the asterisk variable (<literal>*</literal>), which
- means <quote>all users</quote>:</para>
+ <para>在这个例子里，Harry对<filename>bug-142</filename>目录树有完全的读写权限，但是对<filename>secret</filename>子目录没有任何访问权利。</para>
+
+ <para>有一件事需要记住的是需要找到最匹配的目录，<command>mod_authz_svn</command>模块首先找到匹配自己的目录，然后父目录，然后父目录的父目录，就这样继续下去，更具体的路径控制会覆盖所有继承下来的访问控制。</para>
+
+ <para>缺省情况下，没有人对版本库任何访问，这意味着如果你已经从一个空文件开始，你会希望给所有用户对版本库根目录具备读权限，你可以使用<literal>*</literal>实现，用来代表<quote>所有用户</quote>：</para>
<screen>
[/]
* = r
</screen>
- <para>This is a common setup; notice that there's no
- repository name mentioned in the section name. This makes
- all repositories world readable to all users, whether you're
- using <literal>SVNPath</literal> or
- <literal>SVNParentPath</literal>. Once all users have
- read-access to the repositories, you can give explicit
- <literal>rw</literal> permission to certain users on specific
- subdirectories within specific repositories.</para>
-
- <para>The asterisk variable (<literal>*</literal>) is also
- worth special mention here: it's the
- <emphasis>only</emphasis> pattern which matches an anonymous
- user. If you've configured your <literal>Location</literal>
- block to allow a mixture of anonymous and authenticated
- access, all users start out accessing Apache anonymously.
- <command>mod_authz_svn</command> looks for a
- <literal>*</literal> value defined for the path being
- accessed; if it can't find one, then Apache demands real
- authentication from the client.</para>
-
- <para>The access file also allows you to define whole groups
- of users, much like the Unix <filename>/etc/group</filename>
- file:</para>
+ <para>这是一个普通的设置；注意在小节名中没有提到版本库名称，这让版本库对所有的用户可读，不管你是使用<literal>SVNPath</literal>或是<literal>SVNParentPath</literal>。当所有用户对版本库有了读权利，你可以赋予特定用户对特定子目录的<literal>rw</literal>权限。</para>
+
+ <para>星号（<literal>*</literal>）参数需要在这里详细强调：这是匹配匿名用户的<emphasis>唯一</emphasis>模式，如果你已经配置了你的<literal>Location</literal>区块允许匿名和认证用户的混合访问，所有用户作为Apache匿名用户开始访问，<command>mod_authz_svn</command>会查找定义要访问的路径的<literal>*</literal>值；如果可以发现一个，Apache可以要求真实的客户端认证。</para>
+
+ <para>访问文件也允许你定义一组的用户，很像Unix的<filename>/etc/group</filename>文件：</para>
<screen>
[groups]
@@ -1890,9 +1000,7 @@
everyone = harry, sally, joe, frank, sally, jane
</screen>
- <para>Groups can be granted access control just like users.
- Distinguish them with an <quote>at</quote> (<literal>@</literal>)
- prefix:</para>
+ <para>组可以赋予组像用户一样的访问权限，使用<quote>at</quote>（<literal>@</literal>）前缀来加以区别：</para>
<screen>
[calc:/projects/calc]
@@ -1903,55 +1011,20 @@
jane = r
</screen>
- <para>...and that's pretty much all there is to it.</para>
+ <para>...并且会有很多相似的内容。***</para>
</sect3>
<sect3 id="svn-ch-6-sect-4.4.3">
- <title>Disabling Path-based Checks</title>
+ <title>关闭路径为基础的检查</title>
+
+ <para><command>mod_dav_svn</command>模块做了许多工作来确定你标记为“不可读”的数据不会因意外而泄露，这意味着需要紧密监控通过<command>svn
+ checkout</command>或是<command>svn update</command>返回的路径和文件内容，如果这些命令遇到一些根据认证策略不是可读的路径，这个路径通常会被一起忽略，在历史或者重命名操作时—例如运行一个类似<command>svn cat -r OLD foo.c</command>的命令来操作一个很久以前改过名字的文件 — 如果一个对象的以前的名字检测到是只读的，重命令追踪会简单的终止这个操作。</para>
- <para>The <command>mod_dav_svn</command> module goes through a
- lot of work to make sure that data you've marked
- "unreadable" doesn't get accidentally leaked. This means
- that it needs to closely monitor all of the paths and
- file-contents returned by commands like <command>svn
- checkout</command> or <command>svn update</command>
- commands. If these commands encounter a path that isn't
- readable according to some authorization policy, then the
- path is typically omitted altogether. In the case of
- history or rename tracing — e.g. running a command
- like <command>svn cat -r OLD foo.c</command> on a file that
- was renamed long ago — the rename tracking will simply
- halt if one of the object's former names is determined to be
- read-restricted.</para>
-
- <para>All of this path-checking can sometimes be quite
- expensive, especially in the case of <command>svn
- log</command>. When retrieving a list revisions, the server
- looks at every changed path in each revision and checks it
- for readability. If an unreadable path is discovered, then
- it's omitted from the list of the revision's changed paths
- (normally seen with the <option>--verbose</option> option),
- and the whole log message is suppressed. Needless to say,
- this can be time-consuming on revisions that affect a large
- number of files. This is the cost of security: even if you
- haven't configured a module like
- <command>mod_authz_svn</command> at all, the
- <command>mod_dav_svn</command> module is still asking Apache
- <command>httpd</command> to run authorization checks on
- every path. The <command>mod_dav_svn</command> module has
- no idea what authorization modules have been installed, so
- all it can do is ask Apache to invoke whatever might be
- present.</para>
-
- <para>On the other hand, there's also an escape-hatch of
- sorts, one which allows you to trade security features for
- speed. If you're not enforcing any sort of per-directory
- authorization (i.e. not using
- <command>mod_authz_svn</command> or similar module), then
- you can disable all of this path-checking. In your
- <filename>httpd.conf</filename> file, use the
- <literal>SVNPathAuthz</literal> directive:</para>
+ <para>路径检查在有时会非常昂贵，特别是<command>svn
+ log</command>的情况。当检索一列修订版本时，服务器会查看所有修订版本修改的路径，并且检查可读性，如果发现了一个不可读路径，它会从修订版本的修改路径中忽略（可以查看<option>--verbose</option>选项），并且整个的日志信息会被禁止，不必说这必定影响大量文件的修订版本会是一个非常耗时的操作。这是安全的代价：即使你并没有配置<command>mod_authz_svn</command>模块，<command>mod_dav_svn</command>还是会询问<command>httpd</command>来对所有路径运行认证检查，<command>mod_dav_svn</command>模块没有办法知道那个认证模块被安装，所以只有询问Apache来调用所提供的模块。</para>
+
+ <para>在另一方面，也有一个安全舱门允许你用安全特性来交换速度，如果你不是要求任何一种每目录的认证（如不使用 <command>mod_authz_svn</command>和类似的模块），你就可以关闭所有的路径检查，在你的<filename>httpd.conf</filename>文件，使用<literal>SVNPathAuthz</literal>指示：</para>
<example id="svn-ch-6-sect-4.4.3-ex-1">
<title>Disabling path checks altogether</title>
@@ -1965,60 +1038,25 @@
</programlisting>
</example>
- <para>The <literal>SVNPathAuthz</literal> directive is "on" by
- default. When set "off", all path-based authorization
- checking is disabled; <command>mod_dav_svn</command> stops
- invoking authorization checks on every path it
- discovers.</para>
+ <para><literal>SVNPathAuthz</literal>指示缺省是打开的，当设置为“off”时，所有的路径为基础的授权都会关闭；<command>mod_dav_svn</command>停止对每个目录调用授权检查。</para>
</sect3>
</sect2>
<sect2 id="svn-ch-6-sect-4.5">
- <title>Extra Goodies</title>
+ <title>额外的糖果</title>
- <para>We've covered most of the authentication and authorization
- options for Apache and mod_dav_svn. But there are a few other
- nice features that Apache provides.</para>
+ <para>我们已经覆盖了关于认证和授权的Apache和mod_dav_svn的大多数选项，但是Apache还提供了许多很好的特性。</para>
<sect3 id="svn-ch-6-sect-4.5.1">
- <title>Repository Browsing</title>
+ <title>版本库浏览</title>
- <para>One of the most useful benefits of an Apache/WebDAV
- configuration for your Subversion repository is that the
- youngest revisions of your versioned files and directories
- are immediately available for viewing via a regular web
- browser. Since Subversion uses URLs to identify versioned
- resources, those URLs used for HTTP-based repository access
- can be typed directly into a Web browser. Your browser will
- issue a <literal>GET</literal> request for that URL, and
- based on whether that URL represents a versioned directory
- or file, mod_dav_svn will respond with a directory listing
- or with file contents.</para>
-
- <para>Since the URLs do not contain any information about
- which version of the resource you wish to see, mod_dav_svn
- will always answer with the youngest version. This
- functionality has the wonderful side-effect that you can
- pass around Subversion URLs to your peers as references to
- documents, and those URLs will always point at the latest
- manifestation of that document. Of course, you can even use
- the URLs as hyperlinks from other web sites, too.</para>
-
- <para>You generally will get more use out of URLs to versioned
- files—after all, that's where the interesting content
- tends to lie. But you might have occasion to browse a
- Subversion directory listing, where you'll quickly note that
- the generated HTML used to display that listing is very
- basic, and certainly not intended to be aesthetically
- pleasing (or even interesting). To enable customization of
- these directory displays, Subversion provides an XML index
- feature. A single <literal>SVNIndexXSLT</literal> directive
- in your repository's <literal>Location</literal> block of
- <filename>httpd.conf</filename> will instruct mod_dav_svn to
- generate XML output when displaying a directory listing, and
- to reference the XSLT stylesheet of your choice:</para>
+ <para>一个非常有用的好处是使用Apache/WebDAV配置Subversion版本库时可以用普通的浏览器察看最新的版本库文件，因为Subversion使用URL来鉴别版本库版本化的资源，版本库使用的HTTP为基础的URL也可以直接输入到Web浏览器中，你的浏览器会发送一个<literal>GET</literal>请求到URL，根据访问的URL是指向一个版本化的目录还是文件，mod_dav_svn会负责列出目录列表或者是文件内容。</para>
+
+ <para>因为URL不能确定你所希望看到的资源的版本，mod_dav_svn会一直返回最新的版本，这样会有一些美妙的副作用，你可以直接把Subversion的URL传递给文档作为引用，这些URL会一直指向文档最新的材料，当然，你也可以在别的网站作为超链使用这些URL。</para>
+
+ <para>你通常会在版本化的文件的URL之外得到更多地用处—毕竟那里是有兴趣的内容存在的地方***，但是你会偶尔浏览一个Subversion的目录列表，你会很快发现展示列表生成的HTML非常基本，并且一定是没有想法为了让人高兴（或者是为了引起注意）而去美化，为了自定义这些目录显示，Subversion提供了一个XML目录特性，一个单独的<literal>SVNIndexXSLT</literal>指示在你的<filename>httpd.conf</filename>文件版本库的<literal>Location</literal>块里，它将会指导mod_dav_svn在显示目录列表的时候生成XML输出，并且引用你选择的XSLT样式表文件：</para>
<screen>
<Location /svn>
@@ -2029,95 +1067,33 @@
</Location>
</screen>
- <para>Using the <literal>SVNIndexXSLT</literal> directive and
- a creative XSLT stylesheet, you can make your directory
- listings match the color schemes and imagery used in other
- parts of your website. Or, if you'd prefer, you can use the
- sample stylesheets provided in the Subversion source
- distribution's <filename>tools/xslt/</filename> directory.
- Keep in mind that the path provided to the
- <literal>SVNIndexXSLT</literal> directory is actually a URL
- path—browsers need to be able to read your stylesheets
- in order to make use of them!</para>
+ <para>使用<literal>SVNIndexXSLT</literal>指示和创建一个XSLT样式表，你可以让你的目录列表的颜色模式与你的网站的其它部分匹配，否则，如果你愿意，你可以使用Subversion源分发版本中的<filename>tools/xslt/</filename>目录下的样例样式表。记住提供给<literal>SVNIndexXSLT</literal> 指示的路径是一个URL路径—浏览器需要可以按顺序阅读你的样式表来利用它们！</para>
<sidebar>
- <title>Can I view older revisions?</title>
+ <title>我可以看到老的修订版本吗？</title>
- <para>With an ordinary web browser? In one word: nope. At
- least, not with <command>mod_dav_svn</command> as your
- only tool.</para>
-
- <para>Your web browser only speaks ordinary HTTP. That
- means it only knows how to GET public URLs, which
- represent the latest versions of files and directories.
- According to the WebDAV/DeltaV spec, each server defines a
- private URL syntax for older versions of resources, and
- that syntax is opaque to clients. To find an older
- version of a file, a client must follow a specific
- procedure to <quote>discover</quote> the proper URL; the
- procedure involves issuing a series of WebDAV PROPFIND
- requests and understanding DeltaV concepts. This is
- something your web browser simply can't do.</para>
-
- <para>So to answer the question, one obvious way to see
- older revisions of files and directories is by passing the
- <option>--revision</option> argument to the <command>svn
- list</command> and <command>svn cat</command> commands.
- To browse old revisions with your web browser, however,
- you can use third-party software. A good example of this
- is ViewCVS (<systemitem
- class="url">http://viewcvs.sourceforge.net/</systemitem>).
- ViewCVS was originally written to display CVS repositories
- through the web, and the latest bleeding-edge versions (at
- the time of writing) are able to understand Subversion
- repositories as well.</para>
+ <para>通过一个普通的浏览器？一句话：不可以，至少是当你只使用<command>mod_dav_svn</command>作为唯一的工具时。</para>
+
+ <para>你的Web浏览器只会说普通的HTTP，也就是说它只会GET公共的URL，这个URL代表了最新版本的文件和目录，根据WebDAV/DeltaV规范，每种服务器定义了一种私有的URL语法来代表老的资源的版本，这个语法对客户端是不透明的，为了得到老的版本，一个客户端必须通过一种规范过程来<quote>发现</quote>正确的URL；这个过程包括执行一系列WebDAV PROPFIND请求俄和明白DeltaV概念，这些事情一般是你的web浏览器做不了的。</para>
+
+ <para>为了回答这些问题，一个明显的看老版本文件和目录的方式是带<option>--revision</option>参数的<command>svn
+ list</command>和<command>svn cat</command>命令，为了在浏览器里察看老版本，你可以使用第三方的软件，一个好的例子是ViewCVS（<systemitem
+ class="url">http://viewcvs.sourceforge.net/</systemitem>），ViewCVS最初写出来是为了在web显示CVS版本库，最新的带血的（此时正在编写）版本也已经可以理解Subversion版本库了。</para>
</sidebar>
</sect3>
<sect3 id="svn-ch-6-sect-4.5.2">
- <title>Other Features</title>
+ <title>其它特性</title>
- <para>Several of the features already provided by Apache in
- its role as a robust Web server can be leveraged for
- increased functionality or security in Subversion as well.
- Subversion communicates with Apache using Neon, which is a
- generic HTTP/WebDAV library with support for such mechanisms
- as SSL (the Secure Socket Layer, discussed earlier) and
- Deflate compression (the same algorithm used by the
- <command>gzip</command> and <command>PKZIP</command>
- programs to <quote>shrink</quote> files into smaller chunks
- of data). You need only to compile support for the features
- you desire into Subversion and Apache, and properly
- configure the programs to use those features.</para>
-
- <para>Deflate compression places a small burden on the client
- and server to compress and decompress network transmissions
- as a way to minimize the size of the actual transmission.
- In cases where network bandwidth is in short supply, this
- kind of compression can greatly increase the speed at which
- communications between server and client can be sent. In
- extreme cases, this minimized network transmission could be
- the difference between an operation timing out or completing
- successfully.</para>
+ <para>Apache作为一个健壮的Web服务器的许多特性也可以用来增加Subversion的功能性和安全性，Subversion使用Neon与Apache通讯，这是一种一般的HTTP/WebDAV库，可以支持SSL和Deflate压缩（是<command>gzip</command>和<command>PKZIP</command>程序用来<quote>压缩</quote>文件为数据块的一样的算法）之类的机制。你只需要编译你希望Subversion和Apache需要的特性，并且正确的配置程序来使用这些特性。</para>
+
+ <para>Deflate压缩给服务器和客户端带来了更多地负担，压缩和解压缩减少了网络传输的实际文件的大小，如果网络带宽比较紧缺，这种方法会大大提高服务器和客户端之间发送数据的速度，在极端情况下，这种最小化的传输会造成超时和成功的区别。</para>
- <para>Less interesting, but equally useful, are other features
- of the Apache and Subversion relationship, such as the
- ability to specify a custom port (instead of the default
- HTTP port 80) or a virtual domain name by which the
- Subversion repository should be accessed, or the ability to
- access the repository through a proxy. These things are all
- supported by Neon, so Subversion gets that support for
- free.</para>
-
- <para>Finally, because <command>mod_dav_svn</command> is
- speaking a semi-complete dialect of WebDAV/DeltaV, it's
- possible to access the repository via third-party DAV
- clients. Most modern operating systems (Win32, OS X, and
- Linux) have the built-in ability to mount a DAV server as a
- standard network <quote>share</quote>. This is a
- complicated topic; for details, read <xref
- linkend="svn-ap-c"/>.</para>
+ <para>没有那么有趣，但是更加有用一点，这另一个Apache和Subversion关系的特性，像可以指定自定义的端口（而不是缺省的HTTP的80）或者是一个Subversion可以被访问的虚拟主机名，或者是通过代理服务器访问的能力，这些特性都是Neon所支持的，所以Subversion免费得到这些支持。</para>
+
+ <para>最后，因为<command>mod_dav_svn</command>是使用一个半完成的WebDAV/DeltaV方言，所以通过第三方的DAV客户端访问也是可能的，几乎所有的现代操作系统（Win32、OS X和Linux）都有把DAV服务器影射为普通的网络<quote>共享</quote>的内置能力，这是一个复杂的主题；察看<xref
+ linkend="svn-ap-c"/>来得到更多细节。</para>
</sect3>
@@ -2132,60 +1108,31 @@
<!-- ================================================================= -->
<sect1 id="svn-ch-6-sect-5">
- <title>Supporting Multiple Repository Access Methods</title>
+ <title>支持多种版本库访问方法</title>
- <para>You've seen how a repository can be accessed in many
- different ways. But is it possible—or safe—for your
- repository to be accessed by multiple methods simultaneously?
- The answer is yes, provided you use a bit of foresight.</para>
+ <para>你已经看到了一个版本库可以用多种方式访问，但是可以—或者说安全的—用几种方式同时并行的访问你的版本库吗？回答是可以，倘若你有一些远见。</para>
- <para>At any given time, these processes may require read and
- write access to your repository:</para>
+ <para>在任何给定的时间，这些进程会要求读或者写访问你的版本库：</para>
<itemizedlist>
<listitem>
- <para>regular system users using a Subversion client (as
- themselves) to access the repository directly via
- <literal>file:///</literal> URLs;</para>
+ <para>正规的系统用户使用Subversion客户端（客户端程序本身）通过<literal>file:///</literal>URL直接访问版本库；</para>
</listitem>
<listitem>
- <para>regular system users connecting to SSH-spawned private
- <command>svnserve</command> processes (running as
- themselves) which access the repository;</para>
+ <para>正规的系统用户连接使用SSH调用的访问版本库的<command>svnserve</command>进程（以他们自己运行）；</para>
</listitem>
<listitem>
- <para>an <command>svnserve</command> process—either a
- daemon or one launched by
- <command>inetd</command>—running as a particular fixed
- user;</para>
+ <para>一个<command>svnserve</command>进程—或者是一个守护进程，或者是通过<command>inetd</command>启动—作为一个固定的用户运行；</para>
</listitem>
<listitem>
- <para>an Apache <command>httpd</command> process, running as a
- particular fixed user.</para>
+ <para>一个Apache <command>httpd</command>进程，以一个固定用户运行。</para>
</listitem>
</itemizedlist>
- <para>The most common problem administrators run into is repository
- ownership and permissions. Does every process (or user) in the
- previous list have the rights to read and write the Berkeley DB
- files? Assuming you have a Unix-like operating system, a
- straightforward approach might be to place every potential
- repository user into a new <literal>svn</literal> group, and
- make the repository wholly owned by that group. But even that's
- not enough, because a process may write to the database files
- using an unfriendly umask—one that prevents access by
- other users.</para>
-
- <para>So the next step beyond setting up a common group for
- repository users is to force every repository-accessing process
- to use a sane umask. For users accessing the repository
- directly, you can make the <command>svn</command> program into a
- wrapper script that first sets <command>umask 002</command> and
- then runs the real <command>svn</command> client program. You
- can write a similar wrapper script for the
- <command>svnserve</command> program, and add a <command>umask
- 002</command> command to Apache's own startup script,
- <filename>apachectl</filename>. For example:</para>
+ <para>最通常的一个问题是管理进入到版本库的所有权和访问许可，是前面例子的所有进程 （或者说是用户）都有读写Berkeley DB的权限？假定你有一个类Unix的操作系统，一个直接的办法是在新的<literal>svn</literal>组的版本库用户添加所有潜在的用户，但这样还不足够，一位一个进程会使用不友好的umask来写数据库文件—o用来防止别的用户的访问。</para>
+
+ <para>所以下一步超越为每个版本库用户设置一个共同的组的方法是qiangzhi每个版本库访问进程是用一个健全的umask，对用户直接访问版本库，你可以使用<command>svn</command>的包裹脚本来首先设置<command>umask 002</command>，然后运行真实的<command>svn</command>客户端程序，你可以为<command>svnserve</command>写相同的脚本，并且增加<command>umask
+ 002</command>命令到Apache自己的启动脚本<filename>apachectl</filename>中。例如：</para>
<screen>
$ cat /usr/bin/svn
@@ -2197,65 +1144,24 @@
</screen>
- <para>Another common problem is often encountered on Unix-like
- systems. As a repository is used, BerkeleyDB occasionally
- creates new log files to journal its actions. Even if the
- repository is wholly owned by the <command>svn</command> group,
- these newly created files won't necessarily be owned by that
- same group, which then creates more permissions problems for
- your users. A good workaround is to set the group SUID bit on
- the repository's <filename>db</filename> directory. This causes
- all newly-created log files to have the same group owner as the
- parent directory.</para>
-
- <para>Once you've jumped through these hoops, your repository
- should be accessible by all the necessary processes. It may
- seem a bit messy and complicated, but the problems of having
- multiple users sharing write-access to common files are classic
- ones that are not often elegantly solved.</para>
-
- <para>Fortunately, most repository administrators will never
- <emphasis>need</emphasis> to have such a complex configuration.
- Users who wish to access repositories that live on the same
- machine are not limited to using <literal>file://</literal>
- access URLs—they can typically contact the Apache HTTP
- server or <command>svnserve</command> using
- <literal>localhost</literal> for the server name in their
- <literal>http://</literal> or <literal>svn://</literal> URLs.
- And to maintain multiple server processes for your Subversion
- repositories is likely to be more of a headache than necessary.
- We recommend you choose the server that best meets your needs
- and stick with it!</para>
+ <para>另一个在类Unix系统下常见的问题是，当版本库在使用时，BerkeleyDB有时候川建一个新的日志文件来记录它的东西，即使这个版本库是完全由<command>svn</command>组拥有，这个新创建的文件不是必须被同一个组拥有，这给你的用户造成了更多地许可问题。一个好的工作区应该设置组的SUID字节到版本库的<filename>db</filename>目录，这会导致所有新创建的日志文件拥有同父目录相同的组拥有者。</para>
+
+ <para>一旦你跳过了这些障碍，你的版本库一定是可以通过各种可能的手段访问了，这看起来有点混乱和负责，但是这个让多个用户分享对一个文件的写权限的问题是一个经典问题，并且经常是没有优雅的解决。</para>
+
+ <para>幸运的是，大多数版本库管理员不<emphasis>需要</emphasis>这样复杂的配置，用户如果希望访问本机的版本库，并不是一定要通过<literal>file://</literal>的URL—他们可以用<literal>localhost</literal>机器名联系Apache的HTTP服务器或者是<command>svnserve</command>，协议分别是<literal>http://</literal>或<literal>svn://</literal>。为你的Subversion版本库维护多个服务器进程，版本库会发生超出需要的头痛，我们建议你选择最符合你的需要的版本库，并且坚持使用！</para>
<sidebar>
- <title>The svn+ssh:// server checklist</title>
+ <title>svn+ssh://服务器检查列表</title>
- <para>It can be quite tricky to get a bunch of users with
- existing SSH accounts to share a repository without
- permissions problems. If you're confused about all the things
- that you (as an administrator) need to do on a Unix-like
- system, here's a quick checklist that resummarizes some of
- things discussed in this section:</para>
+ <para>让一些用户通过存在的SSH帐户来共享版本库而没有访问许可问题是一件很有技巧的事情，如果你为自己需要在你（作为一个管理员）的类Unix系统上做的事情感到迷惑，这里是一些快速的检查列表总结了本小节讨论的事情：</para>
<itemizedlist>
<listitem>
- <para>All of your SSH users need to be able to read and
- write to the repository. Put all the SSH users into a
- single group. Make the repository wholly owned by that
- group, and set the group permissions to read/write.</para>
+ <para>所有的SSH用户需要能够读写版本库，把所有的SSH用户放到同一个组里，让版本库完全属于这个组，摄制组的权限是读/写。</para>
</listitem>
<listitem>
- <para>Your users need to use a sane umask when accessing the
- repository. Make sure that <command>svnserve</command>
- (<filename>/usr/bin/svnserve</filename>, or wherever
- it lives in <literal>$PATH</literal>) is actually a
- wrapper script which sets <command>umask 002</command> and
- executes the real <command>svnserve</command>
- binary. Take similar measures when using
- <command>svnlook</command> and
- <command>svnadmin</command>. Either run them with a sane
- umask, or wrap them as described above.</para>
+ <para>你的用户在访问版本库时需要使用一个健全的umask，确定<command>svnserve</command>（<filename>/usr/bin/svnserve</filename>或者是任何一个<literal>$PATH</literal>说明的位置）是一个设置了<command>umask 002</command>和执行真正的<command>svnserve</command>程序的包裹脚本，对<command>svnlook</command>和<command>svnadmin</command>使用相同的措施，或者是使用一个健全的umask运行或者是使用上面说明的包裹。</para>
</listitem>
</itemizedlist>
More information about the svnbook-dev
mailing list