Когда гуглишь какие-то ошибки по 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
👍173👎5
У меня уже пару лет живёт в WSL на рабочем ноутбуке алиас, которым я пользуюсь практически каждый день. В нём нет ничего особенного, но может кому-то в голову не приходило такое сделать, поэтому делюсь.
Алиас этот делает одну простую вещь - выдаёт информацию об IP адресе. Я не знаю, как у остальных админов и девопсов проходит рабочий процесс, но мне постоянно приходится проверять те или иные адреса для различных целей.
В
Работает это так:
В выводе обрезается информация об user_agent, так как мне она не нужна, только внимание отвлекает. Если не указывать IP, а просто ввести
Сервис ifconfig.co полностью бесплатен, не нужны ни регистрация, ни что-либо ещё. Просто берёшь и пользуешься.
При поиске информации об IP адресах и домене обычно приходится оперировать следующими командами. Проверка DNS записей:
Потом можно сразу же проверить эти IP адреса:
Часто приходится проверять PTR запись для адреса, чтобы понять его принадлежность или функциональность:
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #wsl
Алиас этот делает одну простую вещь - выдаёт информацию об IP адресе. Я не знаю, как у остальных админов и девопсов проходит рабочий процесс, но мне постоянно приходится проверять те или иные адреса для различных целей.
В
.bashrc алиас с простой функцией:function ipa { curl -s https://ifconfig.co/json?ip=$1 | jq 'del(.user_agent)' }Работает это так:
# ipa 104.21.80.1{ "ip": "104.21.80.1", "ip_decimal": 1746227201, "country": "United States", "country_iso": "US", "country_eu": false, "asn": "AS13335", "asn_org": "CLOUDFLARENET"}В выводе обрезается информация об user_agent, так как мне она не нужна, только внимание отвлекает. Если не указывать IP, а просто ввести
ipa, то выводится информация о моём внешнем IP адресе. Сервис ifconfig.co полностью бесплатен, не нужны ни регистрация, ни что-либо ещё. Просто берёшь и пользуешься.
При поиске информации об IP адресах и домене обычно приходится оперировать следующими командами. Проверка DNS записей:
# dig +short example.com AПотом можно сразу же проверить эти IP адреса:
# ipa 23.215.0.138Часто приходится проверять PTR запись для адреса, чтобы понять его принадлежность или функциональность:
# host 23.215.0.138❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #wsl
👍270👎4
Какое-то дёрганное лето получается. Новые проблемы сыпятся, как из рога изобилия. Жара что ли на сервера так влияет? Расскажу историю очередной проблемы, с которой столкнулся. Там есть несколько поучительных моментов.
На одном проекте ночью упал Redis, сайт начал 500-ю ошибку отдавать. Нечасто такое случается. Редис если и упадёт, то обычно быстро поднимается, потому что используют его в основном под кэш в оперативной памяти, данные можно не сохранять.
Redis словил ошибку Segmentation fault. Эта такая мутная тема, потому что нельзя однозначно сказать, из-за чего она возникает. Это могут быть как проблемы с железом, так и с самим софтом. Либо банально оперативной памяти на сервере не хватило.
У меня скорее всего последний вариант, так как в момент падения сервер реально сильно нагрузили, причём разносторонней нагрузкой. Рядом работающая СУБД в этот же момент скинула на диск свой пул и буферный кэш. Это осталось в её логе. Они это делают, чтобы освободить оперативную память, если её не хватает.
В настройках systemd юнита Redis указан параметр
Redis всю ночь поднимался и падал, постоянно записывая что-то на диск. Это видно по мониторингу. Забил весь ресурс дисков своей записью. Он писал свои трейсы в лог, но помимо них ещё какую-то информацию. Судя по всему своё состояние пытался скинуть, но не получалось. Я трейсы бегло посмотрел, но особо не вникал, так как там без должного понимания ничего особо не увидишь.
В общем случае с параметром
Но как я уже сказал, у меня что-то пошло не так. В данном случае было бы лучше, если бы он тихо помер и не мучал больше сервер. Помогло в итоге то, что я туром проснулся, вручную остановил его и запустил заново:
Так что сильно рассчитывать на systemd в таких вопросах не стоит. Очень желательно настраивать для критичных сервисов внешний мониторинг службы, чтобы она отвечала по настроенному TCP порту или Unix сокету. Отдавала какие-то данные или своё состояние передавала. И если не отвечает, то каким-то образом гарантированно перезапускать её, в зависимости от того, где она запущена, как служба на сервере или в отдельном контейнере.
Если бы это была СУБД, типа MySQL или Postgres, которая всю ночь пыталась подняться и падала, то даже не знаю, что бы стало с данными. Для этих баз данных такое поведение может быть фатальным, особенно если они упали из-за проблем с диском, а при старте запускали восстановление данных. Постоянные перезапуски их добьют. Так что аккуратнее с параметром
Я в итоге снизил потребление памяти у некоторых служб, чтобы избежать ситуаций, когда память вся закончится. Буду наблюдать. Надеюсь, что проблема не повторится.
#linux #systemd #ошибка
На одном проекте ночью упал Redis, сайт начал 500-ю ошибку отдавать. Нечасто такое случается. Редис если и упадёт, то обычно быстро поднимается, потому что используют его в основном под кэш в оперативной памяти, данные можно не сохранять.
Redis словил ошибку Segmentation fault. Эта такая мутная тема, потому что нельзя однозначно сказать, из-за чего она возникает. Это могут быть как проблемы с железом, так и с самим софтом. Либо банально оперативной памяти на сервере не хватило.
У меня скорее всего последний вариант, так как в момент падения сервер реально сильно нагрузили, причём разносторонней нагрузкой. Рядом работающая СУБД в этот же момент скинула на диск свой пул и буферный кэш. Это осталось в её логе. Они это делают, чтобы освободить оперативную память, если её не хватает.
В настройках systemd юнита Redis указан параметр
Restart=always. Подробно на эту тему я делал отдельную заметку. Рекомендую ознакомиться, если не знаете. Данный параметр означает, что при любой причине завершения работы службы будет попытка поднять её. Я упоминал в той заметке, что не всегда это бывает полезно. И это как раз мой случай.Redis всю ночь поднимался и падал, постоянно записывая что-то на диск. Это видно по мониторингу. Забил весь ресурс дисков своей записью. Он писал свои трейсы в лог, но помимо них ещё какую-то информацию. Судя по всему своё состояние пытался скинуть, но не получалось. Я трейсы бегло посмотрел, но особо не вникал, так как там без должного понимания ничего особо не увидишь.
В общем случае с параметром
Restart=always служба должна подняться автоматически. Я потестировал немного на отдельной виртуалке. Если Редису дать команду SIGSEGV, то он так же, как у меня вышло, скидывает свой трейс в лог, завершает работу и запускается заново. Проверить можно так:# kill -SIGSEGV $(pidof redis-server)Но как я уже сказал, у меня что-то пошло не так. В данном случае было бы лучше, если бы он тихо помер и не мучал больше сервер. Помогло в итоге то, что я туром проснулся, вручную остановил его и запустил заново:
# systemctl stop redis-server# systemctl start redis-serverТак что сильно рассчитывать на systemd в таких вопросах не стоит. Очень желательно настраивать для критичных сервисов внешний мониторинг службы, чтобы она отвечала по настроенному TCP порту или Unix сокету. Отдавала какие-то данные или своё состояние передавала. И если не отвечает, то каким-то образом гарантированно перезапускать её, в зависимости от того, где она запущена, как служба на сервере или в отдельном контейнере.
Если бы это была СУБД, типа MySQL или Postgres, которая всю ночь пыталась подняться и падала, то даже не знаю, что бы стало с данными. Для этих баз данных такое поведение может быть фатальным, особенно если они упали из-за проблем с диском, а при старте запускали восстановление данных. Постоянные перезапуски их добьют. Так что аккуратнее с параметром
Restart.Я в итоге снизил потребление памяти у некоторых служб, чтобы избежать ситуаций, когда память вся закончится. Буду наблюдать. Надеюсь, что проблема не повторится.
#linux #systemd #ошибка
👍103👎3
Заметил неожиданное различие между системой Ubuntu и Debian, хотя казалось бы в этом контексте его быть не должно. Для замены шлюза по умолчанию в Ubuntu можно сделать так:
Сначала добавили новый, потом удалили старый. Команды нормально отработают. Заменяют шлюз 172.31.112.1 на 172.31.112.5. Та же самая последовательность команд на Debian не сработает:
Там сработает другая и более правильная, которую имеет смысл использовать в обеих системах.
И дело тут не в версии утилиты ip. Специально проверил на Debian 12, где iproute2-6.1.0 и более старой Ubuntu 22, где версия старее - iproute2-5.15.0. Различия судя по всему системные.
А вообще в Ubuntu такое удобно делать через netplan. Меняем шлюз, потом на всякий случай проверяем конфигурацию и применяем её.
Если что-то не так, и связь потеряна, настройки откатятся обратно. Я хоть и не особо люблю Ubuntu за её частые изменения, которые не всегда нужны, но конкретно netplan удобен именно вот в этом
Лично мне формат конфигурационного файла
Не хватает проверки изменений перед их применением. Когда настраиваешь сеть на арендованных дедиках с Proxmox, почти всегда приходится менять этот файл с сетевыми настройками. И ошибка в них зачастую фатальна. Можно потерять доступ к серверу, если, к примеру, арендуешь подсеть внешних IP адресов и делаешь на них бридж, чтобы прокидывать реальные адреса виртуалкам. Поэтому я всегда эти вещи делаю сразу после установки системы и потом стараюсь настройки сети вообще не трогать. Чаще всего это и не нужно, если уже настроил и проверил.
Кстати, netplan можно установить в Debian, если очень хочется. Например, если в инфраструктуре используются обе системы, и Debian, и Ubuntu.
Дальше рисуем конфигурацию для netplan и применяем:
Заметил, что если у вас в системе используется динамический IP адрес от DHCP сервера, то
❓Вам какой формат сетевых настроек больше нравится?
◽️Как в Debian
◽️Как в Ubuntu
◽️Как в RHEL и форках в
Не знаю, как сейчас в RHEL сеть настраивается. Не смотрел свежие версии. В старых всегда network-scripts использовал. А удобнее всего мне формат interfaces. Люблю, когда всё в одном файле, а не по нескольким раскидано.
#linux
# ip route add default via 172.31.112.5# ip route del default via 172.31.112.1Сначала добавили новый, потом удалили старый. Команды нормально отработают. Заменяют шлюз 172.31.112.1 на 172.31.112.5. Та же самая последовательность команд на Debian не сработает:
# ip route add default via 172.31.112.5RTNETLINK answers: File existsТам сработает другая и более правильная, которую имеет смысл использовать в обеих системах.
# ip route replace default via 172.31.112.5И дело тут не в версии утилиты ip. Специально проверил на Debian 12, где iproute2-6.1.0 и более старой Ubuntu 22, где версия старее - iproute2-5.15.0. Различия судя по всему системные.
А вообще в Ubuntu такое удобно делать через netplan. Меняем шлюз, потом на всякий случай проверяем конфигурацию и применяем её.
# netplan tryЕсли что-то не так, и связь потеряна, настройки откатятся обратно. Я хоть и не особо люблю Ubuntu за её частые изменения, которые не всегда нужны, но конкретно netplan удобен именно вот в этом
try. В Debian никаких проверок нет. Если ошибся в конфигурации сети, то узнаешь об этом уже по факту, когда перезагрузишься или перезапустишь сеть через:# systemctl restart networkingЛично мне формат конфигурационного файла
/etc/network/interfaces в Debian максимально удобен и понятен. Не знаю, зачем тут нужен yaml или что-то ещё. Открыл, посмотрел, поправил. Не надо никакие пробелы и отступы ловить. Все интерфейсы в одном месте.Не хватает проверки изменений перед их применением. Когда настраиваешь сеть на арендованных дедиках с Proxmox, почти всегда приходится менять этот файл с сетевыми настройками. И ошибка в них зачастую фатальна. Можно потерять доступ к серверу, если, к примеру, арендуешь подсеть внешних IP адресов и делаешь на них бридж, чтобы прокидывать реальные адреса виртуалкам. Поэтому я всегда эти вещи делаю сразу после установки системы и потом стараюсь настройки сети вообще не трогать. Чаще всего это и не нужно, если уже настроил и проверил.
Кстати, netplan можно установить в Debian, если очень хочется. Например, если в инфраструктуре используются обе системы, и Debian, и Ubuntu.
# apt install netplan.io openvswitch-switch# systemctl enable --now systemd-networkd# apt remove ifupdownДальше рисуем конфигурацию для netplan и применяем:
# netplan generate# netplan tryЗаметил, что если у вас в системе используется динамический IP адрес от DHCP сервера, то
netplan try будет работать некорректно. Он будет получать новый IP адрес, если на DHCP сервере нет привязки этой системы на выдачу одного и того же IP адреса, и в итоге вас будет отключать от системы. Но откатить обратно сетевые настройки уже не получится. Система получит новый IP адрес и он применится. Вам придётся вручную к ней подключаться. Так что в любом случае надо аккуратно к изменениям сетевых настроек подходить.❓Вам какой формат сетевых настроек больше нравится?
◽️Как в Debian
/etc/network/interfaces◽️Как в Ubuntu
/etc/netplan/*.yaml◽️Как в RHEL и форках в
/etc/sysconfig/network-scripts/ifcfg-*Не знаю, как сейчас в RHEL сеть настраивается. Не смотрел свежие версии. В старых всегда network-scripts использовал. А удобнее всего мне формат interfaces. Люблю, когда всё в одном файле, а не по нескольким раскидано.
#linux
👍122👎5
В свете недавних обсуждений гипервизоров вспомнил, как я начинал изучение KVM. До него работал с Xen и Hyper-V. Первым делом стал разбирать вопрос бэкапа виртуальных машин наживую, без их остановки. Это было более 10-ти лет назад и простых решений не существовало. Proxmox не помню, был уже тогда или нет, но я про него не знал. Использовал всё это в консоли с помощью virsh, и в GUI с помощью virt-manager.
Я изучил вопрос и разобрался, как делать снепшоты при использовании файлов qcow2 для дисков виртуальных машин, и как снимать с них бэкапы. Всё это обернул в очень простой скрипт без каких-то дополнительных проверок. Оформил всё это в статью.
Уже не помню, в чём там был нюанс, но при некотором стечении обстоятельств можно было потерять образы дисков. Вроде бы если по какой-то причине не создался снепшот, то скрипт, не найдя его, удалял сам образ машины. Лично с таким не сталкивался, потому что очень внимательно проверял работу до того, как включал реальное удаление. А вот в комментариях отписались люди, которые диски потеряли, хотя я обо всём этом предупреждал в статье. Сначала всё тщательно проверяем - потом включаем удаление.
Напомню один важный нюанс. Если вы случайно удалили образы VM, а сами машины до сих пор работают, то восстановить всё это относительно просто. Я видел отзывы, когда люди только через неделю или две замечали, что удалили диски VM, а сами машины при этом работали. Покажу на примере, как это выглядит.
Допустим, у нас работает виртуальная машина с диском в виде файла
Вы должны увидеть строки с упоминанием файла
Да, файловый дескриптор на месте и имеет номер 14. Скопируем из него данные обратно в файл:
Какое-то время будет длиться копирование. После этого файл будет возвращён на место. Так как копирование не моментальное, диск виртуальной машины может немного пострадать. Если там есть СУБД, то может нарушиться целостность базы, но не обязательно. Большую часть ошибок сможет починить обычный fsck. По сравнению с полной потерей виртуалки это будут небольшие трудности.
Пример универсальный и будет актуален для любых ситуаций, когда удалён файл, который открыт каким-то процессом. Пока процесс запущен и держит этот файл, его можно без проблем восстановить. Вот если завершить процесс, то задача сильно усложниться и шансов восстановить информацию будет уже значительно меньше, хотя в некоторых случаях тоже будет реально.
❗️Сохраните заметку в закладки, может пригодиться в самом неожиданном случае. У меня бывало, что по ошибке удалял конфиг работающей программы. Казалось бы, вот он только что был, ты его грохнул, а как сразу же вернуть, не знаешь, надо вспоминать.
#restore #linux #terminal
Я изучил вопрос и разобрался, как делать снепшоты при использовании файлов qcow2 для дисков виртуальных машин, и как снимать с них бэкапы. Всё это обернул в очень простой скрипт без каких-то дополнительных проверок. Оформил всё это в статью.
Уже не помню, в чём там был нюанс, но при некотором стечении обстоятельств можно было потерять образы дисков. Вроде бы если по какой-то причине не создался снепшот, то скрипт, не найдя его, удалял сам образ машины. Лично с таким не сталкивался, потому что очень внимательно проверял работу до того, как включал реальное удаление. А вот в комментариях отписались люди, которые диски потеряли, хотя я обо всём этом предупреждал в статье. Сначала всё тщательно проверяем - потом включаем удаление.
Напомню один важный нюанс. Если вы случайно удалили образы VM, а сами машины до сих пор работают, то восстановить всё это относительно просто. Я видел отзывы, когда люди только через неделю или две замечали, что удалили диски VM, а сами машины при этом работали. Покажу на примере, как это выглядит.
Допустим, у нас работает виртуальная машина с диском в виде файла
vm-109-disk-0.qcow2 и этот файл по какой-то причине был удалён в момент работы VM. То есть машина работает, а файла уже нет. Поверяем, реально ли файл удалён, но всё ещё открыт его дескриптор:# lsof | grep '(deleted)'kvm 402083 root 14u REG 0,39 21478375424 17 /var/lib/vz/images/109/vm-109-disk-0.qcow2 (deleted)Вы должны увидеть строки с упоминанием файла
/var/lib/vz/images/109/vm-109-disk-0.qcow2. Значит, он реально ещё не удалён. Его держит процесс с пидом 402083. Проверяем это:# ls -l /proc/402083/fd | grep deletedlrwx------ 1 root root 64 Aug 3 21:16 14 -> /var/lib/vz/images/109/vm-109-disk-0.qcow2 (deleted)Да, файловый дескриптор на месте и имеет номер 14. Скопируем из него данные обратно в файл:
# cp /proc/402083/fd/14 /var/lib/vz/images/109/vm-109-disk-0.qcow2Какое-то время будет длиться копирование. После этого файл будет возвращён на место. Так как копирование не моментальное, диск виртуальной машины может немного пострадать. Если там есть СУБД, то может нарушиться целостность базы, но не обязательно. Большую часть ошибок сможет починить обычный fsck. По сравнению с полной потерей виртуалки это будут небольшие трудности.
Пример универсальный и будет актуален для любых ситуаций, когда удалён файл, который открыт каким-то процессом. Пока процесс запущен и держит этот файл, его можно без проблем восстановить. Вот если завершить процесс, то задача сильно усложниться и шансов восстановить информацию будет уже значительно меньше, хотя в некоторых случаях тоже будет реально.
❗️Сохраните заметку в закладки, может пригодиться в самом неожиданном случае. У меня бывало, что по ошибке удалял конфиг работающей программы. Казалось бы, вот он только что был, ты его грохнул, а как сразу же вернуть, не знаешь, надо вспоминать.
#restore #linux #terminal
Server Admin
Бэкап виртуальных машин KVM без остановки VM
Описание различных подходов к бэкапу виртуальных машин в kvm в зависимости от типа дисков. Представлен скрипт для автоматического бэкапа.
5👍154👎4
На прошлой неделе читал статью про ansible-cmdb. Понравился инструмент. Раньше про него не слышал. Он довольно просто устроен, особенно для тех, кто знает и регулярно использует Ansible в инфраструктуре. Собственно, ansible-cmdb работает на базе Ansible.
Поясню, для тех, кто не в курсе и не работает с Ansible. У неё есть список хостов, куда она имеет доступ по SSH. Соответственно, с помощью Ansible можно ходить по хостам, что-то там делать, собирать информацию. Ansible-cmdb использует вывод модуля setup, который заходит на хосты и собирает о них информацию в так называемые ansible_facts. A ansible-cmdb берёт эту информацию и оформляет в наглядную html страницу.
Как я уже сказал, если вы уже используете Ansible, вам ничего пояснять и настраивать не надо. Просто берёте файл с инвентарём, проходите по нему модулем setup и строите отчёт примерно так:
Теперь расскажу, как собрать информацию о хостах для тех, кто вообще не знаком и не настраивал Ansible. Я не буду рассказывать, как с ней работать, а просто по шагам покажу, как вам собрать информацию со своих хостов, даже если вы не хотите изучать и далее использовать Ansible. Хотя, разумеется, современному админу или девопсу крайне желательно уметь с ней работать.
Настраивать всё буду в Debian 12. Рекомендую использовать для этого отдельную виртуалку или контейнер. Ставим необходимые пакеты:
У ansible-cmdb есть собранный deb пакет. Я изначально использовал его. Но так и не смог заставить работать. Я не знаю, что там за версия python нужна, но у меня постоянно были какие-то ошибки в коде. Залез в репозиторий, в Issues, увидел там похожие ошибки и решение в виде установки через pip, а не из пакета.
Поставил в итоге следующим образом. Это не рекомендованный способ, но для демонстрации работы и простоты делаю так. Когда разберётесь и решите, что вам этот инструмент нужен, устанавливайте и запускайте его через venv. А пока ставим:
Теперь нам нужно подготовить конфигурацию ansible. Добавляю минимальную конфигурацию в файл
И создаю так называемый инвентарь
Передаю в переменную конфигурацию Ansible:
Создаю сертификат, по которому буду подключаться к хостам:
Копирую его на хосты в authorized_keys:
Проверяю, видит ли ansible хосты в инвентаре, всё ли верно настроено:
Всё в порядке, собираем факты:
Если всё в порядке, и в директории появились текстовые файлы с информацией о хостах, то строим по ним html страничку:
Копируем overview.html к себе на компьютер и смотрим браузером. Получили наглядный список, где в выпадающем списке подробная информация о хостах.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #ansible
Поясню, для тех, кто не в курсе и не работает с Ansible. У неё есть список хостов, куда она имеет доступ по SSH. Соответственно, с помощью Ansible можно ходить по хостам, что-то там делать, собирать информацию. Ansible-cmdb использует вывод модуля setup, который заходит на хосты и собирает о них информацию в так называемые ansible_facts. A ansible-cmdb берёт эту информацию и оформляет в наглядную html страницу.
Как я уже сказал, если вы уже используете Ansible, вам ничего пояснять и настраивать не надо. Просто берёте файл с инвентарём, проходите по нему модулем setup и строите отчёт примерно так:
# mkdir out# ansible -m setup --tree out/ all# ansible-cmdb out/ > overview.htmlТеперь расскажу, как собрать информацию о хостах для тех, кто вообще не знаком и не настраивал Ansible. Я не буду рассказывать, как с ней работать, а просто по шагам покажу, как вам собрать информацию со своих хостов, даже если вы не хотите изучать и далее использовать Ansible. Хотя, разумеется, современному админу или девопсу крайне желательно уметь с ней работать.
Настраивать всё буду в Debian 12. Рекомендую использовать для этого отдельную виртуалку или контейнер. Ставим необходимые пакеты:
# apt install python3-pip ansibleУ ansible-cmdb есть собранный deb пакет. Я изначально использовал его. Но так и не смог заставить работать. Я не знаю, что там за версия python нужна, но у меня постоянно были какие-то ошибки в коде. Залез в репозиторий, в Issues, увидел там похожие ошибки и решение в виде установки через pip, а не из пакета.
Поставил в итоге следующим образом. Это не рекомендованный способ, но для демонстрации работы и простоты делаю так. Когда разберётесь и решите, что вам этот инструмент нужен, устанавливайте и запускайте его через venv. А пока ставим:
# pip install ansible-cmdb --break-system-packages# ln -s /usr/bin/python3 /usr/bin/pythonТеперь нам нужно подготовить конфигурацию ansible. Добавляю минимальную конфигурацию в файл
~/.ansible/ansible.cfg[defaults]home = ~/.ansible/inventory = ~/.ansible/inventory.yamlremote_user = rootgather_facts = Trueprivate_key_file = ~/.ssh/id_ed25519host_key_checking = FalseИ создаю так называемый инвентарь
~/.ansible/inventory.yaml в терминологии Ansible со списком серверов, для которых будем делать отчёт. all: hosts: Debian12-VPS: ansible_host: 127.0.0.1 ansible_port: 22 Debian12-CT: ansible_host: 10.20.1.24 ansible_port: 22 Ubuntu24-CT: ansible_host: 10.20.1.21 ansible_port: 22Передаю в переменную конфигурацию Ansible:
# export ANSIBLE_CONFIG="$HOME/.ansible/ansible.cfg"Создаю сертификат, по которому буду подключаться к хостам:
# ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "$(whoami)@$(hostname)_$(date -I)"Копирую его на хосты в authorized_keys:
# ssh-copy-id root@127.0.0.1# ssh-copy-id root@10.20.1.24# ssh-copy-id root@10.20.1.21Проверяю, видит ли ansible хосты в инвентаре, всё ли верно настроено:
# ansible -i inventory.yaml all --list-hosts Debian12-VPS Debian12-CT Ubuntu24-CTВсё в порядке, собираем факты:
# mkdir ~/.ansible/out# ansible -m setup --tree ~/.ansible/out allЕсли всё в порядке, и в директории появились текстовые файлы с информацией о хостах, то строим по ним html страничку:
# ansible-cmdb ~/.ansible/out > overview.htmlКопируем overview.html к себе на компьютер и смотрим браузером. Получили наглядный список, где в выпадающем списке подробная информация о хостах.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #ansible
2👍150👎3
Вспомнил про одну необычную утилиту из мира консоли Linux. Сначала даже не был уверен, что не писал о ней ранее. Оказалось, что реально не писал, только пару упоминаний мельком сделал. Речь пойдёт о faketime. Вспомнил, когда скрипты пересматривал к утренней публикации. Искал что-то для примера в прикреплённой картинке.
Во время отладки скриптов или мониторинга иногда нужно подставить какое-то другое системное время. Можно менять время непосредственно в тестовой системе, а можно воспользоваться
Приложение скомпилировано на базе библиотеки libfaketime. Оно перехватывает системные вызовы для приложения и заменяет в них время на указанное. Работает примерно так:
Передали утилите
Я чаще всего утилиту использую, когда с помощью
Покажу наглядный пример, где можно ошибиться и где я лично ошибался не раз. Простая конструкция:
◽️mtime – время последнего изменения файла
◽️+1 - n*24 часа, в данном случае n=1, то есть 24 часа
Это информация из
Создали файл 28 августа в 14:39, а в 29 августа в 14:40 ничего не находит, хотя мы взяли время более 24 часов вперёд.
Уехали на 48 часов и 1 минуту вперёд и нашли файл. У find есть особенность, и в данном случае +1 это не 24 часа, а 48. А чтобы было именно 24 часа, надо использовать +0:
Faketime позволяет проверить работу своих скриптов, заглянув в будущее.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal
Во время отладки скриптов или мониторинга иногда нужно подставить какое-то другое системное время. Можно менять время непосредственно в тестовой системе, а можно воспользоваться
faketime. Причём сделать это очень просто, потому что утилита с незапамятных времён живёт в базовых репах:# apt install faketimeПриложение скомпилировано на базе библиотеки libfaketime. Оно перехватывает системные вызовы для приложения и заменяет в них время на указанное. Работает примерно так:
# faketime '2025-12-31 23:59:59' dateWed Dec 31 23:59:59 MSK 2025Передали утилите
date указанное время, и она его вывела.Я чаще всего утилиту использую, когда с помощью
find удаляю что-то по меткам времени. Удобно запустить через faketime без удаления, просто чтобы проверить, как отработает поиск. Вообще всё, что связано с удалением, предварительно проверяю и только потом ставлю на исполнение. Иногда в скриптах комментирую строки с удалением, чтобы дождаться полного наполнения данными, чтобы потом прийти, вручную всё отладить и только потом включить ключ с удалением. Иначе рано или поздно из-за ошибки или невнимательности можно наделать дел.Покажу наглядный пример, где можно ошибиться и где я лично ошибался не раз. Простая конструкция:
# find . -type f -mtime +1◽️mtime – время последнего изменения файла
◽️+1 - n*24 часа, в данном случае n=1, то есть 24 часа
Это информация из
man find. Ты ожидаешь, что будут найдены все файлы с датой модификации более суток назад. Проверяем:# touch filename.tar# ls -l-rw-r--r-- 1 root root 0 Aug 28 14:39 filename.tar# faketime '2025-08-29 14:40:00' find . -type f -mtime +1Создали файл 28 августа в 14:39, а в 29 августа в 14:40 ничего не находит, хотя мы взяли время более 24 часов вперёд.
# faketime '2025-08-30 14:40:00' find . -type f -mtime +1./filename.tarУехали на 48 часов и 1 минуту вперёд и нашли файл. У find есть особенность, и в данном случае +1 это не 24 часа, а 48. А чтобы было именно 24 часа, надо использовать +0:
# faketime '2025-08-29 14:40:00' find . -type f -mtime +0./filename.tarFaketime позволяет проверить работу своих скриптов, заглянув в будущее.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal
2👍167👎3
☝️ Всё новое – хорошо забытое старое.
Не люблю делать повторы своих старых публикаций, потому что это странно выглядит для тех, кто их уже читал. При этом формат Telegram каналов таков, что к старой информации, если её не сохранили специально, редко кто обращается. Поэтому, чтобы не терять полезную уже написанную информацию, я её оформляю время от времени в подборки для того, чтобы новые читатели тоже имели возможность с ней познакомиться.
В эту подборку я объединил способы решения типовых задач в консоли Linux, которые практически не теряют актуальность со временем. Все заметки написаны лично мной и чаще всего с конкретными практическими примерами. Их имеет смысл сохранить, чтобы потом в нужный момент открыть и выполнить предложенные действия. Я сам таким образом использую эти заметки.
Система в целом:
🔥Профилирование нагрузки в Linux
▪️Краткий список действий, чтобы понять, из-за чего тормозит сервер
▪️Временная нагрузка на сервер с помощью системных утилит для проверки мониторинга
▪️Анализ производительности системы под нагрузкой с помощью sysbench
▪️Прикладные примеры использования lsof для различных задач
Диск:
🔥 Анализ дисковой активности в Linux с помощью btrace, iostat, iotop, pidstat, fatrace, strace
▪️Анализируем нагрузку на диск с помощью perf-tools
▪️Расследование фантомных чтений с диска
▪️Отличный скрипт, который позволит быстро разобраться, кто и чем занял свободное место на сервере
▪️Снижение задержек в SSD дисках
▪️Файл удалили, а место не освободилось
▪️Шпаргалка с командами, если у вас закончилось место на диске
Сеть:
🔥Подборка утилит для просмотра статистики сетевых интерфейсов
▪️Анализ направлений трафика с реальными скоростями с iftop
▪️Анализ сетевой активности с помощью утилит из пакета netsniff-ng
▪️Запись дампа трафика конкретного приложения
Память:
🔥Просмотр использования памяти процессами с помощью pmap
▪️Кто и как использует swap
▪️Уменьшение или увеличение ram на ходу
▪️Удобный скрипт для просмотра использования оперативной памяти программами (не процессами!)
Разное:
▪️Расследование тормозов MySQL сервера
▪️Трассировка медленных запросов в php-fpm
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#подборка #linux #perfomance
Не люблю делать повторы своих старых публикаций, потому что это странно выглядит для тех, кто их уже читал. При этом формат Telegram каналов таков, что к старой информации, если её не сохранили специально, редко кто обращается. Поэтому, чтобы не терять полезную уже написанную информацию, я её оформляю время от времени в подборки для того, чтобы новые читатели тоже имели возможность с ней познакомиться.
В эту подборку я объединил способы решения типовых задач в консоли Linux, которые практически не теряют актуальность со временем. Все заметки написаны лично мной и чаще всего с конкретными практическими примерами. Их имеет смысл сохранить, чтобы потом в нужный момент открыть и выполнить предложенные действия. Я сам таким образом использую эти заметки.
Система в целом:
🔥Профилирование нагрузки в Linux
▪️Краткий список действий, чтобы понять, из-за чего тормозит сервер
▪️Временная нагрузка на сервер с помощью системных утилит для проверки мониторинга
▪️Анализ производительности системы под нагрузкой с помощью sysbench
▪️Прикладные примеры использования lsof для различных задач
Диск:
🔥 Анализ дисковой активности в Linux с помощью btrace, iostat, iotop, pidstat, fatrace, strace
▪️Анализируем нагрузку на диск с помощью perf-tools
▪️Расследование фантомных чтений с диска
▪️Отличный скрипт, который позволит быстро разобраться, кто и чем занял свободное место на сервере
▪️Снижение задержек в SSD дисках
▪️Файл удалили, а место не освободилось
▪️Шпаргалка с командами, если у вас закончилось место на диске
Сеть:
🔥Подборка утилит для просмотра статистики сетевых интерфейсов
▪️Анализ направлений трафика с реальными скоростями с iftop
▪️Анализ сетевой активности с помощью утилит из пакета netsniff-ng
▪️Запись дампа трафика конкретного приложения
Память:
🔥Просмотр использования памяти процессами с помощью pmap
▪️Кто и как использует swap
▪️Уменьшение или увеличение ram на ходу
▪️Удобный скрипт для просмотра использования оперативной памяти программами (не процессами!)
Разное:
▪️Расследование тормозов MySQL сервера
▪️Трассировка медленных запросов в php-fpm
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#подборка #linux #perfomance
Telegram
ServerAdmin.ru
Как и обещал, подготовил заметку по профилированию нагрузки в Linux. Первое, что нужно понимать — для диагностики нужна методика. Хаотичное использование различных инструментов только в самом простом случае даст положительный результат.
Наиболее известные…
Наиболее известные…
1👍184👎2
Я делал заметку про небольшой набор полезных для меня алиасов в консоли bash, которые я использую в повседневной работе в WLS2 на базе Ubuntu в своей рабочей Windows 11. Также я отдельно и подробно описывал один из них, который выводит информацию об IP адресах.
Мой набор пополнился ещё одним скриптом, которым хотел бы с вами поделиться. У меня он работает вот так:
Передаём на вход имя домена и на выходе получаем краткую информацию по нему:
◽️IP адреса на основе А записей
◽️NS записи
◽️MX записи
За основу взял вот этот скрипт. Он относительно простой. Парсится вывод утилиты host, про которую я отдельно писал ранее. Рекомендую взять на вооружение, регулярно пользуюсь.
Единственное, что я изменил - сделал вывод вместо обычного табличного в json. Мне почему-то так удобнее. Привык уже, возможно из-за подсветки. В общем, вывод сделал такой же, как у других алиасов.
Кстати, попросил ИИ помочь перевести изначальный вывод скрипта в json, напридумывали оба очень длинные потянки. Пришлось самому сделать, потратил 5 минут. Конкретно бесплатный ChatGPT и платный Perplexity AI нагенерировали мне простыню баша с sed и awk. Возможно надо было как-то промпт оформлять, чтобы получить то, что хотелось. Я просто взял две маленькие утилиты, про которые я тут раньше тоже уже писал - jc и jq:
А сам алиас, а точнее функция, выглядит вот так:
Эту строку надо добавить в файл
Хорошо, что я учился ещё в доИИшные времени. Честно говоря, даже не представляю, во что это всё в итоге выльется. Развитие ИИ сумасшедшее. Сам сейчас активно осваиваю и экспериментирую.
Ниже на картинке изначальный вывод и мой обработанный. Второй вариант можно использовать в задачах мониторинга, если каким-то образом наблюдаете за выводимы данными.
#linux #terminal
Мой набор пополнился ещё одним скриптом, которым хотел бы с вами поделиться. У меня он работает вот так:
$ dinfo yandex.ru{ "Checking the domain 'yandex.ru', please wait...": "", "Domain": "yandex.ru", "IP Address": "77.88.44.55 5.255.255.77 77.88.55.88", "Name Server": "Found 2 NS record", "Name Server 1": "ns1.yandex.ru (213.180.193.1)", "Name Server 2": "ns1.yandex.ru (213.180.193.1)", "Name Server 3": "ns2.yandex.ru (93.158.134.1)", "Name Server 4": "ns2.yandex.ru (93.158.134.1)", "Mail Server": "Found 1 MX record", "Mail Server 1": "mx.yandex.ru (77.88.21.249)"}Передаём на вход имя домена и на выходе получаем краткую информацию по нему:
◽️IP адреса на основе А записей
◽️NS записи
◽️MX записи
За основу взял вот этот скрипт. Он относительно простой. Парсится вывод утилиты host, про которую я отдельно писал ранее. Рекомендую взять на вооружение, регулярно пользуюсь.
Единственное, что я изменил - сделал вывод вместо обычного табличного в json. Мне почему-то так удобнее. Привык уже, возможно из-за подсветки. В общем, вывод сделал такой же, как у других алиасов.
Кстати, попросил ИИ помочь перевести изначальный вывод скрипта в json, напридумывали оба очень длинные потянки. Пришлось самому сделать, потратил 5 минут. Конкретно бесплатный ChatGPT и платный Perplexity AI нагенерировали мне простыню баша с sed и awk. Возможно надо было как-то промпт оформлять, чтобы получить то, что хотелось. Я просто взял две маленькие утилиты, про которые я тут раньше тоже уже писал - jc и jq:
$ view-domain-info.sh -d yandex.ru | jc --kv | jq .А сам алиас, а точнее функция, выглядит вот так:
function dinfo {
bash ~/alias_scripts/view-domain-info.sh -d $1 | jc --kv | jq .
}Эту строку надо добавить в файл
~/.bashrc и потом перечитать: source ~/.bashrc.Хорошо, что я учился ещё в доИИшные времени. Честно говоря, даже не представляю, во что это всё в итоге выльется. Развитие ИИ сумасшедшее. Сам сейчас активно осваиваю и экспериментирую.
Ниже на картинке изначальный вывод и мой обработанный. Второй вариант можно использовать в задачах мониторинга, если каким-то образом наблюдаете за выводимы данными.
#linux #terminal
👍55👎1
Я не так давно рассказывал про очень простую и наглядную интерпретацию метрики LA (Load Average). Данную тему будет уместно дополнить более современными метриками – PSI (Pressure Stall Information). Это подсистема ядра Linux, которая отслеживает три наиболее важных ресурса:
▪️CPU
▪️Memory
▪️I/O
В отличие от LA, которая показывает очередь процессов, ожидающих выполнение, PSI измеряет время ожидания процессов при получении доступа к ресурсам, что даёт более точное представление о загрузке системы в режиме реального времени. Плюсом, PSI интегрирована в cgroups, что позволяет мониторить нагрузку отдельных служб и контейнеров.
PSI имеет 3 периода измерений: avg10, avg60, avg300. Это время в секундах, то есть 10 секунд, 1 минута и 5 минут. К периодам прилагаются два типа метрик:
🔹some - процент времени, когда хотя бы один процесс ждёт освобождение ресурсов (line indicates the share of time in which at least some tasks are stalled on a given resource)
🔹full - процент времени, когда все активные процессы находятся в ожидании освобождения ресурсов (line indicates the share of time in which all non-idle tasks are stalled on a given resource simultaneously)
Эти метрики можно и нужно использовать в повседневной работе, наравне с привычными LA, disk r/w, iops. В версии htop, начиная с 3.0.0, можно включить их отображение. По умолчанию они не отображаются. Включаются так:
Открываем htop ⇨ F2 ⇨ Meters ⇨ Aviable Meters ⇨ Выбираем нужные метрики, нажатием Enter ⇨ F10 выйти с сохранением.
В недавнем обновлении Proxmox эти метрики появились на стандартном дашборде.
PSI активно используется в systemd-oomd – современной замене OOM Killer. А точнее помощнике. На основе метрик PSI он более избирательно останавливает процессы, а не ждёт, как OOM Killer, когда закончится память, чтобы прибить самого жирного потребителя при прочих равных условиях.
На практике метрики PSI могут быстро помочь определить узкое место в системе. Например, у вас начала тормозить СУБД. Заходите на сервер и видите высокий LA. Но сама по себе эта метрика не даёт никакой конкретики. Может быть чрезмерно нагружен как процессор, так и диск. Рядом метрики cpu some и io some сразу ответят на вопрос, где у вас узкое место. Если оно реально в CPU, то не придётся лезть в дисковую подсистему и смотреть, что там происходит.
Изменение метрик в режиме реального времени позволяют сразу же оценить какие-то свои изменения и посмотреть, как они повлияли на нагрузку. В общем, это полезные метрики, которые имеет смысл по умолчанию выводить в htop. Не знаю, есть ли они в обычном top. Я на все свои сервера без исключения ставлю htop. Очень к нему привык. Там и PSI, и вкладка I/O с активностью диска, и lsof для просмотра открытых файлов, и strace. В общем, очень удобно.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #perfomance
▪️CPU
▪️Memory
▪️I/O
В отличие от LA, которая показывает очередь процессов, ожидающих выполнение, PSI измеряет время ожидания процессов при получении доступа к ресурсам, что даёт более точное представление о загрузке системы в режиме реального времени. Плюсом, PSI интегрирована в cgroups, что позволяет мониторить нагрузку отдельных служб и контейнеров.
PSI имеет 3 периода измерений: avg10, avg60, avg300. Это время в секундах, то есть 10 секунд, 1 минута и 5 минут. К периодам прилагаются два типа метрик:
🔹some - процент времени, когда хотя бы один процесс ждёт освобождение ресурсов (line indicates the share of time in which at least some tasks are stalled on a given resource)
🔹full - процент времени, когда все активные процессы находятся в ожидании освобождения ресурсов (line indicates the share of time in which all non-idle tasks are stalled on a given resource simultaneously)
Эти метрики можно и нужно использовать в повседневной работе, наравне с привычными LA, disk r/w, iops. В версии htop, начиная с 3.0.0, можно включить их отображение. По умолчанию они не отображаются. Включаются так:
Открываем htop ⇨ F2 ⇨ Meters ⇨ Aviable Meters ⇨ Выбираем нужные метрики, нажатием Enter ⇨ F10 выйти с сохранением.
В недавнем обновлении Proxmox эти метрики появились на стандартном дашборде.
PSI активно используется в systemd-oomd – современной замене OOM Killer. А точнее помощнике. На основе метрик PSI он более избирательно останавливает процессы, а не ждёт, как OOM Killer, когда закончится память, чтобы прибить самого жирного потребителя при прочих равных условиях.
На практике метрики PSI могут быстро помочь определить узкое место в системе. Например, у вас начала тормозить СУБД. Заходите на сервер и видите высокий LA. Но сама по себе эта метрика не даёт никакой конкретики. Может быть чрезмерно нагружен как процессор, так и диск. Рядом метрики cpu some и io some сразу ответят на вопрос, где у вас узкое место. Если оно реально в CPU, то не придётся лезть в дисковую подсистему и смотреть, что там происходит.
Изменение метрик в режиме реального времени позволяют сразу же оценить какие-то свои изменения и посмотреть, как они повлияли на нагрузку. В общем, это полезные метрики, которые имеет смысл по умолчанию выводить в htop. Не знаю, есть ли они в обычном top. Я на все свои сервера без исключения ставлю htop. Очень к нему привык. Там и PSI, и вкладка I/O с активностью диска, и lsof для просмотра открытых файлов, и strace. В общем, очень удобно.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #perfomance
4👍143👎2
Относительно недавно (2018 год) по меркам Linux в составе базовых системных утилит популярных дистрибутивов появилась утилита choom. Узнал о ней случайно. В Debian и Ubuntu она есть по умолчанию, отдельно ставить не надо. В других не проверял.
Забегая вперёд скажу, что лично я для неё применения не увидел, но решил всё равно написать для общего образования. Кому-то может пригодится. Не просто же так её написали и добавили в дистрибутивы. С помощью choom можно управлять таким параметром, как OOM score adjustment (oom_score_adj). На его основе OOM-killer принимает решение о том, какой процесс завершить при нехватке оперативной памяти в системе.
Choom работает с запущенными процессами на лету, используя их pid. Примерно так:
Посмотрели текущее значения
Проверяем:
Oom_score стал 0, а oom_score_adj, как и указали -1000. В данном примере pid 1994 - это процесс mariadbd. Удобней было бы сделать сразу вот так:
Вообще, принцип работы OOM-killer довольно замороченный. Как видно, у него есть два параметра oom_score и oom_score_adj. Первый показывает текущие накопленные баллы, которые динамически изменяются в зависимости от различных условий, а второй - это то, что задаётся вручную и тоже влияет на oom_score. Сделав oom_score_adj минимальным, то есть -1000, мы и oom_score уменьшили.
Вручную всё это менять имеет смысл только в каких-то отладочных целях. Для постоянной работы этими параметрами удобнее управлять через systemd. Просто указываем в unit файле сервиса нужные значения:
Перезапускаем сервис и проверяем. В случае с mariadb это будет выглядеть так. Делаем корректировку стандартного юнита:
Добавляем в конфигурацию:
Перечитываем параметры юнита и перезапускаем его.
Проверяем значение:
По сути choom удобен именно для просмотра. Смотреть значения с помощью утилиты быстрее и проще, чем напрямую:
Она по сути именно это и делает. И меняет значение тоже переопределяя именно эти параметры.
На практике я никогда не занимался настройкой
Исключение, наверное, для каких-то специфических случаев, когда целенаправленно нужно использовать всю память сервера, но при этом гарантированно иметь работающим какое-то приложение. Я не могу придумать таких примеров, но думаю, что они есть. Если кто-то знает такие истории, поделитесь в комментариях. Когда вам приходилось целенаправленно настраивать OOMScoreAdjust? В голову приходят агенты мониторинга. Желательно, чтобы они всегда работали, но на практике я не видел, чтобы их первым отключал OOM-killer.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal #systemd
Забегая вперёд скажу, что лично я для неё применения не увидел, но решил всё равно написать для общего образования. Кому-то может пригодится. Не просто же так её написали и добавили в дистрибутивы. С помощью choom можно управлять таким параметром, как OOM score adjustment (oom_score_adj). На его основе OOM-killer принимает решение о том, какой процесс завершить при нехватке оперативной памяти в системе.
Choom работает с запущенными процессами на лету, используя их pid. Примерно так:
# choom -p 1994pid 1994's current OOM score: 684pid 1994's current OOM score adjust value: 0Посмотрели текущее значения
oom_score и oom_score_adj. Для того, чтобы максимально уменьшить шанс для процесса быть убитыми, ему нужно присвоить параметр oom_score_adj -1000. Соответственно, параметр 1000 будет означать максимальный шанс. То есть там разбег от -1000 до 1000. И чем меньше значение, тем меньше шанса быть завершённым. # choom -p 1994 -n -1000Проверяем:
# choom -p 1994pid 1994's current OOM score: 0pid 1994's current OOM score adjust value: -1000Oom_score стал 0, а oom_score_adj, как и указали -1000. В данном примере pid 1994 - это процесс mariadbd. Удобней было бы сделать сразу вот так:
# choom -p $(pidof mariadbd) -n 1000Вообще, принцип работы OOM-killer довольно замороченный. Как видно, у него есть два параметра oom_score и oom_score_adj. Первый показывает текущие накопленные баллы, которые динамически изменяются в зависимости от различных условий, а второй - это то, что задаётся вручную и тоже влияет на oom_score. Сделав oom_score_adj минимальным, то есть -1000, мы и oom_score уменьшили.
Вручную всё это менять имеет смысл только в каких-то отладочных целях. Для постоянной работы этими параметрами удобнее управлять через systemd. Просто указываем в unit файле сервиса нужные значения:
[Service]............OOMScoreAdjust=-800............Перезапускаем сервис и проверяем. В случае с mariadb это будет выглядеть так. Делаем корректировку стандартного юнита:
# systemctl edit mariadbДобавляем в конфигурацию:
[Service]OOMScoreAdjust=-800Перечитываем параметры юнита и перезапускаем его.
# systemctl daemon-reload# systemctl restart mariadbПроверяем значение:
# choom -p $(pidof mariadbd)pid 2274's current OOM score: 152pid 2274's current OOM score adjust value: -800По сути choom удобен именно для просмотра. Смотреть значения с помощью утилиты быстрее и проще, чем напрямую:
# cat /proc/2274/oom_score# cat /proc/2274/oom_score_adjОна по сути именно это и делает. И меняет значение тоже переопределяя именно эти параметры.
На практике я никогда не занимался настройкой
OOMScoreAdjust. Если на сервере кончается память и приходит OOM-killer - это аварийная ситуация. Надо идти и разбираться, куда утекает память и почему её не хватает. Обычно после этого её должно хватать. Исключение, наверное, для каких-то специфических случаев, когда целенаправленно нужно использовать всю память сервера, но при этом гарантированно иметь работающим какое-то приложение. Я не могу придумать таких примеров, но думаю, что они есть. Если кто-то знает такие истории, поделитесь в комментариях. Когда вам приходилось целенаправленно настраивать OOMScoreAdjust? В голову приходят агенты мониторинга. Желательно, чтобы они всегда работали, но на практике я не видел, чтобы их первым отключал OOM-killer.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal #systemd
3👍83👎1
Как понять, что системе на базе Linux требуется перезагрузка? Самый простой способ - использовать программу needrestart (deb дистрибутивы) или needs-restarting (rpm дистрибутивы). Я про неё подробно рассказывал. Её можно использовать для собственного мониторинга. Также другой софт может на неё опираться. Например, Lynis.
Needrestart установлен не всегда и не везде. Например, в базовых образах LXC контейнеров в Proxmox его нет. Если система не ваша, то самостоятельно лучше ничего не ставить.
Косвенно узнать, что у нас со службами и перезагрузкой можно очень простым и привычным способом, но для других задач. На помощью придёт lsof.
Тут видно удалённые файлы системных сервисов, таких как systemd, sshd, ну и bash заодно. То есть было обновление, приехали новые версии этих файлов, заменили старые. Но так как службы не перезапускались, они до сих пор используют удалённые файлы.
Для systemd существует специальная команда для полного перезапуска службы в том числе после обновления:
Её, кстати, часто ошибочно предлагают ИИ, когда изменяются настройки юнитов. Использовать её в этом случае не стоит. К сожалению, эта команда не всегда помогает запустить systemd с обновлённым бинарём. В таком случае поможет только перезагрузка.
С другими службами проще. Для обновления
А вот если изменился systemd, glibc или ядро, то тут без reboot уже не обойтись. Ядро, кстати, можно так посмотреть:
Это текущая версия, а вот список установленных ядер:
Установлен пакет с более свежим ядром. Надо перезагружаться.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux
Needrestart установлен не всегда и не везде. Например, в базовых образах LXC контейнеров в Proxmox его нет. Если система не ваша, то самостоятельно лучше ничего не ставить.
Косвенно узнать, что у нас со службами и перезагрузкой можно очень простым и привычным способом, но для других задач. На помощью придёт lsof.
# lsof -nP +L1 | grep '(deleted)'
systemd-l 488 root txt REG 8,1 281096 0 270929 /usr/lib/systemd/systemd-logind (deleted)
dockerd 526 root txt REG 8,1 75181152 0 265728 /usr/sbin/dockerd (deleted)
sshd 532 root txt REG 8,1 1265432 0 262298 /usr/sbin/sshd (deleted)
systemd 582 root txt REG 8,1 92544 0 270899 /usr/lib/systemd/systemd (deleted)
(sd-pam) 584 root txt REG 8,1 92544 0 270899 /usr/lib/systemd/systemd (deleted)
bash 647 root txt REG 8,1 1265648 0 263309 /usr/bin/bash (deleted)
Тут видно удалённые файлы системных сервисов, таких как systemd, sshd, ну и bash заодно. То есть было обновление, приехали новые версии этих файлов, заменили старые. Но так как службы не перезапускались, они до сих пор используют удалённые файлы.
Для systemd существует специальная команда для полного перезапуска службы в том числе после обновления:
# systemctl daemon-reexec
Её, кстати, часто ошибочно предлагают ИИ, когда изменяются настройки юнитов. Использовать её в этом случае не стоит. К сожалению, эта команда не всегда помогает запустить systemd с обновлённым бинарём. В таком случае поможет только перезагрузка.
С другими службами проще. Для обновления
sshd и bash достаточно переподключиться по SSH. В новой сессии загрузятся уже новые бинарники.А вот если изменился systemd, glibc или ядро, то тут без reboot уже не обойтись. Ядро, кстати, можно так посмотреть:
# uname -r
6.1.0-35-amd64
Это текущая версия, а вот список установленных ядер:
# dpkg -l | grep linux-image
.................................
ii linux-image-6.1.0-39-amd64 6.1.148-1 amd64 Linux 6.1 for 64-bit PCs (signed)
Установлен пакет с более свежим ядром. Надо перезагружаться.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux
1👍149👎1
В недавнем опросе про консольные редакторы было много упоминаний редактора micro. Никогда не пробовал и не работал в нём. Решил исправить. И вы знаете, он меня реально впечатлил. В нём удобно работать. Удобнее, чем во всех других, с которыми приходилось сталкиваться. Расскажу про основные моменты, на которые обратил внимание.
1️⃣ Установка. Тут всё просто. Micro есть в базовых репозиториях дистрибутивов, так что можно сделать так:
Я хотел получить самую свежую версию, поэтому сделал вот так:
По сути это просто одиночный бинарник на Go. Можно скачать из репозитория.
2️⃣ Делаем micro редактором по умолчанию:
Для того, чтобы в Midnight Commander (mc) он тоже выступал в качестве редактора, надо добавить в
И перечитать файл:
В MC нажимаем F9 ⇨ Options ⇨ Configuration ⇨ [ ] Use internal editor. Убираем галочку с внутреннего редактора. Теперь вместо
📌Теперь что больше всего понравилось:
🔹В micro можно передать текст через pipe:
И весь вывод откроется в редакторе, где с ним можно работать. Не знаю, как вам, но я в других редакторах этого не видел и не использовал. Мне показался очень удобным этот момент. За одно это захотелось использовать micro.
🔹В micro работает копирование/вставка так же, как в гуишных редакторах. Не нужны какие-то особенные выделения через Shift, как это сделано в mcedit или через какие-то другие горячие клавиши.
В micro просто выделяете мышкой текст, копируете по Ctrl+c, выбираете мышкой место, куда будете вставлять и вставляете по Ctrl+v. Как в любом редакторе. Плюс, работает Ctrl+a для выделения всего текста.
Но тут же заметил и минус. Если в mcedit ты выделил текст через Shift, он копируется в буфер внешней системы, через которую ты подключился. Можно вставить текст куда-то во вне терминала. Если копируешь текст в micro, он остаётся в буфере на сервере, и вне терминала его не скопировать. Я не понял, как выйти из этой ситуации и скопировать текст из редактора куда-то во вне. Думаю, этот момент зависит от настроек и возможностей SSH клиента.
🔹В micro полная поддержка мышки. Помимо копирования, вставки, можно двойным кликом выделить слово, тройным всю строку, чтобы, к примеру, её скопировать или удалить.
Выписал для себя горячие клавиши, которыми буду пользоваться:
▪️Ctrl-q, F10 выход
▪️Ctrl-s, F2 сохранение
▪️Ctrl-f, F7 поиск
▪️Ctrl-o открыть файл
▪️Ctrl-z откатить изменения
▪️Ctrl-с копировать
▪️Ctrl-v вставить
▪️Ctrl-k вырезать строку
▪️Ctrl-e открыть командную строку для внутренних команд
Как видно, некоторые клавиши пересекаются с
Я акцентировал внимание только на нескольких моментах, которые понравились больше всего. У Micro много других возможностей, про которые я не упомянул:
- Можно переназначать горячие клавиши
- У него различные темы и подсветки синтаксиса
- Есть плагины
- Можно открыть терминал в нижней строке редактора
- Можно делить экран на несколько рабочих областей
Лично мне micro понравился. Он объединил в себе набор полезной функциональности, простоту и удобство других редакторов. Много умеет, легко осваивается, можно усложнить плагинами, если захочется.
Если ещё не прикипели к какому-то редактору, то смело используйте micro. Я себе поставил его по умолчанию в WSL. Буду пользоваться. Если понравится и привыкну, то начну ставить его везде. Он по всем параметрам лучше и удобнее
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal
# apt install microЯ хотел получить самую свежую версию, поэтому сделал вот так:
# curl https://getmic.ro | bash# mv micro /usr/bin/microПо сути это просто одиночный бинарник на Go. Можно скачать из репозитория.
# update-alternatives --install /usr/bin/editor editor /usr/bin/micro 50# update-alternatives --set editor /usr/bin/microДля того, чтобы в Midnight Commander (mc) он тоже выступал в качестве редактора, надо добавить в
~/.bashrc пару переменных:export EDITOR=microexport VISUAL=microИ перечитать файл:
# source ~/.bashrcВ MC нажимаем F9 ⇨ Options ⇨ Configuration ⇨ [ ] Use internal editor. Убираем галочку с внутреннего редактора. Теперь вместо
mcedit будет использоваться micro.📌Теперь что больше всего понравилось:
🔹В micro можно передать текст через pipe:
# docker inspect aa3a452f7320 | microИ весь вывод откроется в редакторе, где с ним можно работать. Не знаю, как вам, но я в других редакторах этого не видел и не использовал. Мне показался очень удобным этот момент. За одно это захотелось использовать micro.
🔹В micro работает копирование/вставка так же, как в гуишных редакторах. Не нужны какие-то особенные выделения через Shift, как это сделано в mcedit или через какие-то другие горячие клавиши.
В micro просто выделяете мышкой текст, копируете по Ctrl+c, выбираете мышкой место, куда будете вставлять и вставляете по Ctrl+v. Как в любом редакторе. Плюс, работает Ctrl+a для выделения всего текста.
Но тут же заметил и минус. Если в mcedit ты выделил текст через Shift, он копируется в буфер внешней системы, через которую ты подключился. Можно вставить текст куда-то во вне терминала. Если копируешь текст в micro, он остаётся в буфере на сервере, и вне терминала его не скопировать. Я не понял, как выйти из этой ситуации и скопировать текст из редактора куда-то во вне. Думаю, этот момент зависит от настроек и возможностей SSH клиента.
🔹В micro полная поддержка мышки. Помимо копирования, вставки, можно двойным кликом выделить слово, тройным всю строку, чтобы, к примеру, её скопировать или удалить.
Выписал для себя горячие клавиши, которыми буду пользоваться:
▪️Ctrl-q, F10 выход
▪️Ctrl-s, F2 сохранение
▪️Ctrl-f, F7 поиск
▪️Ctrl-o открыть файл
▪️Ctrl-z откатить изменения
▪️Ctrl-с копировать
▪️Ctrl-v вставить
▪️Ctrl-k вырезать строку
▪️Ctrl-e открыть командную строку для внутренних команд
Как видно, некоторые клавиши пересекаются с
mcedit. Ну а в целом набор горячих клавиш типовой, хоть и непривычный для меня в консольном редакторе.Я акцентировал внимание только на нескольких моментах, которые понравились больше всего. У Micro много других возможностей, про которые я не упомянул:
- Можно переназначать горячие клавиши
- У него различные темы и подсветки синтаксиса
- Есть плагины
- Можно открыть терминал в нижней строке редактора
- Можно делить экран на несколько рабочих областей
Лично мне micro понравился. Он объединил в себе набор полезной функциональности, простоту и удобство других редакторов. Много умеет, легко осваивается, можно усложнить плагинами, если захочется.
Если ещё не прикипели к какому-то редактору, то смело используйте micro. Я себе поставил его по умолчанию в WSL. Буду пользоваться. Если понравится и привыкну, то начну ставить его везде. Он по всем параметрам лучше и удобнее
mcedit, которым я пользуюсь просто из-за привычки.⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal
Please open Telegram to view this post
VIEW IN TELEGRAM
3👍167👎4