📂 Напоминалка по Pipes в Linux!

Pipes позволяют процессам обмениваться данными напрямую: вывод одной программы становится входом для другой. Именно благодаря этому работают привычные конвейеры команд через символ |.

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

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

➡️ DevOps Ready | #ресурс

🐱 Большая Linux-шпаргалка для разработчиков!

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

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

➡️ DevOps Ready | #репозиторий

Слышали, что tail умеет автоматически завершаться вместе с процессом, за которым вы наблюдаете?

Обычно при просмотре логов через tail -f возникает мелкая проблема. Процесс уже завершился, а tail продолжает висеть в терминале и его приходится останавливать вручную.

Решение встроено в GNU tail:

$ command > /tmp/out.log 2>&1 &

Команда запускается в фоне, а $! содержит PID последнего background-процесса.

Теперь можно привязать tail к этому процессу:

$ tail --pid=$! -f /tmp/out.log

tail будет следить за логом в реальном времени, но как только процесс завершится — завершится и сам.

Это удобно при сборке проектов, деплое, миграциях, тестах и long-running задачах, когда нужен live output ровно до окончания выполнения.

🔥 С --pid терминал освобождается автоматически в нужный момент.

🚪 Linux Ready | #совет

✍️ Шпаргалка по Linux-командам — полезный справочник для работы с Linux!

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

📌 Оставляю ссылочку: wiki.planetahost.ru

➡️ DevOps Ready | #сайт

Как защитить сессионные куки боевого сервера от утечки через уязвимости на тестовых стендах?

Разработчики часто разворачивают dev- и staging-окружения на путях вроде example.com/dev, используя общие куки с флагом Domain=.example.com. В таком сценарии XSS-атака или взлом слабо защищенного dev-стенда позволяет хакеру мгновенно перехватить сессию администратора от основного prod-сервера.

Разделение окружений на изолированные поддомены полностью блокирует этот вектор на уровне браузера.

Пример уязвимой конфигурации, при которой куки улетают на все поддомены и окружения:

$ # НЕПРАВИЛЬНО: кука доступна для dev.example.com и prod.example.com
$ Set-Cookie: session=secret; Domain=.example.com; Path=/

Правильная изоляция сессии, при которой браузер отдаст куку только конкретному хосту:

$ # ПРАВИЛЬНО: жесткая привязка сессии к боевому домену
$ Set-Cookie: session=secret; Domain=prod.example.com; Path=/; SameSite=Strict

🔥 Важно: если вы опустите атрибут Domain вовсе, браузер по умолчанию привяжет куку строго к текущему хосту (Host-only cookie), что является самой безопасной практикой.

➡️ Hacking Ready | #совет

📂 Напоминалка по стилям API-архитектуры!

Например, REST подходит для классических CRUD-операций, WebSocket — для приложений с обменом данными в реальном времени, GraphQL позволяет получать только нужные данные, а gRPC обеспечивает быстрый обмен между сервисами.

На картинке — 6 популярных архитектурных стилей и протоколов API, которые стоит знать каждому разработчику.

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

➡️ DevOps Ready | #ресурс

Диагностика проблем с DNS в Linux!

Многие сетевые проблемы на Linux-серверах оказываются связаны не с firewall, маршрутизацией или приложением, а именно с DNS. Симптомы обычно такие: curl зависает, пакетный менеджер не работает, API недоступен по домену, но по IP всё открывается.

В таких случаях сначала стоит проверить, как система резолвит DNS. Первое, что нужно посмотреть — какие DNS-серверы используются системой.

cat /etc/resolv.conf

В классических системах этого достаточно. Но в современных дистрибутивах с systemd-resolved файл часто указывает только на локальный stub-resolver.

nameserver 127.0.0.53

Если используется systemd-resolved, реальные DNS лучше смотреть так:

resolvectl status

Команда показывает активные DNS-серверы для интерфейсов и текущее состояние resolver’а.

Дальше стоит проверить, как система реально разрешает имя.

getent hosts google.com

