Инструкция по установке и эксплуатации
почтовых серверов Tegu, Tegu Professional, Tegu Enterprise версии 1.15.0
- Содержание
- 1. Введение, функциональные возможности и выбор редакции Tegu
- 2. Инструкция по установке почтового сервера Tegu
- Преамбула
- 2.1. Настройка доменной зоны
- 2.2. Установка сервера
- 2.3. Настройка параметров сервера
- 2.4. Обновление почтового сервера
- 2.5. Более точные настройки сервера
- 2.6. Проверка настроек сервера
- 2.7. Установка и генерация сертификатов Letsencrypt.
- Автоматизируем обновление сертификатов скриптами:
- 2.8 Интеграция с Active Directory и OpenLDAP.
- 3. Инструкция по установке Web клиента Nextcloud.
- 3.1. Преамбула.
- 3.2. Подготовительные работы.
- 3.3. Установка базы данных Postres.
- 3.3.1. Конфигурируем компоненты Postgres
- 3.4. Установка модулей PHP + Apache
- 3.5. Установка Nextcloud.
- 3.6. Настройка Apache.
- 3.7. Продолжаем установку в Web интерфейсе
- 3.8. Дополнительные настройки.
- 3.9. Публикация конфигурации для Apache Reverse Proxy
- 3.10. Полезные команды при настройке и отладке Nextcloud.
- 3.11. Интеграция с LDAP / AD.
- 3.12 Настройка интеграции Nextcloud с LDAP из командной строки.
- 3.13. Установка и настройка Rainloop
- 3.14 Установка Onlyoffice.
- 3.14.1 Подготовительные работы.
- 3.14.2 Настройка и установка системной локали по умолчанию.
- 3.14.3 Установка, настройка и изменение часового пояса
- 3.14.4 Устанавливаем совместимую с дистрибутивом базу данных PostgreSQL:
- 3.14.5 Подключаемся к PostgreSQL
- 3.14.6 Создаем пользователя и базу для onlyoffice
- 3.14.7 Устанавливаем брокер сообщений RabbitMQ:
- 3.14.8 Устанавливаем дополнения веб-сервера nginx-extras:
- 3.14.9 Обновляем пакетный менеджер:
- 3.14.10 Устанавливаем пакет стандартных шрифтов майкрософт:
- 3.14.11 Проверка работоспособности серверной части.
- 3.14.12 Установка клиентской части и интеграция с nextcloud.
- 3.15 Настрока Apache Revers Proxy для работы сервера через протокол HTTPS.
- 3.16. Вопросы и ответы
- 4. Установка по установке кластера СУБД высокой доступности Master-Slave
- 5. Организация балансировки вычислительных нод Tegu
- 6. Инструкция по эксплуатации почтового сервера Tegu
- 6.1. Введение
- 6.2. Управление с помощью административного веб-интерфейса
- 6.3. Управление с помощью командной строки
- 6.4. Глобальные правила обработки почтовых сообщений
- 6.5. Системные журналы
- 6.6. Резервное копирование и восстановление
- 6.7. Защита
- 6.8. Проверка настроек сервера
- 7. Настройка клиентского ПО
- 8. Миграция почтовых серверов
- 9. Тестирование настроек сервера
- 10. Интеграция Dr.Web Mail Security Suite с почтовым севером Tegu по протоколу Milter
- 11. Нагрузочное тестирование почтового сервера
- 12. Сопровождение Tegu
- Приложения
- Приложение 1. Технологии защиты на примере Greylisting
- Приложение 2. Алгоритм обработки сессий SMTP
- Приложение 3. Административный интерфейс управления
- Приложение 4. Пример настройки провайдера подключения к серверу каталогов
1. Введение, функциональные возможности и выбор редакции Tegu¶
- Содержание
- 1. Введение, функциональные возможности и выбор редакции Tegu
- 2. Инструкция по установке почтового сервера Tegu
- Преамбула
- 2.1. Настройка доменной зоны
- 2.2. Установка сервера
- 2.3. Настройка параметров сервера
- 2.4. Обновление почтового сервера
- 2.5. Более точные настройки сервера
- 2.6. Проверка настроек сервера
- 2.7. Установка и генерация сертификатов Letsencrypt.
- Автоматизируем обновление сертификатов скриптами:
- 2.8 Интеграция с Active Directory и OpenLDAP.
- 3. Инструкция по установке Web клиента Nextcloud.
- 3.1. Преамбула.
- 3.2. Подготовительные работы.
- 3.3. Установка базы данных Postres.
- 3.3.1. Конфигурируем компоненты Postgres
- 3.4. Установка модулей PHP + Apache
- 3.5. Установка Nextcloud.
- 3.6. Настройка Apache.
- 3.7. Продолжаем установку в Web интерфейсе
- 3.8. Дополнительные настройки.
- 3.9. Публикация конфигурации для Apache Reverse Proxy
- 3.10. Полезные команды при настройке и отладке Nextcloud.
- 3.11. Интеграция с LDAP / AD.
- 3.12 Настройка интеграции Nextcloud с LDAP из командной строки.
- 3.13. Установка и настройка Rainloop
- 3.14 Установка Onlyoffice.
- 3.14.1 Подготовительные работы.
- 3.14.2 Настройка и установка системной локали по умолчанию.
- 3.14.3 Установка, настройка и изменение часового пояса
- 3.14.4 Устанавливаем совместимую с дистрибутивом базу данных PostgreSQL:
- 3.14.5 Подключаемся к PostgreSQL
- 3.14.6 Создаем пользователя и базу для onlyoffice
- 3.14.7 Устанавливаем брокер сообщений RabbitMQ:
- 3.14.8 Устанавливаем дополнения веб-сервера nginx-extras:
- 3.14.9 Обновляем пакетный менеджер:
- 3.14.10 Устанавливаем пакет стандартных шрифтов майкрософт:
- 3.14.11 Проверка работоспособности серверной части.
- 3.14.12 Установка клиентской части и интеграция с nextcloud.
- 3.15 Настрока Apache Revers Proxy для работы сервера через протокол HTTPS.
- 3.16. Вопросы и ответы
- 4. Установка по установке кластера СУБД высокой доступности Master-Slave
- 5. Организация балансировки вычислительных нод Tegu
- 6. Инструкция по эксплуатации почтового сервера Tegu
- 6.1. Введение
- 6.2. Управление с помощью административного веб-интерфейса
- 6.3. Управление с помощью командной строки
- 6.4. Глобальные правила обработки почтовых сообщений
- 6.5. Системные журналы
- 6.6. Резервное копирование и восстановление
- 6.7. Защита
- 6.8. Проверка настроек сервера
- 7. Настройка клиентского ПО
- 8. Миграция почтовых серверов
- 9. Тестирование настроек сервера
- 10. Интеграция Dr.Web Mail Security Suite с почтовым севером Tegu по протоколу Milter
- 11. Нагрузочное тестирование почтового сервера
- 12. Сопровождение Tegu
- Приложения
- Приложение 1. Технологии защиты на примере Greylisting
- Приложение 2. Алгоритм обработки сессий SMTP
- Приложение 3. Административный интерфейс управления
- Приложение 4. Пример настройки провайдера подключения к серверу каталогов
1.1. Что такое Tegu¶
Tegu – это линейка полностью отечественных современных почтовых серверов, масштабируемых от начального уровня до уровня кластеров для построения корпоративных и облачных почтовых систем.
Cерверы Tegu позволяют получить единое интегрированное решение для организации почтового сервиса, адресных книг, календарей, мгновенных сообщений, хранения и редактирования документов. Сервер поддерживает все стандартные десктопные и мобильные приложения, однако для работы с ним достаточно только браузера.
Базовая версия разрабатывается и распространяется согласно лицензии FreeWare, остальные редакции поставляются по собственным коммерческим лицензиям.
Tegu в состоянии работать как автономно (standalone), так и в интеграции со множеством контроллеров LDAP/MS Active Directory, а также в виде мультисерверного кластера, что делает решение отказоустойчивым и масштабируемым.
Tegu распростаняется на базе ОС Linux и полностью совместим с отечественными ОС, для каждой из которых поддерживается собственная сборка.
Весь процесс мониторинга и управления сервером осуществляется через веб-панель администрирования и не требует знания Linux.
1.2. Какие почтовые клиенты работают с Tegu¶
Tegu реализует только открытые (стандартные) почтовые протоколы (IMAP, SMTP, CalDAV, 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 Professional | Tegu Enterprise |
---|---|---|---|
Лицензия | FreeWare | Коммерческая | Коммерческая |
Исходный код | + | ||
Регистрация в Росреестре | Запись в реестре №9811 от 18.03.2021 | Запись в реестре №10882 от 23.06.2021 | Запись в реестре №10820 от 25.06.2021 |
Подтвержденная совместимость с отечественными ОС | ALT Linux, РЕД ОС | ||
Стоимость | Вы также можете воспользоваться всегда актуальной веб-версией прайса, опубликованной на официальном сайте: * Tegu Professional * Tegu Enterprise |
||
Электронная почта | |||
Поддержка нескольких интернет-доменов | + | + | + |
Служба приёма/отправки сообщений 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 Professional
- Аутентификация через LDAP/MS Active Directory с неограниченным количество доменных контроллеров различного типа
- Tegu Enterprise
- Отказоустойчивый мультисерверный кластер
1.4.2.2. Tegu Professional¶
Tegu Professional - это полностью отечественный современный почтовый сервер корпоративного уровня, работающий в среде ОС Linux, распространяемый под собственной лицензией. Сервер позволяет организовать обмен с любыми почтовыми серверами по протоколу SMTP, а также поддерживает почтовых клиентов по протоколу IMAP/SMTP. Авторизация почтовых клиентов осуществляется с помощью неограниченного количества контроллеров домена. Сервер отличает простота установки и удобство администрирования через веб-интерфейс.
Отличия данной редакции
- Аутентификация через LDAP/MS Active Directory с неограниченным количество доменных контроллеров различного типа
Базовые функции
- Базовые свойства
- Поддержка любого количества интернет-доменов
- Распределенное администрирование пользователей
- Протоколы
- IMAPs
- SMTPs
- CalDav
- CardDav
- HTTPs
- Аутентификация
- Поддержка локальной БД пользователей (JSON с иерархией групп)
- Аутентификация LDAP/MS Active Directory (количество и тип серверов каталога неограничено)
- Хранилище почты
- Локальной в формате Maildir (ускоренный механизм инжексации)
- Безопасность
- Система проверки политики домена для отправителя (SPF)
- Подпись DKIM для исходящих писем
- Фильтрация GreyListing
- Черные списки
- Белые списки
- Интеграции с антивирусными и антиспамовыми системами Kaspersky и Dr.Web по протоколу Milter
- Топология
- Автономный сервер (Standalone)
- Трехуровневая схема
- Интерфейс
- Веб-интерфейс администратора (полный)
- Веб-интерфейс пользователя (почта, календари, адресные книги, облачное хранение файлов)
- Поддержка любых стандартных десктопных и мобильных клиентов
- Обработки
- Глобальная система обработки входящих писем и событий в соответствии с правилами (настраивается администратором)
- Система обработки входящих писем в соответствии с правилами на уровне пользователя
- Квотирование
- Поддержка мастер-пользователей (количество неограничено)
- Поддержка алиасов и групп рассылок
- Резервное копирование
- Полное
- Гранулированное
- Поддерживаемые ОС
- Linux (glibc 2.28+),
- ALT Linux,
- RedOS,
- AstraLinux
- Поддерживаемые аппаратные архитектуры
- x86_64
- AArch64 (ARM64)
Функции старших редакций
- Tegu Enterprise
- Отказоустойчивый мультисерверный кластер
Топология
1.4.2.4. Tegu Enterprise¶
Tegu Enterprise - это полностью отечественный современный отказоустойчивый мультисерверный почтовый сервер, работающий в среде ОС Linux, распространяемый под собственной лицензией. Сервер позволяет организовать обмен с любыми почтовыми серверами по протоколу SMTP, а также поддерживает почтовых клиентов по протоколу IMAP/SMTP. Сервер отличает простота установки и удобство администрирования через веб-интерфейс.
Отличия данной редакции
- Отказоустойчивый мультисерверный кластер
Базовые функции
- Базовые свойства
- Поддержка любого количества интернет-доменов
- Распределенное администрирование пользователей
- Протоколы
- 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.4.3. Простейший алгоритм выбора редации Tegu¶
Ответьте на вопрос | Tegu (FreeWare) | Tegu Professional | Tegu Enterprise |
---|---|---|---|
Количество пользователей не превышает 3000 и доменная авторизация не нужна (standalone server) | + | ||
Мне нужна доменная авторизация, количество пользователей не превышает 3000 | + | ||
Мне необходимо отказоустойчивое решение на базе симметричного кластера либо количество пользователей более 3000 | + |
1.5. Как получить дистрибутив¶
- Скачать редакции сервера можно здесь
- Вы можете также:
- запросить пробную версию (лицензия на 30 дней);
- заказать тестирование на нашем стенде,
Информация будет выслана вам на указанный email.
- Вы можете подписаться на канал рассылки по email на обновления вашей версии Tegu, либо отслеживать обновления на сайте
1.6. Лицензионное соглашение¶
Вы можете ознакомиться с Лицензионным соглашением с конечным пользователем , а также прочесть Политику обработки персональных данных
2. Инструкция по установке почтового сервера Tegu¶
- Содержание
- 1. Введение, функциональные возможности и выбор редакции Tegu
- 2. Инструкция по установке почтового сервера Tegu
- Преамбула
- 2.1. Настройка доменной зоны
- 2.2. Установка сервера
- 2.3. Настройка параметров сервера
- 2.4. Обновление почтового сервера
- 2.5. Более точные настройки сервера
- 2.6. Проверка настроек сервера
- 2.7. Установка и генерация сертификатов Letsencrypt.
- Автоматизируем обновление сертификатов скриптами:
- 2.8 Интеграция с Active Directory и OpenLDAP.
- 3. Инструкция по установке Web клиента Nextcloud.
- 3.1. Преамбула.
- 3.2. Подготовительные работы.
- 3.3. Установка базы данных Postres.
- 3.3.1. Конфигурируем компоненты Postgres
- 3.4. Установка модулей PHP + Apache
- 3.5. Установка Nextcloud.
- 3.6. Настройка Apache.
- 3.7. Продолжаем установку в Web интерфейсе
- 3.8. Дополнительные настройки.
- 3.9. Публикация конфигурации для Apache Reverse Proxy
- 3.10. Полезные команды при настройке и отладке Nextcloud.
- 3.11. Интеграция с LDAP / AD.
- 3.12 Настройка интеграции Nextcloud с LDAP из командной строки.
- 3.13. Установка и настройка Rainloop
- 3.14 Установка Onlyoffice.
- 3.14.1 Подготовительные работы.
- 3.14.2 Настройка и установка системной локали по умолчанию.
- 3.14.3 Установка, настройка и изменение часового пояса
- 3.14.4 Устанавливаем совместимую с дистрибутивом базу данных PostgreSQL:
- 3.14.5 Подключаемся к PostgreSQL
- 3.14.6 Создаем пользователя и базу для onlyoffice
- 3.14.7 Устанавливаем брокер сообщений RabbitMQ:
- 3.14.8 Устанавливаем дополнения веб-сервера nginx-extras:
- 3.14.9 Обновляем пакетный менеджер:
- 3.14.10 Устанавливаем пакет стандартных шрифтов майкрософт:
- 3.14.11 Проверка работоспособности серверной части.
- 3.14.12 Установка клиентской части и интеграция с nextcloud.
- 3.15 Настрока Apache Revers Proxy для работы сервера через протокол HTTPS.
- 3.16. Вопросы и ответы
- 4. Установка по установке кластера СУБД высокой доступности Master-Slave
- 5. Организация балансировки вычислительных нод Tegu
- 6. Инструкция по эксплуатации почтового сервера Tegu
- 6.1. Введение
- 6.2. Управление с помощью административного веб-интерфейса
- 6.3. Управление с помощью командной строки
- 6.4. Глобальные правила обработки почтовых сообщений
- 6.5. Системные журналы
- 6.6. Резервное копирование и восстановление
- 6.7. Защита
- 6.8. Проверка настроек сервера
- 7. Настройка клиентского ПО
- 8. Миграция почтовых серверов
- 9. Тестирование настроек сервера
- 10. Интеграция Dr.Web Mail Security Suite с почтовым севером Tegu по протоколу Milter
- 11. Нагрузочное тестирование почтового сервера
- 12. Сопровождение Tegu
- Приложения
- Приложение 1. Технологии защиты на примере Greylisting
- Приложение 2. Алгоритм обработки сессий SMTP
- Приложение 3. Административный интерфейс управления
- Приложение 4. Пример настройки провайдера подключения к серверу каталогов
Мы написали для вас качественный код, а также написали эту инструкцию чтобы облегчить вам работу.
Пожалуйста прочтите эту документацию перед началом работ с Tegu.
Преамбула¶
Сервер написан на языке Golang и представляет собой один единственный исполняемый файл, который вы скачиваете для выбранной аппаратной архитектуры. Лицензия не ограничивает вас в выборе или смене аппаратной архитектуры.
Допускается использование Tegu на любом Линукс дистрибутиве, версия библиотеки GLIBC которого не ниже 2.28. В сложившейся ситуации приоритет разумеется отдается использованию отечественных ОС.
- Перед началом работ обратите внимание на настройку DNS-зоны. Правильно настроенная зона - это важнейшая половина работы. При этом настроить надо не только MX-запись, но и записи SPF и DKIM. Мы рекомендуем проводить тестирование каждого выполненного этапа работ. На страницах нашего сайта и в интернете вы можете найти массу сервисов и утилит для проверки настройки DNS-зон. Тестирование зон сэкономит ваше время на следующих этапах.
- Второе, что необходимо выполнить предварительно, подготовить сертификат будущего сервера, который используется для шифрования протоколов. Использование самоподписанных сертификатов вызовет ошибку.
- Некоторые дистрибутивы операционных систем содержат и по умолчанию запускают собственный почтовый сервер. К примеру на борту Alt Server уже установлен сервер postfix. Во избежание конфликта сетевых портов необходимо предварительно остановить или удалить ненужный сервер.
- Установка Tegu представляет собой по сути простое копирование исполняемого файла в заданную вами директорию. Чтобы программа могла выполняться и слушать заданные порты необходимо выполнять команду setcap (setcap необходимо также выполнять при обновлении дистрибутива).
Этого достаточно чтобы выполнить запуск сервера системой systemd. - При первом запуске сервер сформирует конфигурационный файл tegu.conf, в котором вы найдете сгенерированный административный пароль, с помощью которого сможете войти в веб-интерфейс настройки сервера. Все дальнейшие настройки можно выполнить в удобном GUI-интерфейсе.
- Контролируйте работу сервера с помощью команды journalctl -f -u tegu -n 100
- Итак, вы выполнили подготовительные этапы и запустили сервер (команда systemctl status tegu.service возвращает вам успешный статус). Самое время перейти к настройке. Ваш сервер может обслуживать любое количество интернет-доменов, но при этом надо соблюдать правило. Для каждого интернет домена необходимо создать хранилище почты (одно для каждого интернет-домена). Количество хранилищ не ограничено, каждое из них может быть двух типов: локальное в формате maildir, централизованное в СУБД Postgress. Источник Postgress роли не играет (ванильная, либо отечественная PosgresPro), версия - не ниже 13.
- Создав хранилище, необходимо выполнить создание провайдеров базы данных пользователей. Сервер может использовать любое количество собственных баз пользователей, а также подключения к любому количеству серверов каталогов любого типа (Windows AD, Samba4, FreeIPA etc). Другими словами, пользователи одного интернет-домена могут находиться на разных серверах каталогов, а также в локальной базе данных Tegu.
- Финальным этапом является подключение интивирусных/антиспамовых систем, либо 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
Создаем структуру каталогов для сервера:
$ mkdir /opt/tegu $ mkdir /opt/tegu/{bin,sbin,data,certs}
Копируем исполняемый файл в рабочий каталог:
$ cp tegu-free-v1.17.20-x86_64/sbin/* /opt/tegu/sbin/ $ cp tegu-free-v1.17.20-x86_64/bin/* /opt/tegu/bin/
Назначаем пользователя и права:
$ chown -R mail. /opt/tegu/{data,certs} $ chgrp -R mail /opt/tegu/{bin,sbin} $ chmod 750 /opt/tegu/{data,certs} $ chmod -R 750 /opt/tegu/sbin $ chmod -R 750 /opt/tegu/bin
Проверяем правильность создания каталогов и файлов, а также их прав:
$ ls -l /opt/tegu
Должно быть примерно так:
$ ls -l /opt/tegu /opt/tegu: итого 16 drwxr-x--- 2 root mail 4096 апр 11 14:32 bin drwxr-x--- 2 mail mail 4096 апр 11 14:32 certs drwxr-x--- 2 mail mail 4096 апр 11 14:32 data drwxr-x--- 2 root mail 4096 апр 11 14:33 sbin
Настраиваем механизм запуска и управления:
$ nano /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
Разрешаем запуск сервера от имени непривелегированного пользователя
$ setcap CAP_NET_BIND_SERVICE=+eip /opt/tegu/sbin/tegu
Необходимо создать конфигурационный файл в /etc/tegu.conf со следующим содержанием:
$ nano /etc/tegu.conf [global] dataDir = /opt/tegu/data [Log] debug = true [WEB] adminPassword = admin httpPort = 8888 httpsPort = 9999 ctlPort = 8899
И сменить права:
chown root.mail /etc/tegu.conf
chmod 640 /etc/tegu.conf
Во время первого запуска сервер будет искать свой файл конфигурации в следующем порядке:
- /etc/tegu.conf
- ~/tegu.conf (например, /var/mail/tegu.conf)
Если файл не был найден, то он будет создан по пути ~/tegu.conf
Для подробного логирования работы сервера измените значение параметра
debug = true
Значение параметра adminPassword используйте для регистрации в административном веб-интерфейсе (с логином admin). Читайте об этом подробнее в разделе "Настройка"
Разрешаем автозапуск сервера во время загрузки ОС
$ 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
Проверить занимаемые программой порты можно командой:
netstat -tulpn | grep tegu
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.
Права на катологи должны быть такими:
drwxr-x---
Выполним это с помощью команд:
$ mkdir /var/mail/test2 $ find /var/mail/test2 -type d -exec chmod 750 {} \;
Права на файлы должны быть такими:
-rw-r-----
которые устанавливаются командой
find /var/mail/test2 -type f -exec chmod 640 {} \;
Владелец и группа должны быть те, от которых запускается сервис tegu.
Например, mail.mail, которые устанавливаются командой
chown -R mail.mail /var/mail/test2
Для создания хранилища укажите:
- Local mail domain name - интернет-домен, для которого создается хранилище
- Root directory path of mail - каталог для хранения почты выбранного домена.
Завершив настройку, нажмите кнопку Добавить
Хранилище будет создано и вы попадете в диалог добавления нового хранилища.
2.3.2. Создание почтового хранилища СУБД¶
Как было сказано выше, если вы используете редакцию Tegu Enterprise, то вы можете создать хранилище почты в СУБД. С Tegu совместима любая версия от отечественного вендора PosgresPro , либо свободная версия от PostgeSQL . (версия - не ниже 13)
Создаем пользователя:
createuser -d -S -E -P postgres
Создаем 3 базы данных.¶
tegu_queue -база данных очередей
tegu_mailboxes - база данных почтового хранилища
tegu_settings - база данных настроек почтового сервера
createdb -E UTF-8 -O postgres tegu_queue
createdb -E UTF-8 -O postgres tegu_mailboxes
createdb -E UTF-8 -O postgres tegu_settings
Прописываем доступы с подсетей.¶
nano /var/lib/pgsql/data/pg_hba.conf
Смотрим какие базы данных у нас есть.¶
psql -U postgres -c "\l+"
Удалить базы данных.¶
psql DROP DATABASE tegu_mailboxes;
Для создания хранилища в корневом меню выбираем Хранилища почты
Установка сервера БД производится согласно официальной документации Postgre . По окончании установки вам необходимо создать пользователя с правами создания баз, которым будет пользоваться сервер Tegu, а также необходимо создать две базы
- для хранения почты
- для хранения конфигурации.
и, если необходимо
- для очереди сообщений SMTP
Для всех БД пользователь этих БД должен иметь в них право CREATE.
Оптимизация БД, а также сборка отказоустойчивого решения БД, выходит за рамки установки почтового сервера и рассматривается в каждом конкретном случае по запросу. Интерес также представляет создание отказоустойчивой конфигурации базы данных, рассмотренное в данной статье .
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. Обновление почтового сервера¶
Останавливаем на всех нодах почтовый сервис.¶
systemctl stop tegu.service
переходим в папку opt
cd /opt
Скачиваем дистрибутив tegu¶
Распаковываем.¶
tar xvzf tegu-ent-v1.19.44-x86_64.tar.gz
h3.Переходим в распакованную папку
cd /opt/tegu-ent-v1.19.44-x86_64
Копируем содержимое папки bin¶
cp bin/* /opt/tegu/bin/
Консоль спросит: перезаписать содержимое, отвечаем да (y)
Копируем содержимое sbin¶
cp sbin/* /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
выведет всю конфигурацию сервера в тестовом формате.
Утилита teguctl поставляется с дистрибутивом (вы найдете ее в каталоге bin).
2.7. Установка и генерация сертификатов Letsencrypt.¶
Проверяем обновления пакетов
apt update
Устанавливаем Letsencrypt
apt install certbot
Получаем сертификат на свой почтовый домен
certbot certonly --standalone -m ваша_почта@yandex.ru -d mail.вашдомен.рф
Проверяем что сертификаты получены
cd /etc/letsencrypt/live/mail.вашдомен.рф/ ls
должны увидеть следующие файлы:
cert.pem chain.pem fullchain.pem privkey.pem README
Нас интересуют fullchain.pem privkey.pem
Автоматизируем обновление сертификатов скриптами:¶
создаем папку work в папке root она нам чуть позже пригодится
mkdir work
Создаем в папке Letsencrypt hook со следующим содержанием:
nano /etc/letsencrypt/renewal-hooks/deploy/hook01
#!/bin/sh do if [ "$domain" = mail.вашдомен.рф ] then /root/work/tegu_certs /bin/systemctl restart tegu fi done
Делаем его исполняемым
chmod +x /etc/letsencrypt/renewal-hooks/deploy/hook01
Далее создаем еще один скрипт
nano /root/work/tegu_certs
и прописываем в нем следующие строки
#!/bin/bash cat /etc/letsencrypt/live/mail.вашдомен.рф/fullchain.pem > /opt/tegu/certs/cert.pem cat /etc/letsencrypt/live/mail.вашдомен.рф/privkey.pem > /opt/tegu/certs/key.pem chgrp mail /opt/tegu/certs/* chmod 640 /opt/tegu/certs/*
Делаем скрипт исполняемым
chmod +x /root/work/tegu_certs
Меняем группу владельцев
chgrp root /etc/letsencrypt/archive/mail.вашдомен.рф/*
Запускаем скрипт
/root/work/tegu_certs
Проверяем результат отрабатывания скрипта
ls -lh /opt/tegu/certs/
В этой папке должны появится сертификаты
cert.pem key.pem
Соответственно в основных настройках почтового сервера мы указываем следующие пути к сертификатам.
/opt/tegu/certs/cert.pem /opt/tegu/certs/key.pem
Должно получиться так.
После того как сертификаты сгенерированы и прописаны на почтовом сервере, в основных настройках необходимо включить опцию "Требовать шифрования TLS/SSL для авторизации"
Перезапустим почтовый сервер:
systemctl restart tegu
После того как все настройки выполнены только теперь можно проверять какие порты слушает почтовый сервер.
netstat -lnp
2.8 Интеграция с Active Directory и OpenLDAP.¶
Пример настроек для подключения к Active Directory.¶
Пример настроек для подключения к OpenLDAP.¶
3. Инструкция по установке Web клиента Nextcloud.¶
- Содержание
- 1. Введение, функциональные возможности и выбор редакции Tegu
- 2. Инструкция по установке почтового сервера Tegu
- Преамбула
- 2.1. Настройка доменной зоны
- 2.2. Установка сервера
- 2.3. Настройка параметров сервера
- 2.4. Обновление почтового сервера
- 2.5. Более точные настройки сервера
- 2.6. Проверка настроек сервера
- 2.7. Установка и генерация сертификатов Letsencrypt.
- Автоматизируем обновление сертификатов скриптами:
- 2.8 Интеграция с Active Directory и OpenLDAP.
- 3. Инструкция по установке Web клиента Nextcloud.
- 3.1. Преамбула.
- 3.2. Подготовительные работы.
- 3.3. Установка базы данных Postres.
- 3.3.1. Конфигурируем компоненты Postgres
- 3.4. Установка модулей PHP + Apache
- 3.5. Установка Nextcloud.
- 3.6. Настройка Apache.
- 3.7. Продолжаем установку в Web интерфейсе
- 3.8. Дополнительные настройки.
- 3.9. Публикация конфигурации для Apache Reverse Proxy
- 3.10. Полезные команды при настройке и отладке Nextcloud.
- 3.11. Интеграция с LDAP / AD.
- 3.12 Настройка интеграции Nextcloud с LDAP из командной строки.
- 3.13. Установка и настройка Rainloop
- 3.14 Установка Onlyoffice.
- 3.14.1 Подготовительные работы.
- 3.14.2 Настройка и установка системной локали по умолчанию.
- 3.14.3 Установка, настройка и изменение часового пояса
- 3.14.4 Устанавливаем совместимую с дистрибутивом базу данных PostgreSQL:
- 3.14.5 Подключаемся к PostgreSQL
- 3.14.6 Создаем пользователя и базу для onlyoffice
- 3.14.7 Устанавливаем брокер сообщений RabbitMQ:
- 3.14.8 Устанавливаем дополнения веб-сервера nginx-extras:
- 3.14.9 Обновляем пакетный менеджер:
- 3.14.10 Устанавливаем пакет стандартных шрифтов майкрософт:
- 3.14.11 Проверка работоспособности серверной части.
- 3.14.12 Установка клиентской части и интеграция с nextcloud.
- 3.15 Настрока Apache Revers Proxy для работы сервера через протокол HTTPS.
- 3.16. Вопросы и ответы
- 4. Установка по установке кластера СУБД высокой доступности Master-Slave
- 5. Организация балансировки вычислительных нод Tegu
- 6. Инструкция по эксплуатации почтового сервера Tegu
- 6.1. Введение
- 6.2. Управление с помощью административного веб-интерфейса
- 6.3. Управление с помощью командной строки
- 6.4. Глобальные правила обработки почтовых сообщений
- 6.5. Системные журналы
- 6.6. Резервное копирование и восстановление
- 6.7. Защита
- 6.8. Проверка настроек сервера
- 7. Настройка клиентского ПО
- 8. Миграция почтовых серверов
- 9. Тестирование настроек сервера
- 10. Интеграция Dr.Web Mail Security Suite с почтовым севером Tegu по протоколу Milter
- 11. Нагрузочное тестирование почтового сервера
- 12. Сопровождение Tegu
- Приложения
- Приложение 1. Технологии защиты на примере Greylisting
- Приложение 2. Алгоритм обработки сессий SMTP
- Приложение 3. Административный интерфейс управления
- Приложение 4. Пример настройки провайдера подключения к серверу каталогов
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¶
- Содержание
- 1. Введение, функциональные возможности и выбор редакции Tegu
- 2. Инструкция по установке почтового сервера Tegu
- Преамбула
- 2.1. Настройка доменной зоны
- 2.2. Установка сервера
- 2.3. Настройка параметров сервера
- 2.4. Обновление почтового сервера
- 2.5. Более точные настройки сервера
- 2.6. Проверка настроек сервера
- 2.7. Установка и генерация сертификатов Letsencrypt.
- Автоматизируем обновление сертификатов скриптами:
- 2.8 Интеграция с Active Directory и OpenLDAP.
- 3. Инструкция по установке Web клиента Nextcloud.
- 3.1. Преамбула.
- 3.2. Подготовительные работы.
- 3.3. Установка базы данных Postres.
- 3.3.1. Конфигурируем компоненты Postgres
- 3.4. Установка модулей PHP + Apache
- 3.5. Установка Nextcloud.
- 3.6. Настройка Apache.
- 3.7. Продолжаем установку в Web интерфейсе
- 3.8. Дополнительные настройки.
- 3.9. Публикация конфигурации для Apache Reverse Proxy
- 3.10. Полезные команды при настройке и отладке Nextcloud.
- 3.11. Интеграция с LDAP / AD.
- 3.12 Настройка интеграции Nextcloud с LDAP из командной строки.
- 3.13. Установка и настройка Rainloop
- 3.14 Установка Onlyoffice.
- 3.14.1 Подготовительные работы.
- 3.14.2 Настройка и установка системной локали по умолчанию.
- 3.14.3 Установка, настройка и изменение часового пояса
- 3.14.4 Устанавливаем совместимую с дистрибутивом базу данных PostgreSQL:
- 3.14.5 Подключаемся к PostgreSQL
- 3.14.6 Создаем пользователя и базу для onlyoffice
- 3.14.7 Устанавливаем брокер сообщений RabbitMQ:
- 3.14.8 Устанавливаем дополнения веб-сервера nginx-extras:
- 3.14.9 Обновляем пакетный менеджер:
- 3.14.10 Устанавливаем пакет стандартных шрифтов майкрософт:
- 3.14.11 Проверка работоспособности серверной части.
- 3.14.12 Установка клиентской части и интеграция с nextcloud.
- 3.15 Настрока Apache Revers Proxy для работы сервера через протокол HTTPS.
- 3.16. Вопросы и ответы
- 4. Установка по установке кластера СУБД высокой доступности Master-Slave
- 5. Организация балансировки вычислительных нод Tegu
- 6. Инструкция по эксплуатации почтового сервера Tegu
- 6.1. Введение
- 6.2. Управление с помощью административного веб-интерфейса
- 6.3. Управление с помощью командной строки
- 6.4. Глобальные правила обработки почтовых сообщений
- 6.5. Системные журналы
- 6.6. Резервное копирование и восстановление
- 6.7. Защита
- 6.8. Проверка настроек сервера
- 7. Настройка клиентского ПО
- 8. Миграция почтовых серверов
- 9. Тестирование настроек сервера
- 10. Интеграция Dr.Web Mail Security Suite с почтовым севером Tegu по протоколу Milter
- 11. Нагрузочное тестирование почтового сервера
- 12. Сопровождение Tegu
- Приложения
- Приложение 1. Технологии защиты на примере Greylisting
- Приложение 2. Алгоритм обработки сессий SMTP
- Приложение 3. Административный интерфейс управления
- Приложение 4. Пример настройки провайдера подключения к серверу каталогов
Организация балансировки вычислительных нод 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. Управление с помощью административного веб-интерфейса¶
Все страницы Интерфейса управления разделены на восемь разделов.
- Настройки
- Белый и чёрный списки SMTP
- Заблокированные IP
- Провайдеры БД пользователей
- Хранилища почты
- Очередь SMTP
- БД параметров
- Система
Доступ к ним имеет только пользователь 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-адреса и подсети (CIDR) в белый список сервера.
6.2.2.2. Белый список email отправителей¶
С помощью данного инструмента можно добавлять, просматривать и удалять email-адреса в белый список сервера.
Можно указать шаблон со звёздочкой вначале и/или в конце. Примеры:
users@dom* *ers@dom.ru *ers@dom* *@dom.ru
6.2.2.3. Чёрный список адресов IP серверов отправителей¶
С помощью данного инструмента можно добавлять, просматривать и удалять IP-адреса и подсети (CIDR) в черный список сервера.
6.2.2.4. Чёрный список email отправителей¶
С помощью данного инструмента можно добавлять, просматривать и удалять email-адреса в черный список сервера.
Можно указать шаблон со звёздочкой вначале и/или в конце. Примеры:
users@dom* *ers@dom.ru *ers@dom* *@dom.ru
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¶
Пример: admin@test.tegu.online
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 = <пароль администратора> httpPort = 8888 httpsPort = 9999 ctlPort = 8899
Можно заранее создать этот файл вручную, но важно, чтобы папка 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
- Имя пользователя: ikalmetov@mbk-lab.ru
- Требуется аутентификация: Да
- Безопасность: SSL
- Проверка подлинности: Пароль
- Отправка почты:
- Тип сервера: SMTP
- Порт: 465
- Сервер: mail.mbk-lab.ru
- Имя пользователя: ikalmetov@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
- URL: https://cloud.test.tegu.online/remote.php/dav/calendars/ikalmetov@test.tegu.online/-/ (тот, что скопировали выше)
- Имя пользователя: ikalmetov@mbk-lab.ru (не забываем, что имя полное)
- Пароль пользователя
Остается только установить цвет отображения событий и период синхронизации.
Обратите внимание, что различные программы, ведут себя по разному при работе с CalDAV. Для некоторых необходимо подключать каждый календарь отдельно, некоторые с состоянии самостоятельно прочесть весь список пользовательских календарей и предоставить пользователю выбор какие включить (например Evolution, который вы видите на скрине). Если ваша программа так не умеет, то процедуру необходимо повторить для каждого вашего календаря.
7.2.3. Настройка адресных книг¶
Протокол, который используется для работы с адресными книгами - CardDAV.
Проприетарные протоколы не используются. И опять напоминаем, что пользователям MS Outlook для реализации CardDAV необходимо дополнительно использовать бесплатный плагин Outlook CalDav Synchronizer
7.2.3.1. Подготовка к настройке¶
Подготовка состоит в копировании ссылки на выбранную адресную книгу аналогично тому, как это было сделано для календаря.
7.2.2.1. Настройка адресной книги в программе¶
Для настройки адресной книги в почтовой программе нам потребуются следующие параметры:
- Три адресной книги: Сетевой
- Протокол: CardDAV
- URL: https://cloud.test.tegu.online/remote.php/dav/addressbooks/users/ikalmetov@test.tegu.online/contacts/
- Имя пользователя: ikalmetov@mbk-lab.ru (не забываем, что имя полное)
- Пароль пользователя
Готово.
Обратите внимание, что различные программы, ведут себя по разному при работе с CardDAV. Для некоторых необходимо подключать каждую адресную книгу отдельно, повторяя описанную процедуру.
7.3. Мобильный клиент¶
Настройки клиентского ПО на смартфоне производится абсолютно так же, как и для десктопного клиента.
Однако, если CalDAV и CardDAV в iOs поддерживается "из коробки", то на платформе Android это зависит от версии и поставщика. Если ваш Android не поддерживает DAV, то рекомендуем две надежные и бесплатные утилиты:
В итоге у вас должно получиться так
8. Миграция почтовых серверов¶
8.1. Совместная работа старого и нового сервера¶
В этой статье мы научимся делать так, чтобы в течение срока миграции оба сервера (старый и новый) работали совместно.
Общий случай¶
Итак, в организации существует сервер с именем old_mail.tegu.online и IP-адресом 79.137.210.126, интегрированный с сервером каталогов dc.tegu.online.
old_mail.tegu.online прописан в DNS как Mail exchanger с приоритетом 10.
old_mail.tegu.online. IN A 79.137.210.126 tegu.online. IN MX 10 old_mail.tegu.online. tegu.online. IN TXT "v=spf1 mx -all"
А также PRT-запись
126.210.137.79.in-addr.arpa. 3600 IN PTR old_mail.tegu.online.
См. также статью Настройка доменной зоны
Задача установить почтовый сервер Tegu, работающий с ним параллельно.
С этой целью Tegu с именем mail.tegu.online устанавливается на IP-адресе 79.137.210.127.
mail.tegu.online должен быть интегрирован с сервером каталогов dc.tegu.online
mail.tegu.online должен быть прописан в DNS как Mail exchanger с приоритетом 20.
mail.tegu.online. IN A 79.137.210.127 tegu.online. IN MX 20 mail.tegu.online.
А также PRT-запись
127.210.137.79.in-addr.arpa. 3600 IN PTR mail.tegu.online.
Получилось, что оба сервера опубликованы в интернет и могут как отправлять, так и принимать почту для домена tegu.online. При этом приоритет old_mail.tegu.online выше и следовательно большая часть будет приходить на него.
Теперь необходимо создать домен для пересылки почты. С этой целью создадим MX-запись для домена virt.tegu.online (указывающую на Tegu). PTR-для этого сервера прописывать не надо т.к. отправка с этого сервера с виртуальными адресами не предполагается.
virt.tegu.online. IN MX 10 mail.tegu.online. virt.tegu.online. IN TXT "v=spf1 mx -all"
Теперь нам надо научить сервера правильно разбирать полученную почту в зависимости от того, где в настоящий момент находится почтовый ящик пользователя. На начальном этапе ящики всех пользователей находятся на старом сервере old_mail.tegu.online.
С этой целью необходимо перевести Tegu специальный режим работы - Режим миграции.
Для этого включить чекбокс в меню "Основные настройки / Включить режим миграции с другого сервера".
После перехода в "Режим миграции" в левом сайдбаре меню появляется опция "Мигрируемые домены".
В исходном состоянии на странице "Мигрируемые домены" вы найдете "Нет настроенных параметров миграции".
Добавляем необходимый домен из списка кнопкой "Добавить домен".
Открывается диалог "Параметры миграции", который предлагает для заполнения следующие поля:
- Домен (выбор из списка ранее настроенных доменов)
- Виртуальный домен: в нашем случае принимает значение virt.tegu.online
- Другие серверы домена (хост:порт - по одному на строку): Список серверов, которым необходимо пересылать почту пользователей, почтовые ящики которых не находятся на Tegu (т.е. не являются локальными для Tegu)
- Адреса локальных ящиков (по одному на строку): Здесь указываются почтовые ящики, которые уже переехали на Tegu и являются для него локальными. В начале миграции этот список пуст и Tegu пересылает всю почту на old_mail. После миграции каждого ящика необходимо добавить его адрес в это поле. Теперь Tegu считает его локальным, не будет пересылать, а будет доставлять в локальный адрес. В финале миграции, в этом поле должны быть указаны все почтовые ящики домена.
Важно: Tegu должен знать всех пользователей вне зависимости от того, перенесён ли тот или иной ящик. Это значит, что в настройках БД пользователей либо должны быть указаны параметры общей со старым почтовым сервером базы,
либо в новую базу должны быть внесены все пользователи с их адресами email.
Что делает Tegu в режиме миграции:
- Tegu принимает почту из интернет
- В случае если значение RCPT TO присутствует в поле "Адреса локальных ящиков", Tegu доставляет сообщение в локальный почтовый ящик
- В случае если значение RCPT TO отсутствует в поле "Адреса локальных ящиков", Tegu пересылает сообщение на любой из доступных серверов из списка "Другие серверы домена" (согласно очередности описания)
- Tegu принимает почту с сервера, указанного в поле "Другие серверы домена", адресованные пользователям домена virt.tegu.online и обрабатывает их как почту для домена tegu.online
- В качестве примера. Почтовый ящик ivanov переехал на Tegu. Tegu получает письмо с сервера old_mail.tegu.online, где в адресной части ivanov@virt.tegu.online, изменяет адрес на ivanov@tegu.online, находит этот адрес в списке локальных адресов и доставляет сообщение в локальное хранилище.
- В ряде случае невозможно указать весь список возможных старых серверов (к примеру, для облачного оператора, у которого сотни нод). В этом случае Tegu будет ориентироваться на записи SPF и принимать правильное решение.
Итак...
Наши сервера (старый и новый) в правильной позиции.
Как осуществить миграцию для пользователя ivanov:
- Переносим почтовый ящик ivanov с old_mail.tegu.online на mail.tegu.online;
- Настраиваем для ivanov пользовательскую почтовую программу для работы с mail.tegu.online;
- На Tegu прописывает адрес ibanov@tegu.online в поле "Адреса локальных ящиков";
- На old_mail.tegu.online прописываем безусловное правило пересылки всей почты: ibanov@tegu.online переслать на ibanov@virt.tegu.online
- Готово.
Частный случай¶
Обратите внимание, что old_mail.tegu.online может быть облачным (on cloud, к примеру Office 365) сервером или локальным (on premise, допустим MS Exchange).
- Для локального случая отличие заключается в том, что виртуальный домен достаточно создать в локальной (непубличной) зоне.
- Для локального случая прописывание MX-записи Tegu в публичной зоне также необязательно в случае если вы настроите пересылку всей почты Tegu через smarthost, в роли которого выступает старый сервер.
- Опции частного случая необязательны и призваны облегчить работу - правила общего случая будут работать всегда.
8.2. Перенос почтовых ящиков¶
Эта утилита обладает двумя достоинствами:
- Она чрезвычайно корректно работает (сохраняет правильную структуру каталогов, правильно обрабатывает национальные языки и пр.);
- Эта утилита универсально по своему определению (использует механизм IMAP). Благодаря этому ее можно использовать с любыми типами почтовых серверов будь то Postfix, MS Exchange или Lotus Domino.
- Сервер Tegu внесен в список серверов , совместимость которых с imapsync подтверждена.
Важно понимать, что с помощью IMAPSync можно импортировать только те сообщения, которые находятся с почтовом ящике на сервере. Другими словами для того, чтобы импортировать локальные сообщения, хранящиеся в форматах mailbox/maildir или pst, необходимо предварительно перенести их в серверный почтовый ящик. Как правило это делается средствами почтовой программы или с помощью специальных утилит. К примеру, в распоряжении администраторов MS Exchange серверов (начиная с версии 2010 SP1) есть специальная утилита PowerShell: New-MailboxImportReques. Очевидно, что у администратора, выполняющего операцию импорта, должны быть права на каталоги, в котором хранятся PST-файлы пользователей. Данная работа носит подготовительный организационно-технический характер, зависит от архитектуры конкретной системы и в данной статье не рассматривается.
Установка утилиты¶
Если вам не удалось установить из штатного репозитория вашего дистрибутива операционной системы, то нам поможет сайт французского разработчика imapsync Жиля ЛамирАля (Gilles LAMIRAL), gilles@lamiral.info - 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. Тестирование настроек сервера¶
Завершив настройку сервера, обязательно следует проверить его каким либо внешним ресурсом.
Выполняйте такую проверку каждый раз после внесения изменений в настройки.
Данная простая и быстрая процедура позволит вам сохранить безопасность вашего почтового сервера.
Одна из таких сервисов:
- https://www.kitterman.com/spf/validate.html - тест SPF
- https://multirbl.valli.org/lookup/ - проверка в black-листах
- https://www.dnsqueries.com/en/domain_check.php - комплексный тест
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 состоит из двух этапов:
- Установка и настройка Dr.Web Mail Security Suite
- Настройка Tegu
10.1. Установка Dr.Web Mail Security Suite (для UNIX)¶
- Установите Dr.Web Mail Security Suite для UNIX согласно инструкции производителя;
- Включите Компонент Maild
- Настройте параметры транспортного соединения между MTA и Dr.Web
- Оптимизируйте 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¶
Если вам необходима помощь, используйте:
- FAQ. Часто задаваемые вопросы по Tegu
- Техническая поддержка Tegu для зарегистрированных клиентов
- Техническая поддержка Tegu для незарегистрированных клиентов support@mbk-lab.ru
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 - Входящее письмо с адреса ikalmetov@yandex.ru. Tegu отказывается принять письмо и помещает адрес отправителя в серый список.
- 18:31:37 - Повторная попытка отправки письма с адреса ikalmetov@yandex.ru. Tegu нашел пару IP адрес и email отправителя в серых списках, поэтому перемещает адрес в белые списки и принимает письмо.
- 18:31:51 - Обработка принятого письма завершена. Письмо доставлено получателю ikalmetov@test.tegu.online
Выводы:
- На сколько же затормозится доставка почты? Очевидно, что точный ответ на данный вопрос дать невозможно т.к. это зависит не от Tegu, а от настроек отправляющего сервера. Обычно это несколько минут.
- Обратите также внимание, что сессия в 18:25:20 была инициирована с вычислительной нодой tegu-node1, а в 18:31:37 балансировщик отправил трафик на ноду tegu-node2. Однако т.к. все сессии почтового кластера хранятся в единой БД, то вторая нода корректно отработала сессию, начатую первой нодой.
- Как показывает практика, долю нежелательной почты, которую удаётся отсечь с помощью Greylisting, достаточно велика. При этом ощутимо снизится и почтовый трафик, т.к. в отличие от анализаторов спама приём спамерского сообщения не производится.
- Greylisting исключает ложные срабатывания, когда добропорядочное письмо блокируется фильтром и не попадает к адресату.
- Greylisting юридически чист. Блокирование почты на основании DNSBL, или прочтение почты анализаторами может вступить в определенное противоречие, но не Greylisting.
Приложение 2. Алгоритм обработки сессий SMTP¶
Tegu обладает максимально гибкой архитектурой.
Информация о всех объектах (их типах и размещении) хранится в базе данных конфигурации.
Выполняя свою работу, модули запрашивают в БД конфигурации необходимые параметры.
Коннекторы обеспечивают доступ к объектам в необходимом формате.
Рассмотрим алгоритм подробнее:
- Сессия SMTP начинается с блока Blacklist/Greylist, который получив IP адрес и домен сендера, проверяет их в базе данных конфигурации. Хранение данных конфигурации каждого домена возможно в нескольких вариантах. С этой целью менеджер базы данных конфигураций находит путь и выбирает соответствующий коннектор для подключения к локальной базе или СУБД.
- На этапе RCPT TO сервер должен выполнить авторизацию получателя. С этой целью процесс обращается к базе данных конфигураций (которых, как описано выше может быть несколько в разных хранилищах), находит тип и расположение одной из баз, которая хранит данные нужного пользователя и через соответствующий коннектор подключается к базе пользователей (таковыми могут быть любое количество локальных баз или LDAP3-серверов).
- Авторизовав пользователя и на этапе команды DATA сервер находит в конфигурации расположение антивирусного/антиспамового сервера и отправляет ему сообщение по протоколу Milter. Milter агент (сервер) выполняет проверку на вирусы, проверку на спам, а также выполняет любой кастомный сценарий обработки, написанный на языке LUA. В финале Milter-агент заполняет метрику и возвращает сообщение MTA.
- МТА определяет в базе конфигураций расположение очередей и помещает полученное сообщение в очередь на обработку.
- Очередь разбирает сообщения, выполняя для каждого сначала глобальные правила обработки (заданные администратором), затем локальные правила обработки (заданные пользователем). После передает сообщение на доставку.
- Процессы доставки определяют в базе конфигурации расположение хранилища для данного ящика, после чего осуществляет доставку (сохранение сообщение в ящике пользователя).
Все описанные процессы асинхронные, создаются сервером автоматически в нужном количестве и могут быть выполнены любой вычислительной нодой кластера.
Благодаря такой архитектуре, 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", возвращающая результат.