ServerAdmin.ru
31.6K subscribers
851 photos
57 videos
23 files
3K links
Авторская информация о системном администрировании.

Информация о рекламе: @srv_admin_reklama_bot
Автор: @zeroxzed

Второй канал: @srv_admin_live
Сайт: serveradmin.ru

Ресурс включён в перечень Роскомнадзора
Download Telegram
В свете недавних обсуждений гипервизоров вспомнил, как я начинал изучение KVM. До него работал с Xen и Hyper-V. Первым делом стал разбирать вопрос бэкапа виртуальных машин наживую, без их остановки. Это было более 10-ти лет назад и простых решений не существовало. Proxmox не помню, был уже тогда или нет, но я про него не знал. Использовал всё это в консоли с помощью virsh, и в GUI с помощью virt-manager.

Я изучил вопрос и разобрался, как делать снепшоты при использовании файлов 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 deleted
lrwx------ 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
5👍154👎4
Коротенькая, но мне кажется полезная заметка на тему одного небольшого сервиса, который поможет тем, кто пишет свои bash скрипты. Речь пойдёт вот про этот сервис:

https://www.strfti.me

С его помощью можно быстро подобрать формат даты для консольной утилиты date. Я её почти всегда использую в скриптах, чтобы зафиксировать дату, например, в имени файла или директории. Даже если на канале пройтись по моим скриптам, в каждом втором, если не первом она будет.

Например, почти всегда для имени файла с бэкапом использую конструкцию date +"%Y-%m-%d_%H-%M-%S", что запишет дату в виде 2025-08-24_17-52-06. Удобно и для быстрой сортировки по имени, и для визуального восприятия. Если кто-то не понял, о чём идёт речь, то вот простой пример готовой команды с использованием date:

/usr/bin/pg_dump -U postgres db01 | pigz > /var/lib/pgpro/backup/`date +"%Y-%m-%d_%H-%M"`-db01.sql.gz

Получим файл с дампом базы данных 2025-08-24_17-52-06-db01.sql.gz.

Я подобные вещи проверяю сразу в консоли, а наиболее популярные форматы у меня просто в шпаргалке записаны. На сайте можно быстро получить код для любого формата и там же описание всех параметров, чтобы подобрать свой. Быстро и удобно. Быстрее, чем где-то искать или читать man.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#bash #terminal
1👍148👎2
Вспомнил про одну необычную утилиту из мира консоли Linux. Сначала даже не был уверен, что не писал о ней ранее. Оказалось, что реально не писал, только пару упоминаний мельком сделал. Речь пойдёт о faketime. Вспомнил, когда скрипты пересматривал к утренней публикации. Искал что-то для примера в прикреплённой картинке.

Во время отладки скриптов или мониторинга иногда нужно подставить какое-то другое системное время. Можно менять время непосредственно в тестовой системе, а можно воспользоваться faketime. Причём сделать это очень просто, потому что утилита с незапамятных времён живёт в базовых репах:

# apt install faketime

Приложение скомпилировано на базе библиотеки libfaketime. Оно перехватывает системные вызовы для приложения и заменяет в них время на указанное. Работает примерно так:

# faketime '2025-12-31 23:59:59' date
Wed 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.tar

Faketime позволяет проверить работу своих скриптов, заглянув в будущее.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#linux #terminal
2👍167👎3
Я делал заметку про небольшой набор полезных для меня алиасов в консоли bash, которые я использую в повседневной работе в WLS2 на базе Ubuntu в своей рабочей Windows 11. Также я отдельно и подробно описывал один из них, который выводит информацию об IP адресах.

Мой набор пополнился ещё одним скриптом, которым хотел бы с вами поделиться. У меня он работает вот так:

$ 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
👍56👎1
Относительно недавно (2018 год) по меркам Linux в составе базовых системных утилит популярных дистрибутивов появилась утилита choom. Узнал о ней случайно. В Debian и Ubuntu она есть по умолчанию, отдельно ставить не надо. В других не проверял.

