Нестандартное взаимодействие jabber-серверов (одно доменное имя на всех)

[Denjs]

Господа) вопрос по поводу серверов и развертывания жабы в рамках распределенной структуры предприятия.

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

1) Существует предприятие, у которого много отделов. Различные отделы располагаются в разных местах, удаленных территориально. Связь между отделами - интернет канал, часто прерываемый.
2) В каждом из отделов должен стоять собственный жаба-сервер, что бы передачу файлов и обмен сообщениями не выходящими за рамки отдела (локальный адресат) не выпускать наружуа разруливать локально. (интернет трафик дорогой)
3) При этом, необходима авторизация по имени в едином домене вида user@domain.dom где @domain.dom - одинаково у всех пользователей всех отделов.
4) при обрыве связи отдела с другими отделами, локальный jabber-сервер должен продолжать работать автономно, в том числе и авторизировать клиентов из локальной сети. Желательно что бы и сотрудников других отделов, приехавших в командировку.

Что можете предложить?

[fed71]

Господа) вопрос по поводу серверов и развертывания жабы в рамках распределенной структуры предприятия.

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

1) Существует предприятие, у которого много отделов. Различные отделы располагаются в разных местах, удаленных территориально. Связь между отделами - интернет канал, часто прерываемый.
2) В каждом из отделов должен стоять собственный жаба-сервер, что бы передачу файлов и обмен сообщениями не выходящими за рамки отдела (локальный адресат) не выпускать наружуа разруливать локально. (интернет трафик дорогой)
3) При этом, необходима авторизация по имени в едином домене вида user@domain.dom где @domain.dom - одинаково у всех пользователей всех отделов.
4) при обрыве связи отдела с другими отделами, локальный jabber-сервер должен продолжать работать автономно, в том числе и авторизировать клиентов из локальной сети. Желательно что бы и сотрудников других отделов, приехавших в командировку.

Что можете предложить?

Для начала почитать здесь ТЫЦ

[Denjs]

Господа) вопрос по поводу серверов и развертывания жабы в рамках распределенной структуры предприятия.

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

1) Существует предприятие, у которого много отделов. Различные отделы располагаются в разных местах, удаленных территориально. Связь между отделами - интернет канал, часто прерываемый.
2) В каждом из отделов должен стоять собственный жаба-сервер, что бы передачу файлов и обмен сообщениями не выходящими за рамки отдела (локальный адресат) не выпускать наружуа разруливать локально. (интернет трафик дорогой)
3) При этом, необходима авторизация по имени в едином домене вида user@domain.dom где @domain.dom - одинаково у всех пользователей всех отделов.
4) при обрыве связи отдела с другими отделами, локальный jabber-сервер должен продолжать работать автономно, в том числе и авторизировать клиентов из локальной сети. Желательно что бы и сотрудников других отделов, приехавших в командировку.

Что можете предложить?

Для начала почитать здесь ТЫЦ

прошу прощения, но вы вчитались что мне надо?

мне важно совмещение пунктов 2 и 3 - т.е. сети распределенных серверов, которые поддерживают и синхронизируют между собой список контактов из одного домена, и при этом способны работать автономно.

имхо, это более вопрос способен ли джаббер так работать впринципе.

Если там есть такая информация - то извините, не вьехал. но по моему там ничего такого нет.

[fed71]

2 Denjs
А в чем спственно проблема? Джаббер тем и славен, что является децентрализованным. Поясняю
1. В каждом отделении свой джаббер-сервер для "внутреннего потребления"
2А. Один джаббер-сервер выделяется под общий для всех отделений (нужен доступ к нему из нета)
2Б. Используется один из свободных серверов типа jabber.ru или jabber.org
3. Клиент типа Pidgin, SIM, QIP Infium у каждого с соответствующими аккаунтами - достаточно одного на комп
На вскидку так. Или опять не то?

[/dev/random]

На вскидку так. Или опять не то?

Опять не то. Он ищет способ реализовать такую схему:
два (для примера) сервера: 192.168.1.12 и 192.168.2.12. К первому подключается пользователь vasya@bungalo.net, к другому - pupkin@bungalo.net (обратите внимание! Доменное имя ОДНО И ТО ЖЕ!!!), и общаются друг с другом.

