Что было раньше
В первой части мы познакомились с архитектурой RuPost, его связями с внешними сервисами, рассмотрели процесс установки системы и прошли процесс базовой настройки.
О чём часть вторая?
Продолжим знакомство с RuPost версии 2.5.0 в редакции Enterprise. Рассмотрим возможные встроенные конфигурации, в том числе работу с антивирусом Касперского и взаимодействие с Microsoft Exchange, а также посмотрим на инструмент миграции из Microsoft Exchange. Попробуем управлять почтовыми ящиками, группами рассылки и ресурсными ящиками, а также заглянем в командную строку.
Всё это работает, но не без подводных камней. Есть и тонкости в настройке антивирусного/антиспам ПО, и нюансы в миграции, особенно при модифицированной под жизненные потребности службе каталогов. За решением этих вопросов можете обращаться к нам, в Системный Софт.
Встроенные конфигурации
C RuPost версии 2.5.0 поставляются шесть шаблонов конфигурации:
Базовый шаблон конфигурации;
Базовый шаблон конфигурации + Dr.Web;
Базовый шаблон конфигурации + Kaspersky;
Базовый шаблон конфигурации с расширенными параметрами;
Интеграция RuPost с Microsoft Exchange;
Интеграция RuPost с внешним Relay-сервером.
Базовый шаблон мы рассмотрели в первой части, давайте познакомимся с некоторыми другими шаблонами.
Базовый шаблон конфигурации + Kaspersky
RuPost не имеет своей подсистемы защиты от нежелательного ПО и спама, а потому полагается на внешние средства защиты, в качестве которых может выступать, например, Kaspersky Security Mail Gateway или Kaspersky Linux Mail Server. Общение с сервером защиты происходит по Milter протоколу. Установка и настройка сервера Касперского выходит за рамки данной статьи, считаем, что он есть и принимает соединения на порт 10025. Тут должен быть мем с Энакином и Падме, но его украл Бендер.
Откроем консоль администратора RuPost, перейдём раздел «Настройки - Конфигурации» и выберем из библиотеки шаблон «Базовый шаблон конфигурации + Kaspersky»
Проверим пререквизиты, всё должно быть зелёным, мы же уже провели успешную базовую настройку. Жмём «далее» и указываем IP или имя сервера Касперского и порт 10025.
Жмём «далее».
Указываем произвольное и, желательно понятное, имя конфигурации и жмём «Применить конфигурацию». Ознакомившись с предупреждением, применяем конфигурацию ко всем узлам RuPost. Вуаля, у нас появилась защита почты от вирусов и спама.
Интеграция RuPost с Microsoft Exchange
Настало время миграций. С практической точки зрения это, вероятно, один из самых интересных шаблонов. Он позволяет сосуществовать в одном почтовом домене двум почтовым системам – RuPost и Microsoft Exchange. А в то время, пока они мирно сосуществуют, мы можем постепенно стащить почтовые ящики на RuPost и затем вывести Microsoft Exchange из эксплуатации, если необходимо.
К миграции мы ещё вернёмся, а пока рассмотрим сосуществование почтовых систем.
Выберем шаблон «Интеграция RuPost с Microsoft Exchange» и укажем требуемые параметры: IP или имя сервера Microsoft Exchange, его же в качестве Relay сервера и имя почтового домена, в моём примере «doh4.site»
Жмём «далее».
Указываем имя конфигурации и применяем её. Вуаля? Не совсем.
Чтобы заработал этот шаблон нужно провести некоторую подготовку.
Подготовка к интеграции с Microsoft Exchange
Подсвечу основные моменты настройки интеграции RuPost с Microsoft Exchange.
Работа двух почтовых систем в одном почтовом домене производится следующим образом. При отправке письма внутри своего домена сервер проверяет, есть ли у него почтовый объект с указанным именем. Если да, выполняется стандартная локальная доставка. Если локально такого объекта нет, письмо пересылается на сервер-партнёр, обслуживающий этот же почтовый домен. При отправке письма за пределы организации сервер может выполнить это самостоятельно или, как делает RuPost, через relay. Чем может быть чревата такая схема, вы сами догадаетесь, но это вполне рабочее решение.
В Microsoft Exchange необходимо создать Receive Connector с разрешением на получение входящих писем от анонимных отправителей от узлов RuPost. Это позволит принимать почту внутри своего домена для получателей, ящики которых находятся на Microsoft Exchange. Порт именно этого коннектора вместе с IP или именем Microsoft Exchange сервера указываем при разворачивании шаблона RuPost в разделе «receive connector».
Почтовый домен, разделяемый между Microsoft Exchange и RuPost, в Microsoft Exchange указываем как «Internal Relay».
Также на стороне Microsoft Exchange создаём коннектор отправки, использующий RuPost как смарт-хост для отправки в ящики общего почтового домена, находящиеся на RuPost.
Шаблон предполагает наличие почтового релея для отправки почты RuPost-ом пользователям внешних почтовых доменов без аутентификации. Если у вас нет такого релея, можно для этой роли настроить Microsoft Exchange, как это сделать – не мне вам рассказывать.
Миграция с Microsoft Exchange
Из тех российских почтовых систем, с которыми я знаком, RuPost предоставляет самый мощный инструмент миграции данных пользователей из Microsoft Exchange – утилита «RuPost Migration Tool». Этот инструмент позволяет перенести практически все элементы почтового ящика: папки, письма, контакты, события календаря, задачи. Многие элементы переносятся с сохранением прав доступа, и, если что-то в Microsoft Exchange было делегировано коллегам, это будет делегировано в RuPost, если возможно. Есть некоторый шанс, что что-то пойдёт не так, но разработчик постоянно улучшает свои продукты.
Для работы утилиты миграции желательно использовать отдельный сервер с ОС Астра Линукс 1.7.1 или старше. Из обязательных компонентов потребуется установка powershell, .NET Runtime 6.0 и плагина GSS-NTMLSSP, а также PostgreSQL для хранения данных о состоянии миграции. После установки компонентов нужно подготовить СУБД для работы с утилитой миграции:
Создать роль:
CREATE ROLE "rupost_migration" WITH SUPERUSER LOGIN PASSWORD 'Welcome';
И создать создать служебную базу данных утилиты:
CREATE DATABASE "rupost-migration";
После этого можно устанавливать саму утилиту миграции:
apt-get install -y ./rupost-migration-tool_2.2.0_amd64.deb
в процессе установки указать данные для подключения к базе данных, опираясь на то, как и где вы создавали базу для работы с утилитой миграции.
Подготовка RuPost для работы с утилитой миграции
Создать csv-файл с именем служебного почтового ящика, который будет использоваться для миграции, в формате:
EmailAddress
<первичный почтовый адрес учетной записи олицетворения>
Создать почтовый ящик мастер-аккаунта для работы утилиты миграции, от имени которого она будет получать доступ к ящикам пользователей:
rupost mailboxes import -z -d <домен LDAP> <путь до файла csv>
где «домен LDAP» - имя LDAP домена в настройках RuPost
Добавить почтовому ящику мастер-аккаунта права олицетворения в системе RuPost:
rupost impersonation set <первичный почтовый адрес учетной записи олицетворения>
Обязательно переразвернуть почтовую конфигурацию.
Подготовка Microsoft Exchange для работы с утилитой миграции
Создать служебный почтовый ящик, который будет использоваться для миграции. Этот ящик никак не связан с аналогичным на стороне RuPost.
Создать роль администратора, например «RuPost Migration Role» с правами «ApplicationImpersonation» и «Mail Recipients», данную роль назначить созданному служебному почтовому ящику.
Добавить этот же служебный почтовый ящик в группу безопасности «Exchange Trusted Subsystem» AD.
Так как Microsoft Exchange имеет встроенные эффективные средства защиты от перегрузки, необходимо отключить троттлинг на время миграции, иначе вы рискуете не дождаться её окончания. New-ThrottlingPolicy и Set-ThrottlingPolicyAssociation вам в помощь. Обратите внимание, что применить политику ограничения троттлинга достаточно только к служебной учётной записи, так как именно она используется для копирования данных.
Настройка утилиты миграции
После подготовки обеих заинтересованных сторон приступаем к настройке самой утилиты миграции. Основной конфигурационный файл утилиты находится в каталоге /etc/opt/rupost-migration-tool и называется appsettings.json
В конфигурационном файле необходимо задать строку подключения к базе данных, адреса и учётные данные для подключения к серверам Microsoft Exchange и RuPost, а также другие параметры. Внимательно просмотрите его и отредактируйте в соответствии со своими настройками.
Миграция
Миграция производится поэтапно, в соответствии с планом:
Зарегистрировать ящики в утилите;
Запустить миграцию;
Запустить при необходимости повторную миграцию изменившихся с момента первой итерации объектов. Дельта-миграцию можно выполнять произвольное количество раз;
Финализировать миграцию.
Рассмотрим этапы подробнее. Каждый этап выполняется запуском утилиты миграции с определёнными параметрами. Полный список параметров можно посмотреть командой
./MigrationTool.Cli help
Этап номер ноль – проверить работоспособность всех выполненных настроек, как на стороне Microsoft Exchange и Rupost, так и самой утилиты:
./MigrationTool.Cli TestConnection
Все проверки должны завершиться успешно, в худшем случае статусом «WARN». Если получили хотя бы одну ошибку – ищите причину и исправляйте.
Следующим шагом определяем список почтовых ящиков для миграции и ставим их в очередь.
./MigrationTool.Cli ImportMailboxes -f <путь к файлу.csv> -s Queued
Формат списка ящиков в файле:
SourceEmailAddress;TargetEmailAddress
<первичный почтовый адрес №1>;<первичный почтовый адрес №1>
<первичный почтовый адрес №2>;<первичный почтовый адрес №2>
…
Запускаем миграцию:
./MigrationTool.Cli Migrate
Эта команда начнёт процесс копирования данных из исходного почтового ящика в целевой. Повторный запуск с ключом Migrate продолжит миграцию с того шага, на котором она остановилась ранее. Для переноса изменений, произошедших с момента последнего запуска, необходимо запускать команду с ключом –delta.
При выполнении миграции данные в исходном почтовом ящике не удаляются до финализации.
Финализация миграции выполнит следующие действия:
исходный почтовый ящик будет удалён из Microsoft Exchange;
на сервере Microsoft Exchange будут произведены настройки для переадресации входящих сообщений на сервер RuPost;
на сервере RuPost будут выставлены квоты по молчанию для всех мигрировавших ящиков.
Выполняется финализация командой
./MigrationTool.Cli Migrate -f
Просмотр журнала работы
Утилита миграции в процессе работы, помимо вывода в консоль, записывает журнал в файл /var/log/mail.log. Для просмотра событий, относящихся к утилите миграции, можно воспользоваться командой:
cat /var/log/mail.log | grep "RuPost Migration Tool"
При запуске утилиты от имени пользователя root информация о ходе работы также записывается в файл /var/log/rupost-migration-tool/logfile.log
Управление объектами почтовой системы
К объектам почтовой системы относятся почтовые ящики, ресурсные ящики и группы рассылки.
Почтовые ящики
Управление почтовыми ящиками находится в веб-консоли администрирования в разделе «Получатели \ Почтовые ящики». Создание почтовых ящиков мы рассмотрели в первой части, теперь посмотрим, что можно сделать с существующими.
Нажав на имя почтового ящика, мы попадаем в его свойства;
На вкладке «Владелец» видим сводку общей информации. На вкладке «О ящике» можно изменить его статус и переименовать при желании;
На вкладке «Квоты» можно переопределить размер почтового ящика и максимальный размер входящего письма;
На вкладке «Псевдонимы» можно добавить алиас для ящика.
Ресурсные ящики
в разделе «Получатели \ Ресурсы календаря» можно создавать ресурсные почтовые ящики.
Стратегия бронирования определяет, каким образом календарь ресурса принимает приглашения.
Без ограничений — может бронироваться параллельно;
Индивидуальное — в один промежуток времени ресурс может стать участником только одного события;
С ограничениями — выводится предупреждение при попытке забронировать параллельно, событие создаётся.
Группы рассылки
Группы рассылки могут быть статическими и динамическими. Состав первых указывает администратор, состав вторых формируется по некоторому условию, которое тоже указывает администратор, формирование состава группы происходит по этому условию в момент рассылки. Также для групп обоих типов должны быть указаны не только получатели рассылки, но и те, кому разрешено отправлять сообщения в эту рассылку.
Статические группы
Для начала создадим и рассмотрим статическую группу.
Укажем имя группы, адрес и описание.
На следующей вкладке укажем членов группы. Обратите внимание: при указании участника, как отправителя, он автоматически становится получателем.
На третьей вкладке можно прямо указать внешние адреса получателей или подгрузить их из файла.
LDAP фильтры
Динамические группы строятся на основе LDAP фильтров, выборки по которым и формируют состав получателей и отправителей. Перед созданием динамических групп рассылок необходимо определить эти фильтры в разделе «Получатели \ Фильтры LDAP»
Например, этот запрос выбирает всех сотрудников с именем «Иван».
Кнопка «Проверить фильтр» выполняет выборку по указанному фильтру и позволяет проконтролировать его правильность.
Динамические группы
После определения фильтров LDAP можно создавать динамические группы.
Получатели описываются одним фильтром, отправители – другим. Впрочем, можно использовать и один фильтр, если все члены группы должны иметь возможность писать в неё.
Нюанс
После создания групп рассылок требуется переразвернуть текущую конфигурацию.
Мониторинг
Для наблюдения за работой почтовой системы и управления её компонентами используется раздел «Мониторинг» веб консоли администрирования.
Здесь можно получить информацию об экземплярах RuPost, их состоянии и отсюда же можно ими управлять.
Неприметный значок вилки возле имени экземпляра показывает тот узел, к которому в настоящий момент подключена консоль администрирования.
Для каждого экземпляра «RuPost» доступна возможность запустить и перезапустить его, остановить для обслуживания и перезапросить статус с помощью нажатия соответствующих кнопок. Обращу внимание, что при остановке экземпляра компонент haproxy остаётся в работе, что позволяет не терять связь с экземпляром и возможность управления им.
Командный режим
Для режима команд используется команда rupost, доступная на сервере с установленным экземпляром RuPost. У команды есть множество модификаторов и ключей, позволяющих собирать данные о почтовой системе и управлять ею. Как обычно, всё начинается с
rupost –help
Которая выведет справку по использованию командного режима.
Приведу несколько примеров команд для управления и мониторинга.
Создать LDAP фильтр с сотрудниками, имя которых «Василий»:
rupost ldap-filters add --name "Vasilyes" --specification "Все Василии" --domain astra.lan --filter "(&(objectclass=person)(givenname=Василий))"
Создать переговорную комнату с адресом «room@doh4.site» и именем «Переговорная», с индивидуальным бронированием:
rupost resources add -m room@doh4.site -n "Переговорная" -d "Для важных встреч" -t location -s ones
Вывести журнал работы экземпляра RuPost:
rupost logs
Вывести журнал действий администраторов:
rupost audit
Заключение
Простите за несколько формальное изложение второй части, но сама суть материала располагает меня к такому методу подачи. Хотите неформального общения – приходите в Системный Софт.
Мы очень поверхностно ознакомились с почтовой системой RuPost от ГК «Астра» и увидели, что она, хотя и не лишена определённых недостатков, достаточно проста в установке и настройке, гибка в эксплуатации, а также обладает мощным инструментом миграции данных из Microsoft Exchange. Также не могу не отметить достаточно подробную документацию по продукту, доступную на сайте вендора. Хотите протестировать решение лично, вдохновившись статьей? Отправьте нам запрос на пробную версию. Если нет времени и/или желания заниматься тестированием на своих серверах – приходите к нам за персональной демонстрацией.
LerBulka
Отлично!