Quais são seus momentos Unix * dolorosos * favoritos

Que tal compartilhar seus momentos favoritos das lições aprendidas ?

Eu estava curioso para chmod 000 /dar certo.

Bem, na perfeição. Alguns minutos depois, eu estava procurando por um CD de resgate.

Quando comecei a trabalhar como consultor de usuários para a universidade em que participava, recebi sudodireitos limitados para ajudar os alunos que haviam perdido / esquecido suas senhas. sudo passwd <username>era meu novo amigo. Uma hora depois da minha orientação, minha curiosidade tomou conta de mim e eu digitei sudo passwde olhei horrorizada a solicitação de uma nova senha. Fiquei um pouco assustado ^C, pensando (erroneamente, ao que parece) que eu poderia deixar a conta em questão em um estado transitório, então digitei uma senha e imediatamente subi as escadas para o domínio sagrado do segundo andar do SuperUser do campus e perguntou se ele gostaria de saber a senha root do sistema principal.

Surpreendido, ninguém mais mencionou este ainda:

rm -rf .*

(Ao tentar remover todos os arquivos e subdiretórios ocultos, esquecendo completamente que ele retornará para .e ..)

Makefile:

clean:
    @rm -f * .o

O que, é claro, faz com que make cleanlimpe seu código-fonte em vez de apenas arquivos de objeto.

Lição: use o controle de versão.

Um amigo rodou :() { :|:&}; :em um servidor remoto onde não tínhamos acesso ao console. Não foi possível reiniciá-lo, completamente congelado, servidor de produção .

Dividido (por solicitação) para torná-lo um pouco mais legível.

:() # Define ':' as a function. Every time we say ':' execute the following code block
{ # Start of code block
    : # Call ':' again. 
    | # Pipe output to...
    : # Another ':' 
    & # Disown process. 
    # All on one line this would read :|:&, 
} # End of code block
; # End definition of ':' as a function
: # Call ':'

Pode ser mais fácil olhar para ele como

bomb() { bomb|bomb& }; bomb

Eu quis dizer bem, eu realmente fiz. Tentando chmodrecursivamente um diretório e acabou trocando ./com /.

Como raiz, é claro, porque somente com a raiz a verdadeira dor (e, portanto, a iluminação) pode ser alcançada.

Limpei a tabela de partição da minha unidade principal por acidente, pensando que estava trabalhando em outra unidade.

Com o scrollback, o uso cuidadoso df, a memória e a sorte, pude recriá-lo exatamente, reescrevê-lo, reiniciar e ter esperança ... E funcionou.

Não é realmente o meu momento, mas o de outra pessoa.

Quando eu trabalhava em uma instalação de pesquisa em ciências nucleares, costumávamos executar vários computadores SunOS, Ultrix e Linux, e os pesquisadores tinham que compartilhar a CPU nessas máquinas. Como grupos de pesquisa individuais obtiveram suas próprias bolsas de pesquisa, adquiriram seus próprios computadores, principalmente SparcStations, e eles mesmos administraram o sistema.

O SunOS costumava ser fornecido com a área de trabalho do OpenView e um bom gerenciador de arquivos, e era assim:

A maioria dos nossos pesquisadores estava rodando como root e, mais de uma vez, tivemos que reinstalar seus sistemas operacionais porque alguém havia decidido arrumar o diretório raiz e movido / bin, / etc, / tmp e tudo o que atrapalhava a exibição. a Lixeira ou alguma subpasta.

Outros usuários optaram por arrumar o diretório / bin e remover qualquer comando que não conheciam.

Os sortudos tinham backups, a maioria havia comprado uma unidade de fita, mas não possuíam a tradição de executar backups.

Em meados do final da década de 90, um amigo meu e eu estávamos discutindo a loucura rm -rf *e em que momento uma caixa do Linux iria falir. Entramos em bibliotecas vinculadas estaticamente versus dinamicamente e eu postulei que o sistema poderia viver muito bem sem /libe, em seguida, passamos a renomeá-lo na minha estação de trabalho. Coisas ruins aconteceram , mas ficamos com várias janelas de console abertas para tentar corrigir o dano (o desligamento não era mais uma opção). Nenhum dos editores seria executado. É incrível os usos esotéricos que você pode encontrar para o echocomando.

vie Caps-Lockvs./etc/passwd

1. Conecte-se a uma caixa Solaris antiga usando um terminal serial antigo que não atualiza a tela corretamente.
2. su -
3. vi /etc/passwd. Não há vipw, e "estamos apenas fazendo pequenas edições" de qualquer maneira.
4. Pressione a Caps-Locktecla e não perceba.
5. Bata jalgumas vezes para rolar para baixo. Ignore o fato de que você acabou de digitar J("Join"), que combina essa linha com a próxima. A tela do terminal serial não estava sendo atualizada corretamente, então você não viu que acabou de combinar as 5 primeiras linhas em uma linha Loooooong, corrompendo os 5 primeiros usuários ('root', 'daemon' etc.).
6. Finalize as OUTRAS edições pretendidas no arquivo, na parte inferior.
7. Salvar Arquivo.
8. Sair.

