企业官网建设流程全解析

简介：面向在银河麒麟操作系统中自建SVN版本控制服务的中高级运维人员与项目管理员，这份资料以Word文档形式提供完整的源码安装流程。正文以subversion-1.8.14、apr-1.6.5、apr-util-1.6.1、sqlite-amalgamation-3071501的版本选择为起点，先交代下载地址与解压方式，再逐项说明configure编译参数、make install安装、/etc/profile环境变量写入、svnadmin create建库，以及svnserve.conf、passwd、authz三文件的权限与口令配置；文档同时给出版本库目录规划、服务启停等关键环节的校验方式，便于分阶段排错。对易错环节也有专门提醒，如配置首行不可留空、svnserve路径尽量写绝对地址、/root/svn.sh加入rc.local实现开机自启，并附Windows客户端访问地址写法。包体为单个docx文件，压缩包约202KB，命令和配置示例均可直接对照使用。已有2788人学习下载，适合希望通过一份文档快速完成银河麒麟SVN环境部署并减少排错时间的实操型读者。

1. 银河麒麟上的SVN：源码编译是绕不开的一条路

在一台银河麒麟服务器上装SVN，听起来就是yum install subversion一条命令的事，但真正上手后会发现问题没那么简单：默认软件源里的subversion版本老旧，而且经常缺依赖；更麻烦的是，如果需要在内网环境离线部署，或者要跟老版本客户端保持协议兼容，官方源未必能满足需求。这种情况下，源码编译安装就成了最可控的路径。这篇实战笔记面向的是需要在麒麟系统上自建SVN服务器的运维或开发，我会把从下载源码、编译安装、初始化版本库到配置权限、设置开机自启的完整链路走一遍，顺便把那些文档里不会写的坑一并交代了。

2. 编译安装全流程：apr、apr-util、Subversion 的依赖顺序与 configure 参数

2.1 为什么必须手动编译 apr 和 apr-util

Subversion 从 1.7 开始就完全依赖 APR（Apache Portable Runtime）库来处理文件系统操作和网络通信，这套库它自己不带，必须预先装好。在很多 Linux 发行版上，可以用包管理器直接安装 apr 和 apr-util 的开发包，但在银河麒麟这种环境下，常见做法还是从源码编译，因为这样可以把库装到自定义目录，避免污染系统默认的 /usr/lib，后续卸载也更简单。

需要明确一个关键点：apr 和 apr-util 是两个独立的源码包，apr-util 依赖 apr 的安装结果，所以编译顺序不能乱。整个链路的正确顺序是：apr → apr-util → subversion。如果把顺序颠倒，configure 阶段就会报错说找不到 apr。

2.2 下载源码包：版本选择与校验

在开始编译之前，先把所有需要的源码包下载到同一台机器上。这里以 subversion 1.8.14 为例，这个版本在兼容性和稳定性之间比较均衡，适合内网环境长期运行。

# 在用户目录下创建统一的工作目录 mkdir -p /home/dmdba/svn && cd /home/dmdba/svn # 下载 apr 和 apr-util（以 1.6.5 / 1.6.1 为例） wget https://archive.apache.org/dist/apr/apr-1.6.5.tar.gz wget https://archive.apache.org/dist/apr/apr-util-1.6.1.tar.gz # 下载 subversion 1.8.14 wget http://archive.apache.org/dist/subversion/subversion-1.8.14.tar.gz # 下载 sqlite amalgamation（subversion 1.8 编译时需要） wget http://www.sqlite.org/sqlite-amalgamation-3071501.zip

这里要注意 sqlite 这个包。subversion 1.8 的编译过程需要 SQLite 的 amalgamation 源码文件，但它是用来编译进 subversion 内部的，并不需要单独安装到系统里。下载完以后，把 zip 解压，等到 configure subversion 时直接用--with-sqlite参数指向解压目录里的sqlite3.c文件即可。

2.3 编译安装 apr：prefix 参数决定一切

apr 的编译是三段式里最简单的一步，但 prefix 的设定会影响后面 apr-util 和 subversion 的 configure 路径，所以最好一次想清楚。这里把 apr 安装到/usr/local/apr，与系统自带的任何 apr 分开。

cd /home/dmdba/svn/apr-1.6.5 ./configure --prefix=/usr/local/apr make && make install

这段命令的逻辑是：--prefix=/usr/local/apr指定 apr 安装的根目录，所有头文件、库文件、可执行文件都会装到这个目录下。make负责把源码编译成二进制，make install把编译产物复制到 prefix 指定位置。整个过程中如果出现make报错，多半是系统缺少编译工具链，先执行yum install gcc gcc-c++ make补上。

2.4 编译安装 apr-util：必须显式指定 apr 的路径

apr-util 是 apr 的扩展库，它本身不包含完整的 APR 功能，而是提供数据库连接池、XML 解析等扩展能力。所以 configure 时必须通过--with-apr告诉它 apr 装在哪里。

cd /home/dmdba/svn/apr-util-1.6.1 ./configure --prefix=/usr/local/apr-util --with-apr=/usr/local/apr make && make install

这一步最常见的翻车点是--with-apr路径写错。如果安装时赋给 apr 的 prefix 是/usr/local/apr，但这里写成了/usr，configure 就会在/usr/include下找不到apr_pools.h之类的头文件，直接中断。另一个容易踩的坑是，apr-util 在 configure 时还可能检查expat库——这是 XML 解析依赖，在麒麟系统上通常已经默认安装，如果没有，需要先yum install expat-devel。

2.5 编译安装 subversion：--with-sqlite 是隐藏的关键参数

subversion 的编译参数稍微多一点，除了要指定 apr 和 apr-util 之外，还必须给出 sqlite3.c 的路径。这里用到的 sqlite amalgamation 是单个 C 文件，由其源码自动生成，subversion 会把它编进自己的 FSFS 存储后端里。

# 先解压 sqlite，并记住解压目录 cd /home/dmdba/svn unzip sqlite-amalgamation-3071501.zip cd /home/dmdba/svn/subversion-1.8.14 ./configure \ --prefix=/usr/local/svn \ --with-apr=/usr/local/apr \ --with-apr-util=/usr/local/apr-util \ --with-sqlite=/home/dmdba/svn/sqlite-amalgamation-3071501/sqlite3.c make && make install

configure 的过程会比较长，正常会输出一串 checking ... 的检查项。如果某一个依赖缺失，configure 会在最后明确提示缺少什么，常见的如APR not found、sqlite amalgamation not found，按提示修复即可。编译完成后，/usr/local/svn/bin下应该有svn、svnserve、svnadmin三个核心可执行文件。

这里要专门提醒一句：--with-sqlite指向的一定是sqlite3.c文件本身，不是它的目录，也不是sqlite3.h。很多人在这里写错，configure 报Cannot find sqlite3.c之后才发现路径指错了。

2.6 环境变量配置与安装验证

编译安装完成后，需要把/usr/local/svn/bin加进 PATH，这样直接在命令行敲svn就能调起客户端工具，不用每次带全路径。

echo 'PATH=$PATH:/usr/local/svn/bin' >> /etc/profile source /etc/profile which svn svnserve --version

source /etc/profile的作用是让当前 shell 立即读取最新的环境变量配置，而不用重新登录。验证时先which svn确认 PATH 生效，再用svnserve --version检查服务端程序是否正常。如果版本信息能正常打印，说明编译安装这一步就算全部完成了。

3. 建库与权限模型：svnserve.conf、passwd、authz 三个文件的逐项配置

3.1 版本库目录结构与 svnadmin create 的使用

编译安装只是把 SVN 的服务端程序准备好，真正要跑起来还需要创建版本库。SVN 本身不强制要求目录结构，但这里采用一个统一根目录下放多个独立版本库的方式，后续扩展和维护都更方便。

mkdir -p /home/svn/project svnadmin create /home/svn/project

svnadmin create会在 project 目录下生成一个完整的版本库骨架，里面包括conf/（配置文件目录）、db/（存储数据的目录）、hooks/（钩子脚本目录）等。创建完成后检查一下 conf 目录，里面有svnserve.conf、passwd、authz三个默认文件，这是接下来要重点操作的三个文件。

svnadmin是 SVN 的管理工具，与svnserve（服务进程）和svn（客户端）是不同的组件。create子命令专门用于初始化新库，日常维护还会用到svnadmin verify来校验库的完整性。

3.2 svnserve.conf：先认清 anon-access 与 auth-access 的差异

svnserve.conf 是 SVN 服务端最核心的配置文件。这里有一个经常被误解的点：anon-access是控制匿名用户权限的，auth-access是控制已验证用户权限的，两者独立生效。如果只想让匿名用户完全不可访问，必须明确写anon-access = none，而不是留空或注释掉。

[general] anon-access = none auth-access = write password-db = passwd authz-db = authz realm = project

使用 vi 编辑时，很多人都会在这个文件上翻车，原因在于 SVN 对格式要求比较严格。[general]组下面的每一项配置，等号两边有没有空格都可以，但配置项名称必须顶格写，行首不能留空格，更不能有不可见的 BOM 标记。realm是版本库的认证域名称，会在客户端连接时显示，帮助用户区分要连接的是哪个库，建议设置成有辨识度的项目名。

3.3 passwd：用户名与密码的格式陷阱

passwd 文件用来定义 SVN 用户和密码，格式非常简洁，但有一个细节容易被忽略：密码支持明文，也支持用{SHA}之类的方案做摘要存储，但明文密码对格式更敏感，行尾多一个空格都会导致认证失败。

[users] admin = 123456 dev_liu = abc123

这里定义了两个用户：admin 和 dev_liu，等号左边是用户名，右边是密码。需要注意，passwd 文件里的用户是 SVN 自己的用户体系，与操作系统用户完全独立，不需要跟系统用户一一对应。在实际项目里，常见做法是给每个项目成员建一个独立账号，而不是大家共用同一个，这样在版本库历史里才能清晰区分操作者。

另外，passwd 文件的权限建议设置为 600（仅所有者可读写），不要图省事用 777。某些 SVN 版本对配置文件的权限有过检查，权限过宽会导致服务启动时拒绝加载配置，这一点在后面的避坑章节里会专门展开。

3.4 authz：路径级别的读写权限控制

authz 是 SVN 的权限控制文件，支持按用户、按组、按路径设置读写权限。它的概念模型相对简单，但实际配置里容易写出冲突的规则。

[groups] g_admin = admin g_dev = dev_liu [/] @g_admin = rw @g_dev = r * = [/project] @g_admin = rw @g_dev = rw

这段配置的含义是：在[groups]段定义了 g_admin 和 g_dev 两个组；[/]表示对版本库根目录设置权限，g_admin 组有读写权限，g_dev 组只有读权限，* =表示其他任何用户都无权限。[/project]是对 project 目录单独授权——这里用(rw)给 g_dev 组开放了写权限，实现"根目录只读、特定目录可写"的细分控制。

* =这一行等于号后面是空的，表示拒绝所有未明确授权的用户访问。如果不想做这个限制，可以注释掉这一行，但默认情况下建议保留，避免匿名用户或新加用户意外获得根目录访问权。权限匹配的顺序是：先匹配具体路径，再回退到上级路径，最后命中*规则。所以[/project]的规则会覆盖[/]下 g_dev 的只读权限，实现更细粒度的控制。

3.5 启动 svnserve：-d 与 -r 参数的正确理解

配置全部就绪后，就可以启动服务了。svnserve 的启动参数有两个关键选项：-d表示以守护进程方式在后台运行，-r指定版本库的根目录。

svnserve -d -r /home/svn

启动后验证一下进程是否正常存在：

ps -ef | grep svnserve

注意-r参数的路径只到/home/svn，而不是具体的/home/svn/project。因为在-r模式下，客户端访问的 URL 是svn://服务器IP/project，路径中的project会被映射到根目录下的同名目录；如果-r直接指定成/home/svn/project，客户端 URL 就要写成svn://服务器IP/，缺少项目名后面对多库管理很不方便。

这里还有个容易混淆的点：svnserve -d -r /home/svn启动后，客户端访问的路径是相对根目录的。如果后来又建了一个新库/home/svn/other_project，客户端直接访问svn://IP/other_project即可，不需要重启 svnserve。

4. 常见问题排查：字符集、权限与配置文件的三类翻车现场

4.1 svnserve.conf 首行留空格导致配置不生效

使用 vi 编辑 svnserve.conf 时，如果文件第一行不小心按了空格或 Tab，SVN 服务在读取配置时会报错svnserve.conf: 第1行: 选项期望一个字符串，同时服务启动失败或读取不到后续配置。

原因：SVN 的配置解析器要求配置项必须顶格写，行首空白字符会被当作非法前缀，SVN 对格式的容忍度比 Linux 下其他 ini 配置低得多。

解决：把光标移到第一行行首，连续按x删除空格，然后:wq保存。如果文件已经带 BOM 头，最稳妥的办法是:set nobomb去掉 BOM 再保存。

4.2 编译时报 apr-util 找不到、APR 版本不匹配

编译 subversion 时，configure 报错/usr/local/apr/bin/apr-1-config: No such file or directory。

原因：最常见的是 apr-util 安装时--with-apr参数没有指向 apr 的 prefix 路径，导致 apr-util 的 config 文件里记录的是一个无效路径。也有可能是 apr 编译时装到了/usr/local/apr，但 subversion 的--with-apr-util参数写成了/usr/local/apr-util之外的其他目录。

