🧐 Base of Knowledge — большая русскоязычная коллекция заметок, шпаргалок и руководств!

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

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий

🤔 Крутая статья попалась на Хабре: «Как ускорить дисковую подсистему с помощью bcachefs»!

В этой статье:
• Узнаете, как объединить быстрый SSD и медленный диск с помощью кэширования в bcachefs;
• Разберёте настройку Write Back и проверку производительности через fio;
• Посмотрите на реальные тесты RocksDB, где кэширование ускорило запись в 3,75 раза, а случайное чтение — в 7,74 раза.

🔊 Продолжай читать на Habr!

🚪 Linux Ready | #статья

Как запустить процесс в отдельном сетевом пространстве Linux?

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

В линукс для этого предусмотрены network namespaces. Каждый такой namespace имеет собственные сетевые интерфейсы, таблицы маршрутизации, сокеты и ряд других сетевых настроек.

Создадим отдельное сетевое пространство:

sudo ip netns add isolated

Проверим список:

ip netns list

В выводе появится:

isolated

Теперь посмотрим сетевые интерфейсы внутри нового namespace:

sudo ip netns exec isolated ip addr

По умолчанию в нём будет только интерфейс lo, который изначально находится в состоянии DOWN.

Включим loopback:

sudo ip netns exec isolated ip link set lo up

После этого проверим его адрес:

sudo ip netns exec isolated ip addr show lo

На интерфейсе обычно уже назначен стандартный адрес 127.0.0.1/8. Включение lo позволяет использовать его для локального сетевого взаимодействия.

Попробуем выполнить запрос во внешнюю сеть:

sudo ip netns exec isolated \
  ping -c 3 1.1.1.1

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

Теперь запустим внутри namespace простой HTTP-сервер. Чтобы не раздавать файлы текущего каталога, создадим отдельный пустой каталог:

mkdir -p /tmp/netns-http

Запустим сервер:

sudo ip netns exec isolated \
  python3 -m http.server 8080 \
  --bind 127.0.0.1 \
  --directory /tmp/netns-http

В другом терминале проверим, что сервер отвечает:

sudo ip netns exec isolated \
  curl -i http://127.0.0.1:8080

Сервер вернёт HTTP-ответ, поскольку клиент и сервер используют одно сетевое пространство. Для пустого каталога это будет страница со списком файлов.

Но если выполнить аналогичный запрос из основной системы:

curl http://127.0.0.1:8080

Подключиться к серверу внутри isolated не получится, если в основном namespace нет собственного listener на этом адресе и порту. Причина в том, что loopback-интерфейсы разных network namespaces независимы друг от друга.

Это позволяет запускать приложения на одинаковых адресах и портах без конфликтов между сетевыми пространствами. Проверим прослушивающие TCP-порты внутри namespace:

sudo ip netns exec isolated ss -tlnp

В выводе будет присутствовать HTTP-сервер, прослушивающий 127.0.0.1:8080.

При этом обычная команда в основной системе:

sudo ss -tlnp

Не покажет этот listener, поскольку ss просматривает сокеты текущего сетевого пространства.

Посмотрим процессы, использующие созданный namespace как основное сетевое пространство:

sudo ip netns pids isolated

Команда выведет их PID, включая процесс HTTP-сервера.

Также можно проверить сетевое пространство конкретного процесса. Подставим PID сервера из предыдущего вывода:

sudo readlink /proc/<PID>/ns/net

В результате получим идентификатор вида:

net:[4026532456]

Число в квадратных скобках идентифицирует объект namespace. У процессов в одном network namespace ссылки /proc/<PID>/ns/net указывают на один и тот же объект.

Для удаления окружения сначала остановим HTTP-сервер через Ctrl+C, затем удалим namespace:

sudo ip netns del isolated

🔥 Удаление имени namespace не завершает автоматически процессы, которые его используют. Само сетевое пространство сохраняется, пока на него существуют ссылки.

🚪 Linux Ready | #практика

В Linux можно диагностировать загрузку динамических библиотек ещё до запуска самой программы!

Если приложение падает с ошибкой cannot open shared object file, проблема часто не в отсутствии библиотеки, а в том, где именно загрузчик её ищет.

У динамического загрузчика Linux есть собственные диагностические возможности:

LD_DEBUG=libs ./myapp

Команда покажет поиск библиотек по каталогам, включая пути из RPATH, RUNPATH, переменных окружения и системных настроек.

А если нужно проверить зависимости без запуска main(), можно вызвать загрузчик напрямую:

/lib64/ld-linux-x86-64.so.2 --list ./myapp

Он покажет, какие зависимости удалось разрешить и какие файлы библиотек будут использованы.

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

# Посмотреть диагностические данные загрузчика
/lib64/ld-linux-x86-64.so.2 --list-diagnostics ./myapp

Последняя возможность доступна в glibc начиная с версии 2.33. Путь к загрузчику зависит от архитектуры и дистрибутива, а диагностика LD_DEBUG может быть ограничена для защищённых исполняемых файлов.

