[svnbook] r5835 committed - branches/1.8/zh/book/ ch06-server-configuration.xml

wuzhouhui at users.sourceforge.net wuzhouhui at users.sourceforge.net
Thu Nov 29 00:51:47 CST 2018


Revision: 5835
          http://sourceforge.net/p/svnbook/source/5835
Author:   wuzhouhui
Date:     2018-11-29 06:51:44 +0000 (Thu, 29 Nov 2018)
Log Message:
-----------
1.8/zh: chapter 6 reviewed

Modified Paths:
--------------
    branches/1.8/zh/book/ch06-server-configuration.xml

Modified: branches/1.8/zh/book/ch06-server-configuration.xml
===================================================================
--- branches/1.8/zh/book/ch06-server-configuration.xml	2018-11-25 11:48:12 UTC (rev 5834)
+++ branches/1.8/zh/book/ch06-server-configuration.xml	2018-11-29 06:51:44 UTC (rev 5835)
@@ -1690,10 +1690,9 @@
       <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
       <sect3 id="svn.serverconfig.svnserve.auth.users">
       <!--
-           ### TODO realm
         <title>Create a users file and realm</title>
       -->
-        <title>创建一个用户文件和领域</title>
+        <title>创建一个用户文件和认证域</title>
 
       <!--
         <para>For now, the <literal>[general]</literal> section of
@@ -1704,7 +1703,7 @@
       -->
         <para>现在, 你所需要的所有变量都在 <filename>svnserve.conf</filename>
           的 <literal>[general]</literal> 部分. 先从修改这些变量的值开始:
-          为存放用户名和密码的文件选择一个名字; 选择一个认证领域:</para>
+          为存放用户名和密码的文件选择一个名字; 选择一个认证域:</para>
 
         <informalexample>
           <programlisting>
@@ -1764,8 +1763,8 @@
           <filename>conf/</filename> 目录内, 和
           <filename>svnserve.conf</filename> 放在一起. 另外, 多个仓库还能
           共享同一个用户文件, 在这种情况下, 文件应该放在更加开放的位置.
-          共享同一用户文件的仓库还要配置相同的领域, 因为用户名列表在本质上
-          就已经定义了一个认证领域. 无论用户文件放在何处, 都要设置好它的
+          共享同一用户文件的仓库还要配置相同的认证域, 因为用户名列表在本质上
+          就已经定义了一个认证域. 无论用户文件放在何处, 都要设置好它的
           读写权限. 如果管理员知道 <command>svnserve</command> 将以哪些用户
           身份运行, 在必要时可限制用户文件的读取权限.</para>
 
@@ -1893,7 +1892,6 @@
       <para>For many teams, the built-in CRAM-MD5 authentication is
         all they need from <command>svnserve</command>.  However, if
         your server (and your Subversion clients) were built with the
-        ### TODO
         Cyrus Simple Authentication and Security Layer (SASL) library,
         you have a number of authentication and encryption
         options available to you.</para>
@@ -2122,9 +2120,9 @@
           a mechanism such as OTP).</para>
       -->
         <para>有些地方需要注意: 首先要确保 <command>saslpasswd2</command> 的
-          <quote>领域</quote> 参数和定义在 <filename>svnserve.conf</filename>
-          里的领域是一致的, 如果它们不一致, 认证将会失败. 另外, 受限于 SASL,
-          领域必须是不带空格的字符串. 最后, 如果你决定使用标准的 SASL 密码数据
+          <quote>认证域</quote> 参数和定义在 <filename>svnserve.conf</filename>
+          里的认证域是一致的, 如果它们不一致, 认证将会失败. 另外, 受限于 SASL,
+          认证域必须是不带空格的字符串. 最后, 如果你决定使用标准的 SASL 密码数据
           库, 需要确保进程 <command>svnserve</command> 对数据库文件具有读
           权限 (某些认证机制—例如 OTP—还会要求写权限).</para>
 
