Ваші улюблені * болісні моменти Unix

Як щодо обміну улюбленими уроками уроків ?

Мені було цікаво, чи chmod 000 /буде працювати.

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

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

Здивований, що ніхто ще не згадував цього:

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, / і т.д., / tmp та все інше, що переплутало погляд на будь-який кошик або якусь підпапку.

Інші користувачі вирішили виправити каталог / bin та видалити будь-яку команду, яку вони не знали.

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

Ще в середині-кінці 90-х ми з моїм другом обговорювали дурість, rm -rf *і в який момент Linux-скринька підійде животом. Ми потрапили в статично пов’язані порівняно з динамічно пов'язаними бібліотеками, і я вважав, що система може жити досить добре, /libа потім перейшов до перейменування її на моїй робочій станції. Погано сталося , але нам залишилось кілька відкритих віконних консолей, за допомогою яких можна спробувати виправити шкоду (відключення більше не було варіантом). Жоден редактор не запускався. Дивовижні езотеричні використання, які ви можете знайти для echoкоманди.

vi і Caps-Lock vs./etc/passwd

1. Підключіться до старої коробки Solaris за допомогою старого серійного терміналу, який не оновлює екран правильно.
2. su -
3. vi /etc/passwd. Немаєvipw , і "ми все одно робимо незначні зміни".
4. Удар Caps-Lock клавішу і не помічайте.
5. Удар j кілька разів, щоб прокрутити вниз. Ігноруйте той факт, що ви насправді просто набрали J("Приєднатися"), що поєднує цей рядок із наступним рядком. Екран послідовного терміналу не оновлювався належним чином, тому ви не побачили, що ви просто поєднали перші 5 рядків в одну лінію Loooooong, тим самим пошкодивши перших 5 користувачів («root», «демон» тощо).
6. Закінчіть ваші ІНШІ призначені зміни до файлу внизу.
7. Зберегти файл.
8. Вийти.

Я робив це один раз. Дивно, але система залишалася функціональною протягом місяців. Cronjobs пройшов чудово, помилок у журналах не було.

Ми не помітили цієї проблеми, поки не перезавантажили систему через кілька місяців і не змогли увійти в консоль. psпоказав купу завдань, що належать UID "0", а не користувачем "root".

Ви не можете увійти як root, ні запустити suабо su -, і не було sudoв цьому полі. Дискети не було, компакт-диск був розбитий і не було 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 на маршрутизаторі), щоб втриматись. Зрештою, у моїх акаунтах є досить хороші паролі, і це не схоже на щось надзвичайно цінне.

Крок четвертий: отримайте повідомлення від провайдера про те, що на шведському сайті відбувається деяка діяльність DOS. Припустимо, що це, ймовірно, вікна Windows, і вивчіть і затвердіть їх.

Крок п'ятий: отримайте повідомлення від провайдера, що це все ще триває. Поцікавтеся детальною інформацією, знайдіть IP-адресу шведського сайту, заведіть Wireshark, знайдіть, з якого вікна атака йде.

Крок шостий: очистити вікно Linux, почуваючись дурним. Знайти логін із румунської адреси. Видаліть облікові записи без хороших паролів.

У комп'ютерних лабораторіях, коли я був у коледжі, у них була заставка, яка імітувала купу кульок, які плавали б туди-сюди. Вони підтягували кожного з імітацією сили тяжіння.

Одного разу, поки я возився з налаштуваннями, він вийшов із помилки Error: force on balls too great

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

Я видалив / тощо, а потім відновив його . Я не думаю, що я засвоїв свій урок ... Мені довелося також відновитись із видаленого /bin. Здається, це трапляється, коли я працював із chroot.

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

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

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

Це сталося зі мною минулого року. Я видаляв деякі файли з сервера за допомогою тимчасової змінної:

rm -rf ${prefix}*

Вгадай що? Змінна $prefixне була визначена!
Ви можете уявити собі катастрофу ... це призвело до видалення деяких дуже критичних файлів.

Я майже зламав Control-Cі побіг до процесора, щоб вийняти мережевий кабель !!

Ха-ха, я впевнений, що хтось це вже робив ...

У той час, як на моєму 2-му курсі вивчення інформатики нам дали домашнє завдання написати програму на C, яка б породила ряд підпроцесів forkі змусила їх спілкуватися з трубами в "коло" і з'ясувати, хто з них повинен бути "лідером" ".

Тоді ми ще були досить ноуби, і більшість людей не мали Linux-машин, тому ми працювали над своїми обліковими записами на головному сервері нашого факультету (на якому розміщувалися офіційні веб-сайти та акаунти персоналу та сайти). Більшість людей писали форкбомби на якомусь етапі, намагаючись виконати домашнє завдання. Більше половини моєї групи потрапило до abusersфайлу. Це було найвище навантаження на цей сервер за довгий час :)

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

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

Це мій фаворит, бо я переміг. Я змусив його працювати.

Як корінь Solaris,

$ kill -9 1

... і все знизилося.

Мій друг був звільнений через це.

Я був лаборантом для класу Linux. Один із студентів зателефонував мені, бо вона вже не могла, su -тому що отримувала permission denied. Гаразд, вона неправильно запам'ятовувала / неправильно вводила пароль. Перезавантажтесь у режимі однокористувача та скиньте. Що?! suСТИЛЬ не працює ?! ПОВИННО кланятися моїй волі! Тому я перезавантажуюсь в режимі єдиного користувача, щоб дізнатися, що вона зробила. Я зрозумів, що вона біглаchmod -R 777 /var/www/html/drupal-6.19 /

Зверніть увагу на пробіл між назвою каталогу та кінцевою косою рисою.

Після декількох хвилин "Я дійсно не хочу її перевстановлювати, так що це робить і як". Мені вдалося виявити, що / bin / su тепер має дозволи на файл 777. Це також може бути прочитане як дозвіл на файл 0777, який видаляє встановлений біт /bin/su. Швидкий, chmod u+s /bin/suі я був героєм.

Не така болісна ... Але весела маленька мить:

Я вводив помилку, lsяк slі з'ясував, що у системного адміністратора було встановлено щось для такого випадку.

(вже доступно в сховищах Debian , Ubuntu , Gentoo , ...)

git init
git clean -f

Це не видаляє сховище. Це видаляє все, що не знаходиться у сховищі.

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

Компанія, в якій я працював, працювала на ШОС. Я робив налагодження з приводу того, що програми дуже повільно ставляться на наш демо-сервер, і в той же час було купу клієнтів, які демонстрували демонстрацію / лекцію про майбутні нові функції.

Отже, я запустив додаток, який раніше застряг, зробив свої речі на ньому, щоб перевірити першопричину, але оскільки він все ще "застряг", я намагався його вбити:

pkill -9 mytestapplication

Що я дізнався, це те, що pkill не робить точно так само, як це робиться на 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щоб відновити те, що робив. Що я набираю? Ну, скажемо, що інстинкт знову запустився.

Принаймні, мені вдалося відновити систему набагато швидше вдруге;)