Забегая вперёд скажу, что лично я для неё применения не увидел, но решил всё равно написать для общего образования. Кому-то может пригодится. Не просто же так её написали и добавили в дистрибутивы. С помощью choom можно управлять таким параметром, как OOM score adjustment (oom_score_adj). На его основе OOM-killer принимает решение о том, какой процесс завершить при нехватке оперативной памяти в системе.

Choom работает с запущенными процессами на лету, используя их pid. Примерно так:

# choom -p 1994
pid 1994's current OOM score: 684
pid 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 1994
pid 1994's current OOM score: 0
pid 1994's current OOM score adjust value: -1000

Oom_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: 152
pid 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👍84👎1
В недавнем опросе про консольные редакторы было много упоминаний редактора micro. Никогда не пробовал и не работал в нём. Решил исправить. И вы знаете, он меня реально впечатлил. В нём удобно работать. Удобнее, чем во всех других, с которыми приходилось сталкиваться. Расскажу про основные моменты, на которые обратил внимание.

1️⃣ Установка. Тут всё просто. Micro есть в базовых репозиториях дистрибутивов, так что можно сделать так:

# apt install micro

Я хотел получить самую свежую версию, поэтому сделал вот так:

# curl https://getmic.ro | bash
# mv micro /usr/bin/micro

По сути это просто одиночный бинарник на Go. Можно скачать из репозитория.

2️⃣ Делаем micro редактором по умолчанию:

# update-alternatives --install /usr/bin/editor editor /usr/bin/micro 50
# update-alternatives --set editor /usr/bin/micro

Для того, чтобы в Midnight Commander (mc) он тоже выступал в качестве редактора, надо добавить в ~/.bashrc пару переменных:

export EDITOR=micro
export 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👍168👎4
Когда надо узнать скорость сетевого интерфейса в Linux, первое, что приходит на ум - ethtool. Это самая популярная утилита для просмотра и управления настройками сетевых адаптеров. С ней только одна проблема - в базовом наборе системных утилит её обычно нет. Надо ставить отдельно:

# apt install ethtool

Для разовых задач особого смысла в этом нет, потому что все подобные утилиты берут информацию у ядра. Нет никаких проблем самим её посмотреть. Проверяем имена своих сетевых интерфейсов:

# ip a

И смотрим скорость:

# cat /sys/class/net/enp4s0/speed
1000

В данном случае это скорость 1000Mb/s или 1Gb/s. Если у вас виртуальная машина, то в зависимости от типа эмуляции, вы можете получить неожиданные значения:

# cat /sys/class/net/ens18/speed
-1

В данном случае -1 - это отсутствие какого-либо значения, нет данных. Это характерно для виртуальных машин в KVM. Virtio-драйвер не сообщает реальную физическую скорость (у него её просто нет) даже если он в бридже с реальной сетевой картой. А вот драйвер в Hyper-V сообщает:

# cat /sys/class/net/eth0/speed
1000

Это скорость сетевой карты, которая в бридже с виртуальным коммутатором для виртуальных машин.

☝️Кстати, если хотите быстро узнать, в виртуалке вы или на железе, запустите:

# hostnamectl

Я всегда использую эту команду для таких задач.

Помимо скорости интерфейса, ядро может передать всю остальную информацию. Например, наличие линка, параметры дуплекса, mtu или mac адрес:

# cat /sys/class/net/enp4s0/carrier
1
# cat /sys/class/net/enp4s0/duplex
full
# cat /sys/class/net/enp4s0/mtu
1500
# cat /sys/class/net/enp4s0/address
00:25:22:dc:39:42

Можете зайти в директорию /sys/class/net/enp4s0/ и посмотреть всё, что там есть.

Таким образом можно посмотреть всё, что угодно из того, что показывают системные утилиты. Просто некоторые значения нужно преобразовывать. Например, открытые TCP порты:

# cat /proc/net/tcp

Номера портов будут в шестнадцатеричном формате. Подобным образом у ядра можно выведать массу информации. Примерно этим и занимаются многочисленные клоны *top-ов и им подобных утилит. Вы и сами что-то подобное можете написать под свои задачи относительно просто, особенно с помощью ИИ.

#linux #terminal
👍102👎2
На днях зашёл в свежеустановленную из шаблона систему Rocky Linux 9 и с удивлением увидел неработающую. команду:

# clear
-bash: clear: command not found

Первый раз с таким столкнулся. Почему-то был уверен, что это либо системная утилита, либо часть оболочки bash. Не припоминаю, чтобы я отдельно её ставил.

Эта команда полностью очищает терминал и возвращает курсор на самую первую строку. Я постоянно её использую в процессе работы в консоли. Регулярно по привычке набираю её в терминале Windows и расстраиваюсь, что она не работает. Начинаю вспоминать, как она выглядит в винде. Даю подсказку - cls.

Оказывается, эта утилита живёт в пакете ncurses. В Debian и Ubuntu никогда этот пакет не ставил. Утилита clear там была во всех редакциях и шаблонах, с которыми мне приходилось работать. А вот в Rocky пришлось поставить:

# dnf install ncurses

Так что если не знали, про clear, то рекомендую посмотреть и пользоваться. Удобная утилита. Ну а если потеряли, то знайте, что живёт она в отдельном пакете.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#linux #terminal
Please open Telegram to view this post
VIEW IN TELEGRAM
👍101👎3
Столкнулся на днях с ошибкой, которую уже давно не видел. Минут 10 потратил, пока не понял, в чём проблема. Давно работает один LXC контейнер с Debian внутри. У меня давняя привычка везде и всюду использовать названия только на английском языке и никогда не ставить пробелы, заменяя их тире или подчёркиванием. И вам того же советую во избежание траты времени на поиск внезапных ошибок или проблем с отладкой.

Закинул туда скрипт с комментариями на русском языке, которые иногда оставляю в начале. Вместо русских букв местами получил крякозябры. Первое, на что посмотрел - кодировка исходного текста. На всякий случай сохранил его в VSCode, убедился, что там UTF-8 и скопировал ещё раз. Не помогло.

Подумал, может это в mcedit проблема. Открыл скрипт в nano - там то же самое. На всякий случай скопировал по scp этот же скрипт, чтобы исключить проблемы, связанные с буфером обмена. То же самое. Копирую на другой сервер, там всё нормально.

Дальше понял, что надо локали в терминале смотреть:

# locale
LANG=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: 📱 Telegram | 🌐 Сайт | 📲 MAX

#linux #terminal
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍101👎5
При работе в терминале Linux иногда возникает потребность записать все вводимые команды и результаты вывода этих команд. Речь идёт не о централизованном способе записи всей активности, а разовой задачи, потому что централизованно эти вещи не всегда настроены. Плюс, там есть разные нюансы в работе, из-за которых что-то может не попадать в вывод.

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

◽️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: 📱 Telegram | 🌐 Сайт | 📲 MAX

#linux #terminal #ssh
Please open Telegram to view this post
VIEW IN TELEGRAM
👍122👎3
Я всегда без исключения в Linux использую swap в виде отдельного файла, а не раздела. Причина очень простая - это намного удобнее. Из глубины веков тянется шлейф убеждений, что отдельный раздел работает быстрее, чем файл. Теоретически - да, практически не понятно.

Во-первых, 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 сделать в виде файла.

Все эти операции безопасны и могут быть выполнены без перезагрузки. Но как я уже сказал, на работающих серверах не рекомендую это делать, так как потом корневой раздел надо будет увеличивать. Это потенциально небезопасная операция. Но если сильно прижмёт, то сделать можно. Я так делал и не раз.

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

# lvs
root   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_1
Do 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/root
resize2fs 1.47.2 (1-Jan-2025)
Filesystem at /dev/web-01-vg/root is mounted on /; on-line resizing required
old_desc_blocks = 4, new_desc_blocks = 4
The 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: 📱 Telegram | 🌐 Сайт | 📲 MAX

#linux #terminal #совет
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍200👎4
Предлагаю вашему вниманию один проект, который мне прислал подписчик, он же, соответственно, и автор. С его помощью можно отправлять результаты работы команды, выполненной на сервере, в Telegram. То есть это лёгкая CLI обёртка, через которую запускается команда, например, по cron или вручную, а результат её работы в виде времени выполнения, кода выхода и самого вывода будет отправляться в Telegram.

Программа называется tg_exec. В репозитории в том числе описание на русском языке. Мне показалась эта штука удобной, так что решил написать. На первый взгляд всё это видится чем-то подозрительным и небезопасным. Я бегло глянул код на go. Там немного и читается легко. На первый взгляд чего-то необычного там нет. Перехватывается вывод команды и отправляется в телегу. Можно и самому такое наколхозить, но тут всё уже аккуратно собрано в пакет, с конфигурацией, переменными, красивым выводом.

Для того, чтобы пользоваться, делаем так:

1️⃣ Устанавливаем пакет, забрав его из репозитория.

# 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

2️⃣ Добавляем в конфигурационный файл /etc/tg-exec/config.conf токен бота и свой ID. Для тех, кто совсем не знает, что это такое, поясню. Бота создаём через телеграмовского бота @BotFather, а свой ID или ID чата, куда будет добавлен этот бот, узнаём через бота @my_id_bot.

Я проверял и через прямую отправку себе, и через отправку в группу. Нормально работает.

3️⃣ Запускаем любую команду через tg-exec. На первый раз можно в режиме debug:

# DEBUG=1 tg-exec "apt update"
# DEBUG=1 tg-exec "df -h"

Как это выглядит в Telegram можно посмотреть на картинке снизу. Всё аккуратно и наглядно.

В tg-exec можно обернуть команды в кроне, чтобы следить за их выполнением. Можно использовать для каких-то длительных сборок, чтобы узнать, когда она закончится, или где-то в пайплайнах. Тут уже сами смотрите, где может пригодиться.

☝️Когда тестировал, столкнулся с тем, что уведомления не отправлялись. Вылезала ошибка с таймаутом. Оказалось, что сервер пытался по ipv6 достучаться до api.telegram.org и у него это не получалось. Отключил ipv6 и всё заработало. Это ещё один пример, когда работающий ipv6 доставляет проблемы. Я уже как-то делал заметку по этому поводу и там были бурные обсуждения. Но по факту в РФ пока нужды в ipv6 нет. С этим протоколом только лишние проблемы и хлопоты.

На мой взгляд простая, понятная и удобная утилита. Можно пользоваться. Думаю, автор тут ответит, если у кого-то будут вопросы или пожелания по программе. Я даже не знаю, что тут можно улучшить или добавить. Свою задачу она нормально выполняет.

Не забудьте наставить звёздочек в репозиторий. Автор постарался, красиво всё оформил, описал, пакет собрал, мне написал.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#linux #terminal
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍156👎1
Я вчера рассказывал про программу, которая позволяет отправлять в Telegram отчёты о выполнении какой-то команды. Сразу возникло желание получить какой-то инструмент и для обратной связи - выполнять на сервере команду, которая вводится в чате в Telegram.

На эту тему очень много решений, как очень простых в виде небольшого python скрипта, так и более развитых проектов на github. Я попробовал и первое, и второе. Расскажу про то, что понравилось больше всего - shell2telegram.

Сразу отмечу, чем понравился:

Есть deb и rpm пакеты, а так же присутствует в репозитории snap. Сам по себе это один бинарник на go. В пакет упакован для удобства вместе с man.
Есть возможность ограничить набор доступных команд.
Для выполнения команд можно настроить авторизацию.
Есть встроенная статистика и некоторое управление в боте.

Показываю, как пользоваться:

