💬 Вопрос на собеседовании для DevOps-инженера

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Как работать с Terraform State на практике?

✅Ответ: Terraform State используется для хранения текущего состояния инфраструктуры и управления изменениями.

Примеры работы:

1️⃣Просмотр состояния:

terraform show  

Выводит текущее состояние инфраструктуры из файла terraform.tfstate.

2️⃣Обновление состояния вручную: Если ресурс изменился вне Terraform, обновите state:

terraform refresh  

3️⃣Удаление ресурса из state: Если нужно удалить ресурс без фактического удаления из инфраструктуры:

terraform state rm <resource_name>

Протестировали для вас 4 инструмента мониторингов сайтов и серверов - и вот что получилось:

1️⃣ Uptime Kuma: OpenSource, полный контроль, уведомлений (Telegram, Discord и много других), нужно разворачивать и обслуживать сервер.

2️⃣ Kuma Cloud: Та же Uptime Kuma, только в облаке, работает из коробки за 30 секунд, ни каких заморочек, поддержка и авто-обновления.

3️⃣ UpTimeRobot: Бесплатный тариф - 50 мониторов, мало гибкости в настройках, ограниченные уведомления, сильно дороже предыдущих.

4️⃣ Overseer - Простота и минимализм, мало функций, нет детальной аналитики, дёшево.

✅ Почему Kuma Cloud - наш выбор?
- Быстрее, чем разворачивать самому
- Мощнее, чем UptimeRobot и Overseer
- Тесная интеграция с Telegram

Профили пользователя Bash: как всё устроено и зачем это знать

Bash — самая распространённая командная оболочка в Linux. 

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

Разберём, как они работают и что с ними можно делать на практике.

Что происходит при запуске Bash?

Bash может работать в двух режимах: login shell (при входе в систему) и interactive non-login shell (обычное открытие терминала). В зависимости от сценария запуска, загружаются разные файлы:

При входе в систему (login shell):
⏺/etc/profile — глобальный скрипт инициализации;
⏺/etc/profile.d/*.sh — дополнительные скрипты, подключаемые через profile;
⏺один из: ~/.bash_profile, ~/.bash_login, ~/.profile (в Ubuntu чаще всего это ~/.profile, ссылающийся на ~/.bashrc).

При запуске терминала (non-login shell):
• /etc/bash.bashrc или /etc/bashrc;
• ~/.bashrc.

Также есть ~/.bash_logout, который выполняется при выходе из сессии.

Как это использовать на практике?

1. Настройка переменных окружения
В ~/.bashrc или ~/.profile удобно добавлять переменные окружения:

export EDITOR=nano
export PATH="$PATH:$HOME/scripts"

2. Часто используемые команды — в функции
Если вы часто запускаете цепочки команд, создайте функцию:

function logs() {
  cd /var/log && ls -lt | head
}

3. Инициализация новых пользователей
Все, что лежит в /etc/skel/, будет копироваться в домашнюю папку новых пользователей:

/etc/skel/.bashrc
/etc/skel/.profile

Хотите, чтобы у каждого нового пользователя были кастомные алиасы, переменные или структура папок — добавьте это сюда.

4. Настройка путей и alias’ов
В ~/.bashrc можно настраивать alias:

alias ll='ls -lah'
alias gs='git status'

Проверка работы профилей

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

echo "Loaded ~/.bashrc" >> ~/bash_debug.log

Почему netstat лжёт: как ss показывает реальную картину с сокетами

В современном Linux часто применяются инструменты для мониторинга сетевых соединений.

Несмотря на свою популярность, утилита netstat уже не всегда предоставляет точную информацию о состоянии сокетов.

Неточное отображение состояний с netstat

Netstat долгое время был основным инструментом для вывода информации о сетевых соединениях, но его алгоритмы и подходы к сбору статистики имеют ограничения:

⏺Netstat опирается на данные из /proc, которые могут не отражать динамическое изменение состояния сокетов. В результате он часто показывает устаревшую информацию, например, “мертвые” или заброшенные сокеты, которые уже не участвуют в активной передаче.

⏺При анализе состояний, таких как FIN_WAIT2, netstat может некорректно интерпретировать “зависшие” соединения. Это может ввести администратора в заблуждение относительно истинной загрузки и стабильности системы.

Преимущества ss: точные и детальные данные

Современный инструмент ss (socket statistics) из пакета iproute2 разработан для замены netstat и предоставляет гораздо более подробную и актуальную информацию о сетевых сокетах.

Он способен отсеивать “мертвые” соединения, корректно отображать переходные состояния и использовать расширенные опции для фильтрации и диагностики.

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

ss -tan

Здесь ключи означают:
• -t – вывести только TCP-соединения,
• -a – показать все (слушающие и установленные),
• -n – вывод номеров портов в числовом виде.

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

ss -tan state fin-wait-2

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

Это даёт возможность отфильтровать ложные сигналы и сконцентрироваться на проблемных соединениях. Пример использования:

ss -K state established

Эта команда попытается “убить” (удалить) неактивные или ошибочные соединения, предоставляя отчёт о том, какие сокеты останутся в системе после вмешательства. Такой уровень контроля невозможен с netstat.

Как узнать причину перезагрузки Linux

Неожиданная перезагрузка Linux-сервера — это всегда тревожный звоночек. Иногда виноват админ, иногда — ядро, а иногда — железо. Разберём, как правильно искать первопричину, чтобы не гадать на кофейной гуще.

1️⃣Кто и когда перезагружал?

Команды:

who -b     # Показывает последнее время загрузки
last reboot # Список всех событий перезагрузки

Это даст базовую точку отсчёта: когда именно сервер перезапустился.

2️⃣ Логи — наше всё

Сравниваем время перезагрузки с системными журналами:
• RHEL/CentOS: /var/log/messages
• Ubuntu/Debian: /var/log/syslog

Ищем фрагменты про shutdown, poweroff, reboot. Можно фильтровать, чтобы убрать шум:

sudo grep -iE 'recover|power|shutdown|rsyslogd|ups' /var/log/{messages,syslog}

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

3️⃣ auditd: ищем системные события

Если стоит auditd, смотрим аккуратные записи про загрузку и остановку:

sudo ausearch -i -m system_boot,system_shutdown | tail -4

Если видим две подряд строки SYSTEM_BOOT — значит, скорее всего, была авария или падение питания.

4️⃣

journalctl: работа с историей загрузок

Если настроено сохранение логов в /var/log/journal, можно получить историю перезагрузок:

journalctl --list-boots
journalctl -b -1     # Смотрим предыдущую загрузку

Так можно увидеть, были ли перед перезагрузкой ошибки типа OOM, kernel panic или странные systemd-события.

Если логов мало — проверьте, создан ли каталог для хранения:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl kill -s SIGUSR1 systemd-journald

💬 Вопрос на собеседовании для сисадмина

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Как работает механизм KSM (Kernel SamePage Merging) и для чего он используется в Linux?

✅Ответ: KSM (Kernel SamePage Merging) — это механизм в ядре Linux, который позволяет сливать идентичные страницы памяти, используемые разными процессами, с целью экономии оперативной памяти. Этот процесс особенно полезен в виртуализированных средах, где виртуальные машины могут использовать одинаковые данные.

🚀 Всё для сисадминов и директоров по ИТ – в одном месте!

✅ Рекомендации:

— Linux Command Library — справочник по командам Linux
— SAD Servers — тренажёр для отладки Linux-систем
— Kubectl-neat — плагин удаляющий беспорядок в Kubernetes
— Pro Git — бесплатная книга по Git на русском языке

✅ Импортозамещение:

— Облака на практике и в теории
— Облака: итоги 2024 и прогнозы 2025
— SpaceVM: исследование и создание кластера с 0
— FreeGRID: механизм работы карт NVIDIA без лицензий

✅ Инфобез:

— Проверки Роскомнадзора по ПДн: инструкция по подготовке
— Проверки Роскомнадзора по ПДн: часть 2
— 8 трендов в ИБ 2025-2027
— Сравнение сертифицированных антивирусных средств защиты информации

➡️ Присоединяйтесь к каналу для ДИТов

Реклама ООО "Кортэл"
ИНН: 7816246925

Установка Xfce на Ubuntu Server: когда нужен лёгкий GUI

Если нужен графический интерфейс, но GNOME слишком тяжёл, Xfce — отличная альтернатива. Идеален для VPS, embedded-серверов и слабого железа.

⏺Обновим систему:

sudo apt update && sudo apt upgrade

⏺Установим Xfce:

sudo apt install xubuntu-desktop

Или минимальный вариант:

sudo apt install xfce4 slim

slim — это лёгкий дисплей-менеджер. Вместо него можно поставить lightdm:

sudo apt install lightdm

⏺Убедитесь, что выбран нужный менеджер:

cat /etc/X11/default-display-manager

⏺Запуск и остановка GUI:

sudo service lightdm start
sudo service lightdm stop

Или, если slim:

sudo service slim start

Вышел 4MLinux 48.0: ядро 6.12, улучшенный мультимедиа и поддержка KVM-дисков

Разработчик Збигнев Конояцкий представил стабильный релиз 4MLinux 48.0 — облегчённого дистрибутива на базе JWM. В этой версии:

⏺Обновлено ядро до Linux 6.12 LTS, добавлена поддержка установки на диски вида /dev/vda1 (виртуалки KVM).
⏺Включён видеоредактор Kino, несмотря на его возраст.
⏺В набор кодеков добавлен VVenC (H.266/VVC).
⏺Новые опции в расширениях: FreeTube, Bristol, новые версии VLC, GIMP, LibreOffice, Chrome и Firefox.
⏺Улучшена обработка звука, масштабирование видео и драйверы печати.

Сборка 4MServer получила обновлённый LAMP-стек и языки Python, Ruby, Perl.
Релиз доступен в вариантах Full, Core и Server, только для 64-битных систем.

Chrootjail что это и зачем нужно?

Когда нужна изоляция без контейнеров и виртуалок — на помощь приходит chroot.

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

Получается простейшая “тюрьма”, где процессы не видят остальную систему.

Зачем это вообще нужно?
⏺Запустить старую версию приложения с отдельной glibc
⏺Изолировать демоны, если нет systemd-nspawn / Docker
⏺Обеспечить восстановление системы из Live-среды
⏺Сделать легковесный dev-stand или jail для CI

Как поднять chroot jail с bash и ls?

mkdir -p chroot_jail/{bin,lib/x86_64-linux-gnu,lib64}
cp $(which bash) $(which ls) chroot_jail/bin/

Теперь подтянем зависимости. Смотрим, что нужно bash:

ldd $(which bash)

И копируем их:

cp /lib/x86_64-linux-gnu/libtinfo.so.6 chroot_jail/lib/x86_64-linux-gnu/
cp /lib/x86_64-linux-gnu/libdl.so.2 chroot_jail/lib/x86_64-linux-gnu/
cp /lib/x86_64-linux-gnu/libc.so.6 chroot_jail/lib/x86_64-linux-gnu/
cp /lib64/ld-linux-x86-64.so.2 chroot_jail/lib64/

Повторяем то же для ls. Когда всё готово — запускаем:

sudo chroot chroot_jail /bin/bash

Теперь вы в полностью изолированной среде, где доступны только скопированные бинарники и библиотеки. Можно использовать ls, запускать скрипты, писать тесты.

💬 Вопрос на собеседовании для DevOps-инженера

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Как работает механизм Remote Backend в Terraform и зачем он нужен?

✅Ответ: Remote Backend — это механизм, позволяющий хранить файл состояния Terraform (terraform.tfstate) не локально, а в удалённом хранилище (например, S3, Azure Blob, GCS, HashiCorp Consul или Terraform Cloud). Это важно при работе в команде и для обеспечения согласованности состояния.

Примеры и особенности:

1️⃣Настройка S3 backend’а:

terraform {
  backend "s3" {
    bucket = "my-tf-state"
    key    = "prod/terraform.tfstate"
    region = "us-west-2"
  }
}

2️⃣ Блокировка состояния: В связке с DynamoDB Terraform может использовать блокировки, предотвращая параллельные изменения:

dynamodb_table = "terraform-locks"

3️⃣ Безопасность и доступ: Доступ к Remote Backend можно ограничить IAM-политиками или credentials-файлами, повышая безопасность при работе в CI/CD.

Почему DNS-трафик из контейнеров пропадает при смене сети

Один из тех багов, что легко пропустить, пока не начнёт сбоить прод: контейнер теряет резолвинг после смены сети или рестарта systemd-resolved, хотя хост чувствует себя нормально.

Виноват — встроенный DNS в Docker (127.0.0.11), работающий только внутри namespace и не всегда переживающий перезапуск или смену маршрутов.

Docker по умолчанию использует embedded DNS-сервер на 127.0.0.11, который находится внутри каждого сетевого namespace. Он проксирует DNS-запросы от контейнеров к системному DNS, но:

⏺При смене сети (например, ifdown/ifup) dockerd не пересобирает конфигурацию;
⏺При перезапуске systemd-resolved или NetworkManager upstream-адреса становятся недоступны;
⏺Контейнер продолжает слать DNS-запросы, но получает таймаут или пустой ответ.

Как лечить
1️⃣Отключить встроенный DNS:

{
  "dns": ["1.1.1.1", "8.8.8.8"],
  "dns-opt": ["use-vc"]
}

в /etc/docker/daemon.json

2️⃣ Прописать резолверы явно в docker run:

docker run --dns=1.1.1.1 --dns-opt=use-vc ...

3️⃣ Проверить работу через nslookup/dig внутри контейнера:

docker exec -it container sh
dig ya.ru

4️⃣ Следить за iptables -t nat — DNS может сломаться из-за неправильного SNAT в bridge-сетях.

Когда особенно критично
В k8s с Docker runtime, на embedded-системах или в CI, где DHCP может пересобирать сетевой стек. Там лучше не полагаться на автоматическую проксирующую магию.