ejabberd - Comments for "mod_shared_roster_ldap логика работы и возможности"

Вот выдержка из мего конфига

Murz — Mon, 19 Sep 2016 20:21:42 +0000

Вот выдержка из мего конфига с учетом Ваших рекомендаций:

  mod_shared_roster_ldap:
    ldap_auth_check: off
    ldap_rfilter: "(&(objectClass=group)(objectClass=posixAccount))"
    ldap_groupattr: "distinguishedName"
    ldap_group_is_dn: true

    ldap_gfilter: "*"
#    ldap_memberattr: "member"
    ldap_groupdesc: "name"
    ldap_member_selection_mode: "group_children"

    ldap_ufilter: "(&(objectClass=user))"
    ldap_useruid: "sAMAccountName"
    ldap_userdesc: "displayName"

Судя по verbose-логу - список групп он успешно получает из LDAP, т.е. rfilter срабатывает нормально.

Вторым этапом он делает запрос для поиска членов группы, в данном случае не совсем понятно зачем Вы предлагаете ldap_memberattr='memeber' заменить на ldap_member_selection_mode: "group_children" - ведь как раз в поле 'memeber' у группы находится список CN пользователей в формате "CN=Фамилия Имя,CN=Users,DC=example,DC=com", как же ejabberd поймёт с какого поля брать список пользователей?

Если я раскомменчиваю строку ldap_memberattr: "member" то ejabberd вроде как получает список пользователей группы, но он видит что там какая-то фигня вместо jabber id и игнорит полученные записи, даже если я ставлю ldap_auth_check: off, т.к. по логам дальше не видно попыток выполнить ldap_ufilter.

Подскажите пожалуйста как быть в такой ситуации? Может быть к версии 16.08 что-то поменялось уже? В комментариях к багу https://support.process-one.net/browse/EJAB-1480 предлагают использовать также ldap_member_selection_mode: "memberattr_dn" но с ним тоже не работает.

Благодарю за такое подробное

Murz — Mon, 19 Sep 2016 19:56:15 +0000

Благодарю за такое подробное описание, наконец-то прояснил для себя как это работает! А можете привести пример рабочего конфига для AD-совместимого LDAP-сервера? Я уже какие только варианты не пробовал - никак не могу добиться подгрузки списка юзеров, сгруппированного по группам на ejabberd 16.08. Список пользователей без групп получаю нормально, а вот с группами - ну прям никак.

Я использую Zentyal 4.1 Server который эмулирует работу AD на базе Samba LDAP.
Пользователи там почему-то имеют CN вида "CN=Фамилия Имя,CN=Users,DC=example,DC=com" (да-да, прям вот так с пробелом и по-русски) и в группах тоже именно так указываются в поле member.

Поэтому на этапе получения списка пользователей для группы я из этой конструкции не могу получить нормальный jabber id. Помогите пожалуйста подобрать рабочие параметры для получения юзеров группы!

Абсолютно верно. Но в связи с

freebeer — Fri, 07 Oct 2011 13:18:45 +0000

Абсолютно верно.
Но в связи с тем, что web уже вшит mod_shared_roster, это войдет в противоречие с изложенной выше концепцией.
IMHO, для реализации необходимо вынести в отдельный модуль часть mod_shared_rosterа, которая только отдает список из локального хранилища пользователю.
Хотя может быть имеет смысл оставить возможность управления через web правилами отображения?

Плюс реализовать хелпер, который будет скрывать доступ к локальному хранилищу (организовывать его через API).
В хелпер можно также добавить вызовы для процедур пре/постобработки(это позволит осуществить действия с информацией в локальном хранилище перед и после загрузки,например вызов хранимок).

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

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

В плане реализации, признаюсь честно, проблемы три
- очень плотный рабочий график
- отсутствие опыта разработки на erlang и парадигме erlang
- просто страшно :D, т.к. в проекте есть ядро разработчиков и roadmap, и влезать со своим самоваром...

Если подытожить, Вы

mikekaganski — Tue, 04 Oct 2011 08:53:17 +0000

