En büyük komut satırı hatası? [kapalı]

Tek bir yanlış / yanlış yazılmış / yanlış yönlendirilmiş komut satırında şimdiye kadar verdiğiniz en büyük zarar (ne tür)? Örneğin, bir üretim sistemi veritabanını yanlışlıkla geri sildim, fakat şanslıydım (yani yedeklenmiş) ve kalıcı veri kaybı, para kaybı, mülk hasarı vb.

En önemlisi (oy için), bir daha asla olmayacağından emin olmak için ne yaparsın?

SQL server'da, bir üretim sisteminde:

update customer set password = '' <enter>

En yeni yedek bir haftalık gibiydi.

Bunu hafifletmek için, şimdi selectilk önce wherecümleyi doğru yaptığımdan emin olmak için ilk önce bir bildiri yazıyorum , sonra geri dönüp bu setmaddeyi ekleyip deyimi değiştirmek için düzeltiyorum update.

En büyük hata? Düşünmediğimde iki değişken koyduğumu düşünüyorum. Böylece rm -rf $ VARIABLE / $ VARIABLE2, rm -rf / oldu. FreeBSD kısa süre önce rm aracını güncelledi, böylece rm -rf / bu hata nedeniyle tam olarak mümkün değil!

shutdown -h now 

yerel iş istasyonu için tasarlandı, ancak üretim sunucusunda ssh aracılığıyla oturum açarken yazdı. O zamandan beri her zaman benim ana bilgisayar adı var $PS1.

-R'yi bir kapatma komutundan çıkarmak. Uzak bir sunucuda. Ülkenin diğer tarafında. Uzak ofiste BT personeli yok.

Hepimiz yaptık, bu aşamada neredeyse bir geçiş ayinine benziyor.

Bir VMS sisteminde, mantıksal isimler atamak için ASSIGN DCL komutunu kullanıyordum ve önceki bir ASSIGN komut satırını GERİ ALMAK istedim. Şimdi, VMS'de, komutun açık olmasını sağlamak için yalnızca bir komutun birçok karakteri yazdınız. Bu yüzden yazmak istedim

REC ASS

ama yanlışlıkla yazdım

Req ASS

yerine. REQ, operatör ayrıcalığına sahip olan herkesi (IT'deki herkes) tartışmayı yayınlayan REQUEST komutu için yeterince belirgindi. Böylece tüm bölüm, benim "sadece ASS" olan yayın mesajımı aldı.

Solaris sisteminde: "killall dataLoader".

'dataLoader' üzerinde çalıştığım bir uygulama. Linux'ta killall pkill gibi çalışır. Argüman olarak verilen bir dizgeyle eşleşen işlemlere bir sinyal gönderir. Solaris'te, mevcut kullanıcının öldürebileceği sistemdeki her şeyi öldürmeyi dener. Ben kökündüm.

Bir zamanlar, birçok ay önce, belirli bir çalıştırılabilir dosyayı bulmam gerekiyordu ancak isminin tam adını hatırlayamıyordum (ancak birkaç harfini hatırlayabiliyordum). Böylece / usr / bin dizinini böyle bir şeyle kontrol edeceğimi düşündüm.

rm /usr/bin/i*g*

Garip. Hiçbir şey geri dönmedi. İkinci mektubu daha önce yanlış hatırladığımı düşündüm, tekrar denedim.

rm /usr/bin/i*

Yine, hiçbir şey. / Usr / local / bin, / usr / sbin ile aynı şeyi yaptıktan ve içinde olabileceğini düşündüğüm herhangi bir şeyi yaptıktan sonra, 'ls' komutunu yanlış yazdığımı fark ettim.

Beyin fırtınasının nereden geldiğini tam olarak bilmiyorum, ama kesinlikle bir daha yaptığım bir hata değil.

setup.exe

Windows Vista’ydı.

Nokta dosyaları da dahil olmak üzere bir dizindeki her şeyin sahipliğini değiştirmeye çalışıyorum:

chown -R user * .*

Tahmin et ne olduğunu mu?

/ Dev / sdb'yi imha etmek istemiştim, neyse ki iyi bir yedekleme yaptım

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

select * from <File1> join <file2>

Bir üretim kutusunda. Bir onmaddenin eksikliğine dikkat edin . :-) Her iki masa da multi-milyon satırlık masalardı ve bu, 90'lı yılların ortalarında bir AS / 400'deydi ve SQL bir kez çalıştığında onu öldüremedi.

Veri üretim sunucumuzun birinde köklerimden biri şöyle yazıyor:

chmod -R777 /

Çünkü bazı senaryolarda izin hatası alıyordu ...

Bundan kısa bir süre sonra, özel anahtarı tüm sunuculardan kaldırıldı ve veri üretim sunucusundaki 1 TB veri geri yüklemesine özen gösterdi ...

Benim favorim üniversitedeykendi. Bir uygulama inşa ediyordum (ne olduğunu hatırlamıyorum) ve kök olmadığım için onu oluşturdum

PREFIX=~username/usr/local

Böylece onu ev dizinime yükleyebilirim. Ne yazık ki içine yüklü

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

yerine. Doğal olarak yeniden başlattıktan sonra silmek için idam

rm -rf ~username

Kaynak dizinde.

Neden bu kadar uzun sürdüğünü merak ettim ....

:-)

Ancak en kötüsü, solaris iş istasyonuyla çalışırken ve tüm kurulumları yaptıktan sonra yapılandırmayı canlı yapılandırma için hazır hale getirmek istedik. Bu yüzden idam

sys-unconfig

Uyarı mesajı kabul edildi ve makine yeniden başlatılıp yerine "fabrika varsayılanlarına" geri dönüyordu.

connection closed by foreign host.

Hikayenin ahlaki Asla başka bir ana bilgisayarda kök kabuğu bırakma! HİÇ !!

Yıllar önce, projenin sorumlusu olan bir arkadaşımla bir proje üzerinde çalışırken php'de bazı şeyleri kodluyordum. İşbirliği çabası içinde birbirimize IM' yapıyorduk. Biz her zaman oyunda ileri geri şaka yapıyoruz.

PHP’de dini bir Perl savaşı çekerken ssh-agent’ın makinemde düzgün çalışmasını sağlamaya çalışıyordum. Sonra ssh-acentası hakkında değerlendirilmesi gereken bir şeyden bahsettim (neden bunu söylediğimden emin değilim). Sonra bana bu mesajı bir çaba ile gönderdi, bu yüzden, sorunumda bana yardım etmeyi düşündüğümü düşündüm.

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

UYARI! KOMUTAN ÇALIŞMAYIN !!!

Değerlendirmeyi kaldırır ve iç komutu kendi başına çalıştırırsanız:

rm -rf /

Neler olduğunu farketmem 4 saniyemi aldı, ancak hasar çoktan bitmişti. İşletim sistemimi yeniden kurmak zorunda kaldım. Neyse ki, / etc iirc içindeki bazı şeyler dışında işimden hiçbir şey silinmedi. Ona neden yaptığını soran bir korku mesajı gönderdiğimde kocaman bir kahkaha attı. İkimiz de uzun vadeli sistem mühendisiyiz. Koşacağımı ve basitçe c & p'ing yapmadan önce kontrol etmek için daha dikkatli olacağını düşünmüyordu ve ona güvenmiştim, o yüzden oynamayı bile düşünmemiştim. Söylemeye gerek yok, bu küçük hikaye aramızda her zaman gelir. Böylece ölümsüzleştirmeye karar verdim.

Bunun tekrar olmasını nasıl azalttım? Ben kimseye güvenmiyorum!