解决：回到 apr-util 目录重新 configure，确认--with-apr=/usr/local/apr中的路径真实存在。如果还不放心，直接检查/usr/local/apr/bin/apr-1-config文件是否存在，确保它存在后再重新编译 subversion。这种情况我一般会建议把三个源码包全部删除重新编译，因为 apr-util 的 config 文件里记录了编译时的绝对路径，路径一旦错，后续很难只靠参数修正。

4.3 客户端连接超时但服务端进程正常

svnserve 进程已经起来了，ps -ef也能看到，但客户端用svn://协议访问时提示连接超时。

原因：绝大多数情况是系统防火墙没有放行 TCP 3690 端口。银河麒麟默认使用 firewalld 管理防火墙规则，svnserve 默认监听在 3690，如果该端口未放行，外部流量会被拦截。另一种可能是-r参数指向的根目录本身不存在，导致服务端虽然启动但无法正确解析客户端请求路径。

解决：先确认监听端口，执行netstat -tlnp | grep 3690查看进程是否正常绑定。然后添加防火墙例外规则：

firewall-cmd --permanent --add-port=3690/tcp firewall-cmd --reload

如果客户端与服务器在同一台机器上测试，先绕过防火墙因素，用svn://localhost/project连接，能通就确定是端口放行的问题。遇到这种问题，我一般会同时检查/etc/sysconfig/iptables（如果系统用 iptables）和 firewalld 两条线，避免排查方向跑偏。

5. 开机自启与 Windows 端验证：脚本化部署的收尾细节

5.1 自启脚本的绝对路径陷阱

SVN 服务搭好后，最怕的就是服务器重启后 svnserve 没起来，项目成员开始报抱怨连不上。银河麒麟的开机自启沿用传统的 rc.local 机制，但有个细节：rc.local 的执行环境很干净，不会加载登录 shell 的 PATH，所以脚本里必须使用 svnserve 的绝对路径。

#!/bin/bash # svn 自启动脚本 /usr/local/svn/bin/svnserve -d -r /home/svn

把这个脚本保存为/root/svn.sh，然后赋予执行权限并加入开机启动：

chmod +x /root/svn.sh echo '/root/svn.sh' >> /etc/rc.d/rc.local chmod +x /etc/rc.d/rc.local

脚本里/usr/local/svn/bin/svnserve是绝对路径，而不是直接用svnserve -d -r /home/svn，原因前面说了，rc.local 执行阶段环境变量未必包含/usr/local/svn/bin。查 svnserve 绝对路径可以先用which svnserve确认，再把全路径写进脚本。另外，/etc/rc.d/rc.local本身也需要可执行权限，否则系统启动时不会执行它。

5.2 重启后快速验证：进程检查与端口探测

重启服务器后，很多人直接去看进程，却发现ps -ef | grep svnserve输出一片空白，于是判定自启失败。这里建议用两个步骤联合验证：

# 第一步：检查进程是否存在 ps -ef | grep svnserve | grep -v grep # 第二步：检查端口是否已监听 netstat -tlnp | grep 3690

如果进程不存在，但端口在监听，说明服务可能以别的名字或方式启动；如果进程和端口都不在，先检查/etc/rc.d/rc.local的权限和脚本本身的执行权限，再看脚本里有没有写绝对路径。实际操作中，我发现很多自启失败不是因为脚本内容写错，而是忘了给 rc.local 加执行权限。

5.3 Windows 客户端访问与版本库状态检查

从 Windows 客户端验证是最直观的收尾方式。TortoiseSVN 安装后，在资源管理器里右键选择 SVN Checkout，输入：

svn://服务器IP/project

正常情况下会弹出认证窗口，输入之前配置的 admin 账号密码，就能连上。如果认证失败，优先检查 passwd 文件里有没有多余空格或者密码被误改；如果访问被拒绝，看 authz 文件里用户的权限设置。

服务器端还可以用一个快速命令检查版本库健康状态：

svnlook youngest /home/svn/project

svnlook youngest会返回版本库中最新的版本号。如果返回 0 或空，说明库是新建的但还没有任何提交；如果返回错误，说明库目录结构损坏，要考虑svnadmin verify做完整性检查。在项目正式使用前，我一般会先提交一个初始文件测试，确认写入正常后再对外放行。

其实整个链路跑通后你会发现，最耗时间的往往不是编译本身，而是三个配置文件里那些看不见的空格和权限问题。从那以后我每次搭 SVN 都会强制走一遍三件事：编译后先svnserve --version验环境、配置后先svn://localhost本地测通、重启前先chmod +x检查脚本权限。这套流程看起来多花了五分钟，但省掉的是后面反复排查的半天。希望这份笔记能帮你少走这些弯路。

本文还有配套的精品资源，点击获取