最简单的选项是运行 svnserve 作为独立的 “守护进程” 进程。为此，请使用 -d 选项。

$ svnserve -d
$               # svnserve is now running, listening on port 3690

在以守护进程模式运行 svnserve 时，可以使用 --listen-port 和 --listen-host 选项来自定义要 “绑定” 的确切端口和主机名。

一旦我们成功地按照前面介绍的步骤启动 svnserve，系统中的每个存储库都将对网络可用。客户端需要在存储库 URL 中指定一个 绝对 路径。例如，如果存储库位于 /var/svn/project1，则客户端可以通过 svn://host.example.com/var/svn/project1 访问它。为了提高安全性，您可以向 svnserve 传递 -r 选项，该选项限制它仅导出该路径下的存储库。例如：

$ svnserve -d -r /var/svn
…

使用 -r 选项实际上会修改程序视为远程文件系统空间根目录的位置。然后，客户端使用从 URL 中删除了该路径部分的 URL，从而得到更短（并且更不显眼）的 URL。

$ svn checkout svn://host.example.com/project1
…

如果您希望 inetd 启动该进程，则需要传递 -i (--inetd) 选项。在以下示例中，我们展示了在命令行运行 svnserve -i 的输出，但请注意，这不是实际启动守护进程的方式；请参阅示例后的段落以了解如何配置 inetd 来启动 svnserve。

$ svnserve -i
( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops d\
epth log-revprops partial-replay ) ) )

当使用 --inetd 选项调用时，svnserve 尝试通过使用自定义协议通过 stdin 和 stdout 与 Subversion 客户端通信。这是通过 inetd 运行的程序的标准行为。IANA 为 Subversion 协议保留了端口 3690，因此在类 Unix 系统上，您可以向 /etc/services 添加以下行（如果它们尚不存在）：

svn           3690/tcp   # Subversion
svn           3690/udp   # Subversion

如果您的系统正在使用传统的类 Unix 的 inetd 守护进程，您可以将以下行添加到 /etc/inetd.conf 中：

svn stream tcp nowait svnowner /usr/bin/svnserve svnserve -i

确保 “svnowner” 是一个具有访问存储库的适当权限的用户。现在，当客户端连接到您服务器上的 3690 端口时，inetd 将生成一个 svnserve 进程来为其提供服务。当然，您可能还想将 -r 添加到配置行，以限制导出哪些存储库。

启动 svnserve 的另一种方法是使用 -t 选项在隧道模式下运行。此模式假设像 rsh 或 ssh 这样的远程服务程序已经成功地对用户进行了身份验证，并且现在正在 以该用户身份 调用一个私有的 svnserve 进程。（请注意，您（用户）很少（如果有的话）有理由在命令行上使用 -t 启动 svnserve；相反，SSH 守护进程会为您执行此操作。）svnserve 程序正常运行（通过 stdin 和 stdout 通信）并假设流量正在通过某种类型的隧道自动重定向回客户端。当 svnserve 通过像这样的隧道代理调用时，请确保经过身份验证的用户对存储库数据库文件具有完全的读写权限。这与本地用户通过 file:// URL 访问存储库本质上是一样的。

此选项将在本章后面的 名为“通过 SSH 隧道运行”的部分 中进行更详细的描述。

如果您的 Windows 系统是 Windows NT 的后代（Windows 2000 或更新版本），您可以将 svnserve 作为标准的 Windows 服务运行。这通常比使用 --daemon (-d) 选项将其作为独立的守护进程运行要好得多。使用守护进程模式需要启动一个控制台，键入一个命令，然后让控制台窗口一直运行。但是，Windows 服务在后台运行，可以在启动时自动启动，并且可以使用与其他 Windows 服务相同的管理界面启动和停止。

您需要使用命令行工具 SC.EXE 定义新的服务。就像 inetd 配置行一样，您必须为 Windows 在启动时运行指定一个精确的 svnserve 调用。

C:\> sc create svn
        binpath= "C:\svn\bin\svnserve.exe --service -r C:\repos"
        displayname= "Subversion Server"
        depend= Tcpip
        start= auto

这将定义一个名为 svn 的新 Windows 服务，该服务在启动时执行特定的 svnserve.exe 命令（在本例中，该命令的根目录为 C:\repos）。但是，前面的示例中有一些注意事项。

首先，请注意，svnserve.exe 程序必须始终使用 --service 选项调用。然后，必须在同一行上指定 svnserve 的任何其他选项，但您不能添加冲突的选项，例如 --daemon (-d)、--tunnel 或 --inetd (-i)。不过，-r 或 --listen-port 之类的选项是可以的。其次，在调用 SC.EXE 命令时要小心空格：key= value 模式在 key= 之后不能有空格，在 value 之前必须有且只有一个空格。最后，要小心要调用的命令行中的空格。如果目录名包含空格（或其他需要转义的字符），请将 binpath 的整个内部值用双引号括起来，并对它们进行转义：

