⚡ Nextcloud Talk: бот, который не врёт и не дублирует

Собрали для клиента бота эскалации инцидентов в Nextcloud Talk. Делимся тем, что в документации не написано.

Архитектура
Talk шлёт POST в формате Activity Streams 2.0 и не ждёт ответа. Отвечаем 200 OK сразу после проверки подписи, обработку — в очередь. Иначе при лавине сообщений упрётесь в воркеры и потеряете события.

Подпись HMAC-SHA256 — не опциональна
Секрет генерируем через openssl rand -hex 32 и кладём в Vault. Был случай: разработчик «временно» закомментировал валидацию для отладки, выкатил в прод. Через неделю бот начал писать сообщения, которых Talk не отправлял — старый тестовый скрипт на CI дёргал endpoint напрямую. Расследование заняло день.

Replay-защиту делаем через Redis: храним заголовок RANDOM с коротким TTL, повтор отклоняем.

Дубли и rate limits
Talk не гарантирует at-most-once. Идемпотентность держим через Redis SETNX с TTL около часа по object.id — закрывает 99% дублей в Jira, биллинг, SMS-шлюз.

У клиента при сетевом сбое прилетела лавина: 200 хостов Zabbix одновременно. Бот упёрся в rate limit, часть алертов не дошла. Решили агрегацией на стороне адаптера: «24 хоста в кластере db-replica недоступны» одним сообщением.

Реакции как интерфейс эскалации
Алерт приходит — бот ставит 🚨. Дежурный реагирует 👀 (взято в работу), ✅ (закрыто). Нет реакции за N минут — DM старшему. Транзитные статусы 🟡/🟢 бот ставит сам через /ocs/v2.php/apps/spreed/api/v1/reaction/{token}/{messageId} — лента не засоряется «принято».

Грабли версий
Поле object.name для вложений было пустым до Nextcloud 33 с Talk 23. Поля object.inReplyTo и actor.talkParticipantType появились только в Talk 21 — парсер не должен падать на их отсутствии.

✅ Что вытащили в Talk без внешних мессенджеров: алерты Zabbix, события GitLab CI/CD, пуш-уведомления Bitrix24. Данные не уходят за периметр — для финансов и медицины это требование ИБ, не «приятно иметь».

🔧 Разбор с командами OCC, кодом проверки подписи и адаптерами: в материале IT For Prof

⚡ 7 серверов, 9 гипертаблиц, два канала алертов — мониторинг, который не падает вместе с сетью

Когда между сервером мониторинга и удалёнными хостами стоит нестабильный канал, Telegram-уведомления могут не доходить. Мы решили это дублированием: каждый алерт уходит одновременно в Telegram и Matrix. Если один канал не пробивается — проходит второй.

Инфраструктура клиента: 7 серверов в разных локациях, разрозненный мониторинг с пропусками, без единой политики severity. Задача — собрать всё в одну систему с чёткими приоритетами и гарантированной доставкой алертов.

Развернули Zabbix 7 с TimescaleDB в качестве бэкенда хранилища. TimescaleDB хранит метрики в 9 гипертаблицах — это даёт нормальную скорость выборки даже на глубоких исторических диапазонах без партиционирования вручную. Каждый удалённый хост подключён через отдельный 256-битный TLS-PSK-туннель: скомпрометированный ключ одного хоста не затрагивает остальные шесть.

🔒 Политика severity выстроена по трём уровням:
— Average: grace-период 10 минут — короткие флуктуации не создают шум
— High: 5 минут — требует реакции дежурного
— Disaster: 2 минуты — уведомление уходит немедленно

📊 Параллельные каналы алертов — не резервирование ради резервирования. Прямая доставка уведомлений из РФ к сторонним API работает с перебоями. Matrix в этой схеме закрывает слепое пятно: сообщения идут через собственную инфраструктуру, независимо от внешней связности. На практике это означает, что дежурный получает алерт даже тогда, когда Telegram-канал временно недоступен.

Архитектуру, конфигурацию TLS-PSK и полную схему маршрутизации алертов — разобрали в кейсе на IT For Prof

⚡ С OpenSSH 9.8 демон sshd сам банит перебор паролей — без Fail2Ban, без парсинга логов, без правил firewall