Ответ на вопрос. Теоретически, можно написать "распределённый джаббер-сервер", действующий таким образом. Но сомневаюсь, что его кто-то написал, ибо очень специфическая область применения. С обычными серверами такое не прокатит, нужно давать разные имена.

[Denjs]

2 Denjs
А в чем спственно проблема? Джаббер тем и славен, что является децентрализованным. Поясняю
1. В каждом отделении свой джаббер-сервер для "внутреннего потребления"
2А. Один джаббер-сервер выделяется под общий для всех отделений (нужен доступ к нему из нета)
2Б. Используется один из свободных серверов типа jabber.ru или jabber.org
3. Клиент типа Pidgin, SIM, QIP Infium у каждого с соответствующими аккаунтами - достаточно одного на комп
На вскидку так. Или опять не то?

хорошо. тогда на пальцах. Нужна выполнимость следующего сценария:

Есть сервер отделения А - ServerА - в своем сегменте сети.
Есть сервер отделения В - ServerВ - в другом сегменте сети.

Клиент Alise подключается к серверу ServerА и авторизируется под ником Alise@domain.dom
Клиент Bob подключается к серверу ServerB и авторизируется под ником Bob@domain.dom
Клиент Charlie подключается к серверу ServerB и авторизируется под ником Charlie@domain.dom

При этом связь и интернетом есть и все они встроем могут обмениваться сообщениями.

После этого сегмент с ServerА отваливается от сети вообще и интернета в частности. Alise "отваливается" и не может более болтать с Бобом и Чарли.
После этого Bob отключается физически от своего сервера и физически подключается к сегменту сервера ServerA и авторизируется на этом сервере под своим старым ником Bob@domain.dom (при том, что связь ServerА с интернетом и остальной сетью по прежнему отсутствует).
После чего они с Alise болтают про жЫзнь и вообще, а Charlie думает почему Alise и Bob постоянно в оффлайне до тех пор пока связь между ServerА и ServerВ не восстановится.

Отметьте при этом что везде - при всех авторизациях используется одно доменное имя domain.dom.
Может ли Jabber-система "найти" пользователя, который подключается к разным серверам с одним именем?

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

Ответ на вопрос. Теоретически, можно написать "распределённый джаббер-сервер", действующий таким образом. Но сомневаюсь, что его кто-то написал, ибо очень специфическая область применения. С обычными серверами такое не прокатит, нужно давать разные имена.

ВОТЪ )... этого йа и боялсцо. (вы ответили пока я писал историю выше)

и как быть? писать самим не вариант... хотя в принципе-то мы можем такое написать, но нужен спонсор/заказчик...

[fed71]

А вот тут я в ступоре

После этого сегмент с ServerА отваливается от сети вообще и интернета в частности. Alise "отваливается" и не может более болтать с Бобом и Чарли.

Плюс разнесенные в пространстве сервера с ОДНИМ доменным именем? А на джаббер-сервере как-то еще предполагается база с аккаунтами...
System Down.................

[Denjs]

А вот тут я в ступоре

После этого сегмент с ServerА отваливается от сети вообще и интернета в частности. Alise "отваливается" и не может более болтать с Бобом и Чарли.

Плюс разнесенные в пространстве сервера с ОДНИМ доменным именем? А на джаббер-сервере как-то еще предполагается база с аккаунтами...
System Down.................

Вот вот! именно) я тоже.

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

ПРОЕКТ-ПРЕДЛОЖЕНИЕ по расширению межсерверного взаимодействия Jabber-серверов.
Механизм "Гостевые клиенты - авторизация на чужом сервере".

Есть сервер отделения А - ServerА - в своем сегменте сети. У него доменное имя server-a.domain.dom
Есть сервер отделения В - ServerВ - в другом сегменте сети.У него доменное имя server-b.domain.dom
Кроме этого есть "центральный сервер" CentralServer, у которого доменное имя просто domain.dom
(простите, я же правильно понимаю, что это технически реализуемо?)

Далее, рассматриваем процессы межсерверного взаимодействия. ServerB ведет себя аналогично ServerА, потому его не рассматриваем.
Все клиенты изначально заводятся и регистрируются на CentralServer. ServerА и ServerВ не имеют своих клиентов со своими доменными именами.
Далее, между ServerА и CentralServer настраиваются "доверительные отношения".
Т.е. пока связь есть, ServerА периодически запрашивает у CentralServer всю базу его клиентов и хешами паролей или параметрами авторизации - что бы быть способным авторизовать "гостевого клиента" у себя если вдруг будет offline.

