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

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

❓Вопрос: Как работает ядро Linux для управления вводом/выводом и что такое I/O scheduler?

✅Ответ: I/O scheduler в Linux управляет порядком операций ввода/вывода, что важно для эффективного использования дисков и оптимизации работы с данными. Выбор нужного scheduler помогает улучшить производительность системы, особенно при высоких нагрузках.

Основные типы:
• CFQ (Completely Fair Queuing): Равномерное распределение ресурсов для процессов.
• Deadline: Обеспечивает выполнение операций в установленные сроки.
• Noop: Минимальные операции, подходит для систем с кэшированием.

Чтобы проверить текущий scheduler:

cat /sys/block/sda/queue/scheduler

SSSD для интеграции Linux с Active Directory: настройка и тонкости

Интеграция Linux-серверов и рабочих станций в Active Directory (AD) — стандартная задача в смешанных инфраструктурах.

SSSD (System Security Services Daemon) — современный и гибкий способ обеспечить аутентификацию и получение информации из AD без установки громоздких клиентов вроде winbind.

Базовая схема настройки

1️⃣Подключаем Linux к AD

Если есть realmd, достаточно:

realm join example.com -U Administrator

Он автоматически настроит SSSD, Kerberos и разрешения.

Если без realmd — делаем вручную.

2️⃣ Настраиваем /etc/sssd/sssd.conf

Пример минимального конфига:

[sssd]
domains = example.com
config_file_version = 2
services = nss, pam

[domain/example.com]
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
ad_domain = example.com
krb5_realm = EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
fallback_homedir = /home/%u@%d
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False

3️⃣ Права на файл конфигурации

chmod 600 /etc/sssd/sssd.conf

4️⃣ Запускаем и добавляем в автозагрузку

systemctl enable --now sssd

5️⃣ Настраиваем PAM

Обновляем /etc/pam.d/common-auth и common-session для вызова pam_sss.so и автоматического создания домашней директории.

Пример для common-session:

session required pam_mkhomedir.so skel=/etc/skel/ umask=0077

Слепое восстановление root-доступа: когда осталась только консоль или IPMI

Заблокировался root, слетел пароль, SSH не пускает, а у тебя только IPMI или прямой доступ к консоли?

Без паники — вот три проверенных сценария.

Способ 1: init=/bin/bash

Если можешь перезапустить сервер и попасть в GRUB:
1️⃣На экране GRUB выбери нужное ядро и нажми e для редактирования.
2️⃣Найди строку, начинающуюся с linux, и добавь в конец:

init=/bin/bash

3️⃣Нажми Ctrl + X или F10 — система загрузится в bash без пароля.
4️⃣Подмонтируй root в rw:

mount -o remount,rw /

5️⃣Сбрось пароль:

passwd

6️⃣Перезагрузи: exec /sbin/init или просто reboot -f

Способ 2: chroot из Live-ISO или rescue-системы

1️⃣Подключи ISO через IPMI, загрузись в LiveCD.
2️⃣Определи диск: lsblk, fdisk -l
3️⃣Подмонтируй систему:

mount /dev/sdaX /mnt
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt

4️⃣Сбрось пароль: passwd
5️⃣Перезагрузи.

Способ 3: Rescue mode от хостера (если есть)
1️⃣Активируй rescue в панели (Hetzner, OVH, etc.)
2️⃣Подключись по SSH к rescue-системе.
3️⃣Повтори chroot-метод выше.

Samsung откладывает запуск завода чипов в Техасе

Samsung перенесла запуск полупроводникового завода в Техасе как минимум до 2026 года — из-за нехватки заказов на контрактное производство чипов.

Компания теряет позиции: из числа клиентов уже ушли Nvidia и Qualcomm.

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

Завод Samsung был спроектирован под 4-нм техпроцесс с FinFET, но к 2026 году рынок перейдёт на 2-нм технологии и GAA-транзисторы.

Дополнительное давление оказывает строительство флагманского комплекса TSMC в Аризоне стоимостью $100 млрд.

Проблемы с файловыми системами

При использовании SSD для контейнерных решений важно правильно выбрать файловую систему:

• ext4: Подходит для общего использования, но не всегда эффективна при большом числе операций записи, характерных для контейнеров.
• XFS: Хорошо работает с большими файлами, но страдает при работе с мелкими.
• btrfs: Имеет интересные функции, такие как дедупликация и сжатие, но может тормозить при интенсивной записи.

Docker и тома

По умолчанию Docker использует overlay2 для управления слоями контейнеров.

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

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

Причины потери производительности
⏺Журналирование: SSD быстрее работают, но если Docker не оптимизирован для этого, это может привести к потере производительности.
⏺Малые файлы: Контейнеры часто работают с малым количеством данных, что вызывает дополнительные нагрузки на файловую систему.

1️⃣Выбор файловой системы: Для SSD рекомендуется использовать XFS или btrfs, которые лучше справляются с мелкими файлами и высокой нагрузкой.
2️⃣Оптимизация Docker: Отключите избыточное журналирование и используйте bind mount для томов.
3️⃣Настройка SSD: Включите TRIM, чтобы SSD правильно освобождал место и поддерживал свою производительность.
4️⃣Использование ZFS: Если производительность критична, ZFS будет более эффективен в контейнерных окружениях.

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

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

❓Вопрос: Что такое KASLR и как он повышает безопасность ядра Linux?

✅Ответ: KASLR (Kernel Address Space Layout Randomization) — это механизм, который случайным образом размещает ядро и его компоненты в виртуальной памяти при загрузке системы. Цель — усложнить эксплуатацию уязвимостей, основанных на знании точных адресов функций и структур ядра.

Контроль устройств через USBGuard

Как запретить флешки и другие USB-девайсы на уровне ядра

В некоторых инфраструктурах флешки — это не просто риск, а реальный вектор атак.

Чтобы контролировать, какие USB-устройства разрешены, используем USBGuard — мощный инструмент, встроенный в ядро Linux.

Как это работает:
USBGuard создаёт политику разрешённых USB-устройств по их VID/PID и serial number. Всё, что не разрешено — автоматически блокируется.

Быстрый старт:

sudo apt install usbguard
sudo usbguard generate-policy > /etc/usbguard/rules.conf
sudo systemctl enable --now usbguard

По умолчанию все текущие устройства будут разрешены. После запуска новые — блокируются.

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

allow id 0781:5567 serial "4C530001181223103294" name "Cruzer Blade"

Чтобы запретить всё, кроме нужного:
1️⃣Генерируй политику.
2️⃣Удали строки allow with-interface или allow via.
3️⃣Переведи USBGuard в режим enforce.

Интеграция с systemd:

sudo systemctl status usbguard
sudo journalctl -u usbguard

Скрытая перезагрузка Linux

Как понять, что сервер перезапускался, даже если uptime большой

Иногда uptime внушительный, но сервисы «как будто» перезапускались. 

Такое бывает после kexec, resume из сна, контейнерной миграции или даже обмана через sysctl. Разберёмся, как проверить, не было ли на самом деле рестарта.

1️⃣Проверяем journalctl:
Логи systemd разбиты на сессии. Увидим границу между ними:

journalctl --list-boots

Если есть несколько загрузок (boot ID), был перезапуск. Даже если uptime говорит обратное.

2️⃣Логи входов last и btmp:

last reboot

Покажет перезагрузки ядра. Если пусто — подозрительно.

last -f /var/log/btmp

Проверка на сброс логов, частая практика для сокрытия следов.

3️⃣dmesg и таймштампы ядра:

dmesg | head

Таймштамп в первых строках должен совпадать с uptime. Если нет — возможно, kexec или resume.

4️⃣Проверка монтирования /tmp или /run:

mount | grep tmpfs

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

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

❓Вопрос: Как работает oom-killer в Linux и как с ним работать, чтобы минимизировать негативные последствия?

✅Ответ: oom-killer (Out-Of-Memory Killer) — это механизм ядра Linux, который срабатывает, когда системе не хватает оперативной памяти, и она не может выделить память ни одному из процессов. В такой ситуации oom-killer выбирает и завершает “наименее ценную” с точки зрения ядра задачу, чтобы освободить ресурсы.

Как с ним работать:

— Поведение можно контролировать с помощью параметра oom_score_adj. Чем выше значение (макс. 1000), тем выше вероятность, что процесс будет убит.
— Можно настроить cgroups и ограничить память для отдельных групп процессов, чтобы сбои не затрагивали всю систему.
— Желательно использовать swap-файл/раздел, чтобы отложить момент срабатывания OOM, но не полагаться на это как на основную защиту.

