В свете недавних обсуждений гипервизоров вспомнил, как я начинал изучение 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👍151👎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👍185👎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
Когда надо узнать скорость сетевого интерфейса в Linux, первое, что приходит на ум - ethtool. Это самая популярная утилита для просмотра и управления настройками сетевых адаптеров. С ней только одна проблема - в базовом наборе системных утилит её обычно нет. Надо ставить отдельно:
Для разовых задач особого смысла в этом нет, потому что все подобные утилиты берут информацию у ядра. Нет никаких проблем самим её посмотреть. Проверяем имена своих сетевых интерфейсов:
И смотрим скорость:
В данном случае это скорость 1000Mb/s или 1Gb/s. Если у вас виртуальная машина, то в зависимости от типа эмуляции, вы можете получить неожиданные значения:
В данном случае
Это скорость сетевой карты, которая в бридже с виртуальным коммутатором для виртуальных машин.
☝️Кстати, если хотите быстро узнать, в виртуалке вы или на железе, запустите:
Я всегда использую эту команду для таких задач.
Помимо скорости интерфейса, ядро может передать всю остальную информацию. Например, наличие линка, параметры дуплекса, mtu или mac адрес:
Можете зайти в директорию
Таким образом можно посмотреть всё, что угодно из того, что показывают системные утилиты. Просто некоторые значения нужно преобразовывать. Например, открытые TCP порты:
Номера портов будут в шестнадцатеричном формате. Подобным образом у ядра можно выведать массу информации. Примерно этим и занимаются многочисленные клоны *top-ов и им подобных утилит. Вы и сами что-то подобное можете написать под свои задачи относительно просто, особенно с помощью ИИ.
#linux #terminal
# apt install ethtoolДля разовых задач особого смысла в этом нет, потому что все подобные утилиты берут информацию у ядра. Нет никаких проблем самим её посмотреть. Проверяем имена своих сетевых интерфейсов:
# ip a И смотрим скорость:
# cat /sys/class/net/enp4s0/speed1000В данном случае это скорость 1000Mb/s или 1Gb/s. Если у вас виртуальная машина, то в зависимости от типа эмуляции, вы можете получить неожиданные значения:
# cat /sys/class/net/ens18/speed-1В данном случае
-1 - это отсутствие какого-либо значения, нет данных. Это характерно для виртуальных машин в KVM. Virtio-драйвер не сообщает реальную физическую скорость (у него её просто нет) даже если он в бридже с реальной сетевой картой. А вот драйвер в Hyper-V сообщает:# cat /sys/class/net/eth0/speed1000Это скорость сетевой карты, которая в бридже с виртуальным коммутатором для виртуальных машин.
☝️Кстати, если хотите быстро узнать, в виртуалке вы или на железе, запустите:
# hostnamectlЯ всегда использую эту команду для таких задач.
Помимо скорости интерфейса, ядро может передать всю остальную информацию. Например, наличие линка, параметры дуплекса, mtu или mac адрес:
# cat /sys/class/net/enp4s0/carrier1# cat /sys/class/net/enp4s0/duplexfull# cat /sys/class/net/enp4s0/mtu1500# cat /sys/class/net/enp4s0/address00:25:22:dc:39:42Можете зайти в директорию
/sys/class/net/enp4s0/ и посмотреть всё, что там есть.Таким образом можно посмотреть всё, что угодно из того, что показывают системные утилиты. Просто некоторые значения нужно преобразовывать. Например, открытые TCP порты:
# cat /proc/net/tcpНомера портов будут в шестнадцатеричном формате. Подобным образом у ядра можно выведать массу информации. Примерно этим и занимаются многочисленные клоны *top-ов и им подобных утилит. Вы и сами что-то подобное можете написать под свои задачи относительно просто, особенно с помощью ИИ.
#linux #terminal
👍102👎2
Проработал вчера вопрос обновления Debian 12 до свежего релиза 13 Trixie. Предстоит много раз проделать эту процедуру, поэтому решил сам внимательно прочитать документацию к новому релизу и вручную выполнить обновление.
⇨ Как обновить Debian 12 до Debian 13 Trixie
Из особенностей отмечу следующее:
🔹У меня возникли проблемы совместимости с некоторыми пакетами Docker, так что рекомендую всё, что установлено не из стандартных репозиториев удалить, а после обновления вернуть, иначе в процессе могут возникнуть ошибки совместимости и зависимости пакетов.
🔹Очень сильно изменилась конфигурация imap сервера Dovecot в той версии, что приедет с новым релизом. Внимательно проверьте новую конфигурацию сервиса перед обновлением и отладьте. Иначе может случиться сюрприз. Я уже видел отзывы на эту тему.
🔹Наконец-то обновился менеджер пакетов
🔹В Debian 13 убраны утилиты
🔹Раздел
🔹Немного поменялся установщик. Я лично посмотрел на его. По описанию показалось, что он сильно поменялся. На деле не увидел изменений. Основные изменения под капотом. Внешний вид точно такой же остался. Упоминалось, что изменился алгоритм автоматической настройки разделов и точек монтирования. Заметил только, что размер раздела под swap немного по-другому выбирается. Больше никакой разницы не увидел со старым установщиков, который я знаю ещё со времён 6-й версии.
🔹Если у вас на сервере установлена MariaDB, имейте ввиду, что режим recovery запустится только с теми же бинарниками, с которыми база упала. То есть если аварийно завершите работу СУБД версии 10.11 и обновитесь до 11.8, восстановление не сработает. Поэтому перед обновлением корректно завершите работу СУБД, чтобы она остановилась без каких-либо ошибок.
🔹Если в системе используется служба systemd-sysctl, то файл /etc/sysctl.conf больше ею не поддерживается. Вместо него используется /usr/lib/sysctl.d/50-default.conf. Важное изменение. Имейте ввиду. Настройки лучше хранить в /etc/sysctl.d/*.conf.
Всё это вычитал по официальным ссылкам:
◽️What’s new in Debian 13
◽️Upgrades from Debian 12 (bookworm)
#linux #debian
⇨ Как обновить Debian 12 до Debian 13 Trixie
Из особенностей отмечу следующее:
🔹У меня возникли проблемы совместимости с некоторыми пакетами Docker, так что рекомендую всё, что установлено не из стандартных репозиториев удалить, а после обновления вернуть, иначе в процессе могут возникнуть ошибки совместимости и зависимости пакетов.
🔹Очень сильно изменилась конфигурация imap сервера Dovecot в той версии, что приедет с новым релизом. Внимательно проверьте новую конфигурацию сервиса перед обновлением и отладьте. Иначе может случиться сюрприз. Я уже видел отзывы на эту тему.
🔹Наконец-то обновился менеджер пакетов
apt и стал хоть немного, но удобнее за счёт форматирования списка пакетов и подсветки. Не понимаю, почему так долго не могли это сделать. Но даже в таком виде он выглядит хуже, чем yum или dnf даже 15 лет назад. У apt появился новый формат конфигурации. Я использовал уже его.🔹В Debian 13 убраны утилиты
last, lastb и lastlog. Вместо них можно использовать wtmpdb (пакет libpam-wtmpdb), lastlog2 (пакет libpam-lastlog2) и команду lslogins --failed.🔹Раздел
/tmp переехал в оперативную память tmpfs. Может занимать до 50% свободной памяти. Настроить поведение можно в systemd в отдельном конфигурационном файле для этого tmp.mount.🔹Немного поменялся установщик. Я лично посмотрел на его. По описанию показалось, что он сильно поменялся. На деле не увидел изменений. Основные изменения под капотом. Внешний вид точно такой же остался. Упоминалось, что изменился алгоритм автоматической настройки разделов и точек монтирования. Заметил только, что размер раздела под swap немного по-другому выбирается. Больше никакой разницы не увидел со старым установщиков, который я знаю ещё со времён 6-й версии.
🔹Если у вас на сервере установлена MariaDB, имейте ввиду, что режим recovery запустится только с теми же бинарниками, с которыми база упала. То есть если аварийно завершите работу СУБД версии 10.11 и обновитесь до 11.8, восстановление не сработает. Поэтому перед обновлением корректно завершите работу СУБД, чтобы она остановилась без каких-либо ошибок.
🔹Если в системе используется служба systemd-sysctl, то файл /etc/sysctl.conf больше ею не поддерживается. Вместо него используется /usr/lib/sysctl.d/50-default.conf. Важное изменение. Имейте ввиду. Настройки лучше хранить в /etc/sysctl.d/*.conf.
Всё это вычитал по официальным ссылкам:
◽️What’s new in Debian 13
◽️Upgrades from Debian 12 (bookworm)
#linux #debian
Server Admin
Обновление Debian 12 до 13 Trixie | serveradmin.ru
Пошаговая инструкция с разбором нюансов обновления и возможных ошибок при обновлении Debian 12 до 13-й версии.
1👍161👎2
В новом релизе Debian 13 обновился пакетный менеджер apt до версии 3.0, которая вышла в апреле 2025 года. В прошлом релизе apt был версии 2.6. От пакетного менеджера нужно обычно немного - установить пакет и зависимости. Основное, на что обращаешь внимание - интерфейс. И вот тут у apt всегда было всё как-то не очень.
Это не очень и попытались исправить. Стало лучше, но всё равно не так информативно, как в том же
Ну да ладно, что есть то есть. Посмотрел повнимательнее на новый apt, так как теперь постоянно с ним работать придётся. Вот основные изменения по сравнению с прошлой версией.
1️⃣ Как я уже сказал - внешний вид. Более наглядно выделены пакеты и зависимости. Плюс, по умолчанию появилась подсветка. Ею, если что, можно управлять через параметры. Не знаю, кому это может понадобиться. Я точно заниматься подобной настройкой не буду.
2️⃣ Теперь вывод apt, который не умещается в один экран терминала, например, при
Для ручного просмотра это удобно, но теперь не понятно, как грепать вывод. Надо отключать новый pager. Но не хочется лезть в настройки для этого. Можно сделать так:
Такой формат трудно запомнить. Нужно будет постоянно в шпаргалку лазить, что неудобно. В общем, нововведение так себе.
3️⃣ Появилась поддержка формата DEB822 для описания репозиториев. Вместо файла
Эта команда забэкапит файл
Мне новый формат понравился больше. Лучше воспринимается на глаз за счёт того, что запись репозитория разбита на строки с заголовками. Плюс, через
4️⃣ Появился новый движок поиска зависимостей. Не знаю, для чего он был сделан и какие проблемы решил. Я не сталкивался с какими-то проблемами в зависимостях из-за apt.
Ещё ряд не таких заметных в эксплуатации изменений:
- появились несжатые индексы, традиционно их сжимают gzip или xz, теперь будут и несжатые
- переработали механизм autoremove, но я не увидел сам и не нашёл нигде примеров, что конкретно изменилось
- прекращено использование утилиты apt-key и общего хранилища ключей, но это не сказать, что что-то новое, от неё уже давно отказываются в пользу отдельного ключа для каждого репозитория
- вместо gnutls и gcrypt для шифрования теперь используется openssl
В завершении несколько полезных ключей для apt.
Посмотреть версии устанавливаемых пакетов:
Пакеты, установленные не из системных репозиториев:
Список установленных пакетов с версиями и репозиториями, откуда они были установлены:
То же самое, только чтобы можно было грепнуть неродные репы:
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#linux #debian
Это не очень и попытались исправить. Стало лучше, но всё равно не так информативно, как в том же
dnf. Сравнение можно посмотреть на картинке внизу. Не знаю, в чём сложность повторить примерно так же. У dnf и репозиторий сразу видно, и версию пакета, и отформатировано аккуратнее. У apt стало лучше, чем было, когда все пакеты простынёй вываливали. Частично это можно было исправить дополнительными ключами, но всё равно не так наглядно было, как у dnf. Ну да ладно, что есть то есть. Посмотрел повнимательнее на новый apt, так как теперь постоянно с ним работать придётся. Вот основные изменения по сравнению с прошлой версией.
apt search, не вываливается весь в него, а выводится построчно, как при использовании less. Соответственно, работают все горячие клавиши от less. Я чаще всего использую Shif-g - переместиться в конец списка, / - включить поиск. Подробнее про less писал отдельно.Для ручного просмотра это удобно, но теперь не понятно, как грепать вывод. Надо отключать новый pager. Но не хочется лезть в настройки для этого. Можно сделать так:
# apt -o APT::Pager= list | grep zabbixТакой формат трудно запомнить. Нужно будет постоянно в шпаргалку лазить, что неудобно. В общем, нововведение так себе.
sources.list можно описывать репозитории в sources.list.d/*.sources. Текущий sources.list преобразовать в новый формат можно так:# apt modernize-sourcesЭта команда забэкапит файл
sources.list и создаст вместо него sources.list.d/debian.sources. Так же новый apt поддерживает использование Debian APT CDN. Можно указать в качестве источника пакетов deb.debian.org, а реальный сервер для загрузки будет выбран автоматически на основании не знаю чего. Не нашёл информации на этот счёт.Мне новый формат понравился больше. Лучше воспринимается на глаз за счёт того, что запись репозитория разбита на строки с заголовками. Плюс, через
Enabled: no можно отключать репозиторий. Это более аккуратно выглядит, чем комментирование строк с репозиториями.Ещё ряд не таких заметных в эксплуатации изменений:
- появились несжатые индексы, традиционно их сжимают gzip или xz, теперь будут и несжатые
- переработали механизм autoremove, но я не увидел сам и не нашёл нигде примеров, что конкретно изменилось
- прекращено использование утилиты apt-key и общего хранилища ключей, но это не сказать, что что-то новое, от неё уже давно отказываются в пользу отдельного ключа для каждого репозитория
- вместо gnutls и gcrypt для шифрования теперь используется openssl
В завершении несколько полезных ключей для apt.
Посмотреть версии устанавливаемых пакетов:
# apt -V install mcПакеты, установленные не из системных репозиториев:
# apt list '?narrow(?installed, ?not(?origin(Debian)))'Список установленных пакетов с версиями и репозиториями, откуда они были установлены:
# apt -o APT::Pager= list --installed -a | grep -v stableТо же самое, только чтобы можно было грепнуть неродные репы:
# apt -o APT::Pager= list -a --installed | grep -v stable | grep -v '^$'———
ServerAdmin:
#linux #debian
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍105👎2
На днях зашёл в свежеустановленную из шаблона систему Rocky Linux 9 и с удивлением увидел неработающую. команду:
Первый раз с таким столкнулся. Почему-то был уверен, что это либо системная утилита, либо часть оболочки bash. Не припоминаю, чтобы я отдельно её ставил.
Эта команда полностью очищает терминал и возвращает курсор на самую первую строку. Я постоянно её использую в процессе работы в консоли. Регулярно по привычке набираю её в терминале Windows и расстраиваюсь, что она не работает. Начинаю вспоминать, как она выглядит в винде. Даю подсказку -
Оказывается, эта утилита живёт в пакете ncurses. В Debian и Ubuntu никогда этот пакет не ставил. Утилита clear там была во всех редакциях и шаблонах, с которыми мне приходилось работать. А вот в Rocky пришлось поставить:
Так что если не знали, про clear, то рекомендую посмотреть и пользоваться. Удобная утилита. Ну а если потеряли, то знайте, что живёт она в отдельном пакете.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#linux #terminal
# clear-bash: clear: command not foundПервый раз с таким столкнулся. Почему-то был уверен, что это либо системная утилита, либо часть оболочки bash. Не припоминаю, чтобы я отдельно её ставил.
Эта команда полностью очищает терминал и возвращает курсор на самую первую строку. Я постоянно её использую в процессе работы в консоли. Регулярно по привычке набираю её в терминале Windows и расстраиваюсь, что она не работает. Начинаю вспоминать, как она выглядит в винде. Даю подсказку -
cls. Оказывается, эта утилита живёт в пакете ncurses. В Debian и Ubuntu никогда этот пакет не ставил. Утилита clear там была во всех редакциях и шаблонах, с которыми мне приходилось работать. А вот в Rocky пришлось поставить:
# dnf install ncursesТак что если не знали, про clear, то рекомендую посмотреть и пользоваться. Удобная утилита. Ну а если потеряли, то знайте, что живёт она в отдельном пакете.
———
ServerAdmin:
#linux #terminal
Please open Telegram to view this post
VIEW IN TELEGRAM
👍100👎3
Столкнулся на днях с ошибкой, которую уже давно не видел. Минут 10 потратил, пока не понял, в чём проблема. Давно работает один LXC контейнер с Debian внутри. У меня давняя привычка везде и всюду использовать названия только на английском языке и никогда не ставить пробелы, заменяя их тире или подчёркиванием. И вам того же советую во избежание траты времени на поиск внезапных ошибок или проблем с отладкой.
Закинул туда скрипт с комментариями на русском языке, которые иногда оставляю в начале. Вместо русских букв местами получил крякозябры. Первое, на что посмотрел - кодировка исходного текста. На всякий случай сохранил его в VSCode, убедился, что там UTF-8 и скопировал ещё раз. Не помогло.
Подумал, может это в mcedit проблема. Открыл скрипт в nano - там то же самое. На всякий случай скопировал по scp этот же скрипт, чтобы исключить проблемы, связанные с буфером обмена. То же самое. Копирую на другой сервер, там всё нормально.
Дальше понял, что надо локали в терминале смотреть:
Если честно, даже не знаю, что это за локаль
Меняю локаль на английскую:
Теперь надо перезагрузиться, чтобы настройки применились. Перезахода в систему будет недостаточно. Или можно вручную выбрать из списка:
Чтобы новая локально заработала, нужно перезайти пользователем в терминал. Перезагружаться не обязательно.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#linux #terminal
Закинул туда скрипт с комментариями на русском языке, которые иногда оставляю в начале. Вместо русских букв местами получил крякозябры. Первое, на что посмотрел - кодировка исходного текста. На всякий случай сохранил его в VSCode, убедился, что там UTF-8 и скопировал ещё раз. Не помогло.
Подумал, может это в mcedit проблема. Открыл скрипт в nano - там то же самое. На всякий случай скопировал по scp этот же скрипт, чтобы исключить проблемы, связанные с буфером обмена. То же самое. Копирую на другой сервер, там всё нормально.
Дальше понял, что надо локали в терминале смотреть:
# localeLANG=C........Если честно, даже не знаю, что это за локаль
C. Пока нигде не было русского языка, проблем не замечал. Обычно тут по умолчанию стоит en_US.UTF-8. Если и надо поменять локаль, то на ru_RU.UTF-8, чтобы нормально 1С сервер работал. Больше не знаю ситуаций, где бы стоило менять её с английской.Меняю локаль на английскую:
# locale-gen en_US.UTF-8# update-locale en_US.UTF-8Теперь надо перезагрузиться, чтобы настройки применились. Перезахода в систему будет недостаточно. Или можно вручную выбрать из списка:
# dpkg-reconfigure localesЧтобы новая локально заработала, нужно перезайти пользователем в терминал. Перезагружаться не обязательно.
———
ServerAdmin:
#linux #terminal
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍100👎5
При работе в терминале Linux иногда возникает потребность записать все вводимые команды и результаты вывода этих команд. Речь идёт не о централизованном способе записи всей активности, а разовой задачи, потому что централизованно эти вещи не всегда настроены. Плюс, там есть разные нюансы в работе, из-за которых что-то может не попадать в вывод.
Приведу примеры централизованной записи команд, о которых я рассказывал ранее:
◽️sshlog - запись вводимых команд и вывода, централизованный сбор логов с записями сессий, уведомления о каких-то событиях в консоли и многое другое.
◽️tlog - централизованная система сбора пользовательской активности в консоли от RedHat.
◽️snoopy - небольшая библиотека под Linux, которая может логировать не только команды пользователей, но многое другое. Например, команды системных процессов.
◽️log-user-session - программа, которая запускается вместо оболочки пользователя и пропускает через себя все его команды, записывая их в текстовый файл.
◽️PROMPT_COMMAND - логирование в текстовый файл с помощью встроенной возможности оболочки bash.
Сегодня речь пойдёт о разовой задаче, когда вы подключились к серверу и хотите сохранить свою работу в консоли. Сделать это очень просто с помощью программы script, которая обычно уже присутствует в системе.
После подключения к серверу запустите её и направьте вывод в лог-файл:
Теперь всё, что вы введёте в консоль, будет записано в файл. Для удобства сразу дату туда добавил. Для того, чтобы прекратить запись, достаточно ввести команду
В лог попадёт некоторый "мусор", который затрудняет восприятие вывода. Это связано с тем, что script записывает сырой поток команд, который включает в себя некоторые закодированные ASCII последовательности, например, описывающие цветной вывод или команды терминала, типа возврата каретки и т.д.
Это всё можно разом очистить. Например, так:
На выходе будет чистый терминал практический такой же, как вы его видели, когда работали.
Простое и быстрое решение для разовой задачи по сохранению своей работы в терминале. Рекомендую сохранить и использовать по мере необходимости.
Я иногда включаю запись терминала средствами SSH клиента, но туда тоже всякий мусор попадает, надо обрабатывать. Плюс, не всегда всю сессию надо записывать. А тут в терминале включил запись, когда не надо, отключил. Потом очистил и всё видно в наглядном представлении без лишнего мусора. Можно вывод какой-то команды или набора команд сохранить и потом спокойно посмотреть.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#linux #terminal #ssh
Приведу примеры централизованной записи команд, о которых я рассказывал ранее:
◽️sshlog - запись вводимых команд и вывода, централизованный сбор логов с записями сессий, уведомления о каких-то событиях в консоли и многое другое.
◽️tlog - централизованная система сбора пользовательской активности в консоли от RedHat.
◽️snoopy - небольшая библиотека под Linux, которая может логировать не только команды пользователей, но многое другое. Например, команды системных процессов.
◽️log-user-session - программа, которая запускается вместо оболочки пользователя и пропускает через себя все его команды, записывая их в текстовый файл.
◽️PROMPT_COMMAND - логирование в текстовый файл с помощью встроенной возможности оболочки bash.
Сегодня речь пойдёт о разовой задаче, когда вы подключились к серверу и хотите сохранить свою работу в консоли. Сделать это очень просто с помощью программы script, которая обычно уже присутствует в системе.
После подключения к серверу запустите её и направьте вывод в лог-файл:
# script -q -f ~/terminal_$(date +%F_%T).logТеперь всё, что вы введёте в консоль, будет записано в файл. Для удобства сразу дату туда добавил. Для того, чтобы прекратить запись, достаточно ввести команду
exit в терминале, и script завершит свою работу.В лог попадёт некоторый "мусор", который затрудняет восприятие вывода. Это связано с тем, что script записывает сырой поток команд, который включает в себя некоторые закодированные ASCII последовательности, например, описывающие цветной вывод или команды терминала, типа возврата каретки и т.д.
Это всё можно разом очистить. Например, так:
# sed -i 's/\x1B\[[0-9;?]*[A-Za-z]//g; s/\x1B\][0-9;]*.*(\x07|\x1B\\)//g;' terminal_2025-10-12_22:42:54.log\x1B\[[0-9;?]*[A-Za-z] - убрали управляющие последовательности (цвета, курсор и bracketed paste);\x1B\][0-9;]*.*(\x07|\x1B\\) - убрали OSC-последовательности ESC ] 0; title ESC \ и некоторые другие;\r - убрали возврат каретки (^M);На выходе будет чистый терминал практический такой же, как вы его видели, когда работали.
Простое и быстрое решение для разовой задачи по сохранению своей работы в терминале. Рекомендую сохранить и использовать по мере необходимости.
Я иногда включаю запись терминала средствами SSH клиента, но туда тоже всякий мусор попадает, надо обрабатывать. Плюс, не всегда всю сессию надо записывать. А тут в терминале включил запись, когда не надо, отключил. Потом очистил и всё видно в наглядном представлении без лишнего мусора. Можно вывод какой-то команды или набора команд сохранить и потом спокойно посмотреть.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#linux #terminal #ssh
Please open Telegram to view this post
VIEW IN TELEGRAM
👍121👎3
Я всегда без исключения в Linux использую swap в виде отдельного файла, а не раздела. Причина очень простая - это намного удобнее. Из глубины веков тянется шлейф убеждений, что отдельный раздел работает быстрее, чем файл. Теоретически - да, практически не понятно.
Во-первых, swap в принципе редко используется интенсивно. Во-вторых, как замерить скорость его работы на реальной нагрузке? В-третьих, разница если и будет, то незначительная. Swap в виде файла позволяет на лету менять свой размер или вовсе его отключать, если экстренно понадобится доступное место. Это весомое преимущество, которое стоит использовать.
Swap в 1 ГБ добавляю так:
Если всё ок, то добавляю в
Отдельно отмечу, что не рекомендуется создавать пустой файл с помощью truncate или fallocate:
Он создастся мгновенно, в отличие от
Если swap уже настроен в виде раздела, то трогать уже не буду, если только это не пустая виртуалка. Иногда попадаются виртуалки с lvm, где swap в виде отдельного lv раздела. Это стандартная схема установки в Debian. В этом случае его можно удалить, объединить с основным, а swap сделать в виде файла.
Все эти операции безопасны и могут быть выполнены без перезагрузки. Но как я уже сказал, на работающих серверах не рекомендую это делать, так как потом корневой раздел надо будет увеличивать. Это потенциально небезопасная операция. Но если сильно прижмёт, то сделать можно. Я так делал и не раз.
Последовательность действий тут такая. Смотрим список разделов:
Небольшая виртуалка с диском на 30 ГБ, где 1,5 отдано под swap. Уберём этот раздел и объединим с основным. Отключаем этот swap:
И сразу же проверьте файл /etc/fstab. Там нужно удалить строку с подключением этого раздела. Выглядит примерно так:
Закомментируйте её. Удаляем раздел со свапом:
Расширяем корневой раздел:
И растягиваем файловую систему на весь раздел, так как увеличение раздела не подразумевает её автоматическое увеличение. Она ничего не знает об увеличенном разделе, если ей об этом не сказать.
Проверяем, что получилось:
Раздел стал 29G против предыдущих 27.5G. Дальше можно добавлять swap в виде файла, как я показал в начале. И обязательно, когда всё закончите, перезагрузите виртуалку и убедитесь, что всё в порядке. Все эти операции не требуют перезагрузки, но если где-то ошиблись, особенно в fstab, можете получить проблемы во время загрузки. По горячим следам это легко исправить, а если reboot случится через полгода и система не загрузится, можно сразу не сообразить, из-за чего это.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#linux #terminal #совет
Во-первых, swap в принципе редко используется интенсивно. Во-вторых, как замерить скорость его работы на реальной нагрузке? В-третьих, разница если и будет, то незначительная. Swap в виде файла позволяет на лету менять свой размер или вовсе его отключать, если экстренно понадобится доступное место. Это весомое преимущество, которое стоит использовать.
Swap в 1 ГБ добавляю так:
# dd if=/dev/zero of=/swap bs=1024 count=1000000# mkswap /swap# chmod 0600 /swap# swapon /swapЕсли всё ок, то добавляю в
/etc/fstab:/swap swap swap defaults 0 0Отдельно отмечу, что не рекомендуется создавать пустой файл с помощью truncate или fallocate:
# truncate -s 1G /swap# fallocate -l 1G /swapОн создастся мгновенно, в отличие от
dd, которая явно пишет туда нули. Не помню, в какой документации читал, но запомнил, что swap лучше нулями сразу записать, а не создавать пустым.Если swap уже настроен в виде раздела, то трогать уже не буду, если только это не пустая виртуалка. Иногда попадаются виртуалки с lvm, где swap в виде отдельного lv раздела. Это стандартная схема установки в Debian. В этом случае его можно удалить, объединить с основным, а swap сделать в виде файла.
Все эти операции безопасны и могут быть выполнены без перезагрузки. Но как я уже сказал, на работающих серверах не рекомендую это делать, так как потом корневой раздел надо будет увеличивать. Это потенциально небезопасная операция. Но если сильно прижмёт, то сделать можно. Я так делал и не раз.
Последовательность действий тут такая. Смотрим список разделов:
# lvsroot web-01-vg -wi-ao---- <27.51g
swap_1 web-01-vg -wi-ao---- <1.54gНебольшая виртуалка с диском на 30 ГБ, где 1,5 отдано под swap. Уберём этот раздел и объединим с основным. Отключаем этот swap:
# swapoff -aИ сразу же проверьте файл /etc/fstab. Там нужно удалить строку с подключением этого раздела. Выглядит примерно так:
/dev/mapper/web--01--vg-swap_1 none swap sw 0 0Закомментируйте её. Удаляем раздел со свапом:
# lvremove /dev/web-01-vg/swap_1Do you really want to remove active logical volume web-01-vg/swap_1? [y/n]: y Logical volume "swap_1" successfully removed.Расширяем корневой раздел:
# lvextend -l +100%FREE /dev/web-01-vg/root Size of logical volume web-01-vg/root changed from <27.51 GiB (7042 extents) to 29.04 GiB (7435 extents). Logical volume web-01-vg/root successfully resized.И растягиваем файловую систему на весь раздел, так как увеличение раздела не подразумевает её автоматическое увеличение. Она ничего не знает об увеличенном разделе, если ей об этом не сказать.
# resize2fs /dev/web-01-vg/rootresize2fs 1.47.2 (1-Jan-2025)Filesystem at /dev/web-01-vg/root is mounted on /; on-line resizing requiredold_desc_blocks = 4, new_desc_blocks = 4The filesystem on /dev/web-01-vg/root is now 7613440 (4k) blocks long.Проверяем, что получилось:
# df -h | grep root/dev/mapper/web--01--vg-root 29G 4.7G 23G 18% /Раздел стал 29G против предыдущих 27.5G. Дальше можно добавлять swap в виде файла, как я показал в начале. И обязательно, когда всё закончите, перезагрузите виртуалку и убедитесь, что всё в порядке. Все эти операции не требуют перезагрузки, но если где-то ошиблись, особенно в fstab, можете получить проблемы во время загрузки. По горячим следам это легко исправить, а если reboot случится через полгода и система не загрузится, можно сразу не сообразить, из-за чего это.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#linux #terminal #совет
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍200👎4
Вчера в статье про обновление Debian 12 до Debian 13 Trixie появился полезный комментарий. Автор указал, что в результате обновления удаляется файл
В Debian 13 вообще по умолчанию убрали
Существует устоявшаяся практика по изменению стандартных конфигурационных файлов. Обычно для внесения своих правок используется специальная директория с названием сервиса и
Если вы хотите внести изменения в sysctl, то просто добавьте отдельный файл в
Например, если хотите добавить форвард пакетов между сетевыми интерфейсами, создайте отдельный файл
После этого примените настройку:
Я всё это, конечно же, знаю, но иногда сознательно так не делаю для своего удобства. Мне нравится, когда вся конфигурация в одном файле. Кому-то это кажется наоборот неудобным. Это моё личное предпочтение, за которое я часто получал критику, если делал все изменения в стандартном конфигурационном файле.
Например, я предпочитаю, когда конфигурация Postfix или Dovecot в одном общем файле, а не раскиданная по нескольким. А в Nginx или Logstash по разным. Там есть логическое разделение по смыслам. В случае Nginx всё очевидно - разные виртуальны хосты, разные файлы конфигураций. В Logstash тоже разные процедуры с данными в разных файлах.
В общем случае вносить изменения стоит в корректирующие файлы конфигурации, а не основные. А как вам удобнее, решайте сами. Просто знайте, что иногда ваш файл может быть перезаписан. Изменения обычно не теряются, так как старый файл сохраняется рядом с другим расширением. Ещё популярные примеры из этой области:
◽️
◽️
◽️
◽️
◽️
◽️
Ну и так далее. Это типичная картина для файлов конфигураций служб в Linux. Скорее будет исключение, если служба будет использовать другой подход к организации конфигурационных файлов.
А вы как предпочитаете хранить конфигурации? Как правильно или как удобно?
#linux
/etc/sysctl.conf, а старый переименовывается на /etc/sysctl.conf.dpkg-bak. Соответственно, все внесённые настройки не применяются. Этого стоит ожидать и понимать, что такое может произойти, хотя на моей памяти ни разу такого не видел с sysctl.conf, потому что я обычно вношу изменения именно в него. В Debian 13 вообще по умолчанию убрали
/etc/sysctl.conf, так как за эти настройки отвечает служба systemd-sysctl, которая хранит свои настройки в /usr/lib/sysctl.d/.Существует устоявшаяся практика по изменению стандартных конфигурационных файлов. Обычно для внесения своих правок используется специальная директория с названием сервиса и
.d на конце. Для примера с sysctl это всегда была директория /etc/sysctl.d, а сейчас /usr/lib/sysctl.d/. Хотя старая вроде бы тоже подгружается в момент загрузки системы.Если вы хотите внести изменения в sysctl, то просто добавьте отдельный файл в
/etc/sysctl.d и внесите свои правки туда. Имя файла при этом чаще всего может быть любым, главное следить за расширением .conf. Обычно на это проверка стоит и к основной конфигурации подключаются только файлы определённого расширения.Например, если хотите добавить форвард пакетов между сетевыми интерфейсами, создайте отдельный файл
/etc/sysctl.d/forward.conf и добавьте туда:net.ipv4.ip_forward = 1После этого примените настройку:
# sysctl -p /etc/sysctl.d/forward.confnet.ipv4.ip_forward = 1Я всё это, конечно же, знаю, но иногда сознательно так не делаю для своего удобства. Мне нравится, когда вся конфигурация в одном файле. Кому-то это кажется наоборот неудобным. Это моё личное предпочтение, за которое я часто получал критику, если делал все изменения в стандартном конфигурационном файле.
Например, я предпочитаю, когда конфигурация Postfix или Dovecot в одном общем файле, а не раскиданная по нескольким. А в Nginx или Logstash по разным. Там есть логическое разделение по смыслам. В случае Nginx всё очевидно - разные виртуальны хосты, разные файлы конфигураций. В Logstash тоже разные процедуры с данными в разных файлах.
В общем случае вносить изменения стоит в корректирующие файлы конфигурации, а не основные. А как вам удобнее, решайте сами. Просто знайте, что иногда ваш файл может быть перезаписан. Изменения обычно не теряются, так как старый файл сохраняется рядом с другим расширением. Ещё популярные примеры из этой области:
◽️
/etc/zabbix/zabbix_agentd.d◽️
/etc/fail2ban/fail2ban.d◽️
/etc/dovecot/conf.d◽️
/etc/sudoers.d◽️
/etc/mysql/mariadb.conf.d◽️
/etc/logstash/conf.dНу и так далее. Это типичная картина для файлов конфигураций служб в Linux. Скорее будет исключение, если служба будет использовать другой подход к организации конфигурационных файлов.
А вы как предпочитаете хранить конфигурации? Как правильно или как удобно?
#linux
👍109👎2
На прошлой неделе просматривал видео некоторых блогеров. У кого-то заметил экран приветствия на сервере после подключения по SSH. Сразу не записал, у кого увидел, вроде у Realmanual, но не уверен. Потом уже не нашёл. Но не суть.
Я всегда знал, что приветствие можно настроить, но особо не заморачивался. Максимум, что настраивал при подключении, запуск команды
А тут увидел приветствие, которое мне понравилось. Я полный вывод не запоминал, только оставил себе пометку подумать, что было бы полезно увидеть мне. В итоге сделал себе и сохранил для использования такое приветствие:
Пояснять тут особо нечего. Отмечу только, что в качестве IP взял настройку самого первого не
Настроить это очень просто. Любой ИИ вам соберёт по запросу подходящий bash скрипт, который нужно будет положить
Заодно удалил строку:
Она находится в файле
Закомментировал её. Получил приветствие, как на картинке снизу. Мне понравилась. На свои сервера буду добавлять.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#linux
Я всегда знал, что приветствие можно настроить, но особо не заморачивался. Максимум, что настраивал при подключении, запуск команды
w, чтобы увидеть главным образом активные сессии и понимать, что ты не один на сервере. Иногда это работало как хорошая пугалка, если у тебя осталась висеть твоя же сессия, только с какого-то непривычного IP.А тут увидел приветствие, которое мне понравилось. Я полный вывод не запоминал, только оставил себе пометку подумать, что было бы полезно увидеть мне. В итоге сделал себе и сохранил для использования такое приветствие:
-----------------------------------------IP : 95.183.13.208Hostname : serveradmin.ruOS : Debian GNU/Linux 12 (bookworm)USER : rootLoad Average : 0.08 0.06 0.04Uptime : up 1 week, 6 hours, 32 minutes-----------------------------------------CPU : 2 CPURAM : 3915 MB, 1055 MB (26%) freeHDD (/) : 60G, 36G (60%) free-----------------------------------------Пояснять тут особо нечего. Отмечу только, что в качестве IP взял настройку самого первого не
lo интерфейса. У меня это практически всегда основной IP адрес, который я хочу видеть. А пользователя root подкрашиваю в красный цвет.Настроить это очень просто. Любой ИИ вам соберёт по запросу подходящий bash скрипт, который нужно будет положить
/etc/profile.d. Потом можно его подправить по своему вкусу. Я в итоге оставил такой:#!/bin/bash
# Цвета
RED='\033[0;31m'
NC='\033[0m' # No Color
# IP первого сетевого интерфейса
LOCAL_IP=$(ip -4 addr show | grep -oP '(?<=inet\s)\d+\.\d+\.\d+\.\d+' | grep -v '^127\.' | head -n 1)
# Имя сервера
HOSTNAME=$(hostname)
# ОС
OS=$(grep PRETTY_NAME /etc/os-release | cut -d= -f2 | tr -d '"')
# Пользователь
USER_NAME=$(whoami)
# Root красным
if [ "$USER_NAME" = "root" ]; then
USER_NAME="${RED}${USER_NAME}${NC}"
fi
# Load average
LOADAVG=$(awk '{print $1" "$2" "$3}' /proc/loadavg)
# Uptime
UPTIME=$(uptime -p)
# Количество CPU
CPU_COUNT=$(nproc)
# RAM: всего и свободно (в мегабайтах)
RAM_TOTAL=$(free -m | awk '/Mem:/ {print $2}')
RAM_FREE=$(free -m | awk '/Mem:/ {print $7}')
RAM_FREE_PCT=$(( RAM_FREE * 100 / RAM_TOTAL ))
# HDD: для корневого раздела /
DISK_TOTAL_HUMAN=$(df -h / | awk 'NR==2 {print $2}')
DISK_FREE_HUMAN=$(df -h / | awk 'NR==2 {print $4}')
# Используем df без форматирования для процентов
DISK_TOTAL=$(df -k / | awk 'NR==2 {print $2}')
DISK_FREE=$(df -k / | awk 'NR==2 {print $4}')
DISK_FREE_PCT=$(( DISK_FREE * 100 / DISK_TOTAL ))
echo ""
echo "-----------------------------------------"
echo "IP : ${LOCAL_IP:-N/A}"
echo "Hostname : $HOSTNAME"
echo "OS : $OS"
echo -e "USER : $USER_NAME"
echo "Load Average : $LOADAVG"
echo "Uptime : $UPTIME"
echo "-----------------------------------------"
echo "CPU : ${CPU_COUNT} CPU"
echo "RAM : ${RAM_TOTAL} MB, ${RAM_FREE} MB (${RAM_FREE_PCT}%) free"
echo "HDD (/) : ${DISK_TOTAL_HUMAN}, ${DISK_FREE_HUMAN} (${DISK_FREE_PCT}%) free"
echo "-----------------------------------------"
echo ""
Заодно удалил строку:
The programs included with the Debian GNU/Linux system are free software;the exact distribution terms for each program are described in theindividual files in /usr/share/doc/*/copyright.Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extentpermitted by applicable law.Она находится в файле
/etc/motd и подключается в /etc/pam.d/sshd в строке:session optional pam_motd.so noupdateЗакомментировал её. Получил приветствие, как на картинке снизу. Мне понравилась. На свои сервера буду добавлять.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#linux
Please open Telegram to view this post
VIEW IN TELEGRAM
9👍291👎2
Вчера написал заметку про настройку приветствия при подключении к серверу. В комментариях автор, у которого я вдохновился идеей, подкинул ещё одну очень удобную фишку по решению небольшой проблемы. Причём именно той, о которой я много раз думал, что неплохо бы как-то это решить, но даже не представлял как.
У меня в виртуалках и контейнерах Proxmox чаще всего IP адреса назначаются автоматически через DHCP. Иногда хочется быстро посмотреть IP адрес контейнера или виртуалки через веб интерфейс, особенно если он по какой-то причине изменился или не был жёстко привязан по MAC или Machine-ID.
Для VM это чаще всего решается быстро, так как я всегда устанавливаю QEMU Guest Agent. С его помощью IP адрес выводится на основную вкладку Summary виртуальной машины. А вот с контейнерами это так не работает. Приходится либо в него заходить через консоль, либо смотреть на DHCP сервере.
Этот вопрос можно решить с помощью файла
Чаще всего сетевой интерфейс контейнера имеет имя
Очень просто и удобно. Файл
Для виртуалок это тоже можно использовать, но там есть проблема. Сетевые интерфейсы могут называться сильно по-разному: ens18, enp0s18 и т.д. Если вы принудительно не приводили их к старому наименованию в виде ethX, то придётся для каждого случая прописывать имя сетевого интерфейса.
ИИ написал, что можно указать конструкцию вида
If the interface argument is not specified, then select the first fully configured (UP, non-LOCALBACK, RUNNING) interface. If no configured interface is found, fall back to the IP address of the machine’s hostname.
То есть указываем просто
Очень удобная весчь. Мне понравилось. Реально не хватало в повседневной работе.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#linux
У меня в виртуалках и контейнерах Proxmox чаще всего IP адреса назначаются автоматически через DHCP. Иногда хочется быстро посмотреть IP адрес контейнера или виртуалки через веб интерфейс, особенно если он по какой-то причине изменился или не был жёстко привязан по MAC или Machine-ID.
Для VM это чаще всего решается быстро, так как я всегда устанавливаю QEMU Guest Agent. С его помощью IP адрес выводится на основную вкладку Summary виртуальной машины. А вот с контейнерами это так не работает. Приходится либо в него заходить через консоль, либо смотреть на DHCP сервере.
Этот вопрос можно решить с помощью файла
/etc/issue. Вообще не знал до сего дня для чего он существует и какие открывает возможности. Добавляем туда в LXC контейнере:eth0: \4{eth0}Чаще всего сетевой интерфейс контейнера имеет имя
eth0. Теперь открыв консоль контейнера через веб интерфейсе Proxmox, вы увидите его текущий IP адрес:Debian GNU/Linux 12 Debian12-ct tty1eth0: 192.168.137.29Debian12-ct login:Очень просто и удобно. Файл
/etc/issue в Linux - это шаблон приветственного сообщения (pre-login banner), который выводится до появления приглашения login: на локальной консоли (tty). Важно понимать, что подключения по SSH не используют /etc/issue. Это шаблон только для локальных консолей.Для виртуалок это тоже можно использовать, но там есть проблема. Сетевые интерфейсы могут называться сильно по-разному: ens18, enp0s18 и т.д. Если вы принудительно не приводили их к старому наименованию в виде ethX, то придётся для каждого случая прописывать имя сетевого интерфейса.
ИИ написал, что можно указать конструкцию вида
\4{all} для вывода всех IP адресов, но в Debian 13 это не работает. Не знаю, откуда он это взял. Я воспользовался старорежимным дедовским методом и прочитал man:# man agettyIf the interface argument is not specified, then select the first fully configured (UP, non-LOCALBACK, RUNNING) interface. If no configured interface is found, fall back to the IP address of the machine’s hostname.
То есть указываем просто
\4 или для красоты IP: \4 и получаем приветствие с IP адресом, который будет взят с первого активного сетевого интерфейса, но не lo. В принципе, этот вариант можно использовать как универсальный и для VM, и для контейнеров.Очень удобная весчь. Мне понравилось. Реально не хватало в повседневной работе.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#linux
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
5👍155👎3
Предлагаю вашему вниманию один проект, который мне прислал подписчик, он же, соответственно, и автор. С его помощью можно отправлять результаты работы команды, выполненной на сервере, в Telegram. То есть это лёгкая CLI обёртка, через которую запускается команда, например, по cron или вручную, а результат её работы в виде времени выполнения, кода выхода и самого вывода будет отправляться в Telegram.
Программа называется tg_exec. В репозитории в том числе описание на русском языке. Мне показалась эта штука удобной, так что решил написать. На первый взгляд всё это видится чем-то подозрительным и небезопасным. Я бегло глянул код на go. Там немного и читается легко. На первый взгляд чего-то необычного там нет. Перехватывается вывод команды и отправляется в телегу. Можно и самому такое наколхозить, но тут всё уже аккуратно собрано в пакет, с конфигурацией, переменными, красивым выводом.
Для того, чтобы пользоваться, делаем так:
1️⃣ Устанавливаем пакет, забрав его из репозитория.
2️⃣ Добавляем в конфигурационный файл
Я проверял и через прямую отправку себе, и через отправку в группу. Нормально работает.
3️⃣ Запускаем любую команду через tg-exec. На первый раз можно в режиме debug:
Как это выглядит в Telegram можно посмотреть на картинке снизу. Всё аккуратно и наглядно.
В tg-exec можно обернуть команды в кроне, чтобы следить за их выполнением. Можно использовать для каких-то длительных сборок, чтобы узнать, когда она закончится, или где-то в пайплайнах. Тут уже сами смотрите, где может пригодиться.
☝️Когда тестировал, столкнулся с тем, что уведомления не отправлялись. Вылезала ошибка с таймаутом. Оказалось, что сервер пытался по ipv6 достучаться до api.telegram.org и у него это не получалось. Отключил ipv6 и всё заработало. Это ещё один пример, когда работающий ipv6 доставляет проблемы. Я уже как-то делал заметку по этому поводу и там были бурные обсуждения. Но по факту в РФ пока нужды в ipv6 нет. С этим протоколом только лишние проблемы и хлопоты.
На мой взгляд простая, понятная и удобная утилита. Можно пользоваться. Думаю, автор тут ответит, если у кого-то будут вопросы или пожелания по программе. Я даже не знаю, что тут можно улучшить или добавить. Свою задачу она нормально выполняет.
Не забудьте наставить звёздочек в репозиторий. Автор постарался, красиво всё оформил, описал, пакет собрал, мне написал.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#linux #terminal
Программа называется tg_exec. В репозитории в том числе описание на русском языке. Мне показалась эта штука удобной, так что решил написать. На первый взгляд всё это видится чем-то подозрительным и небезопасным. Я бегло глянул код на go. Там немного и читается легко. На первый взгляд чего-то необычного там нет. Перехватывается вывод команды и отправляется в телегу. Можно и самому такое наколхозить, но тут всё уже аккуратно собрано в пакет, с конфигурацией, переменными, красивым выводом.
Для того, чтобы пользоваться, делаем так:
# wget https://github.com/WithoutCowards/tg_exec/releases/download/1.0.3/tg-exec_1.0.3_amd64.deb# dpkg -i tg-exec_*_amd64.deb/etc/tg-exec/config.conf токен бота и свой ID. Для тех, кто совсем не знает, что это такое, поясню. Бота создаём через телеграмовского бота @BotFather, а свой ID или ID чата, куда будет добавлен этот бот, узнаём через бота @my_id_bot.Я проверял и через прямую отправку себе, и через отправку в группу. Нормально работает.
# DEBUG=1 tg-exec "apt update"# DEBUG=1 tg-exec "df -h"Как это выглядит в Telegram можно посмотреть на картинке снизу. Всё аккуратно и наглядно.
В tg-exec можно обернуть команды в кроне, чтобы следить за их выполнением. Можно использовать для каких-то длительных сборок, чтобы узнать, когда она закончится, или где-то в пайплайнах. Тут уже сами смотрите, где может пригодиться.
☝️Когда тестировал, столкнулся с тем, что уведомления не отправлялись. Вылезала ошибка с таймаутом. Оказалось, что сервер пытался по ipv6 достучаться до api.telegram.org и у него это не получалось. Отключил ipv6 и всё заработало. Это ещё один пример, когда работающий ipv6 доставляет проблемы. Я уже как-то делал заметку по этому поводу и там были бурные обсуждения. Но по факту в РФ пока нужды в ipv6 нет. С этим протоколом только лишние проблемы и хлопоты.
На мой взгляд простая, понятная и удобная утилита. Можно пользоваться. Думаю, автор тут ответит, если у кого-то будут вопросы или пожелания по программе. Я даже не знаю, что тут можно улучшить или добавить. Свою задачу она нормально выполняет.
Не забудьте наставить звёздочек в репозиторий. Автор постарался, красиво всё оформил, описал, пакет собрал, мне написал.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#linux #terminal
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍129👎1