Механизм называется PerSourcePenalties. Он работает внутри процесса sshd: каждое подозрительное событие добавляет источнику штрафное время, в течение которого новые соединения с этого адреса просто не принимаются. Никаких внешних демонов, никакого промежуточного слоя — реакция мгновенная, пока жив sshd.

Штрафуются четыре категории событий: аварийное завершение соединения (crash), неудачная аутентификация (authfail), разрыв до аутентификации (noauth) и превышение grace-времени на вход. Штрафы суммируются по адресу или подсети источника — не по имени пользователя. Перебор логинов с одного хоста упирается в стену быстрее, чем успевает навредить.

🔧 Три директивы управляют механизмом:
— PerSourcePenalties yes — включает учёт и задаёт веса по категориям
— PerSourceNetBlockSize — ширина штрафа на соседние адреса подсети
— PerSourcePenaltyExemptList — доверенные сети вне зоны наказания

Настройки лучше выносить в отдельный файл /etc/ssh/sshd_config.d/60-penalties.conf — он подключается раньше основного конфига и удобно раскатывается через систему управления конфигурациями. После любой правки: sshd -t проверяет синтаксис, sshd -T показывает фактически применённые значения, systemctl reload ssh применяет без разрыва сессий.

Где PerSourcePenalties не заменяет Fail2Ban: механизм закрывает ровно одну поверхность — SSH. Перебор на веб-форме входа, сканер по почтовым портам, брутфорс панели управления — всё это остаётся вне его зоны видимости. На узлах, где наружу смотрят веб и почта, Fail2Ban необходим. Там, где из публичного только SSH — встроенного механизма достаточно.

✅ Доступно с OpenSSH 9.8 (Ubuntu 24.10+; в Ubuntu 24.04 LTS этой версии ещё нет). Главный риск при раскатке на парк серверов — узел мониторинга, который опрашивает SSH по расписанию, сам набирает штраф и блокируется по подсети. Лечение тривиальное: внести управляющие сети, адреса мониторинга и VPN-шлюзы в PerSourcePenaltyExemptList до включения штрафов, а не после первого инцидента.

Чек-лист безопасного внедрения, разбор отличий от Fail2Ban и готовый drop-in конфиг — в пошаговом руководстве IT For Prof

🔒 Двухфакторная аутентификация SSH по TOTP: один код спасает от украденного ключа

Одна опечатка в строке AuthenticationMethods отрезает SSH сразу к десяткам серверов — и восстанавливать доступ приходится через консоль провайдера. Поэтому 2FA для SSH включают по строгой процедуре, а массовое включение одной командой на всём парке заканчивается самоблокировкой.

2FA для SSH закрывает частый сценарий взлома: украденного пароля или одного приватного ключа для входа уже мало — нужен ещё одноразовый код. Проверяет его PAM-модуль pam_google_authenticator, а приложение Google Authenticator на телефоне администратора показывает текущий TOTP. Сервер сверяет код локально, без обращения в интернет.

Как устроена связка:
— Секрет лежит в файле .google_authenticator в домашнем каталоге, режим строго 0600 и владелец = сам пользователь, иначе модуль откажется читать файл
— Команду google-authenticator запускают от имени пользователя, а не от root
— Схема «ключ + TOTP»: AuthenticationMethods publickey,keyboard-interactive — запятая значит «и», SSH потребует оба фактора подряд
— Перед перезапуском демона — обязательно sshd -t для проверки синтаксиса

⚡ Автоматизацию выносят в отдельные service-аккаунты и описывают исключение через Match User ansible,backup с AuthenticationMethods publickey — Ansible и бэкапы входят по ключу без кода. Опция nullok временно разрешает вход без секрета на время выкатки, но её риск реальный: забытый nullok месяцами держит учётки «защищёнными» лишь формально. Снимать его нужно по дате, зафиксированной в задаче.

✅ От самоблокировки спасают три линии: резервные одноразовые коды из менеджера паролей, break-glass через консоль IPMI/KVM в обход sshd, и вторая открытая root-сессия на время правок. Плюс NTP на всём парке — при расхождении часов сервера и телефона TOTP-коды перестают совпадать.

