The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Перенос аккаунтов между бэкендами статического кластера CommuniGate. (communigate mail login auth)


<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>
Ключевые слова: 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: Данная заметка не претендует на статус конечного решение, это идея, которую я реализовал и решил поделиться мыслями, чтобы облегчить решение данного вопроса другим.

<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>

 Добавить комментарий
Имя:
E-Mail:
Заголовок:
Текст:




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру