⚡ Outlook на RuPost: что реально переезжает, а что придётся пересоздавать вручную

RuPost от «Группы Астра» внесён в Единый реестр российского ПО (запись №14647), поэтому его можно закупать по 44-ФЗ/223-ФЗ и менять им Exchange там, где импортозамещение закреплено регламентом. Сам RuPost сертификата ФСТЭК не имеет; требования регулятора закрывает сертифицированная ОС Astra Linux SE, на которой он работает.

Почтовые ящики, структура папок и флаги переносятся полностью через IMAP-синхронизацию. RuPost Migration Tool делает инкрементальные прогоны, последний из которых в день переключения занимает минуты. Режим параллельной работы позволяет пользователям получать почту во время длинного первого прогона.

С остальным сложнее. Повторяющиеся серии в календарях требуют проверки таймзон после импорта через iCalendar. Делегирование и Send As настраиваются заново через ACL RuPost. Правила Outlook на стороне сервера не переезжают: создаются вручную. Публичные папки переносятся частично: сначала инвентаризация за последние 12 месяцев, актуальные переезжают как общие ящики, остальное уходит в PST-архив. Без такого фильтра на одном проекте получили 800 папок, из которых половина была мусором пятилетней давности.

🔧 Про Outlook отдельно. Нативного MAPI/EWS у RuPost нет. Outlook подключается через плагин: почта по IMAP/SMTP, календари и контакты по CalDAV/CardDAV. Сценарии, завязанные на MAPI, нужно проверять на тестовом стенде до подписания договора. На одном проекте заказчик заложил «100% совместимость с Outlook по MAPI» без проверки, и на этапе опытной эксплуатации пришлось переводить часть пользователей на IMAP-профиль и веб-клиент.

💰 Standard-редакция стоит ориентировочно 2 000–3 300 ₽ за ящик (подписка или бессрочная лицензия), Enterprise только по запросу. В смете часто недооценивают не лицензии, а человеко-часы: примерно час на пользователя на вопросы первой недели. Для 200 пользователей это ещё 200 часов поддержки.

RuPost оправдан, когда нужен софт из реестра, уже развёрнут стек «Группы Астра» или нужен вендорский SLA. Для десятков ящиков без регуляторных ограничений Mailcow или Stalwart обойдутся дешевле в эксплуатации.

Пятиэтапный план миграции, команды проверки SMTP/IMAP/DNS и таблица совместимости сущностей Exchange — как переехать с Exchange без потери писем разбирает команда @itforprof

Stalwart умещается в 256 МБ оперативной памяти. Mailcow рекомендует от 6 ГБ.

⚡ Разница в 24 раза, и это только по памяти. VPS под Stalwart обходится от 800 ₽ в месяц, под Mailcow нужен сервер от 2 500 ₽. На 100 сотрудников за год набегают реальные деньги.

Для компании из 100 человек корпоративная почта на Яндекс 360 стоит 382 800 ₽ в год. На собственном сервере: Stalwart с Enterprise-лицензией (2 EUR за ящик в год) обходится в 31 600 ₽, Mailcow бесплатен как продукт, итого 30 000 ₽ за сервер. Дешевле облака в 10–12 раз.

Три сервера решают одну задачу с разными компромиссами:

• Stalwart написан на Rust, один бинарник заменяет Postfix, Dovecot и SOGo. Единственный из трёх поддерживает JMAP и встроенную дедупликацию хранилища: одинаковые письма хранятся один раз, экономия диска 20–40%. Минус: проект pre-1.0, веб-клиент ставится отдельно (Bulwark, Roundcube).

• Mailcow: Docker-стек из 15 контейнеров, SOGo из коробки (почта, календарь, контакты), веб-панель администратора. Разворачивается за 30 минут, лицензия бесплатна. Минус: рекомендуется от 6 ГБ RAM, без Docker не работает.

• iRedMail: ставится прямо на систему без контейнеров, Postfix и Dovecot как системные сервисы, полный контроль над конфигами. Проекту больше 10 лет. Минус: панель iRedAdmin-Pro стоит от 499 USD в год, дороже Enterprise Stalwart.

✅ Когда что брать: минимальный VPS и кластеризация → Stalwart; «из коробки» с веб-интерфейсом и бесплатно → Mailcow; bare metal без Docker → iRedMail. Любой вариант выходит в 15–26 ₽ на пользователя в месяц.

💰 SPF, DKIM и DMARC обязательны при любом выборе: без этих записей письма уходят в спам. Если штатного администратора нет, настройку почтового сервера выгоднее передать специалистам.

Матрица выбора с расчётом стоимости владения и разбором каждого протокола: как выбрать почтовый сервер без ошибок разбирает команда @itforprof

🔧 Российские аналоги Microsoft Exchange: что реально заменяет почту в реестре Минцифры

Непропатченный Exchange 2016/2019 в одном из проектов финансового сектора стал точкой входа в домен. После этого инцидента решение о миграции принимало уже правление, а не ИТ-отдел. Это типичная траектория: тянут старый сервер «как есть», пока служба безопасности не закроет доступ к зарубежным облакам или регулятор не потребует ПО из реестра.

Закупать реестровое ПО обязаны органы власти, госучреждения и компании с госучастием по 44-ФЗ и 223-ФЗ. Сертификат ФСТЭК это отдельное требование, актуальное для ИСПДн высоких классов и гостайны. Продукт может быть в реестре без сертификата и наоборот: службы безопасности часто путают эти два условия.

📊 Пять кандидатов из реестра под разные профили:

• RuPost (ГК Астра, реестр №14647): параллельный режим со старым Exchange из коробки, кластеризация, клиент RuPost Desktop, веб и мобильные. Полная синергия со стеком Astra Linux и ALD Pro. На одном проекте держали Exchange и RuPost в параллели три недели, и это спасло мобильные ActiveSync-профили.
• CommuniGate Pro (реестр №7112): единое ядро для почты, мессенджера, VoIP и календарей, исторические сертификаты ФСТЭК. Выбор для госорганов с действующими аттестатами. Слабое место это веб-клиент, пользователям Outlook нужна адаптация.
• Tegu: лёгкий сервер для 50–150 пользователей, развёртывается за несколько часов с DNS, DKIM и SPF. Групповых календарей уровня Exchange и развитой ролевой модели нет.
• Mailion («МойОфис»): объектное хранилище под сотни тысяч ящиков, интеграция с офисным пакетом. Под крупные холдинги и министерства.
• VK WorkMail: единственный облачный из тройки. Не закрывает требования on-premise для КИИ и информации ограниченного доступа.

⚡ Если реестр не обязателен: Carbonio (преемник Zimbra), mailcow (Docker, 20–500 пользователей на одного инженера), iRedMail (классический стек на хосте) или Stalwart на Rust с JMAP и S3-бэкендом. На любом FOSS-варианте подключайте smart-host с прогретой репутацией и настраивайте SPF, DKIM, DMARC, rDNS: собственный сервер на белом IP попадает в спам-листы крупных провайдеров за вторую неделю.

Сравнительная таблица по реестру, ФСТЭК, модели развёртывания и сценариям миграции с Exchange доступна в полном разборе IT For Prof

🔒 CommuniGate Pro: почта, телефония и мессенджер в одном продукте с сертификатом ФСТЭК

Для госсектора и объектов критической информационной инфраструктуры выбор почтовой платформы упирается в документы. CommuniGate Pro закрывает оба уровня: реестровая запись Минцифры № 7112 и сертификат ФСТЭК по 5 уровню доверия.

Архитектурно это монолитное ядро: корпоративная почта (SMTP, IMAP, ActiveSync), мессенджер, IP-телефония (SIP/VoIP), календари и видеосвязь в одном продукте. Для администратора это означает одну точку управления и одну модель безопасности вместо разрозненных почтовика, XMPP-сервера и телефонной АТС. Платформа поддерживает более 15 операционных систем, включая Astra Linux, РЕД ОС и ALT Linux, то есть разворачивается на той же сертифицированной ОС, что и остальная инфраструктура. По данным вендора, в России развёрнуто 3 млн рабочих мест, из них около миллиона в госсекторе.

⚡ Миграция с Exchange строится через режим сосуществования: обе системы работают параллельно с обменом данными о занятости (Free/Busy), а ящики переносятся группами. Почта, календари и контакты переезжают в рамках проекта, мобильные клиенты переключаются через ActiveSync. Административная модель и интеграции проектируются заново, это полноценный проект, а не замена сервера один в один. Главные риски: переподключение мобильных, недонастроенные интеграции и просадка доставляемости. Все снимаются пилотной группой и поэтапным переключением.

✅ Если задача только корпоративная почта из реестра без телефонии, практичнее смотреть на RuPost. Если требований реестра нет и важна близость к Zimbra-стеку, подойдёт Carbonio. CommuniGate Pro оправдан там, где нужен полный набор коммуникаций с подтверждёнными регуляторными документами.

Пошаговый план миграции и критерии выбора между CommuniGate Pro, RuPost и Carbonio — в полном разборе от IT For Prof

⚡ Zimbra Network Edition больше не продлевается. Что дальше?

С 2022 года российские компании лишились продления коммерческих лицензий Zimbra NE и вендорской поддержки на инциденты. Серверы продолжают работать, но обновления безопасности, кластерные сценарии и корпоративные функции ActiveSync фактически заморожены. Open Source Edition жива, но без коммерческого SLA и с неровным развитием. Миграция перестала быть теоретическим вопросом.

Путей два: Carbonio от итальянской компании Zextras и RuPost от Группы Астра. Развилка решается одним вопросом: реестр Минцифры обязателен или нет?

Carbonio: та же команда, другой стек

Zextras годами выпускала расширения для Zimbra. Carbonio — это не форк Zimbra, а самостоятельный продукт, но инструменты миграции заточены именно под переезд с Zimbra OSE: скрипты и imapsync переносят почту, контакты и календари. Модель администрирования узнаваема для тех, кто работал с Zimbra.

Что меняется под капотом: стек строится на Consul для обнаружения сервисов и PostgreSQL 16. Команды CLI другие, zmprov и zmmailbox не перенесутся, синтаксис придётся осваивать заново.

Community Edition бесплатна и разворачивается самостоятельно. Коммерческая версия с расширенными функциями и официальной поддержкой идёт через сертифицированных партнёров Zextras. Главный ограничитель: Carbonio в реестре российского ПО не числится. Для КИИ и госсектора этот аргумент закрывает разговор.

RuPost: реестр и миграция с Exchange

RuPost включён в реестр отечественного ПО под номером 14647 (запись от 23.08.2022). Продукт входит в Группу Астра и ориентирован прежде всего на Astra Linux. По данным вендора, систему используют более 400 000 пользователей.

Встроенный мигратор RuPost заточен под Exchange: режим сосуществования с Exchange на время поэтапного перехода работает из коробки. Для переноса из Zimbra используются стандартные почтовые механизмы: IMAP-синхронизация и экспорт-импорт.

• Реестр Минцифры: Carbonio нет, RuPost да (№ 14647)
• Готовые миграторы из Zimbra: Carbonio (скрипты, imapsync), RuPost (IMAP, экспорт)
• Стоимость входа: Carbonio CE бесплатна, RuPost коммерческий продукт с поддержкой на русском
• Для кого: Carbonio для коммерческих компаний без требований реестра, RuPost для КИИ и госсектора

🔧 Что проверить при переезде

В IT For Prof мы проходим миграцию с Zimbra в несколько этапов: аудит ящиков и доменов, тестовый контур с пилотной группой, поэтапный перенос с контролем целостности, настройка SPF, DKIM и DMARC на новом сервере. Основные риски управляемы при пилотной обкатке: потеря писем на некорректных кодировках, разрыв мобильной синхронизации и недонастроенные фильтры из Zimbra. Весь домен переводим только после проверки пилота, не одним прыжком.

Матрица выбора, этапы переноса ящиков и подводные камни imapsync — как выбрать между Carbonio и RuPost

⚡ Mail и Яндекс отключают бесплатный IMAP: дедлайны 12 и 29 июня 2026

Mail (VK) закрывает бесплатный доступ по IMAP/POP3/SMTP 12 июня, Яндекс — 29 июня 2026. У всех, кто работает с почтой через Outlook, Thunderbird, The Bat или Apple Mail, программа просто перестанет получать письма. Останутся веб-версия и мобильное приложение либо платная подписка.

Официальная причина у обоих сервисов одна — «повышение безопасности авторизации». На практике это означает выбор из трёх сценариев: личная подписка на каждый ящик, облачный бизнес-пакет на своём домене или собственный почтовый сервер.

📊 Цены на июнь 2026 за ящик/сотрудника в месяц:
• Mail Space — 199 ₽ или 1 290 ₽/год, ящик остаётся на @mail.ru
• Яндекс 360 Премиум — от 166 ₽/мес при оплате за год
• VK WorkSpace на своём домене — 259/459 ₽ (207/367 ₽ при оплате за год)
• Яндекс 360 для бизнеса — 319/549/1 399 ₽, при этом минимальный тариф с 1 июля 2026 индексируется до 485 ₽

🔧 Свой сервер — другая математика: разовая настройка 15 000 ₽ и аренда 700–1 000 ₽/мес фиксированы и не зависят от числа ящиков. До 5 ящиков подписка дешевле всегда. С 4–5 ящиков свой сервер выгоден, если в штате есть системный администратор. Под ключ с сопровождением окупается с 13–20 сотрудников, и индексация Яндекса сдвигает эту точку ещё ниже. Из реестра Минцифры подойдёт RuPost.

Что сделать до дедлайна: посчитать число ящиков, проверить, кто работает в Outlook/Thunderbird, и не откладывать перенос — DNS-записи и подготовка домена требуют времени.

Расчёт окупаемости своего сервера на 1, 2 и 3 года с таблицами и сравнение по числу сотрудников от IT For Prof — в полном разборе

🔒 Корпоративный ИИ-ассистент в своём контуре: AstrBot + локальная LLM в Docker

Связка локальной языковой модели и AstrBot работает внутри периметра компании: переписка с ботом, эмбеддинги и логи остаются на вашем сервере. Это закрывает 152-ФЗ по локализации и снимает зависимость от внешнего SLA.

Когда сотрудник кидает в публичный ChatGPT фрагмент договора или выписку из CRM, он передаёт это оператору сервиса. Для персданных российских граждан сразу включается 152-ФЗ: согласие субъекта, локализация в РФ, реестровая запись оператора. Запреты тут работают плохо — пока в корпоративном чате нет легального бота, люди заводят учётки на стороне.

⚡ Из чего собирается стек:

• AstrBot — open source, 1000+ плагинов в один клик, MCP, Agent Sandbox для изолированного выполнения кода и Shell
• Мессенджеры: Telegram, Slack, Mattermost (через webhooks), Rocket.Chat, Feishu, DingTalk, WeChat для предприятий
• Слой инференса: Ollama для старта, llama.cpp с GGUF-квантизацией под скромное железо, vLLM/TGI для продакшена с батчингом
• Модели: Llama 3, Qwen 2.5, Saiga, T-lite для open source; GigaChat On-Prem и YandexGPT On-Prem там, где важно происхождение модели

📊 Железо под нагрузку:

• Пилот 5–15 сотрудников: одна потребительская GPU с 16–24 ГБ VRAM, модель 7–13B в квантизации Q4–Q5
• 50–100 активных пользователей: серверная карта 40–80 ГБ или две по 24 ГБ
• CPU-only — рабочий вариант для текстовых задач без жёстких требований к latency

RAG строится по схеме «загрузка → чанки 400–800 токенов с перекрытием → мультиязычный эмбеддер → Qdrant или Weaviate → переиндексация по расписанию». В AstrBot есть встроенная база знаний для пилота; для зрелого сценария выносим RAG в отдельный сервис и подключаем через MCP. Доступ к внутренним API (Service Desk, 1С, Jira) ассистент получает теми же MCP-инструментами.

🔧 Compose-каркас: контейнер AstrBot + Ollama + векторная БД в общем bridge-сетевом интерфейсе Docker, наружу торчит только мессенджер, WebUI закрыт reverse-proxy с корпоративным SSO и 2FA.

Сравнение Mattermost Agents / Matrix baibot / AstrBot, чек-лист сетевой изоляции и журналирования, разбор антипаттерна «бот в общем канале без правил» от IT For Prof — в полном разборе с архитектурой и конфигами

🔧 Запись звонка в Битрикс24 не перематывается: причина в режиме отдачи из S3

Бегунок плеера прыгает в начало, разговор играет только с нуля. В DevTools главный признак — сервер отдаёт 200 OK вместо 206 Partial Content, заголовок Content-Range отсутствует. Браузерный плеер физически отказывается перематывать аудио без поддержки Range-запросов.

Корень — в режиме отдачи файлов из облачного S3. По умолчанию запрос идёт через PHP: модуль clouds скачивает объект через readfile(), держит воркер PHP-FPM на всё время отдачи и заголовок Range игнорирует. Решение — флаг bx_fast_download=Y: Битрикс возвращает X-Accel-Redirect, дальше файл проксирует nginx с поддержкой 206 Partial Content и Range.

Ловушка в том, что в свежем bitrix-env файл /etc/nginx/bx/conf/bitrix_general.conf знает только AWS, Rackspace, Clodo, Google CDN и Selectel. Reg.ru (s3.regru.cloud) и FirstVDS (s3.firstvds.ru) — generic-S3 со своими доменами, в дефолте их нет. Включаешь bx_fast_download=Y — запросы доезжают до финального deny all и получают 403: запись звонка молчит, вложения в чатах и Битрикс24.Диск отваливаются вместе с ней.

Reg.ru и FirstVDS работают по path-style: имя бакета уходит в путь URL (s3.regru.cloud/bucket/key), а не в поддомен как у AWS. Копирование AWS-шаблона даёт 404 от хранилища.

📊 Ключевые различия конфигов под двух провайдеров:
• Reg.ru — more_clear_input_headers 'Authorization' (требует модуль headers_more, в bitrix-env собран по умолчанию)
• FirstVDS — proxy_set_header Authorization "" (штатная директива, дополнительный модуль не требуется)
• Оба — path-style addressing, resolver 77.88.8.8 с ipv6=off
• Endpoint в proxy_pass обязан совпадать со значением в /home/bitrix/www/bitrix/.settings.php

Проверка одной командой: curl -I -H "Range: bytes=0-1023" на URL записи. Правильный ответ — HTTP/1.1 206 Partial Content с заголовком Content-Range: bytes 0-1023/.... Если пришёл 200 OK, флаг bx_fast_download ещё в N или запрос промахнулся мимо нового location-блока. Если 403 — Битрикс отдал редирект, nginx проксировал, но S3 отказал: проверяй endpoint в .settings.php и /var/log/nginx/error.log с точным URL запроса.

✅ Готовые location-блоки nginx для Reg.ru и FirstVDS, команды включения флага через PHP-консоль со сбросом кэша опций и чек-лист проверки через DevTools — в полном разборе от IT For Prof

⚡ 260 хостов, 150 шаблонов — алерт сам создаёт задачу и закрывает её без дежурного

Когда мониторинг видит проблему, инженер обычно делает это руками: перешёл в Zabbix, скопировал, завёл задачу в трекере, не забыл закрыть. На потоке из сотен хостов такая схема даёт сбои ежедневно. Мы автоматизировали весь цикл через штатный механизм Zabbix 7.0 — без промежуточных сервисов и внешних баз соответствий.

Наша боевая инсталляция: 260 хостов разных клиентов, порядка 150 шаблонов. Задачи дежурной смены ведём в ПланФикс. До автоматизации связка держалась на внимательности оператора — на таком объёме это проблема.

Как устроена интеграция

Вся механика держится на двух сущностях Zabbix: тип оповещения Webhook (скрипт на JavaScript) и действия с эскалацией. Роль «памяти» о созданной задаче играют теги события — внешней базы соответствий нет, это сознательное решение.

Поток работает так: триггер переходит в проблему → действие проверяет уровень важности, группы хостов и флаг подавления → если проблема прожила дольше одного периода эскалации и её не подтвердили, на шаге эскалации 2 уходит оповещение → скрипт вызывает эндпоинт ПланФикс и получает идентификатор задачи → идентификатор сохраняется в тегах события.

Дальше всё автоматически:
• нажал Acknowledge в Zabbix — задача переходит «В работе»
• триггер восстановился — задача закрывается
• эскалация отменена — задача отменяется, без дублей

Обратная связь тоже работает: принял задачу в ПланФикс — событие в Zabbix подтверждается через JSON-RPC API с комментарием от имени исполнителя.

🔧 Три ключевых решения, которые определили архитектуру

Шумовой фильтр через эскалацию. Операция создания задачи стоит на шаге 2 с условием «Event acknowledged = No». Проблема, мигнувшая на 30 секунд или быстро подтверждённая, задачу не создаёт.

Теги как память. При создании задачи скрипт возвращает Zabbix два тега: __zbx_planfix_taskid и __zbx_planfix_link. Все последующие операции — закрытие, подтверждение, отмена — находят задачу по этим тегам. Внешняя база не нужна.

Строгий порядок доставки. Параметр maxsessions=1 гарантирует, что закрытие задачи не обгонит её создание. Повышать нельзя — иначе операция редактирования придёт по ещё не существующей задаче.

Отмена эскалации — отдельный случай: такое событие маскируется под новую проблему, поэтому в коде скрипта эта проверка стоит первой. Без notify_if_canceled=1 оповещение об отмене вообще не придёт.

Полный код webhook-скрипта на JavaScript, пошаговая настройка медиатипа и чек-лист из 9 пунктов — в разборе интеграции Zabbix и ПланФикс от IT For Prof

⚡ BIRD v2 route-server с автообновлением BGP-префиксов: 12 категорий, один скрипт, резервный кэш на 7 дней

В продакшене мы разворачиваем route-server так: bird.conf живёт в git, локальные настройки и BGP-пиры хранятся отдельно. Фильтры и метки обновляются одной командой git pull, не задевая номер AS, router id и список пиров. BIRD v2 версии 2.16.1 держит более 1000 BGP-сессий в одном потоке при расходе менее 250 МБ RAM на два полных routing view.

Python-агрегатор bird2-bgp-prefix-updater скачивает IPv4-префиксы из RIPEstat и двух источников Antifilter, присваивает каждому одну или несколько числовых меток и пишет результат в /etc/bird/prefixes.bird. Итого 12 активных BGP community с кодами 100–112 (один зарезервирован):

• 100 — RU Combined: все IPv4-сети РФ из RIPEstat
• 101 — Blocked Smart: суммаризация списков заблокированных подсетей
• 102 — подсети из официальных списков Antifilter
• 103 — Gov Networks: сети государственных структур
• 104 — Custom User: Telegram, Cloudflare, Google и custom.lst
• 105 — Reserved: зарезервировано
• 106 — Blocked IP: список ip.lst Antifilter
• 107 — Stripe IP: сети Stripe (API, вебхуки)
• 108 — ByteDance AS396986 (TikTok)
• 109 — Akamai AS20940
• 110 — Roblox AS22697
• 111 — Pinterest AS53620
• 112 — Fastly AS54113

MikroTik, Linux-роутеры и edge-маршрутизаторы получают маршруты с метками и сами решают, что с ними делать. Нужен клиенту только Stripe API через отдельный аплинк — фильтр if (bgp_community ~ [(MY_AS, 107)]) then accept; направит только его, не задевая остальной трафик.

🔧 Ловушка, в которую попадают при первом развёртывании: российская сеть может одновременно лежать в RIPEstat (community 100) и в списке заблокированных подсетей (community 101). Фильтр export_only_ru в bird.conf сначала отбрасывает 101–112, затем разрешает 100 — порядок принципиален. Кэш скачанных ответов хранится 6 часов, повторный запуск агрегатора не порождает сетевого трафика. Если все источники недоступны дольше — скрипт не обнуляет prefixes.bird, а берёт последнюю успешную копию из резервного кэша со сроком жизни до 7 дней. BGP-сессии клиентов продолжают работать без изменений. Для диагностики конкретного адреса команда prefix_updater.py --check 194.67.72.31 за секунду показывает источник и присвоенный community ID.

Архитектуру и команды развёртывания под Debian/Ubuntu и RHEL, полную таблицу кодов community, механику атомарной записи и интеграцию с мониторингом разобрал IT For Prof в детальном техническом руководстве — схема фильтров, шаги установки и диагностика.

⚡ Битрикс24 встаёт по утрам? Виноват модуль «Почта»

Симптом коварен: процессор холодный, MySQL без длинных запросов, swap пуст — а портал отдаёт 502 каждое утро в часы синхронизации IMAP. Мониторинг показывает «всё ок», админ добавляет память — без эффекта. Узкое место сидит в архитектуре PHP-FPM.

Чтение из IMAP-сокета — блокирующая операция: fgets() ждёт ответа Яндекса или Exchange десятки секунд. В стандартном bitrix-env все скрипты крутятся в одном пуле www с pm.max_children порядка 50. Запустились синхронизации десятка ящиков — и воркеры намертво заняты ожиданием почты, живым пользователям обслуживать запросы физически нечем. Перезапуск php-fpm по крону каждые 15 минут (встречали и такое) только убивает сессии и причину не лечит.

🔧 Лечение — изолировать check_mail.php в отдельный пул [mail] с жёсткими лимитами:

Ключевые параметры:
• pm.max_children = 3–12 — по объёму почты, больше бессмысленно (внешний IMAP быстрее не ответит)
• request_terminate_timeout = 40–70s — убивает зависший на сокете воркер
• request_slowlog_timeout на 10 секунд ниже terminate — успеть записать трейс до kill
• pm.max_requests = 100 — страховка от утечек памяти при парсинге писем
• memory_limit = 512M на Debian — вложения с base64-картинками раздувают воркер до сотен МБ
• отдельный mail-slow.log — основной www-slow.log остаётся чистым для диагностики реальных тормозов CRM

Маршрутизация — ровно один URL /bitrix/tools/check_mail.php. На bitrix-env (nginx + Apache) правило кладём в /etc/httpd/bx/custom/check_mail.conf через SetHandler. На nginx-only — точный location = /bitrix/tools/check_mail.php обязательно выше общего location ~ \.php$, иначе общий перехватит запрос раньше. Расширять правило на /bitrix/tools/ целиком запрещено: там лежат скрипты других модулей, webhook-и CRM попадут в маленький почтовый пул и получат 503.

📊 На CentOS-портале с парой ящиков хватает 3 воркеров под пользователем bitrix и сокетом /run/php-fpm/mail.sock. На нагруженном Debian с десятками активных ящиков — 12 воркеров под www-data и /run/php/mail.sock. Принцип универсальный: любой блокирующий внешний интегратор (выгрузка в маркетплейс, опросы API, экспорт в 1С) выносится в свой пул по той же схеме.

Готовые конфиги pool [mail] для CentOS и Debian, правила Apache и nginx, разбор каждого параметра — в полном разборе от IT For Prof

⚡ iVentoy: 34 рабочих места с миграцией на Windows 11 за 7 часов одним инженером

В одном из проектов IT For Prof мы заменили парк из 34 ноутбуков с переходом на Windows 11 и включением в домен. Раньше такое делали два инженера за два дня. С iVentoy уложились в один рабочий день силами одного человека.

iVentoy — PXE-сервер «всё-в-одном»: один бинарник поднимает DHCP, TFTP и HTTP без отдельной настройки сервисов. ISO кладётся в каталог и сразу появляется в загрузочном меню — без распаковки install.wim, правки BCD и SMB-шары. В одном меню держим Windows 10 22H2, Windows 11 24H2, Server 2022, Astra Linux, РЕД ОС, WinPE, Clonezilla и ESXi — поддержка 110+ типов ОС.

🔧 Что важно знать инженеру:
• Установка машины ~20 минут до экрана логина, параллельно ставятся 8–10 штук
• Версия 1.0.35 от 9 июня 2026, один бинарник под Windows и Linux на x86_64 и arm64 — поднимается даже на Raspberry Pi
• Режим «без DHCP»: боевой DHCP контроллера домена не трогаем, отдаём только TFTP+HTTP через option 66/67. В 80% корпоративных внедрений используем именно этот сценарий
• Legacy BIOS, IA32 UEFI, x86_64 UEFI и ARM64 UEFI обслуживаются одним сервером — без отдельных конфигов под pxelinux.0 и bootx64.efi
• Фильтр по MAC отсекает гостевые ноуты от unattend-сценария, который затрёт диск
• Для Linux iVentoy сам решает проблему отсутствующих драйверов NIC и RAID-контроллеров — пересобирать initramfs не приходится

Один инженер запускает 10 машин одновременно — и пока они ставятся, занимается следующей партией.

📊 Подводный камень из практики: запуск iVentoy со встроенным DHCP в общем VLAN с боевым контроллером домена — часть рабочих станций получит IP с «левого» сервера и потеряет шлюз. Правило: либо изолированный сегмент со своим DHCP, либо режим без DHCP через option 66/67 на основном.

Команды запуска, шаблоны unattend.xml и kickstart для Astra Linux/РЕД ОС, разбор Secure Boot и переключения UEFI/Legacy PXE — в полном разборе с кейсом на 34 машины

🔧 GLPI: Service Desk и CMDB в одной open-source системе на своём сервере

GLPI закрывает заявки с SLA и инвентаризацию ИТ-активов в одном веб-интерфейсе, без лицензионных платежей Teclib' — но в реестре Минцифры его нет, поэтому для госзаказчиков и субъектов КИИ путь закрыт.

Для коммерческого сектора это рабочая замена Naumen Service Desk, ManageEngine ServiceDesk Plus, JIRA Service Management и BMC Helix. Данные остаются в контуре заказчика — закрывается 152-ФЗ без облачной обработки третьей стороной. Финансовый блок (бюджеты, поставщики, лицензии) встроен в ядро, а не продаётся отдельным модулем.

Стек минимальный: Linux + PHP с расширениями mysql, xml, gd, intl, mbstring, curl, ldap, zip + MariaDB или MySQL + Apache либо Nginx с PHP-FPM. Для парка до нескольких сотен активов и десятков техников хватает виртуалки на 2–4 vCPU и 4–8 ГБ памяти. Узкое место — не CPU, а скорость диска под MariaDB и настройки PHP-OPcache.

📊 GLPI Agent ставится через GPO или пакетный менеджер на Windows, Linux и macOS — собирает серийники, модели дисков, установленное ПО и патчи. Для коммутаторов, принтеров и точек доступа работает agentless-режим по SNMP: один агент-сборщик закрывает сегмент сети филиала. Без правил дедупликации (Rules → Inventory) по серийнику, UUID и MAC парк за полгода вырастает в полтора раза — один ноутбук после переустановки ОС превращается в новый актив.

Каталог форм самообслуживания снимает 60–70% «свободных» обращений: вместо абстрактной очереди — кнопки «Заявка на доступ», «Новый сотрудник», «Заявка на технику» с маршрутом согласования.

Типовые грабли при установке от инженеров IT For Prof: забытое расширение PHP роняет проверку окружения; дефолтные memory_limit, upload_max_filesize и post_max_size режут импорт инвентаря и вложения в заявках; SELinux в enforcing не даёт веб-серверу писать в каталоги GLPI.

✅ Пошаговая установка на Debian, подключение LDAP/AD, рабочий набор плагинов (Formcreator, Fields, Behaviours, DataInjection) и сценарии интеграции с Zabbix для автосоздания тикетов из алертов — в полном разборе

🔧 Zammad: open-source тикет-система на своём сервере за час в Docker

Официальные пакеты Zammad доступны только для CentOS, Debian и Ubuntu — Windows и macOS остаются вне поддержки вендора. На Linux-хосте docker-compose стек поднимается примерно за 60 минут: четверть времени уходит на подготовку ВМ, четверть на образы, остальное — TLS и первичная настройка.

Под капотом Ruby on Rails, PostgreSQL для базы, Elasticsearch для полнотекстового поиска и Memcached для кэша. Минимум для пилота: 4 vCPU, 8 GB RAM, 80 GB SSD, Ubuntu 22.04 LTS или Debian 12. Узким местом чаще становится Elasticsearch — индекс перерастает JVM heap и вычитывается с диска, поиск тормозит. Лечится расширением heap и выносом ES на отдельный SSD.

Сравнение стеков с близкими альтернативами:
• osTicket — PHP+MySQL, акцент на email, разворачивается быстрее всех
• GLPI — PHP+MySQL, сильный CMDB и учёт техники
• OTOBO — Perl+PostgreSQL, классический ITIL-движок
• Zammad — Rails+Elasticsearch+PostgreSQL, омниканальность из коробки

Каналы заводим по очереди: email через IMAP/SMTP на отдельный ящик support@, Telegram-бот (первое сообщение клиента должно начинаться с /start, иначе тикет приходит без контекста), веб-форма с reCAPTCHA, LDAP/AD с узким фильтром по OU. Один клиент пустил всю AD без фильтра — после первой синхронизации в helpdesk легли тысячи лишних учёток, интерфейс зависал от автодополнений.

Типовая засада docker-инсталляции: переменная TZ не проброшена в docker-compose.yml. Хост в UTC, Zammad настроен на Europe/Moscow — SLA-таймеры считают со сдвигом в час. Проверяйте часовой пояс до того, как заведёте живые тикеты.

Архитектура отказоустойчивого развёртывания, импорт из osTicket через встроенный мастер и миграция с GLPI через REST API — в полном разборе от IT For Prof

🔧 Rocket.Chat на своём сервере: MongoDB в replica set обязательна даже для одного узла

В продакшене Rocket.Chat откажется стартовать без MongoDB в режиме replica set — платформа использует change streams для распространения событий между подами. Это правило срабатывает даже при одном узле БД.

Развёртывание на своём сервере оставляет переписку, файлы и учётные записи внутри периметра компании. На проектах в банке и производстве платформа закрывает сразу два сценария: внутренний корпоративный чат и обращения клиентов через виджет на сайте.

📊 Расчёт ресурсов по нашему опыту:

• 50 сотрудников — один узел, MongoDB на той же машине, SSD под полугодовую переписку, резервные копии на отдельное хранилище
• 200 сотрудников — MongoDB выносим на отдельный сервер, replica set из 3 узлов, 2 контейнера приложения за Nginx, общий S3-бакет для uploads
• 500+ сотрудников — кластер: 3 узла MongoDB, минимум 3 экземпляра приложения, выделенный TURN-сервер для голоса и видео, Prometheus с node-exporter и mongodb-exporter, алерты на репликацию

Грабли из практики: Rocket.Chat на виртуалке с thin provisioning и снапшотами гипервизора без согласования с MongoDB. За 3 месяца база раздулась, снапшот не удалялся, ВМ остановилась по нехватке места на датасторе. С тех пор для MongoDB — только eager-zeroed диск и отдельный том под журнал.

⚡ Первый запуск выполняем поэтапно: сначала поднимаем MongoDB → инициализируем replica set → проверяем rs.status() (PRIMARY, health: 1) → только потом запускаем приложение. docker compose up -d всем стеком сразу в 3 случаях из 10 приводит к тому, что Rocket.Chat успевает записать первые документы до инициализации replica set — после этого базу приходится чистить.

✅ Docker Compose оправдан для 1–2 узлов приложения. От 500 пользователей переходим на Kubernetes с Helm-чартом вендора. SSO через Active Directory, интеграции с Jira, GitLab, Zabbix через webhooks и Apps-Engine — закрывают типовые требования ИБ и DevOps без обучения админов.

Команды инициализации replica set, требования к серверу под 50/200/500 пользователей и docker-compose.yml от команды IT For Prof — в полном разборе

⚡ Open-source тикет-системы: GLPI vs Zammad vs OTOBO vs Chatwoot vs osTicket

GLPI — единственная из пяти систем, которая закрывает связку «тикеты + активы + финансы» в одной установке: Helpdesk, CMDB, бюджеты поставщиков, лицензии и agentless-инвентаризация работают из одного интерфейса.

Облачные SaaS-хелпдески тарифицируются за каждого агента в месяц. При росте команды поддержки с 5 до 50 инженеров счёт растёт линейно, тогда как self-hosted решения по основной лицензии бесплатны: платите только за сервер и администрирование. На горизонте 3–4 лет разница в стоимости владения расходится тем сильнее, чем больше агентов в поддержке.

🔧 Разбор по стеку и зоне применения:

• GLPI — PHP+MySQL, GPLv3. Внутренний ИТ-отдел 200–2000 рабочих мест: связка хелпдеска с CMDB ощутимо экономит время первой линии на заявках по железу
• Zammad — Ruby on Rails+PostgreSQL+Elasticsearch+Redis, AGPLv3. Смешанная поддержка с почтой, Telegram, чатом и Twitter из коробки
• Chatwoot — Ruby on Rails+PostgreSQL+Redis, MIT. Контакт-центр на WhatsApp, Telegram, Facebook, Instagram для розницы и e-commerce
• OTOBO — Perl+PostgreSQL/MySQL, GPLv3. Миграция с OTRS с сохранением процессной модели
• osTicket — PHP+MySQL, GPLv2. Простой почтовый хелпдеск, разворачивается за полдня

📊 Главная ошибка при оценке — считать только лицензию. Реальные статьи расходов: инфраструктура (Rails+Elasticsearch требуют в разы больше RAM, чем PHP), администрирование (Ruby-стеку нужен отдельный DevOps на четверть ставки), коммерческая поддержка, обучение операторов и кастомизация. У GLPI есть 45-дневный пробный период для первой инсталляции — хватает на оценку под реальной нагрузкой.

Небольшая компания внедряла GLPI ради CMDB «на будущее», а позже активы всё равно велись в Excel — некому было заполнять карточки. Система «на вырост» оправдана, только когда рост реальный, а не гипотетический.

Пять типовых сценариев выбора, расчёт стоимости владения за 3 года и схемы интеграции с Active Directory, Zabbix и мессенджерами — в полном разборе от IT For Prof

⚡ Битрикс24: −9 ГБ памяти и TTFB 5,2 → 0,8 с за один день без апгрейда сервера

Клиент: оптовая торговая компания, 120 сотрудников, коробочный портал. Проблема: по утрам карточки сделок открывались 5–15 секунд, в пиковые часы портал отдавал 502 Bad Gateway, отдел продаж терял по 10–20 минут. Внутренний админ добавил серверу RAM — через две недели всё вернулось.

📊 Экспресс-аудит за 60–90 минут по логам nginx, PHP-FPM и медленному логу MariaDB показал четыре независимые причины, и ни одна не про мощность железа:

• Пул PHP-FPM в динамике держал десятки простаивающих воркеров, которые впустую занимали гигабайты
• Модуль «Почта» синхронизировался по блокирующему IMAP прямо в общем www-пуле — в часы синхронизации воркеров не оставалось живым пользователям
• Файлы из S3 Reg.ru шли через PHP, на каждое вложение — отдельный воркер и TLS-рукопожатие
• MariaDB работала на дефолтных значениях, буферный пул InnoDB не вмещал рабочие данные

🔧 Что сделали: перевели www-пул на статический режим с расчётом воркеров под реальную память, вынесли IMAP-синхронизацию в отдельный пул с жёстким таймаутом, добавили в nginx прямое проксирование S3 и Brotli, затюнили InnoDB buffer pool и таймауты в отдельном конфиге, который переживает обновления окружения.

Потребление RAM веб-стеком: 9,3 ГБ → 1 ГБ. TTFB на тяжёлых страницах CRM: 5,2 → 0,8 с. Утренние 502 прекратились. Медленный лог PHP-FPM: ~21 МБ мусора в неделю → десятки килобайт.

✅ Освободившиеся 8 ГБ ушли под буферный пул базы, апгрейд сервера не понадобился. Все работы — один рабочий день.

Формулы расчёта воркеров PHP-FPM, параметры изолированного пула для IMAP и регламент еженедельной профилактики от IT For Prof — в полном разборе кейса.

🔧 Chatwoot: омниканальная поддержка на своём сервере вместо Intercom и Zendesk

Открытая платформа поддержки клиентов с 25 000+ звёзд на GitHub. Объединяет WhatsApp, Telegram, Instagram, email и веб-виджет в одну ленту разговоров — без передачи переписки в чужое облако.

Ключевое отличие от классических тикет-систем: базовая единица здесь — разговор с контактом. Каналы склеиваются по email, телефону или внешнему ID. Для веб-виджета это закрывает identity validation: залогиненный пользователь приходит в Chatwoot с HMAC-подписью, и его чат, почта и WhatsApp с тем же номером автоматически попадают в одну карточку. Где общего ключа нет (Instagram отдаёт только внутренний ID профиля), карточки объединяются вручную через merge.

📊 Архитектура и железо для команды 5–10 операторов:
• Rails-приложение + Sidekiq-воркеры + PostgreSQL + Redis + reverse-proxy (Caddy или Nginx)
• минимум 2 vCPU и 4 ГБ RAM на проде
• SSD под PostgreSQL — поиск по разговорам упирается в IOPS
• от 20 операторов и активного WhatsApp/Telegram-трафика PostgreSQL выносится на отдельный сервер с репликой и регулярным pg_dump

Развёртывание из официального docker-compose занимает около получаса, если DNS и TLS-сертификат готовы заранее. В .env правятся FRONTEND_URL (полный HTTPS-адрес, иначе в письмах битые ссылки), параметры PostgreSQL и Redis, SMTP и S3-совместимое хранилище для вложений. Reverse-proxy должен отдельно проксировать websocket ActionCable, иначе интерфейс грузится, но новые сообщения появляются только после F5.

⚡ Встроенный AI-агент Captain работает в двух режимах: автономно отвечает на типовые вопросы из help center и FAQ или подсказывает оператору варианты ответа и переводит реплики на язык клиента. Для контура без выхода данных наружу подключается локальная модель по OpenAI-совместимому API. Контрольный тест перед продом — 30–50 реальных вопросов с известными ответами; запуск на клиентов оправдан, когда «не знаю» уверенно преобладает над «уверенно ошибся».

Chatwoot не подходит для внутренней ITSM-поддержки, контрактов с SLA уровня «P1 — реакция 15 минут» и contact-центра с предиктивным набором. Это платформа живых разговоров, а не учёта инцидентов.

Подключение WhatsApp Business API через 360dialog и Cloud API, связка с Bitrix24 через вебхуки, мониторинг очередей Sidekiq в Zabbix и чек-лист от инженеров IT For Prof — в полном разборе

Frisbee: российский мессенджер держит 300 000 пользователей на одну инсталляцию и обрабатывает 100 000 сообщений в секунду

Компании, которые до 2022 года вели переписку в Telegram и Slack, всё чаще получают запрос от юридического отдела: нужен мессенджер из реестра российского ПО — этого требует 152-ФЗ и приказ по импортозамещению. Frisbee — собственная платформа разработчика KLAUD ATLAS с записью в реестре под номером 7378, публичным сайтом frisbee.chat и клиентами в RuStore и App Store.

По данным Frisbee, продукт получил TAdviser IT Prize 2026 и обслуживает около 1 млн корпоративных пользователей. Одна инсталляция рассчитана более чем на 300 000 пользователей, серверная часть держит 100 000 сообщений в секунду, а видеоконференции — более 1000 участников одновременно, с гостевым доступом по ссылке без регистрации.

✅ Что входит в платформу помимо чата:
• AI-ассистент ведёт протоколы видеовстреч и присылает отчёты прямо в общий чат
• FrisbeeTube — собственный видеохостинг для записей обучений и регламентов
• FrisbeeFlow — таск-менеджер без выгрузки задач в стороннюю систему
• SIP-телефония — звонок сотруднику или добавление в конференцию по номеру телефона

Поставка — по двум моделям: облачный SaaS или on-premise на сервере заказчика. On-premise закрывает требование «данные внутри периметра»: шифрование при хранении и передаче, удалённый выход из аккаунта и очистка данных с устройства при потере или увольнении. Публичного прайс-листа у Frisbee нет — и SaaS-пакеты, и on-premise считают индивидуально, под число пользователей, набор модулей и SIP.

🔧 В IT For Prof мы разбираем такие внедрения на практике: когда Frisbee выгоднее собственного сервера на Matrix, какие три вопроса задать вендору на пресейле и по какому критерию оценивать переход с Telegram, Slack или Teams без потери истории переписки.

Критерии выбора между Frisbee и open-source, чек-лист миграции с Telegram без потери истории переписки и три вопроса вендору на пресейле — как выбрать и внедрить без ошибок

🔒 WireGuard на уровне протокола не знает ни логинов, ни паролей — только пары публичных ключей. При штате 80+ человек это превращает увольнение в квест «найти, какой ключ чей», а туннель уволенного отвечает ещё долго после того, как ему закрыли почту.

Разрыв закрывает wg-portal с LDAP-провайдером: доменная учётка становится единственным источником истины, а VPN синхронизируется следом по расписанию. Заводить и блокировать людей вы продолжаете в оснастке AD, портал перечитывает конфиг WireGuard сам.

Механика отзыва спрятана в LDAP-фильтре (!userAccountControl:1.2.840.113556.1.4.803:=2) — это битовая проверка флага ADS_UF_ACCOUNTDISABLE. Отключили учётку в AD → пользователь перестаёт проходить фильтр → на следующем цикле sync_interval (по умолчанию 15 минут, на чувствительных контурах снижаем до 5) пир уходит в disabled. Для мгновенного отзыва — ручная деактивация в интерфейсе портала, разрывает активные сессии сразу.

Сегментация сети — через interface_filter: группа VPNUsers пускается в wg0 (офисная подсеть), Contractors — в изолированный wg1 (только таск-трекер и один RDP). Пользователь в обеих группах получает два пира, портал их не «схлопывает».

Windows Server 2025 включает LDAP signing по умолчанию — простой bind на 389 без шифрования контроллер отклонит. Нужен STARTTLS на 389 или LDAPS на 636, сертификат CA должен лежать в доверенном store сервера с wg-portal.

⚡ Второй фактор на LDAP не навешивается — только через OIDC-прокладку (Keycloak или Authentik), которая федерирует ту же AD и требует TOTP/WebAuthn поверх пароля. В IT For Prof включаем 2FA точечно на группе wg-critical для доступа к финансовым системам, обычные сотрудники ходят в офисный сегмент по доменному паролю.

Разбор field_map, типовые ошибки bind и чтение логов при no entries returned — в полном разборе

🔧 Cisco приостановила бизнес в РФ ещё в 2022 году: продлить лицензии AnyConnect легально нельзя, обновлений безопасности для ASA/FTD нет, замены железа по гарантии тоже. AnyConnect работает по инерции — пока не кончилась лицензия и не сломался шлюз.

WireGuard закрывает разрыв как открытый протокол без лицензий на пользователя: число пиров ограничено только ресурсами сервера. Для СМБ без ГОСТ-обязательств это прямая замена — доступ к 1С, RDP и файловым по привычному сценарию «запустил клиент — попал в корпоративную сеть».

Ключевой принцип миграции — параллельная работа двух VPN, а не «выключили в пятницу, включили в понедельник». WireGuard поднимается на отдельном сервере, слушает свой UDP (обычно 51820) и не мешает ASA. Пилот — ИТ-отдел на неделю, потом волны по группам доступа: сначала простые политики (одна подсеть), в конце — финансы и дежурная смена. ASA держат ещё две недели в горячем резерве после последнего подключения — за это время всплывают подрядчики раз в квартал и скрипты, ходящие через VPN как транспорт.

Политики переносятся не буквально. Split-tunnel ACL из group-policy превращается в AllowedIPs на пирах, а L4-фильтрация — в nftables на сервере. Десятки индивидуальных политик ASA сводятся к 3–5 интерфейсам wg-portal с маппингом на группы Active Directory: wg-office, wg-finance, wg-devops, wg-contractors.

Постуре-контроль (проверка антивируса, домена, версии ОС) чистый WireGuard не воспроизводит — это архитектурное отличие, а не пробел настройки. Компенсация: OIDC перед wg-portal или MDM.

📊 Честная граница: банкам, госорганам, операторам КИИ и медицине с ЕГИСЗ WireGuard юридически не подходит — там нужен сертифицированный ГОСТ-шлюз (С-Терра, ViPNet, «Континент»). Никакой аудит открытого кода сертификат ФСБ/ФСТЭК не заменит.

Порядок волн, шаблоны peer-конфигов и разбор трёх граблей маршрутизации DNS/split-tunnel — в полном разборе от IT For Prof.