@@ -4036,8 +4034,8 @@
       -->
         <para>你可以通过在 <literal><Location></literal> 添加
           <literal>Require valid-user</literal>, 从而允许用户对仓库执行所有
-          可能的操作. <xref linkend="svn.serverconfig.httpd.authn.digest"/>
-          的例子只允许成功认证的客户端对 Subversion 仓库执行任意的操作:</para>
+          可能的操作. 下面的例子只允许成功认证的客户端对 Subversion
+          仓库执行任意的操作:</para>
 
         <informalexample>
           <programlisting>
@@ -4056,7 +4054,6 @@
 </programlisting>
         </informalexample>
 
-        <!-- ### TODO -->
       <!--
         <para>Sometimes you don't need to run such a tight ship.  For
           example, the server hosting Subversion's own source code at
@@ -4071,7 +4068,7 @@
           inside your <literal><Location></literal>
           block.</para>
       -->
-        <para>有时候, 你并不需要这么绝对的设置. 比如说托管 Subversion 源代码
+        <para>有时候, 你并不需要这么严格的设置. 比如说托管 Subversion 源代码
           的服务器 (<ulink
             url="https://svn.apache.org/repos/asf/subversion/"/>) 允许所有人
           对仓库执行只读操作 (例如检出工作副本, 浏览仓库等), 但只允许认证
@@ -4748,7 +4745,6 @@
           <para>If the client receives a challenge for a certificate,
             the server is asking the client to prove its identity.
             The client must send back a certificate signed by a CA
-            ### TODO
             that the server trusts, along with a <firstterm>challenge
             response</firstterm> which proves that the client owns the
             private key associated with the certificate.  The private
@@ -4759,8 +4755,8 @@
       -->
           <para>如果客户端收到一个证书请求, 那便是服务器要求客户端提供它的
             身份, 客户端必须提供由 CA 签名过的证书, 而该 CA 是服务器所信任
-            的, 除了证书, 还要发送一个 <firstterm>响应</firstterm>
-            (<firstterm>challenge response</firstterm>), 这个响应证明了客户
+            的, 除了证书, 还要发送一个 <firstterm>回应</firstterm>
+            (<firstterm>challenge response</firstterm>), 这个回应证明了客户
             端拥有与证书关联的私钥. 私钥和证书通常被加密后存放在本地磁盘上,
             被一个密码保护. 当 Subversion 客户端收到证书的盘问时, 它将询问
             用户密钥与证书的存放路径, 以及对应的密码:</para>
@@ -6173,7 +6169,6 @@
             and servers.  Since feature negotiation happens against
             the slave, it is the slave's protocol version and feature
             set which is used.  But write operations are passed
-            ### TODO
             through to the master server quite literally.  Therefore,
             there is a risk that the slave server will answer a
             feature negotiation request from the client in way that is
@@ -6186,7 +6181,8 @@
             版本不匹配. 新发布的 Subversion 很可能为服务器与客户端之间所使用
             的网络协议添加了新特性, 由于客户端只和从服务器进行特性协商, 因此
             最终使用的协议版本和特性集合由从服务器的 Subversion 版本决定.
-            不过, 写操作被传递给主服务器, 因此, 如果主服务器的 Subversion
+            不过, 写操作是被逐字逐句地传递给主服务器, 因此, 如果主服务器的
+            Subversion
             版本较旧, 从服务器在与客户端进行特性协商时, 可能会返回从服务器
             支持, 而主服务器不支持的特性, 结果是客户端使用了主服务器不理解的
             特性, 最终导致操作失败.</para>
@@ -6354,7 +6350,6 @@
         directives that administrators can use in their
         <filename>httpd.conf</filename> files to enable and configure
         their Subversion server offering, introducing each directive
-        ### TODO
         as we also introduce the functionality it toggles.  In this
         section, we'll quickly summarize <emphasis>all</emphasis> the
         configuration directives supported by both of the Apache HTTP
