最简单的方式, 就是把 svnserve 作为一个守护进程 运行, 执行时需要添加选项 -d:

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

以守护进程模式运行 svnserve 时, 可以使用 选项 --listen-port 和 --listen-host 修改进程所 “绑定” 的端口号和主机名.

svnserve 一旦成功启动, 服务器上的所有仓库 都能通过网络进行访问. 如果客户端需要访问仓库, 必须在仓库的 URL 参数中指定一个 绝对 路径. 比如说某个仓库在 服务器上的位置是 /var/svn/project1, 那么客户 端访问仓库的 URL 参数就可以写成 svn://host.example.com/var/svn/project1. 为了增加安全 性, 可以为 svnserve 添加选项 -r, 使得只有指定路径下的仓库才会被导出, 例如:

$ svnserve -d -r /var/svn
…

使用选项 -r 等价于修改了 svnserve 的根目录, 客户端访问仓库的所使用的 URL 也能写得更加简短:

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

如果管理员希望由 inetd 启动进程, 就给 svnserve 添加选项 -i (--inetd). 在下面的例子里, 我们展示了在命令行上 执行 svnserve -i 的输出, 但要注意的是命令实际 上并没有启动进程; 例子后面的内容介绍了如何配置 inetd, 使得它能够启动 svnserve.

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

如果使用选项 --inetd 调用 svnserve, 它会尝试使用定制化的协议, 通过 stdin 和 stdout 与 Subversion 通信, 这是由 inetd 所启动的程序的标准 行为. IANA 将端口 3690 保留给 Subversion 使用, 所以说在一个类 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, 负责处理客户端发来的 请求. 当然, 管理员也可以在配置文件里为 svnserve 添加选项 -r, 从而限制被导出的仓库.

某些系统提供了 xinetd 作为 inetd 的替代品, 幸运的是, 管理员也可以配置 svnserve 由 xinetd 启动. 为了实现这点, 管理员创建一个配置 文件 /etc/xinetd.d/svn, 文件的内容是:

# default: on
# description: Subversion server for the svn protocol
service svn
{
  disabled        = no
  port            = 3690
  socket_type     = stream
  protocol        = tcp
  wait            = no
  user            = subversion
  server          = /usr/local/bin/svnserve
  server_args     = -i -r /path/to/repositories
}

要确保 /etc/services 包含了 svn 协议所使用的端口 (见 “由 inetd 调用 svnserve”一节), 否则的话, 守护进程将无法正常启动.

如果是基于 Redhat 的 Linux 发行版, 管理员需要使用 chkconfig --add svn 激活新的服务, 后面就可以用图 形化配置工具禁止或允许服务器程序.

