Хочешь устроить себе челлендж на знание командной строки? Да пожалуйста, лови тренажер по Linux-терминалу. Правда он на английском, но мы с тобой тоже не пальцем деланные.

Тренажер содержит 77 вопросов. Вполне достаточно чтобы заебаться.

Я даж успешно прошел первую задачку, правда по-олдскульному и затронул все бед-практики, которые только существуют.
ㅤ
Установка простая:

cd /tmp
python3 -m venv textual_apps
cd textual_apps
source bin/activate
pip install cliexercises
cliexercises

Здесь я использовал tmp папку и venv, чтобы систему всяким гавно не засорять, а чисто поиграться.

Что прикольно, если совсем тупой, то можно получить подсказку, будет показано несколько решений. Подсказка открывается по CTRL+S.

Сможешь выбить все 77 вопросов без подсказок?

Исходники этого тренажера лежат тут, а видосик с работой можешь посмотреть тут.

🛠 #linux #bash
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Ремонтировал внешний диск, в моменте отвалился от малины и я получил RAW вместо ext3. Печалька. Бекапы естественно я никакие не делал, хотя 5 лет собирался этим заняться.

Как говорится - пока гром не грянет мужик не перекрестится.

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

fsck -y /dev/sdb
fsck.ext3 -y /dev/sdb

Хмм... помимо fsck.ext3 есть еще и fsck.ext4 и еще несколько штук. Ёбтвою мать. Отправляемся ресерчить, чем эта поебота отличается от обычного fsck.

TL:DR: НИЧЕМ!

Ща, расскажу. Короче в чистом виде fsck это обёртка, универсальная оболочка, которая автоматом определяет тип файловой системы и затем уже запускает условно fsck.ext3, ну или какая там у тебя на дисках.

Автоопределение это заебись, но порой fsck не хочет ничего проверять. Поэтому самостоятельно определяем тип своей файловой системы и в зависимости от результата запускаем fsck.ext3 и т.п.

Чтобы узнать, что запустит fsck делаем так:

fsck -N /dev/sda1

В результате получишь:

[/usr/sbin/fsck.ext4 (1) -- fsck.ext4 /dev/sda1

А еще у fsck нет ключа - [-E extended-options]. В нее можно передать:

-E discard - Включает TRIM (удаление неиспользуемых блоков на SSD) во время проверки. Аналог fstrim, но в процессе fsck.

-E journal_only - Проверяет только журнал ext3/ext4, не сканируя всю ФС. Быстро, но полезно только в определённых сценариях.

-E frag - Проводит анализ фрагментации. Полезно, если интересует дефрагментация ext4.

-E bmap2extent - Преобразует старые "indirect" блоки в extent-формат (для старых ext4).

-E test_fs - Включает особое поведение для тестирования (не используется в продакшене).

Пример:

fsck.ext4 -f -E discard /dev/sda1

Принудительная проверка + удаление "мусорных" блоков на SSD.

# Как fsck определяет тип файловой системы

Порядок определения:

1. Смотрит в /etc/fstab и выгребает третий столбец.
2. Если в fstab хуй, то оно запускает blkid /dev/sda1
3. Если определить не получилось, пиздует в /etc/filesystems, но в большинстве случаев такого файла в современных дистрибутивах нет. Этот файл опционален.

Вот и вся наука. В кишки лезть уже не будет, этой информации вполне достаточно.

Ну и чтобы на каждую ошибку не вводить y, пропиши автофикс:

fsck -y /dev/sda1

Оно там само пошуршит, все исправит и будет тебе счастье. Изучай.

🛠 #linux
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Забавная ситуёвина с ubuntu 24. После того, как человек поменял в файле /etc/ssh/sshd_config порт с 22 на 2222 и сделал systemctl restart ssh - ничего не произошло.

По-прежнему слушался порт 22. Хм... Хуйня какая-то.
ㅤ
Всё оказалось прозаичнее. В новых версиях дистрибутива, ssh демон стал использовать сокетовую модель для подключения клиентов. Как раз недавно мы разбирали systemd и его функционал, поищи по тегу #systemd

Ну так вот. Если подключиться к консоли дистрибутива (не по ssh), то обнаружим, что никакой ssh сервис не запущен. Однако...

Но если выполнить: ss -tln то увидим:

tcp LISTEN 0 4096 *:22 *:*

Да ёбтвою мать! Разбираемся.

Суть такая. Для ssh используется не ssh.service юнит, а ssh.socket. А как мы знаем юнит socket не держит процесс постоянно запущенным. Экономия ресурсов и т.п. А вот когда кто-то обращается к порту 22, запрос улетает на сокет systemd, который уже и запускает сервис ssh.service..

Пиздец конечно конструкция. Если посмотреть файл ssh.socket, в нём будет:

[Unit]
Description=OpenBSD Secure Shell server socket
Before=sockets.target ssh.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Socket]
ListenStream=0.0.0.0:22
ListenStream=[::]:22
BindIPv6Only=ipv6-only
Accept=no
FreeBind=yes

[Install]
WantedBy=sockets.target
RequiredBy=ssh.service

Смотрим на ListenStream, вот тебе и 22 порт.

А чё блядь делать?

Снимать штаны и бегать. А если серьезно, то решается это просто. После правки конфига /etc/ssh/sshd_config делаем:

systemctl daemon-reload
systemctl restart ssh.socket

Перезапускаем именно юнит сокета. После этого порт изменится. А в файле ssh.socket будет такое:

[Socket]
ListenStream=0.0.0.0:2222
ListenStream=[::]:2222

Красота. Если тебя удручают эти нововведения, то можно вернуться к привычной схеме.

Делается это так:

systemctl disable --now ssh.socket
rm -f /etc/systemd/system/ssh.service.d/00-socket.conf
rm -f /etc/systemd/system/ssh.socket.d/addresses.conf
systemctl daemon-reload
systemctl enable --now ssh.service

Способ описан на официальном сайте бубунты.

Вот такие пироги.

Ну а чем отличается ssh_config от sshd_config я описывал в этом посте.

🛠 #linux
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Как-то давненько пришлось мне отлаживать большущую APIху, но под рукой была только консолька. Ни о каком GUI и речь не шла. А пулять запросы через curl я заебался.
ㅤ
Тем более хотелось что-то организованное и визуально приятное.

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

Выбор пал на Posting. Это TUI клиент со всем необходимым функционалом.

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

Ставится элементарно:

curl -LsSf https://astral.sh/uv/install.sh | sh
uv tool install --python 3.13 posting

uv — это современный инструмент для Python, который объединяет в себе функционал менеджера пакетов и виртуальных окружений, задумывается как замена pip + venv/virtualenv + pip-tools.

Для хакерменов прям мастхев. Забирай в копилку, годнота!

🛠 #linux #utilites
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Вечный вопрос — как сохранить правила iptables?
ㅤ
Вот навтыкал ты всяких безумных правил и цепочек через командную строку, радуешься. А после ребута все твои поделки к хуям улетучиваются.

И каждый раз ты идешь гуглить, как это решить. Жиза. Каждый раз, как в первый раз.

А делается всё просто, двумя командами:

sudo iptables-save > /etc/iptables/rules.v4
sudo ip6tables-save > /etc/iptables/rules.v6

Ладно, спиздел, нужно еще доставить:

sudo apt install iptables-persistent

Эта хуёвина автоматом создает файлы /etc/iptables/rules.v4, /etc/iptables/rules.v6 и будет применять их при загрузке.

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

😀😃😄😁😅😂🤣😊
😇🙂🙃😉😌😍🥰😘
😗😙😚😋😛😝😜🤪
🤨🧐🤓😎🤩🥳😏😒

Просто открываешь напрямую файл rules.v4/rules.v6 и прописываешь туда все свои хотелки.

