Проект

Общее

Профиль

Действия

Инструкция по установке и эксплуатации
почтовых серверов Tegu, Tegu Professional, Tegu Enterprise версии 1.15.0

1. Введение, функциональные возможности и выбор редакции Tegu

1.1. Что такое Tegu

Tegu – это линейка полностью отечественных современных почтовых серверов, масштабируемых от начального уровня до уровня кластеров для построения корпоративных и облачных почтовых систем.

Cерверы Tegu позволяют получить единое интегрированное решение для организации почтового сервиса, адресных книг, календарей, мгновенных сообщений, хранения и редактирования документов. Сервер поддерживает все стандартные десктопные и мобильные приложения, однако для работы с ним достаточно только браузера.

Базовая версия разрабатывается и распространяется согласно лицензии FreeWare, остальные редакции поставляются по собственным коммерческим лицензиям.

Tegu в состоянии работать как автономно (standalone), так и в интеграции со множеством контроллеров LDAP/MS Active Directory, а также в виде мультисерверного кластера, что делает решение отказоустойчивым и масштабируемым.

Tegu распростаняется на базе ОС Linux и полностью совместим с отечественными ОС, для каждой из которых поддерживается собственная сборка.

Весь процесс мониторинга и управления сервером осуществляется через веб-панель администрирования и не требует знания Linux.

1.2. Какие почтовые клиенты работают с Tegu

Tegu реализует только открытые (стандартные) почтовые протоколы (IMAP, SMTP, CakDAV, CardDAV, WebDAV) и принципиально не поддерживает проприетарные протоколы (к примеру MAPI).

Таким образом, с Tegu совместимы все почтовые программы, поддерживающие стандартные протоколы на всех операционных системах для десктопов и мобильных устройств. Таковыми могут быть:

  • Mozilla Thunderbird
  • Apple Mail
  • Evolution
  • Spark
  • Mailspring
  • Postbox
  • eM Client
  • Pronto Pro!
  • Почтовый клиент 1С
  • THE BAT!
  • MS Outlook (с плагином outlookcaldavsynchronizer )
    и многие другие...

1.3. Как выбрать ОС, аппаратную платформу и рассчитать аппаратные ресурсы

Tegu поставляется для всех версий Linux и в том числе для отечественных ОС.
Соответствующими сертификатами подтверждена совместимость с:

Tegu поставляется для нескольких аппаратных платформ. В т.ч.:

  • x86_64
  • aarch64

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

1.4. Как выбрать редакцию Tegu

Tegu поставляется в нескольких редакциях, которые значительно отличаются друг от друга как по функциональным возможностям, так и по модели распространения.
Архитектура редакций Tegu сделана таким образом, чтобы исключить ветвление (бранчевание). Другими словами, каждое внесенной изменение автоматически применяется ко всем редакциям сразу.
С функциональной точки зрения каждая следующая редакция включает в себя все возможности предыдущей, при этом добавляет новые возможности.
Для удобства сравнения изучите сравнительную таблицу.

1.4.1. Сравнительная таблица редакций Tegu

Редакция Tegu Tegu Enterprise
Лицензия FreeWare Коммерческая
Регистрация в Росреестре Запись в реестре №9811 от 18.03.2021 Запись в реестре №10820 от 25.06.2021
Подтвержденная совместимость с отечественными ОС ALT Linux, РЕД ОС
Стоимость Для расчета стоимости воспользуйтесь калькулятором на сайте
Электронная почта
Поддержка нескольких интернет-доменов + +
Служба приёма/отправки сообщений SMTP + +
Служба доступа к почтовым ящикам пользователей IMAP/SMTP + +
Система обработки входящих писем в соответствии с правилами + +
Квотирование почтовых ящиков + +
Поиск сообщений + +
Мастер-пользователь + +
Хранение почты в maildir + +
Хранение почты в БД PostgresSQL +
Отказоустойчивый мультисерверный кластер +
Администрирование
Полный графический интерфейс управления + +
Журнал активности сервера Log + +
Защита
Серый список отправителей + +
Чёрные списки адресов серверов + +
Система проверки политики домена для отправителя + +
Возможность интеграции
Антиврус/Спамфильтр Kaspersky + +
Антиврус/Спамфильтр Dr.Web + +
Backup and Restore в реальном времени + +
Средства для миграции imapsync + +
Веб-клиент адресных книг NextCLoud +
Веб-клиент календарей NextCLoud +
Веб-клиент электронной почты RoundeCube +
Веб-клиент электронной почты RainLoop +
Аутентификация через LDAP/MS Active Directory +
Поддержка БД PostgresSQL +
Сопровождение
Сообщества и форум + +
Сопровождение по email и телефону
Премиум-сопровождение 24х7
Услуги интеграции

1.4.2. Описание редакций Tegu

1.4.2.1. Tegu (FreeWare)

Tegu - это полностью отечественный современный почтовый сервер начального уровня, работающий в среде ОС Linux, распространяемый под лицензией FreeWare. Сервер позволяет организовать обмен с любыми почтовыми серверами по протоколу SMTP, а также поддерживает почтовых клиентов по протоколу IMAP/SMTP.
Сервер отличает простота установки и удобство администрирования через веб-интерфейс.

Базовые функции редакции

  • Регистрация в реестре отечественного ПО Минцифры России
  • Подтверждена совместимость с отечественными ОС Альт Линукс и РЕД ОС
  • Поддержка протоколов IMAP/SMTP
  • Система проверки политики домена для отправителя (SPF)
  • Подпись DKIM для исходящих писем
  • Поддержка нескольких интернет-доменов
  • Поддержка локальной БД пользователей в формате JSON в иерархии групп
  • Система обработки входящих писем в соответствии с правилами
  • Хранение почты в maildir
  • Квотирование почтовых ящиков
  • Мастер-пользователи
  • Полный графический интерфейс управления
  • Журнал активности сервера Log
  • Серый список отправителей
  • Чёрные списки адресов серверов
  • Система проверки политики домена для отправителя
  • Возможность интеграции с антивирусными системами Kaspersky и Dr.Web
  • Возможность интеграции с веб-клиентами адресных книг, календарей и электронной почтой NextCLoud, RoundeCube и RainLoop

Функции старших редакций

  • Tegu Enterprise
    • Аутентификация через LDAP/MS Active Directory с неограниченным количество доменных контроллеров различного типа
    • Отказоустойчивый мультисерверный кластер

1.4.2.4. Tegu Enterprise

Tegu Enterprise - это полностью отечественный современный отказоустойчивый мультисерверный почтовый сервер, работающий в среде ОС Linux, распространяемый под собственной лицензией. Сервер позволяет организовать обмен с любыми почтовыми серверами по протоколу SMTP, а также поддерживает почтовых клиентов по протоколу IMAP/SMTP. Сервер отличает простота установки и удобство администрирования через веб-интерфейс.

Отличия данной редакции

  • Аутентификация через LDAP/MS Active Directory с неограниченным количество доменных контроллеров различного типа
  • Отказоустойчивый мультисерверный кластер

Базовые функции

  • Базовые свойства
    • Поддержка любого количества интернет-доменов
    • Распределенное администрирование пользователей
  • Протоколы
    • IMAPs
    • SMTPs
    • CalDav
    • CardDav
    • HTTPs
  • Аутентификация
    • Поддержка локальной БД пользователей (JSON с иерархией групп)
    • Аутентификация LDAP/MS Active Directory (количество и тип серверов каталога неограничено)
  • Хранилище почты
    • Локальной в формате Maildir (ускоренный механизм инжексации)
    • Централизованное в СУБД Postgres
  • Безопасность
    • Система проверки политики домена для отправителя (SPF)
    • Подпись DKIM для исходящих писем
    • Фильтрация GreyListing
    • Черные списки
    • Белые списки
    • Интеграции с антивирусными и антиспамовыми системами Kaspersky и Dr.Web по протоколу Milter
  • Топология
    • Автономный сервер (Standalone)
    • Трехуровневая схема
    • Мультисерверный кластер и симметричным балансированием нагрузки
  • Интерфейс
    • Веб-интерфейс администратора (полный)
    • Веб-интерфейс пользователя (почта, календари, адресные книги, облачное хранение файлов)
    • Поддержка любых стандартных десктопных и мобильных клиентов
  • Обработки
    • Глобальная система обработки входящих писем и событий в соответствии с правилами (настраивается администратором)
    • Система обработки входящих писем в соответствии с правилами на уровне пользователя
    • Квотирование
    • Поддержка мастер-пользователей (количество неограничено)
    • Поддержка алиасов и групп рассылок
  • Резервное копирование
    • Полное
    • Гранулированное
  • Поддерживаемые ОС
    • Linux (glibc 2.28+),
    • ALT Linux,
    • RedOS,
    • AstraLinux
  • Поддерживаемые аппаратные архитектуры
    • x86_64
    • AArch64 (ARM64)

Варианты топологии

1. Однонодовый сервер с хранилищем на локальном диске

2. Кластерное отказоустойчивое масштабируемое решение с хранилищем на базе СУБД

1.5. Как получить дистрибутив

1.6. Лицензионное соглашение

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

2. Инструкция по установке почтового сервера Tegu

Мы написали для вас качественный код, а также написали эту инструкцию чтобы облегчить вам работу.
Пожалуйста прочтите эту документацию перед началом работ с Tegu.

Преамбула

Сервер написан на языке Golang и представляет собой один единственный исполняемый файл, который вы скачиваете для выбранной аппаратной архитектуры. Лицензия не ограничивает вас в выборе или смене аппаратной архитектуры.

Допускается использование Tegu на любом Линукс дистрибутиве, версия библиотеки GLIBC которого не ниже 2.28. В сложившейся ситуации приоритет разумеется отдается использованию отечественных ОС.

  1. Перед началом работ обратите внимание на настройку DNS-зоны. Правильно настроенная зона - это важнейшая половина работы. При этом настроить надо не только MX-запись, но и записи SPF и DKIM. Мы рекомендуем проводить тестирование каждого выполненного этапа работ. На страницах нашего сайта и в интернете вы можете найти массу сервисов и утилит для проверки настройки DNS-зон. Тестирование зон сэкономит ваше время на следующих этапах.
  2. Второе, что необходимо выполнить предварительно, подготовить сертификат будущего сервера, который используется для шифрования протоколов. Использование самоподписанных сертификатов вызовет ошибку.
  3. Установка Tegu представляет собой по сути простое копирование исполняемого файла в заданную вами директорию. Чтобы программа могла выполняться и слушать заданные порты необходимо выполнять команду setcap (setcap необходимо также выполнять при обновлении дистрибутива).
    Этого достаточно чтобы выполнить запуск сервера системой systemd.
  4. При первом запуске сервер сформирует конфигурационный файл tegu.conf, в котором вы найдете сгенерированный административный пароль, с помощью которого сможете войти в веб-интерфейс настройки сервера. Все дальнейшие настройки можно выполнить в удобном GUI-интерфейсе.
  5. Контролируйте работу сервера с помощью команды journalctl -f -u tegu -n 100
  6. Итак, вы выполнили подготовительные этапы и запустили сервер (команда systemctl status tegu.service возвращает вам успешный статус). Самое время перейти к настройке. Ваш сервер может обслуживать любое количество интернет-доменов, но при этом надо соблюдать правило. Для каждого интернет домена необходимо создать хранилище почты (одно для каждого интернет-домена). Количество хранилищ не ограничено, каждое из них может быть двух типов: локальное в формате maildir, централизованное в СУБД Postgress. Источник Postgress роли не играет (ванильная, либо отечественная PosgresPro), версия - не ниже 13.
  7. Создав хранилище, необходимо выполнить создание провайдеров базы данных пользователей. Сервер может использовать любое количество собственных баз пользователей, а также подключения к любому количеству серверов каталогов любого типа (Windows AD, Samba4, FreeIPA etc). Другими словами, пользователи одного интернет-домена могут находиться на разных серверах каталогов, а также в локальной базе данных Tegu.
  8. Финальным этапом является подключение интивирусных/антиспамовых систем, либо DLP-систем, для чего Tegu оборудован протоколом Milter.

Более подробно о каждом этапе читайте в ниже следующей документации.

Вы также можете обратиться в техническую поддержку здесь Обратите внимание, что общаться с техподдержкой могут только зарегистрированные пользователи. Для получения аккаунта заполните форму

2.1. Настройка доменной зоны

Для корректной работы сервера необходимо правильно сконфигурить доменую зону.
Пожалуйста обратите внимание, что правильная настройка включает в себя не только создание записи типа MX, но и настройку SPF, DMARC и DKIM, а также обратной зоны, для чего вам придется обратиться к провайдеру канала интернет, на котором установлен сервер.

Рассмотрим эти записи не примере:

Хост

mail.test.tegu.online.          A     95.163.87.32
test.tegu.online.            MX     10    mail.test.tegu.online.

Sender Policy Framework (SPF)

test.tegu.online.            TXT     v=spf1 mx -all

Технология DomainKeys Identified Mail (DKIM)

Ключ DKIM создаётся в Панели управления почтовым сервером после его установки и запуска сервиса (tegu.service).
Запись для зоны DNS будет отображена после создания ключа.

Технология Domain-based Message Authentication, Reporting and Conformance (DMARC)

_dmarc.test.tegu.online.        TXT     v=DMARC1; p=quarantine; rua=mailto:abuse@test.tegu.online

Сразу же отправляем запрос владельцам внешнего адреса IP для настройки обратной записи DNS:

MAIL FROM: Кальметов Игорь <ikalmetov@mbk-lab.ru>
RCPT TO: <адрес владельца>

Прошу прописать следующую запись PTR в системе DNS:

95.163.87.32 -> mail.test.tegu.online.

Спасибо.

2.2. Установка сервера

Мы компилируем все редакции почтового сервера для двух аппаратных платформ x86_64 и AArch64 (ARM64) под управлением всех типов Linux, включая отечественные операционные системы ALT Linux, RedOS, AstraLinux, Rosa Linux и Calculate Linux.

При выборе дистрибутива критическим является не тип операционной системы, а версия GLIBC, которая в ней установлена. GLIBC — это библиотека GNU C (т.е. реализация стандартной библотеки C от GNU, которая является критичным компонентом инструментария GNU, используемым вместе с binutils и компилятором для сборки бинарных файлов). Очевидно, что разные версии одной и той же ОС имеют разные версии библиотеки GLIBC.

Принимая во внимание специфику сборки и сертификации отчественных ОС Linux, нужно понимать, что их версии GLIBC не всегда являются самыми свежими. Для обеспечения совместимости мы специально используем несколько более старую версию библиотеки при компиляции.

Таким образом, при выборе дистрибутива вам необходимо проверить, чтобы версия библиотеки вашей ОС была новее, чем версия, с которой скомпилирован Tegu.

Вы можете узнать версию вашей GLIBC с помощью команды:

$ldd --version

ldd (Ubuntu GLIBC 2.31-0ubuntu9.7) 2.31

Перед установкой обратите внимание, что все работы необходимо выполнять от имени root.
Для того, чтобы вы это не забыли мы выполним все команды с опцией sudo.

Распаковываем архив:

$ tar -xvf tegu-free-v1.17.20-x86_64.tar.gz 

tegu-free-v1.17.20-x86_64/
tegu-free-v1.17.20-x86_64/sbin/
tegu-free-v1.17.20-x86_64/sbin/tegu

Создаем структуру каталогов для сервера:

$ sudo mkdir /opt/tegu
$ sudo mkdir /opt/tegu/{sbin,data,certs,dkim}

Копируем исполняемый файл в рабочий каталог:

$ sudo cp tegu-free-v1.17.20-x86_64/sbin/tegu /opt/tegu/sbin/

Назначаем пользователя и права:

$ sudo chown -R mail. /opt/tegu/{sbin,data,certs,dkim}
$ sudo chmod 750 /opt/tegu/{data,certs,dkim}
$ sudo chmod -R 550 /opt/tegu/sbin

Проверяем правильность создания каталогов и файлов, а также их прав:

$ sudo ls -lR /opt/

Должно быть примерно так:

$ sudo ls -lR /opt/
/opt/:
итого 4
drwxr-xr-x 6 root root 4096 апр 11 14:32 tegu

