ServerAdmin.ru
32.3K subscribers
1.17K photos
72 videos
29 files
3.18K links
Авторская информация о системном администрировании.

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

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

Ресурс включён в перечень Роскомнадзора
Download Telegram
На прошлой неделе просматривал видео некоторых блогеров. У кого-то заметил экран приветствия на сервере после подключения по SSH. Сразу не записал, у кого увидел, вроде у Realmanual, но не уверен. Потом уже не нашёл. Но не суть.

Я всегда знал, что приветствие можно настроить, но особо не заморачивался. Максимум, что настраивал при подключении, запуск команды w, чтобы увидеть главным образом активные сессии и понимать, что ты не один на сервере. Иногда это работало как хорошая пугалка, если у тебя осталась висеть твоя же сессия, только с какого-то непривычного IP.

А тут увидел приветствие, которое мне понравилось. Я полный вывод не запоминал, только оставил себе пометку подумать, что было бы полезно увидеть мне. В итоге сделал себе и сохранил для использования такое приветствие:

-----------------------------------------
IP           : 95.183.13.208
Hostname       : serveradmin.ru
OS           : Debian GNU/Linux 12 (bookworm)
USER          : root
Load Average   : 0.08 0.06 0.04
Uptime         : up 1 week, 6 hours, 32 minutes
-----------------------------------------
CPU           : 2 CPU
RAM           : 3915 MB, 1055 MB (26%) free
HDD (/)        : 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 the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

Она находится в файле /etc/motd и подключается в /etc/pam.d/sshd в строке:

session  optional   pam_motd.so noupdate

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

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

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

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

У меня в виртуалках и контейнерах 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 tty1
eth0: 192.168.137.29
Debian12-ct login:

Очень просто и удобно. Файл /etc/issue в Linux - это шаблон приветственного сообщения (pre-login banner), который выводится до появления приглашения login: на локальной консоли (tty). Важно понимать, что подключения по SSH не используют /etc/issue. Это шаблон только для локальных консолей.

Для виртуалок это тоже можно использовать, но там есть проблема. Сетевые интерфейсы могут называться сильно по-разному: ens18, enp0s18 и т.д. Если вы принудительно не приводили их к старому наименованию в виде ethX, то придётся для каждого случая прописывать имя сетевого интерфейса.

ИИ написал, что можно указать конструкцию вида \4{all} для вывода всех IP адресов, но в Debian 13 это не работает. Не знаю, откуда он это взял. Я воспользовался старорежимным дедовским методом и прочитал man:

# man agetty

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.

То есть указываем просто \4 или для красоты IP: \4 и получаем приветствие с IP адресом, который будет взят с первого активного сетевого интерфейса, но не lo. В принципе, этот вариант можно использовать как универсальный и для VM, и для контейнеров.

Очень удобная весчь. Мне понравилось. Реально не хватало в повседневной работе.

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

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

#linux
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
5👍172👎3
Предлагаю вашему вниманию один проект, который мне прислал подписчик, он же, соответственно, и автор. С его помощью можно отправлять результаты работы команды, выполненной на сервере, в 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
3👍187👎2
Я вчера рассказывал про программу, которая позволяет отправлять в 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
👍116👎9
Для анализа занятого места на дисках в Linux есть встроенная утилита du. Если к ней приловчиться и запомнить некоторые ключи, то больше ничего и не нужно. Например, заходим в директорию и вводим:

# du -hd1 | sort -hr

Получаем отсортированный список всех директорий с размером в порядке убывания. Просто и удобно.

Вот ещё один вариант, который иногда использую. Простой скрипт, который проверяет размер директорий и записывает результат тут же в файл:

#!/bin/bash
{
 echo "=================================="
 echo "Dirs size $(date +"%Y-%m-%d_%H-%M")"
 echo "=================================="
} >> dirs_size.txt
du -s -- * | sort -nr | cut -f 2- | while read -r a; do du -hs "$a" >> dirs_size.txt; done


Это актуально, к примеру, для почтового сервера, когда надо посмотреть, какие ящики наиболее объёмные, или для списка сайтов на веб сервере, чтобы понять, какой из них пухнет выше нормы. Если это происходит регулярно, то история замеров иногда помогает, особенно если размер хранилища очень большой и его обсчёт занимает много времени. Для хранилища почтового сервера в формате maildir это актуально. Там обсчёт всех ящиков может минуты длиться. То же самое для большого сервера бэкапов. Иногда и десятки минут могут уйти для обсчёта большого хранилища на HDD дисках с миллионами мелких файлов.

Если вопрос с занятым местом на сервере возникает регулярно, а решать его удобнее интерактивно, то я почти всегда поставлю туда ncdu. По умолчанию его нет в моём списке обязательного софта, который ставлю, но при необходимости поставлю именно его. Он давно есть в стандартных репозиториях, поэтому изначально выбор был в его пользу, а теперь уже привык.

# apt install ncdu

У ncdu свой механизм сканирования, и работает он значительно быстрее du. Плюс, интерактивно в некоторых ситуациях быстрее разобраться с проблемой занятого места.

Если надо максимально быстро сканировать каталоги и узнавать их размер, то можно взять консольную утилиту dust. Мне она известна давно, ещё со времён, когда её не было в стандартных репозиториях дистрибутивов, а ставить приходилось вручную. Это и ограничивало использование. С выходом Debian 13 этой проблемы нет. Утилита появилась в стандартном репозитории под именем du-dust:

# apt install du-dust

Dust использует свой механизм обхода каталогов, который быстрее du и в некоторых ситуациях быстрее ncdu. Плюс, у него наглядный псевдографический вывод директорий с размерами и с подсветкой самых объёмных. Визуально легко оценить реальную картину на дисках. Для какого-нибудь большого сервера с бэкапами сырых данных эта утилита будет актуальна.

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

———
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
👍227👎3
В стандартных репозиториях Debian, да и многих других дистрибутивов давно живёт небольшая и неприметная утилита grc, которая умеет подкрашивать терминал для популярных утилит и типовых логов. Использовать её очень просто, ничего запоминать не надо.

# apt install grc

И теперь можно подсвечивать почти все типовые действия в консоли:

# grc ss -tulnp
# grc ps axf
# grc ping ya.ru
# grc cat /var/log/syslog
# grc tail -f /var/log/syslog

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

Причём в Debian для алиасов уже всё настроено. Достаточно в в файле /etc/default/grc указать параметр:

GRC_ALIASES=true

После этого активируется файл конфигураций /etc/profile.d/grc.sh и подсветка будет активирована для добавленных туда утилит.

Некоторые современные SSH клиенты сами умеют подкрашивать некоторые строки. Например, в MobaXterm по умолчанию по шаблонам есть подсветка некоторых элементов: подсветка IP адресов, слов error, warn и т.д. Но я обычно это отключаю, что видеть исходный терминал так, как он есть.

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

———
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
5👍213👎3
Рассказываю, как выполнить важную базовую настройку, которую я обычно делаю на всех серверах. Речь пойдёт про отправку системной почты пользователя root через внешний почтовый сервер. Для этого можно использовать любой smtp клиент, например ssmtp или msmtp.

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

Если Postfix не установлен, то надо поставить:

# apt install postfix

Сохраняем на всякий случай стандартную конфигурацию и заменяем своей:

# cp main.cf main.cf.orig

Содержимое main.cf:

relayhost = mail.zeroxzed.ru:465
smtp_sasl_auth_enable = yes
smtp_sasl_security_options =
smtp_tls_CAfile = /etc/ssl/certs/Entrust_Root_Certification_Authority.pem
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache
smtp_tls_session_cache_timeout = 3600s
smtp_tls_wrappermode = yes
smtp_tls_security_level = encrypt
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_generic_maps = hash:/etc/postfix/generic

Здесь достаточно поменять адрес сервера и порт mail.zeroxzed.ru:465 на свои. Создаём файл sasl_passwd, где будут храниться данные для аутентификации. Формат такой:

mail.zeroxzed.ru servers@zeroxzed.ru:password123

◽️mail.zeroxzed.ru - имя почтового сервера, такое же как в параметре relayhost
◽️servers@zeroxzed.ru:password123 - почтовый ящик и пароль от него

Файл generic имеет следующий формат:

root servers@zeroxzed.ru

Здесь мы указываем, что в письмах отправителя root меняем на servers@zeroxzed.ru. Это нужно для того, чтобы не было проблем с доставкой. Если у вас имя сервера имеет вид srv.local, то без этой замены отправитель будет root@srv.local. С таким отправителем вашу почту большинство серверов не примут, ответив что-то в духе: "Sender address rejected: Domain not found". А почтовая служба Яндекса в обязательном порядке требует, чтобы имя пользователя для аутентификации совпадало с адресом отправителя, иначе письмо не будет отправлено.

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

Формируем на основе текстовых файлов локальные базы данных, с которыми будет работать Postfix, и перезапускаем его:

# postmap /etc/postfix/generic /etc/postfix/sasl_passwd
# systemctl restart postfix

Проверяем отправку:

# echo "Test body message." | mail -s "$(hostname)" zeroxzed@gmail.com

Письмо нормально улетело в Gmail. В теме письма - имя сервера, в отправителе - root <servers@zeroxzed.ru>.

Теперь сделаем так, чтобы локальная почта, адресованная пользователю root, отправлялась куда-то на внешний ящик. Для этого добавляем в /etc/aliases:

root: root@zeroxzed.ru

И обновляем базу алиасов:

newaliases

Проверяем:

# echo "Test body message." | mail -s "$(hostname)" root

В ящик root@zeroxzed.ru должно прийти письмо от root <servers@zeroxzed.ru>.

Теперь все системные уведомления для root будут отправляться в этот ящик. Проверим на каком-нибудь задании crontab с ошибкой. Для этого создадим такое ошибочное задание на выполнение несуществующей команды:

# crontab -e

Добавляем задачу:

* * * * * /usr/bin/command-not-found

Сохраняем и ждём минуту. Получаем на почту ошибку выполнения задания cron. Тема письма будет примерно такая: "Cron <root@srv-web01> /usr/bin/command-not-found". По имени сервера srv-web01 можно сделать правило фильтрации.

С такими настройками, к примеру, кроны с rsync и ключами -v или --progress шлют вывод rsync на почту. Удобно бегло посмотреть, что там куда копируется, или увидеть ошибки, если есть.

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

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

#linux
Please open Telegram to view this post
VIEW IN TELEGRAM
3👍172👎2
Пару недель назад прочитал полезную статью на хабре:

Бросил tmux и написал свой инструмент

Там автор прошёлся прям по больному. Он рассказал про разные терминальные мультиплексоры с упоминанием проблем, которые напрягают в повседневной работе. Я нигде и ни от кого не видел ранее такую подборку. Думал всегда, что это я один страдаю из-за неудобного скрола мышки в screen или глюками с буферами или интерактивными утилитами в tmux. Там в статье прям по пунктам всякие неудобства перечислены и чем они вызваны с точки зрения архитектуры приложений.

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

В итоге автор написал небольшую утилиту atch на С, которая работает идеально, если вам нужно просто сохранять сессию при разрыве соединения и потом обратно в неё подключаться. Нет никакой эмуляции терминала, как в screen или tmux. Atch ничего не парсит, не перекодирует, поэтому нет проблем со скролом мышки, пропаданием истории терминала, глюками с OSC-последовательностями.

Работает atch так, как надо, без каких-либо дополнительных настроек. Я попробовал, очень понравилось. В репозитории есть собранный бинарник, его достаточно скачать:

# curl -Lo atch.tgz https://github.com/mobydeck/atch/releases/latest/download/atch-linux-amd64.tgz
# tar -xzf atch-linux-amd64.tgz atch
# mv atch /usr/local/bin/

Утилита совсем новая. В репозиториях дистрибутивов её, разумеется, пока нет. Очень надеюсь, что она там со временем появится, потому что она удобна и проста, решает ровно одну задачу и делает это хорошо. Всё в духе философии UNIX.

Дальше создаём сессию work:

# atch work

И работаем в ней. Если соединение разорвалось, то подключаемся заново по SSH и заходим в сессию:

# atch work

Видим тут же в терминале всю историю терминала, которая была до отключения!!! Она пишется в ~/.cache/atch/ сразу же в момент вывода. И потом воспроизводится при повторном подключении к сессии. Ничего не теряется. Ты попадаешь в тот же вывод терминала, откуда тебя отключило. Это очень удобно.

Смотрим список сессий:

# atch list

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

Можно запустить любой процесс через atch и потом посмотреть консольный вывод из любого места, подключившись в созданную сессию:

# atch start deploy ./deploy.sh

И история автоматом сохранится. Автор также приводит пример с AI агентами, которые работают в сессии с atch, а потом можно посмотреть, что они там делали. В принципе, записать действия в консоли можно очень разными способами (подборка разных решений этой задачи). Этот возможно и не самый удобный для этой задачи, но максимально простой.

Если много работаете в консоли, используете screen или tmux, рекомендую попробовать atch. Вам должно понравиться. Давно мне не попадались утилиты, которые бы так порадовали своей простой и удобством. Казалось бы, уже всё давно придумано, но, как видим, ещё нет.

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

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

#linux #terminal
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍203👎2
Расскажу про один трюк в strace, про который я вроде бы ещё ни разу не писал. В нём ничего особенного нет, но в некоторых ситуациях с ним удобно. Если случайно нигде не видел подобного использования, то самому может и в голову не прийти, что так можно.

У strace и её производных (ltrace, latrace) есть ключ -o, через который настраивается вывод результата в файл. При этом вместо файла может выступать pipe, а не обычный файл. Покажу сразу на примере. Тут будет видно явное удобство такого подхода.

Strace много всего умеет и обычно используется при дебаге. Я про него часто упоминал в различных заметках в основном в контексте анализа дисковой активности процессов. Например, какие файлы читает процесс, в какие пишет. Вот сразу реальный и полезный пример с Angie/Nginx.

Если у вас навороченная конфигурация, где куча всего подключается из разных директорий, что бывает часто (привет настройкам Nginx в Bitrixenv), то хочется быстро посмотреть, а что реально из какой-то конкретной директории подключается в момент запуска веб сервера. Проще всего это сделать, анализируя активность процесса во время выполнения команды nginx -t. В этот момент конфигурация проверяется на ошибки, соответственно, она должна быть прочитана.

Можно просто посмотреть все системные вызовы openat, которые отвечают за чтение:

# strace -zf -e trace=openat nginx -t

В выводе будет много всего лишнего - библиотеки, логи, системные файлы и т.д. Можно попробовать грепнуть:

# strace -zf -e trace=openat nginx -t | grep /etc/nginx

У вас, кстати, ничего не получится. Это особенность nginx, про которую просто надо знать. Вывод этой команды улетает не в стандартный поток stdout, а в stderr. Не знаю, почему так, но в Nginx это исторически сложилось. А grep не грепает stderr. Вам нужно будет как минимум сделать вот так:

# strace -zf -e trace=openat nginx -t 2>&1 | grep /etc/nginx

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

# strace -o "| grep -Eo '/etc/nginx/[^\"]+'" -zf -e trace=openat nginx -t
/etc/nginx/nginx.conf
/etc/nginx/modules-enabled
/etc/nginx/mime.types
/etc/nginx/conf.d
/etc/nginx/sites-enabled
/etc/nginx/sites-enabled/default

На выходе получили аккуратный обработанный список директорий и файлов в /etc/nginx, которые веб сервер прочитал. Смысл того, что мы сделали в том, что через ключ -o вывод отправили не в файл, а в пайп, где он сразу же был обработан тем же grep, который вывел только то, что было между " ", а это как раз путь в файловой системе. Вся остальная информация не нужна и только мешает.

В данном случае уже не имеет значение, куда и как пишет nginx. За этим не нужно следить. Аналогичная команда с обычным грепом выглядела бы так:

# strace -zf -e trace=openat nginx -t 2>&1 | grep -Eo '/etc/nginx/[^\"]+'

Тут обязательно перенаправление 2>&1.

Подобная обработка вывода через pipe актуальна для анализа каких-то интерактивных программ. Например, iftop:

# strace -o "| grep -Eo '/[^\"]+'" -zf -e trace=openat iftop

Запускаем и сразу закрываем iftop. В консоли видим список файлов, которые она прочитала. В данном случае команда:

# strace -zf -e trace=openat iftop | grep -Eo '/[^\"]+'

уже не сработает. До grep дело не дойдёт, так как сначала вывалится портянка strace, а потом запустится iftop. В первом случае мы сразу же обрабатываем вывод в strace, выводим его в консоль и потом запускается iftop.

Можно посмотреть, где живёт конфигурация mc, запущенная под рутом:

# strace -o "| grep -Eo '/root[^\"]+'" -zf -e trace=openat mc
/root/.config/mc/ini
/root/.bash_history

Просто и наглядно. Удобно смотреть, кто, что читает в момент запуска.

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

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

#bash #linux #terminal
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍114👎1
Когда разбирался с файловыми системами, увидел возможность EXT4, про которую раньше не знал. Можно сделать дамп метаданных файловой системы, без непосредственно самих данных. То есть вы получаете список всех файлов с размером, правами и прочими атрибутами. Этот дамп можно примонтировать, как обычный диск, и посмотреть структуру. Всё будет выглядеть, как обычная файловая система, только самих данных не будет.

Выглядит это примерно так. Работает даже для примонтированной системы. Но для надёжности, конечно, лучше отмонтировать, если есть возможность:

# e2image -rf /dev/sda1 fs_raw.img
# mkdir -p /mnt/fs_metadata
# mount -t ext4 -o ro,noload fs_raw.img /mnt/fs_metadata

В данном случае я сделал образ метаданных корневого раздела диска и примонтировал его в /mnt/fs_metadata.

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

Выглядит это примерно так:

# rsync -ani --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/run --exclude=/tmp --exclude=/mnt / /mnt/fs_metadata/

В данном случае --exclude используются, потому что я сравниваю корень. Оставил их для примера, если нужно будет тоже сделать какие-то исключения. На выходе получите листинг изменённых файлов, где будет указан тип файла
f / d / l (файл / директория / симлинк) и чем различаются: s - размер, p - права, o - владелец и т.д. По этим меткам, соответственно, можно грепнуть и вывести только нужные различия.

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

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

#linux
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍143👎1