Zimbra: квоты и размер почтового ящика

 Понадобилось изменить и проверить размеры места, выделяемого пользователям. Общий для всех класс обслуживания разрешает до 450М. Но некоторым этого не хватает, а значит приходится отдельным личностям переопределять квоты.

В GUI пункт с размерами п/я зарыт слишком глубоко, поэтому решил найти способ получить эти сведения в CLI для возможной автоматической обработки.

Были использованы материалы:

1. https://nwildner.com/posts/2019-09-27-zimbra-cli-tips/
2. https://webhostinggeeks.com/howto/how-to-show-mailbox-size-on-zimbra-via-command-line/
3. мануал по awk (оказалось, я забыл бейсик, пришлось лезть в шпаргальник)
4. собственный пост по близкой тематике

Где хранится индивидуальная переопределенная квота, я не проверял.

Итак: zmprov gqu (в первой ссылке, кстати, эта команда написана неправильно - qgu вместо gqu, get quota usage) выводит списком почтовые ящики на сервере в формате "адрес квота занято", например "gates_wh@contoso.ru 471859200 1546199" - "пользователю В.Г. Гейтс выделено 450М, из которых занято полтора".

То есть, размеры выводятся в байтах, а дальше потребитель информации решает, в каких единицах ее использовать.

Для более-менее удобного анализа родил такую хитровыделанную команду:

zmprov gqu localhost|sort -nr -k2,3|awk {'printf "%.2fK:%.2fK=%2.2f%% %s\n", $3/1024, $2/1024, $3/$2*100, $1'}

1. берем данные с этого же сервера
2. сортируем по убыванию сначала квоты, потом - использованного места (2-е и 3-е поля в выводе gqu)
3. выводим в виде "x.xxK:z.zzK=y.yy% адрес", увеличивая порядок единиц для удобочитаемости - килобайты вместо байтов, например "1509.96K:460800.00K=0.33% gates_wh@contoso.ru", то есть, у тов. Гейтса занято 0.33% от выделенной ему квоты

На этом пока всё

P.S.

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

zmprov gqu localhost|sort -nr -k2|awk {'printf "%.2fK:%.2fK=%2.2f%% %s\n", $3/1024, $2/1024, $3/$2*100, $1'} |grep -v "=-nan%"|sort -rn -t \=  -k2 |head -n 10

отличия: убираем недопустимые значения, например, деление на ноль, потом сортируем по процентажу и выводим только топ-10

сдуру решил, что "-d" у sort задает разделитель полей, и долго не мог понять, на что сортировка ругается... Оказалось, надо -t. И, да, -k позволяет задать только одно поле для сортировки, поэтому в исходной команде результаты сортировки могут быть странные

MySQL в Zimbra: пароль доступа и некоторые параметры

Решил поглубже поковыряться в БД зимбры. И понял, что не знаю пароля. Решение:

su - zimbra
zmlocalconfig -s | grep mysql | grep password

На выходе получаем что-то вроде:

mysql_logger_root_password = AWHZ60JYaBw8_hVkA9NDVGh0irmp7xVz
mysql_root_password = lkAd7vkYI.Q_VeWt8uyL9kj0
zimbra_logger_mysql_password = 2iiyAVj3GeH0akkCe6M1o_HvY
zimbra_mysql_password = uMv4EsNqPZdK5htERx97VY5m

и видим пароли как для пользователя root, так и для пользователя zimbra. ЧТД.

В этой БД есть разные параметры, в т.ч. и различные даты/времена. Как выяснилось, хранятся они в стандартном юниксовом формате "число секунд с начала эпохи". Не ломая голову, просто преобразуем это длинное целое в человекочитаемый вид:

date -d @дата_в_формате_unix

Теперь о хранении данных о пользователях. Все они хранятся в БД zimbra в таблице mailbox. Емайл почему-то хранится в поле comment. а номер почтового ящика - в поле id. Номер п/я - это составное число вида

UGG

где GG - номер группы (БД mboxgroupGG), от 1 до 100. При формировании id пользователя, находящегося в группе с номером <10 к номеру группы дописывается ведущий ноль, например для сотой группы gg="00"
U - номер пользователя в группе, начиная с нуля, причем если U=0, то id=GG (ведущие нули в базе, понятное дело, не хранятся), при U=1 id=1GG, например, для сотой группы id=100.

Именно id используется в пути к каталогам хранения данных и индексов почтового ящика. Например, для 3-го пользователя из 94-ой группы путь будет:

/opt/zimbra/store/0/394/

Однако, если пользователь еще не обращался к своему почтовому ящику, то каталоги с его id могут отсутствовать. Например, недавно коллега сделал учетку для нового кладовщика, но не настроил ее комп. Пользователь с id=ugg уже есть в группе gg, а вот пути /opt/zimbra/store/0/ugg/ еще нет.

bash: хардлинки и файл - кто на кого указывает? files and hardlinks

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

Весь материал копировать не буду, ограничусь основным:

1. количество хардлинков:
ls -l имя_файла
например:
drwxr-xr-x  2 root   root     4096 апр 17 23:55  模板

цифра "2" после прав доступа показывает количество хардлинков на этот файл, точнее - на его иноду.

2. что за инода?

stat 模板
   Файл: 模板
   Размер: 4096      Блоков: 8          Блок В/В: 4096   каталог
Устройство: 819h/2073d Inode: 6004887     Ссылки: 2

Конкретно у каталога с шаблонами от WPS Office номер инода 6004887

3. на фиг оно нам надо?

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

4. не, а всё-таки, на кой мне знать эту иноду, если мне нужно найти дубликаты?

А вот на кой:

Вариант 1:

find ~/ -inum 6004887

/home/sergei/模板

Начиная с домашней папки я поискал и нашел файл с таким номером иноды. Но почему он один? Потому что это пустой каталог, в котором есть только файлы и еще есть "псевдо-файл" с именем "." (точка), ссылающийся на самого себя. То есть, по факту ссылок две - из каталога предыдущего уровня и сам-на-себя, а файл всего один. Но если зайти внутрь:

~/模板$ ls -l
drwxr-xr-x   2 root   root    4096 апр 17 23:55  ./ 
drwxr-xr-x 144 sergei sergei 16384 июл 11 06:03  ../
то видно, например, что на домашний каталог аж 144 ссылки

5. всё равно непонятно, неужто нельзя быстрее, чем сначала узнавать иноду, а потом долго и нудно искать?
Можно! Оказывается - можно.
find ~/ -samefile 模板
/home/sergei/模板

То есть, чтобы найти все ссылки на конкретный файл, можно просто воспользоваться ключом -samefile. ЧТД.

Zimbra: место на диске и протухшие сообщения

Я уже упоминал о проблемах с зимброй: в каталогах хранилища скапливаются древние файлы сообщений, которые давным давно удалены. До поры до времени я чистил их вручную, не зная, не аукнется ли это мне проблемами с доступом к п/я и т.п.
Оказалось, не всё так плохо. Хотя и не очень хорошо. Совершенно случайно выяснил, что это задокументированный баг, который нельзя устранить, но с последствиями которого можно бороться штатными средствами.
Итак, информация в зимбре хранится в более чем сотне БД MySQL. То есть, есть 100 штук баз mailboxgroupXXX, где XXX от 1 до 100, и несколько вспомогательных. Блобы, то есть, файлы почтовых сообщений, хранятся отдельно в "кластеризованном хранилище", и они-то и вызывают головную боль: движок MySQL не освобождает место, занятое ими.
В статье рассмотрено несколько вариантов, надо будет попробовать, а то совсем уже тоскливо.

Под катом текст статьи.

Теперь по месту на диске.
Обнаружил, что пропала или очень неактуальна статистика по использованию дискового пространства. Оказалось, что сам виноват: раньше она обновлялась с интервалом в 10 минут и заваливала меня сообщениями об исчерпании места, после чего я увеличил интервал до 5.5 часов. За что и поплатился.
В рабочем порядке уменьшил тот интервал до 3600 секунд, посмотрим, не полегчает ли сборщику статистики

Zimbra: частота предупреждений о заполненности диска

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

zmlocalconfig -e zmstat_disk_interval=19800

19800 секунд составляет 5.5 часов

Zimbra: статистика по размерам почтовых ящиков

Статистику по размерам почтовых ящиков можно смотреть через веб-интерфейс. Но это не всегда удобно, а иногда и невозможно.

Но это ж линукс, детка!

zimbra@server:$ zmprov gqu имя_сервера|sort -k 3 -n|column -t

и получаем красивую ровную табличку, отсортированную по правому столбцу, где указан, собственно, размер занятого места. (в первом столбце адрес учётки, во втором - квота для нее)

gqu -- GetQuoteUsage

