Продолжу начатую недавно тему про заметание следов своей деятельности в системе на базе 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

В свете недавних обсуждений гипервизоров вспомнил, как я начинал изучение 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

Коротенькая, но мне кажется полезная заметка на тему одного небольшого сервиса, который поможет тем, кто пишет свои 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

Вспомнил про одну необычную утилиту из мира консоли 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

Я делал заметку про небольшой набор полезных для меня алиасов в консоли 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

Относительно недавно (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

Когда надо узнать скорость сетевого интерфейса в 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