После этого не забываем дёрнуть слона за хобот:

systemctl restart netfilter-persistent

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

sudo netfilter-persistent save

Но в этом случае файлы rules.v4/rules.v6 будут перезатерты, имей это ввиду если лез в них своими руками.

Саммари

1. Ставим iptables-persistent
2. Пиздярим правила в терминале
3. Применяем netfilter-persistent save

Как делаю я? У меня писюн длинный, поэтому сразу вношу все необходимое руками в rules.v4/rules.v6, хотя это не есть бест-практика, не делай так.

Такие дела, изучай.

🛠 #linux #security #iptables
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Вчера в посте я упомянул конфиги iptables лишь для части дистрибутивов, Alex эту ситуацию в комментариях подметил верно.
ㅤ
Давай посмотрим что в других дистрибутивах происходит.

Debian / Ubuntu

Основной пакет → iptables-persistent / netfilter-persistent

/etc/iptables/rules.v4
/etc/iptables/rules.v6

RHEL / CentOS / Rocky / Alma (iptables-services)

/etc/sysconfig/iptables
/etc/sysconfig/ip6tables

Fedora (новые версии)

По умолчанию использует firewalld (поверх nftables). Если ставишь iptables-services:

/etc/sysconfig/iptables
/etc/sysconfig/ip6tables

Arch Linux / Manjaro

Из коробки iptables не сохраняет правила, обычно юзеры делают сами:

/etc/iptables/iptables.rules
/etc/iptables/ip6tables.rules

OpenSUSE / SLES

По умолчанию тоже firewalld, если ставить пакет iptables, правила обычно хранят в:

/etc/sysconfig/iptables

Astra Linux (Смоленск, Орёл и др. редакции)

Астра базируется на Debian, поэтому у неё схема как у Debian/Ubuntu:

/etc/iptables/rules.v4
/etc/iptables/rules.v6

РЕД ОС (RedOS)

RedOS базируется на RHEL/CentOS, поэтому там всё по «редхэту»:

/etc/sysconfig/iptables
/etc/sysconfig/ip6tables

Вроде основное осветил, если что-то проебал, забыл, затроил — пиши в комменты, поправим.

А вообще при возможности пользуйся облачным фаерволом, если страшно конфигурять iptables или руки растут из жопы.

🛠 #linux #security #iptables
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Мне прилетела интересная задача.

🔤🔤🔥🔤🔤🔤🔤

ТЗ: Сервер без GUI, к нему подключают usb-диск с NTFS и начинается автоматическое архивирование. Логин не требуется, сообщения выдаются на tty1.

sudo apt install ntfs-3g # для монтирования ntfs

Использовать будем штатные средства udev + systemd .

1. Подключаем диск, и запоминаем UUID.

lsblk -f

sdc                                                                         
└─sdc1
     ntfs  FLASH
                1234567890ABCDEF

здесь FLASH - метка диска 1234567890ABCDEF - UUID
ㅤ
создадим каталог для монтирования:

mkdir -p /media/usb_ntfs; chmod 777 /media/usb_ntfs

Дальше создаем 4 файла. Чтобы было проще, в каждом файле в начале коммент с названием файла.

После создания:

sudo systemctl daemon-reload

Как это работает:

При подключении диска usb-диска срабатывает UDEV правило 99-usb-mount.rules и пытается запустить службу autousbbackup.service

autousbbackup.service пытается запустить media-usb_ntfs.mount, поскольку жестко он нее зависит.

Сама media-usb_ntfs.mount запустится только в том случае, если UUID диска будет 1234567890ABCDEF.

Если все условия совпадают, autousbbackup.service запустит скрипт autousbbackup.sh, внутри которого Вы напишите копирование или синхронизацию данных в каталог /media/usb_ntfs.

Если используется архивирование с чередованием дисков - просто сделайте у дисков одинаковые метки:

sudo umount /dev/sdXN # где /dev/sdXN  имя вашего NTFS-раздела.
sudo ntfslabel --new-serial=1234567890ABCDEF /dev/sdXN #задайте UUID

👆 Если в mount не указать опцию nofail система будет тормозить при загрузке.
👆 Запустить скрипт через UDEV даже в фоне не получится, поскольку система вырубит его через 5 сек.

#/etc/udev/rules.d/99-usb-mount.rules

SUBSYSTEM=="block", KERNEL=="sd*", ACTION=="add", TAG+="systemd", ENV{SYSTEMD_WANTS}="autousbbackup.service"

#/etc/systemd/system/media-usb_ntfs.mount

[Unit]
Description=Mount USB NTFS by UUID

[Mount]
What=/dev/disk/by-uuid/1234567890ABCDEF
Where=/media/usb_ntfs
Type=ntfs-3g
Options=defaults,big_writes,nofail,uid=1000,gid=1000

[Install]
WantedBy=multi-user.target

#/etc/systemd/system/autousbbackup.service

[Unit]
Description=Simple service autousbbackup
Requires=media-usb_ntfs.mount
After=media-usb_ntfs.mount

[Service]
Type=simple
ExecStart=/root/work/autousbbackup/autousbbackup.sh

[Install]
WantedBy=multi-user.target

#!/bin/bash
#/root/work/autousbbackup/autousbbackup.sh

declare -x PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
declare MOUNT_POINT=/media/usb_ntfs
declare TTY=/dev/tty1
declare DF='%(%Y%m%d-%H%M%S)T' #date format
declare LOG="$0.log"
exec &>"$LOG" # only one backup log
#exec &>>"$LOG" # all backups log
printf "$DF %s\n" -1 "START BACKUP"|tee "$TTY"
##############################################

sleep 3 # backup emulation

##############################################linux 
printf "$DF %s\n" -1 "END BACKUP"|tee "$TTY"

#suicide, because service require mount point 
systemd-mount --umount "$MOUNT_POINT"

🛠 #linux #bash
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Как оказалось многие не знают, как нативным cron (без systemd timers) запускать скрипты с интервалом в 30 секунд, без модификации самого скрипта.
ㅤ
Все довольно просто и очевидно. Нужно сделать бутерброд.

Cron исторически работает только с минутной точностью. В crontab нельзя написать «каждые 10 секунд» или «раз в 30 секунд». Для этого обычно использую systemd timers или отдельный демонический скрипт с while true; sleep ...

В crontab строка запускается раз в минуту. Но внутри можно поставить sleep — задержку перед запуском. Таким образом мы получим несколько запусков в рамках одной минуты.

* * * * * /usr/local/sbin/bashdays.sh
* * * * * sleep 30; /usr/local/sbin/bashdays.sh

1. Первая строка запускает скрипт в начале минуты (00:00, 00:01, 00:02…)

2. Вторая строка — ждёт 30 секунд и запускает скрипт (00:00:30, 00:01:30, 00:02:30…).

Тут и получаем шаг в 30 секунд, именно через 2 вызова.

Костыльно? Ага! Но порой не хочется ебаться с таймерами и сделать все по-быстрому. Как вариант, вполне годный. Аналогично можно городить и другие интервалы.

Минусы подхода

⚪ Нет гарантии точности. Если первый запуск скрипта будет работать дольше, чем пауза (sleep), запуски могут наложиться.
⚪ Мусор в crontab. Для мелкого интервала надо плодить много строк.
⚪ Нет гибкой логики.

Где это полезно

⚪ Лёгкие скрипты мониторинга (ping, проверка статуса).
⚪ Хаотизация нагрузки (например, sleep $((RANDOM % 60)) для рассинхрона).
⚪ Если systemd timers или другие планировщики недоступны (например, в ограниченных окружениях или старых системах).

А как работать с таймерами ищи по тегу #systemd, много про это писал.

🛠 #linux #cron #systemd
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

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

Был у меня такой сервис и работал он только тогда, когда все его файлы и каталоги принадлежали определенному пользователю.
ㅤ
Доступ к сервису имели многие, поэтому люди порой троили и запускали команды в каталоге сервиса от root. Сервису было на это поебать, но до момента его перезапуска.

Обычно это чинилось очень легко, через chown -R. Все это знали и никого это не смущало. Короче костыль ебаный.

Казалось бы, есть масса способов предотвратить такие ошибки: правильные права на файлы, ACL’ы, SELinux.

Но веселья в этом мало! Поэтому я решил заебенить свой собственный мониторинг файловой системы. Скиллов то предостаточно, хули нет.

Спойлер: Я залез в кроличью нору и знатно так хлебнул гавна.

Попытка намбер 1

В Linux есть API под названием fanotify, с его помощью можно получать события о действиях с файлами в юзерспейс.

Всё просто: инициализируем fanotify_init, указываем каталоги через fanotify_mark и читаем события из дескриптора.

Но тут же вылез огромный хуй:

- нельзя отслеживать каталоги рекурсивно (только целый маунт)
- anotify даёт только PID процесса, который что-то сделал. А чтобы узнать UID/GID — нужно лезть в /proc/<pid>/status. То есть на каждое событие приходится открывать и парсить файлы в /proc.

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

Попытка намбер 2

Вспоминаем что есть eBPF. Это штука позволяет запускать программы прямо в ядре Linux. Они компилируются в байткод, проходят проверку, а потом гоняются через JIT почти с нативной скоростью.

Что такое eBPF можешь почитать тут и тут.

В eBPF заебись то, что можно цепляться за разные функции ядра. Например, можно подцепиться к vfs_mkdir или vfs_create — это общий слой для работы с файлами.

То есть единая точка входа. Там можно отлавливать события и фильтровать их, не гоняя лишние переключения контекста.

Но и тут вылез хуй:

- kprobes на функции VFS нестабильны, в новых ядрах сигнатуры могут меняться или функции вообще исчезнуть.

- фильтрацию приходится писать прямо в eBPF, а там свои ограничения. Нет бесконечных циклов, стек всего ~512 байт.

Да блядь…

Как я победил рекурсивный обход

Чтобы понять, что именно меняется в каталоге сервиса, пришлось использовать структуру dentry и подниматься по дереву до родителя.

Но так как в eBPF нельзя сделать «бесконечный» цикл, я ограничил глубину с помощью MAX_DEPTH.

На практике этого вполне достаточно. Глубина каталогов мне известна. Ну и конечно, пришлось аккуратно работать с RCU-локами, чтобы дерево не поменялось в момент обхода.

➡️ Кусок кода в первом комментарии, сюда не влез.

Как можно улучшить

В идеале использовать не VFS-хуки, а LSM hooks (Linux Security Module).

Они стабильнее, понятнее и позволяют сразу работать с путями. Там можно красиво получить path и сразу преобразовать его в строку, а потом делать поиск подстроки.

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

Итоги

Эта поделка как и предполагалась, погрузила меня в печаль, душевные страдания, НО стала отличным тренажером для прокачки:

- Внутренностей Linux ядра
- Работы с eBPF
- И кучу другого с kernel-space

eBPF — мощнейший инструмент, но очень тонкий. Ошибёшься — будешь выебан в жопу.

Информации по нему много, но вся она разбросана. Собрать всё это в кучу было отдельным квестом.

Мораль?

Иногда самое простое решение — это chown -R. Но куда интереснее — написать свой велосипед и заглянуть в кроличью нору Linux ядра.

🛠 #linux #debug #dev
—
✅ @bashdays ✅ @linuxfactory ✅ @blog

Настройка core dump в Docker

Цель этого поста — дать тебе общее руководство по включению и сбору core dumps для приложений, работающих в docker контейнере.