-k 3 -- сортировать по третьему столбцу
-n -- сортировать числа как числа, чтобы 20 шло после 19, а не после 10

-t -- подобрать подходящие для красивой таблички ширины столбцов

Хранение сообщений в Zimbra: доведение до нервного срыва

Накопились в хранилище зимбры несколько десятков гигов старых сообщений, которые почему-то не прибились при автоматической чистке почтовых ящиков.
Меня смутил их размер - самих файлов с сообщениями, поэтому решил посмотреть в общих чертах, что там внутри. Через штатный просмотрщик MC сообщения показываются нормально, но он не умеет парсить структуру SMTP, поэтому я такие сообщения скопировал в свой сетевой каталог, дабы глянуть их через Thunderbird.
Копировал с помощью rsync. Сразу удивило, что, несмотря на использование опции -z, ускорения передачи не было, словно копировались уже сжатые данные. Ну да ладно, это не критично.
Захожу в FAR-e из-под винды в этот каталог, открываю первый попавшийся файл и выпадаю в осадок: внутри просто мусор. Открываю этот же файл через MC на сервере, куда его скопировал - MC показывает нормальные внутренности письма.
Копирую файл на свой локальный диск - внутри мусор. Копирую этот "мусор" обратно на самбу - MC показывает всё как положено.
Уже начал подозревать, что умудрился каким-то непонятным образом поймать вирус-шифровальщик, причем очень хитрый, который шифрует файл не на диске, а при открытии, в реальном времени. На всякий случай тот же самый файл из того же самого каталога попробовал открыть на другой машине с другой ОС и другим пользователем. Мусор.

ClamAV в старой Zimbra сошёл с ума

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

В огромного размера логе clamd обнаруживаю огромное количество записей типа:

WARNING: [LibClamAV] mpool_malloc(): Attempt to allocate 8388608 bytes. Please report to http://bugs.clamav.net

В некотором недоумении пытаюсь перезапустить зимбру, но обнаруживаю, что процесс clamd не реагирует на штатный kill -15 (sigterm), и снимается только по kill -9 (sigkill). Похожие записи вижу и в логе freshclam, из чего делаю вывод, что что-то не так с антивирусными базами.
Прибиваю все зимбровские процессы, переименовываю существующие базы (например mv daily.cvd -daily.cvd), вручную запускаю зимбровский freshclam. Он отрабатывает нормально, md5 свежескачанных баз совпадает с md5 старых баз. Значит базы не повреждены.
На всякий случай - всё-таки ошибка выделения памяти - проверяю логи гипервизора, на котором крутится зимбра. Там всё в порядке.
As a very last resort вбиваю текст сообщения об ошибке в гугл, и одной из первых ссылок вижу такую страницу: ClamAV DB Update leads to **UNCHECKED** in all messages (оно же в Zimbra KB) с датой изменения 24 октября 2016, то есть сегодня. Выяснилось, что проблема глобальная и Clam-ы версий 097 более не поддерживаются (причем давно) и не умеют работать с новыми базами.

Решение - в следующей по порядку статье ZimbraKB "ClamAV - Updating clamd for releases earlier than ZCS 8.0.6":

1. остановить всё зимбровское
2. скачать (по ссылкам в KB) новый ClamAV подходящей версии
3. распаковать его (под root-ом) в каталог зимбры
4. удалить старую ссылку clamav и создать ее заново, чтобы она указывала на новый каталог
5. убедиться, что ссылка указывает на каталог с новым ClamAV
6. запустить зимбру и порадоваться за нормальную работу антивируса

Zimbra, Outlook и ошибка 0x800ccc0f

Ситуация:Outlook 2010 в качестве POP3-клиента
Zimbra Release 8.0.6.GA.5922.UBUNTU12.64 UBUNTU12_64 FOSS edition

Учетная запись настроена так, чтобы удалять с сервера сообщения старше 2 недель. В основном всё проходит нормально, если проверять почту хотя бы раз в неделю. Но вылезла достаточно давно странная штука: если старых писем больше какого-то предела (не всего писем в инбоксе, а именно старых, подлежащих удалению), то аутлук затыкается на этапе получения новой почты с ошибкой 0x800ccc0f "Почтовый сервер разорвал соединение".

Лечилось это ручным удалением старых писем через веб-интерфейс, но ситуация всё равно не нормальная.

Внимательное изучение mailbox.log показало такую вот картинку:

---
2016-04-18 08:40:58,029 INFO  [Pop3Server-696] [name=user@domain;ip=***;] pop - DELE elapsed=0
2016-04-18 08:40:58,030 WARN  [Pop3Server-696] [name=user@domain;ip=***;] pop - throttling POP3 connection for account оченьдли-нная-стро-кавс-стилеUUID*** due to too many requests
2016-04-18 08:40:58,030 INFO  [Pop3Server-696] [name=user@domain;ip=***;] pop - DELE elapsed=0
2016-04-18 08:40:58,081 INFO  [Pop3Server-696] [ip=***;] pop - connected
2016-04-18 08:40:58,082 WARN  [Pop3Server-696] [ip=***;] pop - throttling POP3 connection for remote IP ***
2016-04-18 08:40:58,082 INFO  [Pop3Server-696] [ip=***;] pop - CAPA elapsed=0
2016-04-18 08:40:58,085 INFO  [Pop3Server-696] [ip=***;] pop - connected
2016-04-18 08:40:58,086 WARN  [Pop3Server-696] [ip=***;] pop - throttling POP3 connection for remote IP ***
2016-04-18 08:40:58,086 INFO  [Pop3Server-696] [ip=***;] pop - CAPA elapsed=0
2016-04-18 08:40:58,089 INFO  [Pop3Server-696] [ip=***;] pop - connected
2016-04-18 08:40:58,089 WARN  [Pop3Server-696] [ip=***;] pop - throttling POP3 connection for remote IP ***
2016-04-18 08:40:58,089 INFO  [Pop3Server-696] [ip=***;] pop - CAPA elapsed=0
---
Причем, судя по логам аутлука и дампу трафика, снятого Wireshark, на разных клиентах это происходило после удаления 195 сообщения, то есть примерно на 200-ой команде после логина.

Судя по этому http://community.zimbra.com/collaboration/f/1886/t/1084347 некий троттлинг (а это чего?) беспокоит не меня одного. Похоже, что это количество запросов в единицу времени либо количество однотипных команд.

---
$ zmlocalconfig|grep throttle
imap_throttle_acct_limit = 250
imap_throttle_command_limit = 25
imap_throttle_fetch = true
imap_throttle_ip_limit = 250
lmtp_throttle_ip_limit = 0
pop3_throttle_acct_limit = 200
pop3_throttle_ip_limit = 200
---

То есть, количество POP3-команд с одного адреса или с одного аккаунта в секунду (?) не может превышать 200 штук. После увеличения лимитов

---
$ zmlocalconfig -e pop3_throttle_acct_limit=2000
$ zmlocalconfig -e pop3_throttle_ip_limit=2000
$ zmcontrol restart
---

 Стало полегче... Но почему же раньше не было таких затыков?

ZIMBRA: фильтры сообщений, уточнение

В сентябре 2015 я писал про работу с фильтрами сообщений в web-клиенте Zimbra через инструменты zmprov и zmmailbox.
В комментариях к тому посту меня спросили, не пробовал ли я переносить правила фильтров из Thunderbird в Zimbra. Нет, не пробовал - не было необходимости. Но сам вопрос заставил немного порыться в интернетах и нашел я вот такую статью с описаниями относящихся к делу команд zmmailbox, а также условий и действий для фильтров. Возможно, она облегчит подобные преобразования. Поскольку статья помечена как устаревшая, то она может быть удалена и я скопировал ее содержимое сюда

Zimbra: грамотно работаем с фильтрами сообщений в веб-клиенте и в командной строке

Содержание: как правильно экспортировать и импортировать фильтры обработки сообщений из учетных записей зимбры.

Веб-интерфейс позволяет создавать фильтры для обработки сообщений. Они сохраняются в параметре zimbraMailSieveScript.

Например:

$ zmprov ga учетка zimbramailsievescript

Zimbra: postfix, aliases и почтовые роботы

Содержание: как заставить postfix в составе Zimbra нормально принимать почту на псевдо-адреса в файле /etc/aliases или его аналоге.

