1. Аварийное прерывание обновления системы

Ситуация: машина в самый разгар обновления (через yum update) выключается по перегреву процессора (это отдельная тема :) ). И потом - загрузка не доходит до конца, а на консоли наблюдается множество ошибок загрузки модулей.
Решение: для всех действий требуется получить консольный доступ к данной системе самом системой или через LiveCD/LiveDVD и потом чрутнуть (от слова chroot, но пока с этим ещё не разобрался). В случае невозможности загрузиться в консоль обычным образом пробуем загрузиться в режиме 1 (runlevel 1). Для этого в строку загрузки в загрузчике пишут соотв.цифру: в данном случае - 1 (в записи 'Первые эксперименты' или 'Ковыряния в Линуксе - 1' это была 3). После загрузки система переходит в однопользовательский режим с правами суперпользователя root. Что нам и нужно (на вопрос "зачем так сделали - это же не безопасно?" ответ такой: это можно сделать ТОЛЬКО при физическом доступе к системе, а вопросы физической защиты - не затрагиваются ОС. Если боитесь - шифруйте разделы).
Первоначально можно попробовать завершить транзакцию обновления. Для этого есть специальная команда менеджера пакетов yum:


$ yum-complete-transaction

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


$ lsmod

Выбранные модули прописываются в новый пустой (для облегчения возврата к старой конфигурации - удалить файл и обновить конфигурацию) файл в каталоге /etc/modprobe.d/. Например это будет /etc/modprobe.d/blklist.tmp. Содержимое файл по примеру:


blacklist <имя_модуля_ядра>

на каждый отключаемый модуль.
По окончании заполнения файла необходимо обновить конфигурацию загрузчика plymouth командой


$ /usr/libexec/plymouth/plymouth-update-initrd

после чего - перезагрузиться.
Если и это не помогло, пробуем выяснить, может какой-то файл повредился при установке какого-то пакета. Ищем соотв. файл (ругань на него) в логах: /var/logs/boot.log и /var/logs/dmesg. У меня это был файл /etc/dbus-1/system.d/nm-ifcfg-rh.conf.
Теперь выясним, с каким пакетом связан этот файл:


$ rpm -qf /etc/dbus-1/system.d/nm-ifcfg-rh.conf

Следущее: проверяем, всё ли с этим пакетом впорядке:


$ rpm -V <имя_пакета_полученного_на_предыдущем_шаге>

Если не в порядке, а особенно если выругается на этот файл, то:


$ yum reinstall <имя_пакета_полученного_на_предыдущем_шаге>

У меня никак не ругался, но я на всякий случай переустановил пакет. Всё! Система после перезагрузки заработала. :)



2. Отладка системы и программ в помощью GDM

При необходимости в привлечении возможностей для отладки, заложенных в операционной системе: GNU GDB Debugger.

№1 Запуск процесса с отладкой
Сделаем на примере telegram-desktop.
Первоначально надо установить пакет с отладочной информацией проблемного приложения (после отладки можно удалить):


$ dnf install telegram-desktop-debuginfo

Чтобы получить отладочную информацию (backtrace) падения, нужно выполнить:


$ gdb /usr/bin/telegram-desktop 2>&1 | tee ~/backtrace.log

В ~/backtrace.log теперь записана необходимая для отладки информация.

№2 Снятие дампа процесса
Предварительно подготовим систему к тому, что будем "безраздельно" пользоваться ресурсами. :)


$ ulimit -c unlimited

Теперь можно начинать работу непосредственно с отлаживаемым процессом. Для начала - найдём его идентификатор - PID:


$ ps -x | grep openvm 11989 ? Sl 0:05 /usr/lib/parallels-workstation/parallels-workstation --openvm

Скармливаем это тайное :) знание отладчику:


$ gdb --pid=11989

После выполнения подготовительных действий отладчик остаётся загруженным - видно приглашение его командной строки (gdb) и теперь можем сохранить дамп интересующего нас процесса и отключаем это дамп:


(gdb) gcore Saved corefile core.11989 (gdb) detatch

Более подробно: "Перевод руководства по отладчику GNU", "Справочник по командам GDB (англ.)".



3. Повреждение базы пакетного менеджера rpm

Если в процессе обновления системы появились сообщения об ошибках базы данных rpm, например:


Finishing rebuild of rpms, from deltarpms error: rpmdb: BDB0113 Thread/process 2324/139767708010432 failed: BDB1507 Thread died in Berkeley DB library] 2.9 MB/s | 32 MB 00:00:32 ETA error: db5 error(-30973) from dbenv->failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery error: cannot open Packages index using db5 - (-30973) error: cannot open Packages database in