Если подытожить, Вы предлагаете сделать альтернативный интерфейс управления (наполнения) mod_shared_roster (в дополнение к единственному на данный момент веб-интерфейсу).

В принципе, почему бы и нет.
Для этого потребуется отобразить схему LDAP на схему БД (ну, конечно, только её малой части :)).
Можете попробовать, это было бы интересно.

Благодарю за подробный

freebeer — Tue, 04 Oct 2011 04:01:17 +0000

Благодарю за подробный ответ!

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

Идея, которую пытался изложить, сводится к следующему:
- Вызовы LDAP дорогие. Язык построения запросов достаточно специфичен.
Используемые поля записей в LDAP зависят от реализации.
- Вызовы к локальной базе - относительно дешевые. Язык запросов более гибок. Структура может быть унифицирована.
- Изменение параметров пользователей в корпоративных системах происходят нечасто.
При такой стоимости запросов проще один раз на достаточно большом промежутке времени выгрузить данные в промежуточное хранилище (локальную базу) и по мере необходимости дергать ее (локальную базу).

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

Таким образом, в предлагаемом решении LDAP отображается на "обычную" базу и далее, используя Ваши слова:
"они обычно имеют быстрые каналы связи с ejabberd, и их собственные методы кэширования гораздо лучше справятся с задачей оптимизации времени доступа."

- при этом возникает возможность влиять на изменение информации в момент загрузки ее в промежуточное хранилище (это делает специальный коннектор) и в момент формирования списка для пользователя (а это делает коннектор общего назначения). Если при этом прикрутить скриптовую логику пре/пост обработки, то получиться веселый механизм...:) Причем скриптовая логика постобработки в хранилищах на основе SQL серверов практически уже реализована,а стоимость обработки в локальной базе будет приемлемой даже при достаточно сложных алгоритмах.

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

мы с Вами, видимо, работаем на значительно разных по качеству линиях связи. :)

- по поводу тезиса

"А вот насчёт задачи отображения данных - это Вы, извините, путаете mod_shared_roster_ldap и программу-клиент :)"

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

На необходимости изменений не настаиваю. Модуль в существующем варианте весьма функционален и значительно облегчает нам жизнь, за что Вам большое спасибо!!!
Но всегда хочется чего-то еще...:D

Таким образом, в предлагаемом

freebeer — Mon, 03 Oct 2011 17:01:19 +0000

Таким образом, в предлагаемом решении LDAP отображается на "обычную" базу и далее, используя Ваши слова:

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

- по поводу тезиса

а это может случиться очень нескоро, так что, вероятнее всего, кэш вообще не будет использован.

мы видимо работаем на значительно разных по качеству линиях связи. :)

- по поводу тезиса

А вот насчёт задачи отображения данных - это Вы, извините, путаете mod_shared_roster_ldap и программу-клиент :)

Благодарю за подробный

freebeer — Mon, 03 Oct 2011 15:00:29 +0000

Благодарю за подробный ответ!

С архитектурой действительно вглубь не лез.

Идея, которую пытался изложить, сводится к следующему:
- Вызовы LDAP дорогие. Язык построения запросов достаточно специфичен.
Используемые поля записей в LDAP зависят от реализации.
- Вызовы к локальной базе - относительно дешевые. Язык запросов более гибок. Структура может быть унифицирована.
- Изменение параметров пользователей в корпоративных системах происходят нечасто.
При такой стоимости запросов проще один раз выгрузить данные в промежуточное хранилище
(локальную базу) и по мере необходимости дергать ее (локальную базу). Таким образом LDAP отображается на "обычную" базу и далее, используя Ваши слова:

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

- по поводу тезиса

а это может случиться очень нескоро, так что, вероятнее всего, кэш вообще не будет использован.

мы видимо работаем на значительно разных по качеству линиях связи. :)

- по поводу тезиса

А вот насчёт задачи отображения данных - это Вы, извините, путаете mod_shared_roster_ldap и программу-клиент :)

freebeer wrote: Извиняюсь,

mikekaganski — Wed, 21 Sep 2011 10:53:18 +0000

freebeer wrote:

Извиняюсь, что вмешиваюсь

Добро пожаловать :)

Quote:

но мне вообще не нравится концепция построения модуля.
В нем одновременно решаются задачи получения, форматирования и отображения данных.

Насчёт форматирования - посмотрите мой вопрос, заданный 13 августа на эту тему. Насчёт остальных задач - напишу ниже.

Quote:

Также частично дублируется функционал уже существующего модуля (mod_shared_roster)

Какой?

Quote:

Считаю, что модуль должен быть разрезан на две части:
1 - коннектор для загрузки в базу информации о пользователях
2 - ростер, отвечающий только за отображение информации из заранее сформированного хранилища (т.е. практически унификация существующего shared rostera).

Функционал по загрузке данных должен быть выброшен в коннектор, который отвечает за частоту и состав обновления из указанного источника (необязательно LDAP)
В коннекторе предусмотреть возможность постобработки выбранных данных.
Т.е. предлагается такая схема работы
- коннектор вытягивает в базу данные, ограниченные простейшими правилами (недостаток - объем трафика, компенсируется кэшированием в базе сервера).
- коннектор на этапе постобработки форматирует данные при помощи механизмов работы с БД сервера (этим снижаются накладные расходы и повышается гибкость).
- коннектор удаляет записи, у которых истек срок существования
- коннектор оповещает модуль ростера, что данные были обновлены.
- коннектор переходит в режим ожидания

Считаю что такая схема организации ростера позволит
- упростить разработку
- создать универсальный механизм получения данных для ростера
- сделать представление данных в ростере более гибким

Porridge уже пытался ответить Вам. Но его ответ, по-видимому, Вас не убедил.
Попробую я :)

Вы неправильно представляете себе архитектуру этого модуля (а также mod_shared_roster и в целом ejabberd). Вообще-то как раз предлагаемая Вами архитектура и реализована.

Модуль, обозначенный Вами как "ростер" (пункт 2) - это mod_roster, который занимется (унифицированным) сбором ростера из разных источников, чтобы потом передать его клиенту.

Модуль-коннектор - это и есть один из модулей mod_shared_roster(_ldap). Этот модуль вызывается модулем mod_roster в момент, когда идёт формирование ростера пользователя, и mod_roster уже подготовил персональный список для данного пользователя. Задачей mod_shared_roster(_ldap) является соединение с "базой" для получения административно заданного дополнительного списка для данного (обратите на это внимание) пользователя. Причём разработчики ejabberd уже проделали большую работу по унификации получения данных - насколько это было возможно: если Вы посмотрите на структуру модулей версии 3, там Вы не найдёте mod_roster_odbc или mod_vcard_odbc: те хранилища, которые были концептуально сходны, были вынесены в слой подключаемых хранилищ. LDAP принципиально отличается от остальных back-ends, поддерживаемых ejabberd: здесь схема данных не определяется ejabberd; эта база только для чтения; эта база обычно занята более важными делами, чем обслуживание системы обмена мгновенными сообщениями; её использование практически гарантированно говорит о корпоративном использовании ejabberd. Поэтому попытка сключить её в общую схему привела бы к ненужному усложнению кода, призванного эффективно работать с "обычными" базами (Mnesia/ODBC), при этом не давая никакой выгоды.

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

При этом для "обычных" баз это не приведёт ни к каким преимуществам: они обычно имеют быстрые каналы связи с ejabberd, и их собственные методы кэширования гораздо лучше справятся с задачей оптимизации времени доступа. Для таких систем (а их - большинство) предложенная Вами схема с дополнительным уровнем кэширования лишь увеличит требования к памяти/CPU и ухудшит их работу.

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

Теперь про коннектор LDAP. Он как раз и реализует Ваши идеи. Он вообще работает по принципу, отличному от mod_shared_roster. Заявленное Вами "дублирование" функционала mod_shared_roster - вообще нонсенс: если Вы посмотрите исходный код этих модулей, Вы не найдёте ни одной функции, которая была бы идентичной для обоих модулей. Они все крайне специфичны и оптимизированы для выполняемых ими (разных для каждого модуля!) задач.