Команды инициализации ключей, настройка forward_pass для схемы «пароль + TOTP» и план массовой раскатки через Ansible — в полном разборе от IT For Prof

🎥 TrueConf Server Free — бесплатный сервер видеоконференций, который ставится в вашем контуре и работает без выхода в интернет. Российский вендор; в реестр отечественного ПО внесён сам сервер (аппаратные терминалы — нет, уточняйте перед закупкой).

Что даёт бесплатная редакция:
• неограниченное число пользователей в адресной книге;
• до 50 одновременно онлайн (до 300 при наличии корпоративной почты);
• 10 PRO-лицензий — столько участников выходят в эфир с камерой одновременно;
• корпоративный мессенджер: чаты, передача файлов, статусы присутствия;
• лицензия бессрочная — без подписок, продлений и лимита минут.

Весь трафик, чаты и файлы остаются внутри сети — это закрывает требования 152-ФЗ и ФСТЭК для работы с персональными данными в закрытом контуре.

Типовая установка — 15–20 минут, интеграция с Active Directory подтягивает учётки. Один сервер обслуживает мобильные приложения, ПК-клиенты, браузер через WebRTC и SIP/H.323-терминалы для переговорных.

Где Free упирается в потолок: нет федерации и кластеризации, ограничена запись в облако и часть API, а SIP/H.323-шлюз держит лишь одно одновременное соединение. Для нескольких переговорных с аппаратными терминалами или штата больше 260 человек нужна платная TrueConf Server.

Установка с нуля и матрица ограничений Free — в полном разборе

В IT For Prof разворачиваем TrueConf под ключ за 1–2 дня.

🔒 NGINX Rift (CVE-2026-42945): 18-летняя дыра в rewrite-модуле бьёт по серверам на 1С-Битрикс

В nginx нашли переполнение кучи с оценкой 9.2 по CVSS — баг прожил в коде 18 лет и срабатывает на типовой схеме ЧПУ, которая стоит почти на каждом сайте под 1С-Битрикс.

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

⚡ Триггер узкий, но повсеместный: директива rewrite идёт следом за rewrite, if или set, использует безымянный захват PCRE ($1, $2) и содержит знак ? в строке замены. Именно так выглядит SEF-маршрутизация Битрикса: десятки правил вида rewrite ^/catalog/(.*)$ /index.php?path=$1 last;. Каждая строка по отдельности легитимна — опасность рождается на стыке, поэтому ручное ревью и классический фаззинг 18 лет проходили мимо. Дыру в итоге нашёл автономный ИИ-агент, перебиравший комбинации директив, а не запросы.

📊 Где проверять и куда обновляться:
— grep по конфигам: grep -REn 'rewrite .*[$][0-9].*[?]' /etc/nginx/ — ловит безымянные $1/$2 с ?, переменные $host, $uri и именованные захваты в паттерн не попадают
— ASLR: cat /proc/sys/kernel/randomize_va_space — значение 2 держит риск на уровне DoS, 0 = максимальный риск RCE
— nginx 1.30.1 (стабильная ветка) и 1.31.0 (mainline)
— NGINX Plus — R36 P4 и R32 P6
— Angie — минимум 1.11.6 (закрывает и связанную CVE-2026-9256)

🔧 Временная мера до обновления — заменить безымянный захват на именованный, уязвимость перестаёт срабатывать: rewrite ^/catalog/(?P<path>.*)$ /index.php?path=$path last;. WAF держите как дополнительный рубеж: триггер сидит в вашем конфиге, а не в одной сигнатурируемой строке запроса, поэтому отфильтровать все варианты на входе не выйдет. Обновление и перезагрузка бинарника проходят без обрыва соединений — отговорка про «простой на патч» здесь не работает.

Полный чек-лист из 5 шагов, разбор следов падения воркера в логах и матрица рисков для ISPmanager, Plesk, Docker и Angie — в полном разборе от IT For Prof.

⚡ Коробочный Битрикс24 на CentOS 7 — прямой миграции не существует

CentOS 7 достиг End of Life летом 2024 года. С этого момента ядро, OpenSSL и системные библиотеки не получают патчей безопасности. Портал может работать — но работающий портал и защищённый портал это разные состояния.

