Запускаем команды от имени другого пользователя через 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 — удобный инструмент для проверки прав, отладки сервисов и запуска отдельных команд от имени системных пользователей без полноценного переключения сессии.

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

DevOps Labs практические лабораторные по Docker, Kubernetes, Terraform и CI/CD!

В этом репозитории собраны hands-on лабораторные для DevOps, DevSecOps и Cloud Engineering: Git, Docker, Kubernetes, Terraform, AWS, CI/CD, GitOps, Ansible, Helm, Prometheus и security-практики. Формат полезный именно для прокачки руками: у каждой лабораторной есть цель, ожидаемый результат и сценарий, похожий на реальные задачи из инфраструктуры, а не просто список ссылок для чтения.

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

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

🐱 Полезную статью нашёл на Хабре: «Права в Linux: chown/chmod, SELinux context, символьная/восьмеричная нотация, DAC/MAC/RBAC/ABAC»!

В статье:
• Даётся цельная картина систем управления доступом в Linux;
• Пошагово разбираются символьная и восьмеричная нотации прав, специальные биты и SELinux-контексты с понятными шпаргалками;
• Собрана база команд и объясняется, как правильно читать и настраивать права без типичных ошибок.

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

🚪 Linux Ready | #статья

The Book of Secret Knowledge — огромная база команд, инструментов и DevOps-приёмов!

В этом репозитории собраны полезные материалы для тех, кто работает с Linux, серверами, сетями и безопасностью: cheatsheets, one-liners, CLI/Web-инструменты, списки команд, заметки по Nginx, DNS, HTTP, TLS, SSH, containers, monitoring, debugging и security-практикам. Это не учебник от первой до последней главы, а большая “операционная база”, куда удобно заходить, когда нужно быстро найти команду, инструмент или идею для диагностики инфраструктуры.

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

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

Как в Linux быстро проверить, кто держит порт?

Иногда сервис не запускается и пишет, что порт уже занят:

bind: address already in use

В такой момент не нужно гадать, какой процесс мешает. Можно сразу посмотреть listening-сокеты через ss:

sudo ss -ltnp

Флаги читаются так:

-l  listening
-t  TCP
-n  не резолвить имена
-p  показать процесс

Если нужен конкретный порт, добавь фильтр:

sudo ss -ltnp 'sport = :8080'

В выводе будет видно адрес, порт, имя процесса и PID:

LISTEN 0 4096 0.0.0.0:8080 users:(("java",pid=2481))

После этого можно проверить процесс:

ps -fp 2481

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

Для UDP почти то же самое:

sudo ss -lunp

А если нужно увидеть все соединения к порту:

sudo ss -tanp 'sport = :8080'

ss помогает быстро понять, какой процесс занял порт. Это одна из первых команд при проблемах со стартом сервисов, Docker, Nginx и backend-приложений.

➡️ DevOps Ready | #совет

📂 Напоминалка по версионированию инфраструктурных изменений!

Изменения в инфраструктуре требуют не меньшего контроля, чем изменения в коде приложения. Грамотное версионирование позволяет отслеживать историю изменений, безопасно выполнять обновления, быстро откатываться при ошибках и обеспечивать прозрачность работы всей команды.
На картинке — 7 практических принципов управления инфраструктурными изменениями: от хранения инфраструктуры как кода и атомарных коммитов до использования Pull Request, автоматизации через CI/CD, документирования изменений, безопасного отката и организации полного жизненного цикла инфраструктурных изменений.

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

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

Шпаргалка по сетевым командам Linux!

Например, ip addr show показывает адреса интерфейсов, dig example.com проверяет DNS, а ss -tuln помогает увидеть открытые порты.
На картинке Linux networking commands: routing, network interfaces, DNS, monitoring, troubleshooting и connectivity-команды для быстрой диагностики серверов.

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

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

Настраиваем ротацию логов через logrotate!

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

Допустим, приложение пишет сюда:

/var/log/myapp/app.log

Создадим конфиг:

sudo nano /etc/logrotate.d/myapp

Минимальная настройка:

/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
}

