Admin Future
242 subscribers
50 photos
1 video
4 files
87 links
Превращаем эникейщиков в System Architects.
🚀 Твой навигатор в мире IT-инфраструктуры:

▪️ Hard Skills: Linux, Windows, Network, Security
▪️ Tools: Лучший софт и скрытые фишки
▪️ Mindset: Как думать, чтобы платили много


Админ - @maksimshap
Download Telegram
🪟 Windows: dMSA в Server 2025 — Microsoft дала нам инструмент и сразу два способа им порезаться

Коллеги, поговорим о ситуации, которую я называю "security feature, meet security incident". Windows Server 2025 принёс delegated Managed Service Accounts (dMSA) — красивая замена старым сервисным учёткам с паролем "Service2019!" в Confluence. dMSA привязывает аутентификацию к идентичности конкретной машины: только явно указанные машины в AD могут получить доступ к учётной записи, что закрывает классический Kerberoasting.

Звучит хорошо. Но есть нюанс.

Исследователи из Akamai нашли атаку BadSuccessor: злоумышленник с минимальными правами на любой OU в домене может создать вредоносный dMSA, который имитирует процесс миграции и наследует все права любого пользователя — вплоть до Domain Admin. При этом права над целевой учёткой не нужны вообще. Patch до сих пор в разработке.

Что делать прямо сейчас — аудит и ограничение прав на создание dMSA:


# Akamai выпустили скрипт для аудита — запускаем и смотрим кто может создавать dMSA
# Скачиваем с их GitHub:
# https://github.com/akamai/BadSuccessor

# Ручная проверка — кто имеет право создавать объекты типа msDS-DelegatedServiceAccount в OU
Import-Module ActiveDirectory

$OUs = Get-ADOrganizationalUnit -Filter * -Properties nTSecurityDescriptor

foreach ($OU in $OUs) {
$acl = Get-Acl "AD:$($OU.DistinguishedName)"
$acl.Access | Where-Object {
$_.ActiveDirectoryRights -match "CreateChild" -and
$_.ObjectType -eq [guid]"ce206244-5827-4a86-ba1c-1c0c386c1b64"
# ObjectType для msDS-DelegatedServiceAccount
} | Select-Object IdentityReference, ActiveDirectoryRights |
ForEach-Object {
[PSCustomObject]@{
OU = $OU.Name
Identity = $_.IdentityReference
Rights = $_.ActiveDirectoryRights
}
}
} | Format-Table -AutoSize | Export-Csv "dMSA_create_rights_audit.csv" -NoTypeInformation

# Включаем аудит событий dMSA — чтобы хотя бы видеть атаку
auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable

# Мониторим Event ID 5136 — изменения атрибута msDS-DelegatedMSAState
# и Event ID 4662 — изменения msDS-ManagedAccountPrecededByLink
# Эти два события вместе = сигнал возможной BadSuccessor-атаки
Get-WinEvent -LogName "Security" -FilterXPath `
"*[System[EventID=5136] and EventData[Data[@Name='AttributeLDAPDisplayName']='msDS-DelegatedMSAState']]" |
Select TimeCreated, Message | Format-List


Зачем это нужно:
По данным Akamai, в 91% исследованных сред нашлись пользователи за пределами группы Domain Admins, у которых были права для проведения этой атаки. Если у вас Server 2025 DC в домене — проверьте, кто может создавать dMSA объекты, прямо сегодня. Это займёт 10 минут.

Итог: Microsoft сделала dMSA для защиты от Kerberoasting — и это правильно. Но разворачивать новую фичу в продакшн без аудита прав — всё равно что поставить бронедверь и забыть закрыть окно. Следите за патчем.

#windows #activedirectory #security #dmsa #kerberos #sysadmin #admin_future
🧠 Skills: Ты единственный, кто знает как это работает. Поздравляю, ты создал себе тюрьму

Коллеги, давайте честно. У каждого из нас есть тот самый сервис, скрипт или конфиг, про который знает только один человек. Ты. И каждый раз, когда ты уходишь в отпуск — телефон не замолкает. Это не уважение к твоей экспертизе. Это Bus Factor = 1, и он убивает и команду, и тебя.

Я это называю "знаниевый монополизм". Он возникает не из жадности — он возникает из того, что некогда было написать документацию, некогда объяснить коллеге, некогда сделать нормальный runbook. И вот ты незаменим. Звучит как комплимент, пока не звонит телефон в 23:47 в субботу.

Хороший runbook — это не просто список шагов. Это живой документ с метаданными: кто владелец, когда последний раз тестировался, какой канал для эскалации, сколько времени займёт выполнение. Именно это отличает документ, который реально используют, от того, что пылится в Confluence с 2021 года.

Шаблон runbook, который реально работает:


---
title: Перезапуск кластера PostgreSQL при split-brain
id: RB-DB-003
version: 1.2.0
last_updated: 2026-04-15
last_tested: 2026-03-01
owner: @your_name
slack_channel: "#infra-oncall"
estimated_duration: 20-40 минут
risk_level: high
requires_approval: true (Роман или тимлид)
---

## Когда использовать
- Alert: "PostgreSQL replication lag > 300s"
- Alert: "Primary node unreachable"
- Симптом: приложение пишет ошибки "could not connect to server"

## Шаг 1 — Диагностика (5 мин)
Проверяем состояние кластера:
$ patronictl -c /etc/patroni/config.yml list
Ожидаемый вывод: один Leader, остальные Replica

## Шаг 2 — Проверка репликации
$ psql -h localhost -U postgres -c "SELECT * FROM pg_stat_replication;"
Если пусто на мастере — реплика отстала или отвалилась.

## Шаг 3 — Failover (только если мастер недоступен)
$ patronictl -c /etc/patroni/config.yml failover --master <node> --candidate <replica>
ВНИМАНИЕ: действие необратимо без ручного вмешательства.

## Шаг 4 — Проверка после failover
$ patronictl -c /etc/patroni/config.yml list
$ psql -h <new_master> -U postgres -c "SELECT pg_is_in_recovery();"
Ожидаемый результат: false (мы на новом мастере)

## Контакты эскалации
- L2: @colleague_name (Telegram)
- L3: вендор поддержки (тикет в портале)

## История изменений
- 1.2.0 (2026-04-15): добавлен шаг проверки pg_stat_replication
- 1.1.0 (2026-02-01): обновлён путь конфига Patroni


Зачем это нужно:
Системы меняются, но документация часто — нет. Решение: триггеры на ревью runbook при изменении инфраструктуры. Когда меняется инфраструктурный код — автоматически флагируются связанные runbook-ы для обновления. Это не бюрократия. Это то, что позволяет тебе нормально спать в отпуске.

Итог: Незаменимых специалистов не бывает — бывают люди, которые не успели или не захотели передать знания. Runbook — это не слабость. Это признак зрелого инженера, который думает о команде, а не только о своей незаменимости.

#skills #documentation #runbook #sysadmin #teamwork #admin_future
🎓 Собеседование сисадмина. Выпуск #12: Kubernetes — то, что спрашивают в 2026 году

Коллеги! Продолжаем марафон. После выпуска про распределённые хранилища (Ceph, Longhorn) логичный следующий шаг — оркестрация. В 2026-м Kubernetes перестал быть "DevOps-штучкой" и стал стандартной частью инфраструктуры даже в небольших компаниях. А значит, сисадмин, который не понимает K8s, — это уже не сисадмин, это билет на понижение.

Три вопроса, на которых плывут даже те, кто "работает с кубером каждый день".

---

Вопрос 1: «Pod завис в статусе CrashLoopBackOff. Ваши действия?»

Ответ новичка: «Удалю pod и пересоздам, он же сам поднимется».

Ответ инженера:
CrashLoopBackOff означает, что контейнер запускается, падает, Kubernetes пытается его поднять снова — и так по кругу. Задача: найти причину, а не перезапускать вслепую.

Алгоритм траблшутинга:


# Шаг 1 — Смотрим текущие логи
kubectl logs <pod-name> -n <namespace>

# Если контейнер упал слишком быстро — логи уже улетели.
# Берём логи предыдущего запуска:
kubectl logs <pod-name> -n <namespace> --previous

# Шаг 2 — Описание pod: ищем Reason в Last State
kubectl describe pod <pod-name> -n <namespace>
# Смотрим секцию "Last State" и "Events"
# Причины бывают разные:
# OOMKilled -> контейнер убит за превышение лимита памяти
# Error (exit 1) -> приложение упало само (ошибка конфига/зависимость)
# RunContainerError -> не может стартовать (нет образа, нет прав на том)

# Шаг 3 — Если OOMKilled: смотрим лимиты и правим манифест
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[0].resources}'
# Временно поднимаем memory limit, чтобы убедиться в диагнозе:
# resources.limits.memory: 512Mi -> 1Gi

# Шаг 4 — Проверяем ConfigMap и Secret: существуют ли они в этом namespace?
kubectl get configmap -n <namespace>
kubectl get secret -n <namespace>
# Если приложение не может найти конфиг — оно упадёт с exit code 1


Ключевая мысль: Удалить и пересоздать pod — это лечить симптом, не болезнь. Kubernetes и сам это делает. Ваша работа — понять, почему падает.

---

Вопрос 2: «В чём разница между Liveness Probe и Readiness Probe? Что будет, если их перепутать?»

Ответ новичка: «Оба проверяют здоровье контейнера. Liveness — жив ли, Readiness — готов ли».

Ответ инженера:
Определение правильное, но поверхностное. Интервьюер ждёт понимания последствий.

Liveness Probe — отвечает на вопрос "не завис ли процесс?". Если проверка провалилась — Kubernetes убивает контейнер и перезапускает его. Используется, чтобы выйти из дедлоков и зависаний.

Readiness Probe — отвечает на вопрос "можно ли слать трафик?". Если проверка провалилась — pod убирается из балансировки Service, но не перезапускается. Используется при старте, когда приложение ещё прогревается (warm-up, загрузка кэша).

Что будет если перепутать:


# ПЛОХОЙ пример: Liveness смотрит на /ready (страница прогрева)
# При старте приложению нужно 30 секунд на инициализацию БД.
# Liveness видит 503 -> убивает контейнер -> перезапускает -> снова 503
# -> бесконечный CrashLoopBackOff на старте.

# ПРАВИЛЬНАЯ конфигурация:
livenessProbe:
httpGet:
path: /healthz # Легкая проверка: "процесс жив?"
port: 8080
initialDelaySeconds: 10
periodSeconds: 15
failureThreshold: 3

readinessProbe:
httpGet:
path: /ready # Тяжелая проверка: "готов принимать трафик?"
port: 8080
initialDelaySeconds: 20 # Даём время на прогрев
periodSeconds: 5
failureThreshold: 2


Pro-tip для собеса: Добавьте, что в 2026 году есть ещё Startup Probe — третий вид. Он запускается только при старте контейнера и блокирует Liveness/Readiness до тех пор, пока приложение не стартует успешно. Идеален для тяжёлых Java- и .NET-приложений с долгой инициализацией.

---

Вопрос 3: «Kubernetes Secrets хранят пароли. Насколько они безопасны "из коробки"?»

Ответ новичка: «Secrets зашифрованы, поэтому безопасны».

Ответ инженера:
Это самая распространённая ошибка на собесах. Secrets "из коробки" — это НЕ шифрование.
По умолчанию Kubernetes Secrets хранятся в etcd только в формате base64, а не в зашифрованном виде. В продакшне необходимо включать шифрование данных at rest и ограничивать доступ через RBAC.

Base64 — это кодировка, а не шифрование. Любой, у кого есть доступ к etcd или к объекту Secret в API — видит пароль в открытом виде.

Как это исправить — три уровня защиты:


# Уровень 1: Включаем Encryption at Rest в etcd
# В конфиге kube-apiserver добавляем:
# --encryption-provider-config=/etc/kubernetes/enc/enc.yaml
# enc.yaml:
# resources:
# - resources: ["secrets"]
# providers:
# - aescbc:
# keys:
# - name: key1
# secret: <base64-encoded-32-byte-key>
# - identity: {}

# Уровень 2: RBAC — минимальные права на чтение Secrets
kubectl create role secret-reader \
--verb=get,list \
--resource=secrets \
--namespace=production

# Уровень 3 (продакшн-стандарт 2026): External Secrets Operator
# Secrets хранятся в Vault / AWS Secrets Manager / Azure Key Vault
# Kubernetes их НИКОГДА не держит у себя в etcd
# Манифест ExternalSecret:
# apiVersion: external-secrets.io/v1beta1
# kind: ExternalSecret
# spec:
# secretStoreRef:
# name: vault-backend
# data:
# - secretKey: db-password
# remoteRef:
# key: production/db
# property: password


Секреты никогда не должны попадать в Git в открытом виде. Стандарт 2026 года: внешние хранилища (HashiCorp Vault, Cloud KMS) с инъекцией через External Secrets Operator или CSI-драйвер.

---

💡 Золотое правило собеса: Когда вас спрашивают про Kubernetes — интервьюер проверяет не знание синтаксиса kubectl, а понимание того, что происходит под капотом. Фраза "pod упал — я смотрю логи предыдущего запуска через --previous флаг, потому что текущие уже затёрты" — мгновенно выдаёт человека, который это делал в реальном продакшне, а не только читал документацию.

Сохраняйте пост — Kubernetes на собесах уже не опциональная тема!

#собеседование_AF #kubernetes #k8s #devops #sysadmin #контейнеры #admin_future
👍1
🐧 Linux: systemd 260 убил SysV — и если у тебя ещё живёт /etc/init.d, читай срочно

Коллеги, 17 марта 2026 года вышел systemd 260 — и он сделал то, о чём предупреждали несколько лет. Наиболее разрушительное изменение: полное удаление поддержки System V init-скриптов. Компоненты systemd-sysv-generator, systemd-sysv-install и rc-local.service удалены окончательно. Никакого мягкого устаревания — мост сожжён.

Если у вас в продакшне живут legacy-сервисы со скриптами в /etc/init.d/ — они тихо перестанут запускаться после обновления. Без ошибок в журнале. Просто не стартуют.

Но в этом же релизе есть кое-что интересное: добавлен новый параметр MemoryTHP= для управления Transparent Huge Pages на уровне отдельного сервиса, а CPUSchedulingPolicy= теперь поддерживает значение ext для включения планировщика SCHED_EXT. Для высоконагруженных сервисов — это прямой рычаг тонкой настройки без правки параметров ядра глобально.

Сначала — аварийный аудит. Находим всё, что ещё на SysV:


# Ищем живые SysV-скрипты в системе
find /etc/init.d/ -type f -not -name "README" 2>/dev/null

# Проверяем, нет ли сервисов без native unit-файла
# (до обновления на systemd 260 — sysv-generator ещё конвертировал их)
systemctl list-units --type=service --state=loaded | grep -v ".service"

# Смотрим, какие сервисы СЕЙЧАС запущены через SysV-совместимость
systemctl list-units --type=service | \
while read unit _; do
unit_file=$(systemctl show "$unit" -p FragmentPath --value 2>/dev/null)
[[ "$unit_file" == /etc/init.d/* ]] && echo "LEGACY SysV: $unit -> $unit_file"
done

# Для найденного legacy-сервиса пишем нормальный unit.
# Пример: конвертируем старый /etc/init.d/myapp
cat > /etc/systemd/system/myapp.service << 'EOF'
[Unit]
Description=My Legacy Application
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/bin/myapp --daemon
ExecStop=/usr/local/bin/myapp --stop
PIDFile=/var/run/myapp.pid
Restart=on-failure
RestartSec=5s

# Новое в systemd 260: тонкая настройка памяти для сервиса
# Отключаем THP для Java-приложений (они его не любят)
MemoryTHP=never

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now myapp.service
systemctl status myapp.service


Зачем это нужно:
Сервисы, у которых нет native unit-файлов, после обновления на systemd 260 не запустятся тихо и без предупреждений. Самый критичный action item для всех администраторов — провести аудит и мигрировать оставшиеся SysV init-скрипты до обновления. Ubuntu 26.04 LTS выходит 23 апреля и несёт systemd 260 по умолчанию. Срок — неделя.

Итог: SysV жил с 1983 года. Хватит. Если у тебя до сих пор есть /etc/init.d/что-то — это не legacy, это пожарная опасность. Миграция на unit-файл занимает 15 минут. Объяснение инциденту на встрече с Романом — значительно дольше.

#linux #systemd #sysv #sysadmin #ubuntu #admin_future
🪟 Windows: Hotpatch по умолчанию с мая 2026 — разбираемся, что это значит для твоей инфраструктуры

Коллеги, тихая, но важная новость: начиная с майского обновления безопасности 2026 года, Windows Autopatch включает hotpatch-обновления по умолчанию для всех eligible-устройств под управлением Microsoft Intune. Если ты управляешь парком Windows 11 24H2 через Intune — с мая твои машины начнут получать патчи безопасности без перезагрузки. Автоматически. Хочешь ты этого или нет.

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

Как это работает: hotpatch следует строгому квартальному циклу: в январе, апреле, июле и октябре — полное накопительное обновление с перезагрузкой (baseline), в остальные месяцы — hotpatch-пакеты, которые патчат только код запущенных процессов в памяти, без рестарта. Итого: 4 перезагрузки в год вместо 12.

Звучит идеально. Но есть нюансы:


# Проверяем, готово ли устройство к hotpatch
# Требования: Windows 11 24H2+, VBS включён, апрельский baseline установлен

# 1. Проверяем версию и билд
Get-ComputerInfo | Select-Object WindowsVersion, OsBuildNumber, OsDisplayVersion

# 2. Проверяем статус Virtualization-Based Security (обязательное требование)
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
Select-Object VirtualizationBasedSecurityStatus
# 2 = Running (хорошо), 0 = Not enabled (hotpatch не получим)

# 3. Смотрим в Intune — статус по устройствам (через Graph API)
# Или через портал: Intune -> Devices -> Monitor -> Hotpatch quality update report

# 4. Если нужно ОТКЛЮЧИТЬ hotpatch для группы устройств или всего тенанта
# Intune -> Devices -> Windows updates -> Quality updates -> Edit policy
# Переключить "When available, apply without restarting" -> Block

# 5. Через реестр на конкретной машине (для тестовых сценариев)
Set-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" `
-Name "HotPatchRestrictions" `
-Value 1 -Type DWORD
# Value 1 = отключить hotpatch, Value 0 = включить

# 6. Проверяем, какой тип обновления был установлен последним
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5
# Hotpatch-обновления будут иметь KB-номер с пометкой "Hotpatch" в описании


Важное предупреждение, которое Microsoft тихо упомянула в документации: устройства с включённым hotpatch могут падать при операции "Reset This PC" — после первой фазы сброса машина перезагружается обратно на рабочий стол с ошибкой. Это задокументированная проблема. Если у тебя есть сценарии переустановки через Push Button Reset — проверь это в лабе до мая.

Зачем это нужно:
Устройства, установившие апрельский baseline и соответствующие требованиям, начнут автоматически получать hotpatch-обновления с 11 мая 2026 года. Если ты ещё не готов — контроль отказа доступен с 1 апреля через Intune. Срок уже прошёл. Проверяй настройки сегодня.

Итог: Меньше перезагрузок — это хорошо для uptime и для нервов пользователей. Но "включилось само" в enterprise без понимания механики — это риск. Проверь VBS на всём парке, убедись в апрельском baseline и реши явно: включаешь или отключаешь. Случайных изменений в инфраструктуре не бывает.

#windows #hotpatch #intune #autopatch #patching #sysadmin #admin_future
🧠Skills: Технический долг инфраструктуры — как объяснить бизнесу, почему "оно работает" это не аргумент

Коллеги, поговорим о разговоре, который рано или поздно происходит у каждого из нас. Ты приходишь к руководителю и говоришь: нам нужно время и ресурсы, чтобы переписать вот это, обновить вот то, заменить вот это. Он смотрит на тебя и говорит: "А что сейчас не работает?" И технически он прав — оно работает. Просто это бомба с таймером.

Это и есть технический долг инфраструктуры. И проблема не в том, что ты его не видишь. Проблема в том, что ты не умеешь его показать.

По данным McKinsey, 30 процентов ИТ-директоров считают, что более 20 процентов их бюджета уходит на обслуживание технического долга. Переведи это на язык своей компании — и разговор с руководством сразу становится другим.

Практический фреймворк: инвентаризация и приоритизация долга

Разделите ваши проблемы на понятные категории с указанием риска:

— Инфраструктурный долг: серверы без IaC, ручной деплой. Риск: Высокий. Чинить нужно первым, так как рутина умножает все остальные проблемы.
— Долг зависимостей: условная CentOS 7 в продакшене. Риск: Критический.
— Долг безопасности: сервисные учетные записи с паролями пятилетней давности. Риск: Критический.
— Долг документации: инфраструктуру знает только один админ, нет инструкций по восстановлению. Риск: Средний, но становится критичным при любых изменениях в команде.
— Архитектурный долг: монолитные решения без возможности быстрого отката. Риск: Высокий. Стратегическая задача.


Формула для разговора с руководством:
Стоимость долга = (часы в неделю на поддержку) умножить на (ставку инженера) умножить на 52 недели.


Пример:
Поддержка старой ОС без обновлений: 3 часа в неделю х 3000 рублей в час х 52 = 468 000 рублей в год.
Это только один пункт из вашего списка.
Миграция на новую систему займет 80 часов один раз = 240 000 рублей. Окупаемость очевидна любому директору.

Как говорить об этом с бизнесом — три правила:

Первое. Никогда не говори "нам нужно переписать". Говори: "Сейчас мы тратим X часов в месяц на поддержку этого. После модернизации — Y. Разница = Z рублей в год." Фраза "это сэкономит бизнесу полмиллиона в год" работает значительно лучше технических терминов.

Второе. Приоритизируй по принципу "что упадет первым и сколько это будет стоить". Инфраструктурный долг и долг безопасности надо чинить первыми. Старая ОС без патчей в 2026 году — это не техдолг, это открытая дверь для шифровальщика.

Третье. Веди реестр долга публично. В трекере, видимом команде и руководству. Описание, риск, стоимость поддержки в год, стоимость устранения. Когда руководитель видит список из 15 строк с итоговой суммой потерь внизу — разговор о выделении времени идет иначе.


Зачем это нужно:
Технический долг не исчезает от того, что о нем молчат. Он накапливается — тихо, как проценты по кредиту. И платить по нему приходится либо планово (когда ты контролируешь ситуацию), либо аварийно (когда упало в пятницу вечером). Второй вариант всегда дороже.

Итог: Твоя работа — не только чинить то, что сломалось. Твоя работа — объяснять руководству, что сломается следующим и во сколько это обойдется. Инженер, который умеет переводить технический долг в деньги — это человек, с которым бизнес разговаривает на равных.

#skills #techdebt #sysadmin #карьера #инфраструктура #admin_future
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥21
🐧 Linux: SCHED_EXT — BPF-планировщик процессов, который меняет правила игры

Коллеги, пока все обсуждают systemd 260 и смерть SysV, в ядре тихо созревает кое-что значительно интереснее. SCHED_EXT — это extensible scheduler class для Linux, позволяющий загружать собственные планировщики CPU прямо из userspace через eBPF, без перекомпиляции ядра и перезагрузки сервера. Это не экспериментальная игрушка — это то, на что обратились инженеры из Meta, Google и NVIDIA.

Почему это важно для нас, а не только для датацентров?

Стандартный CFS (Completely Fair Scheduler) хорошо работает в среднем, но проваливается при специфических нагрузках. Нет контроля над реальными приоритетами внутри CPU, nice-значения слишком грубые. Реальтайм-классы (SCHED_FIFO, SCHED_RR) опасны — один зависший RT-процесс может заморозить систему. SCHED_EXT решает это элегантно.

Главное преимущество: BPF-верификатор гарантирует, что твой кастомный планировщик не может сломать ядро или вызвать бесконечный цикл. Если планировщик ведёт себя неправильно и задача не получает CPU дольше 30 секунд — ядро автоматически убивает BPF-планировщик и возвращает всё на CFS. Fail-safe из коробки.

Практика — запускаем готовый планировщик на продакшн-хосте:


# Устанавливаем пакет с готовыми BPF-планировщиками
# Fedora / RHEL 10:
dnf install scx-scheds

# Ubuntu 26.04 (из репозитория):
apt install scx-scheds

# Проверяем статус SCHED_EXT в ядре
cat /sys/kernel/sched_ext/state
# disabled — нет активного планировщика, ядро использует CFS

# Запускаем scx_lavd — оптимизирован для latency-чувствительных нагрузок
# (хорошо для баз данных, веб-серверов, очередей)
sudo scx_lavd --performance &

# Проверяем что планировщик активен
cat /sys/kernel/sched_ext/state # -> enabled
cat /sys/kernel/sched_ext/root/ops # -> lavd

# Смотрим статистику планировщика в реальном времени
sudo scx_lavd --performance --stats 2

# Для тонкой настройки — scx_layered позволяет создавать слои приоритетов
# Например: критические сервисы в Layer 0, фоновые задачи в Layer 1
sudo scx_layered - << 'EOF'
[
{
"name": "critical",
"matches": [["CgroupPrefix", "system.slice/nginx"]],
"kind": {"Confined": {"cpus_pct": 60, "util_range": [0.8, 0.9]}}
},
{
"name": "background",
"matches": [["CgroupPrefix", ""]],
"kind": {"Confined": {"cpus_pct": 40, "util_range": [0.1, 0.5]}}
}
]
EOF

# Остановить планировщик — просто Ctrl+C или killall scx_lavd
# Система МГНОВЕННО падает обратно на CFS, никакого даунтайма


Зачем это нужно:
BPF-планировщики можно обновлять без перезагрузки сервера — критически важно для датацентра с сотнями тысяч машин, где rolling reboot занимает недели. Но и для нашего парка из 50 серверов — возможность изолировать приоритет nginx от фоновых cronjob без правки ядра и перезагрузки стоит потраченного часа на изучение.

Итог: CFS — это справедливость для всех. SCHED_EXT — это справедливость там, где тебе нужно. Разница примерно как между светофором и круговым движением: второе умнее, но требует понимания.

#linux #ebpf #sched_ext #performance #kernel #sysadmin #admin_future
🪟 Windows: OSConfig — GPO умерло, долго живёт drift control

Коллеги, у вас в домене есть сервера, где кто-то "временно" отключил NTLMv1 и забыл вернуть? Или изменил политику аудита "под задачу"? Или коллега поставил TLS 1.0 для совместимости с каким-то древним ПО и не сказал? Я видел такое. Называется configuration drift, и он медленно разрушает безопасный периметр, который ты тщательно выстраивал.

В Windows Server 2025 Microsoft тихо привезла ответ на этот вопрос: OSConfig. Каждые несколько часов OSConfig сканирует отклонения от baseline-конфигурации и автоматически исправляет их — без необходимости ждать GPO-обновления или вмешательства вручную.

Базовая линия безопасности включает более 300 настроек безопасности, соответствующих отраслевым стандартам. После применения параметры автоматически защищены от дрейфа — это одна из ключевых особенностей платформы.

Разворачиваем и настраиваем:


# Устанавливаем модуль из PSGallery (нужен WS2025)
Install-Module -Name Microsoft.OSConfig -Scope AllUsers -Repository PSGallery -Force

# Смотрим доступные сценарии
Get-OSConfigMetadata | Format-Table Name, Description -Wrap
# Сценарии: SecurityBaseline, SecuredCore, AppControl, Defender

# Применяем baseline для Member Server (более 300 настроек разом)
Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/MemberServer

# Для Domain Controller — отдельный сценарий
Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/DomainController

# Проверяем что применилось и нет расхождений
Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/MemberServer

# Включаем drift control (автоисправление отклонений)
# По умолчанию проверка каждые 4 часа
Get-OSConfigDriftControl
# Ужесточаем — проверка каждые 45 минут
Set-OSConfigDriftControl 45

# Смотрим конкретный параметр и его текущее состояние
Get-OSConfigDesiredConfiguration `
-Scenario SecurityBaseline/WS2025/MemberServer `
-Setting AuditDetailedFileShare

# Кастомизируем под свои нужды (без потери drift control)
# Например, разрешаем RDP drive redirection (отключено по умолчанию)
Set-OSConfigDesiredConfiguration `
-Scenario SecurityBaseline/WS2025/MemberServer `
-Name RemoteDesktopServicesDoNotAllowDriveRedirection `
-Value 0

# Проверяем соответствие требованиям CIS/DISA STIG
# (OSConfig покрывает их автоматически при применении baseline)
Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/MemberServer |
Where-Object {$_.ComplianceState -ne "Compliant"} |
Select-Object Name, ExpectedValue, ActualValue


Важный нюанс: OSConfig не заменяет GPO и не конкурирует с ним напрямую. Он отлично подходит для изолированных серверов, workgroup-машин и облачных инстансов, где нет централизованного AD. В AD-среде — дополнительный слой защиты поверх GPO.

Зачем это нужно:
Аудиторы любят вопрос "как вы гарантируете, что конфигурация безопасности не изменилась с момента последней проверки?". Раньше честный ответ был "ну, мы стараемся следить". Теперь ответ: "автоматический drift control каждые 45 минут с логами". CIO это оценит на следующем совещании по ИБ.

Итог: GPO — это политика на бумаге. OSConfig — это политика, которая не даёт себя обойти. Разница принципиальная.

#windows #security #osconfig #drift #windowsserver2025 #sysadmin #admin_future
🔥2👍1👏1
🧠 Skills: On-call без выгорания — как построить дежурство, которое не съедает людей

Коллеги, давайте честно: у большинства из нас on-call — это "телефон всегда при тебе, и молись чтобы не позвонили". Никакого графика, никакой ротации, один человек тащит всё потому что "он лучше всех знает как это работает". Богдан снова не спал в эту пятницу.

