DeisGood
Junior Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Уже почти год порывался это сделать, наконец собрался и сделал 
Офлайновое обновление ростера Openfire для нескольких доменов(лесов) (встроенная БД + Ldap)
Уже 6 год подряд используем Openfire. Причем как говорится не все так просто: имеется 6 виндовых доменов территориально удаленных, на каждом крутится свой Openfire – типа корпоративная аська.
Долгое время мучились со связкой серверов (в плане пользователи удаленных серверов добавляются ручками, но где админ проленился, где не доглядели…) Ростер раздувался был жутко большим, не актуальным… Openfire торомозил и глючил, вообщем геморрой еще тот… Уж как только не пытались решать проблему, подключали Hazelcast, списывались с Томом Эвансом (разработчиком Openfire), синхронизировали sql, вообщем много сил положили бестолку... Но в конце 2013 года при очередном мозговом штурме наткнулся на небольшую статью в инете, которая махом решила все проблемы и в разы облегчила жизнь нам (админам) и заставила работать Openfire красиво и без сбоев.
Основная суть решения проблемы – оффлайновое обновление ростера Openfire (для виндузятников). Попытаюсь описать основную концепцию. Скрипты написаны по моей просьбе на питоне моим коллегой админом, сам я в питоне не бум-бум, и скрипты заточены под нашу контору, и не все может Вас устроить. Если уважаемых форумчан тема заинтересует, может сделать совместное более универсальное решение, которое значительному облегчит жизнь нашему брату админу. Сразу оговорюсь: большими специфическими знаниями в этом вопросе не обладаю и если ошибусь в каких технических моментах поправляйте на здоровье.
Когда составил более менее подробный мануал получилось аж 8 страниц, дабы не перегружать форум большим количеством букофф всю реализацию полностью оставляю в мануале, а здесь сделаю краткое описание всего механизма работы и сам принцип офлайнового обновления.
Кратко общая схема реализации:
- По расписанию на всех контроллерах домена запускается скрипт сбора информации из AD о пользователях, формируется файл в формате csv.
- По расписанию ведущий сервер копирует себе в общую папку полученные файлы со всех серверов, составляет общий файл списка и затем копирует этот готовый файл на все сервера.
- По расписанию на всех серверах с Openfire запускается скрипт, который останавливает Openfire, формирует ростер на основе общего файла списка и затем запускает Openfire.
Общая идея обновления ростера
А это пожалуй самое основное, как я писал выше решения проблемы с другими доменами чтобы отображался не jid а нормальное человеческое имя типа Паша Степанов я искал давно, не зная с какой стороны подойти. Во время очередной попытки открыл файлик openfire.script скопировал строчку из него в гугл и нашел описание, вот к сожалению, ссылку утерял. Главное я понял, что Openfire при выключении сохраняет данные ростера в файл, а в дальнейшем при запуске подхватывает их и продолжает работу. На этом моменте и родилась идея поправить этот файл и дальше скормить его опенфайеру. Почитав немного профильных форумов я нашел в каких строках какие данные необходимо указывать, какие строки можно безболезненно удалить – почистить ростер от старых записей. Попробовав на нескольких пользователях и получив положительный эффект я привлек штатного программиста ибо наполнение ростера руками практически невозможно. Получившийся скрипт делает полное обновление ростера меньше минуты (для ~150 пользователей). Забегая вперед – эффект превзошел все ожидания: из громоздкой неповоротливой базы с дикими тормозами с размерами более нескольких сотен Мегабайт за последние два года размер базы не вышел за пределы 10Мб, при этом всё отлично работает, обновляется.
Чуть подробнее о формировании файла ростера.
База данных ростера формируется строками:
INSERT INTO OFPRESENCE VALUES – создание пользователя на серевере
INSERT INTO OFROSTER VALUES – добавление пользователю других пользователей в ростер
INSERT INTO OFROSTERGROUPS VALUES – группа в которую добавляем другого пользователя.
Например:
INSERT INTO OFPRESENCE VALUES('operator',NULL,'001432486807808')
где: 'operator' – пользователь кому будем формировать ростер
'001432486807808' – время последнего логина пользователя в систему
INSERT INTO OFROSTER VALUES(11721,'operator','ivanov@dom2',3,-1,-1,'\u0418\u0432\u0430\u043d\u043e\u0432 \u0415\u0432\u0433\u0435\u043d\u0438\u0439')
где: 11721 – уникальный номер добавляемого пользователя во всём ростере,
'operator' – имя пользователя которому добавляем контакт
'ivanov@dom2' – jid пользователя которого мы добавляем к контакту
3,-1,-1 – здесь 3 – значение которое делает контакты видимыми друг для друга, остальные не знаю
'\u0418\u0432\u0430\u043d ' – имя пользователя в кодировке Unicode (здесь сокращено, ибо не входит) в данном случае содержит имя пользователя из домена DOM2 – Иванов Евгений.
INSERT INTO OFROSTERGROUPS VAL-UES(11721,0,'\u0422\u043e\u043b\u044c\u044f\u0442\u0442\u0438')
где: 11721 – уникальный номер пользователя во всём ростере, который был добавлен предыдущей строкой
'\u0422\u043e\u043b\u044c ' – имя группы в кодировке Unicode (здесь сокращено, ибо не входит), в которой будет лежать пользователь Иванов Евгений у пользователя 'operator', в данном случае под юнико-дом скрывается слово «Тольятти»
Итак если мы добавим эти 3 строки в ростер то у пользователя operator в мессенджере появиться Группа «Тольятти», в которой будет лежать пользователь «Иванов Евгений», обратите внимание, не jid - 'ivanov@dom2' а именно нормальный пользователь – Иванов Евгений.
Более того, после того как сервера соединяться (S2S), в Информации о контакте Иванов Евгений мы увидим все данные которые предоставит нам AD о данном человеке, а именно, внутренний номер телефона, почтовый адрес, отдел и должность (т.е. то что мы не поленились внести в AD, и всё что запрашивается Openfire’ом при обращении к AD), например как это выглядит в QIP:
Естественно, что формирование ростера сделать «вручную» нереально, вот например мы имеем 5 доме-нов, по 50 пользователей в среднем в домене, для одного пользователя добавляем:
1(добавление пользователя на сервер) +5групп*50пользователей*2(относим каждого пользователя в группу) = 501 строка
Для всех пользователей в домене соответственно:
50пользователей*501строку(создадим ростер каждому пользователю) = 25050 строк.
А 50 пользователей в домене это не так уж и много .
Какие строки убираются из ростера?, расписывать их не буду, можно попробовать поискать в интернете (кстати, я уверен что список удаляемых строк можно еще расширить, но это всё экспериментально, и для людей которые больше в этом разбираются):
INSERT INTO OFUSER VALUES
INSERT INTO OFPRIVATE VALUES
INSERT INTO OFVCARD VALUES
INSERT INTO OFPRIVACYLIST VALUES
INSERT INTO OFOFFLINE VALUES
INSERT INTO OFPUBSUBNODE VALUES
INSERT INTO OFPUBSUBAFFILIATION VALUES
INSERT INTO OFPUBSUBITEM VALUES
INSERT INTO OFPUBSUBSUBSCRIPTION VALUES
INSERT INTO OFSECURITYAUDITLOG VALUES
INSERT INTO ENTCONVERSATION VALUES
INSERT INTO ENTCONPARTICIPANT VALUES
INSERT INTO OFCONVERSATION VALUES
INSERT INTO OFCONPARTICIPANT VALUES
INSERT INTO OFGROUPPROP VALUES
Описание работы скриптов, сами скрипты и подробный мануал
От себя добавлю работаем по данной схеме с 2013года пока нареканий и проблем не было . Надеюсь кому-нибудь пригодиться
|
Всего записей: 161 | Зарегистр. 18-11-2005 | Отправлено: 08:19 27-05-2015 | Исправлено: DeisGood, 08:25 27-05-2015 |
|
