Как не уничтожить лишнее при массовых операциях?

Любая массовая команда в Linux — это потенциально опасный инструмент.

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

find /data -type f -name "*.log" -print

-print показывает полный список совпадений. Это позволяет увидеть неожиданные вложенные каталоги, лишние расширения или неверный путь.

Когда результат полностью совпадает с ожиданиями, добавляем действие:

find /data -type f -name "*.log" -delete

Если важен контроль и наглядность, лучше использовать -exec:

find /data -type f -name "*.log" -exec rm -v {} +

🔥 rm -v покажет каждый удалённый файл, что особенно полезно в скриптах и при ручной работе в проде.

➡️ DevOps Ready | #совет

❤️ Linux Command Library — большая база команд!

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

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

➡️ DevOps Ready | #сайт

Перенаправление потоков и pipe!

Процесс в Unix обычно имеет три стандартных дескриптора:
0 — stdin, 1 — stdout, 2 — stderr.

Shell не обрабатывает вывод — он до запуска команды переназначает, к каким объектам привязаны дескрипторы (терминал, файл, pipe). Поэтому процесс стартует уже с изменённой таблицей дескрипторов.

Базовый случай — перенаправление stdout в файл:

echo "test" > file.txt

Оператор > открывает файл с перезаписью (truncate). Если нужно дописывать данные в конец, используется >>:

echo "line" >> file.txt

Важно помнить, что > по умолчанию влияет только на stdout (fd 1).
Для stderr используется дескриптор 2:

command 2> error.log

Так можно разделить обычный вывод и ошибки в разные файлы:

command > out.log 2> error.log

Поскольку stdout и stderr — независимые дескрипторы, их можно направить в один файл:

command > all.log 2>&1

2>&1 означает: направить stderr туда же, куда в этот момент направлен stdout.

Редиректы применяются слева направо, поэтому порядок критичен:

command > all.log 2>&1   # оба потока в файл
command 2>&1 > all.log   # stderr останется в терминале

Это именно копирование назначения дескриптора, а не абстрактное объединение потоков.

stdin (fd 0) тоже можно переназначить:

sort < input.txt

В этом случае файл становится источником данных для процесса.

Оператор | создаёт pipe — канал между процессами: stdout левой команды подключается к stdin правой.

grep 500 access.log | wc -l

Через pipe передаётся только stdout. Если нужно передать и stderr, его сначала перенаправляют в stdout:

make 2>&1 | tee build.log

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

exec 3> debug.log
echo "debug info" >&3
exec 3>&-

В этом контексте exec изменяет дескрипторы текущего shell-процесса, позволяя организовать отдельные каналы вывода.

🔥 Основные принципы просты: редиректы настраиваются до запуска, применяются слева направо; 2>&1 копирует stdout, pipe соединяет stdout одной команды со stdin другой.

➡️ DevOps Ready | #практика

📂 SSH Remote Port Forwarding — краткая памятка!

Например, ssh -R используется для публикации локальных сервисов через удалённый SSH-сервер.

На изображении показано: базовый синтаксис ssh -R, отличие short и long form, маршрут трафика через SSH-туннель, влияние параметра GatewayPorts на стороне сервера

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

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

Изоляция процессов в Linux через Unshare без Docker и тяжелых утилит!

Мы научимся использовать системный вызов unshare для создания изолированного пространства имен (namespaces), что является фундаментом контейнеризации в Linux.

Это позволяет запустить процесс с собственной таблицей хостов или файловой системой, не влияя на основную ОС.

Сначала создадим изолированную среду с собственной сетевой петлей и новым пространством имен для имени хоста:

sudo unshare --fork --uts --net bash

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

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

hostname sandbox-env && hostname

Имя хоста изменится только для этой сессии, в то время как основная система сохранит прежнее название.

Для полной демонстрации сетевой изоляции попробуем поднять интерфейс, который будет существовать только в этом пространстве:

ip link set lo up && ip addr show lo

Внутри этого пространства вы увидите чистый сетевой стек, полностью отделенный от физических интерфейсов сервера.

Проверка работоспособности:

hostname

Ожидаемый вывод: ваше старое имя хоста (подтверждает, что изоляция работает).

🔥 Помните, что для некоторых флагов изоляции (например, монтирования) требуются права суперпользователя или настройка User Namespaces.

➡️ DevOps Ready | #практика

❤️ KodeKloud Labs — онлайн-лаборатории для практика DevOps!

Это интерактивная площадка, где можно тренироваться в Linux, Docker, Kubernetes, Git, Terraform и других DevOps-инструментах прямо в браузере. Вместо теории, готовые лабораторные среды с задачами: запускаешь окружение, выполняешь команды, настраиваешь сервисы. Отличный вариант, если хочешь попрактиковаться без установки инструментов.

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

➡️ DevOps Ready | #сайт

❤️ PayloadsAllTheThings — список информации об обходе безопасности веб-приложений и пентестингу/захвату флага!

В репозитории собраны готовые строки и техники для эксплуатации веб-уязвимостей: XSS, SQL Injection, SSRF, RCE, XXE, CSRF, обходы WAF, повышение привилегий и десятки других сценариев атак. Всё удобно структурировано по типам уязвимостей и дополнено методологиями, примерами эксплуатации и файлами для автоматизированного тестирования.

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

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

Разбираемся с поиском файлов по содержимому!

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

Рекурсивный поиск в текущей папке:

grep -r "search_text" .

Команда пройдёт по всем подпапкам и покажет совпадения с именем файла и строкой.

-r — ищет рекурсивно, не заходя в символические ссылки;
-R — тоже рекурсивно, но идёт по symlink’ам, поэтому можно случайно улететь в лишние каталоги или циклы;

Показать только файлы, где есть совпадения:

grep -rl "search_text" .

Выведет просто список файлов без самих строк.

Без учёта регистра:

grep -ril "search_text" .

Найдёт и Text, и TEXT, и text.

Искать только в файлах нужного типа:

grep -r --include="*.conf" "search_text" /etc

Полезно, когда знаешь, что нужное лежит, например, только в конфигах.

Исключить лишние системные каталоги:

grep -r --exclude-dir=proc --exclude-dir=sys --exclude-dir=dev --exclude-dir=run "search_text" /

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

Если раздражают ошибки доступа — можно добавить в конец:

2>/dev/null

Поиск по имени файла + содержимому (через find):

find /var/www -type f -name "*.php" -exec grep -nH "search_text" {} +

Сначала выбираются нужные файлы, потом проверяется их содержимое.

-H — показывает имя файла
-n — номер строки
{} + — обрабатывает файлы пачками (обычно быстрее)

Вариант через xargs:

find /var/www -type f -name "*.php" -print0 | xargs -0 grep -nH "search_text"

Нормально работает с пробелами в именах файлов и тоже быстрый на больших объёмах.

🔥 Эти приёмы позволяют быстро находить конфиги, секреты в тестовых средах, точки использования API и любые текстовые данные в системе или проекте.

➡️ DevOps Ready | #практика

Прямое сетевое соединение из Bash без сетевых утилит!

В bash есть возможность открывать TCP/UDP-соединения через путь /dev/tcp/host/port. Это не реальный файл, а спец-путь, который интерпретируется самим bash (сетевые редиректы).

Открываем сокет к серверу и получаем файловый дескриптор:

exec 3<>/dev/tcp/example.com/80

Теперь можно отправлять данные напрямую, как в обычный файл:

printf "GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n" >&3

И читать ответ сервера без curl, nc и telnet (чтение завершится, когда сервер закроет соединение):

cat <&3

Работает именно в bash (не в sh/dash/busybox ash) и при включённой поддержке сетевых редиректов.

🔥 Это удобно на урезанных системах, контейнерах и rescue-окружениях, где нет сетевых утилит, но есть bash.

➡️ DevOps Ready | #совет

📂 Напоминалка по 8 популярным сетевым протоколам!

Например, HTTP работает по request-response, TCP через SYN-ACK handshake, а UDP — без подтверждений, идеально для видео.

На картинке — таблица с принципами работы (handshake, шифрование, каналы) и примерами: веб-сёрфинг (HTTP/HTTPS), чаты (WebSocket), файлы (FTP), почта (SMTP).
Сохрани, чтобы не забыть!

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

Использование магических ссылок /proc для восстановления удаленных файлов в Linux!

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

Это фундаментальный принцип Linux «все есть файл», позволяющий вернуть данные через файловую систему процессов /proc.

Для начала создадим файл, запустим процесс, который его читает, и имитируем удаление данных злоумышленником:

echo "секретные данные" > secret.log
tail -f secret.log > /dev/null &
# Запоминаем PID последнего процесса и удаляем файл
PID=$!; rm secret.log

Файл исчез из списка ls, но данные все еще доступны через дескрипторы активного процесса.

Теперь ищем дескриптор удаленного файла в директории fd процесса:

ls -l /proc/$PID/fd | grep "deleted"

В выводе вы увидите номер (например, 3), указывающий на призрачную ссылку удаленного файла.

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

cp /proc/$PID/fd/3 restored_secret.log

Файл успешно восстановлен в текущую директорию из оперативной памяти.

Проверка работоспособности:

cat restored_secret.log && ls -l restored_secret.log

Ожидаемый вывод: секретные данные (и информация о новом файле).

🔥 При анализе взломанных систем всегда проверяйте /proc перед перезагрузкой — это ваш лучший шанс найти удаленные улики.

➡️ DevOps Ready | #практика

😎 Linux Insides — подробное руководство по внутреннему устройству ядра!

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

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

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

Параллельный запуск обычных команд без GNU Parallel!

Многие задачи в Linux можно ускорить в разы, задействовав несколько ядер CPU.

Ключ — опция -P у xargs, которая запускает несколько процессов одновременно (это именно многопроцессность, не потоки).

Например, выполнить задачи параллельно:

P=$(nproc)
seq "$P" | xargs -P"$P" -I{} ./task.sh {}

Здесь одновременно работают до P копий скрипта (обычно по числу доступных CPU).

Отлично подходит для тяжёлых операций над файлами:

find . -maxdepth 1 -name "*.log" -print0 | xargs -0 -P4 -I{} gzip "{}"

Файлы сжимаются параллельно, а не по одному. Использование -print0 / -0 безопасно для имён с пробелами и спецсимволами.

Можно комбинировать с find для массовой обработки каталогов:

find . -name "*.jpg" -print0 | xargs -0 -P6 -I{} convert "{}" -resize 50% "resized/{}"

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

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

➡️ DevOps Ready | #совет

☕️ Kubernetes Goat — интерактивная обучающая среда по безопасности!

Здесь можно отрабатывать сценарии взлома контейнеров, обход прав доступа, атаки на кластер, утечки данных и другие типичные проблемы облачной инфраструктуры. Проект подходит как для специалистов по безопасности, так и для разработчиков и DevOps-инженеров, чтобы понимать, как защищать систему на практике.

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

➡️ DevOps Ready | #сайт

Диагностируем процессы в Linux через strace!

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

Запускаем программу под трассировкой:

strace ls /tmp

Сразу видно, какие файлы открываются, какие библиотеки грузятся, где возникают ошибки.

Можно прицепиться к уже работающему процессу — удобно, если сервис завис:

sudo strace -p <PID>

Обычно быстро становится понятно, где он застрял: futex (блокировка), ожидание I/O (poll/epoll_wait), connect, чтение/запись и т.п.

Если программа создаёт дочерние процессы, без этого ключа часть событий не попадёт в вывод:

strace -f <command>

Проблемы с файлами, конфигами и правами:

strace -e trace=%file <command>

Покажет open/stat/access и другие файловые операции — удобно понять, какие пути реально проверяются.

Частый кейс — программа ищет файл, которого нет:

strace -e trace=%file <command> 2>&1 | grep ENOENT

Сразу видно, какой путь оказался отсутствующим.

Для сетевых проблем:

strace -e trace=%network <command>

Видно создание сокетов, попытки подключения и ошибки.

Если нужно сохранить вывод:

strace -o trace.log <command>

С дочерними процессами лучше так:

strace -ff -o trace.log <command>

Будут отдельные файлы по PID.

Иногда вывод обрезает длинные строки — увеличиваем лимит:

strace -s 200 <command>

Посмотреть, где именно тратится время:

strace -T <command>

Короткая сводка по системным вызовам:

strace -c <command>

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

➡️ DevOps Ready | #практика

📂 Напоминалка по архитектуре Linux!

Например, ядро управляет процессами, памятью, устройствами, сетью и файловыми системами — именно эти подсистемы обеспечивают работу всей операционной системы.

На картинке — 5 основных компонентов ядра, которые важно понимать разработчикам, DevOps-инженерам и системным администраторам.

Сохрани, чтобы держать базовую архитектуру Linux под рукой!

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