Отслеживаем внезапные изменения сетевой конфигурации в Linux

Иногда вы теряете доступ по SSH, DNS резко меняется, а ip route не узнаётся. Причин может быть много: DHCP, VPN, скрипты, NetworkManager или зловред.

Разберём, как это отследить, логировать и сразу получать уведомление — даже в Telegram.

1️⃣Слежение за изменениями IP, DNS и маршрутов

Создаём скрипт check_net.sh, который сравнивает текущие настройки с эталоном:

#!/bin/bash

DIR="/var/lib/netwatch"
mkdir -p "$DIR"

NOW="$DIR/now"
PREV="$DIR/prev"

ip addr > "$NOW".ip
ip route > "$NOW".route
cat /etc/resolv.conf > "$NOW".dns

# Если первая итерация — копируем как эталон
[ ! -f "$PREV.ip" ] && cp "$NOW".ip "$PREV.ip"
[ ! -f "$PREV.route" ] && cp "$NOW".route "$PREV.route"
[ ! -f "$PREV.dns" ] && cp "$NOW".dns "$PREV.dns"

# Проверяем различия
DIFF=$(diff -u "$PREV.ip" "$NOW.ip"; diff -u "$PREV.route" "$NOW.route"; diff -u "$PREV.dns" "$NOW.dns")

if [ -n "$DIFF" ]; then
  echo "$DIFF" | tee "$DIR/alert.log"

  # Отправка в Telegram
  TOKEN="your_bot_token"
  CHAT_ID="your_chat_id"
  MSG="⚠️ Изменение сети на $(hostname):%0A$(echo "$DIFF" | tail -n 20 | sed 's/$/%0A/' | sed 's/+/%2B/g')"
  curl -s "https://api.telegram.org/bot$TOKEN/sendMessage" --data-urlencode "chat_id=$CHAT_ID" --data-urlencode "text=$MSG"

  # Обновляем эталон
  cp "$NOW".ip "$PREV.ip"
  cp "$NOW".route "$PREV.route"
  cp "$NOW".dns "$PREV.dns"
fi

2️⃣Настраиваем таймер systemd (альтернатива cron)

Файл netwatch.timer:

[Unit]
Description=Net config watcher timer

[Timer]
OnBootSec=2min
OnUnitActiveSec=5min

[Install]
WantedBy=timers.target

Файл netwatch.service:

[Unit]
Description=Net config watcher

[Service]
ExecStart=/usr/local/bin/check_net.sh

Активируем:

systemctl daemon-reexec
systemctl enable --now netwatch.timer

3️⃣Дополнительно: auditd и лог изменений конфигов

auditctl -w /etc/network/interfaces -p wa
auditctl -w /etc/netplan -p wa
auditctl -w /etc/resolv.conf -p wa

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

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

❓Вопрос: Что такое kprobes в Linux и как их используют для динамической трассировки ядра?

✅Ответ: kprobes — это механизм динамического внедрения точек останова (проб) в ядро Linux без необходимости перезагрузки системы или модификации исходного кода ядра. Он позволяет выполнять пользовательский код при срабатывании определённых событий, например, вызова функций ядра.

Часть 2. GitOps для /etc: отслеживаем конфигурации через etckeeper и pre-commit хуки

Чтобы избежать потери конфигов даже при сбое системы — добавим резервное копирование git-репозитория /etc в безопасное место.

1️⃣Настроим удалённый репозиторий

Создаём bare-репозиторий на другом сервере или в GitLab/Gitea:

git init --bare /srv/backup/etc.git

На основном сервере:

cd /etc
git remote add backup ssh://user@backup-host/srv/backup/etc.git
git push backup master

2️⃣Добавим автоматический push после каждого commit

Можно прописать post-commit хук:

echo 'git push backup master' > /etc/.git/hooks/post-commit
chmod +x /etc/.git/hooks/post-commit

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

Проверка целостности и откат

Если кто-то случайно удалит или испортит конфиг — откат делается одной командой:

cd /etc
git checkout HEAD^ -- ssh/sshd_config

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

git status       # покажет, что поменялось
git log -p FILE  # покажет кто и когда правил конкретный файл