C:\> sc create svn
        binpath= "\"C:\program files\svn\bin\svnserve.exe\" --service -r C:\repos"
        displayname= "Subversion Server"
        depend= Tcpip
        start= auto

还要注意，binpath 这个词具有误导性——它的值是一个 命令行，而不是可执行文件的路径。这就是为什么如果它包含嵌入的空格，您需要用引号将它括起来的原因。

定义服务后，可以使用标准的 GUI 工具（服务管理控制面板）或在命令行中停止、启动或查询它。

C:\> net stop svn
C:\> net start svn

还可以通过删除服务的定义来卸载（即取消定义）服务：sc delete svn。请务必先停止服务！SC.EXE 程序还有许多其他子命令和选项；运行 sc /? 以了解有关它的更多信息。

Mac OS X（10.4 及更高版本）使用 launchd 来管理系统范围和用户范围的进程（包括守护进程）。launchd 作业由 XML 属性列表文件中的参数指定，launchctl 命令用于管理这些作业的生命周期。

当配置为作为 launchd 作业运行时，svnserve 会在需要处理传入的 Subversion svn:// 网络流量时按需自动启动。这比需要您手动调用 svnserve 作为长时间运行的后台进程的配置要方便得多。

要将 svnserve 配置为 launchd 作业，首先创建一个名为 /Library/LaunchDaemons/org.apache.subversion.svnserve.plist 的作业定义文件。示例 6.1，“一个 svnserve launchd 作业定义示例” 提供了这样一个文件的示例。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
    "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        <key>Label</key>
        <string>org.apache.subversion.svnserve</string>
        <key>ServiceDescription</key>
        <string>Host Subversion repositories using svn:// scheme</string>
        <key>ProgramArguments</key>
        <array>
            <string>/usr/bin/svnserve</string>
            <string>--inetd</string>
            <string>--root=/var/svn</string>
        </array>
        <key>UserName</key>
        <string>svn</string>
        <key>GroupName</key>
        <string>svn</string>
        <key>inetdCompatibility</key>
        <dict>
            <key>Wait</key>
            <false/>
        </dict>
        <key>Sockets</key>
        <dict>
            <key>Listeners</key>
            <array>
                <dict>
                    <key>SockServiceName</key>
                    <string>svn</string>
                    <key>Bonjour</key>
                    <true/>
                </dict>
            </array>
        </dict>
    </dict>
</plist>

	警告
	launchd 系统可能有点难以学习。幸运的是，有关本节中描述的命令的文档已存在。例如，在命令行中运行 man launchd 以查看 launchd 本身的联机帮助页，运行 man launchd.plist 以阅读有关作业定义格式的信息，等等。

创建作业定义文件后，可以使用 launchctl load 激活作业。

$ sudo launchctl load \
       -w /Library/LaunchDaemons/org.apache.subversion.svnserve.plist

说清楚一点，此操作实际上还没有启动 svnserve。它只是告诉 launchd 如何在 svn 网络端口上收到传入的网络流量时启动 svnserve；它将在处理完流量后将其终止。

	注意
	因为我们希望 svnserve 成为一个系统范围的守护进程，所以我们需要使用 sudo 以管理员身份管理此作业。还要注意，定义文件中的 UserName 和 GroupName 键是可选的——如果省略，该作业将以加载作业的用户身份运行。

停用作业也很容易——使用 launchctl unload。

$ sudo launchctl unload \
       -w /Library/LaunchDaemons/org.apache.subversion.svnserve.plist

launchctl 还提供了一种方法让您查询作业的状态。如果作业已加载，则将有一行与作业定义文件中指定的 Label 匹配。

$ sudo launchctl list | grep org.apache.subversion.svnserve
-       0       org.apache.subversion.svnserve
$

目前，svnserve.conf 文件的 [general] 节包含你需要的所有变量。首先更改这些变量的值：选择一个包含用户名和密码的文件名，并选择一个身份验证领域。

[general]
password-db = userfile
realm = example realm

realm 是你定义的一个名称。它告诉客户端他们连接到哪种 “身份验证命名空间”；Subversion 客户端会在身份验证提示中显示它，并将其用作键（与服务器的主机名和端口一起），用于在磁盘上缓存凭据（请参阅 “缓存凭据” 部分）。password-db 变量指向一个单独的文件，该文件包含用户名和密码列表，并使用相同的熟悉格式。例如

[users]
harry = foopassword
sally = barpassword

