Самая большая ошибка командной строки? [закрыто]

Какой самый большой ущерб (любого рода) вы когда-либо наносили с помощью одной ошибочной / опечатки / ошибочной командной строки? Например, некоторое время назад я по ошибке удалил базу данных производственной системы, но мне повезло (т.е. я сделал резервную копию), и не было постоянной потери данных, потерянных денег, повреждения имущества и т. Д.

Самое главное (для голосов), что вы делаете, чтобы быть уверенным, что это больше никогда не повторится?

На сервере SQL в производственной системе:

update customer set password = '' <enter>

Самая последняя резервная копия была похожа на недельную.

Чтобы смягчить это, я теперь обычно пишу selectинструкцию сначала, чтобы убедиться, что я whereправильно понял предложение, затем возвращаюсь и редактирую его, чтобы вставить setпредложение и изменить инструкцию на update.

Самая большая ошибка? Думая, что я установил две переменные, когда я не сделал. Таким образом, rm -rf $ VARIABLE / $ VARIABLE2 стал rm -rf /. FreeBSD недавно обновила свой инструмент rm, так что rm -rf / больше не возможен именно из-за этой ошибки!

shutdown -h now 

предназначен для локальной рабочей станции, но набрал его при входе в систему через ssh на производственном сервере. С тех пор у меня всегда есть имя хоста в моем $PS1.

Пропуск -r из команды выключения. На удаленном сервере. На другой стороне страны. Без ИТ-персонала в удаленном офисе.

Мы все сделали это, это почти как обряд на данном этапе.

В системе VMS я использовал команду ASSIGN DCL для назначения логических имен, и я хотел ВЫЗВАТЬ предыдущую командную строку ASSIGN. Теперь в VMS вы только набрали столько символов команды, чтобы сделать ее однозначной. Поэтому я намеревался напечатать

REC ASS

но я случайно набрал

REQ ASS

вместо. REQ был достаточно недвусмысленным для команды REQUEST, которая транслирует аргумент всем, у кого есть привилегии оператора (который был у всех в IT). Таким образом, весь отдел получил мое широковещательное сообщение, которое было просто «ASS».

В системе Solaris: «killall dataLoader».

'dataLoader' был приложением, над которым я работал. В Linux killall работает как pkill. Он отправляет сигнал процессам, которые соответствуют строке, заданной в качестве аргумента. В Solaris killall пытается уничтожить все, что в системе может убить текущий пользователь. Я был root.

Однажды, много, много месяцев назад, мне нужно было найти конкретный исполняемый файл, но я не мог вспомнить его полное имя (но мог запомнить несколько букв). Поэтому я решил проверить каталог / usr / bin примерно так

rm /usr/bin/i*g*

Странный. Ничего не вернулось Поняв, что я только что неправильно запомнил второе письмо, я попытался снова

rm /usr/bin/i*

Опять ничего. После того, как я проделал то же самое с / usr / local / bin, / usr / sbin и всем остальным, что, как я предполагал, могло быть, я понял, что неправильно набрал команду 'ls'.

Не совсем знаю, откуда взялся этот мозг, но это определенно не та ошибка, которую я когда-либо совершал снова.

setup.exe

Это была Windows Vista.

Попытка изменить владельца всего в каталоге, включая точечные файлы, с помощью:

chown -R user * .*

Угадай, что это делает?

Предназначенный для уничтожения / dev / sdb, к счастью, у меня была хорошая современная резервная копия

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

select * from <File1> join <file2>

На производственной коробке. Обратите внимание на отсутствие onпункта. :-) Обе таблицы были многомиллионными таблицами строк, и это было на AS / 400 в середине 90-х, когда после запуска SQL вы не могли его убить.

На одном из наших серверов производства данных один из моих корней набрал:

chmod -R 777 /

Потому что он получал ошибку разрешений с некоторыми сценариями ...

Вскоре после этого его закрытый ключ был удален со всех серверов, и он позаботился о восстановлении данных объемом 1 ТБ на сервере производства данных ...

Мой любимый был когда я был в университете. Я создавал приложение (я не помню, что) и, поскольку я не был пользователем root, я создал его с

PREFIX=~username/usr/local

Так что я мог установить его в свой домашний каталог. К сожалению, это установлено в

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

вместо. Естественно, чтобы удалить его, как начать снова я выполнил

rm -rf ~username

В исходном каталоге.

Я задавался вопросом, почему это заняло так много времени ....

:-)

