Maior erro na linha de comando? [fechadas]

Qual foi o maior dano (de qualquer tipo) que você já causou com uma única linha de comando equivocada / mal digitada / equivocada? Excluí um banco de dados do sistema de produção por engano há um tempo, por exemplo, mas tive sorte (por exemplo, backup) e não houve perda permanente de dados, perda de dinheiro, danos à propriedade etc.

Mais importante (para votar), o que você faz para garantir que isso nunca mais aconteça?

No SQL server, em um sistema de produção:

update customer set password = '' <enter>

O backup mais recente tinha cerca de uma semana.

Para atenuar isso, agora eu normalmente escrevo uma selectdeclaração primeiro para garantir que a wherecláusula esteja correta, depois volto e edite-a para inserir a setcláusula e alterá-la para update.

Maior erro? Pensando que eu tinha definido duas variáveis ​​quando não tinha. Então rm -rf $ VARIABLE / $ VARIABLE2 se tornou rm -rf /. O FreeBSD atualizou recentemente sua ferramenta rm para que rm -rf / não seja mais possível precisamente por causa desse erro!

shutdown -h now 

destinado à estação de trabalho local, mas digitou-a enquanto estava logado via ssh no servidor de produção. Desde então, eu sempre tenho o nome do host no meu $PS1.

Omitindo -r de um comando de desligamento. Em um servidor remoto. Do outro lado do país. Sem equipe de TI no escritório remoto.

Todos nós já fizemos isso, é quase como um rito de passagem nesta fase.

Em um sistema VMS, eu estava usando o comando ASSIGN DCL para atribuir nomes lógicos e queria RECALL de uma linha de comando ASSIGN anterior. Agora, no VMS, você digitou apenas o número de caracteres de um comando para torná-lo inequívoco. Então eu pretendia digitar

REC ASS

mas eu digitei acidentalmente

REQ ASS

em vez de. O REQ foi suficientemente ambíguo para o comando REQUEST, que transmite o argumento para todos os operadores privados (que eram todos em TI). Então todo o departamento recebeu minha mensagem de transmissão que era simplesmente "ASS".

Em um sistema Solaris: "killall dataLoader".

'dataLoader' era um aplicativo em que eu estava trabalhando. No Linux, o killall funciona como pkill. Ele envia um sinal para processos que correspondem a uma sequência fornecida como argumento. No Solaris, mate todos os esforços para matar tudo no sistema que o usuário atual pode matar. Eu era raiz.

Uma vez, muitas luas atrás, eu precisava encontrar um executável específico, mas não conseguia lembrar o nome completo (mas conseguia lembrar algumas letras). Então, pensei em verificar o diretório / usr / bin com algo parecido com isto

rm /usr/bin/i*g*

Estranho. Nada retornou. Achando que acabara de me lembrar da segunda carta, tentei novamente com

rm /usr/bin/i*

Mais uma vez, nada. Depois de fazer o mesmo com / usr / local / bin, / usr / sbin e qualquer outra coisa que imaginei que poderia estar, percebi que estava digitando errado o comando 'ls'.

Não sei bem de onde veio o cérebro, mas definitivamente não é um erro que cometi novamente.

setup.exe

Foi o Windows Vista.

Tentando alterar a propriedade de tudo em um diretório, incluindo arquivos de ponto, com:

chown -R user * .*

Adivinha o que isso faz?

Pretendia destruir / dev / sdb, felizmente eu tinha um bom backup atualizado

dd if=/dev/urandom of=/dev/sda

select * from <File1> join <file2>

Em uma caixa de produção. Observe a falta de uma oncláusula. :-) Ambas as tabelas eram tabelas de vários milhões de linhas, e isso foi em um AS / 400 em meados dos anos 90, onde uma vez que o SQL estava sendo executado, você não podia matá-lo.

Em um dos nossos servidores de produção de dados, uma das minhas raízes digitou:

chmod -R 777 /

Porque ele estava recebendo erro de permissão com alguns scripts ...

Logo depois, sua chave privada foi removida de todos os servidores e ele cuidou da restauração de dados de 1 TB no servidor de produção de dados ...

Meu favorito foi quando eu estava na universidade. Eu estava construindo um aplicativo (não me lembro o quê) e, como não era root, o construí com

PREFIX=~username/usr/local

Para que eu pudesse instalá-lo no meu diretório pessoal. Infelizmente, ele foi instalado no

/home/username/src/app/~username/usr/local

em vez de. Naturalmente para excluí-lo como começar de novo eu executei

rm -rf ~username

No diretório de origem.

Eu me perguntava por que estava demorando tanto ...

:-)

No entanto, o pior foi quando eu estava trabalhando com uma estação de trabalho solaris e, depois de fazer toda a configuração, queríamos limpar a configuração para a configuração ao vivo. Então eu executei

sys-unconfig

Concordou com a mensagem de aviso e em vez de a máquina reiniciar e voltar para "padrões de fábrica" ​​A janela do xterm dizia simplesmente

connection closed by foreign host.

Moral da história Nunca deixe uma raiz aberta em outro host! SEMPRE!!

Muitos anos atrás, eu estava em casa codificando algumas coisas em php enquanto trabalhava em um projeto com um amigo meu que era o mantenedor do projeto. Estávamos conversando em um esforço de colaboração. Nós sempre brincamos de um lado para o outro no jogo.

Eu estava tentando fazer o ssh-agent funcionar corretamente em minha máquina enquanto estávamos tendo uma guerra religiosa entre Perl e PHP. Então mencionei algo sobre o ssh-agent que precisava ser avaliado (não sei por que disse isso). Então ele me enviou esta mensagem em um esforço, assim pensei, para me ajudar com o meu problema (lembre-se de que eu tinha que enraizar):

\# eval $(echo ssh-agent | 
perl -pe 's/h-a/m -r/' | 
perl -pe 's/^ss/r/' | 
perl -pe 's/gent/f \//')

ATENÇÃO! NÃO EXECUTE ESTE COMANDO !!!

SE você remove o eval e executa o comando interno por si só, é:

rm -rf /

Levei 4 segundos para perceber o que estava acontecendo, mas o estrago já estava feito. Eu tive que reinstalar meu sistema operacional. Felizmente, nada do meu trabalho foi eliminado, exceto algumas coisas no / etc iirc. Ele riu muito quando lhe enviei uma mensagem de horror perguntando por que ele fez isso. Nós dois somos engenheiros de sistemas de longo prazo. Ele não achava que eu iria rodar e seria mais cuidadoso em checar antes de simplesmente c & p'ing e eu confiava nele, então nem pensei que ele estivesse brincando. Escusado será dizer que esta pequena história surge o tempo todo entre nós. Então, eu decidi imortalizá-lo.

Como mitiguei isso de acontecer novamente? Eu não confio em ninguém!

Outra história menos interessante é que, alguns anos atrás, eu estava trabalhando em uma caixa de missão crítica no trabalho. Eu tinha alguns termos abertos para máquinas diferentes. Eu precisava remover algumas coisas supérfluas em um diretório. Bem, eu me perdi nos meus termos e acidentalmente me levantei . no meu diretório local, mas no host errado (termo errado) !!. Eu executei o comando em / var / lib / mysql em vez de / tmp no servidor de aplicativos (termo diferente). Escusado será dizer que acabei com o banco de dados de produção. Felizmente, tínhamos uma espera calorosa para a qual passamos, enquanto eu e um colega de trabalho reconstruímos a primária de backups e espera. Isso levou cerca de 18 horas para fazer.

Mitigação: mais cuidado em quais janelas eu executo comandos antes de executá-los.

a versão curta

#/bin/bash
$0&
$0

Uma vez eu quis excluir um monte de arquivos em um diretório.

del *.*

O computador então disse: "Você tem certeza? [S / N]" Pensei: "É claro que não teria digitado o comando danado de outra maneira! Sheesh computadores estúpidos resmungam ..."

Y <enter>

C:\Windows>_

Hum ... WTF? Acabei de apagar meu diretório do Windows? ....

undelete *.*

Naqueles dias de pequenos discos rígidos, eu sabia para que serviam todos os arquivos em c: \ windows e qual era seu nome, mas mesmo depois de desmarcar tudo o sistema nunca mais era o mesmo. Ganhei um pouco de respeito pelo prompt "você tem certeza". Só um pouco.

Acho que a coisa mais estúpida que já fiz foi remover a rota padrão em um cluster de firewall externo - enquanto vpn'ed no meu desktop a mais de 160 quilômetros de distância.

Felizmente, foi em um período designado como tempo de inatividade planejado (apenas no caso), mas isso não me salvou da viagem de ida e volta de 200 milhas para reconfigurar o firewall no local. Também não ajudou que isso eliminou nossos sistemas de produção expostos à Internet durante a minha viagem e a correção subsequente.

Todos nós sabemos a definição de um nanossegundo. Um minuto é ainda menor, e é o tempo entre pressionar 'enter' e perceber seu erro.

Primeiro de dois ...

Em uma caixa Solaris, tínhamos um backup tar de uma máquina AIX.

Um dos desenvolvedores digitou:

tax xvf AIX_Backup.tar

É claro que os caminhos no imposto eram absolutos e acabamos fazendo uma nova distribuição do unix ... Solarix ... O único problema da distribuição é que ela não inicializou :(

A história me contou:

Outra filial ligou porque o PBX local teve alguns problemas. Após alguma investigação, descobrimos que eles atualizaram o servidor, mas não a configuração do Asterisk. Portanto, o administrador decidiu instruir o responsável pelo ramo a refazer a configuração.

Admin: "Ok, agora, digite rm -rf / etc / asterisk"

Cara: "Ok."

Admin: "Agora, digite cp / var / ..."

Guy: "Espere, ainda está em execução ..."

Admin: ??? ... !!!

rm -rf / some/path 

ao invés de

rm -rf /some/path 

Felizmente, isso não aconteceu comigo ;-)

source ~/.bash_history

Minha intenção era source .bashrc, mas eu estava muito apressado com o tab-complete ...

Algo nesse sentido:

sudo dd if=/dev/zero of=/dev/sda

Eu quis dizer sda4. Limpei o disco inteiro, não apenas a partição :-(

XCOPYé uma fera poderosa - impiedosa em sua execução e retardada pelo fato de que seus argumentos de linha de comando são inversos aos do Windows COPYe do UNIX cp.

Alguns dias atrás, escrevi acidentalmente:

xcopy src \path\to\a\new\nonexistent\directory

XCOPYteve a gentileza de sobrescrever meu srcdiretório com ... nada! E também não se preocupou em colocar os arquivos antigos na lixeira.

Ah, e acontece que XCOPYrealmente substitui os mesmos setores no disco em vez de alocar novos. Eu tentei 3 programas de recuperação de disco, e o melhor só conseguiu recuperar 3 dos 10 arquivos perdidos. Claro que esses 3 arquivos eram apenas vshost.exee seus amigos. Inchar!

teve problemas com a rede (em uma máquina remota) e só queria reiniciar a interface

ifconfig eth0 down && ifconfig eth0 upp

Atualmente, garanto que alguém esteja perto da máquina antes de tentar coisas como esta (o iptables também é um bom candidato). E quando ninguém estava lá, eu digitei uma vez

sleep 600; reboot

em outro terminal (tela), para que ele fosse reiniciado se eu não pudesse pressionar Ctrl + c dentro de 10 minutos.

Eu aprendi com esse erro também (ctrl + c o sono executará a reinicialização) e agora eu uso

sleep 600 && reboot

o que me permitirá pressionar Ctrl + C.

ifconfig eth0 down

Opa, eu estou do lado externo do eth0. O servidor da web está do outro lado do mundo, em uma sala trancada. Sem acesso à rede para efetuar login ou reiniciar. Porcaria.

Um cookie gratuito para qualquer um que possa me dizer por que eu era um idiota por tentar remover todos os arquivos e diretórios ocultos da seguinte maneira:

rm -rf. *

Ao limpar minha pasta pessoal em um servidor da web de produção, esqueci que havia vinculado a raiz da web do servidor a um local da minha pasta pessoal. Sem pensar, eu executei um rm -rf nessa pasta e, em seguida, sei que as pessoas estão chamando que o site está inoperante!

OOPS!

Certa vez, eu estava comparando dados em duas pastas e executei o rsync com a opção -d (exclua arquivos no destino que não estão na fonte). E então eu troquei a origem e o destino quando executei o rsync. Isso excluiu todos os novos arquivos que eu queria fazer backup. Agora eu aprendi a executar o rsync com -n (dry-run).

rsync -trvd --stats --progress /destination /source

Eu não tinha backup.

Era uma vez (provavelmente o Sistema III, mas foi há muito tempo), era possível criar um arquivo nomeado *usando a citação correta do shell. Quando encontrei um no meu diretório pessoal, digitei rm *e coloquei o dedo na tecla de retorno quando algo me fez hesitar e pensar sobre isso ...

Criar esse arquivo para outros usuários era uma brincadeira comum.

Se o arquivo estiver em um diretório, é difícil mitigá-lo. O reflexo de apenas digitar seu nome exatamente como lsexibido, é bastante forte.

A outra brincadeira (menos prejudicial) era nomear arquivos com espaço em branco à direita (ou apenas espaço em branco), que eram muito mais difíceis de remover ...

Devido a alguma experiência ruim com falhas no JBoss após uma reinicialização, gosto de limpar os arquivos de trabalho do JBoss antes de uma reinicialização. Eu normalmente faria:

# cd /var/cache/jboss
# rm -rf tmp/* work/*

Para me proteger de digitar qualquer um dos muitos erros desastrosos possíveis, como:

• / tmp / *
• tmp / *
• Você entendeu a ideia

Eu faço o último comando:

# sudo -u jboss rm -rf tmp/* work/*

Como o usuário do JBoss teria dificuldade em remover todos os arquivos críticos que não pertencem a ele.

Na verdade, nunca cometi esse erro, mas estou seguro no caso.