Ключевые слова:communigate, mail, login, auth, (найти похожие документы)
From: Дмитрий Молчанов <mdv@ngs.ru.>
Newsgroups: email
Date: Mon, 2 May 2007 14:31:37 +0000 (UTC)
Subject: Перенос аккаунтов между бэкендами статического кластера CommuniGate.
В данной заметке рассматривается конфигурация статического кластера CGP
с центральным Directory-сервером, где каждый нод кластера имеет
индвидуальную дисковую систему.
Зачем это может быть нужно:
1) нехватка места на одном из бэкендов
2) повышенная дисковая нагрузка одного из бэкендов
3) запуск новых серверов в кластере.
Проблемы с переносом возникают сразу. Казалось бы - чего проще, взял
аккаунт, заархивировал его, перенес на другой сервер... но не все так
просто:
1. CGP хранит информацию об имеющихся у него аккаунтах в памяти и
оперирует, в основном, с этой информацией. Файлы настроек аккаунтов, как
я понимаю, он перечитывает либо после изменений, либо по необходимости.
2. Чтобы CGP увидел аккаунт который мы ему подсунем из архива - придется
перезапускать CGP, это следствие 1й проблемы. Это малоприемлемо на
нагруженной почтовой системе, т.к. CGP останавливается достаточно долго,
с завершением активных сессий и т.д. и через 10 минут простоя почты
пользователи начинают возмущаться.
3. при перемещении аккаунтов между бэкендами надо как-то обновлять
информацию в LDAP.
В результате проблема переноса аккаунтов с одного бэкенда на другой
перерастает в целое действо, которое надо проводить сугубо в нерабочее
время.
В ходе своих изысканий я пришел к еще 2м способам, не скажу, что оба без
недостатков, но на мой взгляд оба достаточно изящны.
Способ 1й, так до конца и не опробованный, т.е. это идея.
1. На входе имеем информацию какой аккаунт, откуда и куда надо переместить
2. через CLI получаем пароль акканута (либо, если они хранятся в
зашифрованном виде, мы его узнаем другим способом)
3. на dstBackend''е создаем временный аккаунт.
4. копируем в него с помощью CLI же accountsetting и accountinfo
5. с помощью входящей в комплект CGP утилиты MoveIMAPMail - копируем
содержимое ящика. из аккаунта на srcBackend''е во временный аккаунт на
dstBackend''е и в результате получаем реплику аккаунта во временном
аккаунте на сервере назначения.
6. переименовываем аккаунт на исходном сервере в какое-либо уникальное временное имя
7. переименовываем временный аккаунт на dstBackend''е в нормальное имя аккаунта.
и... мы ПОЧТИ всё перенесли. За исключением Адресной книги и пересональных web-файлов.
Как перенести те данные можно, конечно, придумать. Например адресную
книгу перенести с помощью ACAP, web-данные как-то perl''овым скриптом...
Способ 2й, опробованный, оказался проще.
1. смотрим где лежи аккаунт в LDAP''е
2. через CLI берем пароль от аккаунта.
3. создаем через CLI на dstBackend''е временный аккаунт, например tmp_$user_tmp@$domain
4. пакуем аккаунт на srcBackend''е
tar --create --file $tmpdir/$accName.tar.gz--gzip --directory /var/Communigate/Domains/$domain/u.sub/s.sub/user.macnt .
5. растариваем содержимое аккаунта во временном аккаунте на dstBackend'е
tar --extract --file $tmpdir/$accName.tar.gz--gzip --directory /var/Communigate/Domains/$domain/t.sub/m.sub/tmp_$user_tmp.macnt
6. переименовываем аккаунт на srcBackend''е во что-то отличное от изначального имени.
7. переименовываем tmp_$user_tmp@$domain в $user@$domain на dstBackend'е
8. через imap делаем рескан всех папок, чтобы CGP обновил информацию об использовании аккаунтом дискового пространства.
9. удаляем на srcBackend''е временный аккаунт.
Всем манипуляции в с LDAP''ом производятся самим CGP в процессе
создания/переименовывания аккаунтов. работа с ldap''ом из
perl-скрипта(как это у меня сделано) через Net::LDAP, с IMAP''ом -
Net::IMAP::Simple. все достаточно просто и прозрачно. в результате того,
что мы переименовывем временный аккаунт, CGP перечитывает те настройки
которые мы ему подсунули от оригнального аккаунта.
Вопрос автоматизации удаленного архивирования аккаунта решается через
ssh+авторизация на ключах и либо sudo либо "premitrootlogin yes" в
sshd_conf, промежуточным хранилищем для архивов аккаунтов может служить
nfs-ресурс подмонтированный на всех серверах. Вопроса переноса
web-данных пользователя не возникает, т.к. мы переносим директорию
аккаунта целиком, с web-данными и адресной книгой вместе.
(c) Дмитирй Молчанов 2007г.
PS: Данная заметка не претендует на статус конечного решение, это идея,
которую я реализовал и решил поделиться мыслями, чтобы облегчить решение
данного вопроса другим.