/opt/tegu:
итого 16
drwxr-x--- 2 mail mail 4096 апр 11 14:32 certs
drwxr-x--- 2 mail mail 4096 апр 11 14:32 data
drwxr-x--- 2 mail mail 4096 апр 11 14:32 dkim
dr-xr-x--- 2 mail mail 4096 апр 11 14:33 sbin

/opt/tegu/certs:
итого 0

/opt/tegu/data:
итого 0

/opt/tegu/dkim:
итого 0

/opt/tegu/sbin:
итого 17612
-r-xr-x--- 1 mail mail 18032927 апр 11 14:33 tegu

Настраиваем механизм запуска и управления:

$ sudo vi /etc/systemd/system/tegu.service

Содержимое файла /etc/systemd/system/tegu.service должно быть таким:


[Unit]
Description=Tegu. MBK-Lab Mail Server

[Service]
ExecStart=/opt/tegu/sbin/tegu
User=mail
Group=mail
UMask=0007
RestartSec=10
Restart=always

[Install]
WantedBy=multi-user.target

Разрешаем запуск сервера от имени непривелегированного пользователя

$ sudo setcap CAP_NET_BIND_SERVICE=+eip /opt/tegu/sbin/tegu

Разрешаем автозапуск сервера во время загрузки ОС

$ systemctl enable tegu.service

Эта команда создает символическую ссылку на копию файла сервиса в /etc/systemd/system/tegu.service в точке на диске, где systemd ищет файлы для автозапуска, а также обновляет конфигурацию systemd. Помните, что вы должны обновлять конфигурацию systemd всякий раз, когда меняете конфигурацию в файле /etc/systemd/system/tegu.service. Обновление выполняется командой sudo systemctl reload tegu.service

Запускаем сервер (вручную)

$ systemctl start tegu.service

Контролируем запуск сервиса (статус сервиса):

$ systemctl status tegu.service

Правильно работающий сервер возвращает примерно такое:

● tegu.service - Tegu. MBK-Lab Mail Server
     Loaded: loaded (/etc/systemd/system/tegu.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2022-04-11 13:58:09 MSK; 50min ago
   Main PID: 88519 (tegu)
      Tasks: 9 (limit: 9357)
     Memory: 3.3M
     CGroup: /system.slice/tegu.service
             └─88519 /opt/tegu/sbin/tegu

апр 11 13:58:09 systemd[1]: Started Tegu. MBK-Lab Mail Server.

Контролируем с помощью лога:

journalctl -f -u tegu -n 100

Если вы захотите остановить сервер используйте команду:

$ systemctl stop tegu.service

Во время первого запуска сервер будет искать свой файл конфигурации в следующем порядке:

  • /var/spool/mail/tegu.conf
  • ~/tegu.conf

Если файл не был найден, то он будет создан по пути ~/tegu.conf со следующим содержанием:

$ sudo cat /var/spool/mail/tegu.conf 

[global]
dataDir = /opt/tegu/data

[Log]
debug = false

[WEB]
adminPassword = admin

Для подробного логирования работы сервера измените значение параметра

debug = true

Значение параметра adminPassword используйте для регистрации в административном веб-интерфейсе (с логином admin). Читайте об этом подробнее в разделе "Настройка"

2.3. Настройка параметров сервера

Если все предыдущие шаги выполнены правильно, то вам становится доступной веб-панель администрирования сервером, в которой производятся все остальные настройки.

С помощью браузера зайдите на порт 8888 сервера (например, http://127.0.0.1:8888) и авторизуйтесь под администратором (логин admin) с паролем, указанным в конфиге в параметре adminPassword.

При первом запуске административного интерфейса вам будет предложено выбрать место хранения конфигурации:

  • Вы можете выбрать SQLite setings database для версии FreeWare или Professional (локальная база);
  • Либо PosgresSQL для версии Enterprise.

или

Сохраните введенные данные и сохраните параметры.

Сервер создаст файл конфигурации по указанному вами пути. Отредактируйте эти настройки или нажмите Назад для выхода в корневое меню.

Вы вошли в корневое меню управления сервером.

Взаимосвязь объектов сервера и последовательность настройки вам поможет понять следующая условная диаграмма.

2.3.1. Создание почтового хранилища Maildir

Приступаем к созданию хранилищ почты. Для этого выбираем пункт меню Хранилища почты

На данном этапе необходимо выбрать тип хранилища

или

Выбрав "Maildir storage" вы можете создать локальное хранилище.

Обратите внимание, что при создании хранилища maildir соответствующий каталог должен быть предварительно создан с правами RW для пользователя mail.
Выполним это с помощью команд:

$ sudo mkdir /var/mail/test2
$ sudo chmod 750 /var/mail/test2/

Для создания хранилища укажите:

  • Local mail domain name - интернет-домен, для которого создается хранилище
  • Root directory path of mail - каталог для хранения почты выбранного домена.

Завершив настройку, нажмите кнопку Добавить

Хранилище будет создано и вы попадете в диалог добавления нового хранилища.

2.3.2. Создание почтового хранилища СУБД

Как было сказано выше, если вы используете редакцию Tegu Enterprise, то вы можете создать хранилище почты в СУБД. С Tegu совместима любая версия от отечественного вендора PosgresPro , либо свободная версия от PostgeSQL .
Для создания хранилища в корневом меню выбираем Хранилища почты

Очевидно, что целесообразно разместить почтовый сервер Tegu и СУБД на различных вычислительных нодах (виртуальных или физических).
Установка сервера БД производится согласно официальной документации Postgre . По окончание установки вам необходимо создать пользователя с правами создания баз, которым будет пользоваться сервер Tegu, а также необходимо создать две базы
  1. для хранения почты
  2. для хранения конфигурации.

Оптимизация БД, а также сборка отказоустойчивого решения БД, выходит за рамки установки почтового сервера и рассматривается в каждом конкретном случае по запросу. Интерес также представляет создание отказоустойчивой конфигурации базы данных, рассмотренное в данной статье .

2.3.3. Создание/подключение баз данных пользователей

Итак, для понимания структуры давайте еще раз взглянем на картинку архитектуры объектов сервера

Как видно, каждый интернет-домен обслуживается одним хранилищем почты (которое может быть любого из двух типов: maildir или СУБД). Количество интернет-доменов не ограничено.

При этом каждый интернет-домен может обслуживать пользователей из различных баз данных. Базы данных могут быть локальными, либо LDAP3 (куда входит в т.ч. и Windows Active Directory).
Можно предположить, что найдутся более одной базы, которые будут содержать данные одного и того же пользователя. Эту коллизию, необходимо разрешить организационными мероприятиями, но сервер разрешит ее следующим образом: обслужен будет пользователь, описанный в конфигурации первым, все остальные будут проигнорированы.

Для создания базы пользователей в корневом меню выберем пункт Провайдеры БД пользователей
Добавим базу данных кнопкой Добавить провайдер БД пользователей

В данном диалоге мы можем выбрать локальную базу пользователей пунктом JSON File User DB, либо подключиться к одному из серверов каталогов LDAP User DB

или

Далее заполняем либо имя и каталог размещения локальной базы данных, которая будет создана в формате JSON

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

Второй вариант базы пользователей - подключение к LDAP-серверу каталогов.

Обратите внимание! Почтовый сервер Tegu не синхронизирует данные ваших серверов каталогов. Это сделано специально для того, чтобы ни в каком случае не иметь возможности скомпрометировать учетные данные ваших пользователей. В момент, когда необходимо выполнить аутентификацию, сервер выполняет запрос к серверу каталогов в отношение одного пользователя, а выполнив аутентификацию очищает эти данные в памяти. По этой причине, осуществив подключение Tegu к LDAP-серверу, не ждите от него активности, ее не будет. Сервер обратится к LDAP только в момент аутентификации.

2.3.4. Загрузка лицензии

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

Прочтите лицензионное соглашение

И нажмите кнопку Принять. Если вы не принимаете соглашение, загрузка лицензии невозможно и работа сервера будет остановлена.
В любой момент вы также можете прочесть Лицензионное соглашение к конечным пользователем на сайте компании.

Выберите опцию Загрузить файл лицензии

Выберите файл лицензии и нажмите Загрузить файл

Загрузка лицензии завершена.

2.4. Обновление почтового сервера

Скачиваем новый дистрибутив Tegu и распаковываем его

tar xvzf tegu-enterprise-1.13.0-altlinux-x86_64.tar.gz

Останавливаем на всех нодах почтовый сервис

systemctl stop tegu.service

Заменяем новым дистрибутивом содержимое sbin

cp tegu /opt/tegu/sbin/

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

setcap CAP_NET_BIND_SERVICE=+eip /opt/tegu/sbin/tegu

/opt/tegu/sbin/tegu – путь до исполняемого файла.

Запускаем почтовый сервер

systemctl start tegu.service

Проверяем статус запущенной службы.

systemctl status tegu.service
● tegu.service - Tegu. MBK-Lab Mail Server
   Loaded: loaded (/etc/systemd/system/tegu.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2021-07-08 14:13:28 +07; 20s ago
 Main PID: 16047 (tegu)
    Tasks: 8 (limit: 2362)
   Memory: 23.7M
   CGroup: /system.slice/tegu.service
           └─16047 /opt/tegu/sbin/tegu

Обновление завершено

2.5. Более точные настройки сервера

Более точные настройки сервера смотрите в п. 6. Инструкция по эксплуатации

2.6. Проверка настроек сервера

Проверить все выполненные настройки сервера можно с помощью утилиты teguctl (идуще в комплекте дистрибутива)

Команда

# /opt/tegu/bin/teguctl dump

выведет всю конфигурацию сервера в тестовом формате.

3. Инструкция по установке Web клиента Nextcloud.

3.1. Преамбула.

NextCloud - набор инструментов с открытым исходным кодом для создания облачного хранилища.
Это веб-приложение и для своей работы требует настроенного веб-сервера.

3.2. Возможности NextCloud

Файлы NextCloud хранятся на сервере и могут быть доступны через WebDAV, если это необходимо. Пользовательские файлы зашифровываются во время транзита (необходимо включить шифрование)
Может быть интегрирован с пакетом онлайн-офиса OnlyOffice, что даст возможность создавать и редактировать файлы doc, ppt, xls прямо из NextCloud.
Приложения-клиент для синхронизации доступны для систем Linux, macOS, Windows, iOS и Android.
Пользователи Nextcloud могут управлять календарями (CalDAV), контактами (CardDAV), планировать задачи изнутри платформы.
Nextcloud позволяет управлять пользователями и группами с помощью OpenID или LDAP.
Пользователи Nextcloud могут делиться файлами через веб-ссылки.

В данной инструкции мы рассмотрим процесс настройки сервиса в связке в Apache и Apache Reverce Proxy
на базе дистрибутива OS Debian 11 и PHP 7.4, хотя дистрибутив поддерживается любой.

Предполагается, что у вас уже установлен и настроен Apache Reverce Proxy (Обратный Прокси).

Обратный прокси-сервер – это тип прокси-сервера, который ретранслирует HTTP/HTPPS-запросы на один или несколько бэкенд-серверов.
(к которым пользователи не должны иметь доступ напрямую).

В конце инструкции мы опубликуем два рабочих конфига для обратного прокси и инструкцию по генерации валидных SSL сертификатов.

Также предполагается что у вас настроена и сконфигурирована доменная зона для Nextcloud.

Рассмотрим эту запись не примере:

Хост

cloud.tegu.online          A     95.163.87.33

3.2. Подготовительные работы.

3.2.1. Настройка и установка системной локали по умолчанию.

dpkg-reconfigure locales
выбираем
ru_RU.UTF-8

3.2.2. Установка, настройка и изменение часового пояса

timedatectl set-timezone Europe/Moscow

3.3. Установка базы данных Postres.

Здесь мы рассматриваем установку обычной версии Postres, допускается установка версии Pro.

sudo apt install postgresql postgresql-contrib

После завершения установки вы можете убедиться, что служба PostgreSQL активна. Для чего в командной строке наберите:

sudo systemctl is-active postgresql

Также, посмотрите, включена ли служба:

sudo systemctl is-enabled postgresql

Проверка запуска PostgreSQL - как установить PostgreSQL и pgAdmin4 в Ubuntu 20.04

И наконец, вы можете увидеть статус службы PostgreSQL:

sudo systemctl status postgresql

Проверка статуса PostgreSQL

После чего, убедитесь, что PostgreSQL-сервер готов принимать подключения от клиентов:

sudo pg_isready

Проверка готовности PostgreSQL - как установить PostgreSQL и pgAdmin4 в Ubuntu 20.04

3.3.1. Конфигурируем компоненты Postgres

Конфигурируем PostgreSQL

Подключаемся к PostgreSQL

sudo -u postgres psql

или такой командой.

su - postgres -s /bin/bash
psql

Создаем пользователя и базу для NextCloud


CREATE USER nextcloud WITH PASSWORD 'your_password';
CREATE DATABASE nextcloud TEMPLATE template0 ENCODING 'UNICODE';
ALTER DATABASE nextcloud OWNER TO nextcloud;
GRANT ALL PRIVILEGES ON DATABASE nextcloud TO nextcloud;
\q

Смотрим вывод в консоли после исполнения вышеперечисленных команд.

postgres=# CREATE USER nextcloud WITH PASSWORD 'Qwe123Poi';
CREATE ROLE
postgres=# CREATE DATABASE nextcloud TEMPLATE template0 ENCODING 'UNICODE';
CREATE DATABASE
postgres=# ALTER DATABASE nextcloud OWNER TO nextcloud;
ALTER DATABASE
postgres=# GRANT ALL PRIVILEGES ON DATABASE nextcloud TO nextcloud;
GRANT
postgres=# 

3.4. Установка модулей PHP + Apache

apt install -y php-imagick php7.4-common php7.4-mysql php7.4-fpm php7.4-gd php7.4-json php7.4-curl  php7.4-zip php7.4-xml php7.4-mbstring php7.4-bz2 php7.4-intl php7.4-bcmath php7.4-gmp libapache2-mod-php php7.4-pgsql php7.4-ldap apache2

Настраиваем php.ini:

nano /etc/php/7.4/apache2/php.ini
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1

Посмотреть версию PHP можно командой:

php -v

Для применения изменений в настройках PHP необходимо перезапустить Apache.

systemctl reload apache2

3.5. Установка Nextcloud.

3.5.1. Скачиваем NextCloud:

wget https://cloud.mbk-lab.ru/index.php/s/xaBr56D7c88yGkp/download/nextcloud-24.0.4.tar.bz2
tar xjvf nextcloud-24.0.4.tar.bz2
cp -R nextcloud /var/www/

3.5.2. Меняем владельца каталога:

chown -R www-data:www-data /var/www/nextcloud/

3.6. Настройка Apache.

3.6.1. Разрешаем модули ssl, rewrite и headers:

a2enmod ssl
a2enmod rewrite
a2enmod headers

3.6.2. Создаем виртуальный домен и настраиваем его для работы с облачным сервисом:

nano /etc/apache2/sites-available/nextcloud.conf
<VirtualHost *:80>
    ServerName localhost
    ServerAdmin root@localhost
    DocumentRoot "/var/www/nextcloud" 

    Redirect 301 /.well-known/carddav https://cloud.tegu.online/remote.php/dav
        Redirect 301 /.well-known/caldav  https://cloud.tegu.online/remote.php/dav
        Redirect 301 /.well-known/webdav  https://cloud.tegu.online/remote.php/dav

    <Directory "/var/www/nextcloud">
        Options FollowSymLinks MultiViews
            AllowOverride All
            Require all granted

        <IfModule mod_dav.c>
            Dav off
        </IfModule>

        SetEnv HOME /var/www/nextcloud
        SetEnv HTTP_HOME /var/www/nextcloud

    </Directory>

    <IfModule mpm_peruser_module>
        ServerEnvironment apache apache
    </IfModule>

    ErrorLog /var/log/apache2/error_log
    TransferLog /var/log/apache2/access_log
</VirtualHost>

* где cloud.tegu.online — домен, на котором будет работать сервис;
  /var/www/nextcloud — каталог с порталом.

3.6.3. Запускаем Apache.

Включаем нашу конфигурацию.

a2ensite nextcloud.conf

Выключаем дефолтные конфиги Apache.

a2dissite 000-default.conf
a2dissite default-ssl.conf

Проверяем конфигурацию Apache:

apachectl configtest

... если видим:

Syntax OK

Разрешаем автозапуск апача и перезапускаем сервис:

systemctl enable apache2
systemctl restart apache2

3.7. Продолжаем установку в Web интерфейсе

Перед установкой рекомендуется сделать резервную копию.
И внимательно заполнить конфиг, если по ошибке введете неправильно данные сервера базы и данных и пароль, необходимо будет вручную исправить это в конфигах PHP

/var/www/nextcloud/config/config.php

После завершения установки необходимо отказаться от установки рекомендованных приложений.

Нажимаем отмена.

3.7.1. Настройка фоновых заданий через Cron.

Открываем crontab файл из под пользователя "www-data".

crontab -u www-data -e

Необходимо выбрать вариант 1 (Редактор Nano), тем кто привык к редактору Vim, значит выбирают второй вариант.

Select an editor.  To change later, run 'select-editor'.
  1. /bin/nano        <---- easiest
  2. /usr/bin/vim.tiny

Choose 1-2 [1]: 1

Далее необходимо добавить задание в Crontab на исполнение каждые 5 минут и сохранить файл.
*/5 * * * * php -f /var/www/nextcloud/cron.php

3.7.2. Продолжим настройку в Web интерфейсе.

Необходимо навести мышкой в правом верхнем углу на профиль пользователя, выбрать настройки и в левой стороне экрана " основные параметры"
и сменить настройку Ajax на рекомендованный Cron.

3.7.3. Необходимо установить модуль php-imagick и SVG.

apt install imagemagick

3.8. Дополнительные настройки.

Необходимо зайти в общие сведения и проверить и исправить предупреждения связанные с безопасностью:

3.8.1. Исправляем предупреждение о php.

Разрешённое максимальное значение использования памяти PHP не ниже рекомендуемого значения в 512 МБ.

nano /etc/php/7.4/fpm/php.ini

Ищем memory_limit и вводим, 512M вместо 128M.

приводим пример: часть конфига.

; Maximum amount of memory a script may consume
; http://php.net/memory-limit
memory_limit = 512M

Перезапускаем Apache.

systemctl reload apache2

3.8.2. Не указан регион размещения этого сервера Nextcloud.

Что требуется для возможности проверки номеров телефонов без указания кода страны.
Чтобы разрешить пользователям сервера указывать номера телефонов без указания кода страны,
добавьте параметр «default_phone_region» с соответствующим кодом страны в соответствии с ISO 3166-1↗.

Для устранения данного предупреждения откроем конфигурационный файл NextCloud:

nano /var/www/nextcloud/config/config.php

и добавим следующие строки:

'default_phone_region' => 'RU',

3.8.3. Проблема: Не настроена система кеширования.

Для увеличения производительности сервера, по возможности, настройте memcache.

Для решения проблемы устанавливаем Redis.

apt install -y redis-server php-redis
systemctl start redis-server
systemctl enable redis-server
phpenmod redis

Добавляем в конец конфига следующие значения:

sudo nano /var/www/nextcloud/config/config.php
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.local' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => array(
     'host' => 'localhost',
     'port' => 6379,
     ),

Должно получится так.

  'installed' => true,
  'default_phone_region' => 'RU',
  'memcache.distributed' => '\OC\Memcache\Redis',
  'memcache.local' => '\OC\Memcache\Redis',
  'memcache.locking' => '\OC\Memcache\Redis',
  'redis' => array(
     'host' => 'localhost',
     'port' => 6379,
     ),
);

Перезапускаем Apache и PHP-FPM:

systemctl restart apache2 php7.4-fpm

3.8.4. Настройка почтового сервера

Переходим в основные параметры и прописываем настройки учетной записи и почтового сервера.

На предупреждение об отправке тестового письма переходим по рекомендуемой ссылке

http://cloud.tegu.online/index.php/settings/user

Заполняем реквизиты:

3.8.5. Заголовки обратного прокси

Заголовки обратного прокси настроены неправильно, либо подключение к серверу Nextcloud осуществляется через доверенный прокси. Если Nextcloud открыт не через доверенный прокси, то это проблема безопасности, которая может позволить атакующему подделать IP-адрес, определяемый сервером Nextcloud. Дополнительная информация представлена в документации ↗.

Добавляем в конфиг IP обратного прокси сразу после конфига обратного прокси.

nano /var/www/nextcloud/config/config.php
 'trusted_proxies' => 
  array (
    0 => '10.199.199.11',
  ),

Должно получиться так:

  'trusted_domains' => 
  array (
    0 => 'cloud.tegu.online',
    1 => '10.44.44.32',
  ),
 'trusted_proxies' => 
  array (
    0 => '10.199.199.11',
  ),

Перезапускаем Apache и PHP.

systemctl restart apache2 php7.4-fpm

3.8.6. Небезопасные ссылки

Сервер создаёт небезопасные ссылки, несмотря на то, что к нему осуществлено безопасное подключение. Скорее всего, причиной являются неверно настроенные параметры обратного прокси и значения переменных перезаписи исходного адреса. Рекомендации по верной настройке приведены в документации ↗.

Редактируем следующий конфиг:

nano /var/www/nextcloud/config/config.php

Добавляем параметр

'overwriteprotocol' => 'https'

перед настройкой mail

Должно получится так:

'overwriteprotocol' => 'https',
  'mail_smtpmode' => 'smtp',
  'mail_smtpsecure' => 'ssl',
  'mail_sendmailmode' => 'smtp',

Перезапускаем Apache и PHP.

systemctl restart apache2 php7.4-fpm

Проверяем остались ли еще какие то предупреждения или нет.

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

3.9. Публикация конфигурации для Apache Reverse Proxy

Идем по пути:

cd /etc/apache2/sites-available

Создаем конфиг. Этап первый.

nano nextcloud.conf

Вставляем конфиг со своими параметрами.

<VirtualHost *:80>
    ServerName cloud.tegu.online

    ErrorLog /var/log/apache2/cloud-tegu-error.log
    TransferLog /var/log/apache2/cloud-tegu-access.log
RewriteEngine on
RewriteCond %{SERVER_NAME} =cloud.tegu.online
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

Включаем конфиг.

a2ensite nextcloud.conf

Получаем сертификат Certbort. На вопрос перенаправлять на SSL, отвечаем да (2)

(здесь указываете свои параметры домена)

certbot --apache -d cloud.tegu.online

Редактируем конфиг для работы с SSL.

nano nexcloud-le-ssl.conf

Должно получится так:

<IfModule mod_ssl.c>
<VirtualHost *:443>
        <IfModule mod_proxy.c>
            ProxyPass /.well-known/acme-challenge !
    </IfModule>

    <IfModule mod_headers.c>
        Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload" 
    </IfModule>
RewriteEngine On
RewriteRule ^/\.well-known/carddav https://%{SERVER_NAME}/remote.php/dav/ [R=301,L]
RewriteRule ^/\.well-known/caldav https://%{SERVER_NAME}/remote.php/dav/ [R=301,L]

    ServerName cloud.tegu.online
    RequestHeader set X-Forwarded-Proto "https"    
    ProxyRequests       Off
    ProxyPreserveHost On
    ProxyPass / http://10.44.44.32/
    ProxyPassReverse    / http://10.44.44.32/
    RemoteIPHeader X-Real-IP
    RemoteIPInternalProxy 10.44.44.0/24

    ErrorLog /var/log/apache2/cloud-tegu-error.log
    TransferLog /var/log/apache2/cloud-tegu-access.log

SSLCertificateFile /etc/letsencrypt/live/cloud.tegu.online/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/cloud.tegu.online/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

3.10. Полезные команды при настройке и отладке Nextcloud.

3.10.1. Отключение сброса пароля

Нужно добавить в файл nano /var/www/nextcloud/config/config.php

'lost_password_link' => 'disabled',

3.10.2. Вывести из бана ip адрес.

sudo -u www-data php /var/www/nextcloud/occ security:bruteforce:reset 10.252.128.1

3.10.3. Отключение "Создайте свою бесплатную учётную запись"

Отключение ссылки на https://nextcloud.com/signup/

Нужно добавить в файл nano /var/www/nextcloud/config/config.php

'simpleSignUpLink.shown' => false,

3.10.4. Работа с пользователями из UNIX-Shell

В состав nextcloud входит php-скрипт occ, с помощью которого можно управлять сервисом из командной строки Linux.

Добавление пользователя.

Создать нового пользователя можно командой:

sudo -u www-data php /var/www/nextcloud/occ user:add admin
  • где admin — имя учетной записи.

Сброс пароля.

При необходимости сбросить пароль пользователя, можно воспользоваться командой:

sudo -u www-data php /var/www/nextcloud/occ user:resetpassword admin
  • где admin — учетная запись пользователя, чей пароль хотим сбросить.

3.11. Интеграция с LDAP / AD.

Для настройки интеграции с LDAP необходимо включить данный компонент:

Идем в профиль пользователя -> приложения.

Опускаемся в самый низ списка приложений, находим LDAP и включаем его.

Переходим обратно в профиль -> Настройки.

Слева в низу экрана появится настройка: LDAP/AD интеграция.

Проваливаемся внутрь и заполняем своими данными настройки.

3.11.1. Настройка пользователей

Переходим на вкладку “пользователи” и вписываем запрос LDAP

(&(objectclass=user)(mail=*))

3.11.2. На вкладке “Учетные данные” вписать следующий запрос LDAP

(mail=%uid)

3.11.3. На вкладке “Группы” вписываем запрос:

(objectclass=group)

3.12 Настройка интеграции Nextcloud с LDAP из командной строки.

Нам необходимо убедиться в наличие модуля php-ldap.
Иначе в процессе настройки мы можем получить ошибку:

the library ldap is not available

3.12.1 Проверка наличия модуля можно выполнить команду на сервере:

php -m | grep ldap

3.12.2 Должны получить следующий вывод:

ldap

Если мы получим в ответ пустую строку, то необходимо установить пакет php-ldap
и перезапустить службу, обрабатывающую скрипты php.

Выполняем поочередно следующие команды:

apt-get install php-ldap
systemctl restart php7.4-fpm
systemctl restart apache2
  • в данном примере мы перезапускаем и php7.4-fpm, и apache2.
    В вашей системе может использоваться только один сервис.
    Имя для сервиса php7.4-fpm может быть другим — это зависит от версии PHP.

У нас должна быть учетная запись на сервере LDAP с правами чтения (DN user).
От данной учетной записи будет выполняться подключение к серверу каталогов.

Из командной строки мы можем управлять Nextcloud с помощью утилиты occ, которая находится в каталоге самого портала.

Для включения приложения интеграции LDAP вводим следующую команду:

sudo -u www-data php /var/www/nextcloud/occ app:enable user_ldap

3.12.3 Настройка интеграции.

Cоздаем конфигурацию:

sudo -u www-data php /var/www/nextcloud/occ ldap:create-empty-config

Должны получить следующий вывод:

Created new configuration with configID s01
  • в данном примере создана конфигурация с идентификатором s01 — последующие команды будут вводиться с данным ID.

Посмотреть информацию о созданной конфигурации можно командой:

sudo -u www-data php /var/www/nextcloud/occ ldap:show-config

3.12.4 Задаем настройки LDAP.

  • в данном примере вы указываете свои настройки своего домена.

Указываем ldap-сервер для подключения и порт:

sudo -u www-data php /var/www/nextcloud/occ ldap:set-config s01 ldapHost "ds.tegu.online" 
sudo -u www-data php /var/www/nextcloud/occ ldap:set-config s01 ldapPort "636" 
  • в данном примере мы используем сервер ds.tegu.online и порт 636 (зашифрованные запросы к ldap).
    Для использования не зашифрованных запросов, соответственно используем порт 389

3.12.5 Задаем пользователя, от которого будем выполнять подключения к каталогу:

sudo -u www-data php /var/www/nextcloud/occ ldap:set-config s01 ldapAgentName "tegu" 
sudo -u www-data php /var/www/nextcloud/occ ldap:set-config s01 ldapAgentPassword "Qwerty123_tegu"; history -d $((HISTCMD-1))
  • мы указали, что подключение будет выполняться от пользователя tegu с паролем Qwerty123_tegu.
    Дополнительная команда history -d $((HISTCMD-1)) удалить из истории строку с паролем.

3.12.6 Задаем область поиска учетных записей:

sudo -u www-data php /var/www/nextcloud/occ ldap:set-config s01 ldapBase "ou=mail,dc=tegu,dc=online" 

3.12.7 Задаем фильтры пользователя, поля для логина и класса объекта:

sudo -u www-data php /var/www/nextcloud/occ ldap:set-config s01 ldapLoginFilter "(&(objectclass=user)(mail=*))" 

sudo -u www-data php /var/www/nextcloud/occ ldap:set-config s01 ldapUserFilter "(|(objectclass=user))" 

sudo -u www-data php /var/www/nextcloud/occ ldap:set-config s01 ldapUserFilterObjectclass "user" 

3.12.8 Указываем поле для атрибута электронной почты:

sudo -u www-data php /var/www/nextcloud/occ ldap:set-config s01 ldapEmailAttribute "mail" 

3.12.9 Проверяем конфигурацию:

sudo -u www-data php /var/www/nextcloud/occ ldap:test-config s01

Мы должны увидеть:

The configuration is valid and the connection could be established!

Если же мы увидим ошибку, смотрим лог и устраняем проблемы:

tail /var/www/nextcloud/data/nextcloud.log

3.12.10 Активируем конфигурацию:

sudo -u www-data php /var/www/nextcloud/occ ldap:set-config s01 ldapConfigurationActive "1" 

Пользователи будут загружаться из каталога ldap,
но их идентификаторы будут отображаться в виде UID — это произвольные набор цифр и букв и его использовать не удобно.
Чтобы изменить атрибут для имени nextcloud, вводим:

sudo -u www-data php /var/www/nextcloud/occ ldap:set-config s01 ldapExpertUsernameAttr "sAMAccountName" 

3.13. Установка и настройка Rainloop

RainLoop(rainloop.net) — легкий, современный и красивый веб-клиент электронной почты, разработанный специально с учетом малого потребления памяти и использования на low-end серверах.
Использование ресурсов не зависит от объема почтового ящика, сообщения или вложения, а поэтому каждый активный пользователь требует не много памяти, даже в случае обработки больших сообщений.
Такой эффект достигнут за счет того что веб-клиент не использует базу данных, а обращается на прямую к файлам почтового сервера и просто отображает имеющиеся там письма, загружая по мере необходимости.

Встроенная система кэширования позволяет повысить общую производительность и снижая нагрузку на веб-и почтовых серверов. Хотя в зависимостях СУБД (MySQL, PostgreSQL, SQLite и т.п.) указана,
но она задействуется исключительно для хранения данных контактов). RainLoop это именно веб-клиент, в его задачи не входит настройка почтовых серверов и управление учетными записями.
Поэтому какую либо базу учетных записей RainLoop не использует, после настройки подключения к почтовым серверам, пользователь может подключиться указав свой логин и пароль созданные ранее.

В настройках уже есть привязка к Gmail, Yahoo, Outlook.com и qq.com. То есть фактически после установки RainLoop, пользователи могут сразу, без дополнительных настроек, подключаться
к этим серверам используя свои учетные записи. Добавить любой сервер, можно за пару кликов. Чтобы ограничить подключения к почтовым серверам используются белые списки.
Но у такого подхода есть и мину — нельзя объединить несколько ящиков и получать к ним доступ с одного места, для каждлой учетной записи потребуется открыть свое окно.

Поддерживает IMAP и SMTP протоколы, включая защищенные SSL и STARTTLS. Возможно шифрование сообщений при помощи OpenPGP и управление ключами (импорт и создание новых).
Интерфейс локализован. Причем это могут быть как корпоративные сервера так и публичные сервера. Поддерживаются многие функции настольного приложения drag’n’drop,
горячие клавиши, автозавершение адресов, виртуальные папки, импорт и экспорт контактов (CSV, VCF и vCard).
Пункты меню позволяют произвести все необходимые операции с сообщением отредактировать, переслать, пометить как спам, распечатать, скачать в виде eml файла.

Поддерживается интеграция с Google (включая Google Drive), Dropbox др системы. Возможности расширяются при помощи плагинов.
В поставке имеется 15 плагинов упрощающих интеграцию с некоторыми приложениями и добавляющих функциональность (белый и черный списки, капча и другие).
Среди плагинов проекта [ownCloud](apps.owncloud.com/content) также можно найти RainLoop (Apps > Enable ‘RainLoop’).

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