Это полезнее, чем кажется. В отличие от dig и nslookup, getent использует системный механизм разрешения имён и ближе к тому, как работают реальные приложения. Если getent не работает, а dig работает — проблема обычно в локальной конфигурации.

Чтобы исключить сам DNS-сервер, полезно сделать прямой запрос.

dig google.com @8.8.8.8

Или через Cloudflare:

dig google.com @1.1.1.1

Так быстро становится понятно, проблема локальная или внешняя.

Даже если DNS отвечает, стоит посмотреть время ответа.

dig google.com

Смотри на строку:

;; Query time: X msec

Если нужно проверить весь путь разрешения, помогает trace.

dig +trace google.com

Также бывает полезно проверить reverse DNS.

dig -x 8.8.8.8

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

Если используется systemd-resolved, можно очистить локальный кэш.

sudo resolvectl flush-caches

А затем посмотреть статистику.

resolvectl statistics

Если приложение жалуется на DNS, но dig работает корректно, стоит проверить NSS.

cat /etc/nsswitch.conf

Особенно строку hosts, потому что она определяет порядок источников разрешения имён.

Для финальной диагностики полезно посмотреть DNS-трафик в реальном времени.

sudo tcpdump -ni any port 53

🔥 Вывод: хорошая DNS-диагностика обычно начинается с трёх вещей: проверки системного resolver’а, прямых запросов к DNS-серверам и анализа сетевого трафика. Такой подход позволяет найти большинство DNS-проблем намного быстрее, чем полный разбор всей сетевой подсистемы.

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

Разбираемся с диагностикой утечек дискового пространства!

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

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

Базовая проверка состояния диска:

df -h

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

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

du -xhd1 /var

-x важен: он ограничивает обход текущей файловой системой и исключает мусор с других mount points.

Если df показывает занято много, а du — нет, почти всегда это либо удалённые открытые файлы, либо редкие случаи с скрытыми mount/overlay слоями (контейнеры тоже сюда попадают).

Поиск удалённых файлов, удерживаемых процессами:

sudo lsof +L1

Здесь важный момент — +L1 означает link count < 1, то есть файл уже удалён, но ещё открыт процессом.

Типичный пример:

COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NLINK NAME
java     1234 app   45w   REG  8,1    12G     0    /var/log/app.log (deleted)

Файл исчез из каталога, но процесс продолжает писать в него. На практике это часто логи или временные буферы.

Быстро отфильтровать только проблемные записи:

sudo lsof +L1 | grep deleted

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

Посмотреть открытые дескрипторы процесса:

ls -l /proc/PID/fd

Каждый файл там — это активный файловый дескриптор. Если среди них есть (deleted), это и есть удерживаемое место.

Приближённая оценка объёма:

sudo lsof +L1 | awk '{print $7}' | grep -E '^[0-9]+$' | awk '{sum+=$1} END {print sum/1024/1024/1024 " GB"}'

Честно говоря, это грубая оценка. SIZE/OFF не всегда чистый байтовый формат, поэтому цифра больше для ориентира, чем для точного аудита.

Как освобождается место: самый нормальный вариант — дать процессу корректно закрыть файл:

sudo systemctl restart service_name

Если это сервис с поддержкой переоткрытия логов:

kill -HUP PID

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

Если df показывает заполнение, а du не объясняет куда делось место — первым делом проверяются открытые удалённые файлы через lsof +L1. Это один из самых быстрых способов найти невидимую утечку диска в Linux-системах.

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

Любую уже запущенную команду можно отправить в background, даже если забыли поставить &!

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

Большинство в такой ситуации останавливают процесс и запускают всё заново с &.

На самом деле это не нужно.

Если команда уже работает в foreground:

$ sleep 1000

Нажмите:

Ctrl + Z

Shell отправит процессу сигнал SIGTSTP и временно остановит выполнение.

Теперь достаточно выполнить:

$ bg

Процесс продолжит работу уже в background, а терминал снова станет свободным.

Проверить список фоновых задач можно так:

$ jobs

Если позже нужно вернуть процесс обратно в foreground:

$ fg

🔥 Полезный встроенный механизм job control в Bash. Он особенно выручает при долгих командах, когда перезапуск означает потерю времени или состояния.

🚪 Linux Ready | #совет

Знали, почему большинство пользователи Linux почти всегда используют find вместе с -print0?

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

Чтобы исключить эту проблему, find умеет разделять имена файлов нулевым байтом:

$ find . -type f -print0

Теперь этот поток можно безопасно передать в xargs:

$ find . -type f -print0 | xargs -0 sha256sum

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

Тот же приём подходит для удаления файлов:

$ find . -type f -print0 | xargs -0 rm

И для передачи файлов любой другой программе:

$ find . -type f -print0 | xargs -0 grep "TODO"

Именно связка -print0 и -0 считается стандартным способом безопасной обработки имён файлов в Unix-подобных системах.

🔥 Если пишете shell-сценарии или автоматизацию, этот приём избавляет от целого класса трудноуловимых ошибок.

🚪 Linux Ready | #совет

👍 Devhints — шпаргалки по Linux, Bash и терминальным утилитам!

На сайте собрана большая база компактных шпаргалок, среди которых есть полезные справочники по Linux, Bash, SSH, systemd, Vim, Tmux, Docker, Git, Regex и другим инструментам. Основные команды, параметры и примеры использования собраны максимально компактно, поэтому нужную информацию можно найти буквально за несколько секунд.

📌 Оставляю ссылочку: devhints.io

🚪 Linux Ready | #сайт

Сборка мультизагрузочного Live-USB накопителя для аварийного аудита и восстановления.

В арсенале любого специалиста по безопасности должен быть портативный инструмент для оперативного восстановления систем, сброса паролей и анализа цифровых следов. Мы соберем собственный тревожный Live-USB накопитель с помощью утилиты Ventoy, которая позволяет загружать любые ISO-образы простым копированием без форматирования флешки. Это превратит обычный USB-диск в универсальный швейцарский нож, готовый к запуску Kali Linux, Tails или системных реаниматоров на любом железе.

Для начала установим консольную утилиту Ventoy в операционную систему Linux для разметки флешки.

wget https://github.com/ventoy/Ventoy/releases/download/v1.0.99/ventoy-1.0.99-linux.tar.gz && tar -xvf ventoy-1.0.99-linux.tar.gz

Архив успешно скачан и распакован в текущую рабочую директорию.

Выполним разметку и установку загрузчика Ventoy на ваш USB-накопитель (например, /dev/sdX).

cd ventoy-1.0.99 && sudo ./Ventoy2Disk.sh -i /dev/sdX

Накопитель будет разбит на два раздела: скрытый с загрузчиком и основной под ISO-образы.

Смонтируем флешку и скопируем необходимые дистрибутивы для аудита и пентеста напрямую в корень накопителя.

sudo mount /dev/sdX1 /mnt && cp kali-linux-live.iso tails-amd64.iso /mnt/

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

Контрольный просмотр содержимого готового накопителя:

ls -la /mnt/*.iso

Ожидаемый вывод: /mnt/kali-linux-live.iso /mnt/tails-amd64.iso

Безопасное размонтирование флешки перед извлечением:

sudo umount /mnt

Созданный таким образом Live-USB накопитель позволяет на лету докидывать новые инструменты, скрипты и образы без перезаписи всей флешки. Держите на ней Kali для сетевого пентеста, Tails для анонимной работы и чистый дистрибутив Linux для сброса забытых локальных паролей через chroot.

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

❤️‍🔥"Это разъ*бный сетап, бро!" 😤

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

Когда я услышал, что до 10% смертности связано с сидячим образом жизни, меня это поразило и я задался целью делать максимально функциональные и полезные рабочие пространства, ибо геморрой в 30 это конечно довольно нишево, но все же сомнительно 😂

Ну а собрать такой комплект под свои задачи и при этом сразу прикинуть цены вы можете в удобном Mini App конструкторе ➕