Понадобилось мне обработать дополнительно письма, приходящие на конкретный адрес. Это было частью весьма эротичной (в смысле - поебаться с ней пришлось конкретно) задачи: письмо, отправленное на несколько абонентов "Мегафона", разбить на отдельные сообщения. То есть, "Мегафон" позволяет отправлять емайлы на "адреса" вида номер_телефона@sms.megafondv.ru (для Дальнего Востока). Но из строк to:/cc:/bcc: обрабатывается только последний адрес получателя, все остальные молча игнорируются. "Мегафон" предлагает услугу, что-то вроде пакетной рассылки смс таким способом, но за приличные таньга.
Проблема только в том, что если не удастся отправить своевременно короткие сообщения именно этим нескольким конкретным получателям, то "Мегафон" в нашей области может сдохнуть через несколько часов после наступления необходимости в такой отправке - диспетчер энергосистемы должен таким способом проинформировать начальство о серьезных сбоях вроде взрыва Фукусимы или пожаре на входном городском трансформаторе.
Тем не менее, такая общественно-полезная рассылка меньше чем на десяток корпоративных номеров всё равно осталась платной услугой, и мы решили её не покупать.

Zimbra 8.0.6 и карантин

Варианты по спасению писем, отправленных в карантин злобным контент-чекером, предлагались не раз. Всё упиралось в отсутствие штатного документированного способа работы с карантином. Собственно, нет его и на данный момент, но есть и светлые моменты: в системе присутствует невидимый служебный аккаунт для карантина, который при определенных условиях можно просмотреть.

Zimbra: переполнение почтовых ящиков

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

Пользователи работают через POP3, и в их Outlook-ax выставлено "Удалять сообщения с сервера через 14 дней". Разумное ограничение, ведь бывает, что пользователь скачал сообщение и случайно удалил его у себя в клиенте, и самый быстрый способ вернуть статус-кво - это залезть в п/я веб-клиентом. (вариант не единственный, но речь сейчас не об этом)

Квота задана COS-ом, 300МБ на ящик. Но одному из пользователей не хватает и этого. Делать ему отдельный COS или вручную править лимиты не хочется. В итоге, если не разрешить POP3 удалять сообщения с сервера сразу по получении, или не делать ручную чистку ящика, то переполнение наступает очень быстро и письма к этому пользователю зависают в очередях, регулярная проверка которых приводит к снижению производительности сервера со всеми неприятными вытекающими.

При просмотре параметров п/я обнаружился параметр, аналога которому в UI ZCS-OSE 8.0.6 я не нашел:

$ zmprov ga пользователь|grep Quota
zimbraMailAllowReceiveButNotSendWhenOverQuota: FALSE
zimbraMailQuota: 314572800
zimbraQuotaWarnInterval: 1d
zimbraQuotaWarnMessage: (текст предупреждения удален)
zimbraQuotaWarnPercent: 90
Вот это - zimbraMailAllowReceiveButNotSendWhenOverQuota - что? В UI не нашел, хотя, может, плохо искал. Однако, название параметра говорит само за себя: "разрешить получение, но не отправку при переполнении п/я". Что нам, собственно, и требуется, поскольку почта в очередях имеет привычку протухать.

Провел эксперимент:

$ zmmailbox -z -m gms трудный_пользователь
299.62 MB
Понятно, ящик забит под завязку.

$#ошибся первый раз:
$ zmprov ma трудный_пользователь zimbraMailAllowReceiveButNotSendWhenOverQuota=true
usage:  modifyAccount(ma) {name@domain|id} [attr1 value1 [attr2 value2...]]
For general help, type : zmprov --help

$#ошибся второй раз:
$ zmprov ma трудный_пользователь zimbraMailAllowReceiveButNotSendWhenOverQuota true
ERROR: account.INVALID_ATTR_VALUE (zimbraMailAllowReceiveButNotSendWhenOverQuota must be TRUE or FALSE)

$#а вот так правильно:
$ zmprov ma трудный_пользователь zimbraMailAllowReceiveButNotSendWhenOverQuota TRUE
То есть, с какого-то перепуга булев параметр стал чувствителен к регистру? Ну да ладно... Заходим в диспетчер очередей и видим, что бедного пользователя в очереди на протухание ждут 129 сообщений. Но мы ж вроде разрешили доставку в переполненный ящик? Делаем "сброс" - попытку доставить всю ожидающую почту. Как ни странно, но очередь очищается, значит почта доставлена. Что ж, снова посмотрим, что там с размером п/я:

$ zmmailbox -z -m gms трудный_пользователь
640.17 MB
Неслабо так! Чувствую, всё равно придется донастраивать ему клиента, чтобы не хранить такие объемы на своем сервере.

Zimbra 8: выбор между http и https для клиентского доступа