Теперь у клиента есть 2 возможности - можно авторизоваться как на CentralServer, так и на ServerА. С первым случаем все понятно. Что со вторым вариантом?

При коннекте клиента на ServerА, сервер его авторизует, и, если есть связь, ставит в известность CentralServer, что типа "такой-то клиент из твоего домена - он у нас авторизовался", и типа "шли все его сообщения мне, если они до тебя дойдут". В крайнем случае - ServerА регистрируется на CentralServer как клиент и далее просто пересылает ему сообщения получаемые от локального-подключенного, т.е. CentralServer считает что к нему подключились обычным способом.

Если же связи нет, то ServerА работает с клиентом локально, и для всех кто не на подключен к ServerА указанный клиент находится в off-liine.

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

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

___________________
Неужели такой схемы ещё никто не сделал ни в одном из расширений протоколов или серверов?

[fed71]

2 Denjs
Попросите пожалуйста модераторов вынести Вашу тему в соответствующую ветку. Ибо с ней еще разбираться, а в тему топика она не укладывается.
На работе погляжу, что там на моем Опенфайре по взаимодействию с другими серверами.

[Denjs]

гм... наверное да)

Господа Модераторы! прошу отрезать последовательность сообщений от #383 до текущего (#392) в от дельную ветку
по причинам озвученным в сообщении выше.
Название темы - на ваше усмотрение, предлагаю "Jabber: авторизация пользователей с одним доменным именем на разных серверах? как?"

[/dev/random]

i	Уведомление от модератора
	Готово. Теперь перенесу в администрирование

[danger08]

Зачем усложнять, сделайте в филиалах сервера @dept1.domain.dom, @dept2.domain.dom и прочее. И все у вас будет работать, как вы хотите (немного телодвижений придется сделать, для межсерверного взаимодействия).

Насчет сведения в один домен: есть вариант поднятия кластера, разнесенного географически. Но насчет стабильности такой связки сомневаюсь.

[rm_]

Зачем усложнять, сделайте в филиалах сервера @dept1.domain.dom, @dept2.domain.dom и прочее. И все у вас будет работать

Тоже хочу этот вариант поддержать. Зачем городить огород, писать свой сервер и т.д.
Сделайте адреса @spb.firma.ru, @msk.firma.ru, и т.д. по территориям. Или какие-то другие названия, по вкусу.
Заодно будет всем ясно из адреса, какой сотрудник из какого филиала.

(немного телодвижений придется сделать, для межсерверного взаимодействия).

Нужно чтобы с точки зрения каждого из серверов резолвились во что-либо все сервера, с которыми он будет хотеть взаимодействовать (это раз), и чтоб был доступ к ним по порту 5269 (это два). И всё.

[Denjs]

/dev/random - сенкс за отрезание ветки.

rm_:

Зачем усложнять, сделайте в филиалах сервера @dept1.domain.dom, @dept2.domain.dom и прочее. И все у вас будет работать

Тоже хочу этот вариант поддержать. Зачем городить огород, писать свой сервер и т.д.
Сделайте адреса @spb.firma.ru, @msk.firma.ru, и т.д. по территориям. Или какие-то другие названия, по вкусу.
Заодно будет всем ясно из адреса, какой сотрудник из какого филиала.

(немного телодвижений придется сделать, для межсерверного взаимодействия).

Нужно чтобы с точки зрения каждого из серверов резолвились во что-либо все сервера, с которыми он будет хотеть взаимодействовать (это раз), и чтоб был доступ к ним по порту 5269 (это два). И всё.

блин... ещё раз: не вопрос, если вы объясните как клиент user@spb.firma.ru сможет авторизироваться на сервере msk.firma.ru, будучи в командировке и физически подключившись в его подсеть в то время когда msk.firma.ru стал временно автономным из-за проблем связи с интернетом.

Если вы глянете [ сообщение выше ] то там примерно так и есть, - на каждый департамент свой домен и свой сервер, но база клиентов у них единая которую они берут с "центрального" сервера domain.dom.

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

[fed71]

Вот накопал кое-что. Это применительно к OpenFire.
Хаутушки по настройке Server To Server http://www.igniterealtime.org/community/docs/DOC-1030
И на форумах нашлось

