Yum repo 鏡像累積 updateinfo.xml.gz 文件 - 可以刪除它們嗎

我有許多 Redhat YUM 儲存庫的鏡像，它們每天都會更新。用於完成此操作的命令是：

reposync --repoid=${i} --download_path=${destdir}  --gpgcheck -l --download-metadata --downloadcomps --newest --delete

createrepo -s sha256 --checkts --update --workers=4 -g $destdir/$fn/comps.xml

變數（i、destdir 和 fn）在發出命令的腳本中設置。這一切都很好，團隊一直在使用鏡子取得良好的效果。

問題是，大約一年後，其中一個儲存庫積累了令人印象深刻的 updateinfo xml 文件堆棧，其名稱模式為 <hash>-updateinfo.xml.gz：頂部目錄中有 456MB，而在目錄中有 28.45GB。 repodata 子目錄。該儲存庫僅包含 4GB 的封包件。

在這個 repo 上執行 yum makecache 的客戶端最終會得到一個 4GB 的 repmod.xml 文件。

我的問題是

1. 為什麼這些文件會累積，即使我指定了 –delete .. ？
2. 我可以在不破壞儲存庫的情況下刪除它們嗎？
3. 我使用的參數是最優的嗎？我們想鏡像一個完整的 repo，但只鏡像每個包的最新版本。

編輯 2018 年 4 月 6 日

經過更深入的探勘，我發現了更多提示，這些文件實際上不是必需的。

儲存庫頂層目錄中的 <hash>updateinfo.xml.gz 文件大小差不多，大約 3.8M。repodata 目錄中的文件（由 createrepo 創建/更新）的大小不斷增長，因為頂層目錄中的所有文件都被連接在一起。

例如：在這個 repodata 目錄中，我有 129 個 gzip 文件。第一個文件的平均大小與頂層目錄中的相同，最後一個文件很大，有 129 個更新標籤，而第一個只有 1 個。

# l -tr
total 29G
-rw-r--r-- 1 root root 3.5M Sep 28  2016 6f9c8bca09bb360b0ac2c18231168d45aa6ef51254fee7b791c6d09693677f4c-updateinfo.xml.gz
...
-rw-r--r-- 1 root root 465M May 17 03:21 1696bec0516791660751bb4a319b287f2a3a5ecfee086aefb73285f07cad3ac5-updateinfo.xml.gz
drwxr-xr-x 3 root root  20K May 22 12:37 ../
# gzip -dc  1696bec0516791660751bb4a319b287f2a3a5ecfee086aefb73285f07cad3ac5-updateinfo.xml.gz >updateinfo-big.xml
# gzip -dc  6f9c8bca09bb360b0ac2c18231168d45aa6ef51254fee7b791c6d09693677f4c-updateinfo.xml.gz >updateinfo.xml
# grep '<updates>' updateinfo.xml |wc -l
1
# grep '<updates>' updateinfo-big.xml |wc -l
129
# ls -1 *updateinfo.xml.gz|wc -l
129
# l updateinfo*
-rw-r--r-- 1 root root 2.4G Jun  4 17:09 updateinfo-big.xml
-rw-r--r-- 1 root root  18M Jun  4 17:10 updateinfo.xml

我猜 reposync 應該在 createrepo 執行之前刪除頂層目錄中的所有現有 updateinfo.xml.gz 文件。客戶端在執行 makecache 時從 repodata 目錄獲取最新的 gzip 壓縮文件，然後將其解壓縮。

在發布上述問題後，我已將堆棧移動到備份目錄，並且沒有看到對客戶端的不利影響。

回答我自己的問題，為其他人記錄這一點。

我們現在幾乎可以確定舊的 updateinfo.xml 文件對於需要是多餘的。顯然，它們的累積只是因為文件名前面的雜湊值。基於此，我進行了一些更改，現在儲存庫的大小基本上保持不變。

在原始形式中，在問題中引用的 reposync 和 createrepo 命令之後，腳本執行 gunzip 後跟一個 modifyrepo 命令，該命令在 ../repodata 目錄中創建一個新的 updateinfo.xml.gz 文件：

 if  [ -n "$(/bin/ls -t $destdir/$fn/*updateinfo.xml.gz 2>/dev/null)" ]; then
    gunzip -c $(/bin/ls -t $destdir/$fn/*updateinfo.xml.gz) > $destdir/$fn/updateinfo.xml 2>> $LOGFILE
    modifyrepo $destdir/$fn/updateinfo.xml $destdir/$fn/repodata  >> $LOGFILE 2>&1
 fi

我將此部分更改為：

 if  [ -n "$(/bin/ls -t $destdir/$fn/*updateinfo.xml.gz 2>/dev/null)" ]; then
    gunzip -c $(/bin/ls -tr $destdir/$fn/*updateinfo.xml.gz|tail -1) > $destdir/$fn/updateinfo.xml 2>> $LOGFILE
    modifyrepo $destdir/$fn/updateinfo.xml $destdir/$fn/repodata  >> $LOGFILE 2>&1

    # clean up old update info - keeping only the 2 most recent files.
    for i in $destdir/$fn $destdir/$fn/repodata; do
        for j in `/bin/ls -t ${i}/*updateinfo.xml.gz|tail -n +3`; do
           echo "removing security file "$(ls -l ${j}) >> $LOGFILE
           /bin/rm -f ${j} >> $LOGFILE 2>&1
        done
    done
 fi

由於時間戳和 tail 命令的反向排序，gunzip 命令僅解壓縮最新的 updateinfo.xml。因此，repodata 目錄中的新文件將只包含一個版本。第二個更改是刪除所有較舊的 updateinfo.xml 文件，欄 2（以防萬一）。

我們已經使用這個版本執行了幾個月，沒有發現任何不需要的副作用。

引用自：https://unix.stackexchange.com/questions/443863