Gerando um registro do estado de gerenciamento de pacote completo (-ish)

Question

Estou prestes a fazer algumas alterações no sistema e gostaria de ter um registro do estado atual do meu sistema feliz. Existe uma maneira conveniente de criar um registro disso? Gostaria de acompanhar informações como

• pacotes atualmente instalados e suas versões
• quais pacotes são fixados em qual versão
• qual fonte (como em /etc/apt/sources.list ) eles foram instalados de
• se eles foram instalados diretamente ou instalados automaticamente como uma dependência de um pacote diferente
• "desconhecidos desconhecidos": ou seja, coisas que eu não sei que eu deveria estar acompanhando, mas que podem ser importantes ao tentar descobrir por que algo não funciona

Em suma, gostaria de manter o máximo possível do banco de dados de aptidão. Qual é a melhor forma de fazer isso? Seria bom se os registros resultantes fossem facilmente legíveis, embora isso não seja realmente essencial. Seria muito bom se fosse facilmente editável através de uma ferramenta SCM como git .

Existe um sistema pergunta sobre o superusuário que parcialmente responde, mas apenas fornece a lista de pacotes atualmente instalados.

atualizar

Com base na resposta de @ ptman, determinei o seguinte:

• A última sugestão do @ ptman, fazendo o backup de /etc/apt e /var/lib/... , realizaria um subconjunto do que aptitude-create-state-bundle faz.
• apt-cache policy parece dar informações prioritárias, então eu preciso de algo mais abrangente; aptitude-create-state-bundle parece ser o ticket. No entanto, seria útil ter alguma maneira de analisar o pacote para obter informações como as fornecidas por apt-cache policy .

Eu iniciei um repositório do git (usando o setgitperms.perl hook util) que contém o conteúdo extraído de aptitude-create-state-bundle , por exemplo, eu faço

sudo aptitude-create-state-bundle --force-gzip /dev/stdout | sudo tar xzv

para criar o conteúdo do diretório antes de executar git add . && git add -u . . É meio lento, já que está comprimindo e descompactando tudo, eu provavelmente o alterarei para obter a listagem de arquivos com a opção --print-inputs e então copiar ou vincular esses arquivos no repositório do git.

Essa abordagem funciona muito bem: depois de executar git gc --aggressive , acabo com um diretório .git que é 2/3 do tamanho do tarball original. Isso foi feito após um segundo commit que registrou o estado depois de instalar puppet e suas dependências. É muito fácil ver o que mudou apenas visualizando o diff, que é uma maneira simples de descobrir o que o aptitude realmente faz ao executar operações. Eu acho que há alguma maneira de estabelecer ganchos no próprio apt (à la etckeeper), então eu posso acabar usando essa facilidade para manter o repositório atualizado com todas as operações do apt.

Uma preocupação menor é que mesmo com o hook setgitperms habilitado, os timestamps não são registrados por este sistema. Então, eu adicionei um segundo comando ao meu gancho pré-commit para despejar um longo diretório listando um arquivo chamado .ls no diretório raiz do repositório:

find * | xargs -d \n ls -ld >.ls

Não tenho certeza se isso é realmente necessário, estou apenas fazendo isso no caso de aptitude-run-state-bundle usar os timestamps de alguma maneira relevante. Alguém sabe se isto é verdade? Mesmo assim, parece improvável que seja necessário, já que os registros de data e hora dos arquivos com check-out sempre serão pelo menos tão novos quanto os timestamps originais desses arquivos quando eles foram confirmados.

Vou continuar fazendo as coisas assim, pelo menos até ter a chance de descobrir o que o puppet faz e como usá-lo.

atualização 2

Eu tenho usado esse sistema, mas parece estar ficando um pouco difícil, já que o repositório .git está crescendo rapidamente. Depois de 12 commits, o diretório .git (após a compactação usando git gc --aggressive ) cresceu em tamanho de um tamanho inicial de (IIRC) 15-20 MB para cerca de 60 MB.

Parece que a maior parte do volume parece ser devido a diffs em dois grandes arquivos binários (~ 15MB), e eu estou querendo saber se esses arquivos são necessários para a preservação do estado de empacotamento do sistema. Esses arquivos são:

var/cache/apt/pkgcache.bin
var/cache/apt/srcpkgcache.bin

Será possível restaurar o repositório usando aptitude-run-state-bundle se esses arquivos não estiverem presentes no tarball? Seria possível adicionar as versões atuais do sistema ao tarball para permitir que o tarball seja usado por aptitude-run-state-bundle (supondo que as versões atuais do sistema não estejam corrompidas, é claro)?

    

Answer 1

Confira as seguintes ferramentas:

dpkg --get-selections
aptitude-create-state-bundle
dpkg -l
dpkg -l |tail -n +6 | awk '{ print $2 }' | xargs apt-cache policy

Backup /etc/apt e /var/lib/{apt,dpkg,aptitude} .

    

Answer 2

Use o boneco . Usando essa ferramenta, você pode consultar um sistema e fazer uma lista de seu estado atual. Essa lista pode então ser usada para clonar o sistema. É como um buildout, exceto para servidores.