Установка Cyrus Murder

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

Тем не менее, мы успешно используем это в Carnegie Mellon.

Introduction & Assumptions

Этот документ имеет статус руководства по конфигурированию Cyrus IMAP Aggregator, он же Cyrus Murder. Рекомендуется изучить этот документ для ознакомления с терминологией используемой далее. Этот документ находиться в разработке и то, что Вы читаете - не последняя его версия.

Этот документ предпологает, что Вы успешно установили сервер Cyrus IMAP. Этот сервер будет первым backend-сервером. Так же предпологается, что Вы знакомы с административными и повседневными операциями на сервере Cyrus IMAP и аутентификационной библиотекой SASL. Если Вы чувствуете, что знаний нехватает, то обратитесь в начало всей документации.

Эта диаграмма взаимодействие различных компонентов Cyrus Murder, она может быть полезна для представления "общей картины".

Установка

Вам необходимо собрать Cyrus IMAPd с опцией --enable-murder . В результате будут скомпилированны proxyds и сопутствующие утилиты.

Требования

Хотябы один сервер Cyrus IMAP. Если серверов больше чем один, то их пространства имен не должны пересекаться(конфликтовать). Другими словами, имя каждого ящика должно быть уникальным (или ящики с одинаковыми именами должны находитьс в разных пространствах имен)
Хотябы одна машина, которая станет первым Frontend-сервером.
Одна машина, которая будет MUPDATE master-сервером. Это может быть и один из Ваших frontend-серверов.

Настройка MUPDATE Master

На mupdate master-сервере должен быть запущен mupdate-сервис в master-режиме. Обратите внимание, MUPDATE master может распологаться на одной из Ваших frontend-машин, только не запускайте на ней процесс mupdate в slave-режиме.

Для настройки mupdate master, Вам необходимо добавить в cyrus.conf строку наботобие приведенной ниже в раздел SERVICES:

  mupdate       cmd="/usr/cyrus/bin/mupdate -m" listen=3905 prefork=1

Обратите внимание на опцию "-m", она запускает mupdate в master-режиме.

Вам нужно настроить хотябы "скелет" imapd.conf который определяет configdirectory, фиктивную partition-default (т.е. только для корректности конфига, такого раздела можен и не быть вообще - Прим. пер.) и admins, которые смогут аутентифицироваться на сервере. Обратите внимание на то, что slave mupdate-сервер так же, как и backend-сервера должен иметь возможность аутентифицироваться как admins на master. Вот очень простой пример imapd.conf для master-сервера:

configdirectory: /imap/conf
partition-default: /tmp

admins: mupdateslave1 backend1

Также Вам потребуется настроить SASL для привильной аутентификации в Вашей среде.

Настройка backend'ов для передачи изменений MUPDATE Master

На backend'ах, настраивать murder легко. Вам нужно настроить backend как часть murder. Чтобы это сделать, укажите опцию mupdate_server в imapd.conf. В зависимости от того, какие аутентификационные механизмы Вы используете, можно определить следующие опции(несколько или все):

mupdate_username
mupdate_authname
mupdate_realm
mupdate_password

После того, как эти настройки будут произведены, любая операция на почтовом ящике на backend'е будет послана mupdate master'у для подтверждения и попадет в базу данных mupdate.

Вам так же необходимо настроить хотябы одного пользователя/группу использующего обцию proxyservers в imapd.conf. Этот пользователь не должен быть администратором, иначе любой, кто сможет получить захватить Ваш прокси получит польный контроль над backend'ом. Пример:

admins: cyrus
proxyservers: murder

Имейте в виду, что создав пользователя(пользователей) дял прокси надо сделать так, чтобы они могли аутентифицироваться на backend'е.

Импортирование базы данных с backend'а

Импорт текущей базы данных почтовых ящиков осуществляется легко, для этого предусмотренна утилита ctl_mboxlist. Чтобы сделать первую синхронизацию, просто от имени cyrus-пользователя выполните команду " ctl_mboxlist -m".

Обратите внимание на то, что преде запуском ctl_mboxlist -mw вы должны понимать все операции которые выполнит эта команда. Так же необходимо, чтобы все ящики были уникальными во всем пространстве имен murder'а.

Если все настроенно правильно, то БД почтовых ящиков текущего хоста будет отправлена в виде дампа mupdate-master'у. Если возникнут проблемы, то наиболее вероятная проблема заключается в неправильных настройках аутентификационных параметров, или mupdate не запущен как master. Использование mupdatetest может помочь в решении некоторых проблем (эта утилита установит аутентифицированное соединение к mupdate-серверу, если сможет).

Также полезно проводить повторную синхронизацию БД ящиков на backend'ах при запуске на master. Это можно реализовать добавив следующую строку в раздел START файла cyrus.conf на backend'е:

  mupdatepush   cmd="ctl_mboxlist -m"

Это заставит осуществлять синхронизацию с mupdate-master'ом каждый раз, когда backend перезапускается, в результате содержание БД mupdate будет обнавлено содержимым с backend'а (и произведет ACTIVATE и DELETES при необходимости).

Предупреждение: Если какой-то ящик существует на двух (или более) backend-серверах, каждый раз когда один из них начнет синхронизацию базы, этот backend-сервер станет авторитетным. Хотя, это не должно случиться при нормальной операции murder'а, это возможно при создании новой БД mupdate или когда присоединяется новый backend-сервер к murder'у.

Настройка frontend'ов

Процесс настройка frontend'ов состоит из двух шагов. Первое, Вам нужно указать mupdate_server (и "друзей"(?)) как Вы делали для beckend'ов до этого. Однако, т.к. frontend'ы общаются с mupdate-master'ом только через slave запущенный на локальной машине, Вам необходимо настроить slave, в разделе SERVICES файла cyrus.conf должно быть что-то типа:

  # mupdate database service - must prefork atleast 1
  mupdate       cmd="mupdate" listen=3905 prefork=1

Обратите внимание, поскольку это thread-служба, то Вы должны запустить(prefork) по крайней мере 1 процесс для того, чтобы БД могла синхронизироваться при запуске. Иначе обслуживание подключений не начнется до тех пор, пока не будет образовано mupdate-соединение клиента со slave'ом.

Вам также неоюходимо изменить все Ваши записи imapd на proxyd, и все записи pop3d на pop3proxyd . Таким образом, Ваш раздел SERVICES будет выглядеть примерно так:

  mupdate       cmd="/usr/cyrus/bin/mupdate" listen=3905 prefork=1 

  imap          cmd="proxyd" listen="imap" prefork=5
  imaps         cmd="proxyd -s" listen="imaps" prefork=1
  pop3          cmd="pop3proxyd" listen="pop3" prefork=0
  pop3s         cmd="pop3proxyd -s" listen="pop3s" prefork=0
  kpop          cmd="pop3proxyd -k" listen="kpop" prefork=0
  sieve         cmd="timsieved" listen="sieve" prefork=0
  lmtp          cmd="lmtpproxyd" listen="/var/imap/socket/lmtp" prefork=0

Заметьте, что timsieved не нуждается в прокси-демоне, протокол managesieve работает с murder'ом по направлению к backend'ам внутри.

Дополнительно, Вам могут понадобятся записи в imapd.conf с указанием пользователя и пароля для прокси (если Вы используете механизмы SASL, то это может потребоваться) на backend'ы, например, если Ваши backend'ы mail1.andrew.cmu.edu и mail2.andrew.cmu.edu с паролем foo и bar , и пользователем murder:

mail1_password: foo
mail2_password: bar
proxy_authname: murder