password-db 的值可以是用户文件的绝对路径或相对路径。对于许多管理员来说，将文件保存在存储库的 conf/ 区域内，与 svnserve.conf 文件并排，会很方便。另一方面，你可能希望两个或多个存储库共享同一个用户文件；在这种情况下，文件可能应该保存在更公开的位置。共享用户文件的存储库也应配置为具有相同的领域，因为用户列表实际上定义了身份验证领域。无论文件保存在哪里，都要确保适当地设置文件的读写权限。如果你知道 svnserve 将以哪些用户身份运行，请根据需要限制对用户文件的读访问权限。

在 svnserve.conf 文件中还有两个变量需要设置：它们决定未经身份验证（匿名）用户和已验证用户可以执行的操作。变量 anon-access 和 auth-access 可以设置为值 none、read 或 write。将值设置为 none 禁止读取和写入；read 允许只读访问存储库，而 write 允许对存储库进行完全读写访问。例如

[general]
password-db = userfile
realm = example realm

# anonymous users can only read the repository
anon-access = read

# authenticated users can both read and write
auth-access = write

实际上，示例设置是变量的默认值，如果你忘记定义它们，可以使用这些值。如果你想更保守，可以完全阻止匿名访问

[general]
password-db = userfile
realm = example realm

# anonymous users aren't allowed
anon-access = none

# authenticated users can both read and write
auth-access = write

服务器进程不仅了解对存储库的这些 “整体” 访问控制，还了解对存储库内特定文件和目录实施的更细粒度的访问限制。要使用此功能，你需要定义一个包含更详细规则的文件，然后将 authz-db 变量设置为指向它

[general]
password-db = userfile
realm = example realm

# Specific access rules for specific locations
authz-db = authzfile

我们将详细讨论本章后面部分中 authzfile 文件的语法，在 “基于路径的授权” 部分中。请注意，authz-db 变量与 anon-access 和 auth-access 变量并不相互排斥；如果所有变量都已定义，则必须满足 所有 规则才能允许访问。

要在服务器上激活特定的 SASL 机制，你需要执行两项操作。首先，在存储库的 svnserve.conf 文件中创建一个 [sasl] 节，其中包含一个初始键值对

          [sasl]
          use-sasl = true

其次，在 SASL 库可以找到的位置创建名为 svn.conf 的主 SASL 配置文件——通常在包含 SASL 插件的目录中。你需要在你的特定系统上找到插件目录，例如 /usr/lib/sasl2/ 或 /etc/sasl2/。（请注意，这不是存储库中包含的 svnserve.conf 文件！）

在 Windows 服务器上，你还需要编辑系统注册表（使用 regedit 等工具），以告诉 SASL 在哪里可以找到这些内容。创建一个名为 [HKEY_LOCAL_MACHINE\SOFTWARE\Carnegie Mellon\Project Cyrus\SASL Library] 的注册表项，并在其中放置两个键：一个名为 SearchPath 的键（其值是包含 SASL sasl*.dll 插件库的目录的路径），以及一个名为 ConfFile 的键（其值是包含你创建的 svn.conf 文件的父目录的路径）。

由于 SASL 提供了多种身份验证机制，因此尝试描述每种可能的服务器端配置将是愚蠢的（并且远远超出本书的范围）。相反，我们建议你阅读 SASL 源代码的 doc/ 子目录中提供的文档。它详细介绍了每种机制以及如何为每种机制适当地配置服务器。在本讨论中，我们将只演示配置 DIGEST-MD5 机制的一个简单示例。例如，如果你的 svn.conf 文件包含以下内容

pwcheck_method: auxprop
auxprop_plugin: sasldb
sasldb_path: /etc/my_sasldb
mech_list: DIGEST-MD5

你已经告诉 SASL 向客户端宣传 DIGEST-MD5 机制，并将用户密码与位于 /etc/my_sasldb 的私有密码数据库进行检查。系统管理员可以使用 saslpasswd2 程序在数据库中添加或修改用户名和密码

$ saslpasswd2 -c -f /etc/my_sasldb -u realm username

需要提醒你几句：首先，确保传递给 saslpasswd2 的 “realm” 参数与你在存储库的 svnserve.conf 文件中定义的相同领域匹配；如果不匹配，身份验证将失败。此外，由于 SASL 中存在一个缺陷，公共领域必须是一个不包含空格的字符串。最后，如果你决定使用标准 SASL 密码数据库，请确保 svnserve 程序可以读取该文件（如果使用的是 OTP 等机制，可能还需要写入权限）。

这只是配置 SASL 的一种简单方法。可以使用许多其他身份验证机制，并且密码可以存储在其他地方，例如 LDAP 或 SQL 数据库中。有关详细信息，请参阅完整的 SASL 文档。