Главная проблема в том, что официальный конвертер AlmaLinux не поддерживает CentOS 7 как источник. Прыгнуть с семёрки напрямую на AlmaLinux 9 одной командой нельзя. Реальных путей два.

🔧 Путь 1 — поэтапный апгрейд через ELevate: CentOS 7 → AlmaLinux 8 → AlmaLinux 9. Инструмент ELevate (на базе Leapp) делает переход между соседними мажорными версиями прямо на сервере. Требования: раздел /boot от 512 МБ (под три версии ядра одновременно) и версия EL8 не ниже 8.4 перед вторым переходом. Для серверов без выхода в интернет — локальное зеркало от 500 ГБ на каждую мажорную версию. Обязателен консольный доступ через KVM или IPMI: во время конвертации по SSH машину не достать.

Путь 2 — чистая установка AlmaLinux 9 на новый сервер с переносом данных из резервной копии. По практике для коробочного Битрикс24 этот путь предпочтительнее: окружение без накопленного за годы мусора, старый сервер остаётся нетронутым как точка отката.

После переноса критично проверить четыре группы настроек: правила адресации в nginx, пул php-fpm (на AlmaLinux 9 сокет живёт в /run/php-fpm/, а не там, где был на семёрке — именно это расхождение даёт «502 Bad Gateway» после переноса), фоновые задачи cron и службу push. Забытый cron — самая частая причина жалоб «перестали приходить уведомления о задачах» через пару дней после миграции.

✅ Старый сервер не сносить сразу — держать живым минимум несколько дней: часть проблем в редко используемых компонентах проявляется только на реальном трафике.

Пошаговые команды для резервного копирования, обоих сценариев миграции и чеклист постпроверки — в полном техническом разборе от IT For Prof

⚡ Битрикс24 тормозит: апгрейд железа лечит симптом, а не причину

Заказчик удвоил RAM на сервере, где таблица b_bp_tracking занимала 9 ГБ. Выигрыш — две недели, потом портал снова встал. В другом проекте месяцами наращивали CPU, а виноват оказался раздутый журнал b_event_log, упиравший InnoDB buffer pool в потолок: после архивации нагрузка вернулась в норму без апгрейда.

📊 По нашей практике тормоза коробки чаще всего — это настройка PHP-FPM, MySQL и дисковой подсистемы, а не нехватка железа. Признаки, по которым видно конкретную причину:

— %iowait стабильно выше 5–10% и await двузначный в мс — диск на пределе, проверять PSI io some avg10 (точнее iowait)
— swap больше 500 МБ и OOM Killer в dmesg — нехватка RAM, апгрейд CPU тут не поможет
— max_children reached в логах PHP-FPM — переполнение очереди воркеров, отсюда 502 Bad Gateway
— LA выше числа ядер и %steal больше 5% на VPS — соседи по гипервизору забирают ресурсы
— hit rate InnoDB buffer pool ниже 99% — данные читаются с диска вместо памяти

🔧 pm.max_children считается по формуле: (Доступная RAM − RAM_MySQL − RAM_Redis − RAM_ОС) / средний RSS воркера. Реальный кейс: pm.max_spare_servers = 35 при RSS 209 МБ съедало 7,3 ГБ только на idle-воркеры. Перевод на pm = static с max_children = 60 уронил потребление с 9,3 до 0,975 ГБ, TTFB — с 5,2 до 0,8 секунды.

Типичные «тяжёлые» таблицы коробки: b_event_log, b_bp_tracking, b_im_message, b_disk_object, b_sale_order. Агенты без cron дёргают пользовательские хиты и съедают тот же воркер, на котором сидит человек — первым делом переводить на crontab. Параллельно лечить все 10 причин нельзя: после серии одновременных изменений невозможно понять, что дало эффект, а что регресс.

✅ Чек-лист экспресс-аудита из 8 шагов, формулы расчёта воркеров, готовые конфиги nginx/PHP-FPM/MySQL и таблица приоритетов по 10 причинам — в полном разборе

⚡ 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 для автосоздания тикетов из алертов — в полном разборе