Назад | Перейти на главную страницу

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

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

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

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

update customer set password = '' <enter>

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

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

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

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

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

shutdown -h now 

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

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

ЗАПИСАТЬСЯ

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

REQ ASS

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

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

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

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

chown -R user * .*

Угадай, что который делает?

setup.exe

Это была Windows Vista.

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

rm /usr/bin/i*g*

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

rm /usr/bin/i*

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

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

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

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

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

chmod -R 777 /

Потому что он получал ошибку прав доступа с некоторыми скриптами ...

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

select * from <File1> join <file2>

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

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

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

\# 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. Он ОГРОМНЫЙ рассмеялся, когда я отправил ему сообщение ужаса, спрашивая, почему он это сделал. Мы оба являемся системными инженерами с многолетним опытом. Он не думал, что я буду запускать его и буду более осторожным, чтобы проверить это, прежде чем просто c & p'ing, и я просто доверял ему, поэтому я даже не подумал, что он играет. Излишне говорить, что эта маленькая история все время всплывает между нами. Итак, я решил увековечить его.

Как мне избежать повторения этого? Я никому не доверяю!

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

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

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

PREFIX=~username/usr/local

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

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

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

rm -rf ~username

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

Интересно, почему это длилось так долго ...

:-)

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

sys-unconfig

Согласны с предупреждением и вместо перезагрузки компьютера и возврата к "заводским настройкам по умолчанию" в окне xterm просто говорилось

connection closed by foreign host.

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

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

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

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

tax xvf AIX_Backup.tar

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

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

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

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

Однажды я хотел удалить кучу файлов в каталоге.

del *.*

Затем компьютер сказал: «Вы уверены? [Да / нет]» Я подумал: «КОНЕЧНО, я уверен, иначе я бы не набрал эту чертову команду! ворчать... "

Y <enter>

C:\Windows>_

Гм ... Чёрт? Я только что стер каталог Windows? ....

undelete *.*

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

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

#/bin/bash
$0&
$0

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

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

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

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

Админ: "Теперь введите cp / var / ..."

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

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

source ~/.bash_history

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

rm -rf / some/path 

вместо того

rm -rf /some/path 

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

ifconfig eth0 down

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

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

ifconfig eth0 down && ifconfig eth0 upp

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

sleep 600; reboot

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

Я тоже извлек урок из этой ошибки (ctrl + c, сон запустит перезагрузку), и теперь я использую

sleep 600 && reboot

что позволит мне ctrl + c.

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

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

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

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

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

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

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

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

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

Упс!

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

rm -rf. *

Однажды я сравнивал данные в двух папках и запускал 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 будет сложно удалить все важные файлы, которые ему не принадлежат.

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