то лучшим вариантом будет пересоздание этой базы:


$ rpm -vv --initdb $ rm -f /var/lib/rpm/__db* $ rpm -vv --rebuilddb

Если всё нормально прошло, то на экран будет выведена информация о созданных базах и индексах.



4. Обновление системы

4.1. Конфликт пакетов из-за rawhide
Если при обновлении Федора 15 появилось сообщение об ошибке типа:
Проверка сценария завершена с ошибкой (примерно):


file /usr/lib64/libva-egl.so.1 from install of libva-freeworld-1.0.13-1.fc15.x86_64 conflicts with file from package libva-1.0.12-1.fc15.x86_64 file /usr/lib64/libva-glx.so.1 from install of libva-freeworld-1.0.13-1.fc15.x86_64 conflicts with file from package libva-1.0.12-1.fc15.x86_64 file /usr/lib64/libva-tpi.so.1 from install of libva-freeworld-1.0.13-1.fc15.x86_64 conflicts with file from package libva-1.0.12-1.fc15.x86_64 file /usr/lib64/libva-x11.so.1 from install of libva-freeworld-1.0.13-1.fc15.x86_64 conflicts with file from package libva-1.0.12-1.fc15.x86_64 file /usr/lib64/libva.so.1 from install of libva-freeworld-1.0.13-1.fc15.x86_64 conflicts with file from package libva-1.0.12-1.fc15.x86_64

то это является признаком, что остались прописаны rawhide-репозитории, требуемые лишь для тестирования (в F15 они остались, т.к. на момент релиза репозитория rpmfusion для F15 ещё не было, приходилось пользоваться rawhide-ом; обещалось что обновления сами исправят локальную конфигурацию репозиториев, когда появится rpmfusion для F15, но этого не произошло).

$ yum update rpmfusion*release
$ yum clean all
$ yum update

б) если предыдущий вариант не помог или вы решили удалить rawhide вообще (что представляется лучшим вариантом), то порядок действий таков:
удаляем неправильные репы:


$ yum remove rpmfusion*release*

ставим правильные:


$ su -c 'yum localinstall --nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm \ http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm'

и обновляемся:


$ yum update

На будущее может пригодиться официальная информация о конфигурировании репозитариев.

4.2. Проблемы из-за сбойных предустановок SELinux
Если в процессе обновления возникли ошибки вида:


Обновление : firewalld-0.3.9.2-1.fc20.noarch 3/32 warning: %post(firewalld-0.3.9.2-1.fc20.noarch) scriptlet failed, exit status 127 Non-fatal POSTIN scriptlet failure in rpm package firewalld-0.3.9.2-1.fc20.noarch

И в конце обновления результаты были похожи на:


Неудача: firewalld.noarch 0:0.3.9-1.fc20 initscripts.x86_64 0:9.50-1.fc20

Это значит, что был установлен сбойный пакет selinux-policy-targeted.
Для исправления надо установить исправленный вариант, например, из тестового репозитория, отключив SELinux на время обновления:


$ setenforce 0 && yum --enablerepo=updates-testing update selinux\* && setenforce 1

А потом провести ещё раз обновление, чтобы обновить те пакеты, которые не смогли обновиться из-за сбоя.

4.3. Дупликация пакетов
Иногда при обновлении происходях сбои uninstall скрипта удаляемого пакета и при обновлении появляются сообщения вида:


** Предварительно ошибок в rpmdb: 1, «yum check» выдает следующее: firewalld-0.3.9.2-1.fc20.noarch — то же, что и firewalld-0.3.9-1.fc20.noarch

При поосмотре по установленным пакетам, то видно удвоение:


$ rpm -qa firewalld firewalld-0.3.9-1.fc20.noarch firewalld-0.3.9.2-1.fc20.noarch

1) Правильный способ.
Первое: сделать резервную копию каталога /var/lib/rpm/ перед запуском пересборки. Это одна из рекомендаций, писанных нервами админов. :-)


$ tar cSf - /var/lib/rpm/ | xz -9 --extreme --threads=4 --verbose --force > ~/VARLIBRPM.tar.xz

Для дистрибутива Fedora 26 и более новых необходимый функционал интегрирован в утилиту DNF. Для удаления дубликатов необходимо запустить её со следующими параметрами:


$ dnf remove --showduplicates

# для Fedora <= 25
$ dnf install yum-utils
# для RedHat / CentOS и пр. на YUM
$ yum install yum-utils

После установки воспользуемся утилитой из установленного пакета для удаления дубликатов:


$ package-cleanup --cleandupes --noscripts

$ rpm --rebuilddb

По хорошему, теперь надо проверить обновления:


$ dnf upgrade --refresh

2) Не совсем правильный способ.
Если пытаться удалить не нужный пакет yum-ом, то это может не получиться:


$ yum remove firewalld-0.3.9-1 Загружены модули: langpacks, remove-with-leaves, show-leaves Совпадений с firewalld-0.3.9-1 не найдено. Пакетов, отмеченных для удаления, нет.

В таком случае надо удалять посредством rpm:


$ rpm -e firewalld-0.3.9-1.fc20.noarch

И после этого провести обновление системы, чтобы проверить на ошибки.



4.4. Тестовые пакеты

Иногда возникает необходимость установить обновление из тестового репозитория. Например, для исправления "пойманого" бага:


# Обновить конкретные пакеты $ yum update mesa\* --enablerepo=updates-testing # Установить пакет $ yum install mesa-dri-drivers.i686 --enablerepo=updates-testing

Соответственно, так же можно работать и с другими репами.



4.5. Откат с текущей версии на одну из предыдущих

Просмотр доступный версии пакета (на примере nginx):


$ dnf list --showduplicates nginx

Получаем, например, такой список:


Установленные пакеты nginx.x86_64 1:1.12.2-1.el7_4.ngx @nginx Доступные пакеты nginx.x86_64 1:1.8.0-1.el7.ngx nginx nginx.x86_64 1:1.8.1-1.el7.ngx nginx nginx.x86_64 1:1.10.0-1.el7.ngx nginx nginx.x86_64 1:1.10.1-1.el7.ngx nginx nginx.x86_64 1:1.10.2-1.el7.ngx nginx nginx.x86_64 1:1.10.2-2.el7 epel nginx.x86_64 1:1.10.3-1.el7.ngx nginx nginx.x86_64 1:1.12.0-1.el7.ngx nginx nginx.x86_64 1:1.12.1-1.el7.ngx nginx nginx.x86_64 1:1.12.2-1.el7_4.ngx nginx

Выбираем версию, на которую будем откатываться (например, 1.10.3-1) и откатываемся:


$ yum downgrade nginx-1.10.3-1.el7.ngx

На этом откат заканчивается.



4.6. Установка тестовых обновлений требуемой сборки

При необходимости установки конкретного требуемого обновления системы необходимо (на примере FEDORA-2019-475e5ab227) выполнить:


$ dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2019-475e5ab227

Список актуальных обновлений здесь.



5. Проблемы с SELinux

Просмотреть зафиксированные журнале в человекопонятном варианте


# все $ ausearch -m avc # за текущий день $ ausearch -m avc -ts today

Специальная утилита audit2allow создает разрешающие правила политики SELinux из файлов журналов, содержащих сообщения о запрете операций.
Варианты использования:
1) использование audit2allow для генерации монолитной (не модульной) политики:


$ cd /etc/selinux/$SELINUXTYPE/src/policy $ cat /var/log/audit/audit.log | audit2allow >> domains/misc/local.te # можно просмотреть domains/misc/local.te и при желании изменить $ cat domains/misc/local.te allow cupsd_config_t unconfined_t:fifo_file { getattr ioctl }; $ make load

2) использование audit2allow для генерации модульной политики:


$ cat /var/log/audit/audit.log | audit2allow -m local > local.te # можно просмотреть local.te и при желании изменить $ cat local.te module local 1.0; require { role system_r; class fifo_file { getattr ioctl }; type cupsd_config_t; type unconfined_t; }; allow cupsd_config_t unconfined_t:fifo_file { getattr ioctl };

3) создание модуля политики вручную:
Компилируем модуль:


$ checkmodule -M -m -o local.mod local.te

Создём пакет:


$ semodule_package -o local.pp -m local.mod

Загружаем модуль в ядро:


$ semodule -i local.pp

4) использование audit2allow для генерации и создания модуля политики:


$ cat /var/log/audit/audit.log | audit2allow -M local

Создаём новый type enforcment файл: local.te
Компилируем политику:


$ checkmodule -M -m -o local.mod local.te

Создаём пакет:


$ semodule_package -o local.pp -m local.mod

