Quali sono i tuoi momenti Unix preferiti * dolorosi

Che ne dici di condividere i tuoi momenti preferiti delle lezioni apprese ?

Ero curioso se chmod 000 /avrebbe funzionato.

Bene, perfettamente. Pochi minuti dopo stavo cercando un CD di salvataggio.

Quando ho iniziato a lavorare come consulente per gli utenti per l'università che frequentavo, mi sono stati concessi sudodiritti limitati per aiutare gli studenti che avevano perso / dimenticato le loro password. sudo passwd <username>era il mio nuovo amico. Un'ora dopo il mio orientamento, la mia curiosità ebbe la meglio su di me e io digitai sudo passwde fissai con orrore la richiesta di una nuova password. Ero un po 'spaventato di ^Cuscirne, pensando (erroneamente, si scopre) che avrei potuto lasciare l'account in questione in uno stato transitorio, quindi ho inserito una password e subito sono salito al piano di consacrazione del secondo dominio del campus SuperUser e ha chiesto se gli sarebbe piaciuto conoscere la password di root del sistema principale.

Sorpreso nessun altro ha ancora menzionato questo:

rm -rf .*

(Durante il tentativo di rimuovere tutti i file e le sottodirectory nascoste, dimenticando completamente che si ripeterà in .e ..)

Makefile:

clean:
    @rm -f * .o

Il che, ovviamente, fa make cleancancellare il codice sorgente anziché solo i file oggetto.

Lezione: utilizzare il controllo versione.

Aveva un amico eseguito :() { :|:&}; :su un server remoto a cui non avevamo accesso alla console. Impossibile riavviarlo, server di produzione completamente bloccato .

Ripartito (su richiesta) per renderlo un po 'più leggibile.

:() # 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 ':'

Potrebbe essere più facile guardarlo come

bomb() { bomb|bomb& }; bomb

Intendevo bene, davvero. Cercando di chmodricorsivamente una directory e ha finito per scambiare ./con /.

Naturalmente come radice, perché solo con la radice si può ottenere il vero dolore (e quindi l'illuminazione).

Ho cancellato la tabella delle partizioni del mio disco principale per errore, pensando di lavorare su un altro disco.

Con scrollback, uso attento df, memoria e fortuna sono stato in grado di ricrearlo esattamente, riscriverlo, riavviare e sperare ... E ha funzionato.

Non proprio il mio momento, ma quello di qualcun altro.

Quando lavoravo in una struttura di ricerca nel campo delle scienze nucleari, utilizzavamo un certo numero di computer SunOS, Ultrix e Linux e i ricercatori dovevano condividere la CPU su quelle macchine. Man mano che i singoli gruppi di ricerca ottenevano le loro borse di ricerca, acquistavano i loro computer, principalmente SparcStation e gestivano autonomamente l'amministrazione del sistema.

SunOS veniva spedito con il desktop OpenView e un buon file manager, ecco come appariva:

La maggior parte dei nostri ricercatori erano in esecuzione come root e più di una volta abbiamo dovuto reinstallare i loro sistemi operativi perché qualcuno aveva deciso di riordinare la directory root e spostare / bin, / etc, / tmp e tutto il resto che ingombrava la vista in il Cestino o qualche sottocartella.

Altri utenti hanno scelto di riordinare la directory / bin e rimuovere qualsiasi comando che non conoscevano.

I fortunati avevano backup, la maggior parte aveva acquistato un'unità a nastro, ma non aveva una tradizione di eseguire i backup da soli.

Dalla metà alla fine degli anni '90, un mio amico e io stavamo discutendo della follia rm -rf *e fino a che punto una scatola di Linux sarebbe andata a male. Siamo entrati nelle librerie collegate staticamente rispetto a quelle collegate dinamicamente e ho ipotizzato che il sistema potesse vivere abbastanza bene senza /libe quindi ho proceduto a rinominarlo sulla mia workstation. Sono successe cose brutte , ma ci sono rimaste diverse finestre della console aperte con cui provare a riparare il danno (l'arresto non era più un'opzione). Nessuno degli editor avrebbe funzionato. È sorprendente gli usi esoterici che puoi trovare per il echocomando.

vie Caps-Lockvs./etc/passwd

1. Collegarsi a una vecchia scatola Solaris usando un vecchio terminale seriale che non aggiorna correttamente lo schermo.
2. su -
3. vi /etc/passwd. Non c'è vipw, e "stiamo solo apportando modifiche minori" comunque.
4. Premi il Caps-Locktasto e non notare.
5. Premi jun paio di volte per scorrere verso il basso. Ignora il fatto che hai appena digitato J("Unisci"), che combina questa riga con la riga successiva. Lo schermo del terminale seriale non si aggiornava correttamente, quindi non hai visto che hai appena combinato le prime 5 linee in una linea Loooooong, corrompendo così i primi 5 utenti ('root', 'daemon', ecc.).
6. Termina le ALTRE modifiche previste per il file, in basso.
7. Salvare il file.
8. Disconnettersi.

L'ho fatto una volta. Sorprendentemente, il sistema è rimasto funzionale per mesi. Cronjobs ha funzionato bene, nessun errore si è distinto nei file di registro.

Non abbiamo riscontrato questo problema fino a quando non abbiamo riavviato il sistema mesi dopo e non è stato possibile accedere alla console. psha mostrato un gruppo di lavori di proprietà dell'UID '0' non dell'utente 'root'.

Non è stato possibile accedere come root, né eseguire suo su -, e sudoin questo riquadro non c'era . Non c'erano unità floppy, il CD-ROM era rotto e nessuna porta USB (quindi nessun CD-ROM esterno). La modalità utente singolo non ha funzionato, perché è necessario digitare la password per root, e questo viene da /etc/passwd.

rm -f * ~

e

rm -rf ${DIR}/

quando DIRnon è stato impostato!

Ricordo di aver provato a inviare una SysRqsequenza di tasti a una macchina remota ...

... ma è stato catturato da quello locale.

Un semplice haltriconoscimento alcuni secondi dopo che non sono su una shell locale e non ho alcuna possibilità di riaccendere il server di produzione.

Lezioni imparate? Il prompt della macchina ora sembra

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

con qualche bel markup rosso ;-)

