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

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

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

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

🚪 Linux Ready | #ресурс

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

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

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

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

🚪 Linux Ready | #ресурс

Слышали, что в 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 | #совет

❤️ Отличная статья на Habr для тех, кто хочет глубже понять реальные уязвимости в ядре Linux и влияние kernel-багов на безопасность системы!

В этой статье:
• Разбирается, как одна ошибка в коде может привести к повышению привилегий до root;
• Показано, почему даже маленький символ в ядре способен создать критичную уязвимость;
• Разобран практический кейс, который полезно знать всем, кто интересуется hacking и infosec.

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

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

Linux-сервисы можно запускать только в момент первого обращения к ним!

Systemd умеет не только постоянно держать сервисы запущенными, но и активировать их по событию через socket activation.

Вместо постоянного запуска процесса создаётся socket:

[Socket]
ListenStream=8080

[Install]
WantedBy=sockets.target

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

После завершения работы сервис может быть остановлен, а ресурсы освобождены.

Проверить такие сокеты можно командой:

$ systemctl list-sockets

Так работает множество системных компонентов Linux, включая некоторые службы systemd и Docker:

$ systemctl status docker.socket

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

🔥 Socket activation позволяет экономить память, ускорять запуск сервисов и строить более эффективные фоновые службы без собственного демона, который постоянно ждёт подключения.

🚪 Linux Ready | #совет

📂 Шпаргалка по Linux-администрированию!

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

На картинке собраны основные направления работы Linux-администратора: командная строка, безопасность, SSH-доступ, firewall, резервное копирование и др.

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

🚪 Linux Ready | #ресурс

Перехватываем сетевые проблемы в Linux через tcpdump!

Когда приложение не может подключиться к внешнему сервису, первое, что обычно проверяют — firewall, маршруты или настройки приложения.
Но на практике проблема часто находится глубже. Бывает, что приложение работает нормально, конфигурация выглядит правильно, маршрут есть, firewall не показывает явных проблем, а соединения всё равно нет.

В такой ситуации важно посмотреть, что реально происходит с пакетами. Например:

curl https://api.example.com

Получаем:

Connection timed out

Проверяем, что firewall не является причиной:

systemctl status firewalld

Всё выглядит нормально, но соединения всё равно нет. Здесь помогает tcpdump. Это один из главных инструментов Linux для сетевой диагностики. Он показывает реальные пакеты: что ушло с сервера, что вернулось обратно и на каком этапе возникла проблема.

В такие моменты tcpdump часто экономит часы поиска. Смотрим TCP-трафик к HTTPS-порту:

sudo tcpdump -nn -i any port 443

Параметры:
-nn — не выполнять DNS-resolve и не заменять номера портов именами;
-i — выбрать интерфейс; any — слушать все интерфейсы.

Например:

IP 10.0.0.15.42310 > 142.250.184.14.443: Flags [S]

Видим SYN-пакеты, но не видим SYN-ACK в ответ. Это означает, что клиент пытается установить TCP-соединение, но ответ обратно не приходит.

Дальше стоит искать проблему в: фильтрации трафика; security group; ACL; маршрутизации; удалённом сервисе. Если видим:

IP 142.250.184.14.443 > 10.0.0.15.42310: Flags [S.]

значит TCP handshake проходит.

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

sudo tcpdump -nn -i any host 10.0.0.5

Например, проверяем соединение приложения с PostgreSQL:

sudo tcpdump -nn -i eth0 host 10.0.0.5 and port 5432

На production это намного удобнее, когда через сервер проходят тысячи соединений. Иногда нужно посмотреть содержимое HTTP-запросов:

sudo tcpdump -A -s0 -i eth0 host 10.0.0.5 and port 80

Можно увидеть:

GET /health HTTP/1.1
Host: backend.local

Для обычного HTTP это работает. Для HTTPS посмотреть содержимое запросов не получится — данные будут зашифрованы TLS. Можно увидеть сам факт соединения и TLS handshake, но не содержимое HTTP-запроса. Если нужно сохранить трафик:

sudo tcpdump -nn -i any port 443 -w capture.pcap

Открыть файл можно в Wireshark или повторно через:

tcpdump -r capture.pcap

На нагруженных серверах удобно ограничивать количество пакетов:

sudo tcpdump -nn -i any port 443 -c 100

Ещё полезный фильтр — только новые TCP-соединения:

sudo tcpdump -nn -i any 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0'

Важно помнить: tcpdump показывает только сетевой трафик, но не знает, какой процесс его создал. Для связи соединения с процессом используйте:

ss -tnp

🔥 Главная сила tcpdump в том, что он помогает быстро определить, где именно проблема: пакет не вышел с сервера; пакет ушёл, но ответ не пришёл; TCP установился, а ошибка уже внутри приложения.

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

👍 Bash One-Liner — крутая шпаргалка по Bash-командам!

Этот репозиторий настоящая находка для тех, кто работает с Linux, терминалом и автоматизацией. Здесь собрана большая коллекция полезных Bash команд для работы с файлами, логами, процессами, сетью, текстом и системным администрированием.

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

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

Запускаем команды от имени другого пользователя через sudo -u — без входа в его интерактивную сессию через su!

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

Обычный запуск команды от имени другого пользователя:

sudo -u www-data id

Команда выполнится с UID и GID пользователя www-data, но текущий терминал останется вашим.

Например, можно проверить, имеет ли веб-приложение доступ к нужной директории:

sudo -u www-data ls -la /var/www/app

Это обычно безопаснее, чем временно менять владельца файлов или расширять права доступа.

Также можно открыть shell от имени сервисного пользователя:

sudo -u postgres bash

Все команды внутри этого shell будут выполняться от имени postgres. Однако это не полноценный login shell: текущая директория и часть окружения могут сохраниться от исходного пользователя.

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

sudo -iu postgres

При отладке важно учитывать, что sudo -u не всегда воспроизводит реальное окружение работающего сервиса.

Например:

sudo -u node env

Эта команда покажет окружение, сформированное sudo, но оно может отличаться от окружения процесса, запущенного через systemd, Docker, Kubernetes, PM2 или другой менеджер процессов.

Также можно передать временную переменную окружения только для одного запуска:

sudo -u www-data env APP_ENV=testing ./deploy.sh

Переменная APP_ENV будет доступна только этому процессу и его дочерним процессам. Глобальные настройки системы при этом не изменятся. Также важно: возможности sudo -u зависят от правил в sudoers. Разрешение на запуск shell, интерпретатора или произвольного скрипта может дать пользователю широкий доступ от имени целевой учётной записи.

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

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

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

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

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

$ cat /dev/stdin

cat читает текущий stdin процесса. Это может быть терминал, pipe или перенаправленный поток.

Например, можно сравнить файл с данными, которые приходят напрямую:

$ generate_config | diff config.old /dev/stdin

Без создания временных файлов:

$ echo "new_value=true" | diff config.old /dev/stdin

Также доступны стандартный вывод и ошибки:

$ echo "hello" > /dev/stdout
$ echo "error" > /dev/stderr

Это удобно в shell-автоматизации, когда программа умеет работать с потоками, но ожидает путь к файлу.

🔥 /dev/stdin, /dev/stdout и /dev/stderr — это удобные ссылки на файловые дескрипторы текущего процесса, которые помогают соединять программы без лишних временных файлов.

🚪 Linux Ready | #совет

📂 Напоминалка по особым правам в Linux!

Например, SUID позволяет запускать файл с правами его владельца, SGID помогает управлять наследованием групповых прав, а Sticky Bit защищает файлы в общих директориях вроде /tmp от удаления другими пользователями.

На картинке — основные отличия между SUID, SGID и Sticky Bit, примеры их использования и команды chmod для настройки специальных прав доступа.

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

🚪 Linux Ready | #ресурс

Практически любую команду можно запустить в отдельной cgroup!

Большинство воспринимает systemd-run как инструмент для запуска сервисов. Но режим --scope запускает команду во временном scope unit, сразу помещая её и всё дерево процессов в отдельную cgroup, где можно задать ограничения.

Например, если большая сборка начинает вытеснять всё остальное из памяти, достаточно выполнить её через systemd-run:

systemd-run --user --scope \
  -p MemoryHigh=1536M \
  -p MemoryMax=2G \
  make -j32

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

Точно так же можно ограничить использование процессора, не меняя приоритет процесса (nice решает другую задачу):

systemd-run --user --scope \
  -p CPUQuota=200% \
  npm test

Или собрать сразу несколько политик для ресурсоёмкой задачи:

systemd-run --user --scope \
  -p MemoryMax=4G \
  -p CPUQuota=300% \
  -p IOWeight=100 \
  cargo build --release

Для работы ограничений требуется systemd с поддержкой соответствующих cgroup-контроллеров (обычно современные дистрибутивы с cgroup v2).

🔥 systemd-run --scope позволяет применять возможности cgroups к любой команде одной строкой, без создания сервисов и постоянных unit-файлов.

🚪 Linux Ready | #совет

📂 Напоминалка для работы с VLAN в Linux: Access vs Trunk!

Например, Access Port используется для подключения устройств в один VLAN без дополнительной настройки на стороне клиента, а Trunk Port позволяет передавать несколько VLAN через один сетевой интерфейс с использованием стандарта 802.1Q.

На картинке — разница между Access и Trunk портами, структура тегированного и нетегированного Ethernet-кадра, а также пример связи нескольких VLAN через trunk-соединение.

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

🚪 Linux Ready | #ресурс

Разбираем диагностику OOM Killer в Linux через systemd, kernel logs и cgroup!

При эксплуатации Linux-сервисов периодически встречается ситуация: процесс завершается, но в логах приложения нет явной причины ошибки.
Первое, что обычно проверяем — состояние сервиса через systemd:

systemctl status api.service

Например, в выводе можно увидеть:

Active: failed (Result: signal)

Этот статус показывает только факт завершения процесса, но не объясняет, что именно произошло. Чтобы найти причину, нужно посмотреть сообщения ядра Linux. Одна из распространённых причин внезапного завершения процессов — срабатывание OOM Killer.

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

Проверяем события OOM в логах ядра:

journalctl -k | grep -Ei "out of memory|killed process|oom"

Также можно использовать:

dmesg -T | grep -Ei "killed process|out of memory|oom"

Например:

Out of memory: Killed process 4210 (java)
anon-rss:16000000kB

Из этого видно, что ядро завершило процесс Java из-за проблем с памятью. Следующий вопрос при расследовании — почему именно этот процесс был выбран.

Для работающего процесса можно проверить значение:

cat /proc/<PID>/oom_score

oom_score показывает относительную вероятность выбора процесса механизмом OOM Killer. Чем выше значение, тем выше вероятность завершения процесса при нехватке памяти.

Также существует параметр:

cat /proc/<PID>/oom_score_adj

Он позволяет изменить приоритет процесса. Значения находятся в диапазоне от -1000 до 1000. Чем ниже значение, тем меньше вероятность завершения процесса. Значение -1000 полностью исключает процесс из выбора OOM Killer.

Для сервисов под systemd такие настройки корректнее задавать через unit-файл:

[Service]
MemoryMax=4G
OOMScoreAdjust=-500

После изменения конфигурации:

systemctl daemon-reload
systemctl restart api.service

При работе с контейнерами важно учитывать ещё один сценарий: проблема может быть не в памяти хоста, а в ограничении cgroup.
Например, сервер может иметь свободную память, но контейнер ограничен параметром memory limit. После превышения этого значения процесс внутри контейнера будет завершён.

Проверяем ограничение памяти Docker:

docker inspect -f '{{.HostConfig.Memory}}' container_name

Текущее потребление:

docker stats

Для анализа cgroup также полезно проверить события памяти:

memory.events

В Kubernetes аналогичная ситуация отображается через:

kubectl describe pod api

В выводе будет:

Reason: OOMKilled

Это означает, что контейнер превысил установленный limits.memory. При диагностике OOM важно определить, где именно возникло ограничение: на уровне памяти хоста, systemd/cgroup, Docker или Kubernetes.

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

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

☕️ Полезная статья недавно вышла на Хабре: Как я написал свой клиент Miracast для шаринга экрана под Linux в 2026 году и погряз в войне за проприетарные байты!

В этой статье:
• Разбирается, как автор на Python собрал собственную Linux-утилиту FluxCast для трансляции экрана на Smart TV без HDMI-кабеля;
• Показываются реальные проблемы Miracast, DLNA, RTSP/RTP, GStreamer, Wayland, Wi-Fi Direct и совместимости с разными телевизорами;
• Рассказывается, как open-source проект вырос из CLI-скрипта в AppImage, AUR-пакет и утилиту, попавшую в ArchWiki.

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

🚪 Linux Ready | #статья