另一种启动方式是通过添加选项 -t, 以隧道模式启动 svnserve. 隧道模式假设有一个远程服务程序 (例如 rsh 或 ssh 已经成功地授权了 一个用户, 并且以该 用户的身份 启动了一个私有 的 svnserve 进程. (用户几乎没有必要在命令行 启动带有选项 -t 的 svnserve, 相反, SSH 守护进程会替用户执行这个操作) 程序 svnserve 像往常一样运行 (通过 stdin 和 stdout 与其他 进程通信), 它还假设网络数据可以通过某种隧道, 被自动重定向回客户端. 当隧道代理 以这种方式启动 svnserve 时, 要确保被授权的用户 对仓库数据库文件具有读写权限, 在本质上它和本地用户通过 file:// URL 访问仓库的情况是一样的.

更多的细节见 “SSH 隧道”一节.

如果服务器所用的 Windows 系统是 Windows NT 的后代 (Windows 2000 或 更新的版本), 管理员就能把 svnserve 作为一个标准 的 Windows 服务启动, 和独立的守护进程启动方式 (添加选项 --daemon (-d)) 相比, 这通常能带 来更好的体验. 为了以守护进程的方式启动 svnserve, 我们需要打开一个控制台, 输入命令, 然后任由控制台永远地运行下去. 然而, 在后台运行的 Windows 服务可以在系统引导时自动启动, 可以使用和其他 Windows 服务一样的管理接口来启动或停止服务.

为了定义一个新的 Windows 服务, 需要用到命令行工具 SC.EXE. 类似于 inetd 的配置 文件, 管理员必须准确地指定 svnserve 的启动方式, 以便 Windows 在开机时启动相应的服务:

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. 在这个例子里有很多需要注意的地方.

首先, 启动 svnserve.exe 时必须带上参数 --service, 其他选项必须出现在同一行, 不能再添加 会引起冲突的选项, 例如 --daemon (-d), --tunnel 或 --inetd (-i), 但可以添加选项 -r 或 --listen-port. 第二, 注意命令行里的空格: 模式 key= value 中, key 和 = 之间不能有空格, 而 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 用于管理作业的生命周期.

如果 svnserve 被配置成作为一个 launchd 作业, 那么当有 svn:// 网络流量需要处理时, 将自动启动 svnserve. 这要比 手动地启动 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 系统学习起来有一定的困难, 幸运的是 本节所介绍的 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 进程就会终止.

	注意
	因为我们希望 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 客户端在认证的提示信息里显示 realm 的值, 并 用它 (再加上服务器的主机名和端口号) 作为缓存在磁盘上的证书的键 (见 “缓存证书”一节). 变量 password-db 指向一个单独的文件, 它包含了 一连串的用户名和密码, 文件的格式和 svnserve.conf 是相同的, 例如:

[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] 节, 并为变量 use-sasl 赋值:

[sasl]
use-sasl = true

然后, 在 SASL 库函数能够找到的位置创建一个名为 svn.conf 的配置文件—最典型的位置就是 SASL 插件所处的位置, 因此管理员需要定位 SASL 插件在系统中的位置, 例如 /usr/lib/sasl2/ 或 /etc/sasl2/. (注意, 本段所说的配置文件是 svn.conf, 不是仓库中的 svnserve.conf!).

如果服务器的系统是 Windows, 你需要编辑系统注册表 (使用工具 regedit), 以便告诉 SASL 去哪里搜索所需要的 文件. 在系统注册表中添加一个新的注册表项, 表项的名字是 [HKEY_LOCAL_MACHINE\SOFTWARE\CarnegieMellon\Project Cyrus\SASL Library], 并在其中新增两项: 一项是 SearchPath (它的值是一个 指向目录的路径, 目录包含了 SASL 动态链接库), 另一项是 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

上面的配置向客户端宣告了 DIGEST-MD5 认证机制, 使用存放在 /etc/my_sasldb 里的私有密码数据库检查用户 输入的密码的正确性. 管理员可以使用 saslpasswd2 向密码数据库添加或修改用户名和密码:

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

有些地方需要注意: 首先要确保 saslpasswd2 的 “认证域” 参数和定义在 svnserve.conf 里的认证域是一致的, 如果它们不一致, 认证将会失败. 另外, 受限于 SASL, 认证域必须是不带空格的字符串. 最后, 如果你决定使用标准的 SASL 密码数据 库, 需要确保进程 svnserve 对数据库文件具有读 权限 (某些认证机制—例如 OTP—还会要求写权限).

这只是一种配置 SASL 的简单方式. 还有其他多种认证机制可供选择, 密码也能以其他格式存在, 例如 LDAP 或 SQL 数据库, 具体的细节请参考 SASL 文档.

注意, 如果管理员将服务器配置成仅允许使用 SASL 认证机制, 这同时 也在要求所有连接到服务器的客户端必须支持 SASL, 不支持 SASL 的客户 端 (包括 1.5 版之前的所有客户端) 将无法完成认证, 但是另一个方面, 这种配置也正是你所想要的效果 (“所有的客户端都必须使用 Kerberos!”). 然而, 如果仍然存在不支持 SASL 的客户端需要 连接服务器, 就要确保 CRAM-MD5 认证机制是可用的, 因为所有的客户端 都支持 CRAM-MD5.

如果特定的机制支持, 那么 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. 如果 管理员希望允许—但并非强制—加密, 就把 min-encryption 设为 0, 把 max-encryption 设为稍微大点的值. 为了强制要求 对数据进行加密, 把两个变量都设为大于 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. 这种行为允许我们实现多种服务器 端技巧, 在下面的例子里, 我们把 authorized_keys 的每一行简写为:

  command="program" TYPE KEY COMMENT

因为我们可以指定在服务器端被执行的命令, 所以很容易就能指定 一个特殊的 svnserve 程序, 并给它传递额外的参数:

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

在上面的例子里, /path/to/svnserve 可能是 一个定制化的 svnserve 包装脚本, 脚本将会重新 设置文件权限掩码 (见 “支持多种仓库访问方法”一节). 例子还展示了如何修改 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, 那么 svnserve 会认为所有的提交都来自被共享的 账户.

最后一点需要提醒的是: 如果一个用户可通过共享账户的公钥访问 服务器, 即使在 authorized_keys 里设置了 command, 也可能仍然允许其他形式的 SSH 访问. 例如 用户仍然能够通过 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

注意上面的内容必须写在同一行内, 因为 authorized_keys 不支持通过反斜杠来实现行的 延续, 例子里的换行只是为了方便排版.

[general] 节包含了最常用到的 svnserve 配置选项.

[sasl] 节包含了专门针对 svnserve 可选特性 SASL (Cyrus Simple Authentication and Security Layer) 的配置, 关于 SASL 更详细的信息 以及它的益处, 见 “svnserve 使用 SASL”一节.