请记住，如果您将服务器配置为仅允许某些 SASL 身份验证机制，这将强制所有连接的客户端也具有 SASL 支持。任何没有 SASL 支持的 Subversion 客户端（包括所有 1.5 之前的客户端）都无法进行身份验证。一方面，这种限制可能正是您想要的（“我的所有客户端都必须使用 Kerberos！”）。但是，如果您仍然希望非 SASL 客户端能够进行身份验证，请确保将 CRAM-MD5 机制作为一种选择进行宣传。所有客户端都可以使用 CRAM-MD5，无论它们是否具有 SASL 功能。

如果特定机制支持，SASL 也可以执行数据加密。内置的 CRAM-MD5 机制不支持加密，但 DIGEST-MD5 支持，而 SRP 等机制实际上需要使用 OpenSSL 库。要启用或禁用不同级别的加密，您可以在存储库的 svnserve.conf 文件中设置两个值。

[sasl]
use-sasl = true
min-encryption = 128
max-encryption = 256

min-encryption 和 max-encryption 变量控制服务器要求的加密级别。要完全禁用加密，请将这两个值都设置为 0。要启用数据的简单校验和（即，防止篡改并保证数据完整性而无需加密），请将这两个值都设置为 1。如果您希望允许（但不强制）加密，请将最小值设置为 0，并将最大值设置为某个位长。要无条件地要求加密，请将这两个值都设置为大于 1 的数字。在前面的示例中，我们要求客户端至少进行 128 位加密，但最多不超过 256 位加密。

首先，找到您将用来启动 svnserve 的帐户的主目录。确保该帐户安装了 SSH 公钥/私钥对，并且该用户可以通过公钥身份验证登录。密码身份验证将不起作用，因为以下所有 SSH 技巧都围绕着使用 SSH authorized_keys 文件。

如果不存在，请创建 authorized_keys 文件（在 Unix 上，通常为 ~/.ssh/authorized_keys）。此文件中的每一行都描述了允许连接的公钥。这些行通常采用以下形式。

  ssh-dsa AAAABtce9euch… user@example.com

第一个字段描述了密钥类型，第二个字段是密钥本身的 Base64 编码，第三个字段是注释。但是，鲜为人知的是，整行都可以用 command 字段作为前缀。

  command="program" ssh-dsa AAAABtce9euch… user@example.com

当设置了 command 字段时，SSH 守护进程将运行指定的程序，而不是 Subversion 客户端要求的典型的隧道模式 svnserve 调用。这为许多服务器端技巧打开了大门。在以下示例中，我们将文件的各行缩写为以下形式。

  command="program" TYPE KEY COMMENT

由于我们可以指定执行的服务器端命令，因此很容易命名一个要运行的特定 svnserve 二进制文件，并向其传递额外的参数。

  command="/path/to/svnserve -t -r /virtual/root" TYPE KEY COMMENT

在这个示例中，/path/to/svnserve 可能是一个围绕 svnserve 的自定义包装脚本，它设置 umask（参见 名为“支持多种存储库访问方式”的部分）。它还展示了如何将 svnserve 锚定在虚拟根目录中，就像在将 svnserve 作为守护进程运行时经常做的那样。这样做可能是为了限制对系统某些部分的访问，或者只是为了减轻用户在 svn+ssh:// URL 中键入绝对路径的负担。

还可以让多个用户共享一个帐户。与其为每个用户创建单独的系统帐户，不如为每个人生成一个公钥/私钥对。然后将每个公钥放入 authorized_keys 文件中，每行一个，并使用 --tunnel-user 选项。

  command="svnserve -t --tunnel-user=harry" TYPE1 KEY1 harry@example.com
  command="svnserve -t --tunnel-user=sally" TYPE2 KEY2 sally@example.com

这个示例允许 Harry 和 Sally 都通过公钥身份验证连接到同一个帐户。他们每个人都拥有一个将被执行的自定义命令；--tunnel-user 选项告诉 svnserve 假设命名的参数是经过身份验证的用户。如果没有 --tunnel-user，则所有提交看起来都像是来自同一个共享系统帐户。

最后要提醒您：通过公钥在共享帐户中授予用户对服务器的访问权限，仍然可能允许其他形式的 SSH 访问，即使您已在 authorized_keys 中设置了 command 值。例如，用户仍然可以通过 SSH 获得 shell 访问权限，或者能够通过您的服务器执行 X11 或通用端口转发。要尽可能地减少对用户的权限，您可能希望在 command 之后立即指定一些限制性选项。

  command="svnserve -t --tunnel-user=harry",no-port-forwarding,no-agent-forw
arding,no-X11-forwarding,no-pty TYPE1 KEY1 harry@example.com

请注意，所有这些都必须在一行上——真正地在一行上——因为 SSH authorized_keys 文件甚至不允许使用传统的反斜杠字符 (\) 来续行。我们之所以在书页上用换行符显示它，只是为了让它能够适应书页的物理尺寸。