Il più grande errore della riga di comando? [chiuso]

Qual è il maggior danno (di qualunque tipo) che tu abbia mai causato con una singola riga di comando errata / errata / sbagliata? Ho cancellato un database del sistema di produzione per errore qualche tempo fa, per esempio, ma sono stato fortunato (ad es. Backup) e non ci sono state perdite permanenti di dati, perdita di denaro, danni alla proprietà ecc.

Ancora più importante (per i voti), cosa fai per assicurarti che non accadrà mai più?

In SQL Server, su un sistema di produzione:

update customer set password = '' <enter>

Il backup più recente era come una settimana fa.

Per mitigare questo, di solito ora scrivo selectprima un'istruzione per assicurarmi di avere la whereclausola corretta, quindi torna indietro e modificala per inserire la setclausola e cambiare l'istruzione in update.

Il più grande errore? Pensando di aver impostato due variabili quando non l'ho fatto. Quindi rm -rf $ VARIABLE / $ VARIABLE2 è diventato rm -rf /. FreeBSD ha recentemente aggiornato il loro strumento rm in modo che rm -rf / non sia più possibile proprio a causa di questo errore!

shutdown -h now 

pensato per la stazione di lavoro locale, ma è stato digitato durante l'accesso tramite ssh sul server di produzione. Da allora ho sempre un nome host nel mio $PS1.

Omettendo -r da un comando di spegnimento. Su un server remoto Dall'altra parte del paese. Senza personale IT nell'ufficio remoto.

L'abbiamo fatto tutti, è quasi come un rito di passaggio in questa fase.

Su un sistema VMS, avevo usato il comando ASSIGN DCL per assegnare nomi logici e volevo RICHIAMARE una precedente riga di comando ASSIGN. Ora, in VMS, hai digitato solo il numero di caratteri di un comando per renderlo inequivocabile. Quindi intendevo scrivere

REC ASS

ma ho scritto per errore

REQ ASS

anziché. REQ era sufficientemente inequivocabile per il comando REQUEST, che trasmette l'argomento a tutti i privati ​​dell'operatore (che erano tutti nell'IT). Quindi l'intero dipartimento ha ricevuto il mio messaggio di trasmissione che era semplicemente "ASS".

Su un sistema Solaris: "killall dataLoader".

'dataLoader' era un'app su cui stavo lavorando. Su Linux, killall funziona come pkill. Invia un segnale ai processi che corrispondono a una stringa fornita come argomento. Su Solaris, killall cerca di uccidere tutto sul sistema che l'utente corrente può uccidere. Ero root.

Una volta, molte lune fa, avevo bisogno di trovare un particolare eseguibile, ma non riuscivo a ricordare il nome completo di esso (ma potevo ricordare alcune delle lettere). Quindi ho pensato di controllare la directory / usr / bin con qualcosa del genere

rm /usr/bin/i*g*

Strano. Non è tornato nulla. Immaginando di aver sbagliato a ricordare la seconda lettera, ho provato di nuovo con

rm /usr/bin/i*

Ancora niente. Dopo aver fatto lo stesso con / usr / local / bin, / usr / sbin e qualsiasi altra cosa in cui immaginavo potesse essere, mi sono reso conto di aver sbagliato a digitare il comando 'ls'.

Non so da dove provenga il brainfart, ma sicuramente non è mai stato un errore.

setup.exe

Era Windows Vista.

Cercare di cambiare la proprietà di tutto in una directory, inclusi i file dot, con:

chown -R user * .*

Indovinate cosa che fa?

Pensato di distruggere / dev / sdb, fortunatamente ho avuto un buon backup aggiornato

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

select * from <File1> join <file2>

Su una scatola di produzione. Nota la mancanza di una onclausola. :-) Entrambe le tabelle erano multi-milioni di tabelle di righe, e questo era su un AS / 400 a metà degli anni '90 dove una volta che era in esecuzione l'SQL non si poteva ucciderlo.

Su uno dei nostri server di produzione dati, una delle mie radici ha digitato:

chmod -R 777 /

Perché stava ottenendo un errore di autorizzazione con alcuni script ...

Poco dopo, la sua chiave privata è stata rimossa da tutti i server e si è occupato del ripristino dei dati da 1 TB sul server di produzione dei dati ...

Il mio preferito erm era quando ero all'università. Stavo costruendo un'applicazione (non ricordo cosa) e siccome non ero root l'avevo costruita

PREFIX=~username/usr/local

Quindi ho potuto installarlo nella mia directory home. Purtroppo è installato in

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

anziché. Naturalmente per eliminarlo come ricominciare ho eseguito

rm -rf ~username

Nella directory di origine.

Mi chiedevo perché ci fosse voluto così tanto tempo ....

:-)