Более подробно - в мануалах: ausearch, audit2allow.
Для установки типа и других параметров контекста безопасности используется команда chcon:


# установка типа файла $ chcon -t <тип>

Для восстановления неправильно установленных (или не установленных совсем, то есть установленных по умолчанию) параметров контекста безопасности используется команда restorecon.
Так же полезное:


# вывод флага getsebool httpd_can_sendmail # установка флага setsebool -P httpd_can_sendmail 1

6. Проблемы с loop (блочными псевдоустройствами)

Иногда возникает ошибка, представленна сообщением "Failed to set up loop device". Я сам столкнулся с этой ошибкой при попытке смонтировать криптоконтейнер RealCrypt/TrueCrypt.
Данная проблема решилась двумя способами (для разных версий Fedora):
1) в Fedora 20 (вероятно, что это проявление ошибки - доказательством является то, что при загрузке с ядром 3.11 проблемы нет): отключение и сразу включение SELinux (только решается временно - до перезагрузки):


$ setenforce=0 $ setenforce=1

2) в Fedora 19: добавлением параметра ядра, указывающего количество возможных loop устройств:


max_loop=64

Для работы с loop устройствами используется утилита losetup.


# просмотр используемых псевдоустройств $ losetup -a # удаление ненужного $ losetup -d /dev/loop2

Например, так можно монтировать образы и работать с ними (есть блочное псевдоустройство в виде файла или тома LVM с таблицей разделов и файловыми системами внутри - надо добраться до содержимого).
Подключаем файл (том) в псевдоустройство:


$ losetup /dev/loop2 /dev/VolGroupXEN1/vm111_img

Проверяем таблицу разметки в юнитах по 512 байт:


$ fdisk -l -u /dev/loop2 Disk /dev/loop2: 32.2 GB, 32212254720 bytes 255 heads, 63 sectors/track, 3916 cylinders, total 62914560 sectors Units = sectors of 1 * 512 = 512 bytes Device Boot Start End Blocks Id System /dev/loop2p1 2048 1525759 761856 82 Linux swap / Solaris Partition 1 does not end on cylinder boundary. /dev/loop2p2 * 1525760 62914559 30694400 83 Linux

Нужно добраться до второго раздела. Юнит с которого начинается второй раздел имеет номер 1525760.
Создаем еще одно псевдоустройство со смещением на 1525760 юнитов по 512 байт:


$ losetup -o $((1525760*512)) /dev/loop3 /dev/loop2

Проверяем, что вышло:


$ blkid /dev/loop3 /dev/loop3: UUID="0ebb8ce2-fb48-4e38-8396-babcd56961e4" SEC_TYPE="ext2" TYPE="ext3"

Можно монтировать файловую систему:


$ mount /dev/loop3 /mnt/dir1

7. Поиск сбойных секторов и восстановление информации с них

Для это используется утилита dd_rescue:


$ dd_rescue -v -l error.log -o bad.log /dev/ad0s1a /dev/null

В указанные файлы журналов работы утилиты будет выведена информация о найденных проблемах.



8. Проблемы со звуком

а) Глюки, пропуски или треск

В файле /etc/pulse/default.pa меняем параметр:


# Исходная строка $ load-module module-udev-detect # исправленная строка $ load-module module-udev-detect tsched=0

Перезагружаем систему или перезапускаем звуковой сервер Pulse:


$ pulseaudio -k $ pulseaudio --start

Для улучшения качестве звука изменим в файле /etc/pulse/daemon.conf значения параметров resample-method и default-sample-format на:


resample-method = src-sinc-best-quality default-sample-format = s16le

Перезапускаем сервер Pulse и наслаждаемся.



б) Запуск звуковой карты Asus ROG Xonar Phoebus

