Кто Ваш фаворит *болезненный* моменты Unix

Мне было любопытно если chmod 000 / работал бы.

Ну, безупречно. Несколько минут спустя я искал спасение CD.

Существует аккуратный прием, чтобы сделать эквивалент dirname и basename, соответственно, в Bash:

${path%/*}
${path##*/}

Не настолько забавный, когда $path содержит запаздывающую наклонную черту...

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

Когда я понял то, что я сделал, я сразу поразил Ctrl-C, но было слишком поздно. Мой rpm база данных давно оставила здание. Я потратил возрасты, возвращающие все к нормальному.

Теперь для болезненной части.

Я возвращаюсь в тот каталог в /mnt возобновлять то, что я делал. Что я ввожу? Ну, позвольте нам просто сказать что тот инстинкт, втолкнутый снова.

По крайней мере, я смог восстановить систему, намного более быструю во второй раз ;)

Мой переключатель от Debian до Ubuntu запустил день, который я пытался удалить некоторые файлы и каталоги, означая вводить

rm -r /var/tmp/*

К сожалению, я вставил пробел между "/var/tmp /" и "*" и еще хуже, я был в корне файловой системы.

root@workstation:/# rm -r /var/tmp/ *

Не пробуйте это дома!

Компания, на которую я раньше работал, имела свой продукт, работающий на SCO. Я делал некоторую отладку о приложениях, становящихся очень медленным на нашем демонстрационном сервере и в то же время был набор клиентов, даваемых демонстрацию/лекцию о предстоящих новых возможностях.

Так, я запустил приложение, которое раньше застревало, сделал мой материал на нем для проверки первопричины, но так как это все еще застряло, я пытался уничтожить его:

pkill -9 mytestapplication

То, что я изучил, было то, что pkill не делает точно того же на SCO, как это делает на Linux =)

... Это в основном уничтожает все, к чему у пользователя есть доступ, и с корнем... это - все =)

Не то, чтобы болезненный... Но забавный небольшой момент:

Я ввел с опечаткой ls как sl и узнанный, что системному администратору установили что-то для такого случая.

(уже доступный в Debian, Ubuntu, хинду... репозитории)

Когда я сначала начал работать пользовательским консультантом для университета, я принимал участие, мне дали ограниченному sudo права помочь студентам, которые теряли/забывали их пароли. sudo passwd <username> был мой новый друг. Спустя час после моей ориентации, мое любопытство взяло верх надо мной, и я ввел sudo passwd и смотрел в ужасе от подсказки для нового пароля. Я немного боялся ^C мой выход из него, думая (ошибочно, он складывается), что я мог бы уйти с рассматриваемого счета в переходном состоянии, таким образом, я ввел пароль и сразу обошел наверх к освященному 2-му домену пола кампуса SuperUser и спросил, хотел ли бы он знать пароль root основной системы.

Удивленный никто больше еще не упомянул этого:

rm -rf .*

(При попытке удалить все скрытые файлы и подкаталоги, полностью упущении, что это рекурсивно вызовет в . и ..)

Make-файл:

clean:
    @rm -f * .o

Который, конечно, делает make clean вытрите свой исходный код вместо просто объектных файлов.

Урок: используйте управление версиями.

Друг работал :() { :|:&}; : на удаленном сервере, где у нас не было консольного доступа к. Не мог перезагрузить его, полностью замороженный, рабочий сервер.

Сломанный (запросом) для создания этого более читаемым.

:() # Define ':' as a function. Every time we say ':' execute the following code block
{ # Start of code block
    : # Call ':' again. 
    | # Pipe output to...
    : # Another ':' 
    & # Disown process. 
    # All on one line this would read :|:&, 
} # End of code block
; # End definition of ':' as a function
: # Call ':'

Могло бы быть легче посмотреть на него как

bomb() { bomb|bomb& }; bomb

Я имел в виду хорошо, я действительно сделал. Попытка к chmod рекурсивно каталог и закончил тем, что подкачал ./ с /.

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

Я вытер таблицу разделов своего основного диска случайно, думая, что я работал над другим диском.

С scrollback, тщательным использованием df, память и удача я смог воссоздать его точно, переписать ее, перезагрузка и надежда... И это работало.

Едва ли мой момент, но чужой.

Назад, когда я работал в ядерной научной экспериментальной установке, мы раньше выполняли много SunOS, Ultrix и компьютеры Linux, и исследователи должны были совместно использовать ЦП на тех машинах. Поскольку отдельные исследовательские группы получили свои собственные гранты на проведение исследований, они купили свои собственные компьютеры, главным образом SparcStations, и они сделали системное администрирование сами.

SunOS раньше поставлялась с рабочим столом OpenView и хорошим файловым менеджером, это - то, на что она была похожа:

Большинство наших исследователей работало как корень, и несколько раз мы должны были переустановить их операционные системы, потому что кто-то решил привести в порядок корневой каталог и переместил / мусорное ведро, / и т.д.,/tmp и все остальное, что создало помехи представлению или в Trashcan или в некоторую подпапку.

Другие пользователи приняли решение убрать / каталог bin и удалить любую команду, которую они не знали.

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

Назад в середине к концу 90-х, мой друг и я обсуждали безумие rm -rf * и в том, какая точка поле Linux пошла бы живот. Мы вошли статически связанный по сравнению с динамически подключаемыми библиотеками, и я установил это, система могла жить вполне хорошо без /lib и затем продолжил переименовывать его на моей рабочей станции. Плохие вещи произошли, но нас оставили с несколькими открытыми консолями, с которыми можно попытаться зафиксировать повреждение (завершение работы больше не было опцией). Ни один из редакторов не работал бы. Это удивительно тайное использование, которое можно найти для echo команда.

vi и Caps Lock по сравнению с. /etc/passwd

1. Соединитесь со старым полем Solaris с помощью старого последовательного терминала, который не обновляет экран правильно.
2. su -
3. vi /etc/passwd. Существует нет vipw, и "мы просто делаем незначительные редактирования" так или иначе.
4. Поразите клавишу Caps Lock и не замечайте.
5. Хит j пару раз для прокручивания вниз. Проигнорируйте то, что Вы на самом деле просто ввели J ("Соединение"), которое комбинирует эту строку со следующей строкой. Экран последовательного терминала не обновлялся правильно, таким образом, Вы не видели, что просто объединили первые 5 строк в одну строку Loooooong, таким образом, повредив первые 5 пользователей ('корень', 'демон', и т.д.).
6. Закончите Ваша OTHER предназначила редактирования в файл, путь вниз внизу.
7. Сохраните файл.
8. Выйти из системы.

Я сделал это однажды. Удивительно, система оставалась функциональной в течение многих месяцев. Cronjobs хорошо работал, никакие ошибки не выделились в файлах журнала.

Мы не заметили эту проблему, пока мы не перезагрузили систему несколько месяцев спустя и не могли войти в систему в консоли. ps показал набор заданий, принадлежавших UID '0' не пользователем 'корень'.

Вы не могли войти в систему как корень, ни работать su или su -, и был нет sudo на этом поле. Не было никакого дисковода для гибких дисков, CD-ROM был арестован и никакие USB-порты (так никакой внешний CD-ROM). Однопользовательский режим не работал, потому что необходимо ввести в пароле для корня, и это прибывает из /etc/passwd.

rm -f * ~

и

rm -rf ${DIR}/

когда DIR не был установлен!

Я не забываю пытаться отправить a Сочетание клавиш SysRq к удаленной машине...

... но это было получено локальным.

Простое halt распознавание несколько секунд спустя, что я не нахожусь на локальной оболочке и имеющий возможность включить рабочий сервер снова.

Уроки извлечены? Подсказка машины теперь похожа

[ --> root <-- @kompost:/home/echox] #

с некоторой хорошей красной разметкой ;-)

Мой любимый момент был, когда коллега, который является emacs пользователем, хотел отредактировать важный файл.

Поскольку emacs слишком много должен ввести, он имел, устанавливают псевдоним для emacs:

alias em=emacs

Под влиянием недостаточно или слишком много кофе он, конечно, ввел с опечаткой em ...

Ну, это - просто другая причина использовать vi ... ;)

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

Шаг один: установите счет на ребенка, в случае, если он хочет использовать поле Linux. Дайте ему тривиальный пароль, так как, в конце концов, это - домашняя система и не выставляется сети.

Шаг два: позвольте времени протекать, таким образом, Вы не помните шаг один.

Шаг три: откройте порт SSH в брандмауэре (на самом деле NAT на маршрутизаторе) чтобы к ssh в. В конце концов, мои учетные записи имеют довольно хорошие пароли, и это не похоже существует что-либо чрезвычайно ценное.

Шаг четыре: получите уведомление от ISP, что существует своего рода действие DOS, идущее в шведский сайт. Предположите, что это - вероятно, поля Windows, и исследуйте и укрепите их.

Шаг пять: получите уведомление от ISP, что он все еще продолжается. Попросите некоторую деталь, получите IP-адрес шведского сайта, разожгите Wireshark, найдите, которые упаковывают нападение, прибывает из.

Шаг шесть: очистите поле Linux, чувствуя себя глупыми. Найдите, что вход в систему прибыл из румынского адреса. Удалите учетные записи без хороших паролей.

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

Однажды, в то время как я бездельничал с настройками, это отказало с ошибкой Error: force on balls too great

Я однажды разрабатывал драйвер устройства для Unix. Это имело проблему указателя, и во время тестирования его начал списывать конец массива в памяти ядра. Я не спешил определять это и сразу не поразил кнопку сброса. Драйвер набросал на всем протяжении дискового кэш-буфера, который был затем сброшен к диску, прежде чем я поразил сброс. Много блоков было inodes и каталогами, и я закончил с полностью поврежденной файловой системой. Я думаю, что 6 000 осиротевших файлов были помещены в lost+found прежде чем я сдался и переустановил. К счастью, это было только системой тестирования, не моей рабочей станцией со всеми моими файлами на нем.

Я удалил / и т.д. и затем восстановил его. Я не думаю, что извлек свой урок... Я должен был восстановиться с удаленного /bin также. Кажется, происходит, когда я работал с a chroot.

В прошлом году мой коллега использовал одну из наших рабочих станций Linux для создания копий дисков флэш-памяти с помощью dd команда. Он случайно ввел что-то подобное следующему:

dd if=flash-image.img of=/dev/sda1

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

Это произошло со мной в прошлом году. Я удалял некоторые файлы из сервера с помощью временной переменной:

rm -rf ${prefix}*

Угадайте что? Переменная $prefix не был определен!
Можно вообразить аварию... она привела к некоторым очень критическим удаленным файлам.

Я почти повредил Ctrl-C и работал к ЦП для удаления сетевого кабеля!!

Ха-ха-ха я уверен, что кто-то уже сделал это...

В то время как на моем 2-м году учащейся информатики нам дали присвоение домашней работы для записи программы в C, который породит много подпроцессов с fork и заставьте их общаться с каналами в "кругу" и фигуре, какой должен быть "лидером".

Мы были все еще вполне новичками тогда, и большинство peple не имело никаких машин Linux, таким образом, мы работали над нашими учетными записями на основном сервере нашей способности (который размещал официальный сайт и учетные записи штата и сайты также). Большинство людей записало fork-бомбы на некотором этапе попытки сделать домашнюю работу. Более чем половина моей группы добралась до abusers файл. Это было самой высокой нагрузкой на тот сервер в looong время :)

Когда мой Университет решил переключить беспроводную сеть для использования собственной Cisco Аутентификация LEAP...

Запущенный очень длинное сражение, которое закончилось достаточно хорошо. Описал документацию для других, которые хотели запустить Linux и иметь доступ к Интернету. Шесть месяцев спустя они решили добавить поддержку PEAP также. удар поверхности

Это - мой фаворит, потому что я победил. Я заставил это работать.

Как базируются на Солярисе,

$ kill -9 1

... и все понизилось.

Мой друг был уволен из-за этого.

Я был помощником лаборатории по классу Linux. Один из студентов позвонил мне, потому что она больше не могла su - потому что она добиралась permission denied. Хорошо, она - misremembered/mistyped пароль. Перезагрузка в однопользовательский режим и сброс. Что?! su ВСЕ ЕЩЕ не работает?! Это ДОЛЖНО поклониться моему желанию! Таким образом, я перезагружаю в однопользовательский режим для обнаружения то, что она сделала. Я понял, что она работала chmod -R 777 /var/www/html/drupal-6.19 /

Отметьте пространство между именем каталога и заключительной наклонной чертой.

После нескольких минут "Я действительно не хочу иметь ее, переустанавливают, поэтому что это делает и как". мне удалось найти, что/bin/su теперь имел полномочия файла 777. Это может также быть считано как полномочия файла 0777, то, которое удаляет setuid, укусило от /bin/su. Быстрое chmod u+s /bin/su и я был героем.

git init
git clean -f

Это не сносит репозиторий. Это удаляет все, что не находится в репозитории.

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