Não, você não está completamente ferrado, é por isso que aproveitou o tempo para fazer bons backups. Agora basta ir ao seu servidor e restaurá-los.
Durante a manutenção ontem eu cometi um erro ao mover arquivos e ao invés de mv ./* / destination-path, eu digitei mv / * / destination-path ... :( Eu parei o processo de mover no meio e movi arquivos de volta para / e tudo parecia bem.Mas eu fiz o logout e agora não consigo fazer login neste servidor, nem através de ssh, nem no console.
O ssh retorna isso:
MacBook:johns$ ssh -vv root@groom
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to groom [192.168.133.196] port 22.
debug1: Connection established.
debug1: identity file /Users/johns/.ssh/id_rsa type -1
debug1: identity file /Users/johns/.ssh/id_rsa-cert type -1
debug1: identity file /Users/johns/.ssh/id_dsa type -1
debug1: identity file /Users/johns/.ssh/id_dsa-cert type -1
ssh_exchange_identification: Connection closed by remote host
No console físico, recebi:
O0o.oops() [console.c(83)]: Opening console failed
O servidor é pingável e todas as máquinas virtuais executadas sobre ele são acessíveis via ssh.
Estou completamente ferrado?
P.S. Infelizmente não há backups. Este não é um servidor de produção e as únicas coisas valiosas são algumas máquinas virtuais, que estão intactas e em execução. O SO é o CentOS 5.x rodando o Xen e eu tenho acesso do DRAC ao servidor. Eu só preciso encontrar uma maneira de fazer login. Alguma idéia?
Não, você não está completamente ferrado, é por isso que aproveitou o tempo para fazer bons backups. Agora basta ir ao seu servidor e restaurá-los.
É um erro. Nós todos fizemos isso em algum momento. Este pode não ser facilmente recuperável. Você não forneceu detalhes sobre qual era a distribuição / versão do sistema operacional do servidor. Você tem acesso de console ao sistema (ILO, DRAC, VMWare, etc.)?
Mesmo se o colocássemos no sistema, não confiaria na integridade da instalação. Você tem backups?
Um console raiz é uma bazuca carregada. mv , rm , dd e alguns outros comandos têm um arco de mira que passa pelo seu pé. Você puxou o gatilho na hora errada e perdeu uma perna.
Neste ponto, a restauração de backups é sua melhor opção. No futuro você será mais cuidadoso quando estiver operando como root ( realmente pare e leia o que você digitou antes de apertar enter), e se / quando você cometer um erro no futuro, você se lembrará para não sair antes de testar que você pode entrar novamente .
Todas as coisas da vida são uma experiência de aprendizado. Este provavelmente será doloroso. A dor é ótima para reforçar a memória.
Você está em um lugar ruim, sem dúvida. Eu duvido que você seja capaz de voltar para a caixa sem reiniciá-lo. Você poderia dar uma chance a sftp e, dependendo de onde o login está sendo gerado, pode funcionar. Mas eu não contaria com isso.
No ponto de reinicialização, você tem algumas opções. Você pode inicializar com um CD do LiveCD / Rescue e tentar limpar ou migrar coisas de lá, ou pode tentar inicializar com a opção de inicialização adicional init=/bin/bash na linha do kernel. Enquanto o bash estiver disponível, isso permitirá que você entre na caixa (sem serviços em execução e nada iniciado). Mas, você vai chegar a um prompt onde você pode tentar obter o que você precisa.
Minha recomendação seria ir direto para o LiveCD, já que você terá maior funcionalidade e é menos provável que você tenha que lutar contra um sistema quebrado enquanto o corrige. Com o hardware da Dell e o DRAC, você pode montar, acessar e inicializar remotamente a partir de um disco de CD ou imagem ISO localizada em seu computador local, se não tiver acesso físico fácil à caixa.
Esse é um bom exemplo do motivo pelo qual muitas pessoas codinaram rm , mv , cp etc. para rm -i , mv -i e cp -i , respectivamente. Ele oferece uma verificação de sanidade adicional e uma rede de segurança (mínima) para detectar erros simples.
Tags linux