Пока данная звуковая карта не поддерживается Linux. :(
Она является Intel HD Audio совместимой, поэтому есть надежда в ядре 3.16 и новей поддержку всё таки получить.
Пока только ссылки на всякую информацию:
CONFIG_SND_HDA_INTEL: Intel HD Audio
[Alsa-user] Asus Xonar Phoebus support
Matrix:Vendor-Asus



9. Исправление ошибки в RFC 5961

В стандарте RFC 5961 обнаружена уязвимость, которую злоумышленник может применить для вклинивания в TCP сессию, если она не зашифрована, а так же разрывать сессии HTTPS и TOR.
Возможно будет выпущено обновление, но в качестве решения можно в /etc/sysctl.conf добавить строку:


net.ipv4.tcp_challenge_ack_limit = 999999999

После чего надо принятие изменений в системе:


$ sysctl -p

Или перезагрузиться.



10. Работа с ядром через клавишу SysRq

SysRq - специальная клавиша за номером 84 (программное прерывание BIOS номер 0x15, подфункция 0x85). Чаще известна, как "Print Scrn / PrScr", но возможно назначение этой функции любой другой клавише, например, Fn. Не имеет единого стандартного назначения, но изначально и чаще всего сейчас используется для прямого вызова некоторых функций ядра ОС.
Выполнение: одновременное нажатие клавиш Alt + SysRq + <буква>.
Если SysRq вызывается с использованием Fn то следует зажать Alt + Fn + SysRq, затем отпустить Fn и ввести букву команды.
Основные комбинации клавиш:


Комбинация клавиш Назначение Описание Alt + SysRq + H Help Вывод всех доступных возможностей SysRq (выделяя большой буквой клавишу действия) Alt + SysRq + 0-8 loglevel0-8 Смена уровня подробности вывода от 0 (только критические сообщения) до 8 (самый подробный режим) Alt + SysRq + B reBoot Выполнение немедленной перезагрузки системы (аналогично кнопке RESET - без синхронизации и размонтирования файловых систем) Alt + SysRq + C Crashdump Выполнение директивы kexec для перезагрузки (чтобы получить сведения об ошибках) Alt + SysRq + D holDs Показывает все блокировки (удерживающие устройства или файлыъ) Alt + SysRq + O powerOff Корректное выключение системы (если настроено и поддерживается) Alt + SysRq + S Sync Выполнение синхронизации примонтированных файловых систем (в консоль выводится 'Emergency Sync'; при успешном завершении - 'Emergency Sync Complete') Alt + SysRq + U Unmount Перемонтирование примонтированных файловых систем в режим 'только чтение' Alt + SysRq + T showTasks Выдача в текущую консоль списка текущих задач и информации о них Alt + SysRq + N Nice Сброс приоритета задачи реального времени или просто с измененным приоритетом Alt + SysRq + W shoW-blocked-tasks Выдача списка всех непрерываемых (заблокированных или ждущих окончания ввода-вывода) задач Alt + SysRq + M showMem Выдача информации о доступной и занятой оперативной памяти и использовании свопа Alt + SysRq + F Full Вызов обработчика oom_kill (out-of-memory kill) для прерывания использующих слишком много памяти приложений (может занять продолжительное время) - если система ни на что не реагирует и индикатор жёсткого диска очень активно работает Alt + SysRq + K secure access Key Прекращение работы всех процессов текущей консоли (если оригинальный login был подменён злоумышленником - вредная программа будет убита и init запустит подлинный login) Alt + SysRq + R unRaw Перехват управления мышью и клавиатурой у Х-сервера (если Х-сервер завис): так можно перейти в консоль Alt + SysRq + E tErm Посыл сигнала завершения работы SIGTERM всем процессам (кроме init) Alt + SysRq + I kIll Посыл сигнала немедленного завершения работы SIGKILL всем процессам (кроме init) Alt + SysRq + L kiLl Посыл сигнала немедленного завершения работы SIGKILL всем процессам (в том числе init)

Например, для аварийной синхронизации данных следует выполнить последовательность Alt + SysRq + S, далее Alt + SysRq + U. После этого можно жать на сброс или, что то же самое, Alt + SysRq + B.
Более правильно экстренную перезагрузку стоит проводить, зажав клавиши Alt + SysRq и с интервалом в 2-3 секунды нажать последовательно 'R E I S U B':
- unRaw : перехват управления клавиатурой;
- tErminate : посыл SIGTERM всем процессам;
- kIll : посыл SIGKILL всем процессам, которые не смогли завершиться предыдущей командой;
- Sync : синхронизация файловых систем;
- Unmount : перемонтирование файловых систем в режим 'только чтение';
- reBoot : выполнить перезагрузку.
Для работы SysRq необходима поддержка этого функционала в ядре: необходимо указать параметру ядра CONFIG_MAGIC_SYSRQ значение 'y'. Проверить можно так же через файл конфигурации ядра:


$ grep 'MAGIC_SYSRQ=' /usr/src/kernels/4.14.8-200.fc26.x86_64/.config CONFIG_MAGIC_SYSRQ=y

При наличии поддержки SysRq в ядре надо включить отслеживание нажатий этих клавиш:


$ echo '1' > /proc/sys/kernel/sysrq

Вместо нажатия клавиш можно использовать SysRq-триггер. Например, для клавиши 'b':


$ echo b > /proc/sysrq-trigger

В современных версиях Fedora включение SysRq производится установкой параметра ядра kernel.sysrq. В документации ядра указываются следующие возможные значения:


0 - disable sysrq completely 1 - enable all functions of sysrq >1 - bitmask of allowed sysrq functions (see below for detailed function description): 2 = 0x2 - enable control of console logging level 4 = 0x4 - enable control of keyboard (SAK, unraw) 8 = 0x8 - enable debugging dumps of processes etc. 16 = 0x10 - enable sync command 32 = 0x20 - enable remount read-only 64 = 0x40 - enable signalling of processes (term, kill, oom-kill) 128 = 0x80 - allow reboot/poweroff 256 = 0x100 - allow nicing of all RT tasks

Дополнительная информация:
Magic SysRq key



11. Смена ядра без перезагрузки

Возможность смены ядра без перезагрузки системы (через обновление ядра в памяти) обеспечивается пакетом kexec-tools:


$ dnf install kexec-tools

После установки пакета автоматически при перезагрузке будет использован вызов kexec. При необходимости отключить kexec необходимо в файле конфигурации /etc/default/kexec установить параметр


LOAD_KEXEC=false

Замена текущего ядра в ручном режиме:


# чтение ядра в память $ kexec -l /boot/vmlinuz --initrd=/boot/initrd.img --command-line="`cat /proc/cmdline`" # перевод управления на загруженное ядро $ kexec -e

Использовать параметр '--command-line="`cat /proc/cmdline`"' не обязательно: по умолчанию должна приняться строчка от старого ядра.



12. Борьба с утечкой памяти через кеширование

Когда память на сервере уходит в неизвестном направлении (нагрузка небольшая – но памяти тоже нет), стоит произвести очистку кеша.
Linux, как и другие ОС кеширует операции чтения/записи, но забывает очищать кеш. В следствии этого, через какое-то время заканчивается память. Быстрый способ очистить память не прибегая к деструктивным методам (перезагрузка сервера, процесса, службы и прочего) - заставить ОС сбросить кеш. Для этого необходимо сбросить буферы (что приведёт к их очистке) после чего послать команду ядру на сброс кеша.


$ sync $ echo "3" >/proc/sys/vm/drop_caches

В drop_caches можно передавать несколько вариантов параметра:


13. Копирование GPT таблицы (разделов)

Устанавливаем утилиту поддержки GPT:


$ dnf install gdisk

В составе пакета есть утилита sgdisk, которая нам и нужна.
Копируем таблицу GPT с диска /dev/sdf на /dev/sdg:


$ sgdisk -R /dev/sdg /dev/sdf

Для обеспечения уникальности необходимо сменить GUID разделов скопированной таблицы на новом накопителе:


$ sgdisk -G /dev/sdg

14. Трассировка и профайлинг

Трассировка и профайлинг в Linux с помощью bcc/eBPF



15. Расширенное журналирование и статистика

Установим дополнительные пакеты:


$ yum install atop sysstat

atop - утилита мониторинга и регистрации (журналирования) производительности;
sysstat - набор утилит, обрабатывающих статистику различных подсистем ОС Linux (sar, sadf, mpstat, iostat, tapestat, pidstat, cifsiostat, sa).
Утилита atop конфигурируется через файл /etc/sysconfig/atop (например, интервал сбора данных до 60 секунд через переменную INTERVAL=60 (по умолчанию - 600)) и запускается, как сервис:


$ systemctl start atop $ systemctl enable atop

Информация в двоичном виде сохраняется в файлах /var/log/atop/atop_<дата>. Для просмотра используется команда:
$ atop -r <имя файла>
Для передвижения по временным точкам используются клавиши:


Клавиши Описание i изменение времени проверки (по умолчанию 10 секунд) g вернет все в дефолтный вывод v подробная информация о процессах u сортировка по самым прожорливым пользователям t переход к следующему временному интервалу Shift + t переход к предыдущему временному интервалу Shift + m сортировка процессов по занимаемой резидентной памяти Shift + с сортировка процессов по потреблению CPU (по умолчанию) Shift + d сортировка процессов по использованию диска Shift + n сортировка процессов по использованию сети

Для записи сообщений с меткой *.debug в отдельном журнале впишем для rsyslog (если используется он) в его конфиг /etc/rsyslog.conf строку:


*.debug /var/log/messages-debug

И перезапускаем сервис:


$ systemctl restart rsyslog

В пакете sysstat содержит системный регистратор SAR (System Activity Reporter) в форме одноимённой утилиты sar.
Файлы статистики, собираемые этой утилитой, сохраняются в каталоге /var/log/sa. Просмотр этой статистики можно сделать как через саму утилиту sar (примеры на справочной странице), а можно в форме графиков сторонними утилитами, например, ksar (java), вызвав её с указанием файла статистики:


$ java -jar kSar.jar -input 'cmd:///usr/bin/sar -dwu -f /var/log/sa/sa25'

Дополнительная информация:
1) Удобство наблюдения, atop;
2) Использование atop;
3) Системный регистратор Sar: полезно и практично.