Il mio momento preferito è stato quando un collega, che è un utente emacs, voleva modificare un file importante.

Perché emacsè troppo da digitare aveva impostato un alias per emacs:

alias em=emacs

Sotto l'influenza di un caffè non sufficiente o troppo, ovviamente ha sbagliato a digitare em...

Bene, questo è solo un altro motivo per usare vi...;)

O un'altra esperienza, come sentirsi davvero stupidi in pochi semplici passaggi che non sembrano così stupidi individualmente.

Primo passo: stabilire un account per il bambino, nel caso in cui voglia usare una scatola Linux. Dagli una password banale, poiché dopo tutto questo è un sistema domestico e non è esposto alla rete.

Passaggio due: attendere che trascorra il tempo, in modo da non ricordare il passaggio uno.

Passo tre: apri la porta SSH nel firewall (in realtà il NAT sul router) per entrare. Dopo tutto, i miei account hanno password abbastanza buone, e non è che ci sia qualcosa di tremendamente prezioso.

Quarto passaggio: ricevi una notifica dall'ISP che c'è una sorta di attività DOS che va su un sito svedese. Supponiamo che siano probabilmente le scatole di Windows, ed esaminale e induriscile.

Passaggio 5: ricevi una notifica dall'ISP che continua. Richiedi alcuni dettagli, ottieni l'indirizzo IP del sito svedese, avvia Wireshark, trova da quale casella proviene l'attacco.

Step sei: ripulisci la scatola di Linux, sentendoti stupido. Trova il login proviene da un indirizzo rumeno. Rimuovi account senza password valide.

Nei laboratori informatici quando ero al college, avevano uno screen saver che simulava un mucchio di palline che galleggiavano avanti e indietro. Hanno tirato su ciascuno con gravità simulata.

Una volta, mentre stavo scherzando con le impostazioni, si è bloccato con l'errore Error: force on balls too great

Una volta stavo sviluppando un driver di dispositivo per Unix. Aveva un problema con il puntatore e durante il test ha iniziato a cancellare la fine di un array nella memoria del kernel. Sono stato lento a individuarlo e non ho premuto immediatamente il pulsante di ripristino. Il driver aveva scarabocchiato tutta la cache del buffer del disco che era stata scaricata sul disco prima di premere reset. Molti blocchi erano inode e directory, e ho finito con un filesystem totalmente distrutto. Penso che siano stati inseriti 6000 file orfani lost+foundprima di arrendermi e reinstallarli. Fortunatamente, questo era solo un sistema di test, non la mia workstation con tutti i miei file su di esso.

Ho cancellato / etc e poi recuperato . Non credo di aver imparato la mia lezione ... Ho dovuto recuperare anche da un cancellato /bin. Sembra accadere quando ho lavorato con a chroot.

L'anno scorso, un mio collega stava usando una delle nostre workstation Linux per creare copie di dischi flash usando il ddcomando. Ha accidentalmente digitato qualcosa di simile al seguente:

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

Quando si rese conto del suo errore, sovrascrivendo il disco rigido della macchina anziché l'unità flash, la macchina era già stata eliminata. Abbiamo dovuto ricostruire la scatola, che per inciso era anche la macchina che ospitava tutte le nostre macchine virtuali di sviluppo al momento ...

Questo è successo a me l'anno scorso. Stavo rimuovendo alcuni file dal server usando una variabile temporanea:

rm -rf ${prefix}*

Indovina un po? La variabile $prefixnon è stata definita!
Potete immaginare il disastro ... ha portato alla cancellazione di alcuni file molto importanti.

Ho quasi rotto Control-Ce sono corso alla CPU per rimuovere il cavo di rete !!

Hahaha sono sicuro che qualcuno lo abbia già fatto ...