Это значит: ротировать каждый день, хранить 7 архивов, сжимать старые файлы и не ругаться, если лог отсутствует.

Если приложению нужно пересоздать файл после ротации, добавим postrotate:

postrotate
    systemctl reload myapp
endscript

Полный вариант:

/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    postrotate
        systemctl reload myapp
    endscript
}

Проверить конфиг можно без реальной ротации:

sudo logrotate -d /etc/logrotate.d/myapp

А принудительно запустить:

sudo logrotate -f /etc/logrotate.d/myapp

После проверки посмотри файлы:

ls -lh /var/log/myapp/

logrotate защищает сервер от бесконечно растущих логов. Это базовая, но очень важная настройка для сервисов, cron-задач и backend-приложений.

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

Ускоряем CI-пайплайн через оптимизацию слоев Docker.

Эффективная последовательность команд в Dockerfile позволяет использовать кэширование и сократить время сборки в разы. Мы научимся правильно разделять установку зависимостей и копирование исходного кода, чтобы не пересобирать проект «с нуля» при каждой правке текста. Это базовый навык DevOps для экономии ресурсов раннеров и времени разработчиков.

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

# Dockerfile-slow
FROM node:18
WORKDIR /app
COPY . .
RUN npm install
CMD ["node", "index.js"]

При такой структуре изменение одного символа в коде заставит npm install запускаться заново.

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

# Dockerfile-fast
FROM node:18
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm install
COPY . .
CMD ["node", "index.js"]

Теперь слой с тяжелыми зависимостями закэшируется и будет пересобираться только при правке package.json.

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

time docker build -t fast-app -f Dockerfile-fast .
# Ожидаемый результат: время сборки во второй раз составит доли секунды (CACHED).

Грамотная последовательность шагов это самый дешевый способ ускорить доставку кода. Используйте этот принцип не только в Docker, но и в шагах GitHub Actions или GitLab CI, вынося самые тяжелые и редко меняющиеся операции в начало пайплайна. Всегда проверяйте логи сборки на наличие пометки «Using cache».

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

Зачем в DevOps использовать timeout для долгих команд?

Иногда команда может зависнуть: сетевой запрос, backup, healthcheck, rsync, миграция или скрипт в CI. Если не ограничить время выполнения, job может висеть бесконечно.

Простой пример:

curl https://api.example.com/health

Если соединение подвиснет, следующий шаг pipeline может так и не начаться.

Для таких случаев есть timeout:

timeout 10s curl https://api.example.com/health

Теперь команда получит максимум 10 секунд.

Это удобно для healthcheck-ов:

timeout 5s ./check-service.sh

И для команд внутри CI/CD:

timeout 2m ./run-migrations.sh

Если команда не завершилась вовремя, timeout остановит её и вернёт ошибочный exit code. Это можно обработать:

if ! timeout 10s curl -f http://localhost:8080/health; then
    echo "service is not ready"
    exit 1
fi

Для более жёсткого завершения можно указать сигнал:

timeout -s KILL 30s ./worker-test.sh

Но обычно лучше начинать с обычного timeout, чтобы процесс успел завершиться аккуратно.

➡️ DevOps Ready | #совет

Почему временные файлы лучше создавать через mktemp?

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

Плохой вариант выглядит так:

tmp="/tmp/app.log"
echo "data" > "$tmp"

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

Чуть лучше, но всё ещё не идеально:

tmp="/tmp/app-$$.log"

$$ добавляет PID процесса, но это не полноценная защита от гонок и предсказуемых имён.

Нормальный способ — mktemp:

tmp="$(mktemp)"

Команда создаёт уникальный файл и сразу возвращает путь к нему:

echo "data" > "$tmp"
cat "$tmp"

А чтобы временный файл точно удалился при выходе из скрипта, добавляют trap:

tmp="$(mktemp)"
trap 'rm -f "$tmp"' EXIT

mktemp убирает риск конфликтов имён и делает временные файлы безопаснее. Для скриптов это маленькая привычка, которая спасает от очень неприятных багов.

➡️ DevOps Ready | #совет