соединить два сервера OpenFire
как соединяются два почтовых сервера smtp? полная аналогия с серверами джаббера.
как пользователи одного почтового домена могут увидеть пользователей второго
почтового домена? никак, пока не подключаться к адресной книге второго домена..
аналог сервис броузер - сервисы второго домена - сервис поиска пользователей.
что бы все пользователи виделись прозрачно ставится кластер или сервер в офисе
и коннекшен менеджеры в офисах.

В управлении сервером
Server -> Server Settings -> Server to Server Settings [Allowed to Connect] можешь прописать с каким сервером дружить.
Server -> Server Settings -> Security Settings [Server Connection Security] можешь прописать настройки безопасности для соединений между серверами.

Поставь плагин Search, чтобы пользователи могли использовать сервис "Поиск" для поиска контактов на своем и соседнем сервере (это типа адресной книги).
http://www.igniterealtime.org/projects/ope...gins/search.jar

Друг друга сервера находят через DNS. Соответственно в DNS должны быть записи
HostA server1.org.ru
HostA server2.org.ru
и алиасы для их сервисов
ALIAS search.server1.org.ru -> HostA server1.org.ru
ALIAS search.server2.org.ru -> HostA server2.org.ru

UPD Вот еще в догонку

A simple way for you information:
Server A:
hostname:ima
IP:192.168.1.x (or internet ip)

Server B:
hostname:imb
IP:192.168.1.xx (or internet ip)

First :
You must enabled S2S's Service on Server A and Server B;
"telnet 192.168.1.x 5269" is ok on Server B and "telnet 192.168.1.xx 5269" is ok on Server A.

Step 1:
add "192.169.1.xx imb" to "C:\windows\system32\drivers\etc\hosts" file on Server A;
add "192.169.1.x ima" to "C:\windows\system32\drivers\etc\hosts" file on Server B;


Step 2:
add "imb" to "Server to Server" configuration on Server A
add "ima" to "Server to Server" configuration on Server B


Step3:
IF you login Server B and want to add user(s) who login Server A, you can use this: "[username@ima]"
IF you login Server A and want to add user(s) who login Server B, you can use this: "[username@imb]"

[Ленивая Бестолочь]

вот пожалуйста, кажется это то, что вам нужно.

[danger08]

Кластеризацию также поддерживает Openfire, но для этого требуется лицензия.

[Denjs]

вот пожалуйста, кажется это то, что вам нужно.

кластеризация - это-то хорошо. как я понимаю, я могу указывать "ejabberd node" в качестве сервера авторизации?
только по прежнему не понятно как "ejabberd node" будет вести себя при обрыве связи, т.е когда "ability to connect to port 4369 of all another nodes" выполняться не будет.
будет-ли она после обрывы связи вести себя как автономный сревер - по прежнему выполнять авторизацию и обслуживать своих клиентов?

[danger08]

вот пожалуйста, кажется это то, что вам нужно.

кластеризация - это-то хорошо. как я понимаю, я могу указывать "ejabberd node" в качестве сервера авторизации?
только по прежнему не понятно как "ejabberd node" будет вести себя при обрыве связи, т.е когда "ability to connect to port 4369 of all another nodes" выполняться не будет.
будет-ли она после обрывы связи вести себя как автономный сревер - по прежнему выполнять авторизацию и обслуживать своих клиентов?

По моему это какой-то изврат: ладно еще, мигрирующие пользователи между филиалами и территориально разбросанный кластер. Так еще и периодически выпадающие ноды кластера, работающие не пойми в каком полуавтономном режиме. И еще "чтоб работало"

[sash-kan]

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

найдите десять отличий:
от кластера из двух серверов отвалился сервер а;
от кластера из двух серверов отвалился сервер б.

erlang — вещь достаточно продуманная и обкатанная. это не столько язык программирования, сколько среда для выполнения программ. причём _распределённая_ среда. причём отказо-устойчивая среда. надеюсь, не надо напоминать о том, что ericsson является (по крайней мере) одним из ведущих производителей всякого мобильно-комунникационного оборудования, на котором erlang трудится на полную катушку?

я лично, конечно, не пробовал строить кластер из ejabberd-емонов. но, надеюсь, Алексей Щепин сотоварищи не ставили себе задачей поломать присущие erlang-у «от рождения» свойства.

Так еще и периодически выпадающие ноды кластера, работающие не пойми в каком полуавтономном режиме. И еще "чтоб работало"

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