1️⃣ Скачиваем и устанавливаем пакет:
# wget https://github.com/msoap/shell2telegram/releases/download/v1.10.0/shell2telegram_1.10.0_linux_amd64.deb
# dpkg -i shell2telegram_1.10.0_linux_amd64.deb

2️⃣ Записываем в переменную окружения токен бота:
# export TB_TOKEN=55555555:AAAAAAAAAAAAA

3️⃣ Запускаем с парой доступных команд:
# shell2telegram /topcpu:desc="Top CPU Procs" 'ps -e -o pcpu,pmem,args --sort -pcpu | head -10' \
/topmem:desc="Top MEM Procs" 'ps -e -o pcpu,pmem,args --sort -pmem | head -10'

Команда /topcpu выводит 10 лидеров среди процессов по CPU, /topmem - по памяти.

4️⃣ Идём в бота и проходим авторизацию для запуска команд от root:
/authroot
Идём в консоль сервера, видим там код для авторизации. Вводим его боту:
/authroot ZJНрhiRGB1NLbkLD5VyS
Получил сообщение:
You (Vladimir Zp (@zeroxzed)) authorized as root.

5️⃣  Вводим боту команды и смотрим вывод со списком процессов:
/topcpu
/topmem

С помощью ключей -allow-users= и -root-users= можно сразу перечислить пользователей с доступом к боту, чтобы не нужно было использовать коды:

# shell2telegram -root-users="zeroxzed" \
/topcpu:desc="Top CPU Procs" 'ps -e -o pcpu,pmem,args --sort -pcpu | head -10' \
/topmem:desc="Top MEM Procs" 'ps -e -o pcpu,pmem,args --sort -pmem | head -10'

Можно посмотреть статистику выполнения команд, отправив боту:

/shell2telegram stat

Или погасить его прямо из Telegram:

/shell2telegram exit

Все доступные команды описаны в репозитории или в man.

Можно много всего накостылить с её помощью. Я обернул в systemd, чтобы работала как служба. Для этого создал файл /etc/systemd/system/shell2telegram.service. Закинул туда:

[Unit]
Description=Shell2Telegram bot
After=network.target

[Service]
Type=simple
Environment=TB_TOKEN=55555555:AAAAAAAAAAAAAA
ExecStart=/usr/bin/shell2telegram -root-users="zeroxzed" \
  /topcpu:desc="Top CPU Procs" 'ps -e -o pcpu,pmem,args --sort -pcpu | head -10' \
  /topmem:desc="Top MEM Procs" 'ps -e -o pcpu,pmem,args --sort -pmem | head -10'

Restart=on-failure
RestartSec=5
User=root
WorkingDirectory=/root

[Install]
WantedBy=multi-user.target


И запустил:

# systemctl daemon-reload
# systemctl enable --now shell2telegram.service

Интересная и функциональная штука. Можно, например, добавлять и удалять правила файрвола. К примеру, разрешим подключаться к SSH. В консоли это выглядит так:

# iptables -A INPUT -i ens18 -s 192.168.13.5 -p tcp --dport 22 -j ACCEPT

Нам надо обернуть эту команду в Shell2Telegram. Бот принимает аргумент после команды как STDIN в консольную команду. В Iptables STDIN можно передать через простой скрипт-прокладку. Создаём исполняемый скрипт addip.sh:

#!/bin/bash
read ip
iptables -A INPUT -i ens18 -s "$ip" -p tcp --dport 22 -j ACCEPT


Запускаем:

# shell2telegram /addip:desc="Add IP to Iptables" '~/addip.sh'

Выполняем в боте:

/addip 1.2.3.4

Проверяем в консоли:

# iptables -L -v -n | grep 22
 0   0 ACCEPT   tcp -- ens18 *    1.2.3.4       0.0.0.0/0      tcp dpt:22

Так можно много всего придумать. Если у вас есть идеи, для чего это может пригодиться, делитесь.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#linux #terminal
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍57👎4