Linux Ready | DevOps

Слышали, что в Linux можно изменить конфигурацию systemd-сервиса без изменения оригинального unit-файла?

Многие редактируют файлы внутри /usr/lib/systemd/system или /lib/systemd/system, но после обновления пакета такие изменения могут быть потеряны.

Systemd поддерживает drop-in конфигурации:

$ sudo systemctl edit nginx

Откроется отдельный файл переопределения конфигурации, который имеет приоритет над оригинальной конфигурацией.

Например, можно изменить параметры запуска:

[Service]
Restart=always
RestartSec=5

После сохранения systemd автоматически создаст отдельное переопределение.

Проверить итоговую конфигурацию, которую реально использует systemd:

$ systemctl cat nginx

Можно увидеть оригинальный unit и все применённые изменения.

Если нужно полностью удалить свои изменения:

$ sudo systemctl revert nginx

Systemd удалит файл переопределения конфигурации и вернёт сервис к исходному состоянию.

🔥 Drop-in конфигурации — способ менять поведение сервисов в Linux. Они сохраняют обновляемость пакетов и делают изменения прозрачными.

🚪 Linux Ready | #совет

📂 Напоминалка по работе с Load Balancer!

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

На картинке — 7 основных задач Load Balancer: распределение нагрузки, SSL termination, сохранение сессий, отказоустойчивость, масштабирование, защита от DDoS и мониторинг серверов.

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

🚪 Linux Ready | #ресурс

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

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

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

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

🚪 Linux Ready | #ресурс

Контроль целостности системных утилит Linux через проверку хэш-сумм.

При компрометации сервера злоумышленники часто подменяют базовые системные бинарники (например, ss, ps или login) на модифицированные версии с бэкдорами. Мы напишем лаконичный bash-скрипт, который создаст эталонные слепки контрольных сумм SHA-256 для критически важных утилит и проверит их на предмет несанкционированных изменений. Этот базовый механизм Host IDS (интрузивного детектирования) позволяет оперативно обнаружить факт присутствия атакующего в системе.

Сформируем базу данных эталонных хэш-сумм для выбранных системных утилит и сохраним её в защищенный файл:

# Создание эталонных хэшей для проверки
sha256sum /bin/ps /bin/ss /usr/bin/whoami > /root/sys_integrity.db

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

Напишем автоматический скрипт валидации, который сверяет текущее состояние файлов с ранее сохраненным эталоном:

# Скрипт проверки и вывода измененных файлов
sha256sum -c /root/sys_integrity.db 2>&1 | grep -v 'OK' || echo "Integrity check: SUCCESS"

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

# проверка (контрольная эмуляция подмены для проверки реакции парсера)
echo "test" >> /root/sys_integrity.db && sha256sum -c /root/sys_integrity.db 2>&1 | grep 'FAILED'

Ожидаемый вывод: /root/sys_integrity.db: FAILED

# cleanup (удаление тестовой базы данных из системы)
rm -f /root/sys_integrity.db

Регулярный запуск такого скрипта через cron помогает вовремя заметить активность руткитов и троянов. Чтобы атакующий не смог подделать саму базу хэшей, обязательно храните эталонный файл sys_integrity.db на удаленном сервере логирования или на флешке в режиме "только чтение".

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

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

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

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

🚪 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 | #совет

📂 Напоминалка для работы с curl!

Например, curl -I позволяет проверить HTTP-заголовки сервера, curl -H добавить необходимые заголовки или токены авторизации, а curl -X POST отправить запрос к API из терминала.

На картинке — основные команды curl, которые пригодятся при разработке, тестировании API, диагностике сетевых проблем и работе с Linux-серверами.

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

🚪 Linux Ready | #ресурс

Запускаем только один экземпляр скрипта с помощью flock!

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

Представьте простой пример. Ваш скрипт выполняется 90 секунд, а cron запускает его каждую минуту:

* * * * * /opt/scripts/backup.sh

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

Именно для таких случаев в Linux есть flock. Он использует файловые блокировки ядра и позволяет сказать: пока этот скрипт работает, второй запуск не начинай.

Самый простой вариант выглядит так:

flock /tmp/backup.lock /opt/scripts/backup.sh

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

Но, честно говоря, для cron ожидание обычно не имеет смысла. Проще пропустить очередной запуск, чем держать очередь из процессов. Поэтому чаще используют ключ -n:

flock -n /tmp/backup.lock /opt/scripts/backup.sh

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

Именно поэтому в cron обычно встречается такой вариант:

* * * * * /usr/bin/flock -n /var/lock/backup.lock /opt/scripts/backup.sh

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

Если же вы хотите защитить скрипт независимо от того, как его запускают — через cron, вручную или из другого скрипта, — блокировку можно поставить прямо внутри него:

#!/usr/bin/env bash

exec 200>/var/lock/backup.lock
flock -n 200 || exit 1

echo "Работает только один экземпляр"

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

🔥 flock использует рекомендательные (advisory) блокировки. Это значит, что они работают только между процессами, которые сами используют flock для одного и того же файла блокировки. Если какая-то программа полностью игнорирует механизм блокировок, flock физически её не остановит.

🚪 Linux 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 | #практика

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

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

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

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

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

$ sleep 1000

Нажмите:

Ctrl + Z

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

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

$ bg

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

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

$ jobs

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

$ fg

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

🚪 Linux Ready | #совет

🤔 Young Linux — большой справочник по Linux и Bash!

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

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

🚪 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 | #практика

📂 Напоминалка по работе с nmcli!

Например, nmcli device wifi list показывает доступные Wi-Fi сети, nmcli connection show выводит список всех подключений, а nmcli connection up <name> активирует нужное подключение.

На картинке — полезные команды для работы с NetworkManager: управление интерфейсами, Wi-Fi, подключениями и настройкой статического IP.

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

🚪 Linux Ready | #ресурс

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

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

Откройте файл через отдельный файловый дескриптор:

$ exec 3< huge.log

Теперь удалите файл обычной командой:

$ rm huge.log

Файл исчезнет из каталога и больше не будет доступен по имени.

Но дескриптор останется открытым:

$ cat <&3

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

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

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

🚪 Linux Ready | #совет

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

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

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

🚪 Linux Ready | #сайт

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

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

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

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

🚪 Linux Ready | #ресурс

Большинство задач на удалённом сервере можно выполнять без входа по SSH!

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

На самом деле SSH умеет запускать команды напрямую:

$ ssh user@server 'journalctl -n 1000'

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

Можно передавать данные через обычные каналы Linux:

$ ssh user@server 'mysqldump db' > dump.sql

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

Можно копировать целые каталоги потоково:

$ ssh user@server 'tar czf - /var/log' | tar xzf -

Архив никогда не записывается на диск сервера и сразу распаковывается локально.

🔥 Такой подход удобно использовать в скриптах, автоматизации, резервном копировании и диагностике. Часто оказывается, что для выполнения задачи полноценная SSH-сессия вообще не нужна.

🚪 Linux Ready | #совет

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

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

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

🚪 Linux Ready | #сайт

Знали, что Bash умеет генерировать десятки путей и аргументов ещё до запуска команды?

Большинство используют циклы или копируют похожие команды несколько раз, хотя Bash умеет делать это самостоятельно.

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

$ mkdir -p project/{src,tests,docs}

Shell автоматически развернёт команду в несколько аргументов ещё до запуска mkdir.

Точно так же удобно создавать резервные копии:

$ cp app.{conf,conf.bak}

Фактически Bash выполнит:

$ cp app.conf app.conf.bak

Можно работать сразу с несколькими каталогами:

$ echo /var/log/{nginx,apache2,redis}/*.log

Команда мгновенно превратится в набор путей для всех указанных директорий.

Поддерживаются и диапазоны:

$ touch file{1..10}.txt

В результате будут созданы файлы от file1.txt до file10.txt без единого цикла.

🔥 Brace expansion выполняется внутри Bash ещё до запуска программы, поэтому работает быстрее и чище, чем дополнительные shell-конструкции.

🚪 Linux Ready | #совет

😍 Linux Cheat — полезнейший репозиторий для изучения Linux!

В этом репозитории подробно разбирается внутреннее устройство Linux: процессы, память, системные вызовы, ELF и работа системы на низком уровне. Материал построен на практических примерах за счёт чего сложные темы намного проще понять. Хорошо подойдёт разработчикам, DevOps и тем, кто хочет лучше понимать, как Linux работает под капотом.

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

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