Каков самый большой ущерб (любого рода), который вы когда-либо нанесли с помощью одной ошибочной / опечатанной / неверной командной строки? Например, некоторое время назад я по ошибке удалил базу данных производственной системы, но мне повезло (т.е. было выполнено резервное копирование), и не было постоянной потери данных, потери денег, материального ущерба и т. Д.
Самое главное (для голосов), что вы делаете, чтобы этого больше никогда не повторилось?
На сервере 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/*
Чтобы защитить себя от множества возможных катастрофических ошибок, например:
Делаю последнюю команду:
# sudo -u jboss rm -rf tmp/* work/*
Поскольку пользователю JBoss будет сложно удалить все важные файлы, которые ему не принадлежат.
На самом деле я никогда не совершал этой ошибки, но в этом случае я в безопасности.