Был несколько удивлен, что для доступа к своим п/я пользователям теперь необходимо использовать https, без вариантов. Учитывая непреодолимую тупость пользователей, для которых предложение "измени закладку в избранном" звучит как "нарисуй мне принципиальную схему БАК", это надо либо писать для них очередную инструкцию с картинками на уровне букваря для первого класса школы для умственно отсталых, либо править все закладки самому. Ну, можно, конечно, воспользоваться политиками домена, но это не всегда возможно.
Хорошо, конечно, что веб-доступом у меня пользуются единицы, из которых только один постоянно, а остальные - эпизодически в особо трудных случаях.

Выход, однако, есть, причем штатными способами:

zmtlsctl

zmtlsctl [mode]

Mode Choices

• http - http only, the user would browse to http://zimbra.domain.com

• https - https only, the user would browse to https://zimbra.domain.com http:// is denied.

• both - A user can go to http:// or https:// and will keep that mode for their entire session.

• mixed - If the user goes to http:// it will switch to https:// for the login only, then will revert to http:// for normal session traffic. If they browse to https:// then they will stay https://

• redirect - Like mixed if the user goes to http:// it will switch to https:// but they will stay https:// for their entire session.

Note: Redirect mode is not available for ZCS 4.5 and earlier. (See Redirect_http_to_https for information about redirect for ZCS 4.5.)

Steps to run

1. Type zmtlsctl [mode] and press Enter.
2. Type zmcontrol stop and press Enter.
3. When everything is stopped, type zmcontrol start and press Enter. 

не совсем, правда, понятно, что этот zmtlsctl делает без параметров:

zimbra@host:~$ zmtlsctl 
Rewriting config files for cyrus-sasl, webxml and mailboxd...done.

Zimbra: перенос паролей пользователей

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

Более того, команда:

zmprov ga <account>

возвращает что-то вроде:

# name <account>
userPassword: VALUE-BLOCKED

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

zmprov -l ga <account> userPassword
# name <account>
userPassword: {SSHA}ДлиннаяСтрокаАбракадабры

(-l - маленькая латинская L, а не i или единица!)

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

zmprov ma <account> userPassword {SSHA}ДлиннаяСтрокаАбракадабры

zmprov молча глотает это безобразие и прекрасно пускает меня со старым паролем уже на новом сервере. Красота! Осталось вытащить со старого сервера старые пароли. Ну, на такие грабли наступал не я один, поэтому решение уже нашлось:

for i in `zmprov -l gaa | egrep -v 'galsync|spam|ham|virus|stimpson'`;do \
  echo "$i,`zmprov -l ga $i userPassword | grep userPassword | \
  sed 's/userPassword: //'`";\
done;

Стимпсон - это старое имя сервера того, кто придумал эту команду, поэтому его можно смело удалить. И я немного доработал вывод команды, чтобы она формировала мне готовый набор команд для пакетной обработки:

for i in `zmprov -l gaa | egrep -v 'avir|galsync|spam|ham|virus'`;do \
   echo "zmprov ma $i userPassword `zmprov -l ga $i userPassword | \ 
   grep userPassword | sed 's/userPassword: //'`"; \
done;

Перенаправить вывод этой команды в файл мне не удалось, но это и не важно - ее результаты я скопировал из терминала в файл, который и запустил, добавив шабанг в начале :-)

Zimbra: перенос алиасов

После переноса учеток не помешает перенести алиасы. Пошел таким неортодоксальным путём.

Нашел способ вывести список алиасов:

for i in `zmprov -l gaa`; do echo ""; echo "$i:"; zmprov ga $i | grep MailAlias; done >/opt/zimbra/log/aliases.txt

Но полученный файл содержит вперемешку как учетки, так и их алиасы:

admin@mydomain:
zimbraMailAlias: root@mydomain
zimbraMailAlias: postmaster@mydomain

wiki@mydomain:

spam.ro7wynrcju@mydomain:

ham.twrv9q1qj@mydomain:

То есть, учетка админа имеет два алиаса, три других алиасов не имеют. Не смог на скорую руку с помощью sed/grep/awk убрать строки, после которых нет алиасов, да и черт с ними: вычистил вручную в редакторе.
Теперь надо подготовиться к автоматическому прописыванию алиасов из этого файла. Любым способом делаем глобальную замену "zaimbraMailAlias:" на "zmprov aaa $1 " (перед закрывающей кавычкой на всякий случай лишний пробел!).
Опять же, не смог оперативно понять, как это сделать штатными средствами, поэтому в редакторе, уже вручную убрал все оставшиеся двоеточия и перед каждым емайлом дописал "set ", чтобы присвоить первому переданному параметру командной строки значение этого емайла:

set admin@mydomain
zmprov aaa $1  root@mydomain
zmprov aaa $1  postmaster@mydomain

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

Zimbra: перенос на другой сервер. Часть 2014-1

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

Начнем с того, что установить 6.0.15 поверх скопированной с боевого сервера просто не удалось. Как ни бился, но сделать ничего не мог - то вдруг ldap терял данные, несмотря на правильный перенос (через zmslapcat), то zimbramon/64 вдруг начинал обращаться к старой библиотеке, которая еще /486, то еще что-то непонятное вылезало.

В общем, плюнул я на всё и решил ставить с нуля 8.0.6/64 на 12.04. Скоро, правда, появится 14.04, но это уже не так страшно.

По ходу дела выяснилось, что набор зимлетов, активированных в админке по умолчанию несколько отличается от того, что был в 8.0.0. Например, зимлета миграции учетных записей там не оказалось. Однако, сами зимлеты в виде zip-архивов лежали в нужном каталоге в /opt/zimbra.
Лихо жму в админке "инсталляция..." и понимаю, что мне предлагают из браузера выбрать файл на моей рабочей станции, а не из упомянутого каталога. Пришлось скопировать zip-ы к себе и ставить уже отсюда. Вроде поставились, я даже увидел знакомые буквы... Зимлет "просмотр почты" во времена 8.0.0/8.0.1 вызвал неслабое бурление говн на форумах, но в конце концов его официально включили в FOSS-версию, что не может не радовать.

Учетные записи этот мастер переноса создал, молодец. Но почту не перенес. Зато вроде без ошибок указал почтовый сервер каждого пользователя, не пришлось править поломатые.

Сейчас стоят две задачи: перенос сообщений и индивидуальных настроек, а также дополнительных объектов LDAP - списков рассылки и т.п.

Под катом размышления по этому поводу.

Планирование автоматического включения/отключения переадресации в зимбре

Automating the turning on/off the mail forwarding in Zimbra

Система состоит из 6 исполняемых файлов-скриптов, 5 на shell-script, 1 на #awk, разбитых на две группы: ввод данных и обработка.

Ввод (и частичная обработка) выполняется по цепочке:

zimtest --> zimtest1
zimtest1 вызывает rrgtest и при необходимости zmonoff

Автоматическая обработка по расписанию выполняется zimparser, который вызывает zimawk.awk и zmonoff.

ZIMTEST

Сценарий-обёртка. При запуске без параметров выдает наикратчайшую справку. Запускается с параметрами:

zimtest дата_начала дата_окончания кого на_кого

Все параметры обязательны.

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

В качестве кого можно указывать как полный емайл (напр. pupkin_vasya@наш_домен), так и только именную его часть (pupkin_vasya) - при проверке имени зимброй работают оба варианта.

На_кого - только полный емайл, поскольку эта строка просто будет вписана в соответствующее поле LDAP для кого. (однако, валидность этого адреса тоже проверяется и вписать несуществующего получателя не удастся)

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

ZIMTEST1

Основной скрипт ввода. Использует два скрипта - rregtest и zmonoff - для выполнения отдельных операций. rregtest используется как подключаемая библиотека, содержащая функцию проверки допустимости даты. Поскольку со времени начальной разработки эта функция сильно упростилась (я отдал все лишние проверки операционной системе), то возможно, что функция будет включена в состав zimtest1, а rregtest будет исключен из "комплекса".

zmonoff (ZiMbra ON/OFF) - скрипт, выполняющий, собственно, включение/выключение переадресации. Используется здесь в случаях, когда дата начала переадресации уже прошла или наступила сегодня для немедленного включения переадресации, либо когда дата отключения уже прошла или наступила сегодня, для немедленного отключения.

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

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

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

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

Если же переданная дата еще не наступила, то информация о ней дописывается в конец файла данных zmsched.dat в виде строки:

@секунды:действие:аккаунт_кого:емайл_на_кого:дата_по-русски

Например:

Переадресовывать почту Васи Пупкина на Петю Попкина с 25.09.2013
@1380027600:on:pupkin_vasya:popkin_petya@my.domain:25.09.2013

Отменить с 25.09.2013 переадресацию почты Васи Пупкина. Поле емайл_на_кого пусто, но оно есть - это строка нулевой длины между третьим и четвертым двоеточиями.
@1380027600:off:pupkin_vasya::25.09.2013

@секунды - дата выполнения действия в формате

date -d "дата 0:00" +@%s

то есть, количество секунд с начала "эпохи" до нуля часов нужного дня. Такой формат выбран для удобства сравнения в обработчике.

действие - принимает одно из трех возможных значений: on, off, skip. Действие skip будет описано ниже в описании обработчика zimawk.awk. Действия on и off самоочевидны: включить или выключить переадресацию для аккаунт_кого, указав, в случае включения емайл_на_кого.

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

емайл_на_кого - емайл и только емайл, на который будет переадресовываться почта. Это просто строка, которая будет помещаться в соответствующее поле в LDAP-записи про аккаунт_кого. Если указано действие off, то содержимое этого поля может быть пустым - оно никак не анализируется в такой ситуации, хотя и обязано присутствовать.

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

RREGTEST

Подключаемая библиотека-сценарий. Содержит только одну функцию validdate(), которая изначально задумывалась как полноценный валидатор дат, но позже была упрощена.

Дата проверяется на минимальную правильность по шаблону, примерно соответствующему дате в русском формате дд.мм.гггг. Причем этот шаблон очень нечеткий и допускает, например, 39.00.2016 (тридцать девятое число нулевого месяца). Это сделано умышленно, чтобы просто удостовериться, что в параметре передана именно дата, а не что-то другое: при любом большем несоответствии скрипт вываливается с exit 1, останавливая работу вызвавших его скриптов.

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

Сформированную дату пытаемся вывести на экран, и тут уже пусть date сама проверяет ее допустимость. Неправильно что-то? Вываливаемся!

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

ZIMPARSER

Скрипт-обёртка, запускаемый по крону. Устанавливает некоторые служебные переменные и вызывает собственно обработчик файла настроек.
Файл со скриптом обработчика и файл настроек должны находиться в одном с ним каталоге. Возможно, в будущем их местоположение будет передаваться в параметрах.

ZIMAWK.AWK

Основной обработчик файла данных zimsched.dat. Файл считывается построчно и если строка проходит ряд проверок, выполняется указанное в ней действие.
Проверки:
1. если в строке не пять полей, то строка считается неправильной и не обрабатывается, о чем делается запись в логе
2. если указано действие skip, то эта строка была обработана на прошлом проходе и ее обработка не требуется. Строка пропускается.

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

В подходящих для обработки строках действие заменяется с on или off на skip, чтобы удалить их на следующем проходе, и вызывается zmonoff для выполнения нужной операции.

После обработки всего файла создается временный файл zmsched.new, в который первой строкой выводится дата/время его создания, а далее построчно дописывается содержимое массива.

Старый файл данных переименовывается в zmsched.DOW, где DOW - номер дня недели, одна цифра, что позволяет вести историю изменений файла данных за последнюю неделю.

Файл zmsched.new копируется под именем zmsched.dat и система готова к новому циклу.

---
Использовались материалы:

Bash Scripting Guide

AWK

Еще awk и sed.

Под катом исходники.

Zimbra: перенос на другой сервер

В целом, перенос 6.0.15 с одного физического сервера (32) на другой (64) прошел нормально:

1. скопировал каталог /opt/zimbra
2. накатил сначала 6.0.15/32, чтобы восстановить пути, кронтабы и права
3. поверх нее накатил 6.0.15/64
4. после апгрейда ОС на новом сервере с Ubuntu 10.04 на 12.04 сразу накатил 8.0.0/64
5. работает

Однако, во время второго этапа вылезла бяка: новый сервер имел другое имя, не такое же, как старый, из-за чего сетап вываливался по таймауту доступа к старому серверу, более недоступному.
Пришлось рыться. Решение: zmsetservername.

Поскольку работал с очень старой, еще мартовской копией /opt/zimbra, решил перекачать новую почту со старого сервера (он недоступен новому по имени, но доступен по IP - две разные подсети, отделенные маршрутизатором). Сначала попробовал zmztozmig, но выяснилось, что оно не умеет создавать на новом сервере учетки, которые еще есть на старом, но которых еще нет на новом. Проще говоря, синхронизировались/мигрировали только существующие на обоих серверах аккаунты.
Это меня сильно расстроило. Но оказалось, что в админке 8.0.0 есть удобная штука - мастер переноса учетных записей, который живет в "средствах и миграции":