🔥 В следующий раз, когда приложение не найдёт .so, не спешите создавать симлинки и менять LD_LIBRARY_PATH. Сначала посмотрите, где загрузчик ищет библиотеку.

🚪 Linux Ready | #совет

📂 Шпаргалка по протоколу NTP!

Например, NTP позволяет синхронизировать системное время компьютеров и серверов, а временные метки T1–T4 помогают рассчитать сетевую задержку и смещение часов.

На картинке — принцип работы NTP, основные формулы, режимы синхронизации и иерархия NTP-серверов.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

В Linux можно найти процессы, использующие конкретный порт или файл, без просмотра полного списка открытых дескрипторов!

Для этого есть fuser из пакета psmisc. Он удобен, когда сервис не запускается из-за занятого порта:

sudo fuser -v -n tcp 8080

Команда покажет процессы, связанные с TCP-портом 8080. А если нужно узнать, кто использует файл или каталог:

sudo fuser -v /var/log/myapp.log

Есть и более интересный сценарий: выяснить, какие процессы мешают размонтировать файловую систему:

sudo fuser -vm /mnt/data

Здесь -m ищет процессы, использующие файлы на той же файловой системе, что и указанный путь. Это полезно при ошибке target is busy.

🔥 fuser позволяет быстро перейти от проблемного ресурса к процессу, который его использует. Что полезно при отладке занятых портов и размонтировании файловых систем.

🚪 Linux Ready | #совет

В Linux можно передать уже открытый сетевой сокет другому процессу без повторного открытия порта!

Этот механизм называется socket activation. Его поддерживает systemd: он сам открывает порт и передаёт готовый файловый дескриптор запускаемому сервису.

Например, можно создать сокет для приложения:

# /etc/systemd/system/myapp.socket
[Socket]
ListenStream=8080

[Install]
WantedBy=sockets.target

После включения сокета systemd начинает слушать порт, даже если приложение ещё не запущено:

sudo systemctl daemon-reload
sudo systemctl enable --now myapp.socket

Когда приходит подключение, ядро ставит его в очередь, а systemd запускает myapp.service и передаёт ему слушающий сокет. Для работы нужен соответствующий unit-файл и приложение с поддержкой socket activation (например, через LISTEN_FDS). Обычный сервер, самостоятельно вызывающий bind(), без адаптации не подойдёт.

Проверить состояние можно так:

systemctl status myapp.socket
systemctl list-sockets

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

🔥 Socket activation позволяет отделить владение сетевым портом от жизненного цикла приложения. Полезно для сервисов с редкими запросами, запуска по требованию и сокращения перерывов при перезапуске.

🚪 Linux Ready | #совет

✍️ linux-book — большое руководство по Linux на русском языке!

В репозитории собраны материалы по работе с командной строкой, файловой системой, процессами, пользователями, правами доступа, сетями и администрированию системы. Здесь есть не только объяснения основных принципов Linux, но и примеры команд, настройки и практические рекомендации, к которым удобно возвращаться во время работы.

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий

Как диагностировать проблемы с MTU и Path MTU Discovery в линукс?

TCP-соединение установилось, мелкие пакеты проходят, а передача данных зависает? Возможно, поймали PMTU black hole: крупные пакеты с DF отбрасываются, а ICMP Fragmentation Needed не доходит до отправителя. Такое встречается с VPN, GRE и VXLAN.

Начнём с MTU интерфейса:

ip -d link show dev eth0

Например:

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

Но MTU 1500 на интерфейсе ещё не означает, что пакеты такого размера пройдут весь маршрут.

Проверим маршрут:

ip -4 route get 203.0.113.10

Теперь отправим IPv4-пакет размером 1500 байт с запретом фрагментации:

ping -4 -M do -s 1472 -c 3 203.0.113.10

Размер: 1472 байта данных + 8 байт ICMP + 20 байт IPv4. Если пакет не проходит, попробуем 1400 байт:

ping -4 -M do -s 1372 -c 3 203.0.113.10

Если меньшие пакеты проходят, а большие нет — есть повод проверить Path MTU.

Отсутствие ответа на ping ещё не доказывает проблему с MTU. Кроме того, -M do учитывает уже известный ядру PMTU. Для проверки в обход этого ограничения можно использовать:

sudo ping -4 -M probe -s 1472 -c 3 203.0.113.10

Для дополнительной диагностики запустим:

tracepath -n 203.0.113.10

Утилита может показать обнаруженное ограничение:

pmtu 1400

Результат зависит от прохождения ICMP. В Debian/Ubuntu tracepath доступен в пакете iputils-tracepath.

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

ip -4 route get 203.0.113.10

Если информация сохранена, вывод может содержать:

cache expires 420sec mtu 1400

Для действующего TCP-соединения проверим MSS и PMTU:

ss -tin dst 203.0.113.10

Например:

mss:1360 pmtu:1400

При стандартных 20-байтных заголовках IPv4 и TCP получаем MSS 1360. Фактические значения могут отличаться.

