Verificação de consistência Linux, Debian, Wheezy, Aptitude / DPKG

Question

Em uma tentativa estúpida e estúpida de resolver problemas de espaço na minha máquina desktop, eu de propósito excluí o Spotify de /opt antes de perceber que eu poderia removê-lo usando o gerenciador de pacotes. Depois de deletar a pasta, tentei limpar o Spotify usando o aptitude, mas deletar os arquivos em /opt tinha quebrado o gerenciador de pacotes por causa dos arquivos e diretórios esperados, mas ausentes.

Consegui resolver este problema alterando manualmente arquivos de aptidões, limpando o Spotify e reinstalando usando o aptitude sem precisar reinstalar todo o sistema. Agora eu estou preocupado que ainda há "alguma coisa" que pode não ser OK depois que eu fiz alterações manualmente, embora tudo pareça estar bem.

Perguntas: Existem bancos de dados ou arquivos simples sendo mantidos pelo aptitude ou dpkg, onde eu posso executar uma verificação de consistência contra ele e os pacotes instalados para ver se eles estão correlacionados e estão OK?

O software mencionado (dpkg, aptitude, apt- *) tem mecanismos para fazer isso por mim? Eu não consigo ver nenhum nos manuais, mas pensei em perguntar aqui caso alguém conheça um caminho.

aplausos.

    

Answer 1

Você pode ver quase ¹ todos os arquivos de um pacote instalado executando

dpkg -L thatpackage

Ou essa mesma informação está disponível no link - você escolhe um pacote na distribuição necessária e, na página desse pacote, navega na "lista" de arquivos "link em uma linha da tabela correspondente à sua arquitetura de hardware.

Outro pacote que pode ser interessante para você é debsums que é capaz de comparar os arquivos pertencentes para um pacote ou um conjunto de pacotes, como encontrado no sistema de arquivos, com suas somas hash MD5, conforme registrado nos metadados dos pacotes. O uso pretendido é a detecção de adulteração nos arquivos do sistema, mas pode ser usado no seu caso também, eu acho.

¹ Alguns pacotes criam certos arquivos e diretórios dinamicamente, e infelizmente isso não é declarativo: eles fazem isso usando scripts de shell simples nos chamados scripts postinst e postrm , que são chamado pelo gerenciador de pacotes quando certos eventos acontecem no tempo de vida do pacote. Por exemplo, um pacote pode gerar seu arquivo de configuração usando ucf de um modelo privado usando as informações obtidas do usuário durante a fase de configuração do pacote e instale o arquivo gerado em algum lugar na hierarquia /etc .

Esses scripts de "encanamento" pertencentes a um pacote são mantidos sob a hierarquia /var/lib/dpkg/info e possuem nomes correspondentes ao padrão packagename.* . A propósito, as listas dos arquivos instalados por um pacote e a lista de arquivos de configuração mantidos pelo pacote são mantidos na mesma hierarquia nos arquivos nomeados como packagename.list e packagename.conffiles . Este é um detalhe de implementação (use melhor dpkg -L ou dispositivos similares), mas ainda assim…