LINUX.ORG.RU
Форум — Admin  

ejabberd, не совсем стандартная ситуация

 ,


1

2

Всем здравствуйте!

Ситуация следующая:

  1. Есть 2 домена (domain1.ru, domain2.ru) и несколько офисов без доменова(и соответсвенно ldap).
  2. Есть ejabberd сервер, пока тестовый;
  3. есть задача сделать чат всех-со-всеми, т.е. оба домена и всех остальных. При этом одни(2 домена) авторизуются по LDAP(mod_auth_ldap),при этом другие, «внедоменные» авторизуются локально(mod_auth, internal);
  4. общий ростер все-со-всеми;
  5. логирование переписки и передачи файлов.

Так вот, как это вижу я:

  1. сервер ejabberd (localhost);
  2. на нём три virtualhost'a (2 для доменов, 1 для localhost);
  3. авторизация настроена под каждый virtualhost (2 по {mod_auth,ldap}, 1 по {mod_auth,internal};
  4. общий ростер (какой я пока не понял см.ниже);
  5. база mnesia или mysql (см.ниже).

Вопросы:

  1. Возможно ли вообще такую схему построить на ejabberd?
  2. Как правильно настроить virtualhost'ы?
  3. Как и где хранить для этого информацию? В mysql?
  4. Как сделать общий ростер для трех вирт.хостов?
  5. Есть ли у кого-нибудь опыт в построении мульти-доменных схем в jabber?

Документации прочитал много, копал по форумам, примеров толковых так и не нашел. Стартовал ветку на ejabberd.im, там тишина.

Заранее очень признателен!



Последнее исправление: beastie (всего исправлений: 1)

Все можно, кроме общего ростера из LDAP. Придется добавлять руками/скрипт. Будут вопросы, пиши, я такую схему реализовал в бою.

uspen ★★★★★
()

Только виден такой ростер будет только ежабберам с лдапом

  mod_shared_roster_ldap:
    ldap_base: "dc=root"
    ldap_rfilter: "(cn=jabber-group)"
    ldap_filter: "(ObjectClass=*)"
    ldap_gfilter: "(cn=jabber-group)"
    ldap_ufilter: "(&(uid=%u)(memberOf=cn=jabber-group,dc=root))"
    ldap_groupattr: "cn"
    ldap_groupdesc: "description"
    ldap_memberattr: "member"
    ldap_userdesc: "displayName"
    ldap_userid: "uid"
    ldap_memberattr_format_re: "cn=([\\w\\.\\-]*),ou=.*,dc=root"
sergej ★★★★★
()

В принципе мнезия умеет расползаться по нодам, но нужно очень хорошо уметь ее готовить.

Ёж это отличная система и в нем можно все. Что не устраивает - допиливается с легкостью ;) на эрланг.

anonymous
()

Может быть, оставите свой e-mail? Тоже есть пара вопросов по Джабберу, а как законтачить через личку - не нашел.

anonymous
()
Ответ на: комментарий от monahoff

Привет. Надо было в профиль глянуть и увидеть там мой email. Уже снял его, не хочу палица.

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

uspen ★★★★★
()
Ответ на: комментарий от anonymous

Да там костылестроение, просто логика нужна, могу подсказать. Сначала цель создать файл ростера, который запушится аккаунту. У меня LDAP. Скрипт принимает аргументы двух файлов. В одном список (user@example.com) КОМУ добавить, в другом список КОГО добавить в ростер. Далее скрипт берет инфу об аккаунтах из LDAP и обрабатывает ее, например, заворачивает в base64, парсит на отсутствие полей и т.д. в итоге создает файл вида {«$user», «$host», «$group», «$fn»}, это и есть ростер. И в итоге пушит: /usr/sbin/mongooseimctl push_roster «${dir_roster}/roster_${list2}» «$user1» «$host1». Обязательное условие: файл ростера должен находится внутри рабочей директории жабера. И я использую mongooseIM вместо ejabberd.

Вот и все. То есть мы создаем два файла со списком и даем их как аргумент скрипту, который формирует файлы ростера и отдает ростер аккаунту.

Формировать эти два файла можно и автоматически (для постоянной актуализации) ведь между доменами автоматически из LDAP не берет!

Пример файла ростера:

[
{"s.user", "example.com", "example-RUSSIA::MOSCOW::example office::Financial department", "user Сергей Васильевич"},
{"yu.user", "example.com", "example-RUSSIA::MOSCOW::Office in example::Visa department", "user Юлия Алексеевна"},
{"n.user", "example.com", "example-RUSSIA::MOSCOW::Office in example::PR department", "user Наталья Александровна"}
].

uspen ★★★★★
()
Ответ на: комментарий от uspen

И потом красота! Мы используем vacuum-im. И ростер получается древовидным - Страна, Город, Офис, Отдел, Сотрудник.

uspen ★★★★★
()
Ответ на: комментарий от uspen

А через vacuum-im вам удалось настроить gssapi-auth через kerberos? Чтобы вот прямо SSO, пользователь залогинился и сразу онлайн, без утомительного ввода паролей?

anonymous
()
Ответ на: комментарий от uspen

1) Выявили ли какие-нибудь преимущества в эксплуатации MongooseIM перед традиционным eJabberd? Стабильность, потребление ресурсов т.п. Какое кол-во пользователей обслуживаете? 2) в чем храните конфигурацию/данные - в mnesia или в mysql? 3) Корректно ли MongooseIM работает с другими серверами XMPP с самоподписанными сертификатами? eJabberd версии 2 и Prosody на моей памяти отказывались работать в s2s режиме с самопальными сертификатами.

anonymous
()
Ответ на: комментарий от anonymous

1) Досконально не тестировал. Тем более ранее было шесть серверов ejabberd в кластере. Сейчас один MongooseIM для той же цели и не корректно сравнивать. Но он один держит, есть не просит, систему почти не нагружает (VM@KVM). Ни падал, перезагружался всегда идеально. Юзеров мало, около 400 в пик.
2) mnesia. История пишется принудительно в mysql.
3) Нет пока такого применения в бою. Просто сам со своим «домашним» стыковался, все ок было.

uspen ★★★★★
()
Ответ на: комментарий от uspen

1) можно узнать конфигурацию виртуальной машины под это дело?

2) а чем смотрите из mysql историю, если что? У меня она пока в html пишется, хотелось бы в базу, но смущает «чем ее доставать потом оттуда»...

3) у вас и на домашнем сервере, и на рабочем самоподписанные сертификаты?

4) используете ли каких-либо xmpp ботов?

anonymous
()
Ответ на: комментарий от anonymous

1) 2 ядра от 24 ядерной машины на Intel(R) Xeon(R) CPU X5660@2.80GHz, 4G RAM.
2) В mysql пишется история по XEP-0313, в базу она ложится в бинарном виде. Поэтому читать тоже нужно по протоколу. Мы не читаем, но если безопасники просят, то логинимся под юзером, которого нужно прочитать и выполняем xml запросы, вместо удобного клиента. По сути вручную. Как есть (
3) Да
4) Нет

uspen ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin