📂 Напоминалка по iptables (netfilter)!

Например, цепочка INPUT обрабатывает пакеты, предназначенные локальной машине, FORWARD — транзитный трафик, а через PREROUTING и POSTROUTING удобно понимать, где выполняется NAT.

На картинке — основные таблицы и цепочки iptables, маршруты входящих, исходящих и транзитных пакетов, а также примеры SSH, DNAT и MASQUERADE.

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

🚪 Linux Ready | #ресурс

📂 Шпаргалка по процессу загрузки Linux!

Например, BIOS/UEFI инициализирует оборудование, загрузчик GRUB запускает ядро, а systemd поднимает системные сервисы и переводит систему в нужный target.

На картинке — основные этапы загрузки: BIOS/UEFI, GRUB, ядро, systemd, уровни загрузки, важные системные файлы, параметры ядра, полезные команды и типичные проблемы при запуске системы.

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

🚪 Linux Ready | #ресурс

Знали, что git diff умеет сравнивать вообще любые файлы и каталоги — даже если они никогда не находились в Git?

Для этого есть малоиспользуемый режим --no-index:

git diff --no-index ./release-old ./release-new

Git рекурсивно сравнит два каталога и покажет привычный цветной diff с именами файлов и изменёнными строками. Репозиторий для этого не нужен.

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

git diff --no-index \
  /tmp/output-before \
  /tmp/output-after

Можно использовать и для отдельных файлов:

git diff --no-index nginx.conf.old nginx.conf.new

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

git diff --no-index old/ new/
echo $?

🔥 Если нужен diff двух произвольных каталогов, возможно, привычный интерфейс Git уже умеет именно то, что нужно.

🚪 Linux Ready | #совет

📂 Напоминалка по модели OSI и передаче данных!

Например, на транспортном уровне данные превращаются в сегменты, на сетевом — в пакеты, а на канальном — во фреймы.

На картинке наглядно показан весь процесс инкапсуляции и деинкапсуляции данных: какие заголовки добавляются на уровнях L4, L3 и L2, где используются IP- и MAC-адреса, порты TCP/UDP и как устроен Ethernet-фрейм.

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

🚪 Linux Ready | #ресурс

😎 Bash-скрипты — подробная шпаргалка по автоматизации задач в Linux!

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

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

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

SSH-туннели: доступ к закрытым сервисам без VPN!

SSH позволяет не только подключаться к удалённым серверам и выполнять команды. Через него можно создавать защищённые туннели и получать доступ к сервисам, которые недоступны извне. Например, PostgreSQL работает только внутри сервера и доступен только локально:

127.0.0.1:5432

Порт базы данных не открыт наружу, но есть SSH-доступ к серверу. Создаём локальный туннель, который принимает соединения на вашем компьютере и передаёт их через SSH:

ssh -L 5433:localhost:5432 user@server

Теперь приложение на локальном компьютере подключается к базе через созданный порт:

psql -h 127.0.0.1 -p 5433 database

При этом PostgreSQL остаётся закрытым для внешнего мира. Доступ к нему появляется только через SSH-туннель.

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

ssh -L 8080:localhost:8080 user@server

После создания туннеля сервис доступен локально:

http://localhost:8080

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

ssh -R 9000:localhost:3000 user@server

Теперь процесс на сервере может обращаться к вашему локальному приложению через:

localhost:9000

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

Если требуется открыть reverse tunnel не только для localhost, нужно изменить настройки SSH-сервера:

GatewayPorts clientspecified
AllowTcpForwarding yes

SSH также может работать как SOCKS5-прокси и направлять поддерживающие приложения через удалённую машину:

ssh -N -D 1080 user@server

После этого в приложении можно указать SOCKS5-прокси:

localhost:1080

Такой вариант используется для диагностики маршрутизации и проверки доступа к ресурсам из другой сети.

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

ssh -fNT -L 5433:localhost:5432 user@server

Параметры команды:

-f  запуск SSH-процесса в фоне
-N  не выполнять команды на удалённой машине
-T  отключить создание псевдотерминала

Проверить, что локальный порт слушается:

ss -tlnp | grep 5433

Или посмотреть процесс, который использует порт:

lsof -i :5433

Чтобы не писать длинные команды каждый раз, туннели можно описать в стандартном конфигурационном файле SSH:

Host production-db
    HostName server.example.com
    User deploy
    LocalForward 5433 localhost:5432

После этого подключение выполняется короткой командой:

ssh production-db

SSH-туннели не заменяют полноценный VPN, так как работают с конкретными портами и TCP-соединениями. Но для точечного доступа к закрытым сервисам это один из самых быстрых и надёжных инструментов.

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

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

В Linux можно удалить файл, но продолжать читать из него или записывать в него данные!

Если процесс уже открыл файл, его можно удалить из каталога:

exec {LOG}>/tmp/debug.log
rm /tmp/debug.log

Имя /tmp/debug.log исчезнет, и открыть файл по этому пути уже нельзя. Но Bash продолжает держать открытый файловый дескриптор, поэтому запись работает:

printf '%s\n' "debug message" >&"$LOG"

Причина в семантике Unix: rm удаляет имя файла из каталога через unlink(), а открытый файловый дескриптор продолжает ссылаться на тот же объект файловой системы.

Пока дескриптор открыт, занятое файлом место также не освобождается. Это объясняет распространённую ситуацию, когда огромный лог уже удалили, ls его не показывает, а свободного места на диске не прибавилось.

Закрываем последний дескриптор:

exec {LOG}>&-

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

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

🔥 В Linux имя файла и открытый файл — не одно и то же. Понимание этой особенности помогает находить утечки дискового пространства и аккуратно работать с временными данными.

🚪 Linux Ready | #совет

Знали, что systemd умеет запускать сервис автоматически при изменении файла?

Многие используют cron или пишут циклы с проверкой времени изменения:

while true; do
  check_file
  sleep 10
done

Но systemd уже имеет встроенный механизм наблюдения за файлами через .path units.

Например, можно следить за конфигурацией:

[Path]
PathChanged=/etc/myapp/config.yml
Unit=myapp-reload.service

Теперь при изменении файла systemd автоматически запустит нужный сервис.

Проверить активные path-наблюдатели:

systemctl list-paths

Запуск и остановка работают так же, как у обычных unit:

systemctl enable --now myapp.path
systemctl stop myapp.path

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

🔥 systemd.path заменяет самописные циклы с sleep и проверки файлов. Вместо опроса система реагирует только тогда, когда изменение действительно произошло.

🚪 Linux Ready | #совет