Mentre nel mio secondo anno di studi di informatica ci veniva assegnato un compito a casa per scrivere un programma in C che generasse una serie di sottoprocessi forke li facesse comunicare con le pipe in un "cerchio" e capire quale dovesse essere il "leader" ".

All'epoca eravamo ancora abbastanza rumorosi e la maggior parte dei peple non aveva macchine Linux, quindi abbiamo lavorato sui nostri account sul server principale della nostra facoltà (che ospitava anche siti e account ufficiali del personale). La maggior parte delle persone ha scritto bombe a forchetta ad un certo punto del tentativo di fare i compiti. Oltre la metà del mio gruppo ha ottenuto il abusersfile. Quello è stato il carico più alto su quel server in un tempo così lungo :)

Quando la mia Università ha deciso di cambiare la rete wireless per utilizzare l'autenticazione Cisco LEAP proprietaria ...

Inizia una lunga battaglia che si è conclusa abbastanza bene. Ha scritto la documentazione per gli altri che volevano eseguire Linux e avere accesso a Internet. Sei mesi dopo hanno deciso di aggiungere anche il supporto PEAP. schiaffo

È il mio preferito perché ho vinto. L'ho fatto funzionare.

Come root su Solaris,

$ kill -9 1

... e tutto è andato giù.

Il mio amico è stato licenziato per questo motivo.

Ero un assistente di laboratorio per una lezione di Linux. Uno degli studenti mi ha chiamato perché non poteva più su -perché stava ricevendo permission denied. OK, ha sbagliato a ricordare / sbagliato a digitare la password. Riavvia in modalità utente singolo e ripristina. Che cosa?! suANCORA non funziona ?! DEVE inchinarsi alla mia volontà! Quindi riavvio in modalità utente singolo per scoprire cosa ha fatto. Mi sono reso conto che correvachmod -R 777 /var/www/html/drupal-6.19 /

Nota lo spazio tra il nome della directory e la barra finale.

Dopo alcuni minuti di "Non voglio davvero avere la sua reinstallazione, quindi cosa sta facendo e come.", Sono riuscito a scoprire che / bin / su ora aveva i permessi sui file di 777. Questo può anche essere letto come permessi dei file di 0777, che rimuove il bit setuid da /bin/su. Una rapida chmod u+s /bin/sued ero un eroe.

Non così doloroso ... Ma un piccolo momento divertente:

Ho sbagliato lsa digitare sle ho scoperto che l'amministratore di sistema aveva installato qualcosa per questo caso.

(già disponibile nei repository Debian , Ubuntu , Gentoo , ...)

git init
git clean -f

Questo non rimuove il repository. Questo rimuove tutto ciò che non è nel repository.

Dopo aver provato a sbarazzarsi del repository esistente e quindi a riavviare il controllo del codice sorgente (sulla prima versione completata di un progetto), questi due comandi hanno modificato il mio intero codice.

Un'azienda per cui lavoravo aveva il suo prodotto in esecuzione su SCO. Stavo eseguendo il debug sulle applicazioni che rallentavano molto sul nostro server demo e allo stesso tempo c'erano un sacco di clienti che avevano ricevuto una demo / lezione sulle nuove funzionalità in arrivo.

Quindi, ho eseguito l'applicazione che si bloccava, ho fatto le mie cose su di esso per verificare la causa principale, ma poiché era ancora "bloccato", ho cercato di ucciderlo:

pkill -9 mytestapplication

Quello che ho imparato è che pkill non fa esattamente lo stesso su SCO come su linux =)

... In pratica uccide tutto ciò a cui l'utente ha accesso, e con root ... questo è tutto =)

Il mio passaggio da Debian a Ubuntu è iniziato il giorno in cui ho provato a eliminare alcuni file e directory, ovvero scrivere

rm -r /var/tmp/*

Sfortunatamente, ho inserito uno spazio tra "/ var / tmp /" e "*" e, peggio ancora, ero nella radice del filesystem.

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

Per favore, non provarlo a casa!

C'è un trucco per fare l'equivalente di dirnamee basename, rispettivamente, in Bash:

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

Non così divertente quando $pathcontiene una barra finale ...

Avevo due unità installate in un punto e avevo il filesystem di root della seconda unità montato in una directory all'interno /mnt. Ero in quella directory e ho cercato di eliminare varma ho finito per digitare rm -rf /var. Sembrava esserci un istinto che diceva che var doveva essere preceduto da una barra!

Quando ho capito cosa avevo fatto, ho subito colpito Ctrl-Cma era troppo tardi. Il mio rpmdatabase aveva da tempo abbandonato l'edificio. Ho passato anni a riportare tutto alla normalità.

Ora per la parte dolorosa.

Torno in quella directory /mntper riprendere ciò che stavo facendo. Cosa scrivo? Bene, diciamo solo che l'istinto è ricominciato.

Almeno sono stato in grado di ripristinare il sistema molto più velocemente la seconda volta;)