CentOS 搭建 SVN 服务器连不上？资深运维带你精准排雷

场景还原： 开发团队急匆匆跑来，“SVN 连不上了！代码提交不上去，也更新不了！” 作为运维，你心头一紧，迅速登录 CentOS 服务器。svnserve 进程明明在跑，netstat -tulnp | grep 3690 也显示端口在监听，但客户端就是报错：“无法连接主机”、“目标机器积极拒绝”... 别慌，这种连接问题,往往藏在这几个关键环节。

核心思路： 连接失败，逃不开 网络可达性、服务状态、权限配置 三大方向,我们按优先级逐一击破。

🛡️ 第一道防线：防火墙与端口 (网络可达性)

这是最高频的“拦路虎”。

1. 检查 CentOS 防火墙 (firewalld 最常见):

   sudo firewall-cmd --list-all

   关键看：ports: 或 services: 部分是否包含 svn 或 3690/tcp，如果没有,立即放行：

   sudo firewall-cmd --zone=public --add-port=3690/tcp --permanent
   sudo firewall-cmd --reload
   sudo firewall-cmd --zone=public --list-ports  # 确认添加成功

2. 云服务器安全组/网络安全策略：

   • 这是独立于系统防火墙的云平台层面防火墙，务必登录云服务商控制台（阿里云、腾讯云、AWS等）。
   • 找到该 CentOS 实例关联的安全组。
   • 添加入站规则：允许来源（如 0.0.0/0 或指定IP段）访问 TCP 3690 端口。这是最容易被忽略的关键一步！

3. 本地网络限制：

   • 客户端是否在受限网络（公司防火墙、代理）？尝试从服务器本机 telnet localhost 3690 或 telnet 服务器内网IP 3690，如果通，说明服务本身监听正常,问题在外网或客户端网络。
   • 服务器本机测试：telnet 127.0.0.1 3690 应该看到类似 Connected to 127.0.0.1... 的提示，按 Ctrl+] 再输入 quit 退出，不通？立刻检查下一步服务状态。

🚦 第二关键：SVN 服务状态与配置

网络通了，门开了，但“店”没开好也不行。

1. 确认 svnserve 进程运行：

   ps -ef | grep svnserve

   查看是否有类似 /usr/bin/svnserve -d -r /var/svn 的进程，如果没有,启动它：

   sudo svnserve -d -r /your/svn/repo/parent/directory

   (确保 -r 指定的路径是你的 SVN 仓库的父目录！)

2. 检查启动命令与监听：

   • 监听地址： 默认 svnserve 监听 0.0.0:3690（所有IP），如果启动命令指定了 --listen-host=127.0.0.1，则只能本机连接。确认未错误绑定到 0.0.1。
   • 端口占用：netstat -tulnp | grep 3690 看是否确实被 svnserve 占用，以及监听的地址是否是 0.0.0:3690 或 :::3690。

3. 配置文件 (svnserve.conf): 进入你的 SVN 仓库目录下的 conf 子目录 (如 /var/svn/myproject/conf/svnserve.conf)。

   • anon-access / auth-access: 初期调试，可暂时设置：

     anon-access = read
     auth-access = write

     允许匿名读取（便于测试连接），认证用户可写。生产环境务必收紧权限！

     
   • password-db / authz-db: 确认指向正确的 passwd 和 authz 文件（默认 passwd 和 authz 即可）。
   • realm: 设置一个仓库标识名（如 My Project Repository），修改后重启 svnserve 生效。

🔐 第三核心：用户权限与文件系统权限

服务跑着，网络通着，但“钥匙”不对或“路”不通。

1. 用户认证 (passwd 文件): 在仓库的 conf 目录下，编辑 passwd 文件。

   • 确认你尝试连接的用户名存在且拼写正确（区分大小写！）。
   • 密码格式为 username = password。确保密码前后没有多余空格。
   • 如果使用 htpasswd 生成的密码，格式需为 username:encryptedpassword。

