Прошло уже почти два года с момента последнего обновления почтового сервера 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-серверу. Дадим ему такой файлик и снова запустим скрипт:
Если видим в конце, что «Upgrade completed», то все ОК, переходим к следующему компоненту.
2) Обновление iRedAdmin:
3) Обновление Roundcube:
Нажимаем Yes. Если видим что:
То процесс обновления прошел успешно.
Поправим имя директории roundcubemail на актуальную с правкой ярлыка (smlinks):
Убедимся что владелец файла конфигурации /usr/share/apache2/plugins/password/config.inc.php (в новых версиях iRedMail путь к файлу может быть другим) и разрешения выставлены как:
Если нет поправим командами:
Добавим в cron скрипт очистки директории /usr/share/apache2/roundcubemail/temp куда загружаются временные файлы пользователей, в основном это мини изображения вложений, графические элементы подписей. Со временем данная папка может существенно вырасти в размере, выжрав все свободное пространство на диске :)
Открываем на редактирование cron и вставляем туда следующую строчку:
Кстати, параметр «$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-го количества обновлений по инструкции должен быть один результат, а у тебя может быть совершенно другой. Поэтому при выходе последующих новых версий я решил более не заниматься апгрейдом системы, а сразу переносить конфигурацию со старого сервера на новый, как это было ранее описано в заметке. Возможно так будет быстрее и точнее в плане соответствия конфигурации от разработчиков.