Daha az ilginç olan bir hikaye ise birkaç yıl önce işte kritik bir görev kutusunda biraz iş yaptığımdı. Farklı makinelere açık bir kaç terim vardı. Bir dizindeki gereksiz şeyleri kaldırmam gerekiyordu. Eh, şartlarımda kayboldum ve yanlışlıkla çektim . benim yerel dir ama yanlış ana (yanlış terim) !!. Komutu uygulama sunucusunda / var / yerine / var / lib / mysql dizininde (farklı terim) yürüttüm. Söylemeye gerek yok, üretim veritabanını sildim. Neyse ki, ben ve bir meslektaşım birincil olanı yedeklemelerden ve bekleme modundan yeniden inşa ederken çevrilen sıcak bir bekleme durumumuz vardı. Bu yapmak için yaklaşık 18 saat sürdü.

Azaltma: çalıştırmadan önce hangi pencereleri çalıştırdığımı bilmemize dikkat edin.

kısa versiyon

#/bin/bash
$0&
$0

Bir keresinde bir dizindeki dosyaları silmek istedim.

del *.*

Bilgisayar ardından "Emin misiniz? [Y / H]" dedi ben "! Sheesh aptal bilgisayarlar Emin, aksi takdirde ağ örme yazılı komutla olmazdı ediyorum DERSİN düşünce homur ..."

Y <enter>

C:\Windows>_

Um ... WTF? Windows dizinimi yeni mi sildim?

undelete *.*

Küçük sabit disklerin o günlerinde, c: \ windows'daki her bir dosyanın neye benzediğini ve adının ne olduğunu biliyordum, ancak her şeyi sildikten sonra bile sistem asla aynı değildi. "Emin misin" sorusuna biraz saygı duydum. Sadece biraz

Sanırım yaptığım en aptalca şey, dışa bakan güvenlik duvarı kümesindeki varsayılan rotayı kaldırmaktı; vpn ise yüzlerce mil öteden masaüstüme geldi.

Neyse ki, planlanan aksama süresi olarak belirlenmiş bir dönemdeydi (sadece durumda), ancak bu durum güvenlik duvarını yerinde gidip yeniden yapılandırmak için 200 mil turu kurtarmamı sağladı. Ayrıca seyahat sürem boyunca internete maruz kalan üretim sistemlerimizi ve sonrasında yapılan düzeltmeleri almamıza da yardımcı olmadı.

Hepimiz bir nano saniyenin tanımını biliyoruz. Bir saniye, daha da küçüktür ve “enter” a basmakla hatanızın farkına varmak arasındaki zamandır.

İkiden ilk ...

Bir Solaris kutusunda, AIX makinelerinin katran yedeklerini aldık.

Yazılan Geliştiricilerden biri:

tax xvf AIX_Backup.tar

Elbette vergideki yollar mutlaktı ve biz unix'in yeni bir dağıtımını yaptık ... Solarix ... Dağıtım ile ilgili tek sorun önyükleme yapmadığıdır :(

Hikaye bana anlattı:

Yerel PBX’in bazı sorunları olduğu için bir başka şube daha çağırdı. Bazı araştırmalardan sonra, sunucularını güncellediklerini, ancak Asterisk konfigürasyonlarının olmadığını öğrendik. Böylece, yönetici, şube görevlisine yapılandırmayı tekrar yapması talimatını vermeye karar verdi.

Yönetici: "Tamam, şimdi, rm -rf / etc / asterisk yazın"

Guy: "Tamam."

Yönetici: "Şimdi, cp / var / ..." yazın.

Guy: "Bekle, hala çalışıyor ..."

Yönetici: ??? ... !!!

rm -rf / some/path 

yerine

rm -rf /some/path 

Neyse ki bana olmadı ;-)

source ~/.bash_history

Niyetim kaynak .bashrc idi, ama tab-complete ile çok acelem vardı ...

Bunun çizgisinde bir şeyler:

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

