Тестировал вчера open source панель для управления сервером и установки на него софта - Cosmos. Сам автор позиционирует её как Secure and Easy Selfhosted Home Server. Панель и сама работает в Docker, и софт запускает тоже в контейнерах. Это уже не первая подобная панель на канале. Сразу скажу, что ничего особенного в ней не увидел. Она не лучше и не проще всех остальных похожих.
В целом, пользоваться можно. Даже русский язык есть, но переведено кривовато. Я переключился на английский. У всех подобных панелей на базе Docker есть один существенный минус. Они хоть и позиционируют себя как простые и быстрые в настройке, на деле это не так. Запуск приложений в Docker, особенно когда их много на одном сервере, требует от пользователя понимания, как всё это между собой связано и работает. Постоянно возникают небольшие нюансы в работе, которые не решить без этих знаний. А если вы знаете Docker, то и панель вам особо не нужна. Ставишь Portainer и запускаешь всё там.
Cosmos в целом неплоха в сравнении с остальными. Выделю несколько полезных особенностей:
▪️Интерфейс адаптивен, работает и на мобильных устройствах.
▪️Можно создавать пользователей веб панели. Бесплатная версия позволяет создать 5 штук.
▪️Панель нативно поддерживает работу MergerFS и SnapRAID.
▪️Из коробки HTTPS от Let's Encrypt.
▪️Поддержка OAuth 2.0 и OpenID, 2FA через Google аутентификатор или аналоги.
▪️Есть встроенные средства безопасности, на основании которых можно ограничивать доступ к публикуемым ресурсам. Можно ограничивать доступ на основе групп. Блокировать ботов, тех, кто превышает лимиты по запросам или трафику.
Запустить и посмотреть на Cosmos можно так:
Если настроено доменное имя, то можно сразу получить сертификат от Let's Encrypt, а все устанавливаемые службы будут запускаться на поддоменах. Если же сделать установку без HTTPS по IP адресу сервера, то сервисы будут подниматься на отдельных TCP портах. Я и так, и так попробовал.
Аналоги Cosmos:
◽️CasaOS
◽️Runtipi
Мне лично CasaOS больше всего понравилась. Она более целостно смотрится, магазин приложений больше, как и в целом сообщество. Но Cosmos более функциональна в базе.
⇨ 🌐 Сайт / Исходники / Demo
#docker #linux
В целом, пользоваться можно. Даже русский язык есть, но переведено кривовато. Я переключился на английский. У всех подобных панелей на базе Docker есть один существенный минус. Они хоть и позиционируют себя как простые и быстрые в настройке, на деле это не так. Запуск приложений в Docker, особенно когда их много на одном сервере, требует от пользователя понимания, как всё это между собой связано и работает. Постоянно возникают небольшие нюансы в работе, которые не решить без этих знаний. А если вы знаете Docker, то и панель вам особо не нужна. Ставишь Portainer и запускаешь всё там.
Cosmos в целом неплоха в сравнении с остальными. Выделю несколько полезных особенностей:
▪️Интерфейс адаптивен, работает и на мобильных устройствах.
▪️Можно создавать пользователей веб панели. Бесплатная версия позволяет создать 5 штук.
▪️Панель нативно поддерживает работу MergerFS и SnapRAID.
▪️Из коробки HTTPS от Let's Encrypt.
▪️Поддержка OAuth 2.0 и OpenID, 2FA через Google аутентификатор или аналоги.
▪️Есть встроенные средства безопасности, на основании которых можно ограничивать доступ к публикуемым ресурсам. Можно ограничивать доступ на основе групп. Блокировать ботов, тех, кто превышает лимиты по запросам или трафику.
Запустить и посмотреть на Cosmos можно так:
# docker run -d --network host --privileged --name cosmos-server -h cosmos-server --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket -v /:/mnt/host -v /var/lib/cosmos:/config azukaar/cosmos-server:latestЕсли настроено доменное имя, то можно сразу получить сертификат от Let's Encrypt, а все устанавливаемые службы будут запускаться на поддоменах. Если же сделать установку без HTTPS по IP адресу сервера, то сервисы будут подниматься на отдельных TCP портах. Я и так, и так попробовал.
Аналоги Cosmos:
◽️CasaOS
◽️Runtipi
Мне лично CasaOS больше всего понравилась. Она более целостно смотрится, магазин приложений больше, как и в целом сообщество. Но Cosmos более функциональна в базе.
⇨ 🌐 Сайт / Исходники / Demo
#docker #linux
При использование популярной в Linux утилиты
Зачастую удобнее сразу указать имя процесса. Покажу на примере просмотра потоков процесса, о которых дальше пойдёт речь:
Увидели сразу PID процесса 525 и все его потоки с номерами SPID. Иногда бывает нужно посмотреть или сразу посчитать потоки во время отладки какого-то приложения, которое, к примеру, виснет по какой-то причине. Быстро считаем его потоки:
Обращаю внимание, что вывод с потоками будет больше, чем просто вывод списка процессов, которые тоже часто считают для задач мониторинга. На том же сервере в тот же момент:
Если есть какие-то проблемы с приложением, и не понятно, что именно тормозит, можно вывести нужные метрики с разбивкой на потоки. Это хорошо показать на примере Fail2ban с PID 508.
У Fail2ban может быть много фильтров, которые обрабатываются в разных потоках. И какой-то из них в случае лавинообразного разрастания лога может очень сильно нагружать систему. Зная PID и SPID можно посмотреть подробности потока:
Всю строку не привожу, так как самое интересное в начале. Тут видно, что указанный поток обрабатывает jail с именем wp-login. Больше информации покажет
Ещё более подробную информацию можно получить через strace. Он не только по PID может подключаться, но и по SPID:
Там будет виден и лог, который поток читает, и даже конкретные строки. На нагруженном сервере завалит консоль, так что лучше сразу в файл выводить и потом смотреть. Обычное перенаправление в файл не сработает, надо использовать ключ
Можно конкретизировать, что записывать. Например, для Fail2ban будут актуальны операции открытия файлов и чтения:
А для каких-то процессов будет иметь смысл следить за записью:
Подобная проверка с strace будет очень актуальна, когда у вас какой-то поток приложения, к примеру, обращается по сети к ресурсу, который недоступен. И запрос висит по таймауту хрен знает сколько времени. А у вас сам процесс из-за него тормозит или висит.
Трейсы в режиме реального времени можно посмотреть и в
Стандартные и относительно простые утилиты консоли Linux позволят продебажить и разобраться даже в сложных и неочевидных на первый взгляд ситуациях.
📌 Полезные ссылки по теме заметки дебага консольными утилитами:
▪️Примеры использования ps
▪️Анализ дисковой активности в Linux
▪️Узнаём, что конкретно тормозит в php коде
▪️Расследование фантомных чтений с диска
▪️Расследование тормозов php сайта с помощью perf
▪️Профилирование нагрузки в Linux
▪️Кто и как использует swap
▪️Анализируем нагрузку на диск с помощью perf-tools
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal #perfomance
ps чаще всего оперируешь PID процесса или грепаешь вывод по строке в имени процесса:# ps -p 524 -o %mem,%cpu,cmd# ps ax | grep prometheusЗачастую удобнее сразу указать имя процесса. Покажу на примере просмотра потоков процесса, о которых дальше пойдёт речь:
# ps -T -C prometheus PID SPID TTY TIME CMD 525 525 ? 00:55:34 prometheus 525 803 ? 00:03:10 prometheus 525 808 ? 00:09:22 prometheus 525 1054 ? 00:08:44 prometheus 525 1113 ? 00:12:03 prometheus 525 1129 ? 00:10:42 prometheus 525 58983 ? 00:11:30 prometheusУвидели сразу PID процесса 525 и все его потоки с номерами SPID. Иногда бывает нужно посмотреть или сразу посчитать потоки во время отладки какого-то приложения, которое, к примеру, виснет по какой-то причине. Быстро считаем его потоки:
# ps -T -C zabbix_server | wc -l82Обращаю внимание, что вывод с потоками будет больше, чем просто вывод списка процессов, которые тоже часто считают для задач мониторинга. На том же сервере в тот же момент:
# ps ax | grep zabbix_server | wc -l59Если есть какие-то проблемы с приложением, и не понятно, что именно тормозит, можно вывести нужные метрики с разбивкой на потоки. Это хорошо показать на примере Fail2ban с PID 508.
# ps -L -o spid,%mem,%cpu,cmd 508 SPID %MEM %CPU CMD 1070 0.6 0.0 /usr/bin/python3 /usr/bin/fail2ban-server -xf start 1071 0.6 0.1 /usr/bin/python3 /usr/bin/fail2ban-server -xf start 1072 0.6 0.0 /usr/bin/python3 /usr/bin/fail2ban-server -xf start 1074 0.6 0.1 /usr/bin/python3 /usr/bin/fail2ban-server -xf start 1075 0.6 0.0 /usr/bin/python3 /usr/bin/fail2ban-server -xf start 1077 0.6 0.3 /usr/bin/python3 /usr/bin/fail2ban-server -xf startУ Fail2ban может быть много фильтров, которые обрабатываются в разных потоках. И какой-то из них в случае лавинообразного разрастания лога может очень сильно нагружать систему. Зная PID и SPID можно посмотреть подробности потока:
# cat /proc/508/task/1077/stat1077 (f2b/f.wp-login) ...................................Всю строку не привожу, так как самое интересное в начале. Тут видно, что указанный поток обрабатывает jail с именем wp-login. Больше информации покажет
status:# cat /proc/508/task/1077/statusЕщё более подробную информацию можно получить через strace. Он не только по PID может подключаться, но и по SPID:
# strace -p 1077Там будет виден и лог, который поток читает, и даже конкретные строки. На нагруженном сервере завалит консоль, так что лучше сразу в файл выводить и потом смотреть. Обычное перенаправление в файл не сработает, надо использовать ключ
-o:# strace -p 1077 -o ~/strace.outМожно конкретизировать, что записывать. Например, для Fail2ban будут актуальны операции открытия файлов и чтения:
# strace -p 1077 -e trace=openat,readА для каких-то процессов будет иметь смысл следить за записью:
# strace -p 1077 -e trace=writeПодобная проверка с strace будет очень актуальна, когда у вас какой-то поток приложения, к примеру, обращается по сети к ресурсу, который недоступен. И запрос висит по таймауту хрен знает сколько времени. А у вас сам процесс из-за него тормозит или висит.
Трейсы в режиме реального времени можно посмотреть и в
htop. Выбираете нужный процесс или поток и нажимайте s. Если strace установлена в системе, то увидите её работу.Стандартные и относительно простые утилиты консоли Linux позволят продебажить и разобраться даже в сложных и неочевидных на первый взгляд ситуациях.
📌 Полезные ссылки по теме заметки дебага консольными утилитами:
▪️Примеры использования ps
▪️Анализ дисковой активности в Linux
▪️Узнаём, что конкретно тормозит в php коде
▪️Расследование фантомных чтений с диска
▪️Расследование тормозов php сайта с помощью perf
▪️Профилирование нагрузки в Linux
▪️Кто и как использует swap
▪️Анализируем нагрузку на диск с помощью perf-tools
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal #perfomance
Я в консоли Linux настройки IP адресов уже давно привык смотреть так:
На выходе получается что-то похожее на
На прошлой неделе смотрел одного блогера и мельком увидел, как он смотрит IP адреса сервера:
Конкретизируем только IPv4:
Очень удобно. Я не знал и нигде не видел этот ключ. Сразу себе записал и постарался запомнить. Так реально удобнее смотреть. Сразу все адреса на виду, не надо глазами искать конкретный адрес в куче других строк.
Для просмотра линков и mac адресов ключ тоже применим:
Для справки ещё одну команду добавлю, которую тоже постоянно выполняю. Просмотр маршрутов:
Вообще, использование ip упростило вопросы просмотра и управления сетевыми настройками, так что довольно легко и добровольно на неё переключился в своё время. Где-то наверное со времён Centos 7.
Интересно, кто-то ещё ставит специально ifconfig и использует? Её вроде выпилили из базовых наборов системных утилит.
#linux #terminal
# ip aНа выходе получается что-то похожее на
ifconfig, только с другим форматированием. Ifconfig давно уже не ставлю и не использую. Все ключи позабыл. Смысла в ней уже нет с повсеместным распространением утилиты ip.На прошлой неделе смотрел одного блогера и мельком увидел, как он смотрит IP адреса сервера:
# ip -br alo UNKNOWN 127.0.0.1/8 ::1/128 eth0 UP 172.18.107.235/20 fe80::215:5dff:fe0d:7101/64 eth1 UP 192.168.101.2/24 fe80::215:5dff:fe0d:7105/64 docker0 DOWN 172.17.0.1/16 br-e901d734a0f3 DOWN 172.18.0.1/16 Конкретизируем только IPv4:
# ip -br -4 alo UNKNOWN 127.0.0.1/8 eth0 UP 172.18.107.235/20 eth1 UP 192.168.101.2/24 docker0 DOWN 172.17.0.1/16 br-e901d734a0f3 DOWN 172.18.0.1/16Очень удобно. Я не знал и нигде не видел этот ключ. Сразу себе записал и постарался запомнить. Так реально удобнее смотреть. Сразу все адреса на виду, не надо глазами искать конкретный адрес в куче других строк.
Для просмотра линков и mac адресов ключ тоже применим:
# ip -br l# ip -br nДля справки ещё одну команду добавлю, которую тоже постоянно выполняю. Просмотр маршрутов:
# ip rВообще, использование ip упростило вопросы просмотра и управления сетевыми настройками, так что довольно легко и добровольно на неё переключился в своё время. Где-то наверное со времён Centos 7.
Интересно, кто-то ещё ставит специально ifconfig и использует? Её вроде выпилили из базовых наборов системных утилит.
#linux #terminal
Одним из самых популярных репозиториев на github (21-е место по кол-ву звёзд) является репозиторий с ohmyzsh. Это фреймворк для создания конфигураций оболочки zsh. Для тех, кто не понимает, что это такое, скажу просто. Это сильно прокачанный по функциональности bash.
Никогда не понимал страсти и большой народной любви к zsh и ohmyzsh в частности. Хотя несколько раз пробовал. У меня и на рабочей станции, и на серверах всегда обычный bash. Мне кажется такое единообразие удобнее.
Если захотите попробовать zsh c ohmyzsh, то сделать это можно так:
Дальше поверх этого делаются различные настройки
Основные возможности ohmyzsh:
◽️Поддержка тем для консоли и промта в частности. Причём тем не только по изменению внешнего вида, но и в плане функциональности: отображение ветки git, таймер выполнения текущей команды и другие возможности.
◽️Большой набор готовых плагинов. Они могут добавлять алиасы, включать автодополнение при наборе команд, к примеру, от docker, git, kubectl, ansible и т.д. Там есть интеграции с менеджерами паролей, с screen и tmux, с батареей ноутбука. Чего там только нет.
В общем, ohmyzsh открывает безграничный простор для изменения и настройки командной строки. Мне это напоминает времена, когда были очень популярный виджеты в Windows. Я время от времени ковырялся в них, настраивал какую-то красоту и удобство. Через неделю все всё это надоедало и я убирал.
С ohmyzsh то же самое. Я аналог этой оболочки даже на виндовый терминал сталвил – oh-my-posh. Потом надоело, убрал. Отзывчивость консоли падает. Все эти расширения и плагины какие-то ресурсы забирают и добавляют задержку. В итоге ни zsh, ни его расширения у меня так и не прижились.
А вы используете эти украшательства или предпочитаете обычный bash? Я даже promt в нём не меняю, оставляю стандартный user@hostname.
#terminal #linux
Никогда не понимал страсти и большой народной любви к zsh и ohmyzsh в частности. Хотя несколько раз пробовал. У меня и на рабочей станции, и на серверах всегда обычный bash. Мне кажется такое единообразие удобнее.
Если захотите попробовать zsh c ohmyzsh, то сделать это можно так:
# apt install zsh# wget https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh# sh install.shДальше поверх этого делаются различные настройки
Основные возможности ohmyzsh:
◽️Поддержка тем для консоли и промта в частности. Причём тем не только по изменению внешнего вида, но и в плане функциональности: отображение ветки git, таймер выполнения текущей команды и другие возможности.
◽️Большой набор готовых плагинов. Они могут добавлять алиасы, включать автодополнение при наборе команд, к примеру, от docker, git, kubectl, ansible и т.д. Там есть интеграции с менеджерами паролей, с screen и tmux, с батареей ноутбука. Чего там только нет.
В общем, ohmyzsh открывает безграничный простор для изменения и настройки командной строки. Мне это напоминает времена, когда были очень популярный виджеты в Windows. Я время от времени ковырялся в них, настраивал какую-то красоту и удобство. Через неделю все всё это надоедало и я убирал.
С ohmyzsh то же самое. Я аналог этой оболочки даже на виндовый терминал сталвил – oh-my-posh. Потом надоело, убрал. Отзывчивость консоли падает. Все эти расширения и плагины какие-то ресурсы забирают и добавляют задержку. В итоге ни zsh, ни его расширения у меня так и не прижились.
А вы используете эти украшательства или предпочитаете обычный bash? Я даже promt в нём не меняю, оставляю стандартный user@hostname.
#terminal #linux
Для просмотра дерева запущенных процессов в системе Linux можно использовать разные способы. Я давно знаю 2 из них и постоянно применяю:
1️⃣ В утилите
2️⃣ Консольная команда
На днях просматривал репозиторий the-art-of-command-line. Там в основном информация для новичков. Большую часть я и так знаю, но нашёл для себя кое-что новое.
3️⃣ Есть программа
Есть ещё пара полезных ключей:
Посмотрел все остальные ключи, полезными их не нашёл.
Берите на вооружение, если как и я не знали о существовании этой утилиты.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal
htop, которую я всегда ставлю на сервера под своим управлением, есть режим древовидного отображения процессов. Для этого надо нажать клавишу t (tree view). Это удобно, когда в моменте надо что-то быстро посмотреть. Если процессов много и надо вдумчиво изучить список, то в htop не очень удобно из-за того, что интерфейс интерактивный.ps axf, а если список большой то она же, но направленная в текстовый файл ps axf > ~/ptree.txt. Там уже можно более спокойно и осмысленно всё посмотреть.На днях просматривал репозиторий the-art-of-command-line. Там в основном информация для новичков. Большую часть я и так знаю, но нашёл для себя кое-что новое.
pstree в составе пакета psmisc. Он во многих системах есть в базовом наборе системных утилит, либо ставится из стандартных репозиториев. С помощью pstree можно вывести древовидный список процессов в наглядном виде. Нагляднее, чем у ps. # pstree -pЕсть ещё пара полезных ключей:
-t – показывает полные имена подпроцессов. Для некоторых служб показывает чуть больше информации.-n – сортировка по pid, а не имени.-С age – раскраска имён процессов по возрасту. Процессы новее 60 секунд выводятся зелёными, новее часа – жёлтыми, а остальные красными.Посмотрел все остальные ключи, полезными их не нашёл.
Берите на вооружение, если как и я не знали о существовании этой утилиты.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Когда-то давно писал про одну полезную консольную команду, которой иногда пользуюсь. Она принудительно и моментально отправляет сервер с Linux в перезагрузку. Эффект аналогичен нажатию на кнопку reset:
Разница с консольными командами reboot или shutdown как минимум в том, что они обычные бинарники на диске.
Хотя на самом деле это уже давно не бинарники, а только ссылки на
Если с диском какие-то проблемы, либо он загружен так, что ни на что не отвечает, штатный reboot не состоится, либо будет долго исполняться. К тому же reboot пытается корректно отключить примонтированные диски. Очевидно, что если с одним из них проблемы, то тоже будет всё тупить и подвисать.
В случае же с приведенной командой, если вы уже находитесь в какой-то загруженной оболочке, сервер моментально перезапустится.
Недавно, кстати, в статье видел использование команды с принудительной перезагрузкой. Там автор наживую накатил на VPS поверх работающей системы RouterOS. Соответственно, текущую файловую систему он уничтожил, никакой бинарник запустить невозможно. А само ядро ОС всё ещё живёт в памяти и работает. Вот ему и можно отправить напрямую команду на перезагрузку.
Эта команда является частью так называемых Linux Magic System Request Key Hacks (sysrq). Магические сочетания клавиш, которые отправляют команды напрямую в ядро. Они реально привязаны к сочетаниям клавиш, выполняемых с управляющего терминала и подключенной клавиатуры. ALT + SysRq + <command key>. Клавиша SysRq часто совмещена с PrtSc. Уже не помню, когда последний раз сидел за экраном реального сервера, если это не мои домашние тестовые компы. Обычно везде хоть какой-то IPMI есть.
Ядро должно поддерживать эти команды. Обычно в популярных дистрибутивах это так:
◽️ 0 - sysrq отключен
◽️ 1 - sysrq полностью включен
◽️ >1 - включены отдельные функции
На Debian или Centos, с которыми я больше всего работал, перезагрузка всегда срабатывала.
Команд, которые можно отправить ядру, довольно много. Я лично использую только b для перезагрузки. Остальные не помню и никогда не использовал. А про reboot помню. Видел рекомендации, что перед перезагрузкой попробовать какие-то другие команды, типа тех, что отмонтируют диски, завершат процессы и т.д. Обычно если ты жёстко ресетишь сервер, то пробовать что-то не имеет большого смысла, потому что уже висим.
Если всё же интересно, то весь список команд можно запросить у ядра:
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal
# echo b > /proc/sysrq-triggerРазница с консольными командами reboot или shutdown как минимум в том, что они обычные бинарники на диске.
# type rebootreboot is /usr/sbin/reboot# type shutdownshutdown is /usr/sbin/shutdownХотя на самом деле это уже давно не бинарники, а только ссылки на
/bin/systemctl, но это не отменяет того, что последний тем не менее исполняемый файл. Он должен существовать, а во время выполнения пошуршать диском. У него куча ссылок на таргеты и службы systemd. Если с диском какие-то проблемы, либо он загружен так, что ни на что не отвечает, штатный reboot не состоится, либо будет долго исполняться. К тому же reboot пытается корректно отключить примонтированные диски. Очевидно, что если с одним из них проблемы, то тоже будет всё тупить и подвисать.
В случае же с приведенной командой, если вы уже находитесь в какой-то загруженной оболочке, сервер моментально перезапустится.
Недавно, кстати, в статье видел использование команды с принудительной перезагрузкой. Там автор наживую накатил на VPS поверх работающей системы RouterOS. Соответственно, текущую файловую систему он уничтожил, никакой бинарник запустить невозможно. А само ядро ОС всё ещё живёт в памяти и работает. Вот ему и можно отправить напрямую команду на перезагрузку.
Эта команда является частью так называемых Linux Magic System Request Key Hacks (sysrq). Магические сочетания клавиш, которые отправляют команды напрямую в ядро. Они реально привязаны к сочетаниям клавиш, выполняемых с управляющего терминала и подключенной клавиатуры. ALT + SysRq + <command key>. Клавиша SysRq часто совмещена с PrtSc. Уже не помню, когда последний раз сидел за экраном реального сервера, если это не мои домашние тестовые компы. Обычно везде хоть какой-то IPMI есть.
Ядро должно поддерживать эти команды. Обычно в популярных дистрибутивах это так:
# cat /proc/sys/kernel/sysrq◽️ 0 - sysrq отключен
◽️ 1 - sysrq полностью включен
◽️ >1 - включены отдельные функции
На Debian или Centos, с которыми я больше всего работал, перезагрузка всегда срабатывала.
Команд, которые можно отправить ядру, довольно много. Я лично использую только b для перезагрузки. Остальные не помню и никогда не использовал. А про reboot помню. Видел рекомендации, что перед перезагрузкой попробовать какие-то другие команды, типа тех, что отмонтируют диски, завершат процессы и т.д. Обычно если ты жёстко ресетишь сервер, то пробовать что-то не имеет большого смысла, потому что уже висим.
Если всё же интересно, то весь список команд можно запросить у ядра:
# echo h > /proc/sysrq-trigger | less /var/log/kern.log❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal
Каждый практикующий линуксоид хотя бы раз в жизни сталкивался с OOM Killer, который просто приходит и грохает какое-нибудь приложение. Чаще всего от этого страдают СУБД, так как они обычно самые жирные по потреблению памяти.
Небольшая инструкция на тему того, что делать, если на сервере кончается память и к вам приходит OOM Killer.
1️⃣ Первым делом я бы проверил системные логи на тему работы OOM Killer. Если у вас включены текстовые логи syslog, то сделать это проще всего так:
Если текстовых логов нет, не знаю, как быстро посмотреть. Я всегда включаю текстовые логи. Надо запускать journalctl и там через поиск искать то же самое. Я всегда забываю горячие клавиши, которые управляют результатами поиска, поэтому предпочитаю текстовые логи.
Может так получиться, что у вас уже давно время от времени прибиваются разные процессы, но заметили вы это только тогда, когда прибили то, что не умеет само подниматься.
2️⃣ Запускаем батю-скрипт на bash, который построит красивую табличку по приоритетным целям для OOM Killer:
Этот скрипт гуляет по комментариям и статьям. Я как-то заморочился и вроде бы нашёл автора, но не уверен, что это именно он. Однострочник только выглядит страшно. Если его записать с форматированием, то там простая структура. Её удобно взять за основу для формирования любых табличек с использованием ps и различных метрик. Может заморочусь и сделаю подборку из прикладных вещей, типа потребления памяти, сетевых соединений и т.д.
3️⃣ Теперь мы знаем, кого прибивает наш киллер, и видим в табличке OOM Score и OOM Adjustment. Чем выше первое значение, тем больше шансов, что процесс будет прибит. Если стоит 0, то не будет прибит никогда. Кто-то может подумать, что хорошо бы сделать нужному процессу Score 0, но это плохая идея. Если процесс течёт по памяти, то тупо виртуалка зависнет. Обычно так не делают. Второе значение - поправочный коэффициент для управления Score. Чем ниже этот коэффициент, в том числе с минусовыми значениями, тем меньше шансов, что OOM Killer убьёт нужный процесс.
Система этих очков и коэффициентов замороченная. Большого смысла в ней разбираться нет. Главное выставить приоритеты так, чтобы нужный вам процесс имел приоритет на убийство ниже остальных.
4️⃣ Прежде чем менять коэффициенты, идём в свои приложения и настраиваем в них потребление памяти, чтобы она на сервере не кончалась. Настраиваем мониторинг, если его нет. Чаще всего этого будет достаточно и трогать параметры OOM Killer не придётся.
5️⃣ Если используемые вами приложения не имеют своих настроек по потреблению памяти, то настроить их и поведение OOM Killer можно с помощью Systemd. У меня была отдельная заметка по этой теме. Там ничего сложного.
6️⃣ Когда всё настроили и хотите посмотреть, как себя поведёт система, если вдруг памяти не останется, то займите её всю чем-нибудь. Например, утилитой stress. Или просто в консоли запустите:
Заняли 1GB памяти. Подберите своё значение, чтобы памяти не осталось (2147483648 - 2GB, 3221225472 - 3GB и т.д.). После этого можно воспользоваться магической командой, про одну из которых я недавно писал:
Она принудительно вызывает OOM Killer. Пример, конечно, так себе, потому что OOM Killer скорее всего грохнет запущенную команду (хотя в моих тестах первым умер systemd). Чтобы этого избежать, надо дать ей низкий Score:
Ещё раз вызываем киллера и смотрим, кого он прибьёт:
У меня systemd умер первым.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#terminal #linux
Небольшая инструкция на тему того, что делать, если на сервере кончается память и к вам приходит OOM Killer.
1️⃣ Первым делом я бы проверил системные логи на тему работы OOM Killer. Если у вас включены текстовые логи syslog, то сделать это проще всего так:
# grep -i Killed /var/log/syslogЕсли текстовых логов нет, не знаю, как быстро посмотреть. Я всегда включаю текстовые логи. Надо запускать journalctl и там через поиск искать то же самое. Я всегда забываю горячие клавиши, которые управляют результатами поиска, поэтому предпочитаю текстовые логи.
Может так получиться, что у вас уже давно время от времени прибиваются разные процессы, но заметили вы это только тогда, когда прибили то, что не умеет само подниматься.
2️⃣ Запускаем батю-скрипт на bash, который построит красивую табличку по приоритетным целям для OOM Killer:
printf 'PID\tOOM Score\tOOM Adj\tCommand\n'
while read -r pid comm; do [ -f /proc/$pid/oom_score ] && [ $(cat /proc/$pid/oom_score) != 0 ] && printf '%d\t%d\t\t%d\t%s\n' "$pid" "$(cat /proc/$pid/oom_score)" "$(cat /proc/$pid/oom_score_adj)" "$comm"; done < <(ps -e -o pid= -o comm=) | sort -k 2nr
Этот скрипт гуляет по комментариям и статьям. Я как-то заморочился и вроде бы нашёл автора, но не уверен, что это именно он. Однострочник только выглядит страшно. Если его записать с форматированием, то там простая структура. Её удобно взять за основу для формирования любых табличек с использованием ps и различных метрик. Может заморочусь и сделаю подборку из прикладных вещей, типа потребления памяти, сетевых соединений и т.д.
3️⃣ Теперь мы знаем, кого прибивает наш киллер, и видим в табличке OOM Score и OOM Adjustment. Чем выше первое значение, тем больше шансов, что процесс будет прибит. Если стоит 0, то не будет прибит никогда. Кто-то может подумать, что хорошо бы сделать нужному процессу Score 0, но это плохая идея. Если процесс течёт по памяти, то тупо виртуалка зависнет. Обычно так не делают. Второе значение - поправочный коэффициент для управления Score. Чем ниже этот коэффициент, в том числе с минусовыми значениями, тем меньше шансов, что OOM Killer убьёт нужный процесс.
Система этих очков и коэффициентов замороченная. Большого смысла в ней разбираться нет. Главное выставить приоритеты так, чтобы нужный вам процесс имел приоритет на убийство ниже остальных.
4️⃣ Прежде чем менять коэффициенты, идём в свои приложения и настраиваем в них потребление памяти, чтобы она на сервере не кончалась. Настраиваем мониторинг, если его нет. Чаще всего этого будет достаточно и трогать параметры OOM Killer не придётся.
5️⃣ Если используемые вами приложения не имеют своих настроек по потреблению памяти, то настроить их и поведение OOM Killer можно с помощью Systemd. У меня была отдельная заметка по этой теме. Там ничего сложного.
6️⃣ Когда всё настроили и хотите посмотреть, как себя поведёт система, если вдруг памяти не останется, то займите её всю чем-нибудь. Например, утилитой stress. Или просто в консоли запустите:
# python3 -c 'a="a"*1073741824; input()'Заняли 1GB памяти. Подберите своё значение, чтобы памяти не осталось (2147483648 - 2GB, 3221225472 - 3GB и т.д.). После этого можно воспользоваться магической командой, про одну из которых я недавно писал:
# echo f > /proc/sysrq-triggerОна принудительно вызывает OOM Killer. Пример, конечно, так себе, потому что OOM Killer скорее всего грохнет запущенную команду (хотя в моих тестах первым умер systemd). Чтобы этого избежать, надо дать ей низкий Score:
# echo -16 > /proc/$(pgrep python3)/oom_adjЕщё раз вызываем киллера и смотрим, кого он прибьёт:
# echo f > /proc/sysrq-trigger# grep -i Killed /var/log/syslogУ меня systemd умер первым.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#terminal #linux
Есть общая рекомендация по использованию дисков в Linux – сначала создать раздел на диске, а потом использовать его по назначению. Даже если у вас будет один раздел на весь диск, сделайте его. То есть использовать не
Какой-то одной явной причины делать именно так нет, и чаще всего всё будет в порядке даже без разделов, но в некоторых ситуациях могут возникать проблемы. Я опишу некоторые из них.
Один читатель жаловался на то, что у него после перезагрузки разваливался рейд mdadm, хотя создавался без ошибок. Он выяснил, что есть версии BIOS, которые пишут какую-то информацию в начало диска и тем самым затирают метаданные mdadm. После того, как он создал разделы и собрал массив из них, он перестал разваливаться. Подозреваю, что это какая-то древняя версия BIOS, но тем не менее, случай реальный.
Ещё один случай от подписчика. У него коллега всегда использовал, как в текущей рекомендации, разделы. Как-то раз на сервере, где не им был добавлен в работу и использовался новый диск без разделов, он его по ошибке отредактировал, так как добавив другой новый диск ожидал именно его увидеть пустым, без разделов. По факту он ошибся, но если бы работающие диски были с разделами, этой ошибки бы не возникло.
В примере выше ошибся человек, но может ошибиться и программа. Некоторый софт считает диски без таблицы разделов неинициализированным или неиспользующимися и может предложить соответствующие действия с ним, которые могут привести к потере данных. Это больше относится к каким-то графическим приложениям нежели консольным. Также актуально, если диск будут куда-то переносить. Новая система может посчитать его неинициализированным.
В стародавние времена утилиты lsblk и blkid некорректно показывали информацию об идентификаторах, типах файловой системы на дисках без разделов.
Вся эта история тянется из прошлого. Как я уже сказал, сейчас возможно проблем и не будет, но тем не менее, лучше перестраховываться и создавать разделы. Я сам одно время не парился и если использовался весь диск, раздел не создавал. Потом узнал эту информацию и стал перестраховываться. Всегда создаю разделы, просто на всякий случай.
#совет #linux
/dev/sdb, а сделать на нём раздел, например с помощью cfdisk /dev/sdb, а потом уже использовать /dev/sdb1.Какой-то одной явной причины делать именно так нет, и чаще всего всё будет в порядке даже без разделов, но в некоторых ситуациях могут возникать проблемы. Я опишу некоторые из них.
Один читатель жаловался на то, что у него после перезагрузки разваливался рейд mdadm, хотя создавался без ошибок. Он выяснил, что есть версии BIOS, которые пишут какую-то информацию в начало диска и тем самым затирают метаданные mdadm. После того, как он создал разделы и собрал массив из них, он перестал разваливаться. Подозреваю, что это какая-то древняя версия BIOS, но тем не менее, случай реальный.
Ещё один случай от подписчика. У него коллега всегда использовал, как в текущей рекомендации, разделы. Как-то раз на сервере, где не им был добавлен в работу и использовался новый диск без разделов, он его по ошибке отредактировал, так как добавив другой новый диск ожидал именно его увидеть пустым, без разделов. По факту он ошибся, но если бы работающие диски были с разделами, этой ошибки бы не возникло.
В примере выше ошибся человек, но может ошибиться и программа. Некоторый софт считает диски без таблицы разделов неинициализированным или неиспользующимися и может предложить соответствующие действия с ним, которые могут привести к потере данных. Это больше относится к каким-то графическим приложениям нежели консольным. Также актуально, если диск будут куда-то переносить. Новая система может посчитать его неинициализированным.
В стародавние времена утилиты lsblk и blkid некорректно показывали информацию об идентификаторах, типах файловой системы на дисках без разделов.
Вся эта история тянется из прошлого. Как я уже сказал, сейчас возможно проблем и не будет, но тем не менее, лучше перестраховываться и создавать разделы. Я сам одно время не парился и если использовался весь диск, раздел не создавал. Потом узнал эту информацию и стал перестраховываться. Всегда создаю разделы, просто на всякий случай.
#совет #linux
Небольшой практический совет во время отладки в консоли Linux. Иногда хочется узнать, в каком окружении работает то или иное приложение. Поти вся информация о процессах в Linux живёт в
Всё в одну строчку. Не воспринимается глазами вообще. Можно ещё вот так посмотреть:
Тоже не очень наглядно. Так как у нас консоль и bash, то вывод можно как угодно обрабатывать, чтобы было удобно. Проще всего взять
или то же самое, но немного по-другому:
Я уже болен cat-офилией и привык везде её использовать. Уже даже не пытаюсь переучиться. Вместо
На выходе получаем аккуратный список окружения процесса, где можно увидеть нужные нам нюансы быстрее и нагляднее, чем где-то в другом месте. И запоминать особо не надо, конструкция несложная. Главное ключ
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #bash
/proc/<pid>, в том числе и об его окружении. Посмотреть можно так:# cat /proc/816/environLANG=en_US.UTF-8PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/binHOME=/var/lib/zabbixLOGNAME=zabbixUSER=zabbixSHELL=/sbin/nologinCONFFILE=/etc/zabbix/zabbix_agentd.confВсё в одну строчку. Не воспринимается глазами вообще. Можно ещё вот так посмотреть:
# ps e -ww -p 816Тоже не очень наглядно. Так как у нас консоль и bash, то вывод можно как угодно обрабатывать, чтобы было удобно. Проще всего взять
xargs, так как у него есть ключ --null, который позволяет разделять строку, используя разделителем так называемый NULL character. Я уже как-то раз писал про него. Иногда его удобно использовать, в том числе в find с ключом -print0.# cat /proc/816/environ | xargs --null --max-args=1или то же самое, но немного по-другому:
# xargs --null --max-args=1 echo < /proc/816/environLANG=en_US.UTF-8PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/binHOME=/var/lib/zabbixLOGNAME=zabbixUSER=zabbixSHELL=/sbin/nologinCONFFILE=/etc/zabbix/zabbix_agentd.confЯ уже болен cat-офилией и привык везде её использовать. Уже даже не пытаюсь переучиться. Вместо
grep постоянно делаю cat | grep. Вы выбирайте, что вам легче запоминается.На выходе получаем аккуратный список окружения процесса, где можно увидеть нужные нам нюансы быстрее и нагляднее, чем где-то в другом месте. И запоминать особо не надо, конструкция несложная. Главное ключ
--null запомнить.❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #bash
В стандартном репозитории Debian живёт неприметная и не особо популярная программа sosreport. Создана она была, судя по названию, для служб технической поддержки. Тем не менее, полезна может быть не только им. Она создаёт архив со слепком состояния системы. Этот архив включает в себя практически всю информацию о системе:
◽️Настройки Grub
◽️Все конфигурационные файлы из раздела
◽️Информация о ядре, модулях, настройках sysctl
◽️Объекты systemd
◽️Различная информация о системе: версия, точки монтирования, информация о железе, кроны, пользователи, настройки сети, установленные пакеты и т.д.
◽️Информация о пользователях, история логинов, параметры.
◽️Логи из
◽️И многое другое, функциональность расширяется плагинами, которые можно писать самостоятельно
По сути собрана вся доступная подробная информация о системе. Ставится так:
Использовать удобнее всего так:
Первый ключ отменяет интерактивные вопросы перед запуском, второй добавляет логи. На выходе получите архив в разделе
Архив будет иметь имя вида
Довольно удобная штука, чтобы быстро снять слепок состояния системы и потом спокойно его изучать, не боясь, что пока ты что-то ищешь или смотришь, состояние изменится. Так же предполагаю, что может быть полезно, например, раз в сутки делать такой слепок и складывать куда-то на некоторое время, просто на всякий случай. Архив получается маленький, проблем его хранить нет. Но в случае внештатной ситуации может помочь.
Ещё вариант применения - запускать по каким-то событиям мониторинга. Например, сработал триггер на загрузку процессора. Можно запустить скрипт с sosreport, который применит только плагин process и соберёт всю информацию о процессах.
Sosreport выполнит и сохранит вывод следующих команд:
Можно и самому всё это выполнить и вывести куда-то, но через sosreport удобнее. Он к тому же может сразу положить архив куда-то по ftp или sftp с помощью ключей
Я нечто подобное делала вручную и до сих пор использую. Описывал в своей статье:
⇨ Мониторинг списка запущенных процессов в Zabbix
Я там сделал более костыльно, но зато вывод сразу в history закидываю, чтобы можно было список процессов прямо в веб интерфейсе Zabbix смотреть.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #мониторинг
◽️Настройки Grub
◽️Все конфигурационные файлы из раздела
/etc◽️Информация о ядре, модулях, настройках sysctl
◽️Объекты systemd
◽️Различная информация о системе: версия, точки монтирования, информация о железе, кроны, пользователи, настройки сети, установленные пакеты и т.д.
◽️Информация о пользователях, история логинов, параметры.
◽️Логи из
/var/log и journalctl◽️И многое другое, функциональность расширяется плагинами, которые можно писать самостоятельно
По сути собрана вся доступная подробная информация о системе. Ставится так:
# apt install sosreportИспользовать удобнее всего так:
# sos report --batch --all-logsПервый ключ отменяет интерактивные вопросы перед запуском, второй добавляет логи. На выходе получите архив в разделе
/tmp. Директорию можно указать любую. Архив будет иметь имя вида
sosreport-337737-2025-04-15-acgbmpx.tar.xz. Его можно распаковать и смотреть прямо тут, либо передать куда-то в другое место, распаковать и запустить сгенерированную html страничку sos.html, которая лежит в директории sos_reports.Довольно удобная штука, чтобы быстро снять слепок состояния системы и потом спокойно его изучать, не боясь, что пока ты что-то ищешь или смотришь, состояние изменится. Так же предполагаю, что может быть полезно, например, раз в сутки делать такой слепок и складывать куда-то на некоторое время, просто на всякий случай. Архив получается маленький, проблем его хранить нет. Но в случае внештатной ситуации может помочь.
Ещё вариант применения - запускать по каким-то событиям мониторинга. Например, сработал триггер на загрузку процессора. Можно запустить скрипт с sosreport, который применит только плагин process и соберёт всю информацию о процессах.
# /usr/bin/sosreport --batch -o processSosreport выполнит и сохранит вывод следующих команд:
# ps auxwww# lsof -b +M -n -l -c ''# ps auxwwwm# ps alxwww# ps -elfL# ps axo pid,ppid,user,group,lwp,nlwp,start_time,comm,cgroup# ps axo flags,state,uid,pid,ppid,pgid,sid,cls,pri,addr,sz,wchan:20,lstart,tty,time,cmdМожно и самому всё это выполнить и вывести куда-то, но через sosreport удобнее. Он к тому же может сразу положить архив куда-то по ftp или sftp с помощью ключей
--upload, --upload-url, --upload-user, --upload-pass. Я нечто подобное делала вручную и до сих пор использую. Описывал в своей статье:
⇨ Мониторинг списка запущенных процессов в Zabbix
Я там сделал более костыльно, но зато вывод сразу в history закидываю, чтобы можно было список процессов прямо в веб интерфейсе Zabbix смотреть.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #мониторинг
Я очень много лет использовал в Linux утилиту screen для того, чтобы в случае обрыва связи при подключении по SSH не завершалось выполнение запущенных интерактивных операций. Особенно это касается обновлений системы через apt или dnf. Типичная проблема, не считая банального обрыва связи, - подключился по VPN к серверу, запустил обновление, обновился софт для VPN, тебя отключило, обновление завершилось на середине процесса. Это может привести к проблемам (система не загрузилась из-за прерванного обновления).
В screen меня всегда раздражало то, что после открытия и сворачивания Midnight Commander по комбинации клавиш CTRL + o, очищался терминал и ты не видел то, что там было до этого. Частично помогает скрол окна SSH клиента, но это неудобно и всё равно часть информации пропадает, обрезается.
В tmux такой проблемы нет. Всё работает ожидаемо, можно разворачивать, сворачивать MC, содержимое терминала не очищается. В итоге у меня на половине серверов по старинке screen стоит, на другой - tmux. Я никакими дополнительными возможностями tmux и screen не пользуюсь, мне главное при обрыве соединения вернуться в свою сессию. В screen привык к горячим клавишам и ключам и переучиваться на tmux не хотелось, так как нет большого смысла.
Оказывается, внутри screen есть свой скролер терминала. Достаточно нажать CTRL + a и потом [, откроется скролинг, где клавиашми PgUp / PgDn можно мотать вверх и вниз и читать содержимое терминала, в том числе то, что там было до запуска MC.
Возможно кому-то эта заметка поможет. Жаль, что я раньше об этом не узнал, столько лет раздражала эта фигня, примерно так же, как лесенка в MC, пока не узнал, как от неё избавиться.
Если кто только выбирает, что использовать, screen или tmux, рекомендую последний. По основным возможностям там примерно одно и то же, у tmux даже их больше, а по удобству, очевидности стандартных настроек, tmux тоже выигрывает. Я уже привык к screen, не хочется переучиваться, так как ничего принципиально нового для себя не получу. У tmux до сих пор подсматриваю горячие клавиши и ключи. Для screen это уже давно в голове отложилось и на автомате выполняется.
Когда-то давно опрос делал по поводу screen и tmux, кто чем пользуется. Результат был примерно 50 / 50. Примерно равная популярность у этих утилит. Сейчас ещё Zellij прибавилась. Но не думаю, что она сильно популярна и не станет таковой, пока не приедет в базовые репы. Вы что предпочитаете из этой троицы?
#linux #terminal
В screen меня всегда раздражало то, что после открытия и сворачивания Midnight Commander по комбинации клавиш CTRL + o, очищался терминал и ты не видел то, что там было до этого. Частично помогает скрол окна SSH клиента, но это неудобно и всё равно часть информации пропадает, обрезается.
В tmux такой проблемы нет. Всё работает ожидаемо, можно разворачивать, сворачивать MC, содержимое терминала не очищается. В итоге у меня на половине серверов по старинке screen стоит, на другой - tmux. Я никакими дополнительными возможностями tmux и screen не пользуюсь, мне главное при обрыве соединения вернуться в свою сессию. В screen привык к горячим клавишам и ключам и переучиваться на tmux не хотелось, так как нет большого смысла.
Оказывается, внутри screen есть свой скролер терминала. Достаточно нажать CTRL + a и потом [, откроется скролинг, где клавиашми PgUp / PgDn можно мотать вверх и вниз и читать содержимое терминала, в том числе то, что там было до запуска MC.
Возможно кому-то эта заметка поможет. Жаль, что я раньше об этом не узнал, столько лет раздражала эта фигня, примерно так же, как лесенка в MC, пока не узнал, как от неё избавиться.
Если кто только выбирает, что использовать, screen или tmux, рекомендую последний. По основным возможностям там примерно одно и то же, у tmux даже их больше, а по удобству, очевидности стандартных настроек, tmux тоже выигрывает. Я уже привык к screen, не хочется переучиваться, так как ничего принципиально нового для себя не получу. У tmux до сих пор подсматриваю горячие клавиши и ключи. Для screen это уже давно в голове отложилось и на автомате выполняется.
Когда-то давно опрос делал по поводу screen и tmux, кто чем пользуется. Результат был примерно 50 / 50. Примерно равная популярность у этих утилит. Сейчас ещё Zellij прибавилась. Но не думаю, что она сильно популярна и не станет таковой, пока не приедет в базовые репы. Вы что предпочитаете из этой троицы?
#linux #terminal
В Debian есть интересная библиотека libeatmydata, которая подменяет системные вызовы fsync, fdatasync, sync и некоторые другие на пустышки. Эти команды сразу выдают положительный результат, ничего не делая. То есть не работает подтверждение записи на диск.
Это существенно ускоряет все операции записи, но и, что логично, создаёт вероятность потери данных, так как реально они залетают в кэш, а не на диск. И будут записаны в зависимости от настроек и параметров системы, когда ядро посчитает нужным выполнить синхронизацию: по таймеру фоновой синхронизации или недостатка свободной оперативной памяти.
Работает это примерно так:
Реально там ещё пару проверок с if, но по сути всё так и есть для всех системных вызовов, что она она перехватывает.
Эту возможность без особых опасений можно использовать во временных или тестовых средах, где не важна сохранность данных. Причём сделать это очень просто. Ставим пакет:
Запускаем через него любую команду. Я протестировал на старой виртуалке, которую давно не обновляли. Сделал запуск обновления без eatmydata и с ней. Разница получилась заметной.
Напомню, что реальной установкой пакетов занимается утилита
Я выполнил полное обновление пакетов в два этапа, откатив первое обновление на изначальный снепшот:
Работа dpkg занимает где-то треть всего времени, ещё треть загрузка пакетов, и треть пересборка initramfs. Без eatmydata dpkg работала примерно 30 секунд, с ней – 20.
Или вот ещё более наглядный тест. Запускаем создание файла в режиме синхронизации и подтверждения записи каждого блока:
И то же самое через eatmydata:
Эта возможность может пригодиться при сборке контейнеров, образов, раскатки тестовых сред. Можно запускать тестовую СУБД через eatmydata. Да всё, что угодно на тестовом сервере.
Если у вас есть какие-то скрипты, которые не хочется переделывать, добавляя в начало каждой команды eatmydata, можете просто задать переменную окружения, в том числе глобальную в
И все процессы будут писать без подтверждения записи в кэш.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux
Это существенно ускоряет все операции записи, но и, что логично, создаёт вероятность потери данных, так как реально они залетают в кэш, а не на диск. И будут записаны в зависимости от настроек и параметров системы, когда ядро посчитает нужным выполнить синхронизацию: по таймеру фоновой синхронизации или недостатка свободной оперативной памяти.
Работает это примерно так:
int fsync(int fd) {
return 0;
}Реально там ещё пару проверок с if, но по сути всё так и есть для всех системных вызовов, что она она перехватывает.
Эту возможность без особых опасений можно использовать во временных или тестовых средах, где не важна сохранность данных. Причём сделать это очень просто. Ставим пакет:
# apt install eatmydataЗапускаем через него любую команду. Я протестировал на старой виртуалке, которую давно не обновляли. Сделал запуск обновления без eatmydata и с ней. Разница получилась заметной.
Напомню, что реальной установкой пакетов занимается утилита
dpkg, а не apt. Dpkg для надёжности выполняет все действия с подтверждением записи. Так что если запустить её через eatmydata, она отработает гораздо быстрее. Я выполнил полное обновление пакетов в два этапа, откатив первое обновление на изначальный снепшот:
# time apt upgrade -yFetched 249 MB in 30s (8,183 kB/s)real 1m 43.690s# time eatmydata apt upgrade -yFetched 249 MB in 33s (7,671 kB/s)real 1m 36.984sРабота dpkg занимает где-то треть всего времени, ещё треть загрузка пакетов, и треть пересборка initramfs. Без eatmydata dpkg работала примерно 30 секунд, с ней – 20.
Или вот ещё более наглядный тест. Запускаем создание файла в режиме синхронизации и подтверждения записи каждого блока:
# dd if=/dev/zero of=/mnt/tempfile bs=1M count=512 oflag=dsync536870912 bytes (537 MB, 512 MiB) copied, 1.95211 s, 275 MB/sИ то же самое через eatmydata:
# eatmydata dd if=/dev/zero of=/mnt/tempfile bs=1M count=512 oflag=dsync536870912 bytes (537 MB, 512 MiB) copied, 0.343773 s, 1.6 GB/sЭта возможность может пригодиться при сборке контейнеров, образов, раскатки тестовых сред. Можно запускать тестовую СУБД через eatmydata. Да всё, что угодно на тестовом сервере.
Если у вас есть какие-то скрипты, которые не хочется переделывать, добавляя в начало каждой команды eatmydata, можете просто задать переменную окружения, в том числе глобальную в
/etc/environment:LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libeatmydata.soИ все процессы будут писать без подтверждения записи в кэш.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux
Настраивал на днях арендованный сервер без прямого доступа к консоли. Ещё и конфигурация была нестандартная, так что техподдержка вручную установила туда ОС и отдала мне с доступом по SSH. Нужно было настроить дополнительные диски и добавить их в fstab. Несмотря на то, что в современных ОС реально монтирует диски systemd, я по старинке предпочитаю добавлять новые точки монтирования в fstab.
В этом деле самое главное – не ошибиться и сразу после изменения файла проверить, что там всё в порядке. Иначе после перезагрузки можно получить проблемы. Без прямого доступа к консоли это может быть фатально.
Я обычно добавляю новые диски в систему следующим образом. Смотрю список дисков через fstab:
Сразу видно диски без разметки. Добавлять разделы предпочитаю в cfdisk, а не напрямую в консоли через fstab. В TUI как-то нагляднее, меньше шансов ошибиться.
Создаю раздел, выбираю тип раздела, сохраняю. После этого можно создавать файловую систему.
Монтирую в систему:
Теперь нам надо добавить эту точку монтирования в fstab. По имени диска категорически нельзя добавлять. Диски могут менять свои имена. Причём это стало актуально в какой-то момент с очередным обновлением железа. Когда я только начинал изучать Linux, спокойно монтировал по именам дисков и проблем не было. В какой-то момент они начались. И сейчас я сам часто наблюдаю, что диски, как и сетевые интерфейсы, могут изменить свои имена после перезагрузки. Если используете LVM, то можно добавлять точки монтирования по имени LV.
Смотрим UUID раздела:
Добавляем его в fstab отдельной строкой:
А теперь проверяем, всё ли мы правильно добавили.
Findmnt проверил все монтирования. В моём случае я получил предупреждение на /media/cdrom0.
Судя по всему систему ставили с какого-то диска, локального или сетевого, не знаю, но он остался в fstab. Делать ему там больше нечего, можно закомментировать строку с ним.
Более кратко можно получить информацию только об ошибках:
☝️Отдельно обращаю внимание на такой момент. До перехода управления к systemd было критически важно оставлять в fstab в конце файла переход на новую строку. Сейчас даже если этого не сделать, то проблем не будет. Всё нормально загрузится. Насколько я понимаю, это тянется из далёкого прошлого и POSIX-совместимой практики, когда файлы конфигурации заканчивались переходом на новую строку. Я лично до сих пор на всякий случай везде этой практики придерживаюсь.
Ещё один способ проверить корректность записей в fstab – использовать mount. Можно не монтировать вручную новый диск, а сразу добавить его в fstab. Потом запустить:
Утилита смонтирует все записи из файла, где не указан параметр noauto. Если вы всё верно добавили, то ошибок не увидите и получите смонтированным новый диск.
Расскажу, что будет, если, к примеру, ошибётесь с диском в fstab или он просто перестанет быть видим в системе. Я лично с этим не раз сталкивался. А однажды это привело к дальней дороге. Добавили наживую новый диск в сервер, я его добавил с ошибкой в fstab и не проверил. Сервер аварийно перезагрузился через полгода из-за обесточивания серверной. Возникли какие-то проблемы с доступом туда, ещё и сервер по неизвестной на тот момент мне причине не стартанул. Приехал туда ножками и увидел примерно то же самое, что вы видите на втором скрине.
Сразу понял, в чём дело, зашёл в режим обслуживания и поправил fstab. Так что внимательно относитесь к его настройке. Этой проблемы можно избежать, если использовать nofail в параметрах монтирования. Но с ним могут быть нюансы. Иногда лучше не загрузиться, если с разделом проблемы.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux
В этом деле самое главное – не ошибиться и сразу после изменения файла проверить, что там всё в порядке. Иначе после перезагрузки можно получить проблемы. Без прямого доступа к консоли это может быть фатально.
Я обычно добавляю новые диски в систему следующим образом. Смотрю список дисков через fstab:
# fdisk -l | grep /dev/Сразу видно диски без разметки. Добавлять разделы предпочитаю в cfdisk, а не напрямую в консоли через fstab. В TUI как-то нагляднее, меньше шансов ошибиться.
# cfdisk /dev/sdbСоздаю раздел, выбираю тип раздела, сохраняю. После этого можно создавать файловую систему.
# mkfs -t ext4 /dev/sdb1Монтирую в систему:
# mkdir /mnt/disk1# mount /dev/sdb1 /mnt/disk1Теперь нам надо добавить эту точку монтирования в fstab. По имени диска категорически нельзя добавлять. Диски могут менять свои имена. Причём это стало актуально в какой-то момент с очередным обновлением железа. Когда я только начинал изучать Linux, спокойно монтировал по именам дисков и проблем не было. В какой-то момент они начались. И сейчас я сам часто наблюдаю, что диски, как и сетевые интерфейсы, могут изменить свои имена после перезагрузки. Если используете LVM, то можно добавлять точки монтирования по имени LV.
Смотрим UUID раздела:
# blkid | grep /dev/sdb1Добавляем его в fstab отдельной строкой:
UUID=eaf5c153-08b7-4ea8-8037-e6baad4cac0d /mnt/disk1 ext4 errors=remount-ro 1 0А теперь проверяем, всё ли мы правильно добавили.
# findmnt --verify --verboseFindmnt проверил все монтирования. В моём случае я получил предупреждение на /media/cdrom0.
[W] unreachable source: /dev/sr0: No such file or directoryСудя по всему систему ставили с какого-то диска, локального или сетевого, не знаю, но он остался в fstab. Делать ему там больше нечего, можно закомментировать строку с ним.
Более кратко можно получить информацию только об ошибках:
# findmnt -x☝️Отдельно обращаю внимание на такой момент. До перехода управления к systemd было критически важно оставлять в fstab в конце файла переход на новую строку. Сейчас даже если этого не сделать, то проблем не будет. Всё нормально загрузится. Насколько я понимаю, это тянется из далёкого прошлого и POSIX-совместимой практики, когда файлы конфигурации заканчивались переходом на новую строку. Я лично до сих пор на всякий случай везде этой практики придерживаюсь.
Ещё один способ проверить корректность записей в fstab – использовать mount. Можно не монтировать вручную новый диск, а сразу добавить его в fstab. Потом запустить:
# mount -a -vУтилита смонтирует все записи из файла, где не указан параметр noauto. Если вы всё верно добавили, то ошибок не увидите и получите смонтированным новый диск.
Расскажу, что будет, если, к примеру, ошибётесь с диском в fstab или он просто перестанет быть видим в системе. Я лично с этим не раз сталкивался. А однажды это привело к дальней дороге. Добавили наживую новый диск в сервер, я его добавил с ошибкой в fstab и не проверил. Сервер аварийно перезагрузился через полгода из-за обесточивания серверной. Возникли какие-то проблемы с доступом туда, ещё и сервер по неизвестной на тот момент мне причине не стартанул. Приехал туда ножками и увидел примерно то же самое, что вы видите на втором скрине.
Сразу понял, в чём дело, зашёл в режим обслуживания и поправил fstab. Так что внимательно относитесь к его настройке. Этой проблемы можно избежать, если использовать nofail в параметрах монтирования. Но с ним могут быть нюансы. Иногда лучше не загрузиться, если с разделом проблемы.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux
На тему LA (Load Average) написано очень много материалов. Про неё любят спрашивать на собеседованиях, писать тематические статьи и проводить уроки различные онлайн школы. Это прям горячая тема. Я когда-то давно в одной переведённой с иностранного материала статье на хабре увидел очень хорошую аналогию LA с загрузкой шоссе машинами и сразу запомнил её. Не встречал с тех пор наглядных объяснений в таком контексте. Расскажу кратко тем, кто до конца не понимает, что эта загрузка означает.
Пара примеров, почему LA неоднозначна. Можно зайти на сервер, увидеть LA под 100, но при этом процессор будет не нагружен вообще. Это тупит примонтированный сетевой диск, например, по NFS или iSCSI. Или LA в 30 может показаться запредельно большой, но если на сервере 36 ядер и нагрузка хоть и большая, но в целом сервер её вывозит.
Для однопроцессорной системы понять логику измерения Load Average можно с помощью картинки во вложении. Для простоты восприятия LA сравнивают с транспортным потоком на мосту. Значение более 1 означает наличие очереди на въезде на мост. Размер этой очереди будет равен превышению единицы. Например, значение 1,7 показывает, что в очереди стоит 70% от числа машин, находящихся на мосту.
В ядре Linux процессы, выполняющиеся в данный момент, это машины на мосту, а процессы, ожидающие очереди на исполнение, это машины в пробке на въезде на мост. Причем очередь из процессов может образовываться не только из-за загруженности процессора, но и других компонентов системы. Например, подсистемы ввода-вывода (диск, сеть).
Идеально, когда пробки нет, никто никого не ждёт, есть запас по пропускной способности моста. Многопроцессорная система - это сумма таких мостов. Каждый увеличивает пропускную способность на единицу. Загрузка 1 для двух мостов означает нагрузку на мосты в 50%, для трёх на 33%. Ну и так далее. Очень просто и наглядно.
Если кто-то знает более простые и наглядные аналогии, расскажите.
И в продолжении этой темы добавлю ссылку на мою недавнюю заметку на тему метрики IOWait. Она тоже очень неоднозначна и может своими показаниями вводить в заблуждение, если не знаешь нюансов. Там, к сожалению, нет простой аналогии, нужно вчитаться и понять без аналогий, о чём идёт речь. Но информация важная, если вам приходится разбираться с производительностью систем на базе Linux.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #perfomance
Пара примеров, почему LA неоднозначна. Можно зайти на сервер, увидеть LA под 100, но при этом процессор будет не нагружен вообще. Это тупит примонтированный сетевой диск, например, по NFS или iSCSI. Или LA в 30 может показаться запредельно большой, но если на сервере 36 ядер и нагрузка хоть и большая, но в целом сервер её вывозит.
Для однопроцессорной системы понять логику измерения Load Average можно с помощью картинки во вложении. Для простоты восприятия LA сравнивают с транспортным потоком на мосту. Значение более 1 означает наличие очереди на въезде на мост. Размер этой очереди будет равен превышению единицы. Например, значение 1,7 показывает, что в очереди стоит 70% от числа машин, находящихся на мосту.
В ядре Linux процессы, выполняющиеся в данный момент, это машины на мосту, а процессы, ожидающие очереди на исполнение, это машины в пробке на въезде на мост. Причем очередь из процессов может образовываться не только из-за загруженности процессора, но и других компонентов системы. Например, подсистемы ввода-вывода (диск, сеть).
Идеально, когда пробки нет, никто никого не ждёт, есть запас по пропускной способности моста. Многопроцессорная система - это сумма таких мостов. Каждый увеличивает пропускную способность на единицу. Загрузка 1 для двух мостов означает нагрузку на мосты в 50%, для трёх на 33%. Ну и так далее. Очень просто и наглядно.
Если кто-то знает более простые и наглядные аналогии, расскажите.
И в продолжении этой темы добавлю ссылку на мою недавнюю заметку на тему метрики IOWait. Она тоже очень неоднозначна и может своими показаниями вводить в заблуждение, если не знаешь нюансов. Там, к сожалению, нет простой аналогии, нужно вчитаться и понять без аналогий, о чём идёт речь. Но информация важная, если вам приходится разбираться с производительностью систем на базе Linux.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #perfomance
На днях столкнулся в небольшой ошибкой в скриптах для бэкапа, когда настраивал их работу через cron. Я уже не раз упоминал, что в скриптах лучше всегда писать полные пути. Я это обычно соблюдаю, особенно для исполняемых файлов. А тут ошибся немного в другом.
Делал большой скрипт, где было много разных операций, в том числе одна из них была с rsync. Строка выглядела примерно так:
Я тут раскрыл все переменные, чтобы было понятно, о чём идёт речь, кроме одной -
То есть просто указал на файл, который лежит тут же в директории. Когда отлаживаешь и запускаешь вручную - всё работает. А через cron - нет. А так как в скрипте было много различных действий, я сходу не смог понять, почему не работает конкретно эта синхронизация. Несколько раз глазами пробежал, не пойму, где ошибка и почему всё работает, а конкретно это не синхронизируется. Вывод rsync направлен в лог, обычно там его ошибки видно, но не в этот раз. Он просто не запускался.
Потом заглянул в системную почту, и там всё понятно:
Rsync просто даже не запускался из-за того, что не видел этот файл. В общем, очередное напоминание, что в скриптах лучше всегда всё писать с полными путями, чтобы потом не тратить время на отладку.
Кто-то может подсказать, как сделать так, чтобы в скрипте был относительный путь на файл, лежащий в этой же директории, и чтобы он корректно работал в cron. Я не могу сообразить, как это сделать. Всегда в списке переменных в самом начале пишу актуальные пути под конкретный сервер, чтобы потом с этим не разбираться.
#linux #cron
Делал большой скрипт, где было много разных операций, в том числе одна из них была с rsync. Строка выглядела примерно так:
/usr/bin/rsync --progress -av --delete --delete-excluded --exclude-from=$EXCLUDE_LST -e "ssh -p 31008" user@1.2.3.4:/home/bitrix/ext_www/site01 /mnt/backups/site01/www --backup --backup-dir=/mnt/backups/site01/www_increment/`date +%Y-%m-%d`/`date +%H-%M-%S` 2>&1 >> /mnt/backups/site01/log.txtЯ тут раскрыл все переменные, чтобы было понятно, о чём идёт речь, кроме одной -
$EXCLUDE_LST. Это файл со списком исключений. Задал его вот так:EXCLUDE_LST=exclude-site01.lstТо есть просто указал на файл, который лежит тут же в директории. Когда отлаживаешь и запускаешь вручную - всё работает. А через cron - нет. А так как в скрипте было много различных действий, я сходу не смог понять, почему не работает конкретно эта синхронизация. Несколько раз глазами пробежал, не пойму, где ошибка и почему всё работает, а конкретно это не синхронизируется. Вывод rsync направлен в лог, обычно там его ошибки видно, но не в этот раз. Он просто не запускался.
Потом заглянул в системную почту, и там всё понятно:
rsync: [client] failed to open exclude file exclude-site01.lst: No such file or directory (2)rsync error: error in file IO (code 11) at exclude.c(1481) [client=3.2.7]Rsync просто даже не запускался из-за того, что не видел этот файл. В общем, очередное напоминание, что в скриптах лучше всегда всё писать с полными путями, чтобы потом не тратить время на отладку.
Кто-то может подсказать, как сделать так, чтобы в скрипте был относительный путь на файл, лежащий в этой же директории, и чтобы он корректно работал в cron. Я не могу сообразить, как это сделать. Всегда в списке переменных в самом начале пишу актуальные пути под конкретный сервер, чтобы потом с этим не разбираться.
#linux #cron
Уже не первый раз сталкиваюсь с ситуацией, что получаешь арендную VPS, а там по умолчанию уже настроены сетевые интерфейсы и ipv4, и ipv6. Делаешь обновление системы через apt, он подключается по ipv6 и ничего не качает, пишет, что no longer has a Release file. Столкнулся вчера лично с репозиторием от Яндекса:
В рунете он популярен. Я и сам всегда его использую. Не знаю, кто тут виноват, сам провайдер или Яндекс (позже выяснилось, что Яндекс, подробности в конце). Не вижу смысла разбираться и тратить время. В данном случае проще отключить ipv6. Это можно сделать разными способами. Можно конкретно apt заставить работать через ipv4. У него есть параметр для этого:
Постоянно так писать не будешь, можно добавить в конфигурацию, создав файл
Я лично поступил проще. Отключил ipv6 на уровне системы. Добавил в
И применил их:
Настройки ipv6 на сетевом интерфейсе сразу пропали, apt успешно заработал по ipv4.
Более радикальный способ отключения через GRUB, но тогда придётся обновлять загрузчик, пересобирать initramfs. Плюс, понадобится перезагрузка. Для этого в его конфиг
После этого нужно обновить загрузчик. В зависимости от системы выглядеть это может по-разному. В Debian можно так:
Заметил ещё такую особенность. До того, как отключил ipv6, заметил, что apt работает то по ipv4, то по ipv6. Можно было несколько раз его запустить и получить желаемый результат. Не знаю, с чем это может быть связано. Возможно первый резолв доменного имени идёт на DNS запись AAAA, а если подключение неудачно, то потом на A. Но не уверен, что это так. Просто догадки.
Уже после написания заметки решил повнимательнее разобраться, что реально происходит в apt при обращении по ipv6 и ipv4. Для этого сделал два отдельных запроса по разным протоколам:
Первый нормально отрабатывает и загружает файл InRelease. А во втором случае репозиторий Яндекса отвечает:
То есть DNS запись для mirror.yandex.ru есть:
Но Nginx, который раздаёт контент, не настроен для работы по ipv6. Не знаю, зачем так сделали. Если не настроили Nginx, зачем настроили ipv6? 🤷♂️ Может какие-то временные проблемы.
☝️В целом, с ipv6 такое бывает, поэтому если не используете, лучше сразу отключить.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #network #ipv6
http://mirror.yandex.ru/debian bookworm mainВ рунете он популярен. Я и сам всегда его использую. Не знаю, кто тут виноват, сам провайдер или Яндекс (позже выяснилось, что Яндекс, подробности в конце). Не вижу смысла разбираться и тратить время. В данном случае проще отключить ipv6. Это можно сделать разными способами. Можно конкретно apt заставить работать через ipv4. У него есть параметр для этого:
# apt -o Acquire::ForceIPv4=true upgradeПостоянно так писать не будешь, можно добавить в конфигурацию, создав файл
/etc/apt/apt.conf.d/disable-ipv6 следующего содержания:Acquire::ForceIPv4 "true";Я лично поступил проще. Отключил ipv6 на уровне системы. Добавил в
/etc/sysctl.conf пару параметров:net.ipv6.conf.all.disable_ipv6 = 1net.ipv6.conf.default.disable_ipv6 = 1И применил их:
# sysctl -pНастройки ipv6 на сетевом интерфейсе сразу пропали, apt успешно заработал по ipv4.
Более радикальный способ отключения через GRUB, но тогда придётся обновлять загрузчик, пересобирать initramfs. Плюс, понадобится перезагрузка. Для этого в его конфиг
/etc/default/grub, конкретно в параметр GRUB_CMDLINE_LINUX, нужно добавить значение ipv6.disable=1. Если там уже указаны другие значения, то перечислены они должны быть через пробел. Примерно так:GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet ipv6.disable=1"После этого нужно обновить загрузчик. В зависимости от системы выглядеть это может по-разному. В Debian можно так:
# dpkg-reconfigure grub-pcЗаметил ещё такую особенность. До того, как отключил ipv6, заметил, что apt работает то по ipv4, то по ipv6. Можно было несколько раз его запустить и получить желаемый результат. Не знаю, с чем это может быть связано. Возможно первый резолв доменного имени идёт на DNS запись AAAA, а если подключение неудачно, то потом на A. Но не уверен, что это так. Просто догадки.
Уже после написания заметки решил повнимательнее разобраться, что реально происходит в apt при обращении по ipv6 и ipv4. Для этого сделал два отдельных запроса по разным протоколам:
# apt -o Debug::Acquire::http=true -o Acquire::ForceIPv4=true update# apt -o Debug::Acquire::http=true -o Acquire::ForceIPv6=true updateПервый нормально отрабатывает и загружает файл InRelease. А во втором случае репозиторий Яндекса отвечает:
Answer for: http://mirror.yandex.ru/debian/dists/bookworm/InReleaseHTTP/1.1 404 Not FoundServer: nginx/1.24.0 (Ubuntu)............................................................Err:2 http://mirror.yandex.ru/debian bookworm Release 404 Not Found [IP: 2a02:6b8::183 80]То есть DNS запись для mirror.yandex.ru есть:
# dig +short mirror.yandex.ru AAAA2a02:6b8::183Но Nginx, который раздаёт контент, не настроен для работы по ipv6. Не знаю, зачем так сделали. Если не настроили Nginx, зачем настроили ipv6? 🤷♂️ Может какие-то временные проблемы.
☝️В целом, с ipv6 такое бывает, поэтому если не используете, лучше сразу отключить.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #network #ipv6
В репозиториях Debian живёт полезная утилита debootstrap, с помощью которой можно собрать работающую систему в каталоге в уже запущенной ОС. Либо взять уже готовую. Применений у этой технологии может быть много.
Например, можно создать диск в оперативной памяти, установить туда систему через debootstrap, сделать туда chroot, туда же для надёжности можно установить openssh-server и подключиться напрямую. И уже из этой системы делать с работающей всё, что угодно. Можно полностью очистить жёсткий диск перед окончанием аренды виртуалки. Можно поверх работающей системы установить совершенно другую, которую не поддерживает панель управления хостера.
Покажу на практике, как это работает. Ставим debootstrap и сразу с его помощью скачиваем образ системы Debian 12 в каталог /mnt/debootstrap:
Монтируем туда из работающей системы оборудование:
И заходим туда:
Мы оказываемся в чистой минимальной системе на базе Debinan 12 Bookworm. Можем делать в ней всё, что угодно. Зададим пароль root, установим некоторый софт:
Разрешим подключаться пользователю root по ssh сразу внутрь изоляции:
Закрываем, сохраняем, перезапускаем openssh сервер:
Выходим из chroot:
Теперь туда можно подключиться напрямую по SSH, как на любой другой сервер:
Вы оказались в вашей новой системе. Можете там делать, что угодно.
Теперь представим, что вам нужно гарантированно очистить содержимое дисков работающей системы. Для этого создаём в оперативной памяти раздел на 2GB. Можно и меньше, если памяти совсем мало, так как минимальный образ для debootstrap меньше 1GB:
Копируем туда подготовленную ранее систему:
Монтируем оборудование и подключаемся:
Запускаем ssh-сервер и подключаемся напрямую:
Теперь можем делать с системой всё, что угодно. Например, полностью очистить содержимое диска, в том числе корневого раздела основной системы. Смотрим список разделов:
У меня один диск и три раздела: sda1, sda2, sda5. Полностью очищаем все из них. После этого восстановить информацию будет невозможно:
Всё, систем надёжно убита. Можно так делать после того, как отказались от аренды. Особенно если у вас там какие-то впны были настроены или использовались другие учётные данные, которые могли остаться где-то в системе.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux
Например, можно создать диск в оперативной памяти, установить туда систему через debootstrap, сделать туда chroot, туда же для надёжности можно установить openssh-server и подключиться напрямую. И уже из этой системы делать с работающей всё, что угодно. Можно полностью очистить жёсткий диск перед окончанием аренды виртуалки. Можно поверх работающей системы установить совершенно другую, которую не поддерживает панель управления хостера.
Покажу на практике, как это работает. Ставим debootstrap и сразу с его помощью скачиваем образ системы Debian 12 в каталог /mnt/debootstrap:
# apt install debootstrap# mkdir /mnt/debootstrap# debootstrap bookworm /mnt/debootstrap http://deb.debian.org/debianМонтируем туда из работающей системы оборудование:
# mount --bind /dev /mnt/debootstrap/dev# mount --bind /dev/pts /mnt/debootstrap/dev/pts# mount --bind /proc /mnt/debootstrap/proc# mount --bind /sys /mnt/debootstrap/sysИ заходим туда:
# chroot /mnt/debootstrapМы оказываемся в чистой минимальной системе на базе Debinan 12 Bookworm. Можем делать в ней всё, что угодно. Зададим пароль root, установим некоторый софт:
# passwd# apt install tmux openssh-serverРазрешим подключаться пользователю root по ssh сразу внутрь изоляции:
# nano /etc/ssh/sshd_configPort 222PermitRootLogin yesЗакрываем, сохраняем, перезапускаем openssh сервер:
# /etc/init.d/ssh restartВыходим из chroot:
# exitТеперь туда можно подключиться напрямую по SSH, как на любой другой сервер:
$ ssh -p 222 root@10.20.1.9Вы оказались в вашей новой системе. Можете там делать, что угодно.
Теперь представим, что вам нужно гарантированно очистить содержимое дисков работающей системы. Для этого создаём в оперативной памяти раздел на 2GB. Можно и меньше, если памяти совсем мало, так как минимальный образ для debootstrap меньше 1GB:
# mkdir /mnt/chroot# mount -t tmpfs -o size=2G tmpfs /mnt/chrootКопируем туда подготовленную ранее систему:
# cp -R /mnt/debootstrap/* /mnt/chrootМонтируем оборудование и подключаемся:
# mount --bind /dev /mnt/chroot/dev# mount --bind /dev/pts /mnt/chroot/dev/pts# mount --bind /proc /mnt/chroot/proc# mount --bind /sys /mnt/chroot/sys# chroot /mnt/chrootЗапускаем ssh-сервер и подключаемся напрямую:
# /etc/init.d/ssh start# exit$ ssh -p 222 root@10.20.1.9Теперь можем делать с системой всё, что угодно. Например, полностью очистить содержимое диска, в том числе корневого раздела основной системы. Смотрим список разделов:
# fdisk -lУ меня один диск и три раздела: sda1, sda2, sda5. Полностью очищаем все из них. После этого восстановить информацию будет невозможно:
# shred -u -z -v /dev/sda{1,2,5}Всё, систем надёжно убита. Можно так делать после того, как отказались от аренды. Особенно если у вас там какие-то впны были настроены или использовались другие учётные данные, которые могли остаться где-то в системе.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux
Почти всегда, когда надо скопировать файлы с сервера на сервер, использую либо scp, либо rsync. Первый для одиночных файлов, второй для директорий. На прошлой неделе нужно было с одного старого сервера перенести выборочно кучу разрозненных файлов на другой. Вспомнил про возможность Midnight Commander, где одной из панелей с обзором файлов может выступать удалённый сервер. Это очень удобно как раз для моей задачи. Я очень редко этим пользуюсь. Даже не знаю, почему. Нет такой привычки. Хотя объективно это удобнее, чем ходить по каталогам и запускать rsync, вспоминая его ключи, особенно если надо использовать нестандартный порт SSH.
MC поддерживает два разных протокола для передачи - SFTP (SSH File Transfer Protocol) или FISH (Files transferred over Shell protocol). Последний в разделе меню называется как Shell link. По названию не совсем понятно, что это такое. На первый взгляд кажется, что в контексте передачи файлов это одно и то же. Но на деле нет. И я как раз столкнулся лично с различиями.
Сервер, с которого я подключался, был старее того, куда надо было копировать. Там вроде бы Debian 11 стоял, я копировал на 12-й. К сожалению, не могу уточнить, сервер удалён уже, а сразу не было времени подробно разбираться. Сначала использовал sftp и ни в какую не мог подключиться. Постоянно в логе принимающего севера были ошибки в auth.log на тему то ли использовавшихся шифров, то ли формата сертификата. Сразу не записал, только пометил себе сделать об этом заметку.
При этом я спокойно подключался из консоли по ssh к удалённому серверу с тем же сертификатом или паролем. Попробовал в MC подключение по Shell link и сразу подключился. Перекинул файлы и разбираться уже не стал. Позже пробовал с разными серверами использовать разные протоколы - везде работали оба.
В целом, разница понятна, так как протоколы передачи совершенно разные. Лучше использовать более привычный и распространённый sftp, если он разрешён и настроен на принимающем сервере. Это не всегда бывает так. Как и обратная ситуация. Может быть разрешён sftp, но запрещён обычный shell. А подключению по fish как раз нужен хотя бы sh на принимающей стороне. Так что если не подключается один протокол, пробуйте другой.
☝️ Отдельно отмечу такую фишку MC. Вы можете в левой панели открыть один удалённый сервер, а в правой - другой. И не настраивая прямого соединения между этими серверами перекинуть файлы, выступая со своим MC как посредник.
Настраиваются такие подключения так: нажимаем F9 -> Right или Left, то есть выбираем нужную нам панель, потом раздел меню Shell link или SFTP link. Формат подключения типичный для ssh -
На подобные заметки постоянно приходят комментаторы и начинают рассказывать, что использовать панельные менеджеры - плохая практика, надо работать в консоли, это быстрее, удобнее и т.д. Давайте воздержимся от этих бессмысленных споров. Пусть каждый работает так, как ему удобно. Мне удобно работать с MC, я к нему привык. И mcedit его люблю.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal #mc
MC поддерживает два разных протокола для передачи - SFTP (SSH File Transfer Protocol) или FISH (Files transferred over Shell protocol). Последний в разделе меню называется как Shell link. По названию не совсем понятно, что это такое. На первый взгляд кажется, что в контексте передачи файлов это одно и то же. Но на деле нет. И я как раз столкнулся лично с различиями.
Сервер, с которого я подключался, был старее того, куда надо было копировать. Там вроде бы Debian 11 стоял, я копировал на 12-й. К сожалению, не могу уточнить, сервер удалён уже, а сразу не было времени подробно разбираться. Сначала использовал sftp и ни в какую не мог подключиться. Постоянно в логе принимающего севера были ошибки в auth.log на тему то ли использовавшихся шифров, то ли формата сертификата. Сразу не записал, только пометил себе сделать об этом заметку.
При этом я спокойно подключался из консоли по ssh к удалённому серверу с тем же сертификатом или паролем. Попробовал в MC подключение по Shell link и сразу подключился. Перекинул файлы и разбираться уже не стал. Позже пробовал с разными серверами использовать разные протоколы - везде работали оба.
В целом, разница понятна, так как протоколы передачи совершенно разные. Лучше использовать более привычный и распространённый sftp, если он разрешён и настроен на принимающем сервере. Это не всегда бывает так. Как и обратная ситуация. Может быть разрешён sftp, но запрещён обычный shell. А подключению по fish как раз нужен хотя бы sh на принимающей стороне. Так что если не подключается один протокол, пробуйте другой.
☝️ Отдельно отмечу такую фишку MC. Вы можете в левой панели открыть один удалённый сервер, а в правой - другой. И не настраивая прямого соединения между этими серверами перекинуть файлы, выступая со своим MC как посредник.
Настраиваются такие подключения так: нажимаем F9 -> Right или Left, то есть выбираем нужную нам панель, потом раздел меню Shell link или SFTP link. Формат подключения типичный для ssh -
root@10.20.1.23/mnt/backup. Если аутентификация по ключу настроена, то сразу подключитесь. Если нет - выскочит окно для ввода пароля. Если надо задать пароль или использовать нестандартный порт, то по F1 открывается подсказка, там показаны все варианты.На подобные заметки постоянно приходят комментаторы и начинают рассказывать, что использовать панельные менеджеры - плохая практика, надо работать в консоли, это быстрее, удобнее и т.д. Давайте воздержимся от этих бессмысленных споров. Пусть каждый работает так, как ему удобно. Мне удобно работать с MC, я к нему привык. И mcedit его люблю.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal #mc
Раз уж начал вчера тему про MC (Midnight Commander), разовью её и перечислю основную функциональность этого файлового менеджера, которой лично я постоянно пользуюсь. Может кто-то найдёт для себя что-то новое.
1️⃣ Закладки. Комбинация Ctrl-\. Практически всегда начинаю работу в MC с открытия закладок. У меня там стандартно есть
2️⃣ Поиск файла. Комбинация Ctrl-s. После выбора закладки и перехода в нужный каталог сразу же запускаю поиск по файлу и начинаю его набирать. Например, перехожу в
3️⃣ Подсветка синтаксиса. Комбинация в mcedit Ctrl-s. После открытия файла включаю или отключаю подсветку синтаксиса, в зависимости то того, что хочу сделать. Если это огромный лог файл, то из-за подсветки будет тормозить просмотр, лучше сразу убрать её. Для того, чтобы стандартная подсветка для sh скриптов действовала на все файлы, даже без расширения, делаю вот так:
Копирую подсветку sh на все неопознанные файлы. Обычно это различные конфиги или логи и там как раз sh подсветка будет актуальной.
4️⃣ Cвернуть окно. Комбинация Ctrl-o. Обычно всегда сворачиваю MC, а не закрываю. Так и работаю, перемещаясь то в консоль, то в MC. Использовать его консоль для выполнения команд не люблю.
5️⃣ Создание, копирование или переименование файла. Комбинации Shift-F4, Shift-F5 и Shift-F6. Можно сделать копию файла с другим именем. Удобно, если руками правишь конфиги. Тут же копируешь старый с добавлением
6️⃣ Обновить содержимое каталога. Комбинация Ctrl-r. Не так давно узнал случайно про эту комбинацию. Пользуюсь постоянно. До этого выходил и возвращался в каталог для обновления списка файлов.
7️⃣ Выбор или отмена выбора. На цифровой панели + или -. Выбрать файлы по маске или отменить выбор. Если цифровой панели нет, то Shift-+ (шифт и потом плюс). Чаще всего приходится выбирать все файлы, для этого используется маска *, либо сразу комбинация Shift-*. Она выделяет все файлы в каталоге.
8️⃣ Расширенный Chown. Комбинации клавиш для него нет. Нажимаю F9 ⇨ File ⇨ A. Открывается Advanced chown. Я работаю в нём вместо отдельных chmod и chown.
9️⃣ Поменять местами панели. Комбинация Сtrl-u.
🔟 Посмотреть размер каталога. Комбинация Ctrl-space. Если каталоги жирные, подсчёт идёт долго, то я сразу по списку каталогов иду, не отпуская Ctrl, нажимая пробел. После каждого нажатия происходит автоматический переход на новый каталог. Так всё прокликав можно быстро либо очень большой каталог найти, либо пустой. Либо можно сначала выделить все каталоги и нажать Ctrl-space.
⏸️ Подстановка имени в консоль. Комбинация Esc-enter. Переходим к файлу, подставляем его имя в консоль, сворачиваем MC и потом в консоли работаем с выбранным файлом.
Есть ещё куча всяких комбинаций клавиш, но я даже не вспомню их, так что не использую, не считая однокнопочных, типа копирования или перемещения файлов. А эти уже на автомате вылетают. Так что когда мне кто-то говорит, что в консоли удобнее и быстрее, мне этого не понять. Что-то может и удобнее, а что-то явно нет.
Ещё некоторые моменты. Чтобы быстро получить путь каталога в буфер обмена, в котором я нахожусь в MC, сворачиваю его, пишу
MC можно запустить с разными темами. Бывает актуально, если какой-то цвет совсем нечитаем в текущей гамме. Можно чёрно-белый режим открыть, или какую-то тему выбрать:
Последняя вообще прикольная тема. Я иногда её на постоянку ставлю для выделения сервера. Обычно на какие-то свои.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #termianl #mc
/etc и /var/log, а дальше уже в зависимости от назначения сервера - каталог с бэкапами, каталог веб сервера, вольюмы контейнеров и т.д./var/log, нажимаю поиск и начинаю набирать syslog. Сразу же попадаю на нужный файл, набрав только sy.# cp /usr/share/mc/syntax/sh.syntax /usr/share/mc/syntax/unknown.syntaxКопирую подсветку sh на все неопознанные файлы. Обычно это различные конфиги или логи и там как раз sh подсветка будет актуальной.
.old. Либо переименовываешь текущий конфиг, чтобы отключить его. Например, добавляя к site.conf расширение .disabled. Я обычно так отключаю конфиги, не удаляю.🔟 Посмотреть размер каталога. Комбинация Ctrl-space. Если каталоги жирные, подсчёт идёт долго, то я сразу по списку каталогов иду, не отпуская Ctrl, нажимая пробел. После каждого нажатия происходит автоматический переход на новый каталог. Так всё прокликав можно быстро либо очень большой каталог найти, либо пустой. Либо можно сначала выделить все каталоги и нажать Ctrl-space.
⏸️ Подстановка имени в консоль. Комбинация Esc-enter. Переходим к файлу, подставляем его имя в консоль, сворачиваем MC и потом в консоли работаем с выбранным файлом.
Есть ещё куча всяких комбинаций клавиш, но я даже не вспомню их, так что не использую, не считая однокнопочных, типа копирования или перемещения файлов. А эти уже на автомате вылетают. Так что когда мне кто-то говорит, что в консоли удобнее и быстрее, мне этого не понять. Что-то может и удобнее, а что-то явно нет.
Ещё некоторые моменты. Чтобы быстро получить путь каталога в буфер обмена, в котором я нахожусь в MC, сворачиваю его, пишу
pwd и выделяю.MC можно запустить с разными темами. Бывает актуально, если какой-то цвет совсем нечитаем в текущей гамме. Можно чёрно-белый режим открыть, или какую-то тему выбрать:
# mc -b# mc -S darkfarПоследняя вообще прикольная тема. Я иногда её на постоянку ставлю для выделения сервера. Обычно на какие-то свои.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #termianl #mc
Please open Telegram to view this post
VIEW IN TELEGRAM
Когда гуглишь какие-то ошибки по Linux и сопутствующему ПО, очень часто попадаешь на сайт access.redhat.com, где есть решения. Но проблема в том, что без подписки ты не можешь посмотреть ответ, только текст ошибки. Это раздражает и расстраивает.
Раньше это не представляло большой проблемы, так как достаточно бесплатной подписки Red Hat Developer Subscription for Individuals. Я даже статью делал о том, как её получить. Не пользовался никакими возможностями этой подписки, кроме доступа к порталу со статьями.
Проблема в том, что подписку надо продлевать каждый год. После 2022 года из-за экспортных ограничений, которые ввело правительство США, сделать это стало невозможно. А если быть точным, то как раньше стало невозможно, но в целом возможно и я расскажу, как это сделать.
У меня уже была учётка в RedHat, поэтому расскажу, как сделать с уже существующей. Если будете делать новую, то сразу вводите те данные, что я расскажу.
Я включил VPN из США, залогинился в учётную запись и поменял адрес с телефоном. Просто открыл карту США и вбил первый попавшийся адрес с номером телефона. Мне пришло подтверждение моего почтового адреса на email. Подтвердил его. Без этого меня не пускали в новый ЛК, ссылаясь на ограничения.
После этого пошёл по адресу developers.redhat.com/register, но не стал регистрировать, а вместо этого справа вверху нажал Login и зашёл под своей учёткой. У меня открылась форма регистрации с уже заполненными из профиля полями. И в конце не был отмечен чекбокс I have read and agree to the Red Hat Developer Subscriptions for Individuals. Отметил его и завершил регистрацию.
Собственно, всё. После этого в личном кабинете у меня появилась свежая подписка Red Hat Developer Subscription for Individuals. Далее я прошёл в их новую консоль для управления всем и вся console.redhat.com. Там уже не помню, что конкретно сделал, но подписка активировалась и добавилась ещё одна - Red Hat Beta Access.
Сначала доступ к материалам не открылся. Я расстроился. Несколько раз выходил и заходил снова в учётку, чистил кэш и куки. Почему-то ничего не помогало. В итоге открыл браузер в инкогнито, ещё раз залогинился и все материалы открылись.
С этой подпиской вам дают 16 лицензий на использование ОС RHEL. Мне и даром это не нужно. Подписку сделал исключительно, чтобы в гугле в результатах поиска иметь возможность прочитать материал. Несмотря на все ИИ, материалы с access.redhat.com представляют определённую ценность. Не раз там находил решения своих проблем, поэтому всегда старался настроить подписку.
Нигде не видел информации о том, как получить сейчас эту подписку. Интуитивно сделал всё сам, пробуя разные варианты. За пару часов разобрался.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux
Раньше это не представляло большой проблемы, так как достаточно бесплатной подписки Red Hat Developer Subscription for Individuals. Я даже статью делал о том, как её получить. Не пользовался никакими возможностями этой подписки, кроме доступа к порталу со статьями.
Проблема в том, что подписку надо продлевать каждый год. После 2022 года из-за экспортных ограничений, которые ввело правительство США, сделать это стало невозможно. А если быть точным, то как раньше стало невозможно, но в целом возможно и я расскажу, как это сделать.
У меня уже была учётка в RedHat, поэтому расскажу, как сделать с уже существующей. Если будете делать новую, то сразу вводите те данные, что я расскажу.
Я включил VPN из США, залогинился в учётную запись и поменял адрес с телефоном. Просто открыл карту США и вбил первый попавшийся адрес с номером телефона. Мне пришло подтверждение моего почтового адреса на email. Подтвердил его. Без этого меня не пускали в новый ЛК, ссылаясь на ограничения.
После этого пошёл по адресу developers.redhat.com/register, но не стал регистрировать, а вместо этого справа вверху нажал Login и зашёл под своей учёткой. У меня открылась форма регистрации с уже заполненными из профиля полями. И в конце не был отмечен чекбокс I have read and agree to the Red Hat Developer Subscriptions for Individuals. Отметил его и завершил регистрацию.
Собственно, всё. После этого в личном кабинете у меня появилась свежая подписка Red Hat Developer Subscription for Individuals. Далее я прошёл в их новую консоль для управления всем и вся console.redhat.com. Там уже не помню, что конкретно сделал, но подписка активировалась и добавилась ещё одна - Red Hat Beta Access.
Сначала доступ к материалам не открылся. Я расстроился. Несколько раз выходил и заходил снова в учётку, чистил кэш и куки. Почему-то ничего не помогало. В итоге открыл браузер в инкогнито, ещё раз залогинился и все материалы открылись.
С этой подпиской вам дают 16 лицензий на использование ОС RHEL. Мне и даром это не нужно. Подписку сделал исключительно, чтобы в гугле в результатах поиска иметь возможность прочитать материал. Несмотря на все ИИ, материалы с access.redhat.com представляют определённую ценность. Не раз там находил решения своих проблем, поэтому всегда старался настроить подписку.
Нигде не видел информации о том, как получить сейчас эту подписку. Интуитивно сделал всё сам, пробуя разные варианты. За пару часов разобрался.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux