🐱 Awesome Sysadmin — огромная база инструментов для Linux и DevOps!

В этом репозитории собраны open-source инструменты для системного администрирования: мониторинг, логирование, backup, docker, kubernetes, безопасность, networking, автоматизация и всё, что нужно для работы с серверами и инфраструктурой. По сути это готовая база полезного софта для сисадминов, DevOps и backend-разработчиков.

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

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

Настройка coredump в Linux — диагностика падений процессов!

Когда Linux-процесс аварийно завершается (например, SIGSEGV / Segmentation fault, SIGABRT и др.), система может сохранить снимок памяти процесса — core dump.

Без dump-файла обычно остаётся только сам факт падения и запись в логах. Core dump позволяет открыть состояние процесса в gdb, получить stack trace, посмотреть память, регистры, потоки и локализовать причину уже после завершения процесса.

Проверка текущего лимита на создание dump:

ulimit -c

Если вывод 0 — сохранение core dump отключено для текущей shell/session.

Временное включение:

ulimit -c unlimited

Это работает только для процессов, запущенных из текущей shell-сессии. После logout или reboot настройка пропадёт.

Для systemd-сервисов одного ulimit недостаточно — лимит нужно задавать в unit-файле:

[Service]
LimitCORE=infinity

После изменения unit-файла:

sudo systemctl daemon-reload
sudo systemctl restart app.service

Теперь проверяем, как именно система сохраняет dump-файлы:

cat /proc/sys/kernel/core_pattern

Параметр core_pattern определяет обработчик и путь сохранения dump. Если значение начинается с |, dump передаётся внешнему обработчику, например systemd-coredump.

Пример прямого сохранения dump в файл:

/core.%e.%p.%t

Где: %e — имя процесса; %p — PID процесса; %t — UNIX timestamp

Создадим каталог для dump-файлов и настроим сохранение:

sudo mkdir -p /var/crash
sudo chmod 1777 /var/crash
sudo sysctl -w kernel.core_pattern=/var/crash/core.%e.%p.%t

1777 используется как простой демо вариант для тестов и локальной диагностики. В продакшен обычно делают более жёсткие права доступа и отдельно контролируют доступ к dump-файлам, поскольку они могут содержать чувствительные данные процесса.

Чтобы настройка сохранилась после reboot:

sudo nano /etc/sysctl.d/99-coredump.conf

Добавляем:

kernel.core_pattern=/var/crash/core.%e.%p.%t

Применяем конфигурацию:

sudo sysctl --system

Пример аварийного завершения процесса:

./app
Segmentation fault (core dumped)

После падения появится dump-файл:

/var/crash/core.app.18422.1715962012

Теперь можно открыть dump через gdb:

gdb ./app /var/crash/core.app.18422.1715962012

Посмотреть стек вызовов:

(gdb) bt

Для полноценного анализа бинарь желательно собирать с debug symbols (-g) без stripping.

На большинстве современных systemd-дистрибутивов dump часто обрабатывается через systemd-coredump, а не сохраняется напрямую через core_pattern.

Посмотреть список crash:

coredumpctl list

Получить информацию по dump:

coredumpctl info PID

Открыть dump сразу в gdb:

coredumpctl debug PID

Вместо PID можно использовать имя процесса, путь к бинарю и другие фильтры coredumpctl. Также важно помнить, что systemd-coredump отдельно управляет хранением dump-файлов через coredump.conf: Storage, ProcessSizeMax, ExternalSizeMax, MaxUse, KeepFree.

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

🔥 Core dump — один из базовых механизмов low-level диагностики Linux-приложений, backend-сервисов и анализа падений в продакшен.

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

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

Например, когда устройство хочет отправить данные на IP-адрес внутри локальной сети, ему сначала нужно узнать MAC-адрес получателя. Для этого используется ARP — Address Resolution Protocol.

На картинке показано, как хост отправляет ARP Request в broadcast, коммутатор рассылает запрос всем устройствам, а нужный хост отвечает своим MAC-адресом через ARP Reply.

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

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

Знали, что Bash умеет редактировать предыдущие команды как полноценный текстовый объект?

Большинство используют history только через ↑, хотя Bash поддерживает полноценные history expansion и inline-редактирование команд без перепечатывания.

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

$ sudo !!:gs/8080/80/

Если последняя команда была:

$ docker run -p 8080:8080 app

Shell выполнит:

$ sudo docker run -p 80:80 app

Без ручного редактирования и без запуска редактора.

Можно вывести результат expansion без выполнения:

$ !-2:p

Флаг :p показывает итоговую команду после expansion и не запускает её. Это безопасный способ проверить подстановку перед выполнением.

Для быстрых исправлений опечаток существует встроенная подстановка:

$ ^sttaus^status

Shell заменит первое совпадение в предыдущей команде и выполнит исправленный вариант в текущей сессии.

🔥 History expansion выполняется самим интерактивным Bash до парсинга команды. Поэтому итоговая строка видит текущие alias, functions, переменные и окружение так же, как если бы вы набрали её вручную.

🚪 Linux Ready | #совет

🧐 Крутая статья для тех, кто хочет руками собрать рабочий Linux‑VPS и привести его в порядок по чек‑листу.

В этой статье:
• Показывают базовую первичную настройку сервера: подключение по SSH, обновление системы, hostname и timezone.

• Разбирают, что нужно сделать сразу после установки, чтобы VPS был готов к работе и не оставался «голым» сервером.

• Объясняют, как превратить этот набор действий в нормальный старт для DevOps, администрирования или дальнейшего развёртывания сервисов.

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

➡️ DevOps Ready | #статья

Знали, что можно добавлять timestamp к любому выводу terminal pipeline без изменения приложения и логгера?

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

Утилита ts из пакета moreutils добавляет timestamp к каждой строке stdin в реальном времени:

$ tail -f app.log | ts '%Y-%m-%d %H:%M:%S'

Теперь каждая строка получает точное время:

2026-05-22 18:41:03 request started
2026-05-22 18:41:07 request finished

Это особенно полезно при отладке конвейеров команд, shell-автоматизации, CI-логов, docker-контейнеров и long-running процессов, где нельзя быстро изменить сам источник логов.

Можно использовать свой формат времени:

$ tail -f app.log | ts '[%H:%M:%S]'

Или измерять интервалы между событиями:

$ ping 1.1.1.1 | ts -i

Иногда программы буферизуют вывод — тогда поможет:

$ stdbuf -oL -eL some-command | ts

🔥 Приём кажется небольшим, но на практике сильно упрощает анализ поведения систем и CLI-инструментов без внедрения полноценного логгирования.

➡️ DevOps Ready | #совет

📂 Базовые принципы построения надёжного стека логирования для DevOps!

На картинке — 14 ключевых правил построения enterprise-grade системы логирования, разделенных на лучшие практики и элементы надёжности, а также бонусный чек-лист для проверки твоего стека.

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

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

✍️ Gizmo AI — нейросеть для обучения и запоминания информации!

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

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

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

📂 Напоминалка по SSH — как устанавливается защищённое соединение!

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

На картинке — полный цикл работы SSH: от TCP-подключения до шифрования команд и проверки ключей клиента.

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

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

Знали, что можно добавлять timestamp к любому выводу terminal pipeline без изменения приложения и логгера?

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

Утилита ts из пакета moreutils добавляет timestamp к каждой строке stdin в реальном времени:

$ tail -f app.log | ts '%Y-%m-%d %H:%M:%S'

Теперь каждая строка получает точное время:

2026-05-22 18:41:03 request started
2026-05-22 18:41:07 request finished

Это особенно полезно при отладке конвейеров команд, shell-автоматизации, CI-логов, docker-контейнеров и long-running процессов, где нельзя быстро изменить сам источник логов.

Можно использовать свой формат времени:

$ tail -f app.log | ts '[%H:%M:%S]'

Или измерять интервалы между событиями:

$ ping 1.1.1.1 | ts -i

Иногда программы буферизуют вывод — тогда поможет:

$ stdbuf -oL -eL some-command | ts

🔥 Приём кажется небольшим, но на практике сильно упрощает анализ поведения систем и CLI-инструментов без внедрения полноценного логгирования.

🚪 Linux Ready | #совет

💅 Linux Notes — полезные заметки и статьи по Linux!

На сайте собрана большая коллекция материалов по Linux, системному администрированию и серверной инфраструктуре. Здесь можно найти шпаргалки по командам, настройку сервисов, работу с сетью, Bash, Docker, SSH, Nginx и другие практические темы, с которыми регулярно сталкиваются админы и backend-разработчики.

📌 Оставляю ссылочку: linux-notes.org

➡️ DevOps Ready | #сайт

Слышали, что Bash умеет выводить set -x не в терминал, а в отдельный log-файл?

Обычно при debugging shell-скриптов используют set -x, но весь trace смешивается с обычным stdout/stderr и быстро делает вывод неудобным для чтения.

В Bash существует специальная переменная BASH_XTRACEFD, которая перенаправляет xtrace в отдельный файловый дескриптор:

$ exec {FD}>>debug.log
$ export BASH_XTRACEFD=$FD

Теперь debugging не ломает основной вывод программы:

$ bash -x ./deploy.sh

Все trace-команды уходят только в debug.log, а stdout/stderr продолжают работать как обычно.

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

После завершения debugging дескриптор корректно закрывается:

$ set +x
$ exec {FD}>&-

🔥 Механизм работает внутри Bash и использует обычные файловые дескрипторы оболочки без внешних утилит.

🚪 Linux Ready | #совет

📂 Напоминалка по перенаправлениям ввода/вывода!

Например, > перенаправляет вывод команды в файл, 2> — ошибки, а 2>&1 объединяет STDOUT и STDERR.

На картинке — основные файловые дескрипторы (STDIN, STDOUT, STDERR), примеры перенаправлений и другое.

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

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

Работа с systemctl edit — переопределение systemd unit без изменения оригинального файла!

Многие администраторы и разработчики до сих пор изменяют unit-файлы напрямую в:

/usr/lib/systemd/system/

или:

/lib/systemd/system/

Но это vendor unit-файлы, устанавливаемые пакетным менеджером. После обновления пакета изменения могут быть перезаписаны.

Правильный способ настройки сервисов в systemd — использовать override-конфигурации через:

systemctl edit

Например, добавим переменные окружения для nginx:

sudo systemctl edit nginx.service

После сохранения systemd создаст файл:

/etc/systemd/system/nginx.service.d/override.conf

Это безопасный способ переопределения параметров сервиса без изменения оригинального unit-файла.

Пример добавления переменных окружения:

[Service]
Environment="APP_ENV=production"
Environment="WORKERS=4"

После сохранения systemctl edit обычно автоматически выполняет daemon-reload, поэтому достаточно просто перезапустить сервис:

sudo systemctl restart nginx

Если unit-файлы или override-конфигурации изменялись вручную в /etc/systemd/system/, тогда дополнительно выполняют:

sudo systemctl daemon-reload

Проверить итоговую конфигурацию сервиса можно так:

systemctl cat nginx.service

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

А для просмотра итоговых параметров сервиса полезно использовать:

systemctl show nginx.service

Это особенно полезно при диагностике сложных production-конфигураций.

Переопределение ExecStart, один из важных нюансов systemd — перед новым ExecStart старое значение нужно очистить. Пример:

sudo systemctl edit app.service

Override:

[Service]
ExecStart=
ExecStart=/usr/local/bin/app --port 8080

Пустой ExecStart= сбрасывает предыдущее значение из исходного unit-файла. Без очистки systemd может выдать ошибку, поскольку для сервисов с типом, отличным от Type=oneshot, допускается только один ExecStart.

Автоматический перезапуск сервиса. Для production-сервисов часто настраивают автоматический перезапуск:

[Service]
Restart=on-failure
RestartSec=5

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

Systemd умеет ограничивать ресурсы процессов через cgroup. Пример ограничения памяти:

[Service]
MemoryMax=1G

Это особенно полезно для Node.js, Python, Java и других серверных приложений с непредсказуемым потреблением памяти.

Иногда требуется изменить почти весь unit-файл. Для этого используется:

sudo systemctl edit --full app.service

В этом режиме systemd создаёт полный локальный unit-файл в:

/etc/systemd/system/

который заменяет оригинальный unit из пакета.

Но использовать --full стоит осторожно — после этого вы фактически берёте поддержку unit-файла на себя и можете пропустить изменения из новых версий пакета.

Практический пример настройки сервиса:

[Service]
Environment="NODE_ENV=production"
WorkingDirectory=/srv/app
ExecStart=
ExecStart=/usr/bin/node /srv/app/server.js
Restart=on-failure
RestartSec=5
LimitNOFILE=65535
MemoryMax=1G

Так часто настраивают production-сервисы для Node.js, Go, Python, Java и других серверных приложений.

Дополнительно полезно знать:

systemctl show app.service -p FragmentPath -p DropInPaths

Команда покажет: путь к основному unit-файлу, все подключённые override-конфигурации.

🔥 Это стандартный и рекомендуемый способ настройки systemd без риска потерять изменения после обновления системы.

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

👍 Linux Audit — полезные материалы по Linux и безопасности!

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

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

➡️ DevOps Ready | #сайт