Гайд: Собери свой Home Lab. От админа к архитектору через практику

Теория — это хорошо, но настоящий рост происходит, когда ломаешь и чинишь. Домашняя лаборатория — это ваша персональная песочница для экспериментов, без риска уронить прод.

Зачем она нужна?
Чтобы набить руку с технологиями, которые вы не можете трогать на работе: Kubernetes, Ansible, Terraform, Proxmox, Active Directory с нуля. Это ваш путь к архитектурному мышлению.

Минимальный набор (на старом ПК или NUC):

Гипервизор: Proxmox VE. Бесплатный, мощный, с веб-интерфейсом. Позволяет создавать и VM, и LXC-контейнеры. Альтернатива: VMware ESXi Free.

Сеть: Настройте виртуальный свитч. Для старта хватит NAT, но цель — разобраться с VLAN и маршрутизацией (pfSense/OPNsense в отдельной VM).

Хранилище: ZFS (если позволяет Proxmox) или просто директория на диске.

Что развернуть в первую очередь (Ваш архитектурный проект):

Контроллер домена: Поднимите AD на Windows Server или Samba/FreeIPA на Linux. Научитесь работать с GPO, пользователями, DNS.

Reverse Proxy: Поставьте Nginx Proxy Manager (в Docker). Публикуйте свои внутренние сервисы наружу через один IP. Разберитесь с SSL-сертификатами от Let's Encrypt.

Мониторинг: Разверните связку Grafana + Prometheus. Настройте сбор метрик с ваших VM. Поймите, что такое node_exporter и дашборды.

IaC-сервер: VM с Ansible. Напишите плейбуки для автоматической настройки других машин в вашей лабе.

Главное правило лабы: она должна работать. Сделайте её полезной — поднимите там свой VPN (WireGuard), медиасервер (Jellyfin) или блокировщик рекламы (Pi-hole). Так у вас будет мотивация её поддерживать и развивать.

#homelab #proxmox #devops #architect #education #гайд

Home Lab: Proxmox — это не VirtualBox. Строим свой Enterprise-полигон

Многие админы "тестируют" в VirtualBox на своем ПК. Архитекторы строят Home Lab — мини-версию корпоративной среды. И Proxmox VE — идеальный, бесплатный, open-source фундамент для этого.
Почему Proxmox, а не что-то другое? Это не просто гипервизор. Это платформа гиперконвергентной инфраструктуры (HCI).
Два-в-одном: KVM + LXC
KVM (виртуальные машины): Полноценная виртуализация для Windows Server, Linux-дистрибутивов и т.д.
LXC (контейнеры): Супер-легкие Linux-контейнеры, которые запускаются за 1 секунду и потребляют минимум RAM. Идеально для запуска десятков сервисов (Pi-hole, Nginx Proxy Manager, Uptime Kuma).
Веб-интерфейс: Управляете всем из браузера. Никаких RDP или VNC.
Встроенные бэкапы: Настройка бэкапов VM и контейнеров "из коробки" по расписанию.
Кластеризация: Вы можете объединить 2-3 старых ПК в кластер Proxmox и получить живую миграцию VM. Это уже настоящий Enterprise-уровень.

Взгляд архитектора: Ваша Home Lab на Proxmox — это ваш личный R&D отдел. Здесь вы можете безопасно ломать то, что никогда не рискнете трогать на работе.
Развернуть кластер Kubernetes с kubeadm.
Протестировать Ansible-плейбуки для настройки "с нуля".
Построить отказоустойчивый кластер баз данных.
Настроить сетевую сегментацию с pfSense.
Это песочница, в которой админ становится архитектором.

#linux #proxmox #homelab #architect #selfhosted #гайд

🐧 Proxmox: Спасаем виртуалку из состояния «Locked» 🔒

Пятничный кошмар: завис бэкап или отвалилось сетевое хранилище в момент создания снапшота.
Виртуалка переходит в статус locked, её невозможно ни перезагрузить, ни выключить, ни мигрировать.
GUI просто выдает ошибку, и машина превращается в "зомби".

Не нужно перезагружать всю ноду Proxmox! Статус блокировки — это просто текстовый флаг в конфигурационном файле.

Как снять блокировку через консоль:
Сначала проверяем, почему она заблокирована (возможно, бэкап всё еще идет):

cat /etc/pve/qemu-server/100.conf | grep lock

(Где 100 — это ID твоей виртуалки).

Если процесс бэкапа/снапшота точно завис и убит, снимаем лок одной командой:

qm unlock 100

Результат: Машина снова слушается команд. Выдыхаем. 😮‍💨

#proxmox #linux #virtualization #troubleshooting #sysadmin #friday13 #kvm

🏛️ Пятничный лонгрид: Синдром «Всегда на связи» или как перестать быть заложником своих серверов

Давай честно: сколько раз ты вздрагивал, когда в твоих AirPods внезапно пиликало уведомление от Zabbix посреди семейного ужина или похода в зал?

В 2026 году управлять инфраструктурой стало проще, но управлять своим вниманием — в разы сложнее.

Особенно, когда на тебе висит сразу несколько проектов, пара серверов на аутсорсе и еще кто-то постоянно просит «быстренько посмотреть винду».
Мы привыкли быть безотказными спасателями, но в IT это путь в никуда.

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

1. Убей в себе «Славного парня»
* Самая большая ошибка сисадмина — пытаться угодить всем и реагировать на каждую просьбу в ту же секунду.
* «У меня тут эксель завис» — это не инцидент уровня P1 (Critical).
* Настрой жесткие SLA (Service Level Agreement) даже для внутренних задач.

Приучи пользователей (и заказчиков) писать в тикет-систему, а не в личные сообщения в Telegram.
Твоя отзывчивость не должна работать против тебя.
Ты архитектор системы, а не служба эскорта для чужих мышек.

2. Архитектура важнее героизма (Failover by Design)
Если твой сервер падает, и тебе нужно бежать к консоли, чтобы руками поднимать сервисы — у тебя плохая архитектура.
Инфраструктура должна уметь выживать без твоего участия хотя бы до утра понедельника.

* Proxmox HA (High Availability): Настрой кворум.
Если одна нода умирает, виртуалки должны сами переехать на соседнюю и запуститься.

Windows Server: Используй DFS (Distributed File System) для шар, чтобы отвал одного файловика никто даже не заметил.
Твоя цель — сделать так, чтобы система лечила себя сама, пока ты спишь.

3. Информационная диета (Alert Fatigue)
Если твой мониторинг шлет тебе в Telegram по 50 сообщений в день («CPU load 80%», «Port flapping») — ты скоро перестанешь на них смотреть.
И в нужный момент пропустишь реальную катастрофу (например, когда Ransomware начнет шифровать бэкапы).

Правило: Уведомления в пуш/смс должны приходить только тогда, когда требуется твое немедленное физическое или удаленное вмешательство.

Всё остальное (предупреждения, графики, мелкие аномалии) — должно падать в отдельный канал без звука или на дашборд Grafana, который ты проверяешь за утренним кофе.

🚀 Пятничный ритуал освобождения:
Прежде чем перевести статус в «Офлайн», сделай три вещи:

1. Проверь точки невозврата: Глянь логи Veeam или Proxmox Backup Server. Зеленые галочки? Отлично.
2. Закрой SSH-туннели: Выключи все временные доступы, которые ты открывал на неделе для тестов.
3. Сними наушники: Буквально. Выключи рабочие чаты до понедельника. Железо железным, но нейронные связи в твоей голове тоже требуют обслуживания и отдыха от цифрового шума.

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

Всем стабильного пинга и отличных выходных! 🧘‍♂️🍻

#friday #longread #sysadmin #psychology #burnout #admin_future #it_culture #proxmox #worklifebalance

🐧 Proxmox: Спасаем зависшую виртуалку, когда Web-интерфейс «умер» 🚑

Знакомая ситуация: виртуалка намертво повисла в статусе `Locked` (например, во время бэкапа), кнопка "Stop" в веб-морде Proxmox (PVE) крутится бесконечно, а нагрузка на ноду растет.

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

Алгоритм реанимации (SSH на ноду PVE):

1. Снимаем лок с ВМ:

# Разблокируем виртуалку с ID 100
qm unlock 100

2. Пытаемся остановить штатно:

qm stop 100

3. Если не помогло — убиваем процесс KVM:

# Ищем PID процесса виртуалки
ps aux | grep "/usr/bin/kvm -id 100"

# Жестко убиваем найденный PID (например, 12345)
kill -9 12345

После этого виртуалка гарантированно потухнет, и её можно будет запустить заново с чистой совестью.

Консоль — наше всё!

#proxmox #linux #virtualization #troubleshooting #cli #sysadmin #admin_future

🎓 Собеседование сисадмина. Выпуск №4: Виртуализация и Хранение данных

Привет, коллеги! Сегодня разберем три вопроса, на которых часто «плывут» даже опытные админы, привыкшие работать по инструкции, а не по логике.

❓ Вопрос 1: «Почему опасно держать снапшот (Snapshot) виртуальной машины дольше пары дней?»
❌ Ответ новичка: «Снапшот занимает много места на диске, и можно просто забыть, что он есть».
✅ Ответ инженера:

1. Производительность: Снапшот — это не копия ВМ, а дельта-файл. При наличии снапшота все новые записи идут в этот файл, а при чтении системе приходится проверять и основной диск, и все файлы цепочки снапшотов. Это создает огромную нагрузку на I/O.
2. Риск повреждения: Чем длиннее «цепочка» снапшотов, тем выше шанс, что при консолидации (удалении снапшота) произойдет ошибка, которая «убьет» файловую систему виртуалки.
3. Место: Снапшот растет непредсказуемо. Если внутри ВМ идет активная запись (например, обновление базы), снапшот может мгновенно забить всё свободное место на хранилище (LUN/Datastore), что приведет к остановке всех машин на этой полке.

❓ Вопрос 2: «В чем разница между Thin (Тонкими) и Thick (Толстыми) дисками? Что вы выберете для высоконагруженной БД?»
❌ Ответ новичка: «Тонкие диски экономят место, а толстые — нет. Для базы выберу толстые, потому что они надежнее».
✅ Ответ инженера:

Thin Provisioning: Место на физическом носителе выделяется только по мере записи данных. Плюс: экономия пространства. Минус: риск «Overprovisioning» (когда суммарный объем тонких дисков больше физического хранилища) и небольшая потеря производительности на операциях записи.
Thick Provisioning (Eager Zeroed): Весь объем резервируется и зануляется сразу. Плюс: максимальная производительность и отсутствие фрагментации на уровне гипервизора.
Выбор: Для высоконагруженной БД (SQL/Oracle/1С) — только Thick Provisioning Eager Zeroed. Это гарантирует отсутствие задержек при расширении файлов базы и исключает ситуацию, когда база падает из-за того, что на физической полке внезапно кончилось место.

❓ Вопрос 3: «Что такое Split-brain в кластере высокой доступности (HA) и как его предотвратить?»
❌ Ответ новичка: «Это когда два сервера работают одновременно. Предотвратить можно, настроив хороший мониторинг».
✅ Ответ инженера:

Split-brain — это состояние, когда узлы кластера теряют связь друг с другом (по сети Heartbeat), но при этом оба остаются живы. Каждый решает, что напарник «умер», и пытается одновременно захватить общие ресурсы (IP, диски). Это гарантированно ведет к повреждению данных.
Защита:
1. Quorum (Кворум): Использование нечетного количества узлов или «свидетеля» (Witness/Quorum Device). Ресурсы получает тот, кто видит большинство голосов.
2. STONITH / Fencing: Принцип «Пристрели другого в голову» (Shoot The Other Node In The Head). Если узел теряет связь, он через управляемую розетку (PDU) или IPMI физически выключает питание напарника, прежде чем забрать ресурсы.

💡 Золотое правило собеса: Помни, что Снапшот — это не бэкап. Это временная точка отката перед рискованной операцией. Если на вопрос «как вы делаете бэкапы» ты ответишь «делаю снапшоты раз в неделю» — собеседование для тебя закончится мгновенно.

Сохраняйте, коллеги! Это те знания, которые превращают «админа-кнопкотыка» в системного архитектора.

#собеседование_AF #virtualization #storage #snapshot #highavailability #proxmox #vmware #admin_future

🧠 Skills: Домашняя лаборатория — лучшая инвестиция в карьеру сисадмина

Коллеги, разговор о том, что разделяет администраторов, которые растут, от тех, кто стоит на месте. Ответ чаще всего один — наличие личной лаборатории.

Домашняя лаборатория — безопасное место для провалов, экспериментов и роста без страха положить продакшн. Облако не заменило homelab. Лаборатория стала ещё актуальнее — это место, где можно практиковать Git, IaC, CI/CD и контейнеры бесплатно, не получив счёт на 100 тысяч долларов из облака.

Минимальный стартовый стек в 2026 году:

ЖЕЛЕЗО (один сервер — уже лаборатория):
  Б/у десктоп / NUC: 32GB RAM, SSD 512GB
  Или: старый игровой ноут с 16GB RAM
  Гипервизор: Proxmox VE (бесплатно)

СЕРВИСЫ ДЛЯ ПРАКТИКИ:
  - Proxmox + несколько VM: Linux + Windows Server
  - Self-hosted Git (Gitea) — всё в Git с первого дня
  - Ansible — автоматизируем конфиги вместо ручного тыка
  - Prometheus + Grafana — мониторинг как в продакшне
  - WireGuard — VPN для удалённого доступа к лабе

ЧТО ПРАКТИКОВАТЬ:
  Неделя 1-2: поднять Proxmox, создать несколько VM
  Неделя 3-4: настроить сеть, VLAN, DNS
  Месяц 2:    Ansible playbook для автодеплоя Ubuntu/WinServer
  Месяц 3:    Kubernetes (k3s) + мониторинг
  Месяц 4+:   Сломай и восстанови. Повтори.

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

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

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

#skills #homelab #карьера #proxmox #sysadmin #admin_future

🐧 Linux: Proxmox Backup Server 4.2 — S3 из preview стал production, и вот что это меняет

Коллеги, 30 апреля вышел Proxmox Backup Server 4.2 — и это один из тех релизов, где changelog стоит читать внимательно, а не по диагонали.

Три главных изменения для тех кто держит инфраструктуру на Proxmox:

S3-совместимые объектные хранилища теперь официально поддерживаются как backend для бэкапов. Появились счётчики запросов и статистика трафика прямо в сводке datastora — это помогает рано замечать неожиданные всплески трафика. Wasabi, Backblaze, MinIO, RustFS — всё это теперь не "экспериментально", а production-ready.

Push sync jobs теперь могут шифровать снапшоты на лету перед отправкой на удалённый datastore — для сценариев когда принимающий сервер находится в менее доверенной среде. Pull sync jobs симметрично умеют расшифровывать. Ключи для tape и sync теперь управляются из единой панели.

Sync jobs теперь обрабатывают несколько групп параллельно через новый параметр worker-threads. Это увеличивает throughput на высоколатентных линках и помогает обойти ограничения HTTP/2 соединений.

Под капотом: Debian 13.4 Trixie, Linux kernel 7.0 как стабильный default, ZFS 2.4.

# Обновляем существующую установку через APT:
apt update && apt dist-upgrade -y

# Проверяем версию после обновления:
pbs-manager version

# Настраиваем S3 datastore через API (или через WebUI):
# Storage -> Add -> S3-Compatible Storage
# Указываем: bucket, endpoint, access key, secret key, region

# Настраиваем параллельные потоки для sync job (в WebUI):
# Datastore -> Sync Jobs -> Edit -> Worker Threads: 4
# Рекомендуется: 2-8 в зависимости от количества групп и ширины канала

# Проверяем статистику S3 datastora:
# Storage -> [datastore name] -> Summary -> Request Counters
# Мониторим API requests/day и transfer bytes

# Включаем шифрование sync job:
# Sync Job -> Edit -> Encryption -> Enable
# Выбираем ключ (создать: Configuration -> Sync Encryption Keys)

Зачем это важно:
Стратегия 3-2-1 становится реальной без дорогих решений: быстрые локальные бэкапы на основном хранилище PBS, копии в S3 для офсайт-защиты. Теперь это не хак через rclone, а встроенная функция с мониторингом и шифрованием.

Итог: PBS 4.2 — апгрейд без поводов откладывать. Особенно если уже смотрели на S3 как on offsite target.

#linux #proxmox #backup #s3 #storage #sysadmin #admin_future

🐧 Skills: три CVE ядра Linux в CISA KEV — и почему «локальная» уязвимость с CVSS 9.8 должна насторожить.

Коллеги, 18 сентября CISA добавила в KEV сразу три уязвимости ядра. Red Hat 19-го подтвердил эксплуатацию и наличие публичного эксплойта. Срок для федеральных агентств — 21 сентября, всего три дня. Это нетипично мало.

ЧТО ЗАКРЫТО:
CVE-2025-39682 (9.8) — kernel TLS (модуль tls), путь приёма
CVE-2026-53266 (8.8) — ebtables SNAT, out-of-bounds write при переписывании ARP
CVE-2025-39964 (7.8) — AF_ALG, гонка при двух записях в один сокет

ФАКТ vs ИНТЕРПРЕТАЦИЯ:
Все три по описанию требуют локального доступа. CVSS 9.8 при локальном векторе — противоречие: такую оценку обычно дают сетевым багам без аутентификации. Значит, либо оценка завышена, либо вектор шире описанного. До разъяснений исходим из худшего. Практический смысл: это стадия повышения привилегий после первичного доступа — через веб-шелл, контейнер или украденный SSH-ключ.

ПРОВЕРКА:

uname -r

# Загружены ли уязвимые подсистемы
lsmod | grep -E '^(tls|ebt_snat|ebtable_nat|ebtables|af_alg|algif_[a-z]+)\s'

# Не вшиты ли в ядро (=y — блэклист не поможет, только обновление)
grep -E 'CONFIG_TLS=|CONFIG_BRIDGE_EBT_SNAT=|CONFIG_CRYPTO_USER_API' /boot/config-$(uname -r)

# Статус по дистрибутиву
# https://security-tracker.debian.org/tracker/CVE-2025-39682
apt update && apt list --upgradable 2>/dev/null | grep -E 'linux-image|proxmox-kernel'

ВРЕМЕННАЯ МЕРА (если патч прямо сейчас невозможен):

cat > /etc/modprobe.d/kev-2026-09.conf <<'EOF'
install tls /bin/false
install ebt_snat /bin/false
install algif_aead /bin/false
install algif_skcipher /bin/false
install algif_hash /bin/false
EOF

⚠️ Перед блэклистом проверить зависимости:
• kTLS используют nginx/HAProxy с ktls и часть NFS-over-TLS
• ebtables использует pve-firewall на Proxmox
• AF_ALG задействуют cryptsetup в отдельных режимах, iwd и часть криптобиблиотек
Блэклист — это мост до перезагрузки в новое ядро, а не решение.

Итог: «локальная» не значит «неважная». В KEV эти CVE попали потому, что их используют как второй шаг атаки. Обновить ядро, перезагрузиться, проверить uname -r — сегодня, если на хосте есть контейнеры, общие учётки или сервисы, доступные извне.

#skills #linux #kernel #cve #kev #proxmox #sysadmin #admin_future

🧠 Skills: Aurora шифрует ESXi. AI на разведке, но цель сдаёт обычный LDAP-запрос

Коллеги, разбор свежей тактики вымогателей, который напрямую касается каждого, кто держит виртуализацию — будь то VMware ESXi, vCenter или Proxmox.

📌 ФАКТЫ (по свежему отчёту Gambit Security)
Кампания Aurora Ransomware: две волны атак в 2026 году на бизнес в Европе, США и Израиле.

AI в роли Co-pilot злоумышленника: оператор использовал Cursor Agent (на базе Claude Sonnet) для автоматизации рутины — генерации конфигов proxychains/VPN, парсинга выдачи Nmap и NetExec, разведки Active Directory, NTLM relay и атак на AD CS.

Операционная дисциплина: атакующий осознанно выставил агенту жесткие рамки — никаких DCSync, без локаута аккаунтов, без регистрации новых машин в домене. Задача — нулевой шум в SIEM.

Как находили виртуализацию: самописный модуль NetExec (esxi_finder.py) вытягивал список хостов через стандартные LDAP-запросы, опрашивал порты 443 и 902, а затем по TLS-сертификату однозначно детектировал гипервизоры и vCenter.

Удар: Linux-бинарник шифровальщика с флагом -esxi тушит виртуальные машины через штатный esxcli и зашифровывает диски (ChaCha20 + RSA-4096).

💡 В ЧЁМ СУТЬ

ИИ здесь не взламывает квантовым алгоритмом — он просто снимает рутину и ускоряет рекогносцировку. Архитектурная дыра ровно та же, что и 5 лет назад: гипервизоры видны из пользовательского сегмента или привязаны к общему AD. Если порт виден наружу, его найдут и без нейросетей.

🛠 АУДИТ БЕЗОПАСНОСТИ
1. Проверяем хост ESXi (по SSH):

Bash

# Проверить, активен ли Lockdown Mode
vim-cmd -U dcui vimsvc/auth/lockdown_is_enabled

# Ограничение белых списков IP для SSH и веб-морды
esxcli network firewall ruleset allowedip list --ruleset-id sshServer
esxcli network firewall ruleset allowedip list --ruleset-id webAccess

# Блокировка запуска неподписанных бинарников (дропает чужой шифровальщик)
esxcli system settings encryption get

# Ревизия локальных учетных записей
esxcli system account list

2. Сканируем из пользовательского сегмента (быстрый smoke-тест):

Bash

nmap -Pn -p 443,902,8006 <подсеть_гипервизоров>
# Порты должны быть отфильтрованы в глухую! (8006 — для Proxmox VE)

🛡 БАЗОВЫЙ ЧЕКЛИСТ ЗАЩИТЫ ГИПЕРВИЗОРОВ
Изолированный Out-of-Band / Management VLAN: интерфейсы управления ESXi, vCenter и Proxmox VE не должны маршрутизироваться в клиентские подсети. Доступ — строго через выделенный Jump-хост с MFA.

Никакого прямого членства в Active Directory: гипервизорам не место в корпоративном домене. Если ESXi все еще там — срочно проверяйте группу ESX Admins и закрывайте дыру CVE-2024-37085.

Харденинг хостов: флаг execInstalledOnly включен, SSH заглушен на уровне службы и поднимается только под регламентные работы.

Неизменяемые (Immutable) бэкапы: резервные копии должны лежать в изолированном пуле (WORM/S3 Object Lock/air-gapped), к которому нет и не может быть доступа с доменными учетками.

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

#skills #esxi #vmware #proxmox #ransomware #virtualization #sysadmin #admin_future

🖥 Proxmox запускает поддержку 24/7 с 19 октября. Закрыт главный аргумент «против» в корпоративе

Коллеги, четверг. Новость для всех, кто ведёт проекты миграции с VMware vSphere и регулярно слышит от CTO или службы безопасности вопрос: «А кому мы будем звонить в 3 часа ночи, когда упадёт прод?».

📌 ФАКТЫ
Старт круглосуточного SLA: с 19 октября Proxmox Server Solutions официально запускает сервис поддержки 24/7 для всей линейки корпоративных продуктов: Proxmox Virtual Environment (PVE), Proxmox Backup Server (PBS) и Proxmox Datacenter Manager.

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

Тарифные уровни:

Premium Subscription: режим 24/7 доступен сразу с 19 октября. Безлимитное число тикетов, первичное время реакции — до 2 часов, прямая эскалация инженерам разработки ядра.

Standard Subscription: поддержка 24/7 появится чуть позже, в Q4 2026.

Basic Subscription: SLA остаётся в прежних рамках (рабочие часы).

Глобальная экспансия: учреждено американское подразделение Proxmox North America Inc., обеспечивающее перекрытие смен по модели follow-the-sun.

🛠 ПРОВЕРКА ГОТОВНОСТИ НОД К ОБРАЩЕНИЮ В TAC
При ночной аварии время идёт на минуты — данные для сервисной заявки должны собираться мгновенно:

Bash

# 1. Проверяем валидность лицензионного ключа и активный уровень подписки
pvesubscription get

# 2. Выгружаем точные версии установленных пакетов ядра и гипервизора
pveversion -v | head -5

# 3. Контролируем репозитории: enterprise-репозиторий должен быть активен без ошибок
ls -la /etc/apt/sources.list.d/

# 4. Снятие полного диагностического слепка ноды (базовый артефакт для любого тикета)
pvereport > /root/pvereport-$(hostname).txt

