Книги Packt Publishing про Troubleshooting

[ТёмныйЭльфНавостриэль2020]

В общем, вот их сайт www.packtpub.com щас там мож чо поменялось, но пару лет назад я тут книжку купил, а щас вроде как можно читать бесплатно, токо подписацца на членство.
Книжка Trougleshooting Centos 160 стр, но про Troubleshooting там почти ничего не сказано. Просто рассмотрены более детально некоторые команды. Например, сказано, что к yum есть плагины, которые добавляют разные опции и ключи в командную строку yum, а есть ещё yum-utils. Прочтение этого побудило меня ознакомицца с полноценной документацией по yum и dnf и наконец понять, чо там есть, а чо нет.

Red Hat Enterprise Linux Troubleshooting Guide. Вот это ваще огонь! 400стр, Берёцца неисправность и описывается, как пользоваться командами в связке с другими командами - мы не просто хз чо набираем, а набираем осмысленные команды, приближающие нас к исправлению неисправности.
Я вот например ещё узнал новую команду ifstat (и ещё много других)
Но афтар обещал показать разные стили поиска неисправностей. Пока что я видел только один стиль - Data collector. Афтар молодец - не леницца затрачивать на поиск несколько больше шагов, проверяет всякие лишние штуки чисто, чтоб показать действие разных команд - как ими нужно что-то искать и проверять.

Он сам писал, что надо делать анализ корневой причины, но пока что в его примерах я такого не видел. Когда неисправность найдена, он не объясняет, как такое вообще могло получиться.

Тем не менее, пока что эта книга уникальна.

В пятой главе db.example.com имеет 2 адреса 192.168.33.12 & 10.0.0.50 и второй адрес он на голубом глазу пробивает по DNS-серверу Гугла (8.8.8.8) Но 10.0.0.0 это ж у нас сети А-класса, немаршрутизируемые в тырнете.

Вот ещё что я узнал. /var/log/sa - туда sar по крону собирает статистику за последние 30 дней работы компа. Статистику можно прочитать через sar (у меня на Федоре она есть, поэтому, возможно есть и на всех Red Hat сверерах) Возможно, есть какие-то графические проги для визуализации sar в виде графиков - так нагляднее, кто бы чо ни говорил. О, прочитал, есть какой-то kSar, а есть ещё sadf, которая преобразует в нужный формат, например csv, а оттуда я залью в Либроофис и там уже настрою графиков.
ещё упоминаются какие-то rrdtool, atop. Полноценные системы мониторинга Munin, Cacti, Zabbix

ip route get 4.4.4.4 - показывает, как пойдёт пакет с таким адресом

фигасе, перец - взял отмонтировал /boot на работающем сервере. А ведь и правда - после загрузки он особо не нужен, а при перезагрузке он сам примонтируется обратно. У меня сложнее - сначала убираешь /boot/efi, потом уже сам /boot

Ну вот в 7й главе он восстанавливет /boot как ext4, а в логах она у него xfs. Каг таг?
В 8й главе про RAID-массивы. Шо у каждого диска есть кол-во event, которое можно посмотреть, у всех дисков в одном массиве оно должно быть одинаково. Там он добавляет в массив диск, который оттуда недавно вылетел. Потому что с самим диском не было ошибок. Плохая практика на мой взгляд. Почему-то же он вылетел. Кстати, вылетевший диск щитал, что он в массиве и оба диска работают (там был рейд-1) Диски пишут свой статус как "AAA", в массиве статус отображется как "UU_"
Как мне пригодятся эти знания? Хз. Токо на экзамене если. Мы с программными рейдами не работает, да и вам не советуем. Юзайте аппаратные рейды. Ваще на своей персоналке я конечно мог бы наворотить, но нахуа? Если у меня один физический диск, будь у меня там хоть сто рейдов, если диск ёбнецца, они ёбнуцца все ))

В 9й главе он рассказывает как отлаживать самописные написанные хер знает кем приложения. Есть у тя бинарник, надо его запустить, чтоб работал. Ну вот, можно по содержимому конф.файла, по параметрам запуска в командной строке уже много чего узнать. Открытые файлы можно смотреть через lsof, логи. если есть, тоже очень неплохо, смотреть через tail -f, открытые порты по netstat. А дальше вплоть до декомпиляции.
Периодически я запускал lsof, но никогда не догадывался сделать lsof /dev/null. Узнал много нового.
Под конец афтар запустил strace, чтобы отследить ебучее приложение - чо оно там делает.

Узнал про процесс идра oom-kill (или oom_kill или oom_killer, хз, так я его и не нашёл, но он есть). Этат працэс запускается, когда не хватает памяти и килит. Как определяет, что не хватает памяти? В идре есть параметры - скоко должно быть свободных Мб и наскоко заполнен swap. Если памяти и свопа меньше, чем прописано, запускается киллер и килит процессы. Не всегда это работает идеально, но я рекомендую вам иметь как можно больше памяти и свопа для таких случаев. Пока толстый сохнет, худой сдохнет, гагага.

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

У меня она кстати в электронной читалке 2 раза сохранена - второй раз вот недавно сохранил, а ещё видимо до этого - собирался прочитать.

@темы: Linux, книжки