Eu fiz isso uma vez. Surpreendentemente, o sistema permaneceu funcional por meses. Cronjobs correu bem, nenhum erro se destacou nos arquivos de log.

Não notamos esse problema até reiniciar o sistema meses depois e não conseguimos fazer login no console. psmostrou vários trabalhos de propriedade do UID '0' e não do usuário 'root'.

Não era possível fazer login como root, nem executar suou su -, e não havia sudonessa caixa. Não havia unidade de disquete, o CD-ROM foi bloqueado e nenhuma porta USB (portanto, nenhum CD-ROM externo). O modo de usuário único não funcionou, porque você precisa digitar a senha para root e isso vem /etc/passwd.

rm -f * ~

e

rm -rf ${DIR}/

quando DIRnão foi definido!

Lembro-me de tentar enviar uma SysRqsequência de teclas para uma máquina remota ...

... mas foi capturado pelo local.

Um simples haltreconhecimento, alguns segundos depois, de que não estou em um shell local e não tenho possibilidade de ligar o servidor de produção novamente.

Lições aprendidas? O prompt da máquina agora parece

[ --> root <-- @kompost:/home/echox] #

com uma boa marcação vermelha ;-)

Meu momento favorito foi quando um colega de trabalho, usuário do emacs, queria editar um arquivo importante.

Como emacsé demais digitar, ele havia configurado um alias para emacs:

alias em=emacs

Sob a influência de café insuficiente ou em excesso, ele naturalmente digitou incorretamente em...

Bem, este é apenas mais um motivo para usar vi...;)

Ou outra experiência, como se sentir realmente estúpido em algumas etapas fáceis que não parecem tão estúpidas individualmente.

Etapa 1: estabelecer uma conta para o garoto, caso ele queira usar uma caixa Linux. Dê uma senha trivial, pois, afinal, esse é um sistema doméstico e não está exposto à rede.

Etapa 2: aguarde o tempo decorrido, para que você não se lembre da etapa um.

Etapa 3: abrir a porta SSH no firewall (na verdade o NAT no roteador) para fazer o ssh. Afinal, minhas contas têm senhas muito boas e não é como se houvesse algo tremendamente valioso.

Etapa quatro: receba uma notificação do ISP de que há algum tipo de atividade do DOS indo para um site sueco. Suponha que sejam provavelmente as caixas do Windows e examine e reforce-as.

Etapa 5: receba uma notificação do ISP de que ainda está acontecendo. Peça alguns detalhes, obtenha o endereço IP do site sueco, inicie o Wireshark e encontre de qual caixa o ataque está ocorrendo.

Etapa seis: limpe a caixa do Linux, sentindo-se estúpido. Encontre o logon veio de um endereço romeno. Remova contas sem boas senhas.

Nos laboratórios de informática, quando eu estava na faculdade, eles tinham um protetor de tela que simulava um monte de bolas que flutuavam para frente e para trás. Eles puxaram cada um com gravidade simulada.

Uma vez, enquanto eu estava mexendo nas configurações, ele travou com o erro Error: force on balls too great

Eu estava desenvolvendo um driver de dispositivo para Unix. Ele tinha um problema de ponteiro e, durante o teste, começou a gravar o final de uma matriz na memória do kernel. Eu demorei a perceber isso e não apertei o botão de reset imediatamente. O driver rabiscou todo o cache do buffer de disco, que foi liberado para o disco antes de eu pressionar Reset. Muitos dos blocos eram inodes e diretórios, e acabei com um sistema de arquivos totalmente destruído. Acho que 6000 arquivos órfãos foram colocados lost+foundantes de eu desistir e reinstalar. Felizmente, este era apenas um sistema de teste, não minha estação de trabalho com todos os meus arquivos.

Eu apaguei / etc e depois o recuperei . Acho que não aprendi minha lição ... Também tive que me recuperar de uma excluída /bin. Parece acontecer quando eu estiver trabalhando com um chroot.

No ano passado, um colega meu estava usando uma de nossas estações de trabalho Linux para criar cópias de discos flash usando o ddcomando Ele acidentalmente digitou algo semelhante ao seguinte:

dd if=flash-image.img of=/dev/sda1

Quando ele percebeu seu erro - sobrescrever o disco rígido da máquina em vez da unidade flash - a máquina já estava na mangueira. Tivemos que reconstruir a caixa, que aliás também era a máquina que hospedava todas as nossas VMs de desenvolvimento na época ...

Isso aconteceu comigo no ano passado. Eu estava removendo alguns arquivos do servidor usando uma variável temporária:

rm -rf ${prefix}*

Adivinha? A variável $prefixnão foi definida!
Você pode imaginar o desastre ... resultou em alguns arquivos muito críticos excluídos.

Eu quase quebrei o Control-Ce corri para a CPU para remover o cabo de rede !!

Hahaha, tenho certeza que alguém já fez isso ...

Enquanto no meu segundo ano estudando ciência da computação, recebemos uma tarefa de casa para escrever um programa em C que geraria vários subprocessos forke os faria se comunicar com tubos em um "círculo" e descobrir qual deles deveria ser o "líder". "

Ainda éramos bastante nobres naquela época e a maioria das pessoas não tinha nenhuma máquina Linux, por isso trabalhamos em nossas contas no servidor principal de nossa faculdade (que hospedava sites e contas de funcionários e sites oficiais). A maioria das pessoas escreveu forkbombs em algum momento da tentativa de fazer a lição de casa. Mais da metade do meu grupo chegou ao abusersarquivo. Essa foi a carga mais alta nesse servidor em um tempo muito longo :)

Quando minha universidade decidiu mudar a rede sem fio para usar a autenticação proprietária do Cisco LEAP ...

Começou uma batalha muito longa que terminou bem o suficiente. Escreveu documentação para outras pessoas que queriam executar o Linux e ter acesso à Internet. Seis meses depois, eles decidiram adicionar o suporte ao PEAP também. tapa na cara

É o meu favorito porque ganhei. Eu tenho que trabalhar.

Como raiz no Solaris,

$ kill -9 1

... e tudo deu certo.

Meu amigo foi demitido por causa disso.

Eu era um assistente de laboratório para uma aula de Linux. Uma das alunas me ligou porque ela não podia mais su -porque estava recebendo permission denied. OK, ela não se lembrou / digitou incorretamente a senha. Reinicie no modo de usuário único e redefina. O que?! suAINDA não funciona ?! DEVE curvar-se à minha vontade! Então, eu reinicio no modo de usuário único para descobrir o que ela fez. Eu percebi que ela corriachmod -R 777 /var/www/html/drupal-6.19 /

Observe o espaço entre o nome do diretório e a barra final.

Depois de alguns minutos de "Eu realmente não quero que ela seja reinstalada, então o que isso está fazendo e como.", Consegui descobrir que / bin / su agora tinha permissões de arquivo de 777. Isso também pode ser lido como permissões de arquivo 0777, das quais remove o bit setuid /bin/su. Um rápido chmod u+s /bin/sue eu era um herói.

Não é tão doloroso ... Mas um momento divertido:

Eu mal digitado lscomo sle descobriu que o sysadmin tinha algo instalado para tal caso.

(já disponível nos repositórios Debian , Ubuntu , Gentoo , ...)

git init
git clean -f

Isso não remove o repositório. Isso remove tudo o que não está no repositório.

Depois de tentar se livrar do repositório existente e reiniciar o controle de origem (na primeira versão concluída de um projeto), esses dois comandos desmarcaram meu código inteiro.

Uma empresa em que eu trabalhava tinha seu produto em execução no SCO. Eu estava fazendo uma depuração de aplicativos que ficavam muito lentos em nosso servidor de demonstração e, ao mesmo tempo, vários clientes receberam uma demonstração / palestra sobre os próximos novos recursos.

Então, eu executei o aplicativo que costumava ficar preso, fiz minhas coisas para verificar a causa raiz, mas como ainda estava "preso", tentei matá-lo:

pkill -9 mytestapplication

O que eu aprendi foi que o pkill não faz exatamente o mesmo no SCO e no linux =)

... Basicamente, mata tudo o que o usuário tem acesso, e com root ... isso é tudo =)

Minha mudança do Debian para o Ubuntu começou no dia em que tentei excluir alguns arquivos e diretórios, o que significa digitar

rm -r /var/tmp/*

Infelizmente, inseri um espaço entre "/ var / tmp /" e "*" e, pior ainda, estava na raiz do sistema de arquivos.

root@workstation:/# rm -r /var/tmp/ *

Por favor, não tente isso em casa!

Há um truque legal para fazer o equivalente a dirnamee basename, respectivamente, no Bash:

${path%/*}
${path##*/}

Não é tão engraçado quando $pathcontém uma barra à direita ...

Eu tinha duas unidades instaladas em um ponto e o sistema de arquivos raiz da segunda unidade foi montado em um diretório dentro /mnt. Eu estava naquele diretório e tentei excluir, varmas acabei digitando rm -rf /var. Pareceu surgir algum instinto que dizia que var deveria ser precedido de uma barra!

Quando percebi o que tinha feito, bati imediatamente, Ctrl-Cmas já era tarde demais. Meu rpmbanco de dados já havia saído do prédio há muito tempo. Passei séculos voltando ao normal.

Agora, a parte dolorosa.

Volto a esse diretório /mntpara retomar o que estava fazendo. O que eu digito? Bem, digamos que o instinto entrou em ação novamente.

Pelo menos eu fui capaz de restaurar o sistema muito mais rápido na segunda vez;)