rm -rf este o comandă Bash similară cu DROPComanda SQL. Dacă nu aveți o copie (backup) a tabelului bazei de date, veți pierde toate datele.
rm -rf este o comandă care, atunci când este invocată fără privilegii de root, va elimina toate folderele la care utilizatorul are acces. Când este invocat cu privilegii de root, acesta vă va șterge hard diskul.
Nu am mai avut ghinion să fac greșeala de a rula acest cod pe un server de producție, dar nu toată lumea a fost atât de norocos. Iată câteva rm -rf povestiri interesante pe care s-ar putea să le găsești.
1. Thomas și programul Trash bazat pe CLI
Thomas era în laboratorul său College Unix, lucrând la un proiect intermediar pentru care a fost conectat la un server dintr-un laborator alăturat folosindPuTTY + RealVNC.
Proiectul său a fost simplu: creați un program CLI „trash” care preia o listă de căi de fișiere și le mută într-un~/.trash director. Puteți apoi „golește coșul de gunoi” care execută rm în director. A făcut prima parte și a completat comanda goală.
Cumva a setat variabila greșită care a lăsat calea de eliminare ca / și a avut acces sudo. Nu s-a întâmplat nimic când a rulat codul la început, dar la scurt timp după aceea, a devenit glitchy și a început să afișeze statică. Ctrl + C nu a putut ajuta. Apoi, monitorul s-a golit și s-a deconectat.
Codul lui a rulat un sudo rm-rf / și care a șters toate datele de pe server. Din fericire pentru Thomas, el lucra pe serverul de testare al departamentului și a reușit să recupereze datele de pe discurile de rezervă. Nu și-a pierdut admiterea.
2. O ștergere curată în timpul unei sesiuni de rezervă
Alex a fost administrator de rețea la o companie care a făcut copii de rezervă ale mașinilor lor prin scripturi. Într-o fatidă Vineri, a actualizat scenariul cu textul, rm -rf ${DIRECTERY}/ în loc de rm -rf ${DIRECTORY}/ – actualizarea comenzii la doar rm-rfdeoarece ${DIRECTERY} a devenit un șir gol.
Sesiunea de rezervă a început mai târziu în acea noapte și înainte ca Alex să-și dea seama, toate mașinile din rețea au fost șterse! Din fericire pentru el, compania face copii de siguranță ale fișierelor în fiecare oră, astfel încât nu s-a făcut prea multă pagubă.Cu toate acestea, a fost un weekend plin. Destul de ironic că o sarcină de rezervă ar șterge sistemele, nu?
3. Curățătorul recursiv automat
O dată Eric lucra la un server de fișiere și dorea să curețe automat unele fișiere în fiecare săptămână sau cam asa ceva. Și-a planificat linia și a testat-o cu scopul de a elimina doar fișierele relativ mai vechi. Munca lui se afla într-un singur director, așa că nu credea că ceva ar putea merge prost. Ei bine, a aflat mai târziu că a ghicit greșit.
A rulat următoarea comandă și a funcționat. Apoi, a adăugat manual linia în crontab și atunci a înlocuit din greșeală . cu un / .
găsi . -type f -nume-ctime -60 -exec rm -rf {} \;
Avanzare rapidă până la o săptămână mai târziu și un număr semnificativ de fișiere au dispărut. Ceea ce a fost mai rău este că au fost șterse la ceea ce părea a fi un model aleatoriu, așa că a crezut că compania a fost piratată până când a efectuat o verificare a codului și și-a dat seama că el este hackerul.
Din fericire, a păstrat backup-uri externe în fiecare zi, astfel încât a putut să-și repare greșeala. Din acea zi poți să pariezi că a fost foarte atent cu comenzile pe care le rulează cu privilegii de administrator.
Cele 2 puncte principale existente în poveștile de mai sus sunt 1, verificați întotdeauna codul și posibilul efect rezultat și 2, păstrați întotdeauna copiile de rezervă cât mai actuale pentru că nu știți niciodată când vor veni la îndemână.
Cunoști vreo poveste nebună din experiență sau din altă parte? Distribuiți-le cu noi în secțiunea de comentarii.