@@ -6363,7 +6358,8 @@
       -->
       <para>在上面一节, 我们介绍了很多配置指令, 通过在
         <filename>httpd.conf</filename> 中使用这些配置指令, 管理员就可以
-        配置 Subversion 服务器的具体行为. 本节将快速总结 Subversion 提供的
+        配置 Subversion 服务器的具体行为, 以及服务器所能提供的功能. 本节将
+        快速总结 Subversion 提供的
         Apache HTTP 服务器模块的 <emphasis>所有</emphasis> 配置指令.</para>
 
       <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
@@ -7224,8 +7220,8 @@
         考虑一下你所创建的文化. 在大多数情况下, 特定的用户
         <emphasis>不应该</emphasis> 向特定的仓库目录提交修改, 这种约定没必要
         通过技术手段加以约束. 团队成员有时候会不由自主地与他们协作, 例如通过
-        向不属于他们的仓库目录提供修改, 帮助他们完成工作. 如果在服务器配置上
-        禁止了这种形式的合作, 无形中就树起了一道协作屏障. 随着着项目的发展与
+        向不属于他们的仓库目录提供修改, 帮助别人完成工作. 如果在服务器配置上
+        禁止了这种形式的合作, 无形中就树起了一道协作屏障. 随着项目的发展与
         新成员的加入, 管理员需要不停地创建新规则, 这会带来大量额外的维护工作.
       </para>
 
@@ -7239,7 +7235,7 @@
       -->
       <para>记住, 这是一个版本控制系统! 即使有人不小心向错误的目录提交了修改,
         这些修改也可以轻易地撤消. 如果用户故意向错误地目录提交修改, 这只能算
-        作人际问题, 这种问题要在 Subversion 外部解决.</para>
+        作人际问题, 要在 Subversion 外部解决.</para>
 
       <!--
       <para>So, before you begin restricting users' access rights, ask
@@ -7247,7 +7243,6 @@
         whether it's just something that <quote>sounds good</quote> to
         an administrator.  Decide whether it's worth sacrificing some
         server speed, and remember that there's very little risk
-        ### TODO
         involved; it's bad to become dependent on technology as a
         crutch for social problems.<footnote><para>A common theme in
         this book!</para></footnote></para>
@@ -7254,7 +7249,9 @@
       -->
   <para>所以, 在管理员限制用户的访问权限之前, 要问一下自己这是否真的有必要,
     是否只是为了 <quote>听起来不错</quote>, 是否值得牺牲服务器的性能. 放任
-    用户的访问权限并不会带来非常大的风险, 而把.</para>
+    用户的访问权限并不会带来非常大的风险, 而且依赖技术手段来解决社交问题是
+    一种不好的做法!<footnote><para>这是本书的一个重要主题</para></footnote>
+  </para>
 
       <!--
       <para>As an example to ponder, consider that the Subversion
@@ -7271,7 +7268,7 @@
         有一套自己约定俗成的规则, 但这些规则总是通过社交来实施. 这是一种
         良好地社区信任模型, 特别是对于开源项目而言. 当然, 有时候确实需要
         基于路径的访问控制, 比如说在公司内部, 某些数据非常敏感, 只能把访问
-        权授予给少部分人员.</para>
+        权授予给少数人.</para>
 
     </sidebar>
 
@@ -7304,7 +7301,7 @@
         在配置文件 <filename>httpd.conf</filename> 内用配置指令
         <literal>AuthzSVNAccessFile</literal> 或
         <literal>AuthzSVNReposRelativeAccessFile</literal> 指定访问权限配置