3.13.1. Установка Rainloop

Для установки Rainloop, необходимо зайти в приложения найти по алфавиту данное приложение и установить.

Необходимо опять перейти в профиль пользователя -> настройки

Необходимо в дополнительных параметрах выбрать автоматический вход пользователей.

Далее необходимо в этом же окне перейти по ссылке:

Перейти в панель администратора RainLoop 

Увидим окно приглашение.
логин: admin
пароль 12345

Меняем пароль и выставляем языковые предпочтения.

Добавляем домен и прописываем соответствующие настройки почтового сервера:

Добавляем основной домен.

3.14 Установка Onlyoffice.

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

Устанавливается на отдельную виртуальную машину:

3.14.1 Подготовительные работы.

Также предполагается что у вас настроена и сконфигурирована доменная зона для onlyoffice.

Рассмотрим эту запись не примере:

Хост

onlyoffice.tegu.online          A     95.163.87.33

3.14.2 Настройка и установка системной локали по умолчанию.

dpkg-reconfigure locales
выбираем
ru_RU.UTF-8

3.14.3 Установка, настройка и изменение часового пояса

timedatectl set-timezone Europe/Moscow

Первым делом обновляем данные о пакетах:

sudo apt-get update
sudo apt-get upgrade

Помимо прочих компонентов, для нормальной работы требуется наличие в системе работающего веб-сервера Nginx.

Выполним для этого ряд действий:

sudo apt-get install nginx
sudo systemctl start nginx
sudo systemctl enable nginx

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

3.14.4 Устанавливаем совместимую с дистрибутивом базу данных PostgreSQL:

sudo apt-get install postgresql

После успешной установки необходимо создать саму базу данных и пользователя.
Стоит обратить особое внимание, что имя пользователя базы данных обязательно должно быть — onlyoffice,
а вот пароль (password) можно указать любой, главное — его не забыть. Он понадобится на этапе установки самого сервера.

3.14.5 Подключаемся к PostgreSQL

sudo -u postgres psql

или такой командой.

su - postgres -s /bin/bash
psql

3.14.6 Создаем пользователя и базу для onlyoffice

CREATE DATABASE onlyoffice;
CREATE USER onlyoffice WITH password 'password';
GRANT ALL privileges ON DATABASE onlyoffice TO onlyoffice;
\q

3.14.7 Устанавливаем брокер сообщений RabbitMQ:

sudo apt-get install rabbitmq-server

3.14.8 Устанавливаем дополнения веб-сервера nginx-extras:

sudo apt-get install nginx-extras

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

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80--recv-keys CB2DE8E5
echo "deb https://download.onlyoffice.com/repo/debian squeeze main" | sudo tee /etc/apt/sources.list.d/onlyoffice.list             

3.14.9 Обновляем пакетный менеджер:

sudo apt-get update

3.14.10 Устанавливаем пакет стандартных шрифтов майкрософт:

sudo apt-get install ttf-mscorefonts-installer
И собственно сама установка ONLYOFFICE Documentserver'а. 
Вот при выполнении этого этапа и будет запрошен пароль доступа к создаваемой ранее базе данных.
sudo apt-get install onlyoffice-documentserver

3.14.11 Проверка работоспособности серверной части.

Собственно, на данном моменте уже можно проверить работоспособность.
Зайдя в браузере по адресу настраиваемого сервера, мы должны увидеть следующее:

Здесь внизу есть кнопка [GO TO TEST EXAMPLE], по которой можно запустить тестовые документы и проверить работоспособность.
Но для этого сначала нужно выполнить:

sudo supervisorctl start ds:example

И теперь можно убедиться в работоспособности сервера и оценить интерфейс.

Главное, после проверки работоспособности не забыть выключить тестовые файлы:

sudo supervisorctl stop ds:example

3.14.12 Установка клиентской части и интеграция с nextcloud.

С установкой серверной части закончено, и пора приступать к настройке клиентской.
Здесь всё просто. Заходим в Nextcloud (под аккаунтом администратора),
открываем магазин приложений > аккаунт > приложения, в поиске вводим ONLYOFFICE и устанавливаем.
После переходим в аккаунт > настройки и в левом меню в разделе «Параметры сервера» ищем пункт ONLYOFFICE

Здесь в поле «Адрес» ONLYOFFICE Docs пишем адрес сервера, который настраивали на предыдущих шагах, и ниже нажимаем сохранить.

Здесь также желательно настроить секретный ключ для доступа к серверу Onlyoffice.

Токен включается сервере Onlyoffice следующим образом:

nano /etc/onlyoffice/documentserver/local.json

Должно получится так:

"token": {
        "enable": {
          "request": {
            "inbox": true,
            "outbox": true
          },
          "browser": true
        },
        "inbox": {
          "header": "Authorization" 
        },
        "outbox": {
          "header": "Authorization" 
        }
      },
      "secret": {
        "inbox": {
          "string": "9Adl54NYtDvYMS" 
  • Где inbox, outbox меняется на true
    а в секции string генерируете удобным способом токен и вписываете его сюда, этот же токен прописываете при интеграции в nextcloud.

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

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

Нижен представлен конфиг для публикации:

3.15 Настрока Apache Revers Proxy для работы сервера через протокол HTTPS.

Здесь всё тоже довольно просто и лаконично.

Применяем подобную схему apache reverse proxy как и для настройки Nextcloud.

3.15.1 Создаем конфиг oo.tegu.online.conf

Конфиги находятся здесь:

cd /etc/apache2/sites-available
nano /etc/apache2/sites-available/oo.tegu.online.conf

Вставляем конфиг со своими параметрами.

root@www:/etc/apache2/sites-available# cat oo.tegu.online.conf
<VirtualHost *:80>
    ServerName oo.tegu.online
    DocumentRoot /var/www/html
    ErrorLog ${APACHE_LOG_DIR}/oo-tegu-error.log
    CustomLog ${APACHE_LOG_DIR}/oo-tegu-access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =oo.tegu.online
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

3.15.2 Включаем созданный конфиг в Apache.

a2ensite oo.tegu.online.conf

Получаем сертификат Certbort. На вопрос перенаправлять на SSL, отвечаем да (2)

(здесь указываете свои параметры домена)

certbot --apache -d oo.tegu.online

3.15.3 Редактируем конфиг для работы с SSL.

oo.tegu.online-le-ssl.conf

Должно получится так:

<VirtualHost *:443>
    ServerName oo.tegu.online
    DocumentRoot /var/www/html
            ProxyRequests       Off

        RequestHeader set X-Forwarded-Proto "https" 

<IfModule mod_proxy.c>
        ProxyPass /.well-known/acme-challenge !
</IfModule>

        SSLProxyEngine On
        SSLProxyVerify none
        SSLProxyCheckPeerCN off
        SSLProxyCheckPeerName off
        ProxyPreserveHost On
        ProxyPassMatch "^/(.*\websocket)$" "ws://10.44.44.33/$1" 
        ProxyPass / http://10.44.44.33/
        ProxyPassReverse    / http://10.44.44.33/
        RemoteIPHeader X-Real-IP
        RemoteIPInternalProxy 10.44.44.0/24
        ErrorLog ${APACHE_LOG_DIR}/oo-tegu-error.log
    CustomLog ${APACHE_LOG_DIR}/oo-tegu-access.log combined

        SetEnvIf Host "^(.*)$" THE_HOST=$1
        RequestHeader setifempty X-Forwarded-Proto https
        RequestHeader setifempty X-Forwarded-Host %{THE_HOST}e
        ProxyAddHeaders Off

SSLCertificateFile /etc/letsencrypt/live/oo.tegu.online/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/oo.tegu.online/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Вот, собственно, и все действия необходимые для базовой локальной настройки интеграции пакета ONLYOFFICE в Nextcloud.

На этом наша настройка облачного хранилища подошла к концу.

3.16. Вопросы и ответы

3.16.1. При авторизации Nextcloud выдает «Слишком много попыток авторизации»?

Для этого нужно очистить таблицу oc_bruteforce_attempts

Подключаемся к базе данных postgres.

su - postgres -s /bin/bash

Далее — запустим psql

psql -Unextcloud -hlocalhost -W --dbname=nextcloud

Проверим, сколько записей в таблице.

select count(*) from oc_bruteforce_attempts;

Смотрим вывод в консоли: видим 6 записей в таблице

nextcloud=>     
select count(*) from oc_bruteforce_attempts;
 count 
-------
     6
(1 строка)

Для очистки запустим команду:

truncate oc_bruteforce_attempts RESTART IDENTITY;

проверяем после очистки

nextcloud=>     
select count(*) from oc_bruteforce_attempts;
 count 
-------
     0
(1 строка)

nextcloud=> 

3.16.2. Nextcloud не отправляет почту. stream_socket_enable_crypto(): SSL operation failed with code 1

Nextcloud не отправляет письма. При попытке отправить тестовое письмо получаем ошибку:
«stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages: error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed at /var/www/nextcloud/3rdparty/swiftmailer/swiftmailer/lib/classes/Swift/Transport/StreamBuffer.php#94»

Проблема в самоподписанном сертификате. По умолчанию Nextcloud живет в идеальном мире в котором все сертификаты заверены доверенными УЦ)
Галочки «доверять всем сертификатам» в настройках нет, значит… We need to go deeper

Открываем текстовым редактором /nextcloud/lib/private/Mail/Mailer.php (обычно полный путь «/var/www/nextcloud/lib/private/Mail/Mailer.php»),
находим блок настроек отправки(ориентировочно 250-257 строки):

$transport = new \Swift_SmtpTransport();
        $transport->setTimeout($this->config->getSystemValue('mail_smtptimeout', 10));
        $transport->setHost($this->config->getSystemValue('mail_smtphost', '127.0.0.1'));
        $transport->setPort($this->config->getSystemValue('mail_smtpport', 25));
        if ($this->config->getSystemValue('mail_smtpauth', false)) {
                $transport->setUsername($this->config->getSystemValue('mail_smtpname', ''));
                $transport->setPassword($this->config->getSystemValue('mail_smtppassword', ''));
                $transport->setAuthMode($this->config->getSystemValue('mail_smtpauthtype', 'LOGIN'));

и добавляем новой строкой:

$transport->setStreamOptions(array('ssl' => array('allow_self_signed' => true, 'verify_peer' => false)));

Этой строчкой мы разрешаем принимать самоподписанные сертификаты. После этого отправка почты будет работать.

3.16.3. Забыли административный пароль от Rainloop

Rainloop хранить пароли в зашифрованном виде, можно сбросить пароль на перврначальный 12345

nano /var/www/nextcloud/data/rainloop-storage/_data_/_default_/configs/nano application.ini

Находим строку ; Login and password for web admin panel

должно получиться так:

; Login and password for web admin panel
admin_login = "admin" 
admin_password = "12345" 

3.16.4. Как включить логи Rainloop

Включаем логи в конфиге.

nano /var/www/nextcloud/data/rainloop-storage/_data_/_default_/configs/application.ini

Должно получиться так:

[logs]
enable = On

4. Установка по установке кластера СУБД высокой доступности Master-Slave

Вы уже знаете, что редакция Tegu Enterprise может хранить базу данных параметров и почту в СУБД Postgres.
Мультисерверная редакция Tegu Enterprise позволяет собрать кластер вычислительных нод Tegu, состоящий из любого количества нод, что позволяет обеспечить отказоустойчивость, а также горизонтально масштабировать мощность сервера. Все они работают симметрично и хранят информацию в СУБД. Однако и сама СУБД может быть собрана по отказоустойчивой схеме. Как это сделать описано в данном разделе.

Обратите внимание, что сборка кластера Postgres не имеет прямого отношения в дистрибутиву Tegu. Тем не менее, данная статья может оказаться полезной в практической реализации решения и потому предлагается вашему вниманию.

4.1. Архитектура

  • Три ноды:
    • сервер СУБД - pgc1 (10.1.1.21)
    • сервер СУБД - pgc2 (10.1.1.22)
    • участник кворума pgc3 (10.1.1.23)
  • виртуальный IP - pgc-vip (10.1.1.20)

4.2. Установка пакетов

На серверы СУБД необходимо установить сервер PostgreSQL версии не ниже 13.
На все серверы надо установить pcs, необходимый агент fence (fence_pve, fence_virsh, fence_vmware или др.).
Если в репозитории resource-agents-paf версии ниже 2.3.0, то надо скачать отсюда последнюю стабильную версию.

4.3. Предварительная подготовка

На всех серверах в файле /etc/hosts должны быть сопоставления имён всех нод с их адресами IP.
Также в этом файле должно быть сопоставление имени для виртуального IP.

10.1.1.20 pgc-vip
10.1.1.21 pgc1.lan pgc1
10.1.1.22 pgc2.lan pgc2
10.1.1.23 pgc3.lan pgc3

Отключаем автозапуск PostgreSQL на серверах СУБД:

systemctl stop postgresql-13.service
systemctl disable postgresql-13.service

Также не забываем убедиться, что в SysV тоже выключено (update-rc.d, chkconfig,...)

4.4. Настраиваем репликацию

4.4.1. На сервере pgc1

Если менеджер пакетов не создал системную БД, то надо её создать:

/usr/pgsql-13/bin/postgresql-13-setup initdb

В конец postgresql.conf добавляем параметры:

listen_addresses = '*'
hba_file = '/var/lib/postgresql/13/pg_hba.conf'
include = '../standby.conf'

Файл postgresql.conf может быть либо в /etc/postgresql, либо в в PGDATA (/var/lib/postgresql/13/data).

В файле /var/lib/postgresql/13/standby.conf указываем параметры подключения к мастеру для репликации (это нужно на случай, если она перестанет быть мастером):

primary_conninfo = 'user=repuser host=10.1.1.20 application_name=pgc1'

Переносим pg_hba.conf в папку /var/lib/postgresql/13. Этот файл изначально может быть либо в /etc/postgresql, либо в PGDATA.
В файл pg_hba.conf добавляем запреты и разрешения доступа на репликацию:

host  replication repuser    10.1.1.20/32    reject
local replication all                reject
host  replication all        pgc1        reject
host  replication all        127.0.0.0/8    reject
host  replication all        ::1/128        reject
host  replication all        10.1.1.21/32    reject
host  replication repuser    10.1.1.22/32    trust

Временно назначаем виртуальный IP:
ifconfig eth0:1 10.1.1.20/24

Временно запускаем PostgreSQL:
systemctl start postgresql-13.service

Переходим под системного пользоваеля postgres и создаём роль для репликации:
su - postgres
psql
CREATE USER repuser REPLICATION;

Выходим из psql (Ctrl+D) и из пользователя postgres (Ctrl+D).

4.4.2. На сервере pgc2

Чистим PGDATA:

rm -rf /var/lib/postgresql/13/data/*

Переходим под пользователя postgres и скачиваем реплику с мастера:
su - postgres
pg_basebackup -h pgc-vip -U repuser -D /var/lib/postgresql/13/data -X stream -P

В файле /var/lib/postgresql/13/standby.conf указываем параметры подключения к мастеру для репликации:

primary_conninfo = 'user=repuser host=10.1.1.20 application_name=pgc2'

Создаём файл /var/lib/postgresql/13/pg_hba.conf с таким же содержимым, как и на pgc1, но меняем следующие строки:

host  replication all        pgc1            reject

меняем на
host  replication all        pgc2            reject

host  replication all        10.1.1.21/32    reject

меняем на
host  replication all        10.1.1.22/32    reject

host  replication repuser    10.1.1.22/32    trust

меняем на
host  replication repuser    10.1.1.21/32    trust

Указываем, что это подчинённый сервер:

touch /var/lib/postgresql/13/data/standby.signal

Выходим из пользователя postgres (Ctrl+D).

4.4.3. На сервере pgc1

Останавливаем PostgreSQL:

systemctl stop postgresql-13.service

Убираем виртуальный IP:
ifconfig eth0:1 0.0.0.0

4.5. Настройка кластера

Для начала на всех серверах надо задать один и тот же пароль для пользователя hacluster:

passwd hacluster

Включаем и запускаем демон pcsd на всех нодах:
systemctl enable --now pcsd

На каждой ноде запускаем авторизацию с остальными:

pcs host auth -u hacluster pgc1 pgc2 pgc3

Создаём кластер, выполнив следующее на первой ноде (pgc1):

pcs cluster setup pgsql_cluster pgc1 pgc2 pgc3

Чтобы не было никаких неожиданных спец.эффектов после перезапуска нод, отключаем автозапуск pacemaker-а. На каждой ноде:

pcs cluster disable --all

4.5.1. На сервере pgc1

Включаем кластер:

pcs cluster start --all

Задаём параметры по умолчанию

pcs resource defaults migration-threshold=5
pcs resource defaults resource-stickiness=10
Создаём устройства ограждения (fencing). Здесь приводятся устройства для Proxmox, но в других конфигурациях могут быть другие. Для конкретного типа надо смотреть доку по параметрам.
pcs cluster cib fencing.xml
pcs -f fencing.xml stonith create fence_vm_pgc1 fence_pve pcmk_host_list="pgc1" pcmk_host_check="static-list" ipaddr="10.1.1.199" node_name="vrt1" login="fenceuser@pve" passwd="Qwe123Poi" port="101" power_wait="10" vmtype="lxc" 
pcs -f fencing.xml stonith create fence_vm_pgc2 fence_pve pcmk_host_list="pgc2" pcmk_host_check="static-list" ipaddr="10.1.1.199" node_name="vrt1" login="fenceuser@pve" passwd="Qwe123Poi" port="102" power_wait="10" vmtype="lxc" 
pcs -f fencing.xml stonith create fence_vm_pgc3 fence_pve pcmk_host_list="pgc3" pcmk_host_check="static-list" ipaddr="10.1.1.199" node_name="vrt1" login="fenceuser@pve" passwd="Qwe123Poi" port="103" power_wait="10" vmtype="lxc" 

здесь
  • 10.1.1.199 - адрес любой достуной ноды Proxmox
  • node_name="vrt1" - имя ноды (точно, как указано в самом Proxmox)
  • fenceuser@pve - пользователь Proxmox, который имеет право перезапускать, запускать и останавливать данные ВМ
  • port="101" - vmid виртуалки, для которой создаётся устройство (берётся в Proxmox)
  • vmtype="lxc" - тип виртуалки (в данном случае - контейнер LXC)

Указываем для каждой ноды, что её устройство ограждения на ней же самой сработать не может (сами в себя не стреляем):

pcs -f fencing.xml constraint location fence_vm_pgc1 avoids pgc1=INFINITY
pcs -f fencing.xml constraint location fence_vm_pgc2 avoids pgc2=INFINITY
pcs -f fencing.xml constraint location fence_vm_pgc3 avoids pgc3=INFINITY

И применяем конфигурацию:
pcs cluster cib-push scope=configuration fencing.xml

Создаём ресурс PostgreSQL:

pcs cluster cib cluster1.xml
pcs -f cluster1.xml resource create pgsqld ocf:heartbeat:pgsqlms \
 bindir=/usr/lib/postgresql/13/bin \
 pgdata=/var/lib/postgresql/13/data \
 pghost=/var/run/postgresql \
 op start timeout=60s \
 op stop timeout=60s \
 op promote timeout=30s \
 op demote timeout=120s \
 op monitor interval=15s timeout=10s role="Master" \
 op monitor interval=16s timeout=10s role="Slave" \
 op notify timeout=60s \
 promotable notify=true

здесь

  • bindir - папка с бинарниками PostgreSQL (нужен pg_ctl)
  • pgdata - PGDATA
  • pghost - папка, где PostgreSQL создаёт unix-сокет (файл с именем .s.PGSQL.5432)

Запрещаем этому ресурсу запускаться на сервере участнике кворума (pgc3):

pcs -f cluster1.xml constraint location pgsqld-clone rule resource-discovery=never score=-INFINITY \#uname eq pgc3

Создаём ресурс виртуального IP:

pcs -f cluster1.xml resource create pgsql-pri-ip ocf:heartbeat:IPaddr2 ip=10.1.1.20 cidr_netmask=24 op monitor interval=10s

Привязываем этот ресурс к предыдущему и задаём порядок запуска ресурсов и их остановки:

pcs -f cluster1.xml constraint colocation add pgsql-pri-ip with master pgsqld-clone INFINITY
pcs -f cluster1.xml constraint order promote pgsqld-clone then start pgsql-pri-ip symmetrical=false kind=Mandatory
pcs -f cluster1.xml constraint order demote pgsqld-clone then stop pgsql-pri-ip symmetrical=false kind=Mandatory

Применяем конфигурацию:

pcs cluster cib-push scope=configuration cluster1.xml

Через несколько секунд будут запущены все ресурсы.

Мониторим командой crm_mon на любой ноде.

5. Организация балансировки вычислительных нод Tegu

Организация балансировки вычислительных нод Tegu потребуется вам в случае использования редакции Tegu Enterprise в мультисерверном (кластерном) исполнении. Такая балансировка не имеет прямого отношения к дистрибутиву Tegu т.к. выполняется сетевым оборудованием пользователя.

Однако, нет ничего страшного в случае, если у пользователя нет сетевого оборудования, способного выполнять балансировку трафика т.к. подобное решение можно реализовать стандартными средствами Linux и дополнительным ПО, отслеживающим падение нод.

Одно из таких решений Tiar мы предлагаем в данном разделе. Данный скрипт написан нами на Python для работы с nftables и может быть полезен как сам по себе, так и для понимания принципа балансировки трафика с помощью собственного оборудования пользователя.

#!/usr/bin/env python3
import signal
import socket
import nftables
import time
from systemd.journal import JournalHandler
import logging

log = logging.getLogger('nft_lb')
log.addHandler(JournalHandler())
log.setLevel(logging.INFO)

class ServiceDestination:
    def __init__(self, name, dip):
        self.name = name
        self.dip = dip
        self.online = True

class LbService:
    def __init__(self, name, vip, vport):
        self.name = name
        self.vip = vip
        self.vport = vport
        self.dest = {}

class Event:
    def __init__(self):
        self.shutdown = False

ev = Event()

lb_map = {}

def create_rules():
    nft = nftables.Nftables()
    code, _, __ = nft.cmd('flush table ip lb')
    if code != 0:
        code, _, __ = nft.cmd('create table ip lb')
    nft.cmd('add chain ip lb prerouting { type nat hook prerouting priority 0 ; }')
    nft.cmd('add chain ip lb forward { type filter hook forward priority -10 ; }')
    for svc_name in lb_map.keys():
        nft.cmd(f'add chain ip lb dnat_{svc_name}')
        nft.cmd(f'add rule ip lb prerouting ip daddr {lb_map[svc_name].vip} tcp dport {lb_map[svc_name].vport} counter jump dnat_{svc_name}')
        dest_count = len(lb_map[svc_name].dest)
        dest_list = []
        for dest_num, dest_name in enumerate(lb_map[svc_name].dest.keys()):
            dest_list.append(f'{dest_num} : {lb_map[svc_name].dest[dest_name].dip}')
            nft.cmd(f'add rule ip lb forward ip daddr {lb_map[svc_name].dest[dest_name].dip} tcp dport {lb_map[svc_name].vport} counter mark set 333444555 accept comment "[{svc_name}] -> {dest_name}"')
        nft.cmd(f'add rule ip lb dnat_{svc_name} counter dnat to numgen inc mod {dest_count} map {{ {", ".join(dest_list)} }}')

def recreate_service(svc_name):
    nft = nftables.Nftables()
    dest_list = []
    online_exists = False
    for dest_name in lb_map[svc_name].dest.keys():
        if lb_map[svc_name].dest[dest_name].online:
            dest_list.append(lb_map[svc_name].dest[dest_name].dip)
            online_exists = True
    dest_count = len(dest_list)
    dest_map_list = []
    for num, dest in enumerate(dest_list):
      dest_map_list.append(f'{num} : {dest}')
    nft.cmd(f'flush chain ip lb dnat_{svc_name}')
    if online_exists:
        nft.cmd(f'add rule ip lb dnat_{svc_name} counter dnat to numgen inc mod {dest_count} map {{ {", ".join(dest_map_list)} }}')

def shutdown_lb(sig_num, frame):
    nft = nftables.Nftables()
    nft.cmd('flush table ip lb')
    nft.cmd('delete table ip lb')
    ev.shutdown = True

def check_backends():
    for svc_name in lb_map.keys():
        need_recreate = False
        for dest_name in lb_map[svc_name].dest.keys():
            a_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
            a_socket.settimeout(1)
            host = lb_map[svc_name].dest[dest_name].dip
            port = lb_map[svc_name].vport
            if a_socket.connect_ex((host, port)) != 0:
                if lb_map[svc_name].dest[dest_name].online:
                    log.info(f'[{svc_name}] Node "{dest_name}" offline')
                    lb_map[svc_name].dest[dest_name].online = False
                    need_recreate = True
            else:
                if not lb_map[svc_name].dest[dest_name].online:
                    log.info(f'[{svc_name}] Node "{dest_name}" online')
                    lb_map[svc_name].dest[dest_name].online = True
                    need_recreate = True
            a_socket.close()
        if need_recreate:
            recreate_service(svc_name)

def process_config():
    with open('/opt/nft_lb_rules', 'r') as f:
        rules_str = f.read()
    for rule_line in rules_str.split('\n'):
        if rule_line.strip() == '': continue
        svc_name, vip, vport, dest_name, dip = rule_line.split('|')
        if svc_name not in lb_map:
            lb_map[svc_name] = LbService(svc_name, vip, int(vport))
        lb_map[svc_name].dest[dest_name] = ServiceDestination(dest_name, dip)
        create_rules()
if __name__ == '__main__':
    signal.signal(signal.SIGINT, shutdown_lb)
    signal.signal(signal.SIGTERM, shutdown_lb)
    signal.signal(signal.SIGHUP, shutdown_lb)
    process_config()
    tik_count = 0
    while not ev.shutdown:
        if tik_count >= 20:
            check_backends()
            tik_count = 0
            continue
        time.sleep(1)
        tik_count += 1

Данный скрипт использует список правил из файла /opt/nft_lb_rules в следующем формате:

smtp|1.2.3.4|25|node1|10.1.1.11
smtp|1.2.3.4|25|node2|10.1.1.12
smtp|1.2.3.4|25|node3|10.1.1.13
imap|1.2.3.4|993|node1|10.1.1.11
imap|1.2.3.4|993|node2|10.1.1.12
imap|1.2.3.4|993|node3|10.1.1.13
smtps|1.2.3.4|465|node1|10.1.1.11
smtps|1.2.3.4|465|node2|10.1.1.12
smtps|1.2.3.4|465|node3|10.1.1.13
webadm|1.2.3.4|9999|node1|10.1.1.11
webadm|1.2.3.4|9999|node2|10.1.1.12
webadm|1.2.3.4|9999|node3|10.1.1.13

Если в nftables в основной цепоче forward последним правилом настроено отбрасывание всех внешних пакетов, то необходимо исключить из этого правила пакеты с меткой 333444555:
iifname "eth1" mark != 333444555 counter drop

Для настройки автозапуска скрипта балансировщика, надо создать, включить и запустить сервис systemd:

/etc/systemd/system/nft_lb.service

[Unit]
Description=Nftables python balancer
After=multi-user.target

[Service]
Type=simple
Restart=always
ExecStart=/usr/bin/python3 /opt/nft_lb.py

[Install]
WantedBy=multi-user.target

6. Инструкция по эксплуатации почтового сервера Tegu

6.1. Введение

После того, как Сервер Tegu запущен и работает, можно приступать к настройке, а его работа может полностью контролироваться через любой Веб браузер.

По умолчанию, модуль HTTPS предоставляет доступ к страницам Администрирования Сервера Tegu через TCP порт номер 9999.

6.2. Управление с помощью административного веб-интерфейса

Все страницы Интерфейса управления разделены на восемь разделов.

  1. Настройки
  2. Белый и чёрный списки SMTP
  3. Заблокированные IP
  4. Провайдеры БД пользователей
  5. Хранилища почты
  6. Очередь SMTP
  7. БД параметров
  8. Система

Доступ к ним имеет только пользователь admin, пароль которого можно считать в файле конфигурации сервера (~/tegu.conf, либо /etc/tegu.conf), который создается автоматически во время процедуры установки.
В секции [WEB] вы найдете параметр adminPassword, значение которого равно первоначальному паролю пользователя admin.

6.2.1. Настройки

6.2.1.1. Server name (used in banner and HELO/EHLO)

Поле определяет Имя сервера для сессий SMTP.
Пример: mail.test.tegu.online

6.2.1.2. Full allowed IPs (one per line)

Параметр определяет Список IP-адресов, с которых допускается отправка писем без авторизации.
Рекомендуем пользоваться этим параметров крайне осторожно, так как это снижает защищенность сервера. Однако, в ряде случаев без него не обойтись. Например, при использовании некоторых моделей сканеров, не поддерживающих авторизацию.
Адреса записываются по одному в каждой строке.

6.2.1.3. Allow empty sender email for full-allowed IPs

Параметр определяет Разрешение/Запрещение отправки почты клиентом без заполнения поля MAIL FROM (как правило используется оборудованием).
По умолчанию: Отключено

6.2.1.4. IP SMTP server listen on

Поле определяет Адреса интерфейсов, на которых работает сервер (либо 0.0.0.0 для работы на всех интерфейсах).

6.2.1.5. Port SMTP server listen on

Поле определяет Порт сессий SMTP.
По умолчанию: 25

6.2.1.6. Port SMTPS (SSL) server listen on

Порт сессий SMTP c SSL (SSL станет доступным если файлы сертификата и ключа существуют и доступны для чтения. См Path to SSL certificate. Обратите внимание, что по умолчанию установлен непривилегированный номер для того, чтобы исключить попытку взлома несконфигурированного сервера).
По умолчанию: 465

6.2.1.7. Max number of simultaneous SMTP connections

Параметр определяет Максимальное количество SMTP подключений.
По умолчанию: 100

6.2.1.8. Enable LMTP delivery (IMAP server starts otherwise. Restart required)

Параметр позволяет Включить/Отключить доставку почты на LMTP (к примеру, дополнительный Dovecot).
По умолчанию: Отключено

6.2.1.9. LMTP host connect to

Параметр определяет Хост LMTP.

6.2.1.10. LMTP port connect to

Параметр определяет Порт LMTP хоста.

6.2.1.11. IP IMAP server listen on

Параметр определяет Адрес, который слушает сервер IMAP.
Если введено 0.0.0.0, то слушает на всех адресах.

6.2.1.12. Port IMAP server listen on

Параметр определяет Порт, который слушает сервер IMAP.
По умолчанию: 143

6.2.1.13. Port IMAPS (SSL) server listen on

Параметр определяет Порт, который слушает сервер IMAPS.
По умолчанию: 993

6.2.1.14. Max number of simultaneous IMAP connections

Параметр определяет Максимальное количество соединений IMAP.
По умолчанию: 1000

6.2.1.15. Canonical name for INBOX (show in WEB panel)

Параметр определяет Имя паки по умолчанию для Входящих.
По умолчанию: Входящие

6.2.1.16. Message size in MB

Параметр определяет Максимальный разрешенный размер почтового сообщения в Mb.
По умолчанию: 30Mb.

6.2.1.17. Directory for work data

Параметр определяет Путь к рабочему каталогу (сервер хранит там оперативные глобальные настройки, а также очереди).
По умолчанию: /opt/tegu/data

6.2.1.18. Directory for DKIM keys

Параметр определяет Путь к приватному ключу DKIM (Напомню, что публичный ключ опубликован в зоне DNS).
По умолчанию: /opt/tegu/dkim

6.2.1.19. DKIM selector

Параметр определяет Селектор DKIM (кодовое слово для подписи, должно соответствовать тому, которое указано в зоне DNS).
По умолчанию: mail

6.2.1.20. Path to SSL certificate

Параметр определяет Пусть к публичному ключу SSL.
По умолчанию: /opt/tegu/certs/fullchain.pem

6.2.1.21. Path to SSL private key

Параметр определяет Путь к приватному ключу SSL.
По умолчанию: Path to SSL private key

6.2.1.22. Master-user login separator

Параметр определяет Разделитель, используемый при вводе мастер-логина.
По умолчанию: *

6.2.1.23. Sender domains greylist ignore (one per line)

Параметр определяет Список доменов, для которых отключена технология GreyList.

6.2.1.24. Server/sender greylist record lifetime (hours)

Параметр определяет Время жизни email-адреса в списке GreyList.
По умолчанию: 24

6.2.1.15. Server/sender whitelist record lifetime (hours)

Параметр определяет Время жизни email-адреса в списке WhiteList.
По умолчанию: 720

6.2.1.16. Clean expired greylist records interval (seconds)

Параметр определяет Период обновления базы GreyList.
По умолчанию: 300

6.2.1.17. DNSBL "listed at" threshold

Параметр определяет Порог срабатывания блокировки по количеству черных списков, в которых найдет адрес отправителя.
Если адрес был замечен в черных списках, но порог не превышен, письмо доставляется, но в тему добавляется x-blacklisted с указанием всех списков, где он был найден.
По умолчанию: 3

6.2.1.18. Enable authentication security

Включение/Отключение функции бан для ошибок авторизации пользователей (на все службы SMTP, IMAP и HTTP).
По умолчанию: Включено

6.2.1.19. Failed auth record lifetime (minutes)

По умолчанию: 60

6.2.1.20. Ban time (minutes)

По умолчанию: 60

6.2.1.21. Max failed authentication attempts

Максимальное количество допустимых ошибок авторизации.
По умолчанию: 3

6.2.1.22. Block senders with SPF fail result

Включение возможности обслуживания клиентов, даже не прошедших SPF проверку (как правило используется оборудованием).
По умолчанию: Включено

6.2.1.23. Enable Greylist

Параметр определяет Включение функции GreyList.
По умолчанию: Включено

6.2.1.24. Enable SMTP ip/sender whitelist/blacklist

Параметр определяет Включение функции whitelist/blacklist.
По умолчанию: Включено

6.2.1.25. Enable DNSBL checks

Параметр определяет Включение DNSBL проверки.
По умолчанию: Включено

6.2.1.26. Log session (IMAP/SMTP) start and finish

По умолчанию: Отключено

6.2.2. Белый и чёрный списки SMTP

6.2.2.1. Белый список адресов IP серверов отправителей

С помощью данного инструмента можно добавлять, просматривать и удалять IP-адреса в белый список сервера.

6.2.2.2. Белый список email отправителей

С помощью данного инструмента можно добавлять, просматривать и удалять email-адреса в белый список сервера.

6.2.2.3. Чёрный список адресов IP серверов отправителей

С помощью данного инструмента можно добавлять, просматривать и удалять IP-адреса в черный список сервера.

6.2.2.4. Чёрный список email отправителей

С помощью данного инструмента можно добавлять, просматривать и удалять email-адреса в черный список сервера.

6.2.3. Заблокированные IP

При включенной функции 2.1.18. Enable authentication security сервер считает количество ошибок авторизации и, в случае превышения порога 2.1.21. Max failed authentication attempts помещает соответствующий IP-адрес в список Ban.

Заблокированный IP-адрес будет находится в Ban-е в течение времени, указанного в параметре 2.1.20. Ban time (minutes).

Отредактировать данный список вручную можно в разделе 2.3. Заблокированные IP.

6.2.4. Провайдеры БД пользователей

Сервер Tegu в состоянии работать как автономно (standalone), так и в интеграции с множеством контроллеров LDAP/MS Active Directory. При этом количество локальных баз данных пользователей и контроллеров домена не ограничено.

Для того, чтобы начать использование одной из баз данных пользователей необходимо создать соответствующего "провайдера БД пользователей".

Это мероприятие осуществляется в разделе "Провайдеры БД пользователей" нажатием на кнопку "Добавить провайдера БД пользователей".

В соответствующем диалоге необходимо выбрать:

  • JSON File User DB - локальная база пользователей в формате JSON
  • LDAP User DB - подключение к удаленному контроллеру домена

Рассмотрим работу каждого провайдера подробнее:

6.2.4.1. JSON File User DB

6.2.4.1.1. Provider Name

Имя соединения (произвольное).
Пример: TEST

6.2.4.1.2. Local domain name

Домен, к которому относится данное соединение.
Пример: test.tegu.online

6.2.4.1.3. Directory path of user/group databases

Параметр определяет путь в JSON-файлу БД пользователей.

6.2.4.1.4. Group name of master users

Параметр определяет имя группы пользователей, которые получают права мастер-пользователей.

6.2.4.2. LDAP User DB

6.2.4.2.1. Provider Name

Имя соединения (произвольное).
Пример: TEST LDAP

6.2.4.2.2. Local domain name

Домен, к которому относится данное соединение.
Пример: test.tegu.online

6.2.4.2.3. LDAP connection URIs (one per line)

Пример: ldaps://tegu-ds.mbk.lan:636

6.2.4.2.4. BindDN

Пример:

6.2.4.2.5. Password

Пароль для поля BindDN

6.2.4.2.6. Base DN

Пример: dc=test,dc=tegu,dc=online

6.2.4.2.7. objectClass for user

Пример: user

6.2.4.2.8. Attr for mailbox e-mail

Произвольное имя поля, которое сервер будет искать в LDAP для того, чтобы трактовать его как email.
Пример: mail

6.2.4.2.9. Attr for mailbox quota (value in MB)

Произвольное имя поле, которое сервер будет искать в LDAP для того, чтобы трактовать его как максимальный размер ящика.
Пример: facsimileTelephoneNumber

6.2.4.2.10. User memberOf attr

Если отношения групп и пользователей указываются в объекте пользователей, то здесь указываем имя поля, содержащего группы, к которым принадлежит пользователь.
Пример: memberOf

6.2.4.2.11. Use groups

Если группы могут иметь email, то этот параметр включает механизм доставки писем всем членам этих групп.

  • objectClass for group
  • Attr for group name - имя поля, содержащего имя группы.
  • Attr for group email - имя поля, содержащего email группы.
  • Attr for group members - имя поля, указывающего на членов групп.
  • Group member attr contains DN - в поле, указывающем на членов групп, могут быть DN членов или только имена этих членов.
    • Attr for user RDN - если в поле, указывающем на членов групп, содержатся имена, то здесь указываем имя поля (например, uid или cn) для поиска этих членов по их именам.
6.2.4.2.12. Use mailbox alias (redirect list)

Параметр определяет использовать ли списки перенаправления.

  • objectClass for alias
  • Attr for alias email - имя поля, содержащего email списка
  • Attr for email redirect to - имя поля, содержащего адреса email, на которые необходимо перенаправить письма (email могут быть локальными или внешними)
6.2.4.2.13. Use mailbox alternative email

Параметр определяет использовать ли дополнительные email для ящиков.

  • Attr for mailbox alternative email - имя поля объекта пользователя, содержащего альтернативные email.
6.2.4.2.14. Attr for group name of master-users

Параметр определяет имя поля, содержащего имя группы мастер-пользователей (может совпадать с "Attr for group name").

6.2.4.2.15. Group name of master-users - имя группы мастер-пользователей

6.2.5. Хранилища почты

6.2.5.1. Maildir mail storage

Параметры хранилища почты (Maildir mail storage)

6.2.5.1.1. Local mail domain name

Домен, к которому относится данное соединение.
Пример: test.tegu.online

6.2.5.1.2. Root directory path of mail

Путь к каталогу maildir

6.2.5.1.3. Archive folder

Имя папки по умолчанию для Архива.

6.2.5.1.4. Drafts folder

Имя папки по умолчанию для Черновика.

6.2.5.1.5. Junk folder

Имя папки по умолчанию для Спама.

6.2.5.1.6. Sent folder

Имя папки по умолчанию для Отправленных.

6.2.5.1.7. Trash folder

Имя папки по умолчанию для Корзины.

6.2.5.1.8. Smarthost (formats: user:pass@host:port or host:port)

Параметр, определяющий доступ к смарт-хосту.

6.2.5.1.9. Default user quota in MB

Параметр, определяющий максимальный размер ящика в Mb.

6.2.5.1.10. Additional Trash quota in MB

Параметр, определяющий дополнительное место (плюс к 2.5.2.13. Default user quota in MB) для корзины. Место может быть использовано для сообщений в корзине, когда квота ящика выбрана.

6.2.5.2. PostgreSQL mail storage

Параметры хранилища почты (PostgreSQL mail storage) домена test.tegu.online

6.2.5.2.1. Адрес сервера

IP-адрес или каноническое имя сервера БД PostgreSQL.

6.2.5.2.2. Порт сервера

Порт, который слушает сервер БД PostgreSQL.

6.2.5.2.3. Имя основной базы данных

Имя основной базы данных сервера PostgreSQL.

6.2.5.2.4. Имя пользователя с правом создавать базы данных

Имя пользователя, для которого определена основная база данных сервера PostgreSQL.

6.2.5.2.5. Пароль
6.2.5.2.6. Максимальное количество одновременных подключений

Параметр определяет количество одновременный сессий с базой данных сервера PostgreSQL.

6.2.5.2.7. Archive folder

Имя папки по умолчанию для Архива.

6.2.5.2.8. Drafts folder

Имя папки по умолчанию для Черновика.

6.2.5.2.9. Junk folder

Имя папки по умолчанию для Спама.

6.2.5.2.10. Sent folder

Имя папки по умолчанию для Отправленных.

6.2.5.2.11. Trash folder

Имя папки по умолчанию для Корзины.

6.2.5.2.12. Smarthost (formats: user:pass@host:port or host:port)

Параметр, определяющий доступ к смарт-хосту.

6.2.5.2.13. Default user quota in MB

Параметр, определяющий максимальный размер ящика в Mb.

6.2.5.2.14. Additional Trash quota in MB

Параметр, определяющий дополнительное место (плюс к 2.5.2.13. Default user quota in MB) для корзины. Место может быть использовано для сообщений в корзине когда квота ящика выбрана.

6.2.6. Очередь SMTP

6.2.6.1. Параметры обработчика очереди сообщений SMTP (PostgreSQL smtp queue)

6.2.6.1.1. Адрес сервера

IP-адрес или каноническое имя сервера БД PostgreSQL.

6.2.6.1.2. Порт сервера

Порт, который слушает сервер БД PostgreSQL.

6.2.6.1.3. Имя базы данных

Имя основной базы данных сервера PostgreSQL.

6.2.6.1.4. Имя пользователя

Имя пользователя, для которого определена основная база данных сервера PostgreSQL.

6.2.6.1.5. Пароль
6.2.6.1.6. Максимальное количество одновременных подключений

Параметр определяет количество одновременный сессий с базой данных сервера PostgreSQL.

6.2.6.1.7. Количество обрабатываемых писем за проход

Количество сообщений, которое вычислительная нода берет из очереди сообщений для обработки, за одно обращение к базе.

6.2.6.2. Панель управления очередью SMTP

6.2.6.2.1. Состояние очереди и управление ею

В данном диалоге вы увидите статистику очереди в разрезе следующих полей:

  • Всего
  • Новые
  • Ожидающие повторную отправку

Вы можете выполнить следующее:

  • Очистить всю очередь
  • Удалить ожидающие повтора
  • Обработать ожидающие повтора
6.2.6.2.2. Список писем в очереди SMTP

В данном диалоге вы увидите очередь в разрезе следующих полей:

  • Отправитель
  • Получатель
  • Добавлено в очередь
  • Будет обработано
  • Действие

6.2.7. БД параметров

6.2.7.1. Настройки БД параметров (PostgreSQL settings database)

6.2.7.1.1. Адрес сервера

IP-адрес или каноническое имя сервера БД PostgreSQL.

6.2.7.1.2. Порт сервера

Порт, который слушает сервер БД PostgreSQL.

6.2.7.1.3. Имя базы данных

Имя основной базы данных сервера PostgreSQL.

6.2.7.1.4. Имя пользователя

Имя пользователя, для которого определена основная база данных сервера PostgreSQL.

6.2.7.1.5. Пароль
6.2.7.1.6. Максимальное количество одновременных подключений

Параметр определяет количество одновременный сессий с базой данных сервера PostgreSQL.

6.2.8. Система

6.2.8.1. Панель управления лицензией

6.2.8.1.1. Информация о лицензии
Идентификатор лицензии: eae4b43e4b4a324c4e4b48e1c4f

Редакция Tegu: Enterprise

Дата окончания действия лицензии: 01.05.2021

Максимальное количество почтовых ящиков: 100

Наименование покупателя: Стенд Лаборатории МБК

Тип покупателя: Юр. лицо

Данные покупателя:

Тип лицензии: Тестовая
6.2.8.1.2. Загрузка ключа лицензии

Инструмент, который позволяет загрузить файл лицензий.
Зашифрованный файл содержит сведения о версии ПО, количестве разрешенных для использования вычислительных нод, количестве разрешенных почтовых ящиков, а также сроке действия лицензии.

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

6.3. Управление с помощью командной строки

Сервер Tegu хранит параметры конфигурации в различных форматах и средах, в зависимости от заданной конфигурации. Это могут быть локальные файлы или записи централизованной базы данных PostgreSQL. Таким образом, основная часть его конфигурирования выполняется через административный веб-интерфейс.

С командной строки выполняется запуск, перезапуск и останов сервера.

6.3.1. Подготовка к запуску

Чтобы разрешить серверу, запущенному от непривилегированного пользователя, слушать на привилегированных портах, необходимо выполнить:

setcap CAP_NET_BIND_SERVICE=+eip /opt/tegu/sbin/tegu

Для запуска через systemd необходимо добавить файл /etc/systemd/system/tegu.service следующего содержания:

[Unit]
Description=Tegu. MBK-Lab Mail Server

[Service]
ExecStart=/opt/tegu/sbin/tegu
User=mail
Group=mail
UMask=0007
RestartSec=10
Restart=always

[Install]
WantedBy=multi-user.target

Во время первого запуска сервер будет искать свой файл конфигурации в следующем порядке:

/etc/tegu.conf
~/tegu.conf

Если файл не найден, то он будет создан по пути ~/tegu.conf со следующим содержанием:

[global]
dataDir = /opt/tegu/data

[WEB]
adminPassword = <пароль администратора>

Можно заранее создать этот файл вручную, но важно, чтобы папка dataDir была доступна для записи пользователю, от которого запускается сервер.

6.3.2. Запуск сервера

Запускаем сервис:

# systemctl enable tegu.service

Created symlink /etc/systemd/system/multi-user.target.wants/tegu.service → /etc/systemd/system/tegu.service.

# systemctl start tegu.service

Читаем лог сервера:

# journalctl -f -u tegu -n 100

окт 05 15:38:26 localhost systemd[1]: Started Tegu. MBK-Lab Mail Server.

6.3.3. Останов сервера

Остановить сервер можно командой

systemctl start tegu.service

Рестарт сервера выполняется командой

systemctl restart tegu.service

6.4. Глобальные правила обработки почтовых сообщений

Глобальные правила обработки почтовых сообщений имеют приоритет и выполняются в первую очередь (перед пользовательскими фильтрами)

Условие 1

  • Тема
  • От
  • Кому
  • Тело
  • Дата
  • Размер

Условие 2

  • Содержит
  • Не содержит
  • Совпадает
  • Не совпадает
  • Начинается

Действие

  • Переместить
  • Скопировать
  • Отметить как прочитано
  • Отметить флагом
  • Отметить меткой
  • Отклонить сообщение

Операторы совпадает , не совпадает , начинается реализованы для всех полей кроме Тело, Дата, Размер.

6.5. Системные журналы

Журналы - это один из самых важных источников информации при возникновении любых ошибок в операционной системе Linux.

6.5.1. Утилита journalctl

Раньше в Linux для сохранения журналов использовался отдельный демон под названием syslogd.
Но с приходом системы инициализации systemd (а именно ее мы настоятельно рекомендуем использовать) большинство функций, касающихся управления сервисами, перешли под её управление. В том числе и управление логами.

Для просмотра логов определенного сервиса или загрузки системы необходимо использовать утилиту journalctl. По сравнению с обычными файлами журналов, у journalctl есть несколько преимуществ. Все логи находятся в одном месте, они индексируются и структурируются, поэтому к ним можно получить доступ в нескольких удобных форматах.

Синтаксис команды очень простой. Напоминаем, что выполнять ее необходимо от суперпользователя.

6.5.2. Опции journalctl

--full, -l - отображать все доступные поля;
--all, -a - отображать все поля в выводе full, даже если они содержат непечатаемые символы или слишком длинные;
--pager-end, -e - отобразить только последние сообщения из журнала;
--lines, -n - количество строк, которые нужно отображать на одном экране, по умолчанию 10;
--no-tail - отображать все строки доступные строки;
--reverse, -r - отображать новые события в начале списка;
--output, -o - настраивает формат вывода лога;
--output-fields - поля, которые нужно выводить;
--catalog, -x - добавить к информации об ошибках пояснения, ссылки на документацию или форумы там, где это возможно;
--quiet, -q - не показывать все информационные сообщения;
--merge, -m - показывать сообщения из всех доступных журналов;
--boot, -b - показать сообщения с момента определенной загрузки системы. По умолчанию используется последняя загрузка;
--list-boots - показать список сохраненных загрузок системы;
--dmesg, -k - показывает сообщения только от ядра. Аналог вызова команды dmesg;
--identifier, -t - показать сообщения с выбранным идентификатором;
--unit, -u - показать сообщения от выбранного сервиса;
--user-unit - фильтровать сообщения от выбранной сессии;
--priority, -p - фильтровать сообщения по их приоритету. Есть восемь уровней приоритета, от 0 до 7;
--grep, -g - фильтрация по тексту сообщения;
--cursor, -c - начать просмотр сообщений с указанного места;
--since, -S, --until, -U - фильтрация по дате и времени;
--field, -F - вывести все данные из выбранного поля;
--fields, -N - вывести все доступные поля;
--system - выводить только системные сообщения;
--user - выводить только сообщения пользователя;
--machine, -M - выводить сообщения от определенного контейнера;
--header - выводить заголовки полей при выводе журнала;
--disk-usage - вывести общий размер лог файлов на диске;
--list-catalog - вывести все доступные подсказки для ошибок;
--sync - синхронизировать все не сохраненные журналы с файловой системой;
--flush - перенести все данные из каталога /run/log/journal в /var/log/journal;
--rotate - запустить ротацию логов;
--no-pager - выводить информацию из журнала без возможности листать страницы;
-f - выводить новые сообщения в реальном времени, как в команде tail;
--vacuum-time - очистить логи, давностью больше указанного периода;
--vacuum-size - очистить логи, чтобы размер хранилища соответствовал указанному.

Пример:

journalctl -f -u tegu -n 100

окт 05 15:38:26 localhost systemd[1]: Started Tegu. MBK-Lab Mail Server.

6.6. Резервное копирование и восстановление

Сервер хранит свои настройки и массив сообщений в двух форматах:

  • maildir на локальном томе
  • В базе данных PostgreSQL

Как следствие выполнение резервного копирования и восстановления также зависит от формата хранения. И в первом случае может быть выполнена штатными средствами ОС Linux, а во втором средствами базы данных.

6.7. Защита

6.7.1. Запрет Открытого релея

По умолчанию на сервере выполнены все настройки для того, чтобы запретить Открытый Релей.
Обрати внимание, что с помощью параметра 2.1.2. Full allowed IPs (one per line) вы можете настроить его использование, но делать это необходимо осознанно и осторожно.

6.7.2. Проверка обратного адреса

Сервер позволяет настроить и использовать технологии SPF, DKIM и DMARC.
Используйте для этого опции

  • 2.1.18. Directory for DKIM keys
  • 2.1.19. DKIM selector
  • 2.1.22. Block senders with SPF fail result

6.7.3. Блокирование на основе DNS (RBL)

Сервер выполняет блокирование сообщений на основании DNS (RBL).
Используйте для этого 2.1.25. Enable DNSBL checks и 2.1.17. DNSBL "listed at" threshold.

6.7.4. Блокирование по IP-адресу

Используйте инструмент 2.2.3. Чёрный список адресов IP серверов отправителей для блокировки сообщений по IP-адресу.

Используйте также инструмент 2.3. Заблокированные IP для работы с адресами, который заблокированы автоматически.

6.7.5. Блокирование по email-адресу

Используйте инструмент 2.2.4. Чёрный список email отправителей для блокировки сообщений по email-адресу.

6.7.6. Гибкие настройки фильтров и блокировок

Используйте 4. Глобальные правила обработки почтовых сообщений для формирования любых правил для настройки глобальных маршрутов сообщений.

6.8. Проверка настроек сервера

Проверить все выполненные настройки сервера можно с помощью утилиты teguctl (идуще в комплекте дистрибутива)

Команда

# /opt/tegu/bin/teguctl dump

выведет всю конфигурацию сервера в тестовом формате.

7. Настройка клиентского ПО

7.1. Веб-интерфейс

Правильно настроенный администратором веб-интерфейс не требует никаких действий по настройке со стороны пользователя.
Однако необходимо запомнить одну особенность - т.к. почтовый сервер Tegu может обслуживать любое количество интернет-доменов и серверов каталогов, то в поле login необходимо вводить полный логин пользователя (с доменной частью) как показано на рисунке.

Далее в пользовательском интерфейсе в горизонтальном меню необходимо выбрать

  • Файловое хранилище
  • Адресные книги
  • Календари
  • Почта

7.2. Десктопный клиент

Настройка десктопного клиента в любой ОС отличается только дизайном диалогов, но выполняется однотипно. Важно понимать основные параметры.
Рассмотрим их на примере.

7.2.1. Настройка почты

  • Чтение почты:
    • Тип сервера: IMAP
    • Порт: 993
    • Сервер: mail.mbk-lab.ru
    • Имя пользователя:
    • Требуется аутентификация: Да
    • Безопасность: SSL
    • Проверка подлинности: Пароль
  • Отправка почты:
    • Тип сервера: SMTP
    • Порт: 465
    • Сервер: mail.mbk-lab.ru
    • Имя пользователя:
    • Требуется аутентификация: Да
    • Безопасность: SSL
    • Проверка подлинности: Пароль

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

7.2.2. Настройка календарей

Протокол, который используется для работы с сервером календарей - CalDAV.

Проприетарные протоколы не используются. В этой связи еще раз напоминаем, что пользователям все еще популярного клиента MS Outlook следует обратить внимание, что в базовой поставке клиент способен работать с почтой по протоколам IMAP и SMTP, но не поддерживает адресные книги и календарь. Для реализации этой возможности необходимо дополнительно использовать бесплатный плагин Outlook CalDav Synchronizer После установки плагина настройка MS Outlook проводится по аналогии с остальными.

7.2.2.1. Подготовка к настройке

У каждого пользователя может быть не один, а любое количество календарей. Поэтому для начала необходимо узнать адрес того, который мы хотим подключить в декстопном клиенте. Для этого откроем страницу календарей в веб-интерфейсе.

В левом фрейме видим список всех календарей данного пользователя. Клик мышкой по элементу управления ... (три точки) открывает меню управления календарем (с помощью которого можно изменить параметры, удалить календарь или Скопировать закрытую ссылку ).
В нашем случае ссылка на календарь выглядит так:

https://cloud.test.tegu.online/remote.php/dav/calendars/ikalmetov@test.tegu.online/-/

Теперь переходим в почтовую программу.

7.2.2.1. Настройка календаря в программе

Для настройки календаря в почтовой программе нам потребуются следующие параметры:

Остается только установить цвет отображения событий и период синхронизации.

Обратите внимание, что различные программы, ведут себя по разному при работе с CalDAV. Для некоторых необходимо подключать каждый календарь отдельно, некоторые с состоянии самостоятельно прочесть весь список пользовательских календарей и предоставить пользователю выбор какие включить (например Evolution, который вы видите на скрине). Если ваша программа так не умеет, то процедуру необходимо повторить для каждого вашего календаря.

7.2.3. Настройка адресных книг

Протокол, который используется для работы с адресными книгами - CardDAV.

Проприетарные протоколы не используются. И опять напоминаем, что пользователям MS Outlook для реализации CardDAV необходимо дополнительно использовать бесплатный плагин Outlook CalDav Synchronizer

7.2.3.1. Подготовка к настройке

Подготовка состоит в копировании ссылки на выбранную адресную книгу аналогично тому, как это было сделано для календаря.

7.2.2.1. Настройка адресной книги в программе

Для настройки адресной книги в почтовой программе нам потребуются следующие параметры:

Готово.

Обратите внимание, что различные программы, ведут себя по разному при работе с CardDAV. Для некоторых необходимо подключать каждую адресную книгу отдельно, повторяя описанную процедуру.

7.3. Мобильный клиент

Настройки клиентского ПО на смартфоне производится абсолютно так же, как и для десктопного клиента.

Однако, если CalDAV и CardDAV в iOs поддерживается "из коробки", то на платформе Android это зависит от версии и поставщика. Если ваш Android не поддерживает DAV, то рекомендуем две надежные и бесплатные утилиты:

В итоге у вас должно получиться так

8. Миграция почтовых серверов

Для переноса почты с одного IMAP сервера на другой мы рекомендуем использовать утилиту IMAPSync.
Эта утилита обладает двумя достоинствами:
  1. Она чрезвычайно корректно работает (сохраняет правильную структуру каталогов, правильно обрабатывает национальные языки и пр.);
  2. Эта утилита универсально по своему определению (использует механизм IMAP). Благодаря этому ее можно использовать с любыми типами почтовых серверов будь то Postfix, MS Exchange или Lotus Domino.
  3. Сервер Tegu внесен в список серверов , совместимость которых с imapsync подтверждена.

Важно понимать, что с помощью IMAPSync можно импортировать только те сообщения, которые находятся с почтовом ящике на сервере. Другими словами для того, чтобы импортировать локальные сообщения, хранящиеся в форматах mailbox/maildir или pst, необходимо предварительно перенести их в серверный почтовый ящик. Как правило это делается средствами почтовой программы или с помощью специальных утилит. К примеру, в распоряжении администраторов MS Exchange серверов (начиная с версии 2010 SP1) есть специальная утилита PowerShell: New-MailboxImportReques. Очевидно, что у администратора, выполняющего операцию импорта, должны быть права на каталоги, в котором хранятся PST-файлы пользователей. Данная работа носит подготовительный организационно-технический характер, зависит от архитектуры конкретной системы и в данной статье не рассматривается.

Установка утилиты


Если вам не удалось установить из штатного репозитория вашего дистрибутива операционной системы, то нам поможет сайт французского разработчика imapsync Жиля ЛамирАля (Gilles LAMIRAL), - https://imapsync.lamiral.info/
Я не просто так написал тут его email - о себе Жиль пишет так "Понимаю, что звучит безумно, но я отвечаю на все письма".

Предварительно установим необходимые пакеты:

sudo apt install -y            \
  libauthen-ntlm-perl     \
  libcgi-pm-perl          \
  libcrypt-openssl-rsa-perl   \
  libdata-uniqid-perl         \
  libencode-imaputf7-perl     \
  libfile-copy-recursive-perl \
  libfile-tail-perl        \
  libio-socket-inet6-perl  \
  libio-socket-ssl-perl    \
  libio-tee-perl           \
  libhtml-parser-perl      \
  libjson-webtoken-perl    \
  libmail-imapclient-perl  \
  libparse-recdescent-perl \
  libmodule-scandeps-perl  \
  libreadonly-perl         \
  libregexp-common-perl    \
  libsys-meminfo-perl      \
  libterm-readkey-perl     \
  libtest-mockobject-perl  \
  libtest-pod-perl         \
  libunicode-string-perl   \
  liburi-perl              \
  libwww-perl              \
  libtest-nowarnings-perl  \
  libtest-deep-perl        \
  libtest-warn-perl        \
  make                     \
  time                     \
  cpanminus

Получаем утилиту:

wget -N https://imapsync.lamiral.info/imapsync

Присваиваем исполняемые права

chmod +x imapsync

Утилита готова к работе.
Запущенная без параметров она возвращает синопсис.

$ ./imapsync 
Name:

 imapsync - Email IMAP tool for syncing, copying, migrating and archiving
 email mailboxes between two imap servers, one way, and without duplicates.

Version:

 This documentation refers to Imapsync $Revision: 2.200 $

Usage:

  To synchronize the source imap account
    "test1" on server "test1.lamiral.info" with password "secret1" 
  to the destination imap account
    "test2" on server "test2.lamiral.info" with password "secret2" 
  do:

   imapsync \
    --host1 test1.lamiral.info --user1 test1 --password1 secret1 \
    --host2 test2.lamiral.info --user2 test2 --password2 secret2

Настройка синхронизации

Рассмотрим следующую модель переноса:

Следуя инструкции получаем примерно следующую команду для синхронизации одного почтового ящика:

imapsync \
--host1 mail.mbk-lab.ru --user1 ikalmetov@mbk-lab.ru --password1 МойПароль1 --ssl1 \
--host2 mail.test.tegu.online --user2 ikalmetov@test.tegu.online --password2 МойПароль2 --ssl2 \
--dry

Ключ --dry говорит, что выполнять перенос сообщений не надо, надо только показать как все это будет выглядеть (проверочный режим). Рекомендуется отладить команду с использованием этого ключа и только затем убрать его из команды чтобы выполнить перенос.

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

Чаще всего аналогичные права можно задать и на других почтовых серверах и это первое, что вы должны уточнить.
" Если нет, оставьте это чтение, возьмите носовой платок и поплачьте " - советует нам Жиль.

Для примера несколько серверов, поддерживающих мастер-пользователей:

  • Exchange 2003/2007/2010/2013/2016
  • Office365
  • Gmail
  • Dovecot
  • Zimbra
  • Kerio
  • Cyrus-imap
  • James
  • UW-imap

Перенос почты в пакетном режиме

Создаем несложный скрипт imapsync_batch:

#!/bin/bash

{ while IFS=';' read  u1 p1 u2 p2; do
       imapsync --host1 mail.mbk-lab.ru --user1 "$u1" --password1 "$p1" \
                --host2 mail.test.tegu.online --user2 "$u2" --password2 "$p2" 
done ; } < file.txt

Очевидно, что скрипт построчно читает файл с параметрами, после чего вызываем imapsync с указанными параметрами.

Создаем файл параметров users.csv:

ikalmetov@mbk-lab.ru;МойПароль1;ikalmetov@test.tegu.online;МойПароль2
user002_1;password002_1;user002_2;password002_2
user003_1;password003_1;user003_2;password003_2

Остается выполнить:

imapsync_batch < users.csv

В финале вы получите что то похожее на это:

Host1 Total size:            2635716542 bytes (2.455 GiB)
Host2 Total size:            2561889417 bytes (2.386 GiB)

Host1 Biggest message:         34710913 bytes (33.103 MiB)
Host2 Biggest message:         34710913 bytes (33.103 MiB)

Time spent on sizing:         4.9 seconds
++++ Statistics
Transfer started on                     : Пятница 22 апреля 2022-04-22 10:55:20 +0300 MSK
Transfer ended on                       : Пятница 22 апреля 2022-04-22 13:04:25 +0300 MSK
Transfer time                           : 7744.8 sec
Folders synced                          : 11/11 synced
Messages transferred                    : 7354 
Messages skipped                        : 249
Messages found duplicate on host1       : 248
Messages found duplicate on host2       : 12
Messages found crossduplicate on host2  : 0
Messages void (noheader) on host1       : 0  
Messages void (noheader) on host2       : 0
Messages found in host1 not in host2    : 2 messages
Messages found in host2 not in host1    : 33 messages
Messages deleted on host1               : 0
Messages deleted on host2               : 0
Total bytes transferred                 : 2480216436 (2.310 GiB)
Total bytes skipped                     : 15442 (15.080 KiB)
Message rate                            : 0.9 messages/s
Average bandwidth rate                  : 312.7 KiB/s
Reconnections to host1                  : 0
Reconnections to host2                  : 2
Memory consumption at the end           : 335.7 MiB (started with 171.8 MiB)
Load end is                             : 1.61 1.34 1.02 1/1241 on 4 cores
CPU time and %cpu                       : 1679.15 sec 21.7 %cpu 5.4 %allcpus
Log file is LOG_imapsync/2022_04_22_10_55_20_476_ikalmetov@mbk-lab.ru_ikalmetov@test.tegu.online.txt

Скорость переноса

Очевидно, что на данный вопрос мы не можем ответить т.к. это зависит от пропускной способности конкретных каналов связи, производительности почтовых серверов и объемов почтовых сообщений. Тут вам придется поэкспериментировать самостоятельно.

9. Тестирование настроек сервера

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

Одна из таких сервисов:

10. Интеграция Dr.Web Mail Security Suite с почтовым севером Tegu по протоколу Milter

Преамбула

Почтовый сервер состоит из двух частей. MTA (Mail Transfer Agent – Агент Передачи) и MDA (Mail Delivery Agent – Агент Доставки). Задача MTA – пересылать (транспортировать) почту между серверами – ориентируясь на доменную часть он сначала находит в DNS список почтовых серверов, упорядочивает их согласно приоритету, и предпринимает попытки отправить сообщение. Иногда ему не удается сделать это с первого раза, в таком случае MTA повторяет попытки по определенному алгоритму. MTA также выполняет ряд процедур по проверке валидности серверов, с которыми он общается. Работа MTA считается выполненной когда удаленный сервер подтвердил прием сообщения, обоснованно отказался принять, либо по тайм-ауту (обычно это несколько дней).

MDA – ничего не пересылает, его задача получить письмо от MTA и положить в ящик пользователя, он также выдает почту пользовательским почтовым программам (MUA, Mail User Agent) по протоколам IMAP/POP. Это его задача организовать систему хранения, идексирования, поиска и выдачи, а также многое другое.

Итак, MTA – это почтовое отделение, а MDA – это почтальон. теперь нам понятно, что работа у каждого из них разная. Поэтому часто бывает, что и сами эти программы тоже разные и написаны разными людьми. К примеру в открытой архитектуре распространены такие MTA, как Postfix и Exim, а в качестве доставщика распространен Dovecot. А все вместе мы называем почтовым сервером.

Tegu – это современный почтовый сервер, который объединяет в себе и MTA, и MDA. Tegu запускает необходимое количество нужных в данный момент асинхронных процессов и контролирует из исполнение. При этом и на стороне MTA, и на стороне MDA могут работать различные правила и фильтры, которые мы предусмотрели.

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

Milter – это протокол название которого образуется из двух слов Mail и Filter. Это протокол, которому MTA передает сообщение до того, как передаст его на доставку или отправку.

Какими могут быть сервера для Milter-обработки? Чаще всего агенты Milter решают следующие задачи:

  • Проверка сообщений электронной почты на спам;
  • Проверка сообщение на вирусы;
  • Фильтрация нежелательных вложений;
  • Интеграция с DLP-системами;
  • Архивирование корреспонденции;
  • Сбор и сохранение статистики;
  • Добавление дисклеймеров;
  • Изменение маршрутизации;
  • Абсолютно любая ваша функция, которая выходит за рамки штатных возможностей.

На рисунке представлена схема встраивание протокола Milter в SMTP-сессию MTA почтового сервера Tegu

Работа по установке и настройке Milter-сервера Dr.Web Mail Security Suite состоит из двух этапов:

  1. Установка и настройка Dr.Web Mail Security Suite
  2. Настройка Tegu

10.1. Установка Dr.Web Mail Security Suite (для UNIX)

  1. Установите Dr.Web Mail Security Suite для UNIX согласно инструкции производителя;
  2. Включите Компонент Maild
  3. Настройте параметры транспортного соединения между MTA и Dr.Web
  4. Оптимизируйте Dr.Web, изучив алгоритм его работы в синхронном и асинхронном режимах (для высоконагруженных систем)

10.2. Настройка почтового сервера

Откройте настройки сервера Tegu:

1. Установить чекбокс "Enable antivirus and/or antispam scan" (Использовать Антивирус) в меню "Настройка" административной панели сервера Tegu;
2. Заполните поля host и port (3001)
3. Задайте название поля заголовка электронной почты для оценки спама. (в правилах обработки входящих писем этот заголовок будет использован в условии по рейтингу спама)

4. Для настройки обработки рейтинга спама, необходимо перейти в меню "Глобальные правила обработки входящих писем" и добавить правила обработки спама.

10.3. Программирование собственных сценариев обработки почтовых сообщений

В сервере Tegu есть несколько уровней настройки обработок почтовых сообщений на уровне администратора и пользователей. Однако, вы можете легко написать собственный сервер для обработки сообщений по протоколу Milter. Для этого существует свободные библиотеки на C, Python и др. Если вы используете Dr.Web Mail Security Suite для UNIX, то вам "из коробки" для программирования сценариев доступен язык LUA. Подробнее см. здесь

11. Нагрузочное тестирование почтового сервера

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

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

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

12. Сопровождение Tegu

Если вам необходима помощь, используйте:

12.1. Регламент техподдержки

Тарифы технической поддержки
Перечень услуг, входящих в техподдержку Базовый Стандартный Расширенный
Объем часов технической поддержки [часов] Безлимитно 20 Безлимитно
Обновления безопасности + + +
Доступ к "Справочному центру" + + +
Доступ к системе отслеживания ошибок (Bug tracker) + + +
Доступ к "Личному кабинету" + + +
Предоставление рецептов HowTo по отдельным сценариям использования + + +
Доступ к минорным версиям и обновлениям + + +
Консультации по установке и настройке + +
Анализ совместимости оборудования, при наличии технической возможности + +
Решение вопросов, связанных с совместимостью оборудования, при наличии технической возможности + +
Моделирование проблемных ситуаций на тестовом стенде, при наличии технической возможности + +
Удаленное подключение к системе пользователя для решения запроса +
Каналы приема запросов Web-портал Web-портал Web-портал, телефон
Выделенный менеджер +
Время обработки запросов Рабочие дни с 09:00 до 18:00 (МСК) Круглосуточно
Дополнительная опция
Техническая поддержка клиентского ПО, взаимодействующего с почтовым сервером Tegu 5 000 ₽/час 5 000 ₽/час 5 000 ₽/час
Время реакции
Уровень 1 Критическая ошибка 8 часов 4 часов
Уровень 2 Значительная ошибка 24 часа 12 часов
Уровень 3 Незначительная ошибка 5 дней 3 дней
Уровень 4 Консультации 8 часов 8 часов
Уровень 5 Пожелание (доработка) Разумные сроки Разумные сроки
Уровень критичности Описание
Уровень 1 Критическая ошибка Ошибка, при которой программный продукт не работоспособен.
Уровень 2 Значительная ошибка Ошибка, при которой поддерживаемый программный продукт в целом работоспособен. Но при этом одна (или несколько) из функций продукта не выполняется или выполняются с ограничениями, которые не позволяют использовать её по назначению.
Уровень 3 Незначительная ошибка Ошибка, при которой поддерживаемый программный продукт в целом работоспособен. Но при этом одна (или несколько) из его функций полностью не выполняется или выполняются с ограничениями, при этом для такой функции существует путь получения аналогичного результата другим способом.
Уровень 4 Консультации Ситуация, при которой поддерживаемый программный продукт выполняет свои документированные функции, но у пользователя есть вопросы по эксплуатации программного обеспечения.
Уровень 5 Пожелание (доработка) Пользователь высказывает разумные предложения по улучшению потребительских качеств поддерживаемого программного обеспечения или описывает отклонения от общепринятых стандартов.

Приложения

Приложение 1. Технологии защиты на примере Greylisting

Greylisting — способ автоматической блокировки спама, основанный на том, что поведение спамерского сервера, оптимизированного на рассылки, отличается от поведения обычных серверов электронной почты.

Сервер, который использует Greylisting, отклоняет любое письмо от неизвестного отправителя, но при этом запоминает адрес отправителя. Смаперский сервер не повторяет попытки доставки, не смотря на то, что так положено по протоколу SMTP. Правильный сервер согласно RFC повторит попытку. В этом случае принимающий сервер найдет адрес отправителя в своих серых списках и незамедлительно примет письмо.

Вот как это выглядит в логе почтового сервера Tegu.

Разберемся:

  • 18:25:20 - Входящее письмо с адреса . Tegu отказывается принять письмо и помещает адрес отправителя в серый список.
  • 18:31:37 - Повторная попытка отправки письма с адреса . Tegu нашел пару IP адрес и email отправителя в серых списках, поэтому перемещает адрес в белые списки и принимает письмо.
  • 18:31:51 - Обработка принятого письма завершена. Письмо доставлено получателю

Выводы:

  • На сколько же затормозится доставка почты? Очевидно, что точный ответ на данный вопрос дать невозможно т.к. это зависит не от Tegu, а от настроек отправляющего сервера. Обычно это несколько минут.
  • Обратите также внимание, что сессия в 18:25:20 была инициирована с вычислительной нодой tegu-node1, а в 18:31:37 балансировщик отправил трафик на ноду tegu-node2. Однако т.к. все сессии почтового кластера хранятся в единой БД, то вторая нода корректно отработала сессию, начатую первой нодой.
  • Как показывает практика, долю нежелательной почты, которую удаётся отсечь с помощью Greylisting, достаточно велика. При этом ощутимо снизится и почтовый трафик, т.к. в отличие от анализаторов спама приём спамерского сообщения не производится.
  • Greylisting исключает ложные срабатывания, когда добропорядочное письмо блокируется фильтром и не попадает к адресату.
  • Greylisting юридически чист. Блокирование почты на основании DNSBL, или прочтение почты анализаторами может вступить в определенное противоречие, но не Greylisting.

Приложение 2. Алгоритм обработки сессий SMTP

Tegu обладает максимально гибкой архитектурой.

Информация о всех объектах (их типах и размещении) хранится в базе данных конфигурации.
Выполняя свою работу, модули запрашивают в БД конфигурации необходимые параметры.
Коннекторы обеспечивают доступ к объектам в необходимом формате.

Рассмотрим алгоритм подробнее:

  1. Сессия SMTP начинается с блока Blacklist/Greylist, который получив IP адрес и домен сендера, проверяет их в базе данных конфигурации. Хранение данных конфигурации каждого домена возможно в нескольких вариантах. С этой целью менеджер базы данных конфигураций находит путь и выбирает соответствующий коннектор для подключения к локальной базе или СУБД.
  2. На этапе RCPT TO сервер должен выполнить авторизацию получателя. С этой целью процесс обращается к базе данных конфигураций (которых, как описано выше может быть несколько в разных хранилищах), находит тип и расположение одной из баз, которая хранит данные нужного пользователя и через соответствующий коннектор подключается к базе пользователей (таковыми могут быть любое количество локальных баз или LDAP3-серверов).
  3. Авторизовав пользователя и на этапе команды DATA сервер находит в конфигурации расположение антивирусного/антиспамового сервера и отправляет ему сообщение по протоколу Milter. Milter агент (сервер) выполняет проверку на вирусы, проверку на спам, а также выполняет любой кастомный сценарий обработки, написанный на языке LUA. В финале Milter-агент заполняет метрику и возвращает сообщение MTA.
  4. МТА определяет в базе конфигураций расположение очередей и помещает полученное сообщение в очередь на обработку.
  5. Очередь разбирает сообщения, выполняя для каждого сначала глобальные правила обработки (заданные администратором), затем локальные правила обработки (заданные пользователем). После передает сообщение на доставку.
  6. Процессы доставки определяют в базе конфигурации расположение хранилища для данного ящика, после чего осуществляет доставку (сохранение сообщение в ящике пользователя).

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

Благодаря такой архитектуре, Tegu поддерживает авторизацию по любому протоколу любого типа (количество неограничено), включая локальный (автономный) в формате JSON. А любой почтовый яшик может хранится в любом формате на любом хранилище.

Приложение 3. Административный интерфейс управления

В процессе установки при первом запуске сервер будет создан файл /etc/tegu.conf следующего содержания

[global]
dataDir = /opt/tegu/data
pluginDir = /opt/tegu/plugins

[WEB]
adminPassword = admin

Файл необходим для того, чтобы прочесть пароль администратора, сгенерированный автоматически. Это пароль используется для дальнейшего администрирования сервера с помощью веб-интерфейса, доступного по адресу https://mail.mbk-lab.ru:9999/

Меню "Настройка"

Меню "Провайдеры БД пользователей"

Сервер может содержать неограниченное количество провайдеров баз данных пользователей любого типа.

Провайдер базы данных пользователей LDAP

Провайдер базы данных пользователей JSON

Меню "Хранилище почты"

Хранилище почты может быть двух типов:

  • maildir
  • PostgreSQL

Меню "Очередь SMTP"

Приложение 4. Пример настройки провайдера подключения к серверу каталогов

Перед настройкой Провайдера БД пользователей проверьте, что вы создали Хранилище почты для целевого домена. В противном случае серверу негде создавать почтовй ящики. Конфигурация без хранилища может быть использована только для настройки релея.

Почтовый сервер Tegu, начиная с редакции Professional и выше поддерживает любое количество подключений к серверам каталогов LDAP версии 3 (в эту же категорию попадает и популярный Windows Active Directory).

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

Другими словами, мы оставляем за вами выбор механизма: создать или использовать существующее, важно понимать, что почтовому серверу необходимо явно объяснить какое поле как именно трактовать.

Рассмотрим учетную запись на картинке:

Обратите внимание:
  • В поле Адрес электронной почты внесен email-адрес пользователя (это ключевое поле);
  • В поле Номер факса внесена квота почтового ящика в Mb.

На следующей картинке мы видим логин указанного пользователя

Далее перейдем на консоль почтового сервера и в командной строке проверим правильность будущего подключения.
Для этого нам потребуется утилита ldapsearch .
Если у вас нет утилиты, то установите пакет ldap-utils примерно такой командой

sudo apt install ldap-utils

Синопсис команды:

ldapsearch -x -b <search_base> -H <ldap_host> -D <bind_dn> -W

В моем случае для подключения к LDAP получается следующая команда:

ldapsearch -x -b "DC=mbk,DC=lan" -H ldap://ldap.mbk-lab.ru:389

Вывод команды весьма интересен и многое говорит сам за себя.
Но мы с вами запросим информацию о конкретном пользователей *uid=ikalmetov *

$ ldapsearch -x -b "uid=ikalmetov,ou=People,DC=mbk,DC=lan" -H ldap://ldap.mbk-lab.ru:389
# extended LDIF
#
# LDAPv3
# base <uid=ikalmetov,ou=People,DC=mbk,DC=lan> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# ikalmetov, People, mbk.lan
dn: uid=ikalmetov,ou=People,dc=mbk,dc=lan
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
homeDirectory: /home/ikalmetov
loginShell: /bin/bash
uid: ikalmetov
uidNumber: 10001
gidNumber: 10000
title:: 0JjQvdC20LXQvdC10YA=
o:: 0JzQkdCaLdCb0LDQsQ==
mail: ikalmetov@mbk-lab.ru
sn:: 0JrQsNC70YzQvNC10YLQvtCy
givenName:: 0JjQs9C+0YDRjA==
cn:: 0JrQsNC70YzQvNC10YLQvtCyINCY0LPQvtGA0Yw=
jpegPhoto:: /9j/4AAQSkZJRgABAQAASABIAAD/7QByUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAD
 ocAVoAAxslRxwCAAACAAIcAigAFm0zTXV6VDhMVHNHQ0JLWCUwc0t4MEEcAhkAC1Bob3RvIEJvb3R
 Bh479yI1rrF7bn/9k=
facsimileTelephoneNumber: 10000

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Как трактовать этот вывод?

  • Почтовый сервер может обратиться к LDAP серверу ldap://ldap.mbk-lab.ru:389 с логином BindDN: cn=admin,dc=mbk,dc=lan и вашим паролем.
  • Определена область поиска BaseDNdc=mbk,dc=lan
  • Определено поле Attr for mailbox e-mail = mail
  • Определено поле Attr for mailbox quota (value in MB) = facsimileTelephoneNumber

Теперь переходим к настройке Провайдера БД пользователей в административном интерфейсе Tegu.

  • Поле Provider Name - любой текст, означающий имя подключения
  • Local Domain Name - имя домена (а не сервера т.е. то, что в email-адресе следует после @)
  • LDAP server connection URI - найденный и проверенный выше пусть к серверу
  • BindDN - логин
  • Password - пароль
  • BaseDN - найденный выше фильтр поиска
  • Atr for mailbox e-mail - название поля, которое в LDAP заполнено email-адресом пользователя (важно! с доменным суффиксом)
  • Atr for mailbox quota - название поля, которое в LDAP используется для определения квоты

На этом настройка интеграции с серверов каталогов завершена.
Остается только настроить почтовый клиент и проверить работу.

PS.

Уважаемые коллеги! В настоящий момент на сервере присутствует некоторое неудобство - настроенное в админке подключение к LDAP невозможно сразу же проверить. Этот недостаток будет исправлен в очередном релизе, а в соответствующем интерфейсе настройки появится кнопка "Тест LDAP connection", возвращающая результат.

Обновлено Кальметов Игорь 3 месяца назад · 24 изменени(я, ий)