В ПРОЦЕССЕ НАПИСАНИЯ!!!!
Пока идет непримеримая борьба с thunderbird, ldap, cyrus-imapd, postfix и другими коммунистическими товариСЧами, решил попробовать госпожу ZIMBRA, ибо там эти товарисчи уже приведены в капиталистический облик.
Итак, Zimbra проставлена на CentOS6.6. Сразу куча вопросов, и вот тут будет маленький склерозник.
[zimbra@zimbra ~]$ zmcontrol -v
Release 8.6.0_GA_1153.RHEL6_64_20141215151155 RHEL6_64 FOSS edition, Patch 8.6.0_P1.
Что мы собственно хотим получить:
+++ 1. Мультидоменность
--- 2. Квотирование ящиков
+++ 3. Нотификацию пользователей о новых письмах/событиях
+++ 4. Глобальная адресная книга (частично автоматически
наполняемая, если это возможно, например при создании/изменении ящиков).
Перенос существующей с openLDAP.
+++ 5. Запрет пользователям менять свои реквизиты
самостоятельно (ФИО, должность, подразделение, телефон и т.д.).
+++ 6. Доступ к ящикам и письмам при необходимости без участия пользователя
+++ 7. Глобальное управление настройками доменов (квотирование, модули интерфейса и т.д.)
--- 8. Возможность зачистки старой почты по определенным
правилам.
+++ 9. Псевдонимы(алиасы) доменов/ящиков (см. п.1 МУЛЬТИДОМЕННОСТЬ).
+++ 10. Инструкция по расширению места на дисковой подсистеме centos. Я
так редко это делаю, что постоянно забываю. А тут виртуалка, так что без
этого никак.
+++ 11. Списки рассылок.
+++ 12. Обработку заголовков и bcc_maps на уровне MTA.
+++ 13. Антивирусная защита
+++ 14. Маршрутизация почты на уровне ящиков(ящики одного домена на разных серверах, для реализации постепенной миграции).
--- 15. Доступ по http/https.
+++ 16. Антиспам. Не рассматриваем пока. В составе что-то есть, пока вообще не приоритет.
+++ 17. План переезда отдельных учетных записей.
--- 18. Настройка нескольких почтовых ящиков на одном рабочем месте
+++ 19. Понятное резервное копирование
+++ 20. Изменение допустимых размеров вложений и писем
--- Автоматическую подпись с реквизитами пользователя, предприятия, логотипом, формируемую на основе адресной книги
--- План переезда с существующей структуры на Zimbra.
Что нужно помнить:
Ручные изменения конфигов в папке .opt/zimbra/conf перетираются при обновлении ПО. Так что из нужно бэкапить дабы не убить при обновлении, И ПОМНИТЬ О ТОМ, ЧТО ТАМ ЧТО_ТО СДЕЛАНО РУЧКАМИ!!!!!
Админка работает на порту 7071
10) Web server HTTP port: 8080
11) Web server HTTPS port: 8443
12) Web server mode: https
13) IMAP server port: 7143
14) IMAP server SSL port: 7993
15) POP server port: 7110
16) POP server SSL port: 7995
################################################
1. МУЛЬТИДОМЕННОСТЬ
################################################
Есть такое дело, причем все достаточно просто. Даже алиасы на домены делать можно. Вот например есть у нас домен *.domain.com.ua, и устаревший *.domain.er.gov.ua, на который до сих пор работают подрядчики в районы, банки там, почтамт и т.д.
Делаем домен new.domain.com.ua, где клепаем ящики, и делаем алиас на него, old.domain.er.gov.ua. Теперь вся почта домена old.domain.er.gov.ua будет автоматом заворачиваться на соответствующий ящик домена new.domain.com.ua.
################################################
2. КВОТИРОВАНИЕ
################################################
Должно работать хитро. Квотирование не должно влиять на получение почты, только на отправку.
Квотирование настраивается в COS. А вот как настроить мою хитрую необходимость пока не понятно...
################################################
3. НОТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЕЙ
################################################
Можно настроить только два момента - Подсветка вкладки "Почта" при получении сообщения и мерцание заголовка браузера при получении сообщения . Все в том же COS. Правда окно у меня при проверке так и не замигало. Кроме того есть еще zimlet что-то типа "Zimbra Notifier", который ставится в систему и маячит в трее о новых сообщениях.
Пока будет пытаться использовать штатные решения и учить пользователей регулярно проверять почту, а если будет надо, будем использовать zimlet.
################################################
4. ГЛОБАЛЬНАЯ АДРЕСНАЯ КНИГА
################################################
Нужно включить GAL(Clobal Address List) так, чтобы он был доступен всем доменам. Это типа должна быть такая адресная книга. По умолчанию она видима только внутри домена, но так как у нас из будет целый зоопарк, да еще и с псевдонимами(или алиасами, как их еще называют).
Делаем так:
su - zimbra
zmprov mcf zimbraGalInternalSearchBase ROOT
zmprov mcf zimbraGalSyncInternalSearchBase ROOT
Далее проводим следственный эксперимент. То есть тупо проверяем, что все у нас будет работать.
Есть домен по умолчанию - zimbra.xoe.com.ua. К нему конечно есть вопросы, он выпадает из общей идеологии адресного пространства компании, так как был создан первым во время установки системы и отсутствия понимания принципов. Но пока его оставим.
Создаем новый домен - ks.com.ua, в котором создается учетная запись GAL galsync@ks.com.ua прямо во время настройки домена.
Создаем поддомены - co.ks.com.ua и gs.ks.com.ua, там аналогичным образом создается запись GAL. В каждом домене создаем пользователя и максимально заполняем реквизиты(test_ivanov@co.ks.com.ua, test_petrov@gs.ks.com.ua), после чего выполняем принудительную синхронизацию:
zmgsautil forceSync -a galsync@ks.com.ua -n zimbra
, где zimbra - имя источника данных для внутреннего GAL. И так как у нас все записи GAL видно из любого домена, данную команду нужно выполнить для каждого домена. Или тупо подождать, пока само не просинхронизируется (настройка GAL домена).
Кстати, есть простой вариант, который мне, например, подходит. Как я сделал: в домене ks.com.ua сделал учетку addr@ks.com.ua, пошарил ее адресную книгу всем на чтение. Вношу адреса в нее, а ее подключаю в учетках пользователей. Таком образом пользователям доступен GAL и подключенная адресная книга addr@ks.com.ua. На этапе переезда, если он будет, нашей системы из 900 адресов на zimbra это может быть промежуточным решением до того, как все контакты появятся в GAL. Кроме того книга addr@ks.com.ua организована древовидно, что удобно.
Ну а теперь по поводу того, как нам свою влить сюда.
Нашел такую утилиту, как http://ldap-csvexport.sourceforge.net. Я тут как раз собирался начать изучать perl, так вот код скрипта очень красивый, как для perl :).
./ldap-csvexport.pl -H ip_old_ldap_server -a ou,cn,sn,givenName,title,mail -b dc=ks,dc=com,dc=ua > ldap.csv
В получившемся ldap.csv меняем первую строку
"ou";"cn";"sn";"givenName";"title";"mail"
на строку
"department";"fullName";"lastName";"firstName";"jobTitle";"email"
и удаляем из файла ненужный нам мусор:
cat ldap.csv | grep -v '"";"";""' > ldap-mod2.csv
После сей замечательное процедуры в пользователе адресной книги создаем каталог, куда импортируем файл ldap-mod2.csv. Шарим этот каталог и отдаем в работу.
Нужно учитывать, что данная адресная книга ВРЕМЕННАЯ, так как там все в одной куче.
По мере создания учетных записей будет актуальная GAL, ну и адресную книгу лучше сделать по человечески. В этой все в куче.
################################################
5. ЗАПРЕТ ПОЛЬЗОВАТЕЛЮ МЕНЯТЬ СВОИ РЕКВИЗИТЫ
################################################
Тут такое дело. В адресной книге юзер ничего не поменяет. Но может поменять в своем ящике в настройках. Но на что это влияет я не понял. Вбил Иванову в настройках полный бред и отправил на Петрова. И порадовался. Ибо отправителя Петров увидел так, как написано в адресной книге.
################################################
6. ДОСТУП К ЯЩИКАМ И ПИСЬМАМ ПРИ
НЕОБХОДИМОСТИ БЕЗ УЧАСТИЯ ПОЛЬЗОВАТЕЛЯ
################################################
Ну это просто какая-то прелесть :)
Вообще все просто проще некуда.
Идем в управление учетными записями, щелкаем на интересующей правой кнопкой мышки, выбираем "Просмотр почты" И ВСЕ!!!!!
################################################
7. ГЛОБАЛЬНОЕ УПРАВЛЕНИЕ НАСТРОЙКАМИ ДОМЕНОВ
################################################
Делается это все через классы обслуживания, или COS(Class of Service) и сами домены, к которым привязывается COS
. Плюшек там много, и ими надо пользоваться.
Самое приятное, что можно сделать при помощи COS:
--- настроить в COS квоту пользователя и привязать COS к домену. Теперь все, кто в нем создается имеют квоту из COS.
--- настроить доступные протоколы(IMAP, POP), зимлеты, задачи(почта, календарь, ежедневник, настройки). Вот уберешь галочку с настроек, и будет пользователь горько плакать, ибо из у него не будет.
--- можно запретить создавать общие ресурсы.
--- настроить темы, периодичность проверки почты, проверку орфографии...
--- и еще много-много всякой полезной всячины.
Осадок в душе оставило то, что я не смог поменять COS на домена. Черег GUI получил ошибку, через zmprov не нашел возможности. Но она есть, просто я бросил искать, ибо не приоритет.
А нет, вот нужда заставила. Оказывается ошибка при смене cos через gui тянется еще с 8.5 версии. Засранцы, до сих пор не полатали. А исправить можно так. например на домен co.ks.com.ua нужно поставить cos all:
[zimbra@zimbra ~]$ zmprov gc all | grep zimbraId
zimbraId: e3793f8c-6853-4cfb-9bb9-97114b8a5ffb
zimbraIdentityMaxNumEntries: 20
[zimbra@zimbra ~]$ zmprov md co.ks.com.ua zimbraDomainDefaultCOSId e3793f8c-6853-4cfb-9bb9-97114b8a5ffb
Однако бубен, однако работает :)
################################################
8. ВОЗМОЖНОСТЬ ЗАЧИСТКИ СТАРОЙ ПОЧТЫ
ПО ОПРЕДЕЛЕННЫМ ПРАВИЛАМ
################################################
В настройках COS есть такая фишка, как "политики сохранения". Такие же есть на глобальном уровне. Там можно настроить, сколько может жить сообщение. По окончанию срока жизни сообщение удаляется. Это все. Если нужно что-то большее - сами, сами, ручками, скриптиками, костыликами, думайте...
################################################
10. РАСШИРЕНИЕ РАЗДЕЛА CENTOS
################################################
[root@zimbra /]# export http_proxy=http://10.11.11.70:3128
[root@zimbra /]# umount /dev/xvdb1
[root@zimbra /]# yum install parted
[root@zimbra ~]# parted /dev/xvdb
GNU Parted 2.1
Используется /dev/xvdb
Добро пожаловать в GNU Parted! Наберите 'help' для просмотра списка команд.
(parted) print
Модель: Виртуальное блочное устройство Xen (xvd)
Диск /dev/xvdb: 26,8GB
Размер сектора (логич./физич.): 512B/512B
Таблица разделов: msdos
Номер Начало Конец Размер Тип Файловая система Флаги
1 1049kB 10,7GB 10,7GB primary ext4
(parted) resize 1
Конец? 26,8GB
(parted) quit
Информация: Не забудьте обновить /etc/fstab.
Попробовали, нихрена не сработало. Оказывается parted до сих пор не поддерживает ext4.
А
потом когда баловался в resize2fs и fdisk раздел был успешно пересоздан
вот этими самыми кривыми руками :( Так что сейчас займусь
восстановлением, а потом продолжим.
КАРОЧИ!!!! ТУПО
БЕРЕМ LIVE DVD OPENSUSE, ГРУЗИМСЯ С НЕГО И МЕНЯЕМ РАЗМЕР РАЗДЕЛА. ВСЕГДА
РАНЬШЕ ТАК ДЕЛАЛ И НЕ БЫЛО НИ ОДНОЙ ОСЕЧКИ!!!НЕ ЗАБЫВАЕМ ПЕРЕД ЭТИМ
СДЕЛАТЬ БЭКАП РАЗДЕЛА!!!!
################################################
11. СПИСКИ РАССЫЛОК
################################################
Создаются в админке. Автоматом из всех конечно из нашего постфикса туда не перефигачишь, но в принципе при желании за полчасика активного кнопконажимательства и мышкодвиганья это реально сделать.
Важный момент - предлагаю делать списки рассылки в самом вышестоящем домене(это логично, ибо ими пользуются все домена и в адресном пространстве такая логика правильно), а для обратной совместимости делать на них псевдонимы на старые адреса.
################################################
12. ОБРАБОТКА ЗАГОЛОВКОВ ПИСЕМ НА УРОВНЕ MTA
################################################
В postfix у нас есть такой замечательный файлик /etc/postfix/header_checks, в котором настроено перекидывание банковских выписок. Цель - получить аналогичное в zimbra.
В zimbra используется postfix, но файлы конфигурации его динамические и при выполнении команды
zmmtactl reload
перетираются неизвестнооткудаберущимися.
Соответственно напрямую менять параметры postfix бессмыссленно.
Нас интересует параметр header_checks. Вот как мы его можем посмотреть:
[zimbra@zimbra ~]$ zmprov gacf | grep zimbraMtaHeaderChecks
zimbraMtaHeaderChecks: pcre:/opt/zimbra/conf/postfix_header_checks
А вот что в зимбровском постфиксе:
[root@zimbra conf]# /opt/zimbra/postfix/sbin/postconf header_checks
header_checks =
Как видим, настройки отличаются.
Логично предположить, что раз указывается на файл, то если таковой будет в наличии, то перетираться он не будет, а будет использоваться по прямому назначению.
Создаем файл /opt/zimbra/conf/header_checks, заполняем его и меняем настройку:
[zimbra@zimbra ~]$ zmprov mcf zimbraMtaHeaderChecks regexp:/opt/zimbra/postfix/conf/header_checks
[zimbra@zimbra conf]$ zmprov mcf zimbraMtaBlockedExtensionWarnRecipient FALSE
[zimbra@zimbra conf]$ zmmtactl reload
[root@zimbra conf]# /opt/zimbra/postfix/sbin/postconf header_checks
header_checks = regexp:/opt/zimbra/postfix/conf/header_checks
Ты гля, совпало... И, кстати, заработало. Так что радуемся.
Ну и еще, у нас настроен дубляж почты по адресам отправителей/получателей на отдельные архивные ящики, которые частенько используются для разбора полетов. Для этого используются параметры
recipient_bcc_maps=hash:/etc/postfix/bcc_maps_r
sender_bcc_maps=hash:/etc/postfix/bcc_maps_s
, это на старом сервере. Переносим аналогичную настройку на новый.
Первым делом копируем соответствующие файлы (bcc_maps_r, bcc_maps_s) со старого сервера (/etc/postfix/) на новый (/opt/zimbra/postfix/conf)
После чего
[zimbra@zimbra ~]$ zmlocalconfig -e postfix_recipient_bcc_maps = lmdb:/opt/zimbra/postfix/conf/bcc_maps_r
[zimbra@zimbra ~]$ zmlocalconfig -e postfix_sender_bcc_maps = lmdb:/opt/zimbra/postfix/conf/bcc_maps_s
[zimbra@zimbra ~]$ /opt/zimbra/postfix/sbin/postmap /opt/zimbra/postfix/conf/bcc_maps_r
[zimbra@zimbra ~]$ /opt/zimbra/postfix/sbin/postmap /opt/zimbra/postfix/conf/bcc_maps_s
Ну и после этого еще одну неправильную вещь. Редактируем файл /opt/zimbra/conf/zmconfigd.cf.
В секцию "SECTION mta DEPENDS amavis" перед строкой "RESTART mta" добавляем две строки:
POSTCONF recipient_bcc_maps lmdb:/opt/zimbra/postfix/conf/bcc_maps_r
POSTCONF sender_bcc_maps lmdb:/opt/zimbra/postfix/conf/bcc_maps_s
и делаем zmmtactl reload.
ВНИМАНИЕ!!! При обновлении zimbra файл zmconfigd.cf с вероятностью 99% будет ликвидирован и заменен на новый. Но другого способа как сделать то, что я хотел, я не нашел!!! Это надо учитывать при обновлении. Указанное выше применение zmlocalconfig вроде как должно не дать поломаться системе при обновлении, но проверить пока не могу - нечего обновлять.
################################################
13. АНТИВИРУСНАЯ ЗАЩИТА
################################################
Не мудрствуя лукаво ZIMBRA, как и я ( :) ) использует clamav, только не через clamsmtpd, а через amavisd. Но не суть. Единственное, что нам надо сделать, это настроить прокси для freshclam для обновления антивирусных баз. Почему-то системные настройки proxy freshclam использовать упорно не хочет.
Для этого редактируем файл /opt/zimbra/conf/freshclam.conf.in (freshclam.conf будет перетерт им при перезапуски антивируса). В файле меняем настройки прокси (HTTPProxyServer, HTTPProxyPort) и перезапускаем антивирусную защиту.
[zimbra@zimbra ~]$ zmantivirusctl restart
################################################
14. МАРШРУТИЗАЦИЯ ПОЧТЫ НА
УРОВНЕ ПОЧТОВЫХ ЯЩИКОВ
################################################
Собственно в чем суть. Адресов и доменов дофига, и переезд на зимбру планируется сделать плавный и постепенный. Когда мы переезжали на cyrus-imapd, postfix через transport был настроен на ручную маршрутизацию. То есть например, Васю Пупкина отправляем на хост такой-то, Папу Курицина туда-то, всех остальных в сад, то есть на третий сервер. Так постепенно все и переехали. Здесь мне надо так-же. Так как постфикс тут с шифрами, то посмотреть настройки transport можно так:
[zimbra@zimbra ~]$ zmprov gacf | grep zimbraMtaTransportMaps
zimbraMtaTransportMaps: proxy:ldap:/opt/zimbra/conf/ldap-transport.cf
[zimbra@zimbra ~]$ /opt/zimbra/postfix/sbin/postconf transport_maps
transport_maps = proxy:ldap:/opt/zimbra/conf/ldap-transport.cf
Настраиваем зимбропостфикс на использование /opt/zimbra/postfix/conf/transport, такой родной и привычный:
[zimbra@zimbra ~]$ zmprov mcf zimbraMtaTransportMaps "proxy:ldap:/opt/zimbra/conf/ldap-transport.cf, lmdb:/opt/zimbra/postfix/conf/transport"
[zimbra@zimbra ~]$ /opt/zimbra/postfix/sbin/postmap /opt/zimbra/postfix/conf/transport
[zimbra@zimbra ~]$ zmmtactl reload
Теперь так. У нас есть домен co.ks.com.ua на старом сервере. Такой же на новом сервере. Шо робыть???
На старом сервере понятно: адрес, который переехал на новый сервер пробиваем в transport таким вот образом:
address1@co.ks.com.ua smbt:ip_of_new_server_zimbra
А вот что на зимбре??? Там у нас будет так:
co.ks.com.ua smtp:ip_of_old_server_postfix
fa@co.ks.com.ua local:zimbra
Теперь по мере переезда адресов подрихтовываем файлы transport на обеих серверах. Когда все переедет, соответствующие записи в transport на зимбре просто удалим.
Не забываем после изменения transport делать postmap и zmmtact.
И еще весьма мутный момент. Например, есть домен gs.ks.com.ua и алиас на него gs.old.some.com.ua. Мы их создали в zimbra и начали перенос ящиков. НО. Как оказалось, алиасы отрабатывают РАНЬШЕ правил в transport. То есть приходит нам письмо со старого сервера от user@gs.old.some.com.ua и мы на него отвечаем. При этом в transport прописан маршрут, куда ехать smtp для данного домена. Но он не срабатывает, мы получаем ошибку, что ящик user@gs.ks.com.ua не существует. Перечитайте еще раз, тут надо прочувствовать. И вот как нам иметь ящики домена gs.old.some.com.ua на старом сервере, а алиас в zimbra?
Наверное сделаем так. Алиасы переименовываем по принципу такому:
zmprov -l rd gs.old.some.com.ua temp.gs.old.some.com.ua
Как только домен переедет целиком, алиас вертаем в зад. Зимбру настраиваем на использование алиасов постфикса:
[zimbra@zimbra ~]$ zmprov gacf zimbraMtaAliasMaps
[zimbra@zimbra ~]$ zmprov mcf zimbraMtaAliasMaps "lmdb:/etc/aliases, lmdb:/opt/zimbra/postfix/conf/ali4migrate"
[zimbra@zimbra ~]$ touch /opt/zimbra/postfix/conf/ali4migrate
[zimbra@zimbra ~]$ /opt/zimbra/postfix/sbin/postalias /opt/zimbra/postfix/conf/ali4migrate
[zimbra@zimbra ~]$ zmmtactl reload
Теперь на сервере зимбры для учетки, которая меняет доменное имя при переезде добавляем
в ali4migrate:
fname.lname: fname.lname@gs.ks.com.ua
в transport:
fname.lname@gs.ks.com.ua local:zimbra
fname.lname@gs.old.some.com.ua local:fname.lname
Применяем изменения:
[zimbra@zimbra ~]$ /opt/zimbra/postfix/sbin/postalias /opt/zimbra/postfix/conf/ali4migrate
[zimbra@zimbra ~]$ /opt/zimbra/postfix/sbin/postmap /opt/zimbra/postfix/conf/transport
[zimbra@zimbra ~]$ zmmtactl reload
Теперь на сервере, где живет gs.old.some.com.ua
в ali4migrate:
fname.lname: fname.lname@gs.ksoe.com.ua
в transport:
fname.lname@gs.old.some.com.ua local:fname.lname
Далее дописано 2015.04.29
Когда у меня по указанным выше правилам ничего не получилось с некоторыми адресами, т.к. я начал получать ошибку
: mail forwarding loop for
nach_insp@gs.....ua
я нашел другой способ. Он как всегда немного неправильный с точки зрения того, что при обновлении версии zimbra придется все повторять ручками, как в обработках заголовков MTA, но на форуме сами разрабы рекомендуют так делать, но предупреждают о том же.
Обходимся без всяких алиасов, транспортов и т.д.
[zimbra@zimbra ~]$ /opt/zimbra/postfix/sbin/postconf smtpd_recipient_restrictions
smtpd_recipient_restrictions = reject_non_fqdn_recipient, permit_sasl_authenticated, permit_mynetworks, reject_unlisted_recipient, reject_invalid_helo_hostname, reject_non_fqdn_sender, check_recipient_access lmdb:/opt/zimbra/postfix/conf/recipient_redirect, permit
Редактируем файл/opt/zimbra/conf/zmconfigd/smtpd_recipient_restrictions.cf. ПЕРВОЙ строкой (чтобы обрабатывалось раньше всех) добавляем:
check_recipient_access lmdb:/opt/zimbra/postfix/conf/recipient_redirect
[zimbra@zimbra ~]$ touch /opt/zimbra/postfix/conf/recipient_redirect
В recipient_redirect добавляем примерно следующее
nach_insp@gs.....ua REDIRECT someothermail@fff.com
[zimbra@zimbra ~]$ /opt/zimbra/postfix/sbin/postmap -v /opt/zimbra/postfix/conf/recipient_redirect
[zimbra@zimbra ~]$ zmmtactl reload
[zimbra@zimbra ~]$ /opt/zimbra/postfix/sbin/postconf smtpd_recipient_restrictions
smtpd_recipient_restrictions = check_recipient_access lmdb:/opt/zimbra/postfix/conf/recipient_redirect, reject_non_fqdn_recipient, permit_sasl_authenticated, permit_mynetworks, reject_unlisted_recipient, reject_invalid_helo_hostname, reject_non_fqdn_sender, permit
Вроде как настройки применены.
Далее дописано 2015.06.09
Вылезла очередная фигня. Предыдущая настрока не устраивает, потому что оказалось, что: если пользователь отправляет письмо на двух адресатов, один из которых перечислен в файле recipient_redirect, то письмо получит только он, второй получатель не получит ничего, ибо письмо уже было ПЕРЕНАПРАВЛЕНО перечисленному. И вот тут я не могу понять, то ли это баг, то ли это фича :) Фак в том, что пользователи у меня не всегда гарантировано получают почту, и это плохо...
Попробуем еще по другому сделать.
Смотрим следующие настройки:
[zimbra@zimbra ~]$ zmprov gacf | grep zimbraMtaVirtualAliasMaps
zimbraMtaVirtualAliasMaps: proxy:ldap:/opt/zimbra/conf/ldap-vam.cf
или так
[zimbra@zimbra ~]$ zmprov gacf zimbraMtaVirtualAliasMaps
zimbraMtaVirtualAliasMaps: proxy:ldap:/opt/zimbra/conf/ldap-vam.cf
Меняем:
[zimbra@zimbra ~]$ zmprov mcf zimbraMtaVirtualAliasMaps "proxy:ldap:/opt/zimbra/conf/ldap-vam.cf, lmdb:/opt/zimbra/postfix/conf/virtual"
В /opt/zimbra/postfix/conf/virtual добавляем запись:
oldmail@olddomain.com newmail@newdomain.com
Выполняем:
[root@zimbra ~]# chown zimbra:zimbra /opt/zimbra/postfix/conf/virtual
[zimbra@zimbra ~]$ /opt/zimbra/postfix/sbin/postmap /opt/zimbra/postfix/conf/virtual
[zimbra@zimbra ~]$ zmmtactl reload
################################################
15. ДОСТУП ПО HTTP/HTTPS
################################################
По умолчанию работает только по https. Включаем http и https вместе:
[zimbra@zimbra ~]$ /opt/zimbra/bin/zmtlsctl both
[zimbra@zimbra ~]$ zmcontrol stop
[zimbra@zimbra ~]$ zmcontrol start
Фигня в том, что при доступе по http нужно указывать порт 8080, а нам не хочется.
Но нам, по ходу, придется.
################################################
17. ПЛАН ПЕРЕЕЗДА ОТДЕЛЬНЫХ ПОЧТОВЫХ ЯЩИКОВ
################################################
1. На сервере zimbra создаем новый почтовый ящик. При создании МАКСИМАЛЬНО заполняем все атрибуты. Особенно внимание к ФИО, ОТОБРАЖЕНИЕ, ДОЛЖНОСТЬ, ОТДЕЛ, ОРГАНИЗАЦИЯ, ТЕЛЕФОН ВНУТРЕННИЙ И ВНЕШНИЙ. Основой для заполнения реквизитов являютпя ПК "Кадры" и "Зарплата", телефонный справочник. Безликие адреса, типа bt-01@ss.gg.tt выясняем с пользователями, такие адреса либо сервисные, то есть официальные, либо персональные, но сделанные через жопу в старые добрые времена, когда все делалось через жопу. Если ящик сервисный или официальный, так и оставляем, если черезжопный, делаем нормальный адрес, а этот оставляем синонимом на него. В качестве образца спросите меня какой ящик использовать.
2. В адресной книге addr@ksoe.com.ua создаем соответствующие контакт в соответствующей ветке дерева отделов. При создании МАКСИМАЛЬНО заполняем все атрибуты (смотри п.1). ВНИМАНИЕ!!! В адресной книге атрибутов больше, на ее основе будет составляться динамическая подпись. В качестве образца спросите меня какой ящик использовать.
3. Во временной импортированной адресной книге соответствующий контакт удаляем.
4.1. Если домен ящика не меняется, то в файлах transport старого и нового сервера вносим изменения:
на старом (/etc/postfix/transport)сервере добавляем:
address@co.ks.com.ua smtp:10.11.11.84
на новом(/opt/zimbra/postfix/conf/transport) сервере добавляем:
address@co.ks.com.ua local:zimbra
4.2 Если домен ящика меняется(например с aaa@gs.ks.old.somedomain.com.ua на aaa@gs.ks.com.ua ), то
на старом (/etc/postfix/transport) добавляем:
aaa@gs.ks.old.somedomain.com.ua local:aaa
на старом (/etc/postfix/ali4migrate) добавляем:
aaa: aaa@gs.ks.com.ua
на новом (/opt/zimbra/postfix/conf/transport)
aaa@gs.ks.old.somedomain.com.ua local:aaa
aaa@gs.ks.com.ua local:zimbra
на новом (/opt/zimbra/postfix/conf/ali4migrate)
aaa: aaa@gs.ks.com.ua
5. На компе пользователя при помощи thunderbird переносим почту на новый сервер.
################################################
18. НАСТРОЙКА НЕСКОЛЬКИХ ПОЧТОВЫХ ЯЩИКОВ
НА ОДНОМ РАБОЧЕМ МЕСТЕ
################################################
В принципе настройки все делаются через вкладку "НАСТРОЙКИ", ну а как еще. Пользоваться только неудобно получается. Но ко всему можно привыкнуть. Минус в том, что видно все папки учетки, включая адресные книги, в том числе подключенные общие ресурсы. И отписаться от них, несмотря на то, что адрес настраивается как внешний IMAP, возможности нет. Но, опять же, все это можно терпеть.
Настройки работы с несколькими почтовыми ящиками тут оригинальные. Варианта 3, все есть в теме http://community.zimbra.com/collaboration/f/1886/t/1138637.
1. Подключать ящики как внешние IMAP. Вариант настолько кривой, шопипец. Во первых, сжирается квота твоего ящика, так как зимбра синхронизирует внешние ящики с твоим. Соответственно в твоем ящике будет сожрано ровно чтолько, сколько в присоединенных внешних IMAP. Кроме того этим неудобно пользоваться. Кроме того череж задницу организована проверка почты.
2. Создавать псевдонимы(алиасы), состоящие из ящиков, которые должны быть в одном профиле. Пока не попробовал, но там по ходу аналогичная шняга с квотой, как во внешних IMAP ящиках.
3. В ящике, который должен быть присоединен, нарезаются доступы на конкретные папки конкретным пользователям. И эти папки присоединяются в конкретные ящики. Есть минус - нельзя пошарить весь ящик целиком, соответственно если на рабочем месте, где присоединяемый ящик является основным, создали папку и не пошарили ее, то никто больше эту папку не увидит.
Как по мне, то третий вариант наиболее нормальный. У нас есть официальные ящики, их никому не ставить, а только подключать папками. Ну и в профиле пользователей посоздавать образов для нескольких подписей. чтоб от разных ящиков могли почту отправлять.
################################################
19. ПОНЯТНОЕ РЕЗЕРВНОЕ КОПИРОВАНИЕ
################################################
С понятным резервным копированием тяжело. Для community версии ничего толкового не нашел. В вики есть куча вариантов, но все они основаны на остановке сервисов зимбры и либо копирования всего тома целиком, либо его синхронизации, либо упаковке и копировании и т.д. Самое неприятное, что сервисы нужно останавливать. В нашем случае с планируемыми объемами хранения бэкап будет делаться долго, а не работать система долго (более часа) не может. Так что есть 2 варианта:
1. Резервное копирование виртуальной машины целиком на ходу.
2. Тупая упаковка /opt/zimbra тоже на ходу.
Совместив эти два незатейливых способа мы можем добиться желаемого результата. Для восстановления системы целиком подойдет способ 1, для восстановления отдельных писем - способ 2.
Есть еще 3-й вариант - сделать самому нечто человеческое. Но это тот еще факультативчик, из разряды былобыуменянемеряновремени...
Полезности:
https://wiki.zimbra.com/wiki/Zimbra_DR_Strategy
################################################
20. ИЗМЕНЕНИЕ ДОПУСТИМЫХ РАЗМЕРОВ
ПИСЕМ И ВЛОЖЕНИЙ
################################################
[zimbra@zimbra ~]$ /opt/zimbra/postfix/sbin/postconf message_size_limit
message_size_limit = 10240000
[zimbra@zimbra ~]$ zmprov gacf zimbraMtaMaxMessageSize
zimbraMtaMaxMessageSize: 10240000
[zimbra@zimbra ~]$ zmprov gacf zimbraFileUploadMaxSize
zimbraFileUploadMaxSize: 10485760
[zimbra@zimbra ~]$ zmprov gacf zimbraMailContentMaxSize
zimbraMailContentMaxSize: 10240000
[zimbra@zimbra ~]$ zmprov gs zimbra.ks.com.ua | grep zimbraFileUploadMaxSize
zimbraFileUploadMaxSize: 10485760
[zimbra@zimbra ~]$ zmprov gs zimbra.ks.com.ua | grep zimbraMailContentMaxSize
zimbraMailContentMaxSize: 10240000
[zimbra@zimbra ~]$ zmprov mcf zimbraMtaMaxMessageSize 38912000
[zimbra@zimbra ~]$ zmprov mcf zimbraFileUploadMaxSize 15360000
[zimbra@zimbra ~]$ zmprov mcf zimbraMailContentMaxSize 38912000
[zimbra@zimbra ~]$ zmprov ms zimbra.xoe.com.ua zimbraFileUploadMaxSize 15360000
[zimbra@zimbra ~]$ zmprov ms zimbra.xoe.com.ua zimbraMailContentMaxSize 38912000
[zimbra@zimbra ~]$ zmcontrol restart
################################################
АВТОМАТИЧЕСКАЯ ПОДПИСЬ С РЕКВИЗИТАМИ
ПОЛЬЗОВАТЕЛЯ, ПРЕДПРИЯТИЯ, ЛОГОТИПОМ,
ФОРМИРУЕМАЯ НА ОСНОВЕ АДРЕСНОЙ КНИГИ
################################################
Есть статейка (http://wiki.zimbra.com/index.php?title=Setting_automatic_Default_Signature, https://wiki.zimbra.com/wiki/Mail_signatures_with_images), в которой дается bash скрипт, который, как я понял, для всех учеток выставляет сигнатуры разово. То есть при добавлении, изменении и т.д. скрипт нужно прогонять по новой. Манипулирует он параметрами zimbraPrefMailSignatureEnabled, zimbraPrefMailSignatureStyle, zimbraPrefMailSignature.
Запоминаем это как вариант, хоть и весьма похожий на костыль. И ищем дальше.
В официальной доке есть раздел "Enabling Support for Domain Disclaimers".
Нужно нам будет настроить автоматическую подпись для писем. Для начала включаем эту фичу:
zmprov mcf zimbraDomainMandatoryMailSignatureEnabled TRUE
Потом при помощи команд
zmprov mcf zimbraDomainMandatoryMailSignatureText
zmprov mcf zimbraDomainMandatoryMailSignatureHTML
можно будет ее поднастроить.
Попробуем для домена co.ks.com.ua.... Описывать не буду - попробовал... Не пойдет - подпись статичная, со сложным html не получилось.
Ищем дальше.
А давай ка я напишу в community.zimbra.com...
Сказано - сделано:
http://community.zimbra.com/collaboration/f/1886/t/1138680
Время прошло, а никто так и не помог. Так что нашел статейку (https://wiki.zimbra.com/wiki/Setting_automatic_Default_Signature), на базе которой придется делать свой скрипт, который по счедулеру будет устанавливать подпись учетным записям.
################################################
ПЛАН ПЕРЕЕЗДА
################################################
050. Создаем все домены и псевдонимы доменов (п.1).Из-за кривизны GUI, COS назначаем через CLI (п.7) каждому домену.
070. Настраиваем маршрутизацию почты (п.14).
100. Переносим адресную книгу (п. 4).
200. Переносим списки рассылки (п. 11).
300. Переносим обработку заголовков header_checks и bcc_maps (п. 12).
400. Переносим поочередно учетные записи (п.17).
Читать далее
