​​В репозиториях популярных дистрибутивов есть маленькая, но в некоторых случаях полезная программа progress. Из названия примерно понятно, что она делает - показывает шкалу в % выполнения различных дисковых операций. Она поддерживает так называемые coreutils - cp, mv, dd, tar, gzip/gunzip, cat и т.д.

Progress по смыслу немного похожа на pv, но принцип работы там совсем другой. Pv берёт информацию из пайпов, соответственно, надо заранее направить поток в неё, чтобы что-то увидеть. А progress сканирует каталог /proc, находит там поддерживаемые утилиты, далее идёт в fd и fdinfo, находит там открытые файлы и следит за их изменениями.

Для того, чтобы посмотреть прогресс той или иной команды, не обязательно запускать утилиту progress вместе с выполнением. Это можно сделать в любой момент времени. Например, запустили упаковку или распаковку большого архива gz и хотите посмотреть, как она выполняется. Достаточно открыть вторую консоль и там посмотреть. Мне это часто актуально, когда большие дампы sql распаковываю. Иногда это прям очень долго, особенно, когда однопоточный gzip используется.

Покажу сразу на примере. Создадим файл:

# dd if=/dev/urandom of=testfile bs=1M count=2048

За процессом, кстати, тоже можно следить с помощью progress, только не будет отображаться % выполнения, потому что утилита ничего не знает о конечном размере. Будет отображаться только скорость записи в режиме реального времени.

Жмём файл:

# gzip testfile

Открываем вторую консоль и там смотрим за процессом:

# watch -n 1 progress -q
[34209] gzip /tmp/testfile
    6.5% (132.2 MiB / 2 GiB)

Если запустить без watch, то progress выведет только текущую информацию и сразу же закроется. То есть не получится наблюдать в режиме реального времени.

То же самое будет и с распаковкой:

# gunzip testfile.gz

В соседней консоли смотрим:

# watch -n 1 progress -q
[35685] gzip /tmp/testfile.gz
    76.1% (1.5 GiB / 2.0 GiB)

Progress очень маленькая утилитка, написанная на чистом C (вспоминается песня "Папа может в C"). Размер - 31K. Из зависимостей только небольшая библиотека ncurses для вывода информации от сишных программ в терминал. Есть почти под все линуксы:

# apt install progress
# dnf install progress

⇨ Исходники

#terminal #linux

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

▪️ duf как замена df
▪️ bat как замена cat
▪️ hyperfine как замена time

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

# apt install exa

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

◽более информативная расцветка
◽умеет показывать расширенные атрибуты файлов (xattrs)
🔥иерархичное древовидное отображение
◽отображает статус файлов в git репозитории (изменён или нет со времени последнего коммита)
◽может выводить в несколько колонок информацию

Все привычные ключи ls тоже поддерживает. Мне лично только расцветка понравилась и древовидное отображение:

# exa -T /var/log

├── alternatives.log
├── alternatives.log.1
├── alternatives.log.2.gz
├── alternatives.log.3.gz
├── alternatives.log.4.gz
├── apt
│ ├── eipp.log.xz
│ ├── history.log
│ ├── history.log.1.gz
│ ├── history.log.2.gz
......................................

Можно ограничить максимальный уровень вложенности:

# exa -T -L 2 /var/log

Привычные ключи ls, как я уже сказал, поддерживаются, поэтому можно алиасом заменить ls на exa:

# echo 'alias ls=exa' >> ~/.bashrc
# source ~/.bashrc
# ls -la

❗️К сожалению, exa больше не развивается, потому что автор куда-то пропал. В репозитории есть об этом информация. Предлагают переходить на форк eza, но его пока нет в репозиториях для Debian 12, но планируется в Debian 13. В Ubuntu 24 уже есть eza. Так что всё написанное актуально и для неё. Если в вашем дистрибутиве она уже есть, то имеет смысл поставить именно её. Там есть ряд небольших правок багов и некоторые улучшения функциональности. Я себе поставил в WSL как замену ls.

⇨ Исходники / Сайт

#linux #terminal

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

В комментариях один человек посоветовал использовать утилиту column. Что самое интересное, я про неё знаю, писал заметку. Тоже посоветовали в комментариях. Но с ss не догадался её попробовать. А это удобно. Вывод получается более компактный и наглядный:

# ss -tulnp | column -t
# ss -nte | column -t

А самое главное, что я cразу эту конструкцию запомнил и теперь постоянно пользуюсь, так как и ss, и column есть во всех дистрах из коробки. Рекомендую попробовать. Я column привык с mount использовать для удобного вывода:

# mount | column -t

Теперь вот и с ss. Про netstat стал забывать. Не использую почти, перешёл на ss. Один неприятный нюанс всё равно остался. Даже с column в ss бывают длинные строки, если поле с users очень длинное, типа такого:

users:(("smtpd",pid=1680589,fd=6),("smtpd",pid=1680587,fd=6),("smtpd",pid=1680585,fd=6),("smtpd",pid=1678705,fd=6),("smtpd",pid=1678348,fd=6),("smtpd",pid=1675803,fd=6),("master",pid=1837,fd=13))

Netstat вообще не выводит пользователей, только название процесса. В ss тоже можно убрать, например вот так (заменили p на e):

# ss -tulne

Но тут вывод о процессе ненагляден, так как выводится имя юнита systemd, а не непосредственно рабочего процесса.

#linux #terminal

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

Покажу сразу очень наглядный пример:

# echo --version
--version

# /usr/bin/echo --version
echo (GNU coreutils) 9.1

В первом случае ключ не сработал, а во втором сработал, хотя запускал вроде бы одно и то же. А на самом деле нет. В первом примере я запустил echo из состава оболочки bash, а во втором случае - это бинарник в файловой системе. Это по факту разные программы. У них даже ключи разные.

Узнать, что конкретно мы запускаем, проще всего через type:

# type echo
echo is a shell builtin

# type /usr/bin/echo
/usr/bin/echo is /usr/bin/echo

В первом случае прямо указано, что echo - встроена в оболочку.

И ещё один очень характерный пример:

# type ls
ls is aliased to `ls --color=auto'

Очень часто ls это не утилита ls, а алиас с дополнительными параметрами.

Когда вы вводите команду в терминал, происходит следующее:

1️⃣ Проверяются алиасы. Если команда будет там найдена, то поиск остановится и она исполнится.

2️⃣ Далее команда проверяется, встроена в ли она в оболочку, или нет. Если встроена, то выполнится именно она.

3️⃣ Только теперь идёт поиск бинарника в директориях, определённых в $PATH.

У последнего варианта тоже есть свои нюансы. У вас может быть несколько исполняемых файлов в разных директориях с одинаковым именем. Ситуация нередкая. Можно столкнуться при наличии разных версий python или php в системе. Поиск бинарника ведётся по порядку следования этих директорий в переменной слева направо.

# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Что раньше будет найдено в директориях, определённых в этой строке, то и будет исполнено.

И ещё важный нюанс по этой теме. Есть привычные команды из оболочки, которых нет в бинарниках. Например, cd.

# type cd
cd is a shell builtin

# which cd

В выводе последней команды пусто, то есть бинарника cd нет. Если вы будете использовать cd в скриптах, то проблем у вас не будет, так как там обычно в шебанге указан интерпретатор. Обычно это bash или sh, и там cd присутствует.

А вот если вы cd используете в юните systemd, то ничего не заработает:

ExecStart=cd /var/www/ ....... && .........

Вот так работать не будет. Systemd не будет запускать автоматом оболочку. Надо это явно указать:

ExecStart=/usr/bin/bash -с "cd /var/www/ ......."

То есть либо явно указывайте bash, либо запускайте скрипт, где bash будет прописан в шебанге.

❗️В связи с этим могу дать совет, который вам сэкономит кучу времени на отладке. Всегда и везде в скриптах, в кронах, в юнитах systemd и т.д. пишите полные пути до бинарников. Команда, в зависимости от пользователя, прав доступа и многих других условий, может быть запущена в разных оболочках и окружениях. Чтобы не было неожиданностей, пишите явно, что вы хотите запустить.

#bash #terminal

И вновь возвращаемся к рубрике с современными утилитами, которые можно использовать в качестве альтернативы более старым, потому что они уже поселились в официальных репозиториях. Речь пойдёт об уже упоминаемой мной несколько лет назад программе fd, которую можно использовать вместо find. Она приехала в стабильные репы:

# apt install fd-find

Короткое название fd использовать не получится, потому что оно уже занято. Придётся использовать fdfind. Под Windows она, кстати, тоже есть:

> winget install sharkdp.fd

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

Ищем файл syslog в текущей директории:

# fdfind syslog

Ищем файл в конкретной директории:

# fdfind syslog /var/log

Ищем файл по всему серверу:

# fdfind syslog /

Вот то же самое, только с find:

# find . -name syslog
# find /var/log -name syslog
# find / -name syslog

По умолчанию find найдёт только полное совпадение по имени. Файл должен будет точно называться syslog, чтобы попасть в результаты поиска. Fd в примере отобразит все файлы, где встречается слово syslog. Это и интуитивнее, и проще для запоминания. Хотя этот момент субъективен. С find такой же поиск будет выглядеть вот так:

# find / -name '*syslog*'

Отличия от find, которые отмечают авторы:

◽️Более скоростной поиск за счёт параллельных запросов. Приводят свои измерения, где это подтверждается.
◽️Подсветка результатов поиска.
◽️По умолчанию поиск ведётся без учёта регистра.
◽️Итоговые команды в среднем на 50% короче, чем то же самое получается с find.
⚠️ Отдельный ключ --exec-batch или -X в дополнение к традиционному --exec. Разница в том, что --exec выполняется параллельно для каждого результата поиска, а с помощью --exec-batch можно во внешнюю команду передать весь результат поиска. Это важный момент, который где-то может сильно выручить и упростить задачу. Даже если вам сейчас это не надо, запомните, что с fd так можно. Где-то в скриптах это может пригодиться.

Несколько простых примеров для наглядности. Поиск файлов с определённым расширением:

# fdfind -e php -p /var/www

Найти все архивы и распаковать их:

# fdfind -e zip -p /home/user -x unzip

Найти файлы с расширением gz и удалить одной командой rm:

# fdfind -e gz -p /var/log -X rm

Вызванный без аргументов в директории, fd рекурсивно выведет все файлы в ней:

# cd /var/log
# fdfind

Это примерно то же самое, что с find:

# find -name '*'

Только у fd вывод нагляднее, так как уже отсортирован по именам. А find всё вперемешку выводит. Ему надо sort добавлять, чтобы то же самое получилось:

# find -name '*' | sort

Fd умеет результаты выводить не по одному значению на каждую строку, а непрерывной строкой с разделением с помощью так называемого NULL character. Все символы воспринимаются буквально, не являются специальными, их не надо экранировать. Актуально, когда результаты поиска имеют пробелы, кавычки, косые черты и т.д. Например, xargs умеет принимать на вход значения, разделённые NULL character. У него для этого отдельный ключ -0, --null.

Покажу на примере, как это работает:

# touch 'test test.log'
# fdfind -e log
...
test test.log

# fdfind -e log | xargs wc -l
...
wc: test: No such file or directory
wc: test.log: No such file or directory

Xargs не смог обработать файл с пробелом. А вот так смог:

# fdfind -0 -e log | xargs -0 wc -l
...
0 ./test test.log

И ничего экранировать не пришлось. Полезная возможность, стоит запомнить. Find то же самое делает через ключ -print0:

# find . -name '*.log' -print0 | xargs -0 wc -l

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

#terminal #linux #find

На днях на одном из серверов VPN с IP 175.115.158.81 заметил странные строки в логе:

ovpn-server[3742533]: TCP connection established with [AF_INET] 95.145.141.246:58560
ovpn-server[3742533]: 95.145.141.246:58560 Connection reset, restarting [0]
ovpn-server[3742533]: 95.145.141.246:58560 SIGUSR1[soft,connection-reset] received, client-instance restarting

Внимание привлекло то, что 95.145.141.246 это мой IP адрес ещё одного VPN сервера. Я не припомнил, чтобы настраивал на нем клиента для подключения к серверу 175.115.158.81. На всякий случай сходил туда и убедился в этом:

# ps axf

Никакого openvpn клиента тут не было запущено. Да и настроек для него тоже нет. У меня настроена разветвлённая система VPN туннелей с маршрутизацией, так что иногда начинаю в ней путаться. Надо схему рисовать.

Я немного напрягся и стал разбираться, в чём тут дело. Решил посмотреть на сервере с IP 95.145.141.246 исходящие сетевые соединения:

# ss -ntu

Соединения разные были, но к указанному VPN серверу ничего не было. Стало ещё интереснее. Расчехлил tcpdump и стал смотреть им:

# tcpdump -nn 'dst host 175.115.158.81'

Подождал, когда в логе на VPN сервере 175.115.158.81 опять появится запись о неудачном соединении. Вернулся в консоль сервера 95.145.141.246 и увидел запись:

14:29:38.706375 IP 172.17.0.4.58700 > 175.115.158.81.1778

1778 - порт VPN сервера. Смотрю на адрес 172.17.0.4 и тут до меня доходит, что это Docker контейнер. Проверяю IP адреса контейнеров:

# docker ps -q | xargs -n 1 docker inspect --format '{{ .NetworkSettings.IPAddress }} {{ .Name }}' | sed 's/ \// /'
...........
172.17.0.4 gatus
...........

А там мониторинг Gatus. И тут я вспоминаю, что настроил мониторинг VPN канала через проверку доступности порта, на котором он принимает подключения. Всё встало на свои места. Не думал, что проверка порта будет такими записями в логе отмечаться. Хотя на самом деле с таким встречаюсь иногда, когда через Zabbix порты проверяю через simple check.

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

#linux #terminal

Где вы оставляете следы, когда подключаетесь по SSH к серверу на базе Linux? Собрал краткую подборку основных ваших артефактов в Debian. Будет актуальна во всех дистрибутивах на её основе. Для других могут отличаться только частности в виде имён и путей к логам, но общий смысл будет тот же.

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

1️⃣ Подключение по SSH фиксируется в /var/log/auth.log. С ним всё просто - это текстовый лог. Сразу посмотреть удачные подключения можно так:
# grep 'Accepted' /var/log/auth.log
Лога может не быть, либо логи могут параллельно храниться в journald. Смотреть так:
# journalctl -u ssh -r

2️⃣ Информация о подключении будет записана в бинарный лог /var/log/wtmp. Смотреть в консоли командой last. Увидите информацию о дате логина, пользователе, его IP адресе. Там же дополнительно хранится информация о загрузках и выключениях сервера, в том числе кем они были инициированы. Могу сразу для расширенной информации посоветовать ключи: last -Faiwx.

3️⃣ Информация о последнем логине пользователя хранится в бинарном файле /var/log/lastlog. Смотреть одноимённой консольной командой lastlog. Увидите список всех системных пользователей и дату их последнего подключения вместе с IP адресом.

4️⃣ Пока вы не отключились, информация о вашей активной сессии вместе с остальными сессиями хранится в бинарном файле /var/run/utmp. Смотреть информацию оттуда можно командой who.

5️⃣ Если во время подключения были неудачные попытки с неправильным логином и паролем, то эта информация будет сохранена в бинарном файле /var/log/btmp. Смотреть командой lastb.

6️⃣ Если что-то делали в консоли, то информация об этом сохранится в текстовом файле ~/.bash_history. Если не хотите, чтобы это происходило, после логина измените место хранения истории через переопределение переменной. Выполните в консоли:
# export HISTFILE=/dev/null
В рамках сессии история будет сохраняться и отображаться по команде history, но в файл записана не будет.

Для скрытия информации о подключении можно банально обнулить указанные выше логи и бинарные файлы. О вас не останется информации, но станет понятно, что кто-то подключался. Я, кстати, с подобным сталкивался. Когда только устроился в одну компанию. Через несколько дней после начала работы, когда стал проверять все серваки и разбираться в инфраструктуре, заметил на одном из серверов очищенную историю и прочие следы. Остаётся только гадать, что там делал бывший админ.

Просто взять и удалить информацию о себе из бинарных файлов не очень просто. Как один из вариантов - взять готовый скрипт, который на основе IP адреса вычистит информацию в том числе из бинарных логов. У меня на Debian 12 он не завёлся. Всё время ругался на UTMP block size. Мучал уже родной ChatGPT с chatgpt.com на эту тему, не смог помочь. Много всего предложил, но ничего не помогло. В конце предложил по-другому очистить файл: удалить и заново создать. Забил.

Для того, чтобы от подобных очисток защититься, достаточно на любом Linux сервере запустить syslog сервер или systemd-journal-remote. И вы всегда будете знать, кто и когда к вам подключается. Для логов службы sshd не нужно ни много ресурсов, ни места на диске. Нет нужды разворачивать какое-то специальное хранилище для логов, если у вас в нём нет нужды. Я отдельно для syslog сервера поднимал виртуалку 1CPU/512M/10G.

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

#terminal #security

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

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

Напомню, что у файла есть несколько меток времени:

▪️Birth (crtime) - время создания айноды файла, то есть самого файла.
▪️Access (atime) - время последнего доступа к файлу.
▪️Modify (mtime) - время последнего изменения содержимого файла.
▪️Change (ctime) - время последнего изменения метаданных файла в файловой системе.

Посмотреть указанные метки можно командой stat:

# stat testfile

Поменять значения atime и mtime крайне просто. Можно взять банальную утилиту touch:

# touch -m -a -t 202501010000 testfile
# stat testfile
Access: 2025-01-01 00:00:00.000000000 +0300
Modify: 2025-01-01 00:00:00.000000000 +0300

То же самое можно сделать напрямую в файловой системе через debugfs:

# debugfs -w -R 'set_inode_field /var/www/testfile crtime 202501010000' /dev/sda1
# debugfs -w -R 'set_inode_field /var/www/testfile atime 202501010000' /dev/sda1
# debugfs -w -R 'set_inode_field /var/www/testfile mtime 202501010000' /dev/sda1
# debugfs -w -R 'set_inode_field /var/www/testfile ctime 202501010000' /dev/sda1
# echo 2 > /proc/sys/vm/drop_caches
# stat /var/www/testfile
Access: 2025-01-01 03:00:00.881765992 +0300
Modify: 2025-01-01 03:00:00.881765992 +0300
Change: 2025-01-01 03:00:00.881765992 +0300
Birth: 2025-01-01 03:00:00.881765992 +0300

В конце для проверки надо обязательно сбросить кэш, иначе изменений не увидите. Важно понимать, что для изменения atime и mtime достаточно обычных прав доступа к файлу. То есть любой червь, который залез через исходники сайта, может у него менять эти параметры. А вот для изменения crtime уже нужны права root, так как надо лезть в файловую систему.

Помимо прочих средств защиты, конкретно в данной ситуации с файлами может помочь аудит доступа с помощью auditd.

# apt install auditd
# auditctl -w /var/www/testfile -p rwa -k testfile_rule

◽️rwa - чтение (r), запись (w), изменение атрибута (a)
◽️testfile_rule - название правила аудита

Смотрим список правил:

# auditctl -l
-w /var/www/testfile -p rwa -k testfile_rule

После изменения файла смотрим записи аудита:

# aureport -f -i | grep /var/www/testfile
# ausearch -i -k testfile_rule

Лог аудита хранится в директории /var/log/audit. Поддерживается работа через syslog, так что при желании этот лог выносится на внешний сервер, как я уже рассказывал в предыдущих заметках. Подобный аудит больше актуален для конфигурационных файлов служб, в том числе системных, а не исходников сайтов. Я просто показал пример.

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

#linux #terminal

Я в консоли Linux настройки IP адресов уже давно привык смотреть так:

# ip a

На выходе получается что-то похожее на ifconfig, только с другим форматированием. Ifconfig давно уже не ставлю и не использую. Все ключи позабыл. Смысла в ней уже нет с повсеместным распространением утилиты ip.

На прошлой неделе смотрел одного блогера и мельком увидел, как он смотрит IP адреса сервера:

# ip -br a
lo         UNKNOWN    127.0.0.1/8 ::1/128 
eth0        UP        172.18.107.235/20 fe80::215:5dff:fe0d:7101/64 
eth1        UP        192.168.101.2/24 fe80::215:5dff:fe0d:7105/64 
docker0      DOWN       172.17.0.1/16 
br-e901d734a0f3 DOWN       172.18.0.1/16 

Конкретизируем только IPv4:

# ip -br -4 a
lo         UNKNOWN   127.0.0.1/8 
eth0        UP       172.18.107.235/20 
eth1        UP        192.168.101.2/24 
docker0      DOWN      172.17.0.1/16 
br-e901d734a0f3 DOWN      172.18.0.1/16

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

Для просмотра линков и mac адресов ключ тоже применим:

# ip -br l
# ip -br n

Для справки ещё одну команду добавлю, которую тоже постоянно выполняю. Просмотр маршрутов:

# ip r

Вообще, использование ip упростило вопросы просмотра и управления сетевыми настройками, так что довольно легко и добровольно на неё переключился в своё время. Где-то наверное со времён Centos 7.

Интересно, кто-то ещё ставит специально ifconfig и использует? Её вроде выпилили из базовых наборов системных утилит.

#linux #terminal

Для тех, кому в консоли достаточно обычного bash, могу порекомендовать ресурс, с помощью которого можно быстро настроить себе prompt. Для тех, кто не знает, что это такое, поясню. Promt – это информация, которая отображается в командной строке перед полем с вводом своей команды. Его называют приглашением командной строки.

Стандартный promt чаще всего user@host-name:current-directory# . С помощью сайта bash-prompt-generator.org можете легко его изменить, просто собрав как в конструкторе те элементы, что вам нужны. И тут же на сайте видно, как будет выглядеть приглашение командной строки.

Из того, что обычно добавляют, отмечу следующие вещи:

- отображение IP адреса сервера
- подсветка промта разными цветами на разных серверах
- подсветка промта красным цветом при работе от root
- вывод времени

Немного поигрался в конструкторе и собрал следующий промт:

[username@hostname.com|192.168.1.100] 20:32:03 (~/bin)$ █

PROMPT_COMMAND='PS1_CMD1=$(ip route get 1.1.1.1 | awk -F"src " '"'"'NR == 1{ split($2, a," ");print a[1]}'"'"')'; PS1='[\[\e[38;5;196m\]\u\[\e[0m\]@\H|${PS1_CMD1}] \t (\[\e[4m\]\w\[\e[0m\])\$ '

Теперь эту команду надо добавить в ~/.bashrc и применить изменения:

# source ~/.bashrc

В данном случае мы настроили promt у конкретного пользователя. Я цвет имени пользователя сделал красным, потому что это root. Для остальных пользователей promt можно вообще не менять, либо задать индивидуальный. Общие же настройки для всех пользователей живут в системном файле /etc/bash.bashrc.

Если у вас какой-то прикольный и необычный promt, поделитесь, пожалуйста, информацией.

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

#terminal #bash

Когда-то давно писал про одну полезную консольную команду, которой иногда пользуюсь. Она принудительно и моментально отправляет сервер с Linux в перезагрузку. Эффект аналогичен нажатию на кнопку reset:

# echo b > /proc/sysrq-trigger

Разница с консольными командами reboot или shutdown как минимум в том, что они обычные бинарники на диске.

# type reboot
reboot is /usr/sbin/reboot

# type shutdown
shutdown is /usr/sbin/shutdown

Хотя на самом деле это уже давно не бинарники, а только ссылки на /bin/systemctl, но это не отменяет того, что последний тем не менее исполняемый файл. Он должен существовать, а во время выполнения пошуршать диском. У него куча ссылок на таргеты и службы systemd.

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

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

Недавно, кстати, в статье видел использование команды с принудительной перезагрузкой. Там автор наживую накатил на VPS поверх работающей системы RouterOS. Соответственно, текущую файловую систему он уничтожил, никакой бинарник запустить невозможно. А само ядро ОС всё ещё живёт в памяти и работает. Вот ему и можно отправить напрямую команду на перезагрузку.

Эта команда является частью так называемых Linux Magic System Request Key Hacks (sysrq). Магические сочетания клавиш, которые отправляют команды напрямую в ядро. Они реально привязаны к сочетаниям клавиш, выполняемых с управляющего терминала и подключенной клавиатуры. ALT + SysRq + <command key>. Клавиша SysRq часто совмещена с PrtSc. Уже не помню, когда последний раз сидел за экраном реального сервера, если это не мои домашние тестовые компы. Обычно везде хоть какой-то IPMI есть.

Ядро должно поддерживать эти команды. Обычно в популярных дистрибутивах это так:

# cat /proc/sys/kernel/sysrq

◽️ 0 - sysrq отключен
◽️ 1 - sysrq полностью включен
◽️ >1 - включены отдельные функции

На Debian или Centos, с которыми я больше всего работал, перезагрузка всегда срабатывала.

Команд, которые можно отправить ядру, довольно много. Я лично использую только b для перезагрузки. Остальные не помню и никогда не использовал. А про reboot помню. Видел рекомендации, что перед перезагрузкой попробовать какие-то другие команды, типа тех, что отмонтируют диски, завершат процессы и т.д. Обычно если ты жёстко ресетишь сервер, то пробовать что-то не имеет большого смысла, потому что уже висим.

Если всё же интересно, то весь список команд можно запросить у ядра:

# echo h > /proc/sysrq-trigger | less /var/log/kern.log

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

#linux #terminal

Каждый практикующий линуксоид хотя бы раз в жизни сталкивался с OOM Killer, который просто приходит и грохает какое-нибудь приложение. Чаще всего от этого страдают СУБД, так как они обычно самые жирные по потреблению памяти.

Небольшая инструкция на тему того, что делать, если на сервере кончается память и к вам приходит OOM Killer.

1️⃣ Первым делом я бы проверил системные логи на тему работы OOM Killer. Если у вас включены текстовые логи syslog, то сделать это проще всего так:

# grep -i Killed /var/log/syslog

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

Может так получиться, что у вас уже давно время от времени прибиваются разные процессы, но заметили вы это только тогда, когда прибили то, что не умеет само подниматься.

2️⃣ Запускаем батю-скрипт на bash, который построит красивую табличку по приоритетным целям для OOM Killer:



printf 'PID\tOOM Score\tOOM Adj\tCommand\n'
while read -r pid comm; do [ -f /proc/$pid/oom_score ] && [ $(cat /proc/$pid/oom_score) != 0 ] && printf '%d\t%d\t\t%d\t%s\n' "$pid" "$(cat /proc/$pid/oom_score)" "$(cat /proc/$pid/oom_score_adj)" "$comm"; done < <(ps -e -o pid= -o comm=) | sort -k 2nr

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

3️⃣ Теперь мы знаем, кого прибивает наш киллер, и видим в табличке OOM Score и OOM Adjustment. Чем выше первое значение, тем больше шансов, что процесс будет прибит. Если стоит 0, то не будет прибит никогда. Кто-то может подумать, что хорошо бы сделать нужному процессу Score 0, но это плохая идея. Если процесс течёт по памяти, то тупо виртуалка зависнет. Обычно так не делают. Второе значение - поправочный коэффициент для управления Score. Чем ниже этот коэффициент, в том числе с минусовыми значениями, тем меньше шансов, что OOM Killer убьёт нужный процесс.

Система этих очков и коэффициентов замороченная. Большого смысла в ней разбираться нет. Главное выставить приоритеты так, чтобы нужный вам процесс имел приоритет на убийство ниже остальных.

4️⃣ Прежде чем менять коэффициенты, идём в свои приложения и настраиваем в них потребление памяти, чтобы она на сервере не кончалась. Настраиваем мониторинг, если его нет. Чаще всего этого будет достаточно и трогать параметры OOM Killer не придётся.

5️⃣ Если используемые вами приложения не имеют своих настроек по потреблению памяти, то настроить их и поведение OOM Killer можно с помощью Systemd. У меня была отдельная заметка по этой теме. Там ничего сложного.

6️⃣ Когда всё настроили и хотите посмотреть, как себя поведёт система, если вдруг памяти не останется, то займите её всю чем-нибудь. Например, утилитой stress. Или просто в консоли запустите:

# python3 -c 'a="a"*1073741824; input()'

Заняли 1GB памяти. Подберите своё значение, чтобы памяти не осталось (2147483648 - 2GB, 3221225472 - 3GB и т.д.). После этого можно воспользоваться магической командой, про одну из которых я недавно писал:

# echo f > /proc/sysrq-trigger

Она принудительно вызывает OOM Killer. Пример, конечно, так себе, потому что OOM Killer скорее всего грохнет запущенную команду (хотя в моих тестах первым умер systemd). Чтобы этого избежать, надо дать ей низкий Score:

# echo -16 > /proc/$(pgrep python3)/oom_adj

Ещё раз вызываем киллера и смотрим, кого он прибьёт:

# echo f > /proc/sysrq-trigger
# grep -i Killed /var/log/syslog

У меня systemd умер первым.

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

#terminal #linux

Я очень много лет использовал в Linux утилиту screen для того, чтобы в случае обрыва связи при подключении по SSH не завершалось выполнение запущенных интерактивных операций. Особенно это касается обновлений системы через apt или dnf. Типичная проблема, не считая банального обрыва связи, - подключился по VPN к серверу, запустил обновление, обновился софт для VPN, тебя отключило, обновление завершилось на середине процесса. Это может привести к проблемам (система не загрузилась из-за прерванного обновления).

В screen меня всегда раздражало то, что после открытия и сворачивания Midnight Commander по комбинации клавиш CTRL + o, очищался терминал и ты не видел то, что там было до этого. Частично помогает скрол окна SSH клиента, но это неудобно и всё равно часть информации пропадает, обрезается.

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

Оказывается, внутри screen есть свой скролер терминала. Достаточно нажать CTRL + a и потом [, откроется скролинг, где клавиашми PgUp / PgDn можно мотать вверх и вниз и читать содержимое терминала, в том числе то, что там было до запуска MC.

Возможно кому-то эта заметка поможет. Жаль, что я раньше об этом не узнал, столько лет раздражала эта фигня, примерно так же, как лесенка в MC, пока не узнал, как от неё избавиться.

Если кто только выбирает, что использовать, screen или tmux, рекомендую последний. По основным возможностям там примерно одно и то же, у tmux даже их больше, а по удобству, очевидности стандартных настроек, tmux тоже выигрывает. Я уже привык к screen, не хочется переучиваться, так как ничего принципиально нового для себя не получу. У tmux до сих пор подсматриваю горячие клавиши и ключи. Для screen это уже давно в голове отложилось и на автомате выполняется.

Когда-то давно опрос делал по поводу screen и tmux, кто чем пользуется. Результат был примерно 50 / 50. Примерно равная популярность у этих утилит. Сейчас ещё Zellij прибавилась. Но не думаю, что она сильно популярна и не станет таковой, пока не приедет в базовые репы. Вы что предпочитаете из этой троицы?

#linux #terminal

Почти всегда, когда надо скопировать файлы с сервера на сервер, использую либо scp, либо rsync. Первый для одиночных файлов, второй для директорий. На прошлой неделе нужно было с одного старого сервера перенести выборочно кучу разрозненных файлов на другой. Вспомнил про возможность Midnight Commander, где одной из панелей с обзором файлов может выступать удалённый сервер. Это очень удобно как раз для моей задачи. Я очень редко этим пользуюсь. Даже не знаю, почему. Нет такой привычки. Хотя объективно это удобнее, чем ходить по каталогам и запускать rsync, вспоминая его ключи, особенно если надо использовать нестандартный порт SSH.

MC поддерживает два разных протокола для передачи - SFTP (SSH File Transfer Protocol) или FISH (Files transferred over Shell protocol). Последний в разделе меню называется как Shell link. По названию не совсем понятно, что это такое. На первый взгляд кажется, что в контексте передачи файлов это одно и то же. Но на деле нет. И я как раз столкнулся лично с различиями.

Сервер, с которого я подключался, был старее того, куда надо было копировать. Там вроде бы Debian 11 стоял, я копировал на 12-й. К сожалению, не могу уточнить, сервер удалён уже, а сразу не было времени подробно разбираться. Сначала использовал sftp и ни в какую не мог подключиться. Постоянно в логе принимающего севера были ошибки в auth.log на тему то ли использовавшихся шифров, то ли формата сертификата. Сразу не записал, только пометил себе сделать об этом заметку.

При этом я спокойно подключался из консоли по ssh к удалённому серверу с тем же сертификатом или паролем. Попробовал в MC подключение по Shell link и сразу подключился. Перекинул файлы и разбираться уже не стал. Позже пробовал с разными серверами использовать разные протоколы - везде работали оба.

В целом, разница понятна, так как протоколы передачи совершенно разные. Лучше использовать более привычный и распространённый sftp, если он разрешён и настроен на принимающем сервере. Это не всегда бывает так. Как и обратная ситуация. Может быть разрешён sftp, но запрещён обычный shell. А подключению по fish как раз нужен хотя бы sh на принимающей стороне. Так что если не подключается один протокол, пробуйте другой.

☝️ Отдельно отмечу такую фишку MC. Вы можете в левой панели открыть один удалённый сервер, а в правой - другой. И не настраивая прямого соединения между этими серверами перекинуть файлы, выступая со своим MC как посредник.

Настраиваются такие подключения так: нажимаем F9 -> Right или Left, то есть выбираем нужную нам панель, потом раздел меню Shell link или SFTP link. Формат подключения типичный для ssh - root@10.20.1.23/mnt/backup. Если аутентификация по ключу настроена, то сразу подключитесь. Если нет - выскочит окно для ввода пароля. Если надо задать пароль или использовать нестандартный порт, то по F1 открывается подсказка, там показаны все варианты.

На подобные заметки постоянно приходят комментаторы и начинают рассказывать, что использовать панельные менеджеры - плохая практика, надо работать в консоли, это быстрее, удобнее и т.д. Давайте воздержимся от этих бессмысленных споров. Пусть каждый работает так, как ему удобно. Мне удобно работать с MC, я к нему привык. И mcedit его люблю.

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

#linux #terminal #mc