[devel] I: Jabber policy, jabber-config, jabberd2

[devel] I: Jabber policy, jabber-config, jabberd2

[Mikhail Yakshin]

Приветствую всех!

В Сизиф 2 дня назад отправлены пакеты jabber-common и ejabberd, в 
которых реализована функциональность, которую условно можно назвать 
jabber-config. Подробнее ее идея описана в "Jabber policy", кратко 
сообщу детали ее реализации:

============================================================================

1. Есть пакет jabber-common, в котором есть:

* директории /usr/share/jabber/server, /usr/share/jabber/component
* скрипт "сделать-все-хорошо" /usr/sbin/jabber-config
* RPM-макросы /etc/rpm/macros.d/jabber, указывающие на эти директории и 
для вызова этого скрипта, сейчас такие вот:

%_jabber_server_dir %_datadir/jabber/server
%_jabber_component_dir %_datadir/jabber/component
%_jabber_config %_sbindir/jabber-config

2. Для каждого джаббер-сервера в Сизифе предлагается добавить следующие 
вещи:

* Req и BuildReq на jabber-common в спек
* вызов %_jabber_config в post-install
* написать маленький скрипт-адаптер, который бы лежал в 
%_jabber_server_dir/имя_сервера и который бы, будучи вызванный с 
параметрами --port=... --host=... --password=... регистрировал 
соответствующий компонент в конфиге сервера.

Пример есть в виде сервера ejabberd.

3. Для каждого джаббер-компонента в Сизифе предлагается добавить следующее:

* Req и BuildReq на jabber-common в спек
* вызов %_jabber_config в post-install
* скрипт-адаптер в %_jabber_component_dir/имя_компонента, который бы при 
вызовах с параметрами --port, --host, --password отдавал бы 
соответствующие значения из конфига компонента.

Пример скрипта для mrim есть в предыдущем письме:
http://lists.altlinux.org/pipermail/devel/2007-March/042616.html

============================================================================

Кроме этого, в процессе общения с новым мейнтейнером jabberd2, был 
выяснен следующий факт: по умолчанию, его роутер принимает соединения от 
всех компонентов на один порт - 5437, различая компоненты по хостнейму, 
которые они ему говорят, и паролю. ejabberd, кажется, умеет так же 
работать - слушая несколько возможных компонентов на 1 порте. jabberd1.4 
так точно не умеет работать. Wildfire - не знаю, не проверял.

Альтернативы, которые у нас есть - либо:
1) паковать все компоненты на 5437 порт, отбросить поддержку jabberd1.4;
2) паковать все компоненты на разные порты, сделать (возможно, запатчив) 
в jabberd2 поддержку прослушки;
3) хитро переделать всю систему в обратную сторону - чтобы порт 
передавался компоненту в зависимости от установленного сервера;

Вопрос: что кому больше нравится, нужна ли нам более универсальная 
система, которая бы поддерживала в том числе и jabberd1.4 и как обстоят 
дела с этим у Wildfire?

============================================================================

Предыдущие серии см. в
http://lists.altlinux.org/pipermail/devel/2007-March/042592.html
http://lists.altlinux.org/pipermail/devel/2007-March/042616.html

-- 
WBR, Mikhail Yakshin

Re: [devel] I: Jabber policy, jabber-config, jabberd2

[Mikhail Yakshin]

Mikhail A. Pokidko wrote:
> 15.03.07, *Mikhail Yakshin* написал(а):
> 
>     Альтернативы, которые у нас есть - либо:
>     1) паковать все компоненты на 5437 порт, отбросить поддержку jabberd1.4;
> 
> 5347, все же

Да, согласен, извиняюсь, опечатался.

>     2) паковать все компоненты на разные порты, сделать (возможно, запатчив)
>     в jabberd2 поддержку прослушки;

>     3) хитро переделать всю систему в обратную сторону - чтобы порт
>     передавался компоненту в зависимости от установленного сервера;

>     Вопрос: что кому больше нравится, нужна ли нам более универсальная
>     система, которая бы поддерживала в том числе и jabberd1.4 и как обстоят
>     дела с этим у Wildfire?

> Я лично за вариант 1, поскольку поддержка jabberd1.4, фактически, будет 
> заключаться в "не напрягать пожилого трудягу и дать ему спокойно уйти на 
> заслуженый отдых" --  его и в сизифе-то нет уже.
> А вот с Wildfire стоит подумать, как и что он умеет

Тут немножко более сложный вопрос - если мы хотим закрыть ровно то, что 
в Сизифе - то да, возможно. Если мы хотим предложить сообществу некий 
более универсальный вариант и таки сделать его более-менее 
стандартизованной схемой для всех - то придется поддерживать и такие 
вещи. А там, вообще говоря, хорошо это или плохо, но за jabberd 1.4 
тянется огромнейший хвост legacy, который до сих пор стоит толпами много 
где.