-        文件. (详细的解决见 <xref
+        文件. (详细的说明见 <xref
           linkend="svn.serverconfig.httpd.authz.perdir"/>.)</para>
 
       <!--
@@ -7391,7 +7388,7 @@
       -->
       <para>下面是访问权限配置文件的一个例子, 文件把仓库 <literal>calc</literal>
         的路径 <filename>/branches/calc/bug-142</filename> (及其子目录) 的
-        读权限授予 Sally, 把读取权限授予 Harry:</para>
+        读权限授予 Sally, 把读写权限授予 Harry:</para>
 
       <informalexample>
         <programlisting>
@@ -7427,7 +7424,6 @@
         the <literal>SVNReposName</literal> <filename>httpd.conf</filename>
         directive will be ignored by the authorization subsystem.
         Your access control file sections must refer to repositories
-        ### TODO
         by their server-sensitive paths as previously
         described.</para></footnote>,
         while <command>svnserve</command> uses the entire relative
@@ -7467,8 +7463,8 @@
           同一个仓库服务, 那么 <command>mod_dav_svn</command> 与
           <command>svnserve</command> 决定仓库名的不同之外将会带来问题.
           通常情况下, 管理员更喜欢为两种服务器配置同一个访问权限配置文件, 然而,
-          为了能让访问权限配置文件正常工作, 管理员必须确保访问文件里的仓库
-          名对于两种服务器而言都是兼容的—例如把
+          为了能让访问权限配置文件正常工作, 管理员必须确保访问权限配置文件里
+          的仓库名对于两种服务器而言都是兼容的—例如把
           <command>svnserve</command> 的根目录配置成和
           <command>mod_dav_svn</command> 的配置指令
           <literal>SVNParentPath</literal> 相同的值, 或者为每个仓库指定一个
@@ -7562,7 +7558,7 @@
           path in the access file will always override any permissions
           inherited from parent directories.</para>
       -->
-        <para>需要记住的是最明确的路径最明确的路径总是最先被匹配. 服务器总
+        <para>需要记住的是最明确的路径总是最先被匹配. 服务器总
           是试图匹配路径本身, 然后是路径的父路径, 然后再是父路径的父路径,
           以此类推. 这样做的影响是如果我们在访问权限配置文件里添加一个特定的
           路径, 那么它的权限配置就会覆盖从父目录继承而来的权限配置.</para>
@@ -7588,7 +7584,7 @@
         asterisk variable (<literal>*</literal>), which means <quote>all
         users</quote>:</para>
       -->
-    <para>在默认情况下, 任何用户对任意一个仓库都不具体访问权限, 这意味着
+    <para>在默认情况下, 任何用户对任意一个仓库都不具备访问权限, 这意味着
       如果从头开始写访问权限配置文件, 你可能希望所有用户至少对仓库的根目录具有
       只读权限. 可以通过把用户名设置成通配符 (<literal>*</literal>) 实现这
       种配置, 此时通配符 <literal>*</literal> 表示 <quote>所有用户</quote>:
@@ -7910,7 +7906,6 @@
       <!--
       <para>If you're using Apache as your Subversion server and have
         made certain subdirectories of your repository unreadable to
-        ### TODO
         certain users, you need to be aware of a possible nonoptimal
         behavior with <command>svn checkout</command>.</para>
       -->
@@ -8440,7 +8435,7 @@
       ### TODO
       The answer is yes, provided you use a bit of foresight.</para>
       -->
-    <para>读者已经见到了访问仓库的多种方式, 但是否有可能同时以多种方式,
+    <para>读者已经见到了访问仓库的多种方式, 但是否有可能同时以多种方式
       (安全地) 访问仓库? 答案是肯定的.</para>
 
       <!--
@@ -8607,7 +8602,7 @@
       -->
       <para>对于已经有了 SSH 账户的用户, 为了让他们共享仓库而不会产生权限上
         的问题, 其中的过程可能会比较麻烦. 如果你 (作为一个管理员) 对需要在类
-        Unix 系统上需要完成的工作不太清楚, 这里列出了一个检查列表, 总结了本节
+        Unix 系统上完成的工作不太清楚, 这里列出了一个检查列表, 总结了本节
         讨论的几个主题:</para>
 
       <itemizedlist>




More information about the svnbook-dev mailing list