16. Проблема с подключением по PPTP

Основная проблема с подключением к удалённой системе по PPTP (при условии, что все необходимы компоненты - установлены): заблокирован протокол GRE. Если на сетевом оборудовании он открыт, а проблема не разрешилась, значит на уровне ОС он не разрешён.
Откроем на firewalld :


# временно (в текущей зоне) $ sudo firewall-cmd --add-protocol=gre $ sudo firewall-cmd --query-protocol=gre # постоянно (в зоне home) $ sudo firewall-cmd --permanent --zone=home --add-protocol=gre $ sudo firewall-cmd --permanent --zone=home --query-protocol=gre $ sudo firewall-cmd --reload

В большинстве случаев проблема решена.



17. Сброс забытого пароля root

Для разных ОС и версий сброс отличается (хотя есть и общие моменты.
а) Fedora Linux;
В загрузчике Grub выбирает целевую системы и жмём "e", чтобы отредактировать этот пункт. Находим строку с параметрами ядра (начинается, в зависимости от версии, на linux, linux16, linuxefi) и редактируем:
- заменяем ro на rw;
- добавляем init=/bin/bash;
- если диск зашифрован, добавляем plymouth.enable=0.
Окончив редактирование нажимаем Ctrl-X или F10 и ждём загрузки до получения консоли.
В консоли вводим:


$ passwd $ touch /.autorelabel $ /sbin/reboot -f

После загрузки входим с новым пароле root-а.
б) CentOS / Scientific Linux 7:
В загрузчике Grub выбирает целевую системы и жмём "e", чтобы отредактировать этот пункт. Находим строку с параметрами ядра (начинается, в зависимости от версии, на linux, linux16, linuxefi) и редактируем:
- заменяем ro на rw;
- добавляем rd.break.
Окончив редактирование нажимаем Ctrl-X или F10 и ждём загрузки до получения консоли.
В консоли вводим:


$ mount -o remount,rw /sysroot/ $ chroot /sysroot $ cd /etc/ $ passwd $ load_policy -i $ chcon -t shadow_t /etc/shadow $ touch /.autorelabel $ /sbin/reboot -f

После загрузки входим с новым пароле root-а.



Немного послезностей

а) Создание файла


$ cat > <имя_создаваемого_файла>

Ввод содержимого, как обычно. Завершение ввода: Ctrl+D.

б) Создание файла нужной длины


$ dd if=/dev/zero of=~/file count=1 bs=100M

Получим файл ~/file размером 100 Мбайт.

в) Смена прав и разрешений
Если необходимо сменить права, то необходимо помнить, что для каталогов необходимо разрешение x (например, rwxr-xr-x, если надо дать: владельцу - полный доступ (чтение, запись, просмотр), а группе и все остальным - только чтение содержимого каталога), для каталогов являющееся разрешением на просмотр содержимого каталога. Например, вышеописанный пример (выполнять, находять в обрабатываемом каталоге) с рекурсивным спуском прав на все вложенные каталоги:


# рекурсивно назначаем требуемые права текущему каталогу и # всем вложенным каталогам и файлам, но... $ chmod -R 640 # ... затем каталогам назначает права на просмотр ('x') $ find . -type d -exec chmod 750 {} \; # назначаем владельца и группу (если требуется) $ chown -R nginx:nginx .

который необходимо выполнить, нахродясь в каталоге, содержимое которого необходимо изменить, где -type d - поиска файла с атрибутом d, т.е. каталога; 755 - числовое представление устанавливаемого атрибута безопасности; вторая строчка - рекурсивная смена владельца и группы.
Может пригодиться: краткое описание команд chmod и chown.

г) Анализ изменений в системе
Если требуется проанализировать систему на наличие изменений файлов пакетов отоносительно значения "в пакете", то это можно сделать так:


# сравнить установленный пакеты относительно содержимого RPM-пакета $ rpm -Vp foo-1.0-1.i386.rpm # проверить все пакеты, установленные в системе $ rpm -Va

Можно получить примено следующее ("отброшены" файлы и каталоги, у которым изменилось только время):


# rpm -Va | grep -v ".......T" .M....... / .M....... /root .M....... /sys prelink: /usr/lib64/libunwind-coredump.so.0.0.0: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib64/libunwind-coredump.so.0.0.0 prelink: /usr/lib64/libunwind-x86_64.so.8.0.1: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib64/libunwind-x86_64.so.8.0.1 prelink: /usr/lib64/libtorrent-rasterbar.so.7.0.0: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib64/libtorrent-rasterbar.so.7.0.0 prelink: /usr/lib64/libkeybinder.so.0.1.0: at least one of file's dependencies has changed since prelinking S.?...... /usr/lib64/libkeybinder.so.0.1.0 .M....G.. /var/log/journal .M....... c /etc/grub.d/20_linux_xen ....L.... c /etc/pam.d/fingerprint-auth ....L.... c /etc/pam.d/password-auth ....L.... c /etc/pam.d/postlogin ....L.... c /etc/pam.d/smartcard-auth ....L.... c /etc/pam.d/system-auth missing /var/run/gluster missing /var/run/wpa_supplicant .M....... /var/lib/nfs/rpc_pipefs missing /var/run/pluto

Расшифровка результатов проверки (слева):


Шаблон Описание 'S.......' отличаются размеры файлов '.M......' отличаются флаги и права доступа '..5.....' отличается контрольная сумма '...D....' несоответствуют major/minor номер устройств '....L...' readLink(2) path mismatch '.....U..' отличаются владельцы '......G.' отличаются группы-владельцы '.......T' отличается время модификации ' c' файл из секции %config (явно конфигурационный файл) ' d' файл из секции %doc (явно принадлежит к документации) ' g' файл-призрак (содержимое файла явно не существует в пакете (возможно создание скриптами при инсталляции пакета)) ' l' файл из секции %license ' r' файл из секции %readme

Дополнительно: RPM, 15.2. Использование RPM, Проверка целостности установленной linux-системы перед использованием.

д) Вывод сортированного по размеру списка пакетов в системе
Просмотр списка пакетов, установленных в системе, с выводом размера и сортировкой по размеру:


$ rpm -qa --queryformat '%{SIZE} - %{NAME}\n' | sort -rn | less

Можно поиграться с параметрами rpm.

е) Чистка базы journald
Просмотр занятого журналами места:


$ journalctl --disk-usage

Если решено зачистить все журналы, то останавливаем основную службу journald:


$ systemctl stop systemd-journald.service

Затем переходим в /var/log/journal/ и удаляем всё содержимое. Может это не корректно (и есть штатный "шринк"), но работает. :-)
После очистки указанного каталога возвращаем всё в исходное состояние:


$ systemctl start systemd-journald.service $ systemctl restart systemd-journal-flush

На будущее можно задать ограничивающий параметр в cat /etc/systemd/journald.conf:


[Journal] SystemMaxUse=100M

Подробности про journald: часть 1, часть 2, часть 3, часть 4.

ё) Полезные команды работы с пакетами, возможности yum
Для работы с пакетами требуется установленный пакет yum-utils.
Найти, какой пакет установит запрашиваемый файл/команда (например, repoquery):


$ yum whatprovides repoquery # более полно $ yum whatprovides */repoquery

Найти из какого репозитория установлен пакет:


$ find-repos-of-install httpd

Найти процессы, пакеты которых обновлены и требуют рестарта:


$ needs-restarting

Узнать зависимости пакета httpd, не устанавливая сам пакет:


$ repoquery --requires --resolve httpd

Синхронизировать yum репозиторий updates в локальную директорию repo1:


$ reposync -p repo1 --repoid=updates

Если требуется настроить работу yum через proxy-сервер, прописываем


# работать через IPv4 (при не настроенном IPv6 возможны проблемы) ip_resolve=4 # указываем proxy-сервер proxy=http://proxy.mydomain.com:3128 proxy_username=<UserProxy> proxy_password=<P@s$W0Rd>

Если требуется для одних репозиториев работать через proxy-сервер, а для других - через доступных напрямую (обычно внутренних): /etc/yum.conf не изменяется, а в файле /etc/yum.repos.d/*.repo тоже можно использовать директивы настройки прокси.