💡 В ЧЁМ СУТЬ

Наличие контракта 24/7 снимает формальный барьер у топ-менеджмента, но не отменяет законов физики: оно не заменяет локальный кворум Corosync, кластерный High Availability и отработанный план Disaster Recovery.

Дежурный инженер вендора в Вене или США в первую очередь запросит вывод

pvereport

и системные журналы. Снимите и сохраните эталонный отчет

pvereport

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

#proxmox #virtualization #support #vmware #enterprise #ha #sysadmin #admin_future

🚨 PwnEscape (CVE-2026-99999): побег из ВМ на хост KVM через virtio-net. Proxmox уже выпустил исправленное ядро

Коллеги, понедельник. Если у вас Proxmox или любой KVM — это пост номер один на неделю.

📌 ФАКТЫ
Уязвимость ядра Linux в обработке virtio-net и TAP в KVM

Последствия: утечка памяти хоста, его падение или выполнение кода на хосте из гостевой ВМ

CVSS: Linux CNA/NVD — 9.3, Red Hat — 8.8. Оценки привилегий в госте расходятся: от «любая нагрузка, отправляющая трафик» до «нужен root в госте»

В KEV пока нет, эксплуатация в дикой природе не подтверждена. Утечку памяти показали в продакшене Vercel

Обходного решения нет, только обновление ядра и перезагрузка

Исправлено:

Plaintext

Proxmox VE : proxmox-kernel-7.0.14-24-pve (PSA-2026-00068-1)
Debian 13  : 6.12.113-1 (DSA-6568-1)
Debian 12  : 6.1.190-1  (DLA-4841-1)
Upstream   : 6.1.190 · 6.6.159 · 6.12.113 · 6.18.57 · 7.2.11

🛠 PROXMOX: ОБНОВЛЕНИЕ БЕЗ ПРОСТОЯ
Bash

# 1. Проверяем текущее ядро и версию PVE
uname -r && pveversion -v | grep -E 'kernel|manager'

# 2. Выкачиваем патчи
apt update && apt full-upgrade

# 3. Уводим ВМ с узла, ребутаем хост, возвращаем — узел за узлом
qm migrate <VMID> <NODE> --online

💡 В ЧЁМ СУТЬ

Граница между ВМ и хостом — главное обещание виртуализации. Если на одном хосте живут ВМ разной степени доверия (клиентские, тестовые, DMZ), обновляйтесь в первую очередь. Live migration делает это без простоя — ради таких дней её и настраивают.

#security #proxmox #kvm #virtualization #linux #cve #sysadmin #admin_future

🖥 Proxmox: с сегодняшнего дня поддержка 24/7, а ветка 8.x уже без обновлений. Чек-лист перехода на 9

Коллеги, два события по Proxmox, которые стоит связать между собой.

📌 ФАКТЫ
С 19 октября Proxmox запускает круглосуточную enterprise-поддержку (Premium — сразу, Standard — в Q4 2026)

Proxmox VE 8 — конец поддержки в августе 2026. Debian 12 продолжает получать патчи через LTS до июня 2028, но pve-manager, qemu-server, pve-qemu-kvm, ядро Proxmox и Ceph обновляться перестали

Значит, свежие исправления вроде PwnEscape приходят в ядро PVE 9. Узлы на 8.x их не получат

🛠 ЧЕК-ЛИСТ 8 → 9
Bash

pveversion                     # сначала до последней 8.4 (pve-manager ≥ 8.4.1)
ceph --version                 # гиперконвергентный Ceph — сначала до Squid 19.2
df -h /                        # минимум 5 ГБ свободно, лучше 10+
pve8to9 --full                 # только проверяет и сообщает, ничего не меняет

Дальше узел за узлом: унести ВМ → репозитории на Trixie → apt dist-upgrade → перезагрузка → проверка → следующий узел. Репозитории переходят на формат deb822, помогает apt modernize-sources.

💡 В ЧЁМ СУТЬ

Поддержка 24/7 появилась, но платить за неё и сидеть на неподдерживаемой 8.x — плохая комбинация. Сначала обновление до 9 и бэкап в PBS, потом подписка.

#proxmox #virtualization #upgrade #debian #sysadmin #admin_future