В линукс есть и встроенный механизм TCP MTU probing, который помогает при проблемах с определением MTU. Проверим его состояние:

sysctl net.ipv4.tcp_mtu_probing

Возможные значения:

0 — отключён
1 — включается при обнаружении проблемы
2 — включён постоянно

Сохраним исходное значение и временно включим механизм:

original=$(sysctl -n net.ipv4.tcp_mtu_probing)
sudo sysctl -w net.ipv4.tcp_mtu_probing=1

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

Вернём исходное значение:

sudo sysctl -w net.ipv4.tcp_mtu_probing="$original"

Механизм работает только для TCP в соответствующем сетевом пространстве имён и не заменяет правильную настройку MTU туннелей. Все проверки рассчитаны на IPv4. В IPv6 для обнаружения ограничений используется ICMPv6 Packet Too Big.

Адрес 203.0.113.10 приведён для примера. Замените его на адрес доступного узла, где воспроизводится проблема, а eth0 — на свой интерфейс.

🔥 PMTU black hole — одна из причин, почему TCP-соединение есть, а нормальной передачи данных нет. Проверка DF-пакетов, tracepath, PMTU и MSS помогает найти ограничение на маршруте, особенно в сетях с VPN и туннелями.

🚪 Linux Ready | #практика

❤️ Необычная и крайне интересная статья на Хабре: «Пустили ботов по SSH на фейковый сервер с четырьмя H100: что они там делали»!

В этой статье:
• Узнаете, как с помощью Python и Cowrie создать SSH-ловушку, имитирующую мощный сервер с четырьмя NVIDIA H100;
• Посмотрите, что делали атакующие боты после входа: меняли пароли, добавляли SSH-ключи и пытались установить майнеры;
• Разберёте результаты первых 12,5 часов эксперимента — 1 846 подключений и более 1 500 команд — и способы защиты SSH от подобных атак.

🔊 Продолжай читать на Habr!

🚪 Linux Ready | #статья

В Git можно переносить незавершённые изменения между проектами или рабочими деревьями без коммитов и копирования файлов вручную!

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

git diff > changes.patch

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

Перед применением полезно проверить, получится ли внести изменения:

git apply --check changes.patch

Если проверка прошла успешно, применяем:

git apply changes.patch

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

git diff HEAD > changes.patch

Важно: новые неотслеживаемые файлы в такой патч автоматически не попадут.

🔥 git diff вместе с git apply — удобный способ переносить локальные правки между рабочими деревьями, тестовыми окружениями и копиями проекта без промежуточных коммитов.

🚪 Linux Ready | #совет

Почему линукс может показывать разные файлы по одному и тому же пути?

В линукс два процесса могут обращаться к /tmp, /etc или /var, но фактически видеть разные файловые системы. Причём для этого необязательно использовать docker или полноценный контейнер.

Такое поведение обеспечивает механизм mount namespaces, позволяющий изолировать таблицу монтирования отдельных процессов.

Проверим на практике. Сначала создадим тестовый каталог:

sudo mkdir -p /mnt/ns-test
echo "original" | sudo tee /mnt/ns-test/file

Теперь запустим отдельное пространство имён монтирования:

sudo unshare --mount --propagation private /bin/bash

Внутри новой оболочки смонтируем tmpfs поверх существующего каталога:

mount -t tmpfs tmpfs /mnt/ns-test
echo "isolated" > /mnt/ns-test/file
cat /mnt/ns-test/file

Результат:

isolated

Откроем второй терминал и выполним:

cat /mnt/ns-test/file

Здесь результат будет другим:

original

Оба процесса используют одинаковый абсолютный путь, но обращаются к разным объектам файловой системы.

Посмотреть пространства имён процессов можно через:

readlink /proc/self/ns/mnt

А для конкретного процесса:

readlink /proc/PID/ns/mnt

Если идентификаторы отличаются, процессы находятся в разных mount namespaces. Однако это ещё не означает, что их таблицы монтирования обязательно различаются.

Посмотреть реальные точки монтирования процесса:

cat /proc/PID/mountinfo

Можно также войти в существующее пространство имен другого процесса:

sudo nsenter --target PID --mount -- /bin/bash

После этого новая оболочка будет использовать его mount namespace. Именно этот механизм применяется в контейнерах и при изоляции сервисов systemd. Например, параметр PrivateTmp=yes позволяет сервису получить отдельные пространства для временных файлов в /tmp и /var/tmp.

Поэтому файл, созданный сервисом в /tmp, может быть недоступен по тому же пути из обычной пользовательской оболочки. После эксперимента выйдем из изолированной оболочки командой exit и удалим тестовый каталог:

sudo rm -rf /mnt/ns-test

🔥 Абсолютный путь в линукс не гарантирует обращение к одному и тому же файлу. При диагностике контейнеров и systemd-сервисов проверяйте не только путь, но и mount namespace процесса. Особенно если приложение видит файл, который отсутствует на хосте, или наоборот.

🚪 Linux Ready | #практика