Настраиваем хост для сохранения дампов

Для начала надо сконфигурировать хостовую машину, чтобы сохранять такие дампы в нужное место. Нет, не в жопу.
ㅤ
Универсальный способ — задать шаблон core pattern. Шаблон определяет путь и информацию о процессе который наебнулся.

echo '/tmp/core.%e.%p' | sudo tee /proc/sys/kernel/core_pattern

Кратенько:

%e — имя процесса
%p — pid процесса

Более подробно о конфигурации core pattern можешь почитать в man-странице ядра Linux.

Как вариант, можно настроить host изнутри контейнера через CMD или ENTRYPOINT. Но контейнер в этом случае должен запускаться в privileged mode, что хуева с точки зрения безопасности.

Пример хуёвого приложения

#include <cstdlib>
void foo() {
    std::abort();
}

int main() {
    foo();
    return 0;
}

После компиляции и запуска, приложение наебнется с ошибкой.

Пишем Dockerfile для этого приложения

FROM ubuntu:22.04

# Install tools
RUN apt update \
    && apt -y install \
    build-essential \
    gdb \
    && rm -rf /var/lib/apt/lists/*

# Build the application
COPY ./ /src/
WORKDIR /src/
RUN g++ main.cpp -o app

CMD ["/src/app"]

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

Запускаем контейнер с нужными опциями:

docker run \
    --init \
    --ulimit core=-1 \
    --mount type=bind,source=/tmp/,target=/tmp/ \
    application:latest

Разбираем опции:

--init — гарантирует корректную обработку сигналов внутри контейнера

--ulimit — устанавливает неограниченный размер core dump для процессов внутри контейнера

--mount — монтирует /tmp из хоста в контейнер, чтобы дампы, создаваемые внутри контейнера, были доступны после его остановки или удаления

Здесь важно: путь source на хосте должен совпадать с тем, который задан в шаблоне core pattern.

После того как приложение наебнется, core dump будет сохранён на хостовой машине в директории /tmp.

ls /tmp/core*
# /tmp/core.app.5

Анализируем дамп с помощью gdb

Такс, мы получили core dump и он у нас лежит на хостовой машине, но рекомендуется открыть его внутри контейнера. Контейнер должен быть из того же образа, в котором компилилось приложение.

Это поможет убедиться, что все зависимости (библиотеки и прочая хуитень) доступны.

docker run \
    -it \
    --mount type=bind,source=/tmp/,target=/tmp/ \
    application:latest \
    bash

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

docker run \
    -it \
    --mount type=bind,source=/tmp/,target=/tmp/ \
    --mount type=bind,source=<путь_к_исходникам_на_хосте>,target=/src/ \
    application:latest \
    bash

Теперь внутри контейнера запускаем:

gdb app /tmp/core.app.5

После загрузки дампа можно выполнить команду bt (backtrace), чтобы увидеть трассировку стека:

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007f263f378921 in __GI_abort () at abort.c:79
#2  0x000055f9a9d16653 in foo() ()
#3  0x000055f9a9d1665c in main ()

Команда поможет определить, где именно произошел факап.

Давай быстренько разберем ошибку.

#0 и #1 показывают, что процесс получил сигнал 6 (SIGABRT) и завершился через abort()

#2 — вызов произошёл внутри функции foo()

#3 — main() вызвал foo()

В исходнике было:

void foo() {
    std::abort();
}

То есть ошибка здесь не баг компиляции или рантайма, а намеренно вставленный вызов std::abort(), который и приводит к аварийному завершению и генерации core dump.

Если у тебя docker-compose, то все флаги (--init, --ulimit, --mount и т.д.) применимы и для него. То есть отладку можно легко адаптировать.

Хуй знает чё еще написать, завтра тему дебага продолжим, чет в конце года много траблшутинга навалило разнообразного.

🛠 #linux #debug #dev
—
✅ @bashdays ✅ @linuxfactory ✅ @blog