Серверное администрирование *

У меня на столе стоит небольшая золотистая коробочка размером чуть больше Mac mini. Внутри — приватный AI-сервер: чат с локальной 26B-моделью, поисковая индексация моих документов с GPU-парсингом, конструктор агентов в Dify, RAGFlow для тяжёлого парсинга PDF, мониторинг, бэкапы, опциональный кластер из двух машин по QSFP 200G. Тридцать контейнеров, пять минут на установку через sudo bash install.sh, ноль обращений к внешним API.

Я делал это не как pet-project, а под себя — мне нужна была машина для работы с корпоративными документами, договорами и регламентами, которые ни при каких условиях нельзя отдавать в облачные ассистенты. Сборка получилась самостоятельным дистрибутивом — назвал его AGmind, выложил на GitHub под Apache 2.0.

В статье разберу:

— из чего собран стек и зачем там каждый компонент; — почему RAGFlow пришлось пересобрать с нуля и что я туда добавил; — как устроен кластер из двух Spark'ов; — пять конкретных грабель GB10, которые я ловил вечерами; — почему Claude Code за месяц превратил один из этих компонентов в работающий продукт, но при этом не заменил собственно программиста.

Несколько дней назад, 29 апреля 2026 года, вышел Proxmox Backup Server 4.2. Формально это промежуточный релиз: обновили базовую систему до Debian 13.4 Trixie, поставили Linux 7.0 как новый стабильный вариант ядра, добавили ZFS 2.4.1, поправили ошибки и доработали интерфейс. Но по смыслу релиз заметнее, чем кажется: S3-совместимые объектные хранилища стали официально поддерживаемыми, синхронизация между серверами научилась работать параллельно, появились шифрование и расшифровка на стороне сервера для задач синхронизации, а группы резервных копий и пространства имён теперь можно перемещать внутри хранилища.

То есть Proxmox Backup Server постепенно уходит от образа «удобной бэкапницы рядом с Proxmox VE». Он становится отдельным сервером резервного копирования: с дедупликацией, политиками хранения, проверкой целостности, удалённой синхронизацией, S3-хранилищами, лентами и внятной эксплуатационной моделью. Нет, не универсальной заменой всем системам резервного копирования на свете, но очень естественным инструментом для тех, у кого инфраструктура уже построена вокруг Proxmox.

Infrastructure as Code научила нас важной дисциплине: инфраструктура не должна жить только в голове. Ресурсы, настройки и изменения надо описывать, хранить в Git, применять повторяемо и обсуждать как код.

Это все еще правильная мысль. Terraform хорошо описывает ресурсы. Ansible хорошо описывает действия. CI/CD хорошо описывает путь изменения от репозитория до рабочей среды. Мониторинг хорошо ловит симптомы.

Но когда в эксплуатацию входит ИИ-агент, появляется новый вопрос: что агент должен понимать перед действием?

Не какую команду выполнить. Не какой ресурс создать. Не какой playbook применить. А именно понимать: куда он попал, что здесь считается правдой, что уже проверено, что только предполагается, какие решения нельзя повторять, какие секреты нельзя читать, что обязательно записать после изменения.

Я называю этот слой AgentOps.

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

Привет! Меня зовут Даниил Ткаченко, я веб‑разработчик в ИТ‑компании «Активика». В статье я поделюсь опытом развёртывания Sentry self‑hosted для высоконагруженного проекта. Несмотря на обилие материалов по SaaS‑версии, актуальных гайдов по self‑hosted‑установке почти нет — особенно с учётом современных требований к производительности и отказоустойчивости.

Мы столкнулись с рядом проблем: нестабильностью на базовом хостинге, отсутствием перехвата HTTP‑ошибок и быстрым заполнением диска. Под катом разберу каждую проблему, покажу код решений и дам рекомендации для тех, кто планирует развернуть Sentry самостоятельно.

Статья будет полезна разработчикам и DevOps‑инженерам без опыта работы с self‑hosted Sentry.

Рано или поздно админ VMware упирается в один и тот же вопрос: как навесить мониторинг на vCenter или Cloud Director, не сломав поддержку аплайнса. Официально — никак. Неофициально — Zabbix Agent 2, разложенный поверх Photon OS 4 так, что система остаётся нетронутой. Разбираем подход, который переживает рестарты, FIPS и обновления.

Давайте разберем как с помощью утилиты ktpass.exe создавать гарантированно рабочие файлы keytab. Подробно и с примерами рассмотрим каждый параметр утилитыktpass.exe. А самое интересное - вы узнаете неочевидные факты о принципах использования salt при генерации ключей Kerberos, из-за которой получаются нерабочие ключи AES. В этом поможет инспекция базы ntds.dit командлетами DSInternals.

Ситуация до боли знакома каждому, кто регулярно арендует выделенные серверы: вы оплачиваете счет, заходите по SSH и видите, что ОС установлена на /dev/sda, а второй диск просто болтается пустым. Никакого RAID, никакой отказоустойчивости. Умрет первый диск — ваши данные исчезнут. Мы в SoftStore идем по пути полного контроля над процессом. В этой статье разбираем пошаговый протокол: как собрать программный RAID 1 и LVM прямо на живой, работающей операционной системе без использования Rescue-режима и переустановки. В качестве бонуса — практика по управлению квотами, снапшотами и замене дисков в Production.

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

Предупрежу, в статье МНОГО БУКВ, поэтому можно сразу перейти к Linux, Windows или к инструментам (они в самом конце).

Самая опасная угроза — внутри

В массовом представлении угроз информационной безопасности главным врагом остаётся внешний хакер. Однако многолетняя практика эксплуатации корпоративных ИТ‑систем показывает более неприятную реальность.

Днём на работе вокруг всегда коллеги, созвоны, обсуждения в чатах. Если что-то непонятно, можно быстро спросить совета у более опытных инженеров. Ночью всё по-другому. Дежурный остаётся один на один с системой оповещений, и разбираться приходится самостоятельно. Наверное, поэтому одна из самых странных вещей в мониторинге проявляется именно ночью.

На одном из дежурств мне за несколько часов пришло больше десятка уведомлений. То температура в стойке подскочила на пару градусов. То CPU неожиданно преодолел порог. То один из дисков выдал предупреждение SMART. Конечно, я проверял каждый сигнал, смотрел графики, открывал логи и переключался между дашбордами. Но метрики и без этого возвращались к исходным значениям, и всё продолжало работать как обычно.

К утру инфраструктура так и не полыхнула синим пламенем, зато система оповещений просто разрывалась. Так я впервые узнал об «усталости от алертов» и начал искать способ справиться с этой проблемой.

Если коротко: После дефейса сайта нашего знакомого из-за утекшего пароля от админки мы поняли, что управлять доступами нетехнической команды (редакторы, SEO, подрядчики) через VPN или статические IP - это боль. Существующие proxy требовали рестартов и рулились конфигами. В итоге мы написали свой forward-proxy на Go, где доступ выдается токеном через расширение браузера, а правила (TTL, лимиты трафика, доступные домены) применяются на лету без разрыва соединений.

Сегодня, 22 апреля 2026, прошла конференция ML-ечный путь в Open Space. Ну адрес вполне себе Земной. На мероприятии собрались и менеджеры, и DevOps, и специалисты по безопасности, и руководители направлений, директора в различных областях, смежных с разработкой и поддержкой облачных серверов.

Одноразовые алиасы скрывают основной почтовый ящик и надёжно защищают от спама через включение/отключение алиасов, которые засветились у спамеров.

Оригинальный hosted-сервис Addy.io (AnonAddy) предоставляется как платная услуга. Хотя есть бесплатная версия, но она работает с ограничениями. При этом исходный код сервера открыт, так что его можно установить на VPS и использовать без ограничений — со всеми функциями платной подписки и без ограничений трафика.

Привет, Хабр! Меня зовут Сергей, я разработчик облачной платформы в Selectel. В прошлой статье я рассказал об использовании Terraform для создания глобального роутера и настройки сетевой связности между разными регионами облака. Сегодня продолжим тему и объединим в сеть выделенный и облачный серверы.

Историю Linux обычно рассказывают как историю об удачном ядре. На деле это ещё и история лицензии GPL, которая повлияла на рынок, культуру разработки и саму архитектуру экосистемы. Но что было бы, если Linux пошёл по пути BSD? Альтернативный сценарий представил в статье, заходите похоливарить в комментарии. 

В малом и среднем бизнесе ИТ-аутсорсинг часто начинается не с аудита и архитектуры, а с подписания абонентского договора. В результате подрядчик тонет в заявках, а инфраструктура продолжает работать как попало. При этом владелец бизнеса ждет от «поддержки» и починку вчерашних проблем, и построение завтрашних сервисов в рамках одной фиксированной платы. Через несколько месяцев становится ясно, что количество инцидентов растет, а риски не уменьшаются.

Если вы когда-либо выставляли сервис в интернет и смотрели на логи — вы знаете, что происходит в первые минуты. Сканеры, боты, перебор паролей. Firewall помогает, но не всегда. VPN — хорошо, но не всегда удобно и сами протоколы в России к примеру хорошо работают. А что если сервер будет просто отказывать в соединении всем, у кого нет нужного криптографического сертификата — ещё до того, как они увидят страницу логина? Это и есть mTLS.

В статье разберём: что такое mTLS и как работает рукопожатие, как это связано с Zero Trust, от каких атак защищает и где принципиально бессилен, какие риски несёт сама PKI-инфраструктура и где чаще всего ошибаются при реализации. В конце — практика: как мы в Opensophy сделали mtls.sh, bash-скрипт для управления mTLS-сертификатами под Traefik, и почему архитектура «промежуточный CA на каждого клиента» позволяет мгновенно отзывать доступ без CRL и OCSP в Traefik.

Статья будет полезна всем, кто хочет защитить свои сервисы — будь то домашняя лаборатория, панели управления вроде Proxmox или Portainer/Dokploy, внутренние API или любой сервис, который не должен быть доступен всем подряд. Если коротко: если вы выставляете что-то в интернет и не хотите, чтобы туда мог зайти кто угодно — mTLS для этого и существует.

Привет, Хабр! Летом мы рассказывали о сложном, но очень интересном пути в создании UEFI-загрузчика для серверных продуктов компании OpenYard. Теперь хочется перейти к его постоянному спутнику ― BMC, без которого сегодня трудно представить полноценную серверную платформу. 

В этой статье поделюсь инструкцией по переносу, в которой учтены неочевидные баги несовместимости Traefik 3 с Docker API, политика безопасности свежего Postgres и конфликты ключей шифрования.

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

Потому что бот работает только пока открыт ваш ноутбук.

Это момент когда большинство разработчиков застревают. Код написан, идея рабочая — но бот живёт только на вашем компьютере и умирает как только вы закрываете терминал. Гуглишь "как задеплоить телеграм бота", находишь статьи про Docker, Kubernetes, CI/CD pipelines — и закрываешь вкладку.

На самом деле всё проще.

Чтобы бот работал 24/7 нужно три вещи: дешёвый VPS за 300-500 рублей в месяц, минимальная конфигурация и systemd который не даст боту упасть и не встать. Никаких сложных конфигураций.

В этой статье я покажу как перенести готового aiogram-бота на сервер с нуля. Без лишней теории — только конкретные команды которые можно скопировать и запустить. Весь процесс занимает около восьми минут.

Поехали.