Какие твои любимые * болезненные * моменты Unix

Как насчет того, чтобы поделиться любимыми уроками ?

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

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

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

Удивлен, еще никто не упомянул об этом:

rm -rf .*

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

Makefile:

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рекурсивно каталог и в конечном итоге обмен ./с /.

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

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

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

Не совсем мой момент, но кто-то другой.

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

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

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

Другие пользователи решили убрать каталог / 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(«Join»), что объединяет эту строку со следующей строкой. Экран последовательного терминала не обновлялся правильно, поэтому вы не видели, что вы просто скомбинировали первые 5 строк в одну строку Loooooong, повредив тем самым первых 5 пользователей («root», «daemon» и т. Д.).
6. Завершите свои ДРУГИЕ намеченные правки в файле, внизу.
7. Сохранить файл.
8. Выйти.

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

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

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

rm -f * ~

а также

rm -rf ${DIR}/

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

Я помню, как пытался отправить SysRqпоследовательность клавиш на удаленную машину ...

... но он был захвачен местным.

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

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

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

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

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

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

alias em=emacs

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

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

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

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

Шаг второй: дайте время пройти, так что вы не помните первый шаг.

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

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

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

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

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

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

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

Я удалил / etc и затем восстановил это . Не думаю, что усвоил урок ... Мне тоже пришлось восстанавливаться после удаленного /bin. Кажется, произойдет , когда я работал с chroot.

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

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

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

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

rm -rf ${prefix}*

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

Я чуть не сломал Control-C и побежал к процессору, чтобы удалить сетевой кабель !!

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

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

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

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

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

Это мой любимый, потому что я выиграл. Я получил это на работу.

Как root на Solaris,

$ kill -9 1

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

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

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

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

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

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

Я набрал ошибку lsкак slи узнал, что сисадмин что- то установил для такого случая.

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

git init
git clean -f

Это не удаляет хранилище. Это удаляет все, чего нет в хранилище.

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

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

Итак, я запустил приложение, которое раньше застряло, сделал свои вещи для проверки основной причины, но, так как оно все еще «зависло», я попытался убить его:

pkill -9 mytestapplication

Что я узнал, так это то, что pkill не делает в SCO то же самое, что и в linux =)

... Это в основном убивает все, к чему у пользователя есть доступ, и с помощью root ... вот и все =)

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

rm -r /var/tmp/*

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

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

Пожалуйста, не пытайтесь сделать это дома!

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

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

Не так смешно, когда $pathв конце есть косая черта ...

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

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

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

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

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