Reconstrua o diretório do sistema danificado (por exemplo, / lib)

4

Digamos que eu tenha um sistema Linux, seja Debian, Ubuntu ou CentOS, onde um usuário removeu /lib , por exemplo. Digamos também que eu consegui inicializar este sistema com uma versão do Liveecd de qualquer sistema operacional que estivesse rodando. É possível executar um comando que irá reconstruir /lib no sistema danificado?

Por exemplo, eu diria que algo assim poderia funcionar, reinstalando todos os pacotes que o sistema de destino tinha em uso.

Eu tive um colega que encontrou essa situação, mas o resultado final foi uma reinstalação completa. No entanto, isso me fez pensar se um reparo é possível e talvez mais rápido?

    
por cat pants 16.04.2014 / 23:58

4 respostas

4

Na maioria dos casos, isso deve ser relativamente fácil de corrigir. Você pode gerar uma lista de todos os pacotes instalados usando o diretório /lib com:

dpkg -S /lib | awk -F': ' '{ print $1 }' | tr -d ,

Se você reinstalar esses pacotes, deverá corrigir o problema:

apt-get --reinstall $(dpkg -S /lib | awk -F': ' '{ print $1 }' | tr -d ,)

Isso, obviamente, depende do diretório excluído não ser crítico para apt-get . Os pacotes necessários para o apt-get funcionar teriam que ser instalados manualmente, talvez até mesmo sem dpkg . Nesse caso, o pacote poderia ser extraído em outra máquina e os arquivos copiados no lugar, eles seriam reinstalados com apt de qualquer maneira, portanto, isso não causaria nenhum outro problema.

Olhando minha própria lista de pacotes colocando arquivos em /lib , vejo que os principais são o kernel (todos os módulos vão para /lib/modules ) e libc . Estes são dois que quase certamente teriam que ser reinstalados para o sistema ser inicializável. Uma maneira de fazer isso seria instalar a partir de um sistema baseado no Debian. Se você baixar os pacotes necessários e montar a raiz do sistema de destino, você pode adicionar a opção --root ao dpkg lá para instalar, por exemplo:

dpkg --root=/path/to/target/root -i package1.deb package2.deb ...

A opção --root também pode ser usada com o primeiro comando dpkg , se necessário. É claro que com paciência e habilidade suficiente, deve ser possível reparar on-line. Se o comando dpkg não funcionar, você sempre poderá procurar as dependências de pacote diretamente em /var/lib/dpkg/info e procurar pacotes colocando arquivos em /lib por meio dos arquivos .list em /var/lib/dpkg/info .

Para dar uma idéia do que pode ser alcançado, aqui está um blog sobre alguém que conseguiu recuperar um sistema Gentoo em execução, onde todos os pacotes foram desinstalados. É uma leitura interessante, e algumas das técnicas usadas (ou sugeridas nos comentários) podem ser aplicadas neste tipo de situação - link

    
por 17.04.2014 / 00:21
1

Na maioria dos casos, acho que, sem um diretório /lib em funcionamento, muitos dos aplicativos necessários para fazer um trabalho de reparo não estarão mais presentes. Eu iria morder a bala e apenas fazer uma reinstalação.

Se você está disposto a tentar de qualquer maneira, então aqui está o que fazer para distribuições baseadas em RedHat.

Para distros baseadas no Redhat, como o CentOS / Fedora / RHEL, você pode usar o RPM para verificar e reparar alguns aspectos dos pacotes instalados.

verificar todos os pkgs

% rpm -qVav
.........    /usr/bin/rdesktop
.........    /usr/share/doc/rdesktop-1.6.0
.........  d /usr/share/doc/rdesktop-1.6.0/AUTHORS
.........  d /usr/share/doc/rdesktop-1.6.0/COPYING
.........  d /usr/share/doc/rdesktop-1.6.0/ChangeLog
.........  d /usr/share/doc/rdesktop-1.6.0/HACKING
.........  d /usr/share/doc/rdesktop-1.6.0/README
.........  d /usr/share/doc/rdesktop-1.6.0/TODO
.........  d /usr/share/doc/rdesktop-1.6.0/ipv6.txt
.........  d /usr/share/doc/rdesktop-1.6.0/keymap-names.txt
.........  d /usr/share/doc/rdesktop-1.6.0/keymapping.txt
...
...

verifica o openssh

% rpm -qVv openssh
.........    /etc/ssh
..?......  c /etc/ssh/moduli
.........    /usr/bin/ssh-keygen
.........    /usr/libexec/openssh
.........    /usr/libexec/openssh/ssh-keysign
.........    /usr/share/doc/openssh-5.5p1
.........  d /usr/share/doc/openssh-5.5p1/CREDITS
.........  d /usr/share/doc/openssh-5.5p1/ChangeLog
.........  d /usr/share/doc/openssh-5.5p1/INSTALL
.........  d /usr/share/doc/openssh-5.5p1/LICENCE
.........  d /usr/share/doc/openssh-5.5p1/OVERVIEW
...
...

corrigir permissões e propriedade

% rpm --setperms {packagename}
% rpm --setugids {packagename}

NOTA: Veja man rpm para mais detalhes sobre -V|--verify output.

Veja este artigo para mais detalhes: link .

    
por 17.04.2014 / 00:31
1

Como outros já disseram, eu provavelmente faria uma reinstalação se isso acontecesse comigo. No entanto, se eu estivesse tentando fazer um reparo, primeiro começaria copiando o diretório /lib de uma instalação ativa para o meu sistema. Se todo o /lib fosse excluído, nada funcionaria inicialmente, nem mesmo o (s) gerenciador (es) de pacotes, portanto, tal passo seria necessário. Então eu iria para o meu gerenciador de pacotes e reinstalaria todos os pacotes com arquivos em /lib que estavam listados como sendo instalados (veja a resposta de Graeme sobre como obter tal lista). Então, como uma limpeza final, eu iria entrar e excluir todos os arquivos /lib copiados da instalação ao vivo que não deveria estar lá; isto é, não corresponde aos arquivos de um pacote instalado.

    
por 17.04.2014 / 13:17
0

Em termos de ser mais rápido, acho que a reinstalação seria. Como você ainda precisaria escolher a paz do sistema pela paz, para não contar o tempo que você levaria para depurar mais tarde alguns problemas que poderiam ser causados por isso, isso levaria mais tempo. Eu sugeriria apenas reconstruir a máquina já que isso definitivamente traria o sistema para um estado estável.

    
por 17.04.2014 / 00:06