Tuttavia, il peggiore è stato quando stavo lavorando con una stazione di lavoro Solaris e dopo aver completato l'installazione volevamo cancellare la configurazione pronta per la configurazione live. Quindi l'ho giustiziato

sys-unconfig

Accetto il messaggio di avviso e invece di riavviare la macchina e tornare alle "impostazioni di fabbrica" ​​La finestra di xterm diceva semplicemente

connection closed by foreign host.

Morale della storia Non lasciare mai una shell di root aperta su un altro host! MAI!!

Molti anni fa ero a casa a programmare alcune cose in php mentre lavoravo a un progetto con un mio amico che era il manutentore del progetto. Ci stavamo scambiando l'un l'altro in uno sforzo di collaborazione. Scommettiamo sempre avanti e indietro in gioco.

Stavo cercando di far funzionare correttamente l'agente ssh sulla mia macchina mentre facevamo una guerra religiosa tra Perl e PHP. Poi ho menzionato qualcosa sull'agente ssh che ha bisogno di essere valutato (non so perché l'ho detto). Quindi mi ha inviato questo messaggio nel tentativo, così ho pensato, di aiutarmi con il mio problema (tenere presente che sono stato chiamato in causa alla radice):

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

AVVERTIMENTO! NON ESEGUIRE IL COMANDO !!!

Se rimuovi l'Eval ed esegui il comando interno da solo è:

rm -rf /

Mi ci sono voluti tutti e 4 i secondi per notare cosa stava succedendo ma il danno era già stato fatto. Ho dovuto reinstallare il mio sistema operativo. Fortunatamente, nulla del mio lavoro è stato cancellato tranne alcune cose in / etc iirc. Aveva una risata ENORME quando gli ho inviato un messaggio di orrore che mi chiedeva perché lo avesse fatto. Siamo entrambi ingegneri di sistemi a lungo termine. Non pensava che l'avrei eseguito e sarebbe stato più attento a controllarlo prima di fare semplicemente c & p'ing e mi sono solo fidato di lui, quindi non ho nemmeno pensato che stesse giocando. Inutile dire che questa piccola storia arriva continuamente tra noi. Quindi, ho deciso di immortalarlo.

Come ho mitigato questo accadere di nuovo? Non mi fido di nessuno!

Un'altra storia meno interessante è che un paio di anni fa stavo facendo un lavoro su un box mission-critical al lavoro. Avevo alcuni termini aperti a macchine diverse. Avevo bisogno di rimuovere alcune cose superflue in una directory. Beh, mi sono perso nei miei termini e accidentalmente mi è stato detto .nella mia directory locale ma sull'host errato (termine errato) !!. Ho eseguito il comando in / var / lib / mysql invece di / tmp sul server delle applicazioni (termine diverso). Inutile dire che ho cancellato il database di produzione. Fortunatamente, abbiamo avuto un caldo standby a cui siamo passati mentre io e un collega abbiamo ricostruito il primario dai backup e dallo standby. Ci sono volute circa 18 ore per farlo.

Mitigazione: più attento a quali finestre eseguo i comandi prima di eseguirli.

la versione corta

#/bin/bash
$0&
$0

Una volta volevo cancellare un mucchio di file in una directory.

del *.*

Il computer poi disse: "Sei sicuro? [Y / N]" Ho pensato "DI CORSO Sono sicuro, non avrei digitato il comando maledetto altrimenti! Sheesh stupidi computer brontolano ..."

Y <enter>

C:\Windows>_

Um ... WTF? Ho appena cancellato la mia directory di Windows? ....

undelete *.*

In quei giorni di piccoli dischi rigidi sapevo a cosa serviva ogni file in c: \ windows e come si chiamava, ma anche dopo aver cancellato tutto il sistema non era più lo stesso. Ho guadagnato un po 'di rispetto per il prompt "sei sicuro". Solo un po.

Penso che la cosa più stupida che abbia mai fatto sia stata quella di rimuovere la route predefinita dal cluster di firewall esterno - mentre era collegato al mio desktop a oltre cento miglia di distanza.

Fortunatamente è stato in un periodo indicato come tempo di inattività pianificato (per ogni evenienza), ma ciò non mi ha risparmiato il viaggio di andata e ritorno di 200 miglia per andare a riconfigurare il firewall in loco. Inoltre, non ha aiutato il fatto che ciò abbia eliminato i nostri sistemi di produzione esposti a Internet per la durata del mio viaggio e le successive correzioni.

Conosciamo tutti la definizione di un nano-secondo. Un ohno-secondo è ancora più piccolo, ed è il tempo che intercorre tra colpire "invio" e realizzare l'errore.

Prima di due ...

Su una scatola di Solaris avevamo un backup tar di una macchina AIX.

Uno degli sviluppatori ha digitato:

tax xvf AIX_Backup.tar

Ovviamente i percorsi nella tassa erano assoluti e abbiamo finito per creare una nuova distro di unix ... Solarix ... L'unico problema con la distro è che non si è avviato :(

La storia mi ha raccontato:

Un altro ramo chiamato perché il loro PBX locale aveva alcuni problemi. Dopo alcune indagini, abbiamo appreso che hanno aggiornato il loro server, ma non la loro configurazione Asterisk. Quindi, l'amministratore ha deciso di incaricare il responsabile delle filiali di ripetere la configurazione.

Admin: "Ok, ora, digita rm -rf / etc / asterisk"

Guy: "Ok".

Admin: "Ora, digita cp / var / ..."

Guy: "Aspetta, è ancora in esecuzione ..."

Amministratore: ??? ... !!!

rm -rf / some/path 

invece di

rm -rf /some/path 

Fortunatamente non mi è successo ;-)

source ~/.bash_history

La mia intenzione era fonte .bashrc, ma ero troppo frettoloso con tab-complete ...

Qualcosa del genere:

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

Intendevo sda4. Ho cancellato l'intero disco, non solo la partizione :-(

XCOPY è una bestia potente - spietata nella sua esecuzione e ritardata dal fatto che la sua riga di comando arg va al contrario da quella di Window COPY e UNIX cp.

Un paio di giorni fa ho scritto per caso:

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

XCOPY è stato così gentile da sovrascrivere il mio src directory con ... niente! E non ha nemmeno disturbato a mettere i vecchi file nel Cestino.

Oh, e si scopre che XCOPYeffettivamente sovrascrive gli stessi settori sul disco anziché allocarne di nuovi. Ho provato 3 programmi di recupero del disco e il migliore è riuscito a recuperare solo 3 dei 10 file persi. Naturalmente quei 3 file erano solo vshost.exee i suoi amici. Swell!

ha avuto problemi con la rete (su una macchina remota) e volevo solo riavviare l'interfaccia

ifconfig eth0 down && ifconfig eth0 upp

Oggi mi assicuro che qualcuno sia vicino alla macchina prima di provare cose del genere (anche iptables è un buon candidato). E quando non c'era nessuno, una volta ho scritto

sleep 600; reboot

in un altro terminale (schermo), in modo che si riavvierebbe se non riuscissi a ctrl + c il comando entro 10 minuti.

Ho imparato anche da quell'errore (ctrl + c il sonno eseguirà il riavvio) e ora lo uso

sleep 600 && reboot

che mi permetterà di ctrl + c esso.

ifconfig eth0 down

Oops, sono dalla parte esterna di eth0. Il server web è dall'altra parte del mondo, in una stanza chiusa a chiave. Senza accesso alla rete per accedere o riavviare. Una schifezza.

Un cookie gratuito per chiunque possa dirmi perché ero un idiota per aver cercato di rimuovere tutti i file e le directory nascosti in questo modo:

rm -rf. *

Durante la pulizia della mia cartella principale su un server Web di produzione, ho dimenticato di aver collegato simbolicamente la radice Web del server a una posizione nella mia cartella principale. Non pensando, ho eseguito un rm -rf su quella cartella e la prossima cosa che so, la gente sta chiamando che il sito Web è inattivo!

OOPS!

Una volta stavo confrontando i dati in due cartelle e ho eseguito rsync con l'opzione -d (elimina i file sulla destinazione che non sono sulla fonte). E poi ho cambiato sorgente e destinazione quando ho eseguito rsync. Ciò ha eliminato tutti i nuovi file, che volevo fare il backup. Ora ho imparato a eseguire rsync con -n (dry-run).

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

Non ho avuto alcun backup.

C'era una volta (probabilmente System III, ma era tanto tempo fa), era possibile creare un file chiamato *usando il giusto quotazione della shell. Quando ne ho trovato uno nella mia directory home, avevo digitato rm *e avevo il dito sul tasto Invio quando qualcosa mi ha fatto esitare e pensarci ...

La creazione di un tale file per altri utenti era uno scherzo comune.

Se il file si trova lì in una directory, è difficile da mitigare. Il riflesso di digitare il suo nome esattamente comels appena visualizzato è piuttosto forte.

L'altro scherzo (meno dannoso) era quello di nominare i file con uno spazio bianco finale (o solo uno spazio bianco) che erano molto più difficili da rimuovere ...

A causa di una brutta esperienza con la generale debolezza di JBoss dopo un riavvio, mi piace cancellare i file di lavoro di JBoss prima di un riavvio. Normalmente farei:

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

Per proteggermi dal digitare uno dei tanti possibili disastrosi errori, come:

• / Tmp / *
• tmp / *
• hai avuto l'idea

Faccio l'ultimo comando:

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

Poiché l'utente di JBoss troverebbe difficile rimuovere tutti i file critici che non gli appartengono.

In realtà non ho mai fatto questo errore, ma sono al sicuro nel caso in cui lo faccio.