Обновление почтового сервера iRedMail с 0.9.5-1 до 0.9.7

0
689

iredmail-0.9.7Прошло уже почти два года с момента последнего обновления почтового сервера iRedMail до версии  0.9.5-1. а значит имеет смысл актуализировать нашу почтовую систему до последней на момент выхода статьи версии — 0.9.7. Пошаговый процесс установки iRedMail (MySQL Backend)  и различные проблемы возникающие в процессе обслуживания сервера описаны в главной статье.  В текущей  сборке произошли некоторые  изменения по части безопасности таких компонентов как Postfix, Amavis, Fail2ban + небольшие правки по части интерфейса в том же Roundcube, iRedAPD.

Если ставить новую версию на новый сервер, не OpenLDAP, то можно заметить что в качестве СУБД, вместо MySQL теперь MarinaDB, что на самом деле, абсолютно не страшно, поскольку MarinaDB это клон MySQL с тем же набором команд и инструкций от тех же разработчиков, только более свободный и независимый :)

Итак приступим. Для начала обновим саму ось выполнив всем известный набор команд:

или

Если, что-то пошло не так. У меня например в начале обновления на моем Debian 7 (Wheezy) вылезло информационное окошко PostgreSQL (С чего это вдруг, ведь данный пакет в системе не установлен?!), где в конце для выхода предлагают нажать quit (q), но при нажатии данной клавиши ничего не происходит. Следовательно приходится прерывать процесс при помощи ctrl+c. А вот если обновлять систему при помощи aptitude то нажатие «q» отрабатывает корректно.

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

Меняем текущий номер версии iRedMail на последнюю, открыв на изменение файлик /etc/iredmail-release

1) Обновление iRedAPD:

Скрипт ругнулся на отсутствующий файлик .my.cnf, где записана инфа о подключении к MySQL-серверу. Дадим ему такой файлик и снова запустим скрипт:

[client]
host=localhost
port=3306
user=root
password="<your-password>"

Если видим в конце, что «Upgrade completed», то все ОК, переходим к следующему компоненту.

2) Обновление iRedAdmin:

3) Обновление Roundcube:

Нажимаем Yes. Если видим что:

This instance of Roundcube is up-to-date.
Have fun!
All done.

То процесс обновления прошел успешно.

Поправим имя директории roundcubemail на актуальную с правкой ярлыка (smlinks):

Убедимся что владелец файла конфигурации /usr/share/apache2/plugins/password/config.inc.php (в новых версиях iRedMail путь к файлу может быть другим) и разрешения выставлены как:

Если нет поправим командами:

Добавим в cron скрипт очистки директории /usr/share/apache2/roundcubemail/temp куда загружаются временные файлы пользователей, в основном это мини изображения вложений, графические элементы подписей. Со временем данная папка может существенно вырасти в размере, выжрав все свободное пространство на диске :)

Открываем на редактирование cron и вставляем туда следующую строчку:

# Roundcube: Удаляем временные файлы.
# По умолчанию файлы хранятся два дня и контролируются в Roundcube параметром: $config['temp_dir_ttl']
2 2 * * * php /usr/share/apache2/roundcubemail/bin/gc.sh >/dev/null

Кстати, параметр «$config[‘temp_dir_ttl’]» не был мной обнаружен в /usr/share/apache2/roundcubemail-1.3.3/config/config.inc.php а вот в самом дистрибутиве он есть, что как бы намекает, что процесс обновления со старой версии на новую не совсем корректно происходит. Хотя ничто не мешает нам его добавить в конфиг:

Но тогда не понятно, если существует данный параметр и файлы хранятся два дня, то зачем задание в cron очищающие данную папку или они хранятся где-то еще?! Надо будет понаблюдать! К слову сказать у меня за последние 2 года использования таких файлов  набралось аж 5 мб :)

4) Обновление Apache:

Исправляем уязвимость HTTProxy добавлением параметра в файл /etc/apache2/apache2.conf

Перезапускаем Apache командой:

4) Изменения в Postfix:

Версия iRedMail-0.9.5-1 и более ранние позволяют доверенным клиентам (указанным в параметре mynetworks) отправлять электронную почту через порт 587 без проверки подлинности smtp, что недостаточно строго и может использоваться спамерами. Для того что бы сконфигурировать механизм отправки почты через 587 порт с проверкой подлинности smtp для всех пользователей, поменяем значения параметра smtpd_client_restrictions в файле /etc/postfix/master.cf.

Открываем master.cf. на редактирование и находим строки:

Удаляем

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

Так же в версии iRedMail-0.9.5-1 и более ранних не было поддержки безопасного соединения через TLS, что приводило к тому что другие серверы не могли передавать электронные сообщения через безопасное соединение. Добавим данную поддержку командой:

Обновим настройки postfix командой:

Одно неправильное или дополнительное ограничение в файле etc/postfix/helo_access.pcre. Убрать строку:

и поставить вместо нее следующее регулярное выражение:

В моем файле ошибок нет, но такой строки тоже, поэтому просто добавил себе как доп. опцию.

5) Изменения в Amavis:

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

Вносим изменения в главный конфиг сервиса /etc/amavis/conf.d/50-user и перезапускаем его командой;

6) Изменения в  Fail2ban:

Улучшаем регулярные выражение фильтра Fail2ban, чтобы поймать больше спама POP3 / IMAP и добавляем правильный фильтр для файла журнала Dovecot:

7) Изменения в Awstat:

В iRedMail-0.9.5-1 и более ранних выпусках, Awstats была неправильно настроена и доступна без аутентификации. Что бы это исправить, открываем конфиг /etc/apache2/conf.d/awstats.conf на редактирование и добавляем две строки:

8) Изменения в Dovecot:

Фиксим неправильный параметр logrotate для файла журнала Dovecot, из-за которого все файлы журнала Dovecot пусты, в ввиду отсутствия необходимых разрешений для открытия файлов журнала. Что бы поправить, открываем файл /etc/logrotate.d/dovecot на редактирование и удаляем следующую сроку:

9) Обновление phpmyadmin. (опционально)

10) Изменения в MySQL:

Скорректируем значения (datetime) для некоторых столбцов SQL в базе данных «vmail»:

Добавим новые таблицы forwardings,

и alias_moderators в базу vmail (опционально):

Затем закачаем скрипт по миграции пользовательских аккаунтов и запустим его. Данный скрипт делает запрос к MySQL базе «vmail» и производит миграцию (копирование) почтовых акаунтов из основной таблицы mailbox в таблицу псевдонимов — alias:

Но миграция не происходит т.к. скрипт ругается на отсутствующие поля в таблице alias, а именно: islist, is_alias.

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

И повторно запустить скрипт:

И вуаля, надпись «Done», говорит о том, что миграция завершилась успешно.

Теперь, сообщим postfix о новых таблицах, выполнив:

И напоследок грохнем ранее созданные и неиспользуемые столбцы SQL в таблице alias, базе vmail:

11) Послесловие

Как видим процесс обновления почтового сервера на базе Linux, не самая простая и тривиальная задача, требующая внимательности и глубокого понимания работы всей системы в целом :) Особенно актуально, когда после N-го количества обновлений по инструкции должен быть один результат, а у тебя может быть совершенно другой.  Поэтому при выходе последующих новых версий я решил более не заниматься апгрейдом системы, а сразу переносить конфигурацию со старого сервера на новый, как это было ранее описано в заметке. Возможно так будет быстрее и точнее в плане соответствия конфигурации от разработчиков.