SD4 demek istedim. Sadece bölümü değil tüm diski sildim :-(

XCOPYgüçlü bir canavardır - idamında acımasızdır ve komut satırının argümanlarının Window'lardan COPYve UNIX'lerden tersine gitmesi geriliği nedeniyle geciktirir cp.

Birkaç gün önce yanlışlıkla şöyle yazdım:

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

XCOPYdizimi üzerine yazacak kadar kibardı src... hiçbir şey! Eski dosyaları Geri Dönüşüm Kutusu'na koymak da zahmete girmedi.

Oh, ve XCOPYaslında yeni olanları tahsis etmek yerine diskteki aynı sektörlerin üzerine yazdığı ortaya çıktı . 3 disk kurtarma programı denedim ve en iyisi kaybedilen 10 dosyanın sadece 3'ünü kurtarabilirdi. Tabii ki bu 3 dosya sadece vshost.exeve arkadaşlarıydı. Kabarma!

ağda sorun yaşandı (uzaktaki bir makinede) ve arayüzü yeniden başlatmak istedim

ifconfig eth0 down && ifconfig eth0 upp

Günümüzde, böyle şeyleri denemeden önce birinin makineye yakın olduğundan emin olun (iptables da iyi bir adaydır). Kimse yokken, bir kere yazdım

sleep 600; reboot

başka bir (ekran) terminaline, böylece 10 dakika içinde komutu ctrl + c yapamazsam yeniden başlatacaktı.

Ben de bu hatayı öğrendim (ctrl + c, uyku yeniden başlatılacak) ve şimdi kullanıyorum

sleep 600 && reboot

bu da ctrl + c ile çalışmamı sağlayacak.

ifconfig eth0 down

Üzgünüz, eth0’un dış tarafındayım. Web sunucusu dünyanın öbür tarafında, kilitli bir odada. Oturum açmak veya yeniden başlatmak için ağ erişimi yok. Bok.

Tüm gizli dosyaları ve dizinleri bu şekilde kaldırmaya çalışırken neden aptal olduğumu söyleyebilen herkese bedava bir çerez:

rm -rf. *

Bir üretim web sunucusundaki ana klasörümü temizlerken, sunucunun web kökünü ana klasörümdeki bir yere bağladığımı unuttum. Düşünmüyorum, bu klasörde bir rm-rf koştum ve bildiğim bir sonraki şey, insanlar web sitesinin kapalı olduğunu söylüyorlar!

Oops!

Bir keresinde iki klasördeki verileri karşılaştırıyordum ve -d seçeneğiyle rsync kullandım (kaynaktaki hedef üzerindeki dosyaları sil). Ve sonra rsync'i çalıştırdığımda kaynak ve hedef arasında geçiş yaptım. Yedeklemek istediğim tüm yeni dosyaları sildi. Şimdi -n (dry-run) ile rsync çalıştırmayı öğrendim.

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

Desteğim yoktu.

Bir zamanlar (muhtemelen Sistem III, ancak uzun zaman önceydi), *doğru kabuk alıntı kullanarak bir dosya oluşturmak mümkündü . Birini ev dizinimde bulduğumda, bir rm *şey tereddüt ettiğinde ve düşünürken ...

Diğer kullanıcılar için böyle bir dosya oluşturmak ortak bir şakaydı.

Dosya bir dizinde oturuyorsa, hafifletilmesi zor bir dosyadır. Adını tam olarak lsgöründüğü gibi yazacak olan refleks oldukça güçlü.

Diğer (daha az zararlı) şakası, kaldırılması çok daha zor olan beyaz alandan (veya sadece beyaz alandan) takip eden dosyaları adlandırmak ...

Yeniden başlatma sonrası genel JBoss lapa lapa laflığı konusundaki bazı kötü deneyimler nedeniyle, yeniden başlatılmadan önce JBoss'un çalışma dosyalarını silmeyi seviyorum. Normalde yapardım:

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

Kendimi olası felaket hatalarından herhangi birini yazmaya karşı korumak için:

• / Tmp / *
• tmp / *
• kaptın bu işi

Son komutu ben yaparım:

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

JBoss kullanıcısı, kendisine ait olmayan kritik dosyaları çıkarmakta zorlanır.

Asla bu hatayı yapmadım, ama yaptığım durumda güvende olurum.