☰

Yum repo ミラーには updateinfo.xml.gz ファイルが蓄積されます。削除できますか？

tag-icon • tag-icon yum repository mirror
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）は、コマンドを実行するスクリプトに設定されます。すべてが本当にうまくいき、チームは鏡を使って良い効果を得ました。

問題は、約1年後のリポジトリの1つに名前パターン<hash> -updateinfo.xml.gz：456 MBが最上位ディレクトリにあり、28.45 GBがデフォルトディレクトリにある印象的なupdateinfo xmlファイルスタックが蓄積されたことです。 repodata サブディレクトリ。ストレージには4 GBのパッケージファイルのみが含まれています。

このリポジトリでyum makecacheを実行しているクライアントは、最終的に4 GBのrepmod.xmlファイルを持ちます。

私の質問は

  1. --delete..を指定しても、これらのファイルが蓄積されるのはなぜですか？
  2. ストレージを壊さずに削除できますか？
  3. 私が使用しているパラメータは最適ですか？リポジトリ全体をミラーリングしたいのですが、各パッケージの最新バージョンのみをミラーリングしたいと思います。

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 圧縮ファイルを取得し、解凍します。

上記の質問を投稿した後、スタックをバックアップディレクトリに移動し、クライアントに悪影響を与えません。

答え1

私の質問に答え、他の人のためにこれを文書化します。

今、私たちは、以前のupdateinfo.xmlファイルが私たちのニーズに比べて重複していることをほとんど確信しています。どうやらファイル名の前のハッシュ値のために積み重ねられるようです。これに基づいていくつかの変更が行われ、現在リポジトリのサイズは基本的に同じままです。

元の形式では、質問で参照されているreposyncコマンドとcreaterepoコマンドの後に、スクリプトはgunzipを実行してから../repodataディレクトリに新しいupdateinfo.xml.gzファイルを生成するadjustrepoコマンドを実行します。

  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ディレクトリの新しいファイルには1つのバージョンしか含まれていません。 2番目の変更点は、場合のために以前のすべてのupdateinfo.xmlファイルの2列を削除することです。

私たちはこのバージョンを数ヶ月間使用してきましたが、望ましくない副作用が見つかりませんでした。

関連情報