Это не героизм. Это провал организации процесса.

Google SRE Workbook рекомендует максимум 2–3 actionable-инцидента за смену как устойчивую норму. Если у вашей команды стабильно 8–10 — у вас не проблема дежурства, у вас проблема с алертами. Сначала чиним шум, потом думаем о ротации.

Три кита нормального on-call:

Первое — ротация и границы. Идеально: не чаще одной недели дежурства раз в 6–8 недель. Всё чаще — ведёт к усталости. Всегда должны быть: primary (отвечает первым), secondary (бэкап если primary недоступен) и escalation path к руководителю — не для технических решений, а для принятия бизнес-решений.


ШАБЛОН МАТРИЦЫ ЭСКАЛАЦИИ

Уровень 1 (0–15 мин): Дежурный инженер (primary)
-> Автоматический runbook, первичная диагностика

Уровень 2 (15–30 мин): Дежурный инженер (secondary)
-> Подключается если primary не отвечает или нужна помощь

Уровень 3 (30–60 мин): Тимлид / старший инженер
-> Техническое решение нестандартной ситуации

Уровень 4 (60+ мин): Руководитель
-> Только для бизнес-решений: откат релиза,
уведомление клиентов, привлечение вендора

ПРАВИЛО: каждый уровень получает уведомление автоматически.
Никакого "позвони сам если не справляешься" — это перекладывание
ответственности на усталого человека в 3 ночи.