Если Ваши SASL-механизмы не требуют имени пользователя и пароля (например KERBEROS_V4), это не требуется. Обратите внимание - мы использовали то же самое имя пользователя как и в настройке backend'а выше(строка proxyservers, файл imapd.conf ).

Кагда Вы запускаете master на frontend'е, локальная БД ящиков должна автоматически синхронизировать себя с содержанием БД на mupdate-master'е. Ваши клиенты должны подключаться к frontend'ам, а frontend'ы будут проксировать по направлению к blackend-серверам.

Дополнительная настройка backend'а

Если Ваша аутентификационная система требует наличия имени пользователя, пароля и т.п., для аутентификации (если это не Kerberos), Вам нужно указать proxy_authname на backend'е в imapd.conf. Это также необходимо, чтобы backend'ы могли аутентифицировать друг друга для упрощения процедуры перемещения ящиков. (Backend-машины должны бать полными админами(admins)).

Доставка почты

Для доставки почты на Ваш Murder, настройте Ваш MTA так, как Вы это делали до этого, но вместо прямого соединения с lmtpd, теперь он должен соединяться с lmtpproxyd. Вы можете соединяться с lmtpproxyd запущеном на frontend-машине, или Вы можете установить master и lmtpproxyd на Ваших SMTP-серверах.

Администрирование

Хранение синхронизировавшейся базы данных

Согласованность в базе данных обеспечивается посредствам помещения текущего статуса backend'ов на master, и имея актуальную БД на frontend'ах (такую же, как на master'е). Начиная с ресинхронизации frontend'а на этапе запуска, простой в синхронизации не должен вызвать проблем. (Пока он функционирует - он должен продолжать получать обновления БД, при потере связи с master'ом, он попытается восстановить связь(reconnect) и ресинхронизировать базу после соединения)

При условии, что пространство имен backend-серверов оставалось дискретным (небыло ящиков расположенного на двох и более серверах), возможна ресинхронизация mupdate-master'а используя ctl_mboxlist -m. Если два сервера имеют один и тот же ящик, то говорить о гарантированной согласованности БД можно только после урегулирования этого вопроса.

Перемещение ящиков между backend'ами

На данный момент нет на 100% безошибочного способа сделать это, однако, если вы запустите команду переименования на frontend'е (точно так же, как Вы перемещаете ящики между разделами), и изменете имя раздела на имя нового backend'а, это заставит переместить ящик на указанный backend. Вы так же можете использовать следующий формат: backend.domain.com!partition для перемещения в указанный раздел (иначе будет использован раздел по-умолчанию). В cyradm, это выглядит так:

cyrus.andrew.cmu.edu> rename user.bcyrus user.bcyrus mail2.andrew.cmu.edu!u2

Обратите внимание на то, что при перемещении "замеченное состояние" сохранено в пользователе, по этому, возможно, при перемещение разделяемого пользовательского ящика будут иметь место странные эффекты. Общее правило при перемещении заключается в том, что при перемещении INBOX'а перемещается полностью весь пользователь (включая все под-ящики в INBOX'е, его состояние, подписки, sieve-скрипты и т.д.). "Замеченное состояние" объединиться с "замеченным состоянием" на новом backend'е, таким образом никакие данные не бедет потеряны ("замеченное состояние" - это единственная что оснается на старом backend'е). В случае с любым другим ящиком, перемещен будет только индивидуальный ящик. Если это корневая квота, новая корневая квота будет задействована на новом сервере, но квоты могут нарушиться, т.к. каждый backend заботиться только о своих квотах.

Вообще, лучше оставить "деревья" ящиков на том сервере где они и былиr, и не двигать под-ящики и inbox'ы между серверами.

Добавление дополнительного backend-сервера

Это делается элементарно, просто настройте пустой backend-сервер и пропишите параметр mupdate_server указывающим на mupdate-master.

Резервное копирование

xxx, need to write stuff. Нет необходимости делать бэкапы на mupdate-master't или slave'ах, поскольку данные, хранящиеся на них, могут быть сгенерированы напрямую с backend'ов.