-- 
WBR, Mikhail Yakshin

Re: [devel] I: Jabber policy, jabber-config, jabberd2

[Sergey V Turchin]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

On 16 марта 2007, Mikhail Yakshin wrote:

[...]
> А там, вообще говоря, хорошо это или
> плохо, но за jabberd 1.4 тянется огромнейший хвост legacy,
> который до сих пор стоит толпами много где.
А он вообще-то пока далеко не помер.
В jabberd14-1.6.0 добавили xml:lang для конфигов, например.
А этого нет ни в egabberd, ни в jabberd2 пока.

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: Jabber policy, jabber-config, jabberd2

[Mikhail Gusarov]

Twas brillig at 18:57:11 15.03.2007 UTC+03 when Mikhail Yakshin did gyre and gimble:

 MY> 3) хитро переделать всю систему в обратную сторону - чтобы порт 
 MY> передавался компоненту в зависимости от установленного сервера;

Третий вариант кажется самым общим, но при этом per-server скрипты усложнятся. Я
бы предложил слегка изменённый сценарий:

3.1)

* сервер сообщает посреднику, какой режим работы он поддерживает (скажем,
  выкладыванием маркерного файла в определённое место. естественно, при этом
  маркерный файл должен быть нужен только в редких случаях).

* посредник, в соответствии с возможностями сервера, распределяет порт(ы).

Плюсы 

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

* скрипты поддержки в сервере и посреднике оказываются простыми настолько,
  насколько возможно.

-- 
JID: dottedmag@jabber.dottedmag.net

Re: [devel] I: Jabber policy, jabber-config, jabberd2

[Mikhail A. Pokidko]

15.03.07, Mikhail Yakshin написал(а):
> 3. Для каждого джаббер-компонента в Сизифе предлагается добавить следующее:
>
> * Req и BuildReq на jabber-common в спек
> * вызов %_jabber_config в post-install
> * скрипт-адаптер в %_jabber_component_dir/имя_компонента, который бы при
> вызовах с параметрами --port, --host, --password отдавал бы
> соответствующие значения из конфига компонента.

Возникла мысль, что скрипт-адаптер еще должен уметь отдавать ip.
host ведь для disco?

Иными словами,
% Jabber ICQ Transport
 {$PORT, ejabberd_service, [{ip, {$IP}},
                           {access, all},
                           {hosts, ["$HOST"], [{password, "$PASSWORD"}]}]},


-- 
Mikhail A. Pokidko
ALTLinux Team
e-mail: pma@altlinux.org
jid: solar@gmail.ru

Re: [devel] I: Jabber policy, jabber-config, jabberd2

[Mikhail Yakshin]

Mikhail A. Pokidko пишет:
> 15.03.07, Mikhail Yakshin написал(а):
>> 3. Для каждого джаббер-компонента в Сизифе предлагается добавить следующее:
>>
>> * Req и BuildReq на jabber-common в спек
>> * вызов %_jabber_config в post-install
>> * скрипт-адаптер в %_jabber_component_dir/имя_компонента, который бы при
>> вызовах с параметрами --port, --host, --password отдавал бы
>> соответствующие значения из конфига компонента.
> 
> Возникла мысль, что скрипт-адаптер еще должен уметь отдавать ip.
> host ведь для disco?
> 
> Иными словами,
> % Jabber ICQ Transport
>  {$PORT, ejabberd_service, [{ip, {$IP}},
>                            {access, all},
>                            {hosts, ["$HOST"], [{password, "$PASSWORD"}]}]},

Зачем IP? Мы всегда рассматриваем только случай нахождения и сервера и
транспорта на локалхосте. В общем случае - "давайте поставим сервер и он
автоматом потыкается в ближайшую сеть и найдет транспорты, которые к
себе подключить" - это уже задача куда более сложная, и, честно говоря -
по-моему - достаточно бесполезная. Можно нагородить, конечно, что-то
вроде zeroconf, только зачем? Администратор, который ставит такую
сложную инфраструктуру серверов с вероятностью -> 1 захочет настроить ее
руками так, как ему надо.

-- 
WBR, Mikhail Yakshin AKA GreyCat

Re: [devel] I: Jabber policy, jabber-config, jabberd2

[Mikhail A. Pokidko]

27.03.07, Mikhail Yakshin написал(а):

> Зачем IP? Мы всегда рассматриваем только случай нахождения и сервера и
> транспорта на локалхосте. В общем случае - "давайте поставим сервер и

А как же
>Rationale: транспорт не должен зависеть от сервера, т.к. сервер может не
>быть в одном окружении с транспортом (на одной физической или
>виртуальной машине).
?

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


-- 
Mikhail A. Pokidko
ALTLinux Team
e-mail: pma@altlinux.org
jid: solar@gmail.ru