簡介這份資源面向在銀河麒麟國產(chǎn) Linux系統(tǒng)上需要搭建版本控制服務(wù)的管理員與開發(fā)人員圍繞「從源碼編譯安裝 SVN 環(huán)境」這一實際問題給出一條可落地的完整安裝路線。包中共 1 個 docx 文檔約 202KB以文字步驟與命令片段為主體積小、查閱方便適合作為部署時的對照手冊。內(nèi)容覆蓋預(yù)編譯依賴 apr、apr-util 與 sqlite 的下載與 configure/make 安裝Subversion 源碼編譯/etc/profile 環(huán)境變量配置與 svnserve 版本驗證以及版本庫目錄創(chuàng)建、svnadmin create 建庫等環(huán)節(jié)并說明 svnserve.conf、passwd、authz 三個配置文件的關(guān)鍵項寫法包括匿名訪問關(guān)閉、鑒權(quán)用戶讀寫、用戶口令與群組權(quán)限設(shè)置還涉及服務(wù)啟動與開機自啟腳本、Windows 客戶端訪問地址格式等延伸細節(jié)。已有 2798 人學(xué)習適合需要在內(nèi)網(wǎng)或離線環(huán)境自建 SVN 服務(wù)、希望減少編譯與配置踩坑的讀者參考。1. 銀河麒麟上裝 SVN系統(tǒng)源自帶的版本為什么常常不能直接用一臺銀河麒麟服務(wù)器要接回一套跑了很多年的版本管理流程運維給過來的要求很樸素地址不變、賬號不變、hook 腳本別動。真正動手才發(fā)現(xiàn)系統(tǒng)源里的 subversion 版本和這套流程對不上svnadmin dump出來的東西在兩邊行為不一致鉤子腳本里的路徑假設(shè)也不一樣。老項目維護最怕版本漂移所以我一般不從源里裝而是把 subversion 1.8.14 連同 apr、apr-util、sqlite 一起源碼編譯鎖死在/usr/local/svn這個前綴下。這條路適合兩類人一是在國產(chǎn)化平臺上必須把 svnserve 跑起來、又拿不到合適軟件包的運維二是需要固定版本、機器在內(nèi)網(wǎng)、只能靠 U 盤或跳板機往里傳包的開發(fā)。整個過程不難難的是依賴順序、動態(tài)庫路徑和那三個配置文件里的細節(jié)下面按我實際走通的順序拆。2. 依賴三件套apr、apr-util、sqlite 的編譯順序與參數(shù)怎么定subversion 不是一個能單獨站住的程序。它把文件操作、內(nèi)存池、字符串處理、網(wǎng)絡(luò)收發(fā)幾乎全部壓在 Apache Portable Runtime 上所以 apr 和 apr-util 必須先就位而 1.8 這一支又把 sqlite 的源碼直接塞進自己的構(gòu)建流程里用一份 amalgamation 源碼現(xiàn)場編不依賴系統(tǒng)里的 libsqlite3。三者的關(guān)系是一條鏈順序錯了 configure 就會在探測階段直接退出。2.1 為什么必須先 apr 后 apr-util再輪到 subversionapr-util 的 configure 腳本第一件事就是找 apr 的頭文件和庫找不到就報錯退出。而 subversion 的 configure 會同時找 apr 和 apr-util兩個都齊了才繼續(xù)往下探測。所以順序只能是 apr → apr-util → subversion沒有別的排列。這里還有個容易被忽略的點apr 和 apr-util 的版本要成套。apr-1.6.5 配 apr-util-1.6.1 是同一代的組合跨代混搭時 configure 未必報錯但編譯到一半出現(xiàn)結(jié)構(gòu)體成員不匹配的情況我見過不止一次。手上沒有成套的包就先停下來把版本對齊別硬編。安裝前綴我習慣分開寫/usr/local/apr、/usr/local/apr-util、/usr/local/svn。全都塞進/usr/local看著省事實際是給自己埋雷——頭文件和庫全糊在一起將來想單獨升級或卸掉其中一個根本分不清哪些文件是誰的。# 全程 root源碼包統(tǒng)一放在 /home/dmdba/svn 下 cd /home/dmdba/svn # 1) 編譯 apr只依賴系統(tǒng)自帶的 gcc / make cd apr-1.6.5 ./configure --prefix/usr/local/apr make -j4 make install # 2) 編譯 apr-util--with-apr 指向 apr 的安裝前綴不是源碼目錄 cd ../apr-util-1.6.1 ./configure --prefix/usr/local/apr-util --with-apr/usr/local/apr make -j4 make install--prefix決定make install把東西放到哪后面 subversion 的--with-apr必須和它一字不差。-j4是按 CPU 核數(shù)給的編譯機上核多可以給到 8核少就給 2給太高在內(nèi)存緊張的虛機上會因為 OOM 直接殺掉編譯進程表現(xiàn)成莫名其妙的make: *** [xxx] Killed。2.2 apr-util 的--with-apr寫錯會怎么表現(xiàn)--with-apr后面跟的必須是 apr 的安裝前綴/usr/local/apr不是解壓出來的源碼目錄/home/dmdba/svn/apr-1.6.5。寫成源碼目錄時 configure 有時也能過因為它能在源碼樹里找到apr.h但make install之后 apr-util 里記錄的路徑是錯的等到 subversion 鏈接階段才會以cannot find -lapr-1的形式爆出來。判斷方法很直接configure 跑完看它打印的摘要行./configure --prefix/usr/local/apr-util --with-apr/usr/local/apr 21 | tail -20正常的輸出里會出現(xiàn)checking for apr-config... /usr/local/apr/bin/apr-1-config這樣的行。如果這一行顯示的是源碼目錄或者干脆是no就說明路徑給錯了別急著 make先回去改。另外如果系統(tǒng)里缺 expat 開發(fā)包apr-util 會跳過 expat 支持繼續(xù)編。這對 svnserve 本身影響不大但如果后面要接 Apache httpd 做 http 訪問就會缺 DAV 相關(guān)能力。想一次到位編譯前把expat-devel、zlib-devel、openssl-devel裝上能省掉后面重編 apr-util 的返工。2.3 sqlite-amalgamation 不用編譯但改名和位置是硬約束subversion 1.8.14 的構(gòu)建腳本不調(diào)用系統(tǒng)的 sqlite3而是在源碼根目錄下找sqlite-amalgamation/sqlite3.c這個文件找到之后現(xiàn)場編進去。這個約定非常死目錄名差一個字符都不認。從官網(wǎng)下下來的是sqlite-amalgamation-3071501.zip解壓出來是同名目錄。必須把它挪到 subversion 源碼根目錄下并且改名為sqlite-amalgamationcd /home/dmdba/svn unzip sqlite-amalgamation-3071501.zip # 挪進 subversion 源碼樹并改成構(gòu)建腳本認的名字 mv sqlite-amalgamation-3071501 subversion-1.8.14/sqlite-amalgamation # 確認文件在位這一步別省 ls -l subversion-1.8.14/sqlite-amalgamation/sqlite3.c最后那條ls是我每次都會敲的。少敲這一下等到 subversion 編了十幾分鐘才報sqlite3.c: No such file返工的時間遠比這一行命令貴。2.4 離線傳包與解壓后的目錄規(guī)劃內(nèi)網(wǎng)機器最常見的傳包方式是跳板機 scp 或 U 盤掛載。不管哪種落地之后統(tǒng)一解壓到同一個父目錄路徑才好寫cd /home/dmdba/svn tar -zxvf apr-1.6.5.tar.gz tar -zxvf apr-util-1.6.1.tar.gz tar -zxvf subversion-1.8.14.tar.gz unzip sqlite-amalgamation-3071501.zip ls -d apr-1.6.5 apr-util-1.6.1 subversion-1.8.14 sqlite-amalgamation-3071501四個包解壓后應(yīng)該平級出現(xiàn)在/home/dmdba/svn下這是后面所有cd命令的前提。傳包過程中最怕的是壓縮包被截斷tar -zxvf報unexpected EOF就是這個原因重傳一遍即可別懷疑包本身。提示銀河麒麟的默認 shell 和 coreutils 與新版本發(fā)行版存在差異腳本里凡是涉及通配符和路徑拼接的地方寧可寫全路徑也別依賴相對路徑的推斷。3. subversion 1.8.14 編譯configure 三個--with與 make 中斷的處理依賴齊了之后subversion 這一關(guān)卡人的地方集中在兩個階段configure 的依賴探測和 make 的鏈接階段。前者報錯很干脆一行紅字告訴你缺什么后者往往要滾幾百行才露出真正的原因得會從日志尾部往回翻。3.1 configure 階段依賴探測的三個關(guān)鍵參數(shù)subversion 的 configure 參數(shù)不少真正必須顯式給的就三個安裝前綴、apr 路徑、apr-util 路徑。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 \ 21 | tee /tmp/svn-configure.log三個參數(shù)的含義務(wù)必分清--prefix是自己要裝到哪--with-apr和--with-apr-util是依賴在哪。前一個寫錯裝完找不到命令后兩個寫錯configure 直接報APR not found或APR-UTIL not found然后退出。tee那一段不是多余的。configure 輸出動輒幾百行滾屏之后想回頭找具體是哪個探測失敗只能靠日志。養(yǎng)成把 configure 和 make 的輸出都落一份到/tmp的習慣出問題時grep -i error一下就能定位。configure 順利跑完時末尾會打印一段摘要里面能看到APR、APR-UTIL、SQLite各自的版本和路徑。這一段建議截圖或復(fù)制留存將來排查版本不一致時是唯一的對照依據(jù)。3.2 make 中斷先看這三處不要急著重裝系統(tǒng)make 失敗的原因五花八門但在麒麟上裝 1.8.14 這個組合九成跑不出下面三種第一處sqlite3.c 找不到。前面 2.3 節(jié)說過目錄名和位置不對就會在編譯到 sqlite 那一層時中斷。解決辦法是把sqlite-amalgamation目錄放回 subversion 源碼根目錄并確認文件名。第二處鏈接階段報undefined reference to一串 apr 符號。這基本是 apr-util 編譯時沒真正鏈上 apr回頭重編 apr-util--with-apr指向安裝前綴別指向源碼目錄。第三處編譯器把警告當錯誤。新版 gcc 對某些老代碼的隱式類型轉(zhuǎn)換會給出-Werror級別的提示1.8.14 這樣的老代碼在新工具鏈上偶爾會撞上。這種情況不是代碼壞了是編譯選項太嚴可以在 configure 時加一句放寬# 編譯失敗時先把完整日志留下來再決定怎么改 make -j4 21 | tee /tmp/svn-make.log # 從日志尾部往前找第一個 error而不是從頭讀 grep -n -i error /tmp/svn-make.log | head -20grep出來的第一條 error 往往不是根因真正的根因通常在它上面幾十行。用sed -n 起始行,結(jié)束行p /tmp/svn-make.log把上下文打出來看比一行行往上翻快得多。3.3 動態(tài)庫路徑/etc/ld.so.conf.d里那兩行省不得make install成功不代表能跑。subversion 的可執(zhí)行文件鏈接的是/usr/local/svn/lib下的libsvn_*apr 的庫在/usr/local/apr/lib這些目錄都不在系統(tǒng)默認的庫搜索路徑里。不處理的話svnserve --version會以error while loading shared libraries: libsvn_client-1.so.0收場。正確做法是交給 ldconfig 管理而不是在/etc/profile里堆LD_LIBRARY_PATHcat /etc/ld.so.conf.d/svn.conf EOF /usr/local/apr/lib /usr/local/apr-util/lib /usr/local/svn/lib EOF # 讓新配置生效 ldconfig # 驗證庫是否已被系統(tǒng)識別 ldconfig -p | grep -E libsvn_client|libapr-1三行路徑按依賴順序排列l(wèi)dconfig會把它們加進緩存。用 conf.d 的好處是干凈、可回滾將來升級只需改這一個文件再ldconfig。相比之下往/etc/profile里追加LD_LIBRARY_PATH只對交互式登錄的 shell 生效systemd 拉起的服務(wù)和 cron 任務(wù)讀不到是典型的“手動能跑、開機就掛”。3.4 PATH 生效與svnserve --version的冒煙驗證最后一步是把/usr/local/svn/bin加進 PATH。寫在/etc/profile末尾對所有用戶生效cat /etc/profile EOF # Subversion export PATH$PATH:/usr/local/svn/bin EOF # 當前會話立即生效 source /etc/profile # 三件事一起驗命令找得到、版本對得上、動態(tài)庫加載正常 which svnserve svnserve --version svn --version --quietwhich svnserve應(yīng)該輸出/usr/local/svn/bin/svnserve。如果輸出的是/usr/bin/svnserve說明系統(tǒng)里原本就裝著 subversionPATH 順序不對把/usr/local/svn/bin提到前面或者干脆把系統(tǒng)自帶的卸掉避免兩套混用。svnserve --version會打印版本號和編譯時間同時把依賴的 apr、apr-util、sqlite 版本一并列出來。這一屏信息極其有用后面遇到任何行為異常第一件事就是回來核對這三個版本號。注意svn --version --quiet只輸出版本號適合寫進腳本做版本斷言svnserve --version輸出更全適合人工核對。4. 版本庫與權(quán)限svnadmin create之后的三個配置文件怎么落地服務(wù)能啟動只是開始真正決定這套 SVN 好不好用的是版本庫結(jié)構(gòu)和權(quán)限模型。svnadmin create一條命令就能建庫但它生成的conf目錄里那三個文件任何一個改錯都會讓客戶端連不上而且報錯信息相當不友好。4.1svnadmin create的實際產(chǎn)物與目錄規(guī)劃版本庫根目錄的選擇有講究。放在/home/svn下方便備份但要注意系統(tǒng)安全策略對這個路徑的讀取限制放在/var/svn下更符合常規(guī)權(quán)限管理也更順。我這邊沿用/home/svn因為備份腳本早就按這個路徑寫死了。# 版本庫的父目錄注意這一步只是普通目錄 mkdir -p /home/svn # 項目目錄作為單個版本庫存在 mkdir -p /home/svn/project # 關(guān)鍵一步把普通目錄變成 SVN 版本庫 svnadmin create /home/svn/project # 看它生成了什么 ls -l /home/svn/project執(zhí)行完svnadmin create之后/home/svn/project下會多出conf、db、hooks、locks、format、README.txt。db是 FSFS 格式的實際存儲日常不用碰hooks放提交前后的鉤子腳本老流程里那些“提交后發(fā)郵件”的邏輯就掛在這conf是接下來要改的三個文件所在。有一點要提前說清楚/home/svn是所有版本庫的父目錄/home/svn/project才是一個版本庫。這個層級關(guān)系決定了后面svnserve -r參數(shù)該指到哪搞混了客戶端就會連到空路徑。4.2svnserve.conf四行配置的作用域和頂格規(guī)則conf/svnserve.conf是服務(wù)端的總開關(guān)里面的配置項全部要頂格寫行首不能留空格注釋行用#開頭。這不是格式潔癖解析器對前導(dǎo)空白極敏感行首多一個空格就會導(dǎo)致啟動失敗而且報錯信息只說“配置錯誤”不告訴你是哪一行。[general] anon-access none auth-access write password-db passwd authz-db authz realm /home/svn五行的含義逐條過一遍anon-access none匿名用戶什么都不能做。默認是read意味著不登錄也能看代碼這個默認值在公網(wǎng)環(huán)境是重大風險必須改。auth-access write通過認證的用戶可以讀寫。只想給某些人讀權(quán)限靠下面的 authz 文件控制這一行給write是上限。password-db passwd賬號密碼文件。這里寫的是相對路徑相對于conf目錄所以實際讀的是conf/passwd。authz-db authz權(quán)限控制文件同樣是相對conf的路徑。realm /home/svn認證域。這一行原配置里沒有建議加上。不設(shè)的話客戶端會用默認域緩存憑據(jù)同一臺機器連多個不同 SVN 服務(wù)時賬號密碼會互相覆蓋表現(xiàn)成“密碼明明對卻一直認證失敗”。password-db和authz-db也可以寫絕對路徑。寫絕對路徑的好處是不受conf目錄位置影響壞處是遷移版本庫時要跟著改。我一般保持相對路徑把整個版本庫目錄一起搬走就能用。4.3passwd與authz分組、路徑前綴與匹配順序passwd只管賬號不管權(quán)限格式極簡[users] admin 123456 dev01 123456 dev02 123456等號兩邊可以有空格解析器會裁掉。密碼是明文存儲這一點要有心理準備——conf目錄的權(quán)限必須收緊到700否則同機器上任何用戶都能看到密碼。authz才是真正決定誰能訪問哪里的地方它支持分組、路徑和權(quán)限三元組[groups] g_admin admin g_dev dev01,dev02 [/] g_admin rw g_dev r * 逐段解釋[groups]段定義組。一個用戶可以屬于多個組組名前面加引用。[/]表示版本庫根路徑。注意這個斜杠是相對版本庫根不是文件系統(tǒng)根。如果只想放開某個子目錄寫成[/trunk/docs]這種形式。g_admin rw管理員組讀寫。g_dev r開發(fā)組只讀。* 除上面列出的組之外的所有用戶權(quán)限為空也就是拒絕。這一行必須寫不寫的話未列出的用戶會落到默認策略容易出現(xiàn)“誰都能進”的意外。匹配順序是從具體到寬泛路徑越長的規(guī)則優(yōu)先同一條路徑上用戶規(guī)則的優(yōu)先級高于組規(guī)則。所以給某個特定用戶單獨開權(quán)限時直接把用戶名寫進去比如zhangsan rw它會覆蓋所在組的限制。改完這三個文件不需要重啟服務(wù)svnserve 每次請求都會重新讀配置。這一點很省事但也意味著改錯了會立刻生效改之前先備份一份。4.4svnserve -d -r的-r到底停在哪一層啟動命令是svnserve -d -r /home/svn。-d是守護進程模式-r是版本庫根路徑。關(guān)鍵在于-r要指到所有版本庫的父目錄不是某個具體版本庫# 正確指到父目錄 /home/svn svnserve -d -r /home/svn # 錯誤指到具體版本庫客戶端 URL 會多一層且其他庫訪問不到 # svnserve -d -r /home/svn/project # 確認進程和端口 ps -ef | grep svnserve ss -lntp | grep 3690-r /home/svn之后客戶端訪問地址是svn://服務(wù)器IP/project。如果寫成-r /home/svn/project地址就變成svn://服務(wù)器IP/而且再想加第二個項目就得重啟服務(wù)換路徑。端口默認 3690啟動后必須確認防火墻放行# firewalld 環(huán)境 firewall-cmd --permanent --add-port3690/tcp firewall-cmd --reload firewall-cmd --list-portsps能看到進程但客戶端連不上八成就是防火墻這一層。這個坑后面還會細說。5. 避坑與排查五條在麒麟上真踩過的記錄下面的每一條都是實際遇到的按“現(xiàn)象 → 原因 → 解決”的順序?qū)懹龅酵悊栴}時可以直接對號入座。5.1 啟動即退出日志里只有一行 “Option expected”現(xiàn)象執(zhí)行svnserve -d -r /home/svn后進程沒起來前臺跑一次就輸出svnserve: /home/svn/project/conf/svnserve.conf:12: Option expected然后退出。原因svnserve.conf里某個配置項前面留了空格或制表符。這個文件是 ini 風格解析但解析器對行首空白零容忍。常見的觸發(fā)場景是從網(wǎng)頁或聊天窗口復(fù)制配置粘貼時帶了縮進。解決用cat -A conf/svnserve.conf把所有不可見字符打出來行首出現(xiàn)^I制表符或一串空格的就是元兇。把所有配置項改成頂格注釋行統(tǒng)一用#開頭改完再啟動。養(yǎng)成習慣改完這個文件先cat -A掃一眼再敲啟動命令。5.2 客戶端 Connection refused服務(wù)端ps卻能看到進程現(xiàn)象服務(wù)器上ps -ef | grep svnserve有進程端口也在監(jiān)聽但 Windows 客戶端連svn://192.168.10.20/project報Unable to connect to a repository at URL底層是連接被拒。原因系統(tǒng)防火墻沒放行 3690。另一種情況是svnserve監(jiān)聽在 IPv6 而客戶端走 IPv4ss -lntp的輸出里如果只有[::]:3690而沒有0.0.0.0:3690就是這個原因。解決先放行端口firewall-cmd --permanent --add-port3690/tcp firewall-cmd --reload再確認監(jiān)聽地址ss -lntp | grep 3690應(yīng)能看到0.0.0.0:3690。如果只監(jiān)聽 IPv6檢查/etc/hosts和系統(tǒng)是否禁用了 IPv4 回環(huán)。5.3 密碼沒錯卻一直認證失敗現(xiàn)象客戶端反復(fù)彈認證框輸入admin/123456始終提示認證失敗服務(wù)端日志里沒有明顯報錯。原因最常見的是passwd文件里的用戶名帶了前后空格或者authz里根本沒有為這個用戶配置任何路徑權(quán)限。還有一種隱蔽情況是客戶端緩存了舊憑據(jù)清掉緩存前怎么輸都不對。解決先用svn auth --show-passwords或客戶端自帶的“清除認證緩存”把本地緩存清掉再核對authz里是否有[/]段對這個用戶或所在組授權(quán)最后檢查passwd文件的編碼必須是 UTF-8 無 BOM帶 BOM 時第一行用戶名會解析失敗。5.4 重啟后 SVN 沒起來rc.local里的腳本像沒執(zhí)行現(xiàn)象手動執(zhí)行/root/svn.sh一切正常重啟機器后ps里沒有 svnserve 進程腳本里的日志也沒寫。原因/etc/rc.d/rc.local這個文件在新版系統(tǒng)上默認沒有執(zhí)行權(quán)限systemd 不會去跑它。另一個原因是腳本里寫的是相對路徑svnserve而開機時 PATH 還沒加載到/usr/local/svn/bin。解決chmod x /etc/rc.d/rc.local給上執(zhí)行權(quán)限腳本里改用絕對路徑/usr/local/svn/bin/svnserve -d -r /home/svn。查絕對路徑用which svnserve。更穩(wěn)妥的做法是舍棄 rc.local寫成 systemd 服務(wù)單元下一章展開。5.5svn命令能跑svnserve卻說找不到 libsvn_client現(xiàn)象交互式登錄后svn --version正常但svnserve啟動報error while loading shared libraries: libsvn_client-1.so.0: cannot open shared object file。原因動態(tài)庫搜索路徑?jīng)]配。svn和svnserve鏈接的庫不完全相同前者可能命中了系統(tǒng)自帶的舊庫后者走的是/usr/local/svn/lib。解決按 3.3 節(jié)寫/etc/ld.so.conf.d/svn.conf把三個 lib 目錄列進去執(zhí)行l(wèi)dconfig再用ldconfig -p | grep libsvn確認。改完必須重開一個會話舊會話的環(huán)境變量還是老的。6. 把 svnserve 交給 systemd一次寫對之后不用再碰 rc.localrc.local那套做法在老系統(tǒng)上能用但在麒麟這一類新系統(tǒng)上它依賴“被手動賦予執(zhí)行權(quán)限”這個前提換臺機器部署就得重新記得敲一次chmod x屬于典型的靠人肉記憶維持的配置。我現(xiàn)在的做法是直接寫 systemd 單元一次寫對后面復(fù)制過去就能用。先看單元文件。放在/etc/systemd/system/svnserve.service[Unit] DescriptionSubversion Server Afternetwork.target [Service] Typeforking ExecStart/usr/local/svn/bin/svnserve -d -r /home/svn ExecStop/usr/bin/pkill -f svnserve -d -r /home/svn Restarton-failure RestartSec3 [Install] WantedBymulti-user.target幾個關(guān)鍵點說明一下。Typeforking是因為svnserve -d會自己 fork 到后臺父進程立刻退出systemd 需要知道這一點才不會誤判服務(wù)已死。ExecStart里用的是絕對路徑繞開 PATH 未加載的問題。ExecStop用pkill -f按完整命令行匹配比按進程名殺更精確避免誤傷其他 svn 相關(guān)進程。Restarton-failure加RestartSec3是給自己留的后悔藥——進程意外退出時 3 秒后自動拉起比人肉發(fā)現(xiàn)再登錄處理快得多。啟用和驗證按這個順序走# 重新加載單元文件讓新寫的 service 生效 systemctl daemon-reload # 設(shè)為開機自啟并立即啟動 systemctl enable --now svnserve # 看狀態(tài)重點看 Active 那一行是不是 active (running) systemctl status svnserve --no-pager # 從外部驗證端口真的在監(jiān)聽 ss -lntp | grep 3690systemctl status的輸出里如果出現(xiàn)Active: active (running)說明服務(wù)起來了如果是failed用journalctl -u svnserve -n 50 --no-pager看最近 50 行日志比翻/var/log/messages快得多。服務(wù)起來之后驗證要分三層做別只做最上面一層層次驗證命令通過標準進程與端口ss -lntp | grep 3690顯示0.0.0.0:3690處于 LISTEN服務(wù)端自檢svn info svn://127.0.0.1/project輸出倉庫 UUID 和 Revision客戶端拉取svn checkout svn://192.168.10.20/project /tmp/proj-test檢出成功能提交一次測試文件三層里最容易漏的是第二層。很多人直接拿 Windows 客戶端試連不上時分不清是服務(wù)端問題還是網(wǎng)絡(luò)問題。先在服務(wù)器本機用svn info打一次本機通了再排查網(wǎng)絡(luò)問題范圍立刻縮小一半。最后說個我自己的習慣。每次交付這類環(huán)境我都會把svnserve.conf、passwd、authz三個文件連同 systemd 單元一起打包到版本庫的docs/目錄下寫清楚版本號和改動日期。不是怕自己忘是怕半年后接手的人對著一個跑著的服務(wù)完全不知道它當初是怎么配起來的——這臺機器會變成一個黑匣子。從那以后我每次裝完 SVN都會強制走一遍“本機 svn info → 外部 checkout → 重啟機器再驗一次”這三步缺一步都不算交付完成。希望幫到你。本文還有配套的精品資源點擊獲取