Однако мой худший случай был, когда я работал с рабочей станцией Solaris, и после того, как все было настроено, мы хотели стереть конфигурацию, готовую для живой конфигурации. Итак, я выполнил

sys-unconfig

Согласился с предупреждением и вместо перезагрузки машины и возврата к «заводским настройкам» в окне xterm просто сказано

connection closed by foreign host.

Мораль истории Никогда не оставляйте открытую корневую оболочку на другом хосте! КОГДА-ЛИБО!!

Много лет назад я был дома, кодировал некоторые вещи в php, работая над проектом с моим приятелем, который был сопровождающим проекта. Мы общались друг с другом в совместной работе. Мы всегда подшучиваем в игре.

Я пытался заставить ssh-agent нормально работать на моей машине, когда у нас была религиозная война Perl против PHP. Затем я упомянул кое-что о ssh-agent, который необходимо оценить (не знаю, почему я так сказал). Затем он послал мне это сообщение, чтобы я решил помочь мне с моей проблемой (имейте в виду, что мне нужно было болеть):

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

ПРЕДУПРЕЖДЕНИЕ! НЕ ПРОПУСТИТЕ ЭТУ КОМАНДУ !!!

Если вы удалите eval и запустите внутреннюю команду, то это:

rm -rf /

Мне потребовалось всего 4 секунды, чтобы заметить, что происходит, но ущерб уже был нанесен. Мне пришлось переустановить мою ОС. К счастью, ничего из моей работы не было уничтожено, за исключением некоторых вещей в / etc iirc. У него был ОГРОМНЫЙ смех, когда я послал ему сообщение ужаса, спрашивающее, почему он это сделал. Мы оба долгосрочные системные инженеры. Он не думал, что я запустил бы его, и будет более осторожным, чтобы проверить это, прежде чем просто зайти, и я просто доверял ему, поэтому даже не думал, что он играет. Излишне говорить, что эта маленькая история все время возникает между нами. Итак, я решил увековечить это.

Как я смягчила это случиться снова? Я никому не доверяю!

Еще одна менее интересная история - пару лет назад я работал над критическим блоком на работе. У меня было несколько терминов, открытых для другой машины. Мне нужно было удалить некоторые лишние вещи в каталоге. Ну, я заблудился в своих терминах и случайно позвонил . в моем местном каталоге, но не на том хосте (неправильный термин) !! Я выполнил команду в / var / lib / mysql вместо / tmp на сервере приложений (другой термин). Излишне говорить, что я уничтожил производственную базу данных. К счастью, у нас был теплый резерв, к которому мы обратились, пока я и коллега восстановили основной из резервных копий и резервного. Это заняло около 18 часов.

Смягчение: более внимательно относитесь к тому, в каких окнах я выполняю команды, прежде чем их выполнять.

короткая версия

#/bin/bash
$0&
$0

Я когда-то хотел удалить кучу файлов в каталоге.

del *.*

Затем компьютер сказал: «Вы уверены? [Y / N]» Я подумал: «Конечно, я уверен, я бы не набрал команду darn! В противном случае тупые компьютеры ворчат …»

Y <enter>

C:\Windows>_

Хм ... WTF? Я только что стер мой каталог Windows? ....

undelete *.*

В те времена маленьких жестких дисков я знал, для чего нужен каждый файл в c: \ windows и как его называли, но даже после удаления всего, система никогда не была прежней. Я получил немного уважения к подсказке «ты уверен». Немного.

Я думаю, что самой глупой вещью, которую я когда-либо делал, было удаление маршрута по умолчанию для внешнего кластера брандмауэра, обращенного к внешнему устройству, при этом он был подключен к моему рабочему столу на расстоянии более ста миль.

К счастью, это было в период, обозначенный как запланированное время простоя (на всякий случай), но это не спасло меня от 200-мильной поездки туда и обратно и изменения конфигурации межсетевого экрана на месте. Также не помогло то, что это уничтожило наши производственные системы, работающие в Интернете, на время моего путешествия и последующего исправления.

Мы все знаем определение нано-секунды. Оно-секунда еще меньше, и это время между нажатием «enter» и пониманием вашей ошибки.

Первый из двух ...

На коробке Solaris у нас была резервная копия tar на машине AIX.

Один из разработчиков набрал:

tax xvf AIX_Backup.tar

Конечно, пути в налоге были абсолютными, и в итоге мы создали новый дистрибутив unix ... Solarix ... Единственная проблема с дистрибутивом в том, что он не загружался :(

История сказала мне:

Вызван другой филиал, потому что у их местной АТС были некоторые проблемы После некоторого расследования мы узнали, что они обновили свой сервер, но не свою конфигурацию Asterisk. Итак, администратор решил поручить парню из филиала переделать конфигурацию.

Администратор: «Хорошо, теперь введите rm -rf / etc / asterisk»

Парень: Хорошо.

Администратор: «Теперь введите cp / var / ...»

Парень: «Подождите, он все еще работает ...»

Админ: ??? ... !!!

rm -rf / some/path 

вместо того

rm -rf /some/path 

К счастью, со мной этого не случилось ;-)

source ~/.bash_history

Моим намерением был исходный код .bashrc, но я слишком торопился с завершением табуляции ...

Что-то вроде этого:

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

Я имел в виду sda4. Я вытер весь диск, а не только раздел :-(

XCOPYэто мощный зверь, беспощадный в своем исполнении и замедленный тем, что его аргументы командной строки идут в обратном направлении от окон COPYи UNIX cp.

Пару дней назад я случайно написал:

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

XCOPYбыл достаточно любезен, чтобы переписать мой srcкаталог ... ничего! И не мешало положить старые файлы в корзину.

Ох, и получается, что на XCOPYсамом деле перезаписывают одни и те же сектора на диске вместо выделения новых. Я пробовал 3 программы восстановления дисков, и лучшая из них могла восстановить только 3 из 10 потерянных файлов. Конечно эти 3 файла были только vshost.exeи его приятели. Зыбь!

были проблемы с сетью (на удаленной машине) и просто хотел перезагрузить интерфейс

ifconfig eth0 down && ifconfig eth0 upp

В настоящее время я проверяю, что кто-то находится рядом с машиной, прежде чем пытаться делать подобные вещи (iptables также является хорошим кандидатом). И когда там никого не было, я однажды набрал

sleep 600; reboot

в другой (экранный) терминал, чтобы он перезагрузился, если бы я не смог Ctrl + C команда в течение 10 минут.

Я также учился на этой ошибке (Ctrl + C сон будет запускать перезагрузку), и теперь я использую

sleep 600 && reboot

что позволит мне Ctrl + C это.

ifconfig eth0 down

Ой, я на внешней стороне eth0. Веб-сервер находится на другой стороне мира, в закрытой комнате. Без доступа к сети для входа или перезагрузки. Дерьмо.

Бесплатный cookie для любого, кто может сказать мне, почему я был идиотом за попытку удалить все скрытые файлы и каталоги таким образом:

rm -rf. *

При очистке домашней папки на рабочем веб-сервере я забыл, что я поместил символическую ссылку веб-корня сервера в место в моей домашней папке. Не думая, я запустил rm -rf в этой папке, и следующее, что я знаю, люди звонят, что веб-сайт не работает!

OOPS!

Однажды я сравнивал данные в двух папках и запустил rsync с опцией -d (удалить файлы в месте назначения, которых нет в источнике). Затем я переключился между источником и местом назначения, когда запустил rsync. Это удалило все новые файлы, которые я хотел сделать резервную копию. Теперь я научился запускать rsync с -n (всухую).

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

У меня не было резервной копии.

Когда-то давно (возможно, System III, но это было очень давно), было возможно создать файл с именем *, используя правильное цитирование оболочки. Когда я нашла один в своем домашнем каталоге, я набрала rm *и положила палец на клавишу возврата, когда что-то заставило меня задуматься и подумать об этом ...

Создание такого файла для других пользователей было обычной шуткой.

Если файл находится там, в каталоге, это трудно исправить. Рефлекс, чтобы просто ввести его имя в точности так, как он lsтолько что отображался, довольно сильный.

Другая (менее вредная) шутка заключалась в том, чтобы называть файлы с конечным пробелом (или только пробелом), которые было намного сложнее удалить ...

Из-за некоторого плохого опыта с общей ошибкой JBoss после перезапуска мне нравится очищать рабочие файлы JBoss перед перезапуском. Я бы обычно делал:

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

Чтобы защитить себя от ввода любой из множества возможных катастрофических ошибок, таких как:

• / TMP / *
• tmp / *
• вы поняли идею

Я делаю последнюю команду:

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

Поскольку пользователю JBoss будет трудно удалить любые важные файлы, которые ему не принадлежат.

Я на самом деле никогда не совершал эту ошибку, но я в безопасности, если я это сделаю.