2. 访问授权 (authz 文件): 编辑 authz 文件。

   • 仓库路径： 权限规则作用在仓库内的路径上，不是服务器文件系统路径。

     [/]               # 代表仓库根目录
     user1 = rw       # user1 对根目录有读写权
     user2 = r        # user2 只有读权限
     [/trunk/docs]
     user2 = rw       # user2 对 trunk/docs 有读写权

   • 权限继承： 权限默认从父目录继承，确认用户在其尝试访问的路径上有足够权限 (r 读，w 写)。
   • 用户组： 如果使用组 ([groups])，确认用户被正确添加到组,且组被赋予权限。

3. 文件系统权限 (极易忽略！):

   • 仓库目录权限：svnserve 进程的运行用户（通常是启动它的用户，或 root）必须对 SVN 仓库的整个目录树（包括父目录）拥有 读+执行 (rx) 权限。
   • 关键文件权限： 仓库目录下的 db 子目录及其内容、conf 目录下的 passwd, authz, svnserve.conf 文件，运行用户至少要有 读(r) 权限。
   • 命令检查： 切换到 svnserve 的运行用户 (可用 ps -ef | grep svnserve 第一列查看)，尝试访问仓库目录和读取 conf 下文件：

     sudo -u <svnserve_user> ls -l /your/svn/repo/parent/directory/yourrepo
     sudo -u <svnserve_user> cat /your/svn/repo/parent/directory/yourrepo/conf/svnserve.conf

     如果提示权限不足，用 chown 和 chmod 修正。

     sudo chown -R apache:apache /var/svn/repositories  # 如果运行用户是apache
     sudo chmod -R 750 /var/svn/repositories           # 确保目录有rx，文件有r

     (权限设置需根据安全要求调整，750 是常见起点)

4. SELinux 干扰： CentOS 默认启用 SELinux，它可能阻止 svnserve 访问必要资源。

   • 临时关闭 (测试用)：sudo setenforce 0，如果关闭后连接成功，则问题在 SELinux。
   • 永久方案 (不推荐直接关闭)：
     • 检查审计日志：sudo ausearch -m avc -ts recent 找 denied 记录。
     • 修正 SELinux 上下文：

       sudo restorecon -Rv /your/svn/repo/parent/directory

     • 或添加 SELinux 规则允许 svnserve 网络访问：

       sudo setsebool -P httpd_can_network_connect on  # 如果以apache用户运行常见
       sudo semanage port -a -t svn_port_t -p tcp 3690 # 确保3690端口类型正确

🔍 终极测试与客户端提示

• 服务器端本地连接测试：

  svn co svn://localhost/yourrepo /tmp/testcheckout

  输入正确用户名密码，成功则证明服务本身配置基本OK,问题在外部网络或客户端配置。

• 客户端连接命令： 确认客户端使用的 URL 格式正确：svn://your_server_ip_or_domain/yourrepo (注意是仓库名，不是仓库的完整路径！-r 参数指定的是父目录)。

• 客户端错误信息： 仔细阅读客户端返回的错误信息！“Authorization failed” 指向权限问题；“No repository found” 可能 URL 错误或仓库路径权限问题；“Connection refused” 强烈指向网络或服务未监听。

经验之谈： 十次 SVN 连接故障，九次半源于防火墙（系统或云平台）或文件系统权限配置不当，特别是在云环境，安全组规则是排查的重中之重，权限问题则往往体现在 authz 文件中对仓库路径的理解偏差，以及服务器上实际目录权限未对 svnserve 用户开放，保持冷静，按照网络->服务->权限的链条，结合命令输出和日志（/var/log/messages 或 journalctl -u svnserve 可能有线索）逐层剥离，真相必然浮现，SVN 虽“老”，稳定性毋庸置疑,连接问题几乎总能定位到具体配置环节。