Кэширование в этом модуле полезно и эффективно: во-первых, здесь наполнение общего ростера гораздо более унифицировано для всех пользователей, чем в обычном mod_shared_roster, а во-вторых, нужно учитывать, что серьёзные админы доменов обычно не сильно радуются дополнительной нагрузке на свои контроллеры со стороны говорилок (естественно, имеются ввиду серьёзные и часто распределённые, в т.ч. географически, организации).
И в этой связи - замечание относительно "задач форматирования и отображения данных". Задача форматирования данных могла бы решаться аналогично тому, как это сделано в mod_shared_roster - т.е. с использованием специально предназначенного для этих целей mod_vcard(_ldap) (и да, это можно было бы тогда унифицировать) (см. мой вопрос, ссылку на который я дал выше). Но тогда, как я там написал, это приведёт к многократно растущей нагрузке на базу (что допустимо для "обычных" баз, но в случае LDAP сведёт на нет любые механизмы оптимизации, в т.ч. предлагаемые Вами). Так что можете рассматривать эту конкретную особенность данного модуля специфической оптимизацией, реализованной с использованием знания особенностей механизма работы с БД сервера.
А вот насчёт задачи отображения данных - это Вы, извините, путаете mod_shared_roster_ldap и программу-клиент :)

Так что я совершенно не согласен с тем, что есть необходимость в предлагаемых Вами изменениях. Повторюсь:
- mod_roster при формировании ростера пользователя унифицированно просит модули-коннекторы добавить в полусформированный ростер дополнительные записи;
- коннекторы индивидуально для каждого пользователя формируют дополнительный список;
- существует два вида коннекторов: "общего назначения", являющийся "универсальным механизмом получения данных для ростера", работающий по своей схеме и имеющий свои настройки, и специальный коннектор, заточенный под LDAP (очень сильно отличающийся по логике).

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

Извиняюсь, что вмешиваюсь, но

freebeer — Wed, 21 Sep 2011 06:17:35 +0000

Извиняюсь, что вмешиваюсь, но мне вообще не нравится концепция построения модуля.
В нем одновременно решаются задачи получения, форматирования и отображения данных.
Также частично дублируется функционал уже существующего модуля (mod_shared_roster)

из личного опыта, может

BABUT — Thu, 25 Aug 2011 23:42:01 +0000

из личного опыта, может пригодится кому:
так и не удалось полностью без косяков собрать 2.1.8 под вин, но проблему презенса можно обойти, если заменить эрланг, который ставится инсталятором, на более новую(манипуляции с оригинальной r12b4 не дают эффекта) версию(пробовал r14b01(рекомендована), r14b03(не рекомендована)- разницы не заметил). для этого из более свежей(erlang\bin, erlang\erts-<версия>\bin) версии заменяем в старой(ejabberd\bin) одинаковые по имени файлы(или тупо закидываем всё сразу), кроме erl.ini. затем в ejabberd\lib переносим erlang\lib, оставляя из старых только отсутствующие в эрланге. после этого презенс заработает, но не будет запускаться сервис- для решения оного нужно перекомпилировать(уже новым компилятором erlc) ejabberd\lib\win_service-1.0\src\win_service.erl, поместив win_service.beam в ejabberd\lib\win_service-1.0\ebin

зы: благодарность mikekaganski за объяснения и помощь

отправил на пару адресов,

BABUT — Wed, 24 Aug 2011 00:19:25 +0000

отправил на пару адресов, найденных при прохождении квеста "найди мыло" ;) не факт, что они верные и дойдёт

Боюсь, я под виндой не

mikekaganski — Tue, 23 Aug 2011 10:04:30 +0000

Боюсь, я под виндой не компилил...

Попробовал, вроде, компилится под экспрессом 2010 (configure.bat; nmake /f Makefile.win32), правда, после некоторых плясок с правкой Makefile.inc, который генерится cofigure, но, похоже, это не то... что-то там хреново. Возможно, нужно собирать под mingw.

Может быть, попробовать отловить проблему без пересборки? (Каюсь, да, это я предложил пересобрать - но я не знал, что это винда; под *nixами всё ок).

Пришлите подробные логи работы (из режима live, с уровнем логов 5, когда не отображается презенс) мне на почту. Попробуем так.

не осилил. 2.1.x собирал на

BABUT — Mon, 22 Aug 2011 10:57:54 +0000

не осилил. 2.1.x собирал на 2010 экспрессе(ну где в наш атомный век найти 6 версию?). раз сурьёзно ругнулся в src\tls\Makefile.win32 на невозможность исользования несколько сорцов в -Fo, разбил(ну как сообразил) на пару:
..
SOURCE1 = sha_drv.c
OBJECT1 = sha_drv.o
SOURCE2 = tls_drv.c
OBJECT2 = tls_drv.o
DLL1 = ..\sha_drv.dll
DLL2 = ..\tls_drv.dll
ALL : $(DLL1) $(DLL2) $(BEAMS)
..
$(DLL1) : $(OBJECT1)
$(LD) $(LD_FLAGS) -out:$(DLL1) $(OBJECT1)
$(DLL2) : $(OBJECT2)
$(LD) $(LD_FLAGS) -out:$(DLL2) $(OBJECT2)
$(OBJECT1) : $(SOURCE1)
$(CC) $(CC_FLAGS) -c -Fo$(OBJECT1) $(SOURCE1)
$(OBJECT2) : $(SOURCE2)
$(CC) $(CC_FLAGS) -c -Fo$(OBJECT2) $(SOURCE2)
в итоге они собрались, но сам(а что вообще должно собраться? %)) нет. последнее, что делает:
..
c:/EJABBE~1/src/web/mod_http_fileserver.erl:442: Warning: call to httpd_util:to_lower/1 will fail, since it was removed in R12B; use string:to_lower/1
cd ..\odbc
nmake -nologo -f Makefile.win32
erlc -W -I .. -pz .. -o .. ejabberd_odbc.erl
c:/EJABBE~1/src/odbc/ejabberd_odbc.erl:32: Warning: behaviour p1_fsm undefined
erlc -W -I .. -pz .. -o .. ejabberd_odbc_sup.erl
erlc -W -I .. -pz .. -o .. -Dgeneric odbc_queries.erl
cd ..
build target does not exist
ALL target does not exist
и конечно werl -s ejabberd -name ejabberd крашится.
тема непопулярная..:\ может какие-нибудь хинты? ;)

я ни как не пойму почему не

kozakman — Thu, 18 Aug 2011 14:15:06 +0000

я ни как не пойму почему не работает версия модуля от 03.08.2011г. и вообще он способен работать с OpenLDAP ? В общем конфиг такой:

{mod_shared_roster_ldap, [
{ldap_servers, ["192.168.100.7"]},
{ldap_group_base, "ou=testing,ou=addressbook,dc=example,dc=com"},
{ldap_rfilter, "(objectClass=organizationalUnit)"},
%%{ldap_groupattr, "ou"},
{ldap_gfilter, "(&(objectClass=organizationalUnit)(ou=%g))"},
{ldap_groupdesc, "description"},
{ldap_member_selection_mode, group_children},
{ldap_ufilter, "(&(objectClass=inetOrgPerson)(cn=%u))"},
{ldap_userdesc, "displayName"},
{ldap_auth_check, off}
%%{ldap_useruid, "cn=%u"}
]},

в логах ежика никаких ошибок нет, вообще никаких рапортов.

структура ldap http://s1.ipicture.ru/uploads/20110818/TB1JrU45.png

ткните пальцем, совсем голову сломал

да, бинарник. попробую(займёт

BABUT — Tue, 09 Aug 2011 23:32:31 +0000

да, бинарник. попробую(займёт время, навалилось работы)
не со зла, не знал о существовании EJAB-1480. наткнулся при поиске актуальной версии, не прочитал дальше нескольких верхних каментов- виноват, исправился сразу, как только поиск повторно, уже на тему презенса, привёл туда же, но было поздно -.-