O espelho de reutilização Yum acumula arquivos updateinfo.xml.gz - eles podem ser removidos

1

Eu tenho um número de espelhos de repositórios Redhat YUM, que são atualizados diariamente. Os comandos usados para realizar isso são:

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

As variáveis (i, destdir e fn) são definidas no script que emite os comandos. Isso funciona muito bem, e a equipe tem usado os espelhos com bons resultados.

O problema é que, depois de um ano, um dos repositórios acumulou uma pilha impressionante de arquivos xml updateinfo, com nomes do padrão < hash > -updateinfo.xml.gz: 456MB no diretório superior e 28,45 GB no subdiretório repodata. O repositório contém apenas 4 GB de arquivos de pacotes.

Clientes que fazem um yum makecache neste repo acabam com um arquivo repmod.xml de 4GB.

Minhas perguntas são

  1. Por que esses arquivos se acumulam, embora eu tenha --delete Especificadas.. ?
  2. Posso removê-los sem quebrar o repositório?
  3. Os parâmetros que utilizo são os mais ideais? Queremos espelhar um repo completo, mas apenas a versão mais recente de cada pacote.

EDIT 4/6/2018

Depois de cavar mais fundo, descobri mais algumas dicas de que esses arquivos não são de fato necessários.

Os arquivos < hash > updateinfo.xml.gz no diretório superior do repositório são todos mais ou menos do mesmo tamanho, cerca de 3,8M. Os arquivos no diretório repodata (que é criado / atualizado pelo createrepo) crescem constantemente em tamanho devido a todos os arquivos no diretório principal sendo concatenados.

por exemplo: neste diretório de repodata, eu tenho 129 arquivos gzipados. O primeiro arquivo tem o mesmo tamanho médio dos que estão no diretório principal, o último é enorme e tem 129 tags de atualizações, contra o primeiro apenas 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

Eu acho que o reposync deve remover quaisquer arquivos updateinfo.xml.gz existentes no diretório principal antes que o createrepo seja executado sobre ele. O cliente obtém o arquivo gzipado mais recente do diretório repodata quando faz uma makecache e o descompacta.

Mudei a pilha para um diretório de backup depois de postar a pergunta acima e não vi nenhum efeito adverso nos clientes.

    
por Tony 15.05.2018 / 09:07

1 resposta

0

Respondendo a minha própria pergunta, para documentar isso para os outros.

Agora, estamos praticamente certos de que os antigos arquivos updateinfo.xml são supérfluos para as necessidades. Aparentemente, eles acumulam apenas porque o valor do hash que é prefixado ao nome do arquivo. Com base nisso, fiz algumas alterações e agora o repositório permanece basicamente de tamanho estático.

Em sua forma original, após os comandos reposync e createrepo citados na pergunta, o script executa gunzip seguido por um comando modifyrepo que cria um novo arquivo updateinfo.xml.gz no diretório ../repodata:

  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

Alterei esta seção para:

  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

O comando gunzip descompacta apenas o updateinfo.xml mais recente devido à ordenação inversa no registro de data e hora e no comando tail. Como resultado, o novo arquivo no diretório repodata conterá apenas uma versão. A segunda mudança é excluir todos os arquivos updateinfo.xml antigos, barra 2 (apenas no caso).

Estamos trabalhando com esta versão há vários meses e não notamos nenhum efeito colateral indesejado.

    
por 29.11.2018 / 03:07