Jabber Policy — различия между версиями

Материал из ALT Linux Wiki
Перейти к: навигация, поиск
(Import from freesource.info)
 
(+шаблон DraftPolicy)
Строка 1: Строка 1:
[[Category:Policy]]
+
{{DraftPolicy
{{MovedFromFreesourceInfo|AltLinux/Policy/Jabber}}
+
|responsible=...}}
  
Предлагаю вниманию интересующихся некий примерный проект того, как планируется организовывать инфраструктуру сборки jabber-сервисов в ALT:
+
== Инфраструктура сборки jabber-сервисов в ALT Linux ==
  
 
=== 1. Серверы ===
 
=== 1. Серверы ===
  
Есть серверы - ejabberd, jabberd2, возможно wildfire. Каждый лежит в своем пакете, ни от кого не зависит. Каждый можно поставить абсолютно отдельно, без всего. Ничего, кроме себя, опять же, они не провайдят.
+
Есть серверы — ejabberd, jabberd2, возможно wildfire. Каждый лежит в своем пакете, ни от кого не зависит. Каждый можно поставить абсолютно отдельно, без всего. Ничего, кроме себя, опять же, они не провайдят.
  
 
=== 2. Транспорты ===
 
=== 2. Транспорты ===
  
Есть транспорты, которые являются отдельными сервисами с точки зрения системы (т.е. имеют отдельный собственный [[SysV|SysV]]-init). Предпочтительно иметь в названии транспорта префикс "jabber" (jabber-jit, jabber-mrim, jabber-pyicqt и т.п.) - и в названии пакета, и в названии сервиса. Транспорт точно так же, никого не требует, никого не провайдит, кроме себя.
+
Есть транспорты, которые являются отдельными сервисами с точки зрения системы (то есть имеют отдельный собственный SysV-init). Предпочтительно иметь в названии транспорта префикс «jabber» (jabber-jit, jabber-mrim, jabber-pyicqt и т. п.) — и в названии пакета, и в названии сервиса. Транспорт точно так же, никого не требует, никого не провайдит, кроме себя.
  
Rationale: транспорт не должен зависеть от сервера, т.к. сервер может не быть в одном окружении с транспортом (на одной физической или виртуальной машине).
+
Rationale: транспорт не должен зависеть от сервера, так как сервер может не быть в одном окружении с транспортом (на одной физической или виртуальной машине).
  
 
=== 3. Теоретическое обоснование их связи ===
 
=== 3. Теоретическое обоснование их связи ===
  
Транспорты и серверы общаются между собой через протокол accept-connect через TCP/IP. Все иные варианты взаимодействия использовать рекомендуется не рекомендуется, т.к. они менее универсальны и зачастую не позволяют разнести сервер с транспортом по сети.
+
Транспорты и серверы общаются между собой через протокол accept-connect через TCP/IP. Все иные варианты взаимодействия использовать рекомендуется не рекомендуется, так как они менее универсальны и зачастую не позволяют разнести сервер с транспортом по сети.
  
Есть некая управляющая система (по механизму действия схожая с control или alternatives), которая знает о том, что есть те и другие и связывает их между собой. У системы есть один вызов типа "сделать все хорошо", который вызывается при:
+
Есть некая управляющая система (по механизму действия схожая с control или alternatives), которая знает о том, что есть те и другие и связывает их между собой. У системы есть один вызов типа «сделать все хорошо», который вызывается при:
  
 
* инсталляции нового сервера
 
* инсталляции нового сервера
 
* инсталляции нового транспорта
 
* инсталляции нового транспорта
  
"Сделать все хорошо" включает в себя прописывание всех транспортов по все серверы, если только они оттуда не были принудительно выкинуты (прописываемые строчки закомментированы).
+
«Сделать все хорошо» включает в себя прописывание всех транспортов по все серверы, если только они оттуда не были принудительно выкинуты (прописываемые строчки закомментированы).
  
Есть некая сложность в том, что во всех известных мне серверах (jabberd1.4, jabberd2, ejabberd) нет нормальной модуляризации конфига с возможностью подключения модуля через установку дополнительного кусочка конфига в какой-то каталог, а в головном конфиге иметь что-то вроде "include тот-каталог/*". Таким образом, управляющая система должна будет влезать в конфиги этих серверов и что-то исправлять (дописывать) в них вручную, при этом, разумеется, зная синтаксис каждого такого конфига.
+
Есть некая сложность в том, что во всех известных мне серверах (jabberd1.4, jabberd2, ejabberd) нет нормальной модуляризации конфига с возможностью подключения модуля через установку дополнительного кусочка конфига в какой-то каталог, а в головном конфиге иметь что-то вроде «include тот-каталог/*». Таким образом, управляющая система должна будет влезать в конфиги этих серверов и что-то исправлять (дописывать) в них вручную, при этом, разумеется, зная синтаксис каждого такого конфига.
  
 
=== 4. Практический ход их связи ===
 
=== 4. Практический ход их связи ===
Строка 32: Строка 32:
  
 
* номер порта (статический, заранее присвоенный в рамках ALT)
 
* номер порта (статический, заранее присвоенный в рамках ALT)
* hostname (генерящийся из заранее присвоенного префикса типа "mrim." + hostname)
+
* hostname (генерящийся из заранее присвоенного префикса типа «mrim.» + hostname)
 
* генерящийся случайно пароль
 
* генерящийся случайно пароль
  
Строка 38: Строка 38:
  
 
1) получить от транспорта эти данные из конфига (очевидно, система не может знать форматы конфигов всех возможных транспортов, для этого нужен маленький адаптер со стороны транспорта)
 
1) получить от транспорта эти данные из конфига (очевидно, система не может знать форматы конфигов всех возможных транспортов, для этого нужен маленький адаптер со стороны транспорта)
2) поправить конфиг сервера - подключить этот по полученным данным новый транспорт или проверить, что он уже подключен (опять же, система не занимается этим сама - сервер несет внутри себя некий скрипт-адаптер).
+
2) поправить конфиг сервера — подключить этот по полученным данным новый транспорт или проверить, что он уже подключен (опять же, система не занимается этим сама — сервер несет внутри себя некий скрипт-адаптер).
  
Т.е. управляющая система - это лишь некий диспетчер, который получает фиксированный набор данных от транспорта и передает его серверу.
+
То есть управляющая система — это лишь некий диспетчер, который получает фиксированный набор данных от транспорта и передает его серверу.
  
 
=== 5. Реализация ===
 
=== 5. Реализация ===
  
 
1) генерящийся конфиг со стороны транспорта (в postinstall)
 
1) генерящийся конфиг со стороны транспорта (в postinstall)
2) адаптер со стороны транспорта - скрипт а ля pkgconfig, с опциями --host, --port, --password.
+
2) адаптер со стороны транспорта — скрипт а ля pkgconfig, с опциями --host, --port, --password.
3) адаптер со стороны сервера - скрипт, которому передаются такими же опциями --host= --port= --password= параметры; после запуска скрипта появляется некая уверенность в том, что данный транспорт подключен к данному серверу.
+
3) адаптер со стороны сервера — скрипт, которому передаются такими же опциями --host= --port= --password= параметры; после запуска скрипта появляется некая уверенность в том, что данный транспорт подключен к данному серверу.
4) скрипт-диспетчер "сделать все хорошо" (в postinstall всех транспортов и серверов) - запускает все возможные комбинации адапетров серверов и транспортов и пихает их вводы-выводы друг дружке.
+
4) скрипт-диспетчер «сделать все хорошо» (в postinstall всех транспортов и серверов) — запускает все возможные комбинации адапетров серверов и транспортов и пихает их вводы-выводы друг дружке.
  
 
=== 6. Директории ===
 
=== 6. Директории ===
  
Все серверы и транспорты имеют собственные директории логов / спулов / lib и т.п., в соответствии с именем пакета. Рекомендуется использовать что-то вроде:
+
Все серверы и транспорты имеют собственные директории логов / спулов / lib и т. п., в соответствии с именем пакета. Рекомендуется использовать что-то вроде:
  
 
/var/log/ejabberd
 
/var/log/ejabberd
 
/var/log/jabber-pyicqt
 
/var/log/jabber-pyicqt
 
/var/log/jabber-mrim
 
/var/log/jabber-mrim
...
+
 
/var/lib/ejabberd
 
/var/lib/ejabberd
 
/var/lib/jabber-pyicqt
 
/var/lib/jabber-pyicqt
 
/var/lib/jabber-mrim
 
/var/lib/jabber-mrim
...
+
 
/var/spool/ejabberd
 
/var/spool/ejabberd
 
/var/spool/jabber-pyicqt
 
/var/spool/jabber-pyicqt
 
/var/spool/jabber-mrim
 
/var/spool/jabber-mrim
...
+
  
 
=== 7. Пользователи ===
 
=== 7. Пользователи ===
  
В соответствии с [[[UidGid|UidGid]]], предлагается для каждого сервера и компонента иметь отдельного псевдопользователя, соответствующего имени пакета. Для серверов, как правило, имеющих в своем названии "jabber" это будет просто ejabberd, jabberd14, jabberd2 и т.п., для компонентов предлагается использование префикса "jabber-" - jabber-jit, jabber-mrim, jabber-muc, jabber-pyicq-t и т.п.
+
В соответствии с [[PseudoUserPolicy]], предлагается для каждого сервера и компонента иметь отдельного псевдопользователя, соответствующего имени пакета. Для серверов, как правило, имеющих в своем названии «jabber» это будет просто ejabberd, jabberd14, jabberd2 и т. п., для компонентов предлагается использование префикса «jabber-» — jabber-jit, jabber-mrim, jabber-muc, jabber-pyicq-t и т. п.

Версия 18:10, 10 сентября 2008

Stub.png
Черновик политики Sisyphus
Автор(ы) — ...


Инфраструктура сборки jabber-сервисов в ALT Linux

1. Серверы

Есть серверы — ejabberd, jabberd2, возможно wildfire. Каждый лежит в своем пакете, ни от кого не зависит. Каждый можно поставить абсолютно отдельно, без всего. Ничего, кроме себя, опять же, они не провайдят.

2. Транспорты

Есть транспорты, которые являются отдельными сервисами с точки зрения системы (то есть имеют отдельный собственный SysV-init). Предпочтительно иметь в названии транспорта префикс «jabber» (jabber-jit, jabber-mrim, jabber-pyicqt и т. п.) — и в названии пакета, и в названии сервиса. Транспорт точно так же, никого не требует, никого не провайдит, кроме себя.

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

3. Теоретическое обоснование их связи

Транспорты и серверы общаются между собой через протокол accept-connect через TCP/IP. Все иные варианты взаимодействия использовать рекомендуется не рекомендуется, так как они менее универсальны и зачастую не позволяют разнести сервер с транспортом по сети.

Есть некая управляющая система (по механизму действия схожая с control или alternatives), которая знает о том, что есть те и другие и связывает их между собой. У системы есть один вызов типа «сделать все хорошо», который вызывается при:

  • инсталляции нового сервера
  • инсталляции нового транспорта

«Сделать все хорошо» включает в себя прописывание всех транспортов по все серверы, если только они оттуда не были принудительно выкинуты (прописываемые строчки закомментированы).

Есть некая сложность в том, что во всех известных мне серверах (jabberd1.4, jabberd2, ejabberd) нет нормальной модуляризации конфига с возможностью подключения модуля через установку дополнительного кусочка конфига в какой-то каталог, а в головном конфиге иметь что-то вроде «include тот-каталог/*». Таким образом, управляющая система должна будет влезать в конфиги этих серверов и что-то исправлять (дописывать) в них вручную, при этом, разумеется, зная синтаксис каждого такого конфига.

4. Практический ход их связи

При инсталляции нового транспорта нужно сгенерировать конфиг, в котором есть как минимум:

  • номер порта (статический, заранее присвоенный в рамках ALT)
  • hostname (генерящийся из заранее присвоенного префикса типа «mrim.» + hostname)
  • генерящийся случайно пароль

Задачи управляющей системы:

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

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

5. Реализация

1) генерящийся конфиг со стороны транспорта (в postinstall) 2) адаптер со стороны транспорта — скрипт а ля pkgconfig, с опциями --host, --port, --password. 3) адаптер со стороны сервера — скрипт, которому передаются такими же опциями --host= --port= --password= параметры; после запуска скрипта появляется некая уверенность в том, что данный транспорт подключен к данному серверу. 4) скрипт-диспетчер «сделать все хорошо» (в postinstall всех транспортов и серверов) — запускает все возможные комбинации адапетров серверов и транспортов и пихает их вводы-выводы друг дружке.

6. Директории

Все серверы и транспорты имеют собственные директории логов / спулов / lib и т. п., в соответствии с именем пакета. Рекомендуется использовать что-то вроде:

/var/log/ejabberd /var/log/jabber-pyicqt /var/log/jabber-mrim … /var/lib/ejabberd /var/lib/jabber-pyicqt /var/lib/jabber-mrim … /var/spool/ejabberd /var/spool/jabber-pyicqt /var/spool/jabber-mrim …

7. Пользователи

В соответствии с PseudoUserPolicy, предлагается для каждого сервера и компонента иметь отдельного псевдопользователя, соответствующего имени пакета. Для серверов, как правило, имеющих в своем названии «jabber» это будет просто ejabberd, jabberd14, jabberd2 и т. п., для компонентов предлагается использование префикса «jabber-» — jabber-jit, jabber-mrim, jabber-muc, jabber-pyicq-t и т. п.