Gotchyas

Clients, имеющие дело с пулом frontend-серверов - Некоторые клиенты могут не эффективно кэшировать соединения к пулу imap-серверов, по большому счету это не проблема, просто Вы будуту наблюдать мнего попыток аутентификации(больше чем необходимо).
- Kerberos - Если Вы используете аутентификацию kerberos, Вы должны убедиться, что все машины получаут ключи должным образом, т.к. мы видели некоторые проблемы с клиентами пытающимися аутентифицироваться на различных службах (например imap.imap-pool вместо imap.pool-frontend-1), также проверьте клиентов использованных в Вашей среде и удостоверьтесь, что они работают корректно с Вашей схемой выдачи ключей.
Clients, имеющие дело с направлениями- Некоторые клиенты (у нас были проблемы с pine, хотя, суйчас эти проблемы решены и с новыми версиями все должно быть OK(т.е., версия > 4.44), но, поскольку, до сих пор направления интенсивно не использовались ниодним IMAP-сервером, возможно, они будут работать неправильно или будут давать неожиданный эффект.
Clients, имеющие дело с получение NO при команде LSUB - Некоторые клиенты (например Outlook) могут некорректно работать если команда LSUB вернет ответ NO, который может быть получен если backend-сервер с пользовательским inbox'ом не отвечает. Мы, например, видели, что это приводит к удалению отсоединенного кэша сообщений.
Поведение cyradm / некоторые операции почтового ящика - Поведение некоторых административных команд может быть довольно неожиданным. Например, Если Вы выполняете команду SETQUOTA на frontend-сервере и если дерево указанного ящика ниже чем место откуда вы устанавливаете квоту и находиться на другом backend-сервере, скорее всего Вам потребуется подключиться напрямую к этому backend-серверу и произвести необходимые изменения на нем. Точно так же, почтовые ящики будут созданы на том же backend-сервере где находиться их родитель. Для того, чтобы создать их на другом сервере (или создать новый ящик вверху иерархии) Вам потребуется соединиться напрямую к этому backend-серверу.
Подписки - Если пользователи хотят подписаться на ящик на другом, не на их "домашнем" backend-сервере, у них ничего не получиться пока Вы не пропишите параметр "allowallsubscribe: t " на backend'е в файле imapd.conf. Это позволит подписаться на что лубой строке(?).
Перезапуск mupdate-master - Поскольку ctl_cyrusdb -r очищает резервирование на ящике, если Вы перезапустите mupdate-master (и запустите восстановление), тогда, возможно (мы считаем маловероятно), в БД mupdate возникнет несогласованность.

Проблемы & когда что-то не работает

Операции на ящике запрещены - Это говорит о том, что mupdate-master может быть недоступен. Перезапустите его.
Операции на ящике не видны с одного или более frontend'ов - Это говорит о том, что процесс mupdate на slave'е может быть умер, Вым нужно перезапустить master. Альтернатива: в случае потери связи с master'ом, mupdate попытается соединиться заново каждые 20 секунд в течении 20 попыток.
Повреждение mailboxes.db на frontend'е / не синхронизируется - Перезапустите master на frontend'е для того, чтобы процесс mupdate ресинхронизировал локальнуб базу данных. В случае сильного повреждения может потребоваться удаление локальной БД почтовых ящиков.
Почтовый ящик постоянно перемещяется меджу двумя(или более) backend-серверами. -Скорее всего, ящик существует более чем на одном сервере. Удалите ящик со всех серверов кроме одного и запустите "ctl_mboxlist -m" на машине где будет находиться этот ящик.
БД не создается на frontend/slave - Проверьте запущен ли slave-процесс mupdate(prefork=1).

Ссылки

Кратрий обзоп Aggregator'а
Протокол MUPDATE
last modified: $Date: 2003/10/29 19:28:21 $