Второе — алерты, которые требуют действия. Каждый алерт должен отвечать на один вопрос: "нужно ли действие прямо сейчас?" Усталость от алертов возникает из плохого соотношения сигнал/шум.

Аудит алертов раз в квартал — три категории:


[ACTIONABLE] Алерт требует действия в течение 15 минут.
Будит людей. Должен быть в PagerDuty/Grafana OnCall.

[WATCHFUL] Алерт требует внимания в рабочее время.
Тикет в очередь, не звонок ночью.

[NOISE] Алерт не требует никаких действий.
Отключить немедленно.

Реальная статистика большинства команд при честном аудите:
- 20% алертов — ACTIONABLE
- 30% — WATCHFUL
- 50% — NOISE (которые будят людей ночью годами)


Третье — blameless postmortem, который реально работает. Команды с blameless postmortem в 2.3 раза чаще имеют высокопроизводительные системы. Разница проста: blameless-культура фокусируется на обучении, blame-культура — на наказании. Когда инженеры боятся признавать ошибки, они скрывают проблемы, и мелкие инциденты разрастаются в крупные.

Шаблон постмортема за 30 минут:


## Постмортем: [Название инцидента] | [Дата] | Severity: P[1-3]

### Что случилось (2-3 предложения)
### Timeline (с точными временными метками)
### Влияние на пользователей и бизнес
### Root Cause (система/процесс, не человек)
### Что сработало хорошо
### Что нужно улучшить
### Action items:
| Задача | Владелец | Дедлайн |
|--------|----------|---------|
| ... | ... | ... |

ЗАПРЕЩЁННЫЕ ФОРМУЛИРОВКИ:
"Инженер не заметил алерт"
"Алерт не имел достаточного приоритета в системе"
"админ забыл обновить конфиг"
"Процедура деплоя не включала проверку конфигурации"


Зачем это нужно:
Организации, которые делают это правильно, имеют не только меньше случаев выгорания — у них быстрее время реакции, лучше follow-through по постмортемам и on-call программы, которым инженеры доверяют, а не которых боятся.

Итог: On-call — это контракт между компанией и инженером. Компания получает надёжность 24/7. Инженер получает справедливую ротацию, понятные правила и восстановление после смены. Если одна из сторон не выполняет свою часть — это не дежурство. Это эксплуатация.

#skills #oncall #incident #postmortem #sysadmin #sre #admin_future
🔥2
🐧 Linux: io_uring — самый быстрый и самый опасный интерфейс ввода-вывода в ядре

Коллеги, разговор о том, что активно идёт в production прямо сейчас, но о чём мало говорят в контексте безопасности. io_uring появился в ядре 5.1 в 2019 году как революция асинхронного I/O — два кольцевых буфера между ядром и userspace, работа без системных вызовов, минимальный overhead. PostgreSQL оценивает его интеграцию, Meta использует в production годами. Производительность реальная.

Проблема тоже реальная. В июне 2023 года команда безопасности Google сообщила, что 60% эксплойтов в их bug bounty программе за 2022 год были направлены против уязвимостей io_uring. Итог: io_uring отключён в Android, полностью отключён в ChromeOS и на серверах Google.

Ситуация улучшилась, но не исчезла. io_uring может обходить системные вызовы целиком — это означает, что инструменты безопасности, основанные на перехвате syscall (Falco, Tetragon в стандартной конфигурации, многие коммерческие EDR), слепы к операциям через io_uring. Rootkit, работающий через io_uring, будет невидим для большинства систем обнаружения.

Практика: проверяем состояние io_uring в своей инфраструктуре и ограничиваем где нужно:


# Проверяем, используют ли процессы io_uring прямо сейчас
# Смотрим открытые io_uring файловые дескрипторы
find /proc/*/fd -type l 2>/dev/null | xargs ls -la 2>/dev/null | grep anon_inode

# Более точно — смотрим через lsof
lsof | grep io_uring

# Проверяем, какие приложения слинкованы с liburing
ldd /usr/bin/postgres 2>/dev/null | grep uring
find /usr/bin /usr/sbin /opt -type f -name "*.so*" 2>/dev/null | \
xargs grep -l "io_uring" 2>/dev/null | head -20

# ---- ОГРАНИЧЕНИЕ ДЛЯ КОНТЕЙНЕРОВ ----
# Запрет io_uring через seccomp (правильный способ для Docker/Podman)
cat > /etc/docker/seccomp-no-iouring.json << 'EOF'
{
"defaultAction": "SCMP_ACT_ALLOW",
"syscalls": [
{
"names": ["io_uring_setup", "io_uring_enter", "io_uring_register"],
"action": "SCMP_ACT_ERRNO",
"errnoRet": 38
}
]
}
EOF

# Запускаем контейнер без io_uring
docker run --security-opt seccomp=/etc/docker/seccomp-no-iouring.json nginx

# ---- ДЛЯ systemd-сервисов ----
# В unit-файле — ограничение системных вызовов
# Добавляем в [Service]:
# SystemCallFilter=~io_uring_setup io_uring_enter io_uring_register

# ---- АУДИТ ----
# Если используете auditd — добавляем правила мониторинга io_uring
cat >> /etc/audit/rules.d/iouring.rules << 'EOF'
-a always,exit -F arch=b64 -S io_uring_setup -k iouring_activity
-a always,exit -F arch=b64 -S io_uring_enter -k iouring_activity
EOF
auditctl -R /etc/audit/rules.d/iouring.rules
# Смотрим активность:
ausearch -k iouring_activity | tail -20


Зачем это нужно:
Продакшн-системы на затронутых ядрах должны иметь мониторинг таймаутов сокетных операций и исчерпания ресурсов. Критические системы могут потребовать временного отключения некоторых функций io_uring до выхода патчей. Быть слепым к части I/O-активности в продакшне в 2026 году — это не технический нюанс, это дыра в модели угроз.

Итог: io_uring — это не плохая технология. Это мощный инструмент с расширенной поверхностью атаки. Как и у любого острого инструмента — важно знать, где он лежит и кто к нему имеет доступ.

#linux #iouring #security #kernel #sysadmin #admin_future
🪟 Windows: Patch Tuesday апрель 2026 — три проблемы из одного обновления, памятка для выживших

Коллеги, 14 апреля вышел апрельский Patch Tuesday. И он немедленно стал мемом в сообществе администраторов — но не потому что хороший. За три дня Microsoft подтвердила три отдельные проблемы от одного пакета обновлений KB5082063. Разбираем по порядку.

Что закрыли: 163 CVE, из них 8 критических, два zero-day. Самый опасный — CVE-2026-33824 с CVSS 9.8 в Windows IKE Service Extensions: уязвимость позволяет неаутентифицированному атакующему выполнить код удалённо, достаточно отправить специально сформированные пакеты на машину с включённым IKEv2. Не устанавливать нельзя.

Что сломали — проблема первая, BitLocker: некоторые Windows Server 2025 устройства с определённой конфигурацией TPM Group Policy требуют ввода ключа восстановления BitLocker при первой перезагрузке после KB5082063. Это происходит, если одновременно выполнены условия: BitLocker включён, GPO настраивает TPM PCR7, msinfo32 показывает PCR7 Binding как "Not Possible", и на устройстве уже присутствует сертификат Windows UEFI CA 2023.

Проблема вторая, ещё хуже: non-Global Catalog контроллеры домена в средах с Privileged Access Management (PAM) могут войти в бесконечный цикл перезагрузок из-за краша LSASS при старте. Затронуты Windows Server 2016, 2019, 2022 и 2025.

Проблема третья — ошибка 0x800F0983 при установке на части Windows Server 2025 систем. Обновление просто не ставится.

Что делать прямо сейчас:


# ШАГ 1 — Перед установкой KB5082063: проверяем риск BitLocker
# Проверяем состояние PCR7 Binding
Get-ComputerInfo | Select-Object BiosFirmwareType, SecureBootEnabled

# Смотрим msinfo32 через PowerShell
$csWmi = Get-WmiObject -Class Win32_ComputerSystem
# Или через msinfo32.exe — ищем строку "PCR7 Binding"
msinfo32.exe # -> System Summary -> Secure Boot State

# Если PCR7 Binding = "Not Possible" — снимаем GPO перед патчем
# Computer Config -> Admin Templates -> Windows Components
# -> BitLocker Drive Encryption -> OS Drives
# -> "Configure TPM platform validation profile" -> Not Configured
gpupdate /force

# ШАГ 2 — Проверяем, является ли DC Global Catalog (GC)
# Если NOT GC + PAM включён = высокий риск reboot loop
# Проверяем GC статус:
Import-Module ActiveDirectory
Get-ADDomainController -Identity $env:COMPUTERNAME |
Select-Object Name, IsGlobalCatalog, IPv4Address

# Если IsGlobalCatalog = False И в среде есть PAM ->
# НЕ устанавливать KB5082063 до появления фикса,
# или ставить только после консультации с Microsoft Support

# ШАГ 3 — Проверяем наличие IKEv2 (CVE-2026-33824 CVSS 9.8)
# Если IKEv2 не используется — блокируем UDP 500 и 4500
netsh advfirewall firewall show rule name="IKE*"

# Временный mitigation если патч не встаёт:
netsh advfirewall firewall add rule `
name="Block IKEv2 inbound temp" `
dir=in action=block `
protocol=UDP localport=500,4500

# ШАГ 4 — Экстракция BitLocker recovery ключей заранее (всегда!)
# Для всех машин домена:
Get-ADComputer -Filter * | ForEach-Object {
Get-ADObject -Filter {objectclass -eq 'msFVE-RecoveryInformation'} `
-SearchBase $_.DistinguishedName `
-Properties 'msFVE-RecoveryPassword' |
Select-Object @{N='Computer';E={$_.DistinguishedName}},
@{N='Key';E={$_.'msFVE-RecoveryPassword'}}
} | Export-Csv "bitlocker_keys_backup_$(Get-Date -Format yyyyMMdd).csv"


Зачем это нужно:
Это уже четвёртый раз с 2022 года, когда Patch Tuesday вызывает неожиданные запросы BitLocker recovery. И второй год подряд апрельское обновление ломает контроллеры домена. Паттерн достаточно устойчив, чтобы считать его нормой и готовиться заранее: держать ключи BitLocker в AD и в оффлайн-хранилище, тестировать обновления на одном DC перед раскаткой на всю инфраструктуру.

Итог: Patch Tuesday с CVSS 9.8 пропустить нельзя. Но и ставить вслепую тоже нельзя. Проверь PCR7, проверь GC-статус DC, экспортируй ключи BitLocker. Пять минут подготовки сейчас — это не три часа ночного инцидента потом.
🧠 Skills: Мониторинг vs Observability — в чём разница и почему это важно для карьеры

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

Мониторинг — это когда знаешь заранее, что может сломаться, и смотришь на это. Дашборд с CPU, памятью, диском, статусом сервиса. Алерт когда CPU > 90%. Всё понятно, всё предсказуемо.

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

Разница не в инструментах. Разница в том, как мы думаем об инфраструктуре.

Два де-факто открытых стандарта в observability сегодня — Prometheus и OpenTelemetry. 65% организаций инвестируют в оба. Prometheus зрелее и больше используется в production (59%), OpenTelemetry быстрее растёт — 35% сейчас находятся на стадии POC и готовятся к масштабированию.

Практика: строим минимальный observability-стек на своём парке серверов:


# docker-compose.yml — базовый стек: Prometheus + Grafana + Node Exporter
# Разворачивается за 10 минут, даёт реальную видимость

version: '3.8'

services:
prometheus:
image: prom/prometheus:latest
container_name: prometheus
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
- prometheus_data:/prometheus
command:
- '--config.file=/etc/prometheus/prometheus.yml'
- '--storage.tsdb.retention.time=30d' # Храним 30 дней истории
ports:
- "9090:9090"
restart: unless-stopped

node-exporter:
image: prom/node-exporter:latest
container_name: node_exporter
volumes:
- /proc:/host/proc:ro
- /sys:/host/sys:ro
- /:/rootfs:ro
command:
- '--path.procfs=/host/proc'
- '--path.rootfs=/rootfs'
- '--path.sysfs=/host/sys'
- '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'
ports:
- "9100:9100"
restart: unless-stopped

grafana:
image: grafana/grafana:latest
container_name: grafana
volumes:
- grafana_data:/var/lib/grafana
environment:
- GF_SECURITY_ADMIN_PASSWORD=changeme_immediately
- GF_USERS_ALLOW_SIGN_UP=false
ports:
- "3000:3000"
restart: unless-stopped

volumes:
prometheus_data:
grafana_data:



# prometheus.yml — базовая конфигурация
global:
scrape_interval: 15s
evaluation_interval: 15s

scrape_configs:
# Сам Prometheus
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']

# Метрики хоста
- job_name: 'node'
static_configs:
- targets: ['node-exporter:9100']
labels:
env: 'production'
datacenter: 'main'

# Если есть несколько серверов — добавляем все
- job_name: 'servers'
static_configs:
- targets:
- '192.168.1.10:9100'
- '192.168.1.11:9100'
- '192.168.1.12:9100'



# Три PromQL-запроса, которые реально нужны каждый день:

# 1. Топ-5 процессов по CPU (не просто средний по системе)
topk(5, rate(namedprocess_namegroup_cpu_seconds_total[5m]))

# 2. Свободное место на дисках с предсказанием когда кончится
predict_linear(node_filesystem_avail_bytes[6h], 4*3600) < 0

# 3. Доступная память — реальная, не та что показывает free
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100


Ключевая идея: observability as code — это когда конфигурации мониторинга управляются как код: версионируются в Git, проходят code review, разворачиваются через те же CI/CD-пайплайны, что и инфраструктура. Те же инструменты, те же принципы.

Что это значит на практике: дашборды и алерты живут в репозитории. Когда поднимается новый сервер через IaC — мониторинг на него появляется автоматически. Когда сервер уходит — метрики перестают собираться и дашборд обновляется сам. Ноль ручной работы.
Зачем это важно для карьеры:
Разрыв между "администратором который смотрит на Zabbix" и "инженером который строит observability-пайплайн" в 2026 году — это разрыв в грейде и зарплате. Настройка занимает 4–6 часов в первый раз. Это звучит много — пока не сравниваешь с восьмичасовым разбором инцидента без нормальных данных.

Итог: мониторинг отвечает на вопрос "сломалось или нет". Observability отвечает на вопрос "почему сломалось и где именно". В современной инфраструктуре достаточно первого только для очень простых систем. Для всего остального нужна observability. И строить её уже можно с нуля за один вечер.

#skills #observability #prometheus #grafana #opentelemetry #sysadmin #admin_future
🐧 Linux: XFS self-healing в ядре 7.0 — конец ночных xfs_repair на продакшне

Коллеги, 12 апреля вышел Linux 7.0, и пока все обсуждают красивый мажорный номер версии и официальный статус Rust, кое-что поважнее тихо проскользнуло мимо радаров большинства. Для тех, кто держит боевые серверы на XFS — а это весь RHEL-мир, CentOS-наследники, Rocky и Alma — это прямой удар по одной из самых болезненных ситуаций в практике.

До 7.0 картина была такая: если XFS обнаруживал повреждение метаданных — от скачка питания, аппаратного сбоя или битого сектора — файловая система переходила в read-only или падала с ошибкой. Требовалось размонтировать том, часто невозможное на живой корневой ФС, загрузиться с rescue-медиа и запустить xfs_repair вручную.

Теперь другая история. Новая возможность использует специальный daemon, который опирается на parent pointer metadata и reverse mapping для обнаружения ошибок, о которых сообщает ядро, и запускает исправление автоматически. Всё это происходит пока файловая система примонтирована и активно используется.

Важный нюанс сразу: ядро не сканирует файловую систему непрерывно. Вместо этого — когда при обычных операциях чтения или записи встречаются несогласованные метаданные, оно теперь пытается исправить их на месте, а не возвращать ошибку или переходить в read-only. Это не покрывает все сценарии: глубокие структурные повреждения, аппаратный bit rot и сбои в блоках данных по-прежнему требуют офлайн-ремонта или восстановления из бэкапа.

Что делать практически прямо сейчас:


# Проверяем версию ядра — нужна 7.0+
uname -r

# На Ubuntu 26.04 LTS (выходит 23 апреля) — будет из коробки
# На текущих системах — смотрим в mainline PPA для тестовых сред:
# add-apt-repository ppa:kernel-ppa/mainline && apt update

# Проверяем что XFS примонтирован с нужными опциями
# self-healing включён по умолчанию — дополнительной конфигурации не нужно
mount | grep xfs
# Убеждаемся что есть rmapbt и parent pointers (нужны для self-heal)
xfs_info /dev/sda1 | grep -E "rmapbt|ftype|reflink"

# Мониторинг self-healing активности в реальном времени
# Смотрим dmesg — ядро будет логировать каждое исправление
dmesg -w | grep -iE "xfs.*(heal|repair|corrupt|recover)"

# Пример того что увидим при срабатывании:
# [ 183.44] XFS (sda1): Repairing corrupt inode btree in AG 2.
# [ 183.45] XFS (sda1): Self-healing complete. Filesystem operational.

# Для мониторинга через journalctl (если нет dmesg watch):
journalctl -k -f | grep -i "xfs"

# Проверяем health XFS-тома утилитой xfs_scrub (рекомендуется периодически)
# В режиме онлайн — не блокирует работу
xfs_scrub -v /mount/point

# Настраиваем регулярный xfs_scrub через systemd timer (уже есть в xfsprogs)
systemctl enable --now xfs_scrub_all.timer
systemctl status xfs_scrub_all.timer

# Смотрим статистику ошибок ФС
xfs_db -r -c "check" /dev/sda1 # offline check для диагностики


Зачем это нужно:
Для системных администраторов, отвечающих за XFS-тома на продакшн-серверах, это значимое улучшение quality-of-life. Однако эту возможность не следует использовать как замену полноценному процессу резервного копирования и восстановления. Self-healing — это safety net для конкретного класса сбоев, а не страховка от всего.

Итог: xfs_repair в 3 ночи с rescue USB — это был обряд посвящения для каждого линукс-администратора. В ядре 7.0 этот обряд стал значительно реже встречаться. Бэкапы всё равно делайте.

#linux #xfs #kernel7 #storage #filesystem #sysadmin #admin_future
🪟 Windows: Secure Boot 2011 → 2026 — у тебя есть два месяца до истечения сертификатов

Коллеги, это тот случай, когда Microsoft предупреждает заранее и громко — но в суете патч-вторников и инцидентов это всё равно тонет. Поэтому говорим сегодня, пока ещё есть время.

Сертификаты Secure Boot, которые Microsoft выпустила в 2011 году, начинают истекать в июне 2026 года. Затронуты физические и виртуальные машины на всех поддерживаемых версиях: Windows 10, Windows 11, Windows Server 2016, 2019, 2022, 2025 — всё железо с 2012 года.

Что произойдёт если не обновить: устройства продолжат запускаться и работать нормально, стандартные обновления Windows продолжат устанавливаться. Однако они больше не смогут получать новые средства защиты раннего процесса загрузки — обновления Windows Boot Manager, базы данных Secure Boot, списки отзыва и средства защиты от вновь обнаруженных уязвимостей уровня загрузки. С октября 2026 года — никаких security-фиксов для Windows Boot Manager.

Критический нюанс для серверов: в отличие от клиентских Windows-машин, которые получают сертификаты 2023 года автоматически через Windows Update, Windows Server требует ручного действия. Сертификаты на сервера автоматически не прилетают.

Аудит и обновление прямо сейчас:


# ШАГ 1 — Инвентаризация: проверяем статус на каждом сервере

# Проверяем текущий статус обновления сертификатов
Get-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
-Name "UEFICA2023Status" -ErrorAction SilentlyContinue |
Select-Object UEFICA2023Status

# Возможные значения:
# (пусто / ключ отсутствует) = обновление не начато
# "InProgress" = в процессе
# "Updated" = готово, сертификаты 2023 установлены

# Проверяем включён ли Secure Boot вообще
Confirm-SecureBootUEFI

# Проверяем через Event Log — Event ID 1808 = сертификаты успешно обновлены
Get-WinEvent -LogName System |
Where-Object {$_.Id -eq 1808} |
Select-Object TimeCreated, Message |
Format-List

# ШАГ 2 — Для серверов БЕЗ сертификатов 2023: запускаем обновление вручную

# Инициируем обновление Secure Boot certificates
Set-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" `
-Name "AvailableUpdates" `
-Value 0x5944

# Запускаем scheduled task для обновления
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

# Смотрим статус — должен появиться "InProgress"
Get-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
-Name "UEFICA2023Status"

# ПЕРЕЗАГРУЖАЕМ сервер, затем запускаем task ещё раз
Restart-Computer -Force
# После перезагрузки:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# Статус должен смениться на "Updated"

# ШАГ 3 — Массовый аудит через домен (все серверы сразу)
$servers = Get-ADComputer -Filter {OperatingSystem -like "*Server*"} |
Select-Object -ExpandProperty Name

$results = foreach ($server in $servers) {
try {
$status = Invoke-Command -ComputerName $server -ScriptBlock {
$s = Get-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
-Name "UEFICA2023Status" -ErrorAction SilentlyContinue
[PSCustomObject]@{
Server = $env:COMPUTERNAME
Status = if ($s) { $s.UEFICA2023Status } else { "NotStarted" }
SecureBootEnabled = (Confirm-SecureBootUEFI -ErrorAction SilentlyContinue)
}
} -ErrorAction Stop
$status
} catch {
[PSCustomObject]@{Server = $server; Status = "Unreachable"; SecureBootEnabled = $null}
}
}

$results | Sort-Object Status | Export-Csv "secureboot_audit_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation
$results | Group-Object Status | Format-Table Name, Count
Зачем это нужно:
Обновление защищает от BlackLotus и аналогичных UEFI-буткитов, которые атакуют ранний процесс загрузки. После истечения 2011-сертификатов система не сможет получать mitigation-обновления против новых буткитов, даже если Patch Tuesday приходит вовремя.

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

#windows #secureboot #security #windowsserver #patching #sysadmin #admin_future
🧠 Skills: Как правильно использовать ИИ в работе администратора — без иллюзий и без паники

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

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

Где ИИ реально помогает прямо сейчас — три конкретных паттерна:


ПАТТЕРН 1: ГЕНЕРАЦИЯ И ОТЛАДКА СКРИПТОВ

Плохой запрос:
"Напиши мне PowerShell-скрипт для AD"

Хороший запрос:
"Я Senior Systems Administrator. Среда: Windows Server 2025,
PowerShell 7.4, домен corp.local, модуль ActiveDirectory установлен.
Напиши скрипт который находит все неактивные компьютерные аккаунты
(не логинились больше 90 дней), экспортирует в CSV с полями:
Name, LastLogonDate, OU, Enabled.
Добавь обработку ошибок и -WhatIf параметр для безопасного тест-запуска."

Разница: второй запрос даёт рабочий результат с первого раза.
Контекст среды — это ключ. Без него ИИ галлюцинирует cmdlets.

ПАТТЕРН 2: ТРАБЛШУТИНГ КАК ДИАЛОГ

Ситуация: непонятная ошибка в логах, нет времени читать man.
Метод: вставить полный текст ошибки + контекст системы
и спросить "объясни что происходит и дай 3 гипотезы"

Пример:
"На RHEL 9 в journalctl вижу:
kernel: EXT4-fs error (device sdb1): ext4_find_entry:1455
Система: PostgreSQL 15, база на /dev/sdb1 ext4, kernel 6.18.
Что это может быть и что проверить в первую очередь?"

Результат: структурированные гипотезы, команды для диагностики.
Ты всё равно принимаешь решение — ИИ даёт карту возможностей.

ПАТТЕРН 3: ДОКУМЕНТАЦИЯ КАК ПОБОЧНЫЙ ПРОДУКТ

После решения инцидента: скармливаешь ИИ
- timeline событий из логов
- команды которые выполнял
- итог

Просишь: "Напиши postmortem по этому инциденту в формате:
Timeline / Root Cause / Impact / Actions Taken / Prevention"

За 2 минуты получаешь структурированный документ.
Который раньше не писал вообще, потому что "некогда".


Где ИИ НЕ стоит использовать без проверки:


КРАСНЫЕ ФЛАГИ:

[!] Любые деструктивные операции без -WhatIf / --dry-run
Всегда тестируй сгенерированный скрипт в тестовой среде

[!] Конфигурации безопасности (firewall rules, SELinux policies)
ИИ не знает твою топологию — он угадывает

[!] Чувствительные данные в промпте
Не вставляй пароли, ключи, имена пользователей в публичные ИИ

[!] "ИИ сказал что так правильно" как аргумент
ИИ уверенно ошибается. Всегда проверяй по официальной документации


Практический подход — три правила зрелого использования ИИ:

Первое — контекст решает всё. Чем точнее описана среда (ОС, версия, конкретная задача, ограничения), тем выше качество ответа. Потрать 30 секунд на формулировку — сэкономишь 30 минут на исправление.

Второе — ИИ как черновик, не как финал. Каждый сгенерированный скрипт читай как код коллеги на code review: понимаешь ли что делает каждая строка? Нет — разбирай дальше или переписывай.

Третье — документируй промпты которые работают. Если нашёл промпт который даёт хорошие результаты для регулярной задачи (аудит AD, проверка сертификатов, генерация отчётов) — сохрани его в своём репозитории промптов. Это твои инструменты, не одноразовые запросы.

Зачем это важно:
Инженер, который умеет правильно использовать ИИ, решает за день то, на что раньше уходила неделя. Не потому что ИИ умнее — а потому что рутинная часть задачи делается быстрее, и остаётся больше времени на то, что требует реального опыта и суждения. В 2026 году это уже конкурентное преимущество на рынке труда, а не опциональный навык.
1
Итог: ИИ — это очень хороший стажёр с фотографической памятью и нулевым чувством ответственности. Он делает то что просишь, не думает о последствиях и иногда уверенно врёт. Твоя задача — быть опытным тимлидом этого стажёра, а не слепо доверять его выводам.

#skills #AI #автоматизация #sysadmin #карьера #powershell #admin_future
💯2
🐧 Linux: Ubuntu 26.04 LTS вышла сегодня — что важно для сервера

Коллеги, 23 апреля 2026 — день релиза Ubuntu 26.04 LTS «Resolute Raccoon». Поддержка 5 лет бесплатно (до 2031), с Ubuntu Pro — 10 лет. Это первый LTS после 24.04.

Три вещи, важных конкретно для серверной эксплуатации:

Первое — sudo-rs теперь дефолтный sudo-провайдер. Оригинальный sudo переименован в sudo.ws. Пакет sudo-ldap удалён: LDAP-аутентификация теперь только через PAM. Если у вас sudo через LDAP — проверьте конфигурацию до апгрейда.

Второе — systemd в этом релизе убирает поддержку cgroup v1 полностью. Только унифицированная иерархия cgroup v2. Если какие-то контейнеры или легаси-сервисы у вас были привязаны к v1 — они не запустятся.

Третье — ядро Linux 7.0 из коробки. Это XFS self-healing, стабильный Rust, улучшенная производительность памяти (время аллокации больших блоков упало с 3.6 до 0.43 секунды), создание контейнеров стало на 40% быстрее.


# Проверяем готовность к апгрейду с 24.04
# Смотрим есть ли sudo через LDAP
grep -r "ldap" /etc/sudo* /etc/nsswitch.conf 2>/dev/null

# Проверяем cgroup версию
stat -fc %T /sys/fs/cgroup/
# tmpfs = v1 (проблема), cgroup2fs = v2 (порядок)

# Официальный апгрейд (когда будет открыт путь 24.04→26.04):
sudo do-release-upgrade


Зачем это нужно:
Для продакшн-серверов рекомендуется подождать релиза 26.04.1 в августе 2026 — первый point release включает несколько месяцев исправлений и открывает официальный путь апгрейда с 24.04.

Итог: новые серверы — ставьте 26.04 сегодня. Продакшн 24.04 — дождитесь августа.

#linux #ubuntu #lts #sysadmin #admin_future