Chapril/xmpp.chapril.org-ejabberd
25
1
Fork 0
mirror of https://github.com/processone/ejabberd.git synced 2024-11-24 16:23:40 +01:00
Code Releases Activity

*** empty log message ***

Browse Source 
SVN Revision: 70
This commit is contained in:
Alexey Shchepin 2003-02-11 18:09:14 +00:00
parent c1ae6a30f3
commit d563284ade
2 changed files with 242 additions and 162 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

229
doc/guide.html
View File

@ -21,7 +21,7 @@
<A HREF="mailto:alexey@sevcom.net"><TT>mailto:alexey@sevcom.net</TT></A><BR> <A HREF="mailto:alexey@sevcom.net"><TT>mailto:alexey@sevcom.net</TT></A><BR>
<A HREF="xmpp:aleksey@jabber.ru"><TT>xmpp:aleksey@jabber.ru</TT></A></H3> <A HREF="xmpp:aleksey@jabber.ru"><TT>xmpp:aleksey@jabber.ru</TT></A></H3>
<H3 ALIGN=center>February 3, 2003</H3><DIV ALIGN=center> <H3 ALIGN=center>February 11, 2003</H3><DIV ALIGN=center>
<IMG SRC="logo.png"> <IMG SRC="logo.png">
@ -30,24 +30,86 @@
<BR> <BR>
<BR> <!--TOC section Table of Contents-->
<BR>
<H2>Table of Contents</H2><!--SEC END -->
<UL><LI>
<A HREF="#htoc1">1&nbsp;&nbsp;Introduction</A>
<LI><A HREF="#htoc2">2&nbsp;&nbsp;Installation</A>
<UL><LI>
<A HREF="#htoc3">2.1&nbsp;&nbsp;Installation Requirements</A>
<LI><A HREF="#htoc4">2.2&nbsp;&nbsp;Obtaining</A>
<LI><A HREF="#htoc5">2.3&nbsp;&nbsp;Compilation</A>
<LI><A HREF="#htoc6">2.4&nbsp;&nbsp;Starting</A>
</UL>
<LI><A HREF="#htoc7">3&nbsp;&nbsp;Configuration</A>
<UL><LI>
<A HREF="#htoc8">3.1&nbsp;&nbsp;Initial Configuration</A>
<UL><LI>
<A HREF="#htoc9">3.1.1&nbsp;&nbsp;Host Name</A>
<LI><A HREF="#htoc10">3.1.2&nbsp;&nbsp;Access Rules</A>
<LI><A HREF="#htoc11">3.1.3&nbsp;&nbsp;Listened Sockets</A>
<LI><A HREF="#htoc12">3.1.4&nbsp;&nbsp;Modules</A>
</UL>
<LI><A HREF="#htoc13">3.2&nbsp;&nbsp;Online Configuration and Monitoring</A>
<UL><LI>
<A HREF="#htoc14">3.2.1&nbsp;&nbsp;Node <TT>config</TT>: Global Configuration</A>
<LI><A HREF="#htoc15">3.2.2&nbsp;&nbsp;Node <TT>online users</TT>: List of Online Users</A>
<LI><A HREF="#htoc16">3.2.3&nbsp;&nbsp;Node <TT>all users</TT>: List of Registered User</A>
<LI><A HREF="#htoc17">3.2.4&nbsp;&nbsp;Node <TT>outgoing s2s</TT>: List of Outgoing S2S connections</A>
<LI><A HREF="#htoc18">3.2.5&nbsp;&nbsp;Node <TT>running nodes</TT>: List of Running <TT>ejabberd</TT> Nodes</A>
<LI><A HREF="#htoc19">3.2.6&nbsp;&nbsp;Node <TT>stopped nodes</TT>: List of Stopped Nodes</A>
</UL>
</UL>
<LI><A HREF="#htoc20">4&nbsp;&nbsp;Distribution</A>
<UL><LI>
<A HREF="#htoc21">4.1&nbsp;&nbsp;How it works</A>
<UL><LI>
<A HREF="#htoc22">4.1.1&nbsp;&nbsp;Router</A>
<LI><A HREF="#htoc23">4.1.2&nbsp;&nbsp;Local Router</A>
<LI><A HREF="#htoc24">4.1.3&nbsp;&nbsp;Session Manager</A>
<LI><A HREF="#htoc25">4.1.4&nbsp;&nbsp;S2S Manager</A>
</UL>
</UL>
<LI><A HREF="#htoc26">A&nbsp;&nbsp;Built-in Modules</A>
<UL><LI>
<A HREF="#htoc27">A.1&nbsp;&nbsp;Common Options</A>
<UL><LI>
<A HREF="#htoc28">A.1.1&nbsp;&nbsp;Option <TT>iqdisc</TT></A>
<LI><A HREF="#htoc29">A.1.2&nbsp;&nbsp;Option <TT>host</TT></A>
</UL>
<LI><A HREF="#htoc30">A.2&nbsp;&nbsp;<TT>mod_register</TT></A>
<LI><A HREF="#htoc31">A.3&nbsp;&nbsp;<TT>mod_roster</TT></A>
<LI><A HREF="#htoc32">A.4&nbsp;&nbsp;<TT>mod_configure</TT></A>
<LI><A HREF="#htoc33">A.5&nbsp;&nbsp;<TT>mod_disco</TT></A>
<LI><A HREF="#htoc34">A.6&nbsp;&nbsp;<TT>mod_stats</TT></A>
<LI><A HREF="#htoc35">A.7&nbsp;&nbsp;<TT>mod_vcard</TT></A>
<LI><A HREF="#htoc36">A.8&nbsp;&nbsp;<TT>mod_offline</TT></A>
<LI><A HREF="#htoc37">A.9&nbsp;&nbsp;<TT>mod_echo</TT></A>
<LI><A HREF="#htoc38">A.10&nbsp;&nbsp;<TT>mod_private</TT></A>
<LI><A HREF="#htoc39">A.11&nbsp;&nbsp;<TT>mod_time</TT></A>
<LI><A HREF="#htoc40">A.12&nbsp;&nbsp;<TT>mod_version</TT></A>
</UL>
<LI><A HREF="#htoc41">B&nbsp;&nbsp;I18n/L10n</A>
</UL>
<!--TOC section Introduction--> <!--TOC section Introduction-->
<H2><A NAME="htoc1">1</A>&nbsp;&nbsp;Introduction</H2><!--SEC END --> <H2><A NAME="htoc1">1</A>&nbsp;&nbsp;Introduction</H2><!--SEC END -->
<A NAME="sec:intro"></A> <A NAME="sec:intro"></A>
<TT>ejabberd</TT> is a Free and Open Source distributed fault-tolerant Jabber <TT>ejabberd</TT> is a Free and Open Source fault-tolerant distributed Jabber
server. It is writen mostly in Erlang.<BR> server. It is writen mostly in Erlang.<BR>
<BR> <BR>
Main features of ejabberd is: The main features of <TT>ejabberd</TT> is:
<UL><LI> <UL><LI>
Distributed. You can run ejabberd on a cluster of machines and Distributed: You may run <TT>ejabberd</TT> on a cluster of machines and all of
all of them will serve one Jabber domain. them will serve one Jabber domain.
<LI>Fault-tolerance. You can setup an ejabberd cluster so that all <LI>Fault-tolerance: You may setup an <TT>ejabberd</TT> cluster so that all the
information required for a properly working service will be stored information required for a properly working service will be stored
permanently on more then one node. This means that if one of the permanently on more then one node. This means that if one of the nodes
nodes crashed, then the others continue working without disruption. crashes, then the others will continue working without disruption.
You can also add or replace more nodes ``on the fly''. You can also add or replace more nodes ``on the fly''.
<LI>Support for <LI>Support for
<A HREF="http://www.jabber.org/jeps/jep-0030.html">JEP-0030</A> <A HREF="http://www.jabber.org/jeps/jep-0030.html">JEP-0030</A>
@ -68,7 +130,7 @@ Distributed. You can run ejabberd on a cluster of machines and
<H3><A NAME="htoc3">2.1</A>&nbsp;&nbsp;Installation Requirements</H3><!--SEC END --> <H3><A NAME="htoc3">2.1</A>&nbsp;&nbsp;Installation Requirements</H3><!--SEC END -->
<A NAME="sec:installreq"></A> <A NAME="sec:installreq"></A>
To compile <TT>ejabberd</TT>, you need following packages: To compile <TT>ejabberd</TT>, you will need the following packages:
<UL><LI> <UL><LI>
GNU Make; GNU Make;
<LI>GCC; <LI>GCC;
@ -82,7 +144,7 @@ GNU Make;
<A NAME="sec:obtaining"></A> <A NAME="sec:obtaining"></A>
Currently no stable version has been released.<BR> Currently no stable version has been released.<BR>
<BR> <BR>
The latest alpha version can be retrieved via CVS. Do following steps: The latest alpha version can be retrieved from CVS.
<UL><LI> <UL><LI>
<TT>export CVSROOT=:pserver:cvs@www.jabber.ru:/var/spool/cvs</TT> <TT>export CVSROOT=:pserver:cvs@www.jabber.ru:/var/spool/cvs</TT>
<LI><TT>cvs login</TT> <LI><TT>cvs login</TT>
@ -105,7 +167,7 @@ TBD<BR>
<H3><A NAME="htoc6">2.4</A>&nbsp;&nbsp;Starting</H3><!--SEC END --> <H3><A NAME="htoc6">2.4</A>&nbsp;&nbsp;Starting</H3><!--SEC END -->
<A NAME="sec:starting"></A> <A NAME="sec:starting"></A>
... To use more then 1024 connections, you need to set environment ... To use more then 1024 connections, you will need to set environment
variable <TT>ERL_MAX_PORTS</TT>: variable <TT>ERL_MAX_PORTS</TT>:
<PRE> <PRE>
export ERL_MAX_PORTS=32000 export ERL_MAX_PORTS=32000
@ -126,15 +188,17 @@ TBD<BR>
<H3><A NAME="htoc8">3.1</A>&nbsp;&nbsp;Initial Configuration</H3><!--SEC END --> <H3><A NAME="htoc8">3.1</A>&nbsp;&nbsp;Initial Configuration</H3><!--SEC END -->
<A NAME="sec:initconfig"></A> <A NAME="sec:initconfig"></A>
Configuration file is loaded after first start of <TT>ejabberd</TT>. It consists of The configuration file is initially loaded the first time <TT>ejabberd</TT> is
sequence of Erlang terms. Parts of lines after <TT>`%'</TT> sign are ignored. executed, when it is parsed and stored in a database. Subsiquently the
Each term is tuple, where first element is name of option, and other are option configuration is loaded from the database and any commands in the configuration
values. Note, that after first start all values from this file stored in file are appended to the entries in the database. The configuration file
database, and in next time they will be APPENDED to existing values. E.&nbsp;g. consists of a sequence of Erlang terms. Parts of lines after <TT>`%'</TT> sign
if this file will not contain ``host'' definition, then old value will be are ignored. Each term is tuple, where first element is name of option, and
used.<BR> other are option values. E.&nbsp;g. if this file does not contain a ``host''
definition, then old value stored in the database will be used.<BR>
<BR> <BR>
To override old values following lines can be added in config: To override old values stored in the database the following lines can be added
in config:
<PRE> <PRE>
override_global. override_global.
override_local. override_local.
@ -157,8 +221,8 @@ serves. E.&nbsp;g. to use <TT>jabber.org</TT> domain add following line in confi
<H4><A NAME="htoc10">3.1.2</A>&nbsp;&nbsp;Access Rules</H4><!--SEC END --> <H4><A NAME="htoc10">3.1.2</A>&nbsp;&nbsp;Access Rules</H4><!--SEC END -->
<A NAME="sec:configaccess"></A> <A NAME="sec:configaccess"></A>
Access control in <TT>ejabberd</TT> is done via Access Control Lists (ACL). Access control in <TT>ejabberd</TT> is performed via Access Control Lists (ACL). The
Declaration of ACL in config file have following syntax: declarations of ACL in config file have following syntax:
<PRE> <PRE>
{acl, &lt;aclname&gt;, {&lt;acltype&gt;, ...}}. {acl, &lt;aclname&gt;, {&lt;acltype&gt;, ...}}.
</PRE> </PRE>
@ -180,11 +244,11 @@ Declaration of ACL in config file have following syntax:
<PRE> <PRE>
{acl, jabberorg, {server, "jabber.org"}}. {acl, jabberorg, {server, "jabber.org"}}.
</PRE><DT><B><TT>{user_regexp, &lt;regexp&gt;}</TT></B><DD> Matches local user with name that </PRE><DT><B><TT>{user_regexp, &lt;regexp&gt;}</TT></B><DD> Matches local user with name that
mathes <TT>&lt;regexp&gt;</TT>. Example: matches <TT>&lt;regexp&gt;</TT>. Example:
<PRE> <PRE>
{acl, tests, {user, "^test[0-9]*$"}}. {acl, tests, {user, "^test[0-9]*$"}}.
</PRE><DT><B><TT>{user_regexp, &lt;regexp&gt;, &lt;server&gt;}</TT></B><DD> Matches user with name </PRE><DT><B><TT>{user_regexp, &lt;regexp&gt;, &lt;server&gt;}</TT></B><DD> Matches user with name
that mathes <TT>&lt;regexp&gt;</TT> and from server <TT>&lt;server&gt;</TT>. Example: that matches <TT>&lt;regexp&gt;</TT> and from server <TT>&lt;server&gt;</TT>. Example:
<PRE> <PRE>
{acl, tests, {user, "^test", "localhost"}}. {acl, tests, {user, "^test", "localhost"}}.
</PRE><DT><B><TT>{server_regexp, &lt;regexp&gt;}</TT></B><DD> Matches any JID from server that </PRE><DT><B><TT>{server_regexp, &lt;regexp&gt;}</TT></B><DD> Matches any JID from server that
@ -192,7 +256,7 @@ Declaration of ACL in config file have following syntax:
<PRE> <PRE>
{acl, icq, {server, "^icq\\."}}. {acl, icq, {server, "^icq\\."}}.
</PRE><DT><B><TT>{node_regexp, &lt;user_regexp&gt;, &lt;server_regexp&gt;}</TT></B><DD> Matches user </PRE><DT><B><TT>{node_regexp, &lt;user_regexp&gt;, &lt;server_regexp&gt;}</TT></B><DD> Matches user
with name that mathes <TT>&lt;user_regexp&gt;</TT> and from server that matches with name that matches <TT>&lt;user_regexp&gt;</TT> and from server that matches
<TT>&lt;server_regexp&gt;</TT>. Example: <TT>&lt;server_regexp&gt;</TT>. Example:
<PRE> <PRE>
{acl, aleksey, {node_regexp, "^aleksey", "^jabber.(ru|org)$"}}. {acl, aleksey, {node_regexp, "^aleksey", "^jabber.(ru|org)$"}}.
@ -200,8 +264,8 @@ Declaration of ACL in config file have following syntax:
<DT><B><TT>{user_glob, &lt;glob&gt;, &lt;server&gt;}</TT></B><DD> <DT><B><TT>{user_glob, &lt;glob&gt;, &lt;server&gt;}</TT></B><DD>
<DT><B><TT>{server_glob, &lt;glob&gt;}</TT></B><DD> <DT><B><TT>{server_glob, &lt;glob&gt;}</TT></B><DD>
<DT><B><TT>{node_glob, &lt;user_glob&gt;, &lt;server_glob&gt;}</TT></B><DD> This is same as <DT><B><TT>{node_glob, &lt;user_glob&gt;, &lt;server_glob&gt;}</TT></B><DD> This is same as
above, but use shell glob patterns instead of regexp. This patterns can have above, but uses shell glob patterns instead of regexp. These patterns can
following special characters: have following special characters:
<DL COMPACT=compact><DT> <DL COMPACT=compact><DT>
<B><TT>*</TT></B><DD> matches any string including the null string. <B><TT>*</TT></B><DD> matches any string including the null string.
<DT><B><TT>?</TT></B><DD> matches any single character. <DT><B><TT>?</TT></B><DD> matches any single character.
@ -211,21 +275,21 @@ Declaration of ACL in config file have following syntax:
character not enclosed is matched. character not enclosed is matched.
</DL> </DL>
</DL> </DL>
Following ACLs pre-defined: The following ACLs pre-defined:
<DL COMPACT=compact><DT> <DL COMPACT=compact><DT>
<B><TT>all</TT></B><DD> Matches all JIDs. <B><TT>all</TT></B><DD> Matches all JIDs.
<DT><B><TT>none</TT></B><DD> Matches none JIDs. <DT><B><TT>none</TT></B><DD> Matches none JIDs.
</DL> </DL>
Allowing or denying of different services is like this: An entry allowing or denying different services would look similar to this:
<PRE> <PRE>
{access, &lt;accessname&gt;, [{allow, &lt;aclname&gt;}, {access, &lt;accessname&gt;, [{allow, &lt;aclname&gt;},
{deny, &lt;aclname&gt;}, {deny, &lt;aclname&gt;},
... ...
]}. ]}.
</PRE>When JID is checked to have access to <TT>&lt;accessname&gt;</TT>, server </PRE>When a JID is checked to have access to <TT>&lt;accessname&gt;</TT>, the server
sequentially checks if this JID in one of the ACLs that are second elements in sequentially checks if this JID mathes one of the ACLs that are second elements
each tuple in list. If one of them matched, then returned first element of in each tuple in list. If it is matched, then the first element of matched
matched tuple. Else returned ``<TT>deny</TT>''.<BR> tuple is returned else ``<TT>deny</TT>'' is returned.<BR>
<BR> <BR>
Example: Example:
<PRE> <PRE>
@ -251,7 +315,7 @@ Port number;
<LI>Function in this module that starts connection (likely will be removed); <LI>Function in this module that starts connection (likely will be removed);
<LI>Options to this module. <LI>Options to this module.
</UL> </UL>
Currently three modules implemented: Currently three modules are implemented:
<DL COMPACT=compact><DT> <DL COMPACT=compact><DT>
<B><TT>ejabberd_c2s</TT></B><DD> This module serves C2S connections.<BR> <B><TT>ejabberd_c2s</TT></B><DD> This module serves C2S connections.<BR>
<BR> <BR>
@ -262,12 +326,12 @@ Following options defined:
</DL> </DL>
<DT><B><TT>ejabberd_s2s_in</TT></B><DD> This module serves incoming S2S connections. <DT><B><TT>ejabberd_s2s_in</TT></B><DD> This module serves incoming S2S connections.
<DT><B><TT>ejabberd_service</TT></B><DD> This module serves connections to Jabber <DT><B><TT>ejabberd_service</TT></B><DD> This module serves connections to Jabber
services (i.&nbsp;e. that use <TT>jabber:component:accept</TT> namespace). services (i.&nbsp;e. that use the <TT>jabber:component:accept</TT> namespace).
</DL> </DL>
For example, following configuration defines that C2S connections listened on For example, the following configuration defines that C2S connections are
port 5222 and denied for user ``<TT>bad</TT>'', S2S on port 5269 and that listened on port 5222 and denied for user ``<TT>bad</TT>'', S2S on port 5269
service <TT>conference.jabber.org</TT> must be connected to port 8888 with and that service <TT>conference.jabber.org</TT> must be connected to port 8888
password ``<TT>secret</TT>''. with a password ``<TT>secret</TT>''.
<PRE> <PRE>
{acl, blocked, {user, "bad"}}. {acl, blocked, {user, "bad"}}.
{access, c2s, [{deny, blocked}, {access, c2s, [{deny, blocked},
@ -283,9 +347,9 @@ password ``<TT>secret</TT>''.
<H4><A NAME="htoc12">3.1.4</A>&nbsp;&nbsp;Modules</H4><!--SEC END --> <H4><A NAME="htoc12">3.1.4</A>&nbsp;&nbsp;Modules</H4><!--SEC END -->
<A NAME="sec:configmodules"></A> <A NAME="sec:configmodules"></A>
Option <TT>modules</TT> defines list of modules that will be loaded after Option <TT>modules</TT> defines the list of modules that will be loaded after
<TT>ejabberd</TT> startup. Each list element is a tuple where first element is a <TT>ejabberd</TT> startup. Each list element is a tuple where first element is a
name of module and second is list of options to this module. See name of a module and second is list of options to this module. See
section&nbsp;<A HREF="#sec:modules">A</A> for detailed information on each module.<BR> section&nbsp;<A HREF="#sec:modules">A</A> for detailed information on each module.<BR>
<BR> <BR>
Example: Example:
@ -309,14 +373,14 @@ Example:
<H3><A NAME="htoc13">3.2</A>&nbsp;&nbsp;Online Configuration and Monitoring</H3><!--SEC END --> <H3><A NAME="htoc13">3.2</A>&nbsp;&nbsp;Online Configuration and Monitoring</H3><!--SEC END -->
<A NAME="sec:onlineconfig"></A> <A NAME="sec:onlineconfig"></A>
To use facility of online reconfiguration of <TT>ejabberd</TT> needed to have To perform online reconfiguration of <TT>ejabberd</TT> you will need to have
<TT>mod_configure</TT> loaded (see section&nbsp;<A HREF="#sec:modconfigure">A.4</A>). Also highly <TT>mod_configure</TT> loaded (see section&nbsp;<A HREF="#sec:modconfigure">A.4</A>). It is also highly
recommended to load <TT>mod_disco</TT> (see section&nbsp;<A HREF="#sec:moddisco">A.5</A>), because recommended to load <TT>mod_disco</TT> as well (see section&nbsp;<A HREF="#sec:moddisco">A.5</A>),
<TT>mod_configure</TT> highly integrates with it. Also recommended to use disco- and because <TT>mod_configure</TT> is highly integrated with it. Additionally it is
xdata-capable client recommended to use a disco- and xdata-capable client such as
(<A HREF="http://www.jabber.ru/projects/tkabber/index_en.html">Tkabber</A> <A HREF="http://www.jabber.ru/projects/tkabber/index_en.html">Tkabber</A>
developed synchronously with <TT>ejabberd</TT>, its CVS version use most of (which was developed synchronously with <TT>ejabberd</TT>, its CVS version
<TT>ejabberd</TT> features).<BR> supports most of <TT>ejabberd</TT> features).<BR>
<BR> <BR>
On disco query <TT>ejabberd</TT> returns following items: On disco query <TT>ejabberd</TT> returns following items:
<UL><LI> <UL><LI>
@ -339,15 +403,15 @@ Identity of server.
<H4><A NAME="htoc14">3.2.1</A>&nbsp;&nbsp;Node <TT>config</TT>: Global Configuration</H4><!--SEC END --> <H4><A NAME="htoc14">3.2.1</A>&nbsp;&nbsp;Node <TT>config</TT>: Global Configuration</H4><!--SEC END -->
Under this node exists following nodes:<BR> Under this node the following nodes exists:<BR>
<BR> <BR>
<!--TOC paragraph Node <TT>config/hostname</TT>--> <!--TOC paragraph Node <TT>config/hostname</TT>-->
<H5>Node <TT>config/hostname</TT></H5><!--SEC END --> <H5>Node <TT>config/hostname</TT></H5><!--SEC END -->
Via <TT>jabber:x:data</TT> queries to this node possible to change host name of Via <TT>jabber:x:data</TT> queries to this node possible to change host name of
this <TT>ejabberd</TT> server. (See figure&nbsp;<A HREF="#fig:hostname">2</A>) (Currently will work this <TT>ejabberd</TT> server. (See figure&nbsp;<A HREF="#fig:hostname">2</A>) (Currently this works
correctly only after restart) correctly only after a restart)
<BLOCKQUOTE><DIV ALIGN=center><DIV ALIGN=center><HR WIDTH="80%" SIZE=2></DIV> <BLOCKQUOTE><DIV ALIGN=center><DIV ALIGN=center><HR WIDTH="80%" SIZE=2></DIV>
<IMG SRC="confhostname.png"> <IMG SRC="confhostname.png">
@ -362,8 +426,8 @@ correctly only after restart)
<H5>Node <TT>config/acls</TT></H5><!--SEC END --> <H5>Node <TT>config/acls</TT></H5><!--SEC END -->
Via <TT>jabber:x:data</TT> queries to this node possible to edit ACLs list. (See Via <TT>jabber:x:data</TT> queries to this node it is possible to edit ACLs list.
figure&nbsp;<A HREF="#fig:acls">3</A>) (See figure&nbsp;<A HREF="#fig:acls">3</A>)
<BLOCKQUOTE><DIV ALIGN=center><DIV ALIGN=center><HR WIDTH="80%" SIZE=2></DIV> <BLOCKQUOTE><DIV ALIGN=center><DIV ALIGN=center><HR WIDTH="80%" SIZE=2></DIV>
<IMG SRC="confacls.png"> <IMG SRC="confacls.png">
@ -378,13 +442,14 @@ figure&nbsp;<A HREF="#fig:acls">3</A>)
<H5>Node <TT>config/access</TT></H5><!--SEC END --> <H5>Node <TT>config/access</TT></H5><!--SEC END -->
Via <TT>jabber:x:data</TT> queries to this node possible to edit access rules.<BR> Via <TT>jabber:x:data</TT> queries to this node it is possible to edit access
rules.<BR>
<BR> <BR>
<!--TOC paragraph Node <TT>config/remusers</TT>--> <!--TOC paragraph Node <TT>config/remusers</TT>-->
<H5>Node <TT>config/remusers</TT></H5><!--SEC END --> <H5>Node <TT>config/remusers</TT></H5><!--SEC END -->
Via <TT>jabber:x:data</TT> queries to this node possible to remove users. If Via <TT>jabber:x:data</TT> queries to this node it is possible to remove users. If
removed user is online, then he will be disconnected. Also user-related data removed user is online, then he will be disconnected. Also user-related data
(e.g. his roster) is removed (but appropriate module must be loaded).<BR> (e.g. his roster) is removed (but appropriate module must be loaded).<BR>
<BR> <BR>
@ -440,15 +505,15 @@ TBD<BR>
<H3><A NAME="htoc21">4.1</A>&nbsp;&nbsp;How it works</H3><!--SEC END --> <H3><A NAME="htoc21">4.1</A>&nbsp;&nbsp;How it works</H3><!--SEC END -->
<A NAME="sec:howitworks"></A> <A NAME="sec:howitworks"></A>
Jabber domain is served by one or more <TT>ejabberd</TT> nodes. This nodes can be A Jabber domain is served by one or more <TT>ejabberd</TT> nodes. These nodes can
runned on different machines that can be connected via network. They all must be run on different machines that are connected via a network. They all must
have access to connect to port 4369 of all another nodes, and must have same have the ability to connect to port 4369 of all another nodes, and must have
magic cookie (see Erlang/OTP documentation, in short file the same magic cookie (see Erlang/OTP documentation, in other words the file
<TT>~ejabberd/.erlang.cookie</TT> must be the same on all nodes). This is <TT>~ejabberd/.erlang.cookie</TT> must be the same on all nodes). This is
needed because all nodes exchange information about connected users, S2S needed because all nodes exchange information about connected users, S2S
connections, registered services, etc...<BR> connections, registered services, etc...<BR>
<BR> <BR>
Each <TT>ejabberd</TT> node run following modules: Each <TT>ejabberd</TT> node must run following modules:
<UL><LI> <UL><LI>
router; router;
<LI>local router. <LI>local router.
@ -459,39 +524,41 @@ router;
<H4><A NAME="htoc22">4.1.1</A>&nbsp;&nbsp;Router</H4><!--SEC END --> <H4><A NAME="htoc22">4.1.1</A>&nbsp;&nbsp;Router</H4><!--SEC END -->
This module is the main router of Jabber packets on each node. It route This module is the main router of Jabber packets on each node. It routes
them based on their destanations domains. It have two tables: local and global them based on their destinations domains. It has two tables: local and global
routes. First, domain of packet destination searched in local table, and if it routes. First, domain of packet destination searched in local table, and if it
finded, then packet routed to appropriate process. If no, then it searched in found, then the packet is routed to appropriate process. If no, then it
global table, and routed to appropriate <TT>ejabberd</TT> node or process. If it not searches in global table, and is routed to the appropriate <TT>ejabberd</TT> node or
exists in both tables, then it sended to S2S manager.<BR> process. If itdoes not exists in either table, then it sent to the S2S
manager.<BR>
<BR> <BR>
<!--TOC subsubsection Local Router--> <!--TOC subsubsection Local Router-->
<H4><A NAME="htoc23">4.1.2</A>&nbsp;&nbsp;Local Router</H4><!--SEC END --> <H4><A NAME="htoc23">4.1.2</A>&nbsp;&nbsp;Local Router</H4><!--SEC END -->
This module route packets which have destination domain equal to this server This module routes packets which have a destination domain equal to this server
name. If destination JID have node, then it routed to session manager, else it name. If destination JID has a node, then it routed to the session manager,
processed depending on it content.<BR> else it is processed depending on it's content.<BR>
<BR> <BR>
<!--TOC subsubsection Session Manager--> <!--TOC subsubsection Session Manager-->
<H4><A NAME="htoc24">4.1.3</A>&nbsp;&nbsp;Session Manager</H4><!--SEC END --> <H4><A NAME="htoc24">4.1.3</A>&nbsp;&nbsp;Session Manager</H4><!--SEC END -->
This module route packets to local users. It search to what user resource This module routes packets to local users. It searches for what user resource
packet must be sended via presence table. If this reseouce connected to this packet must be sended via presence table. If this resource is connected to
node, it routed to C2S process, if it connected via another node, then packet this node, it is routed to C2S process, if it connected via another node, then
sended to session manager on it.<BR> the packet is sent to session manager on that node.<BR>
<BR> <BR>
<!--TOC subsubsection S2S Manager--> <!--TOC subsubsection S2S Manager-->
<H4><A NAME="htoc25">4.1.4</A>&nbsp;&nbsp;S2S Manager</H4><!--SEC END --> <H4><A NAME="htoc25">4.1.4</A>&nbsp;&nbsp;S2S Manager</H4><!--SEC END -->
This module route packets to another Jabber servers. First, it check if This module routes packets to other Jabber servers. First, it checks if an
already exists opened S2S connection from domain of packet source to domain of open S2S connection from the domain of the packet source to the domain of
destination. If it opened on another node, then it routed to S2S manager on packet destination already exists. If it is open on another node, then it
that node, if it opened on this node, then it routed to process that serve this routes the packet to S2S manager on that node, if it is open on this node, then
connection, and if this connection not exists, then it opened and registered.<BR> it is routed to the process that serves this connection, and if a connection
does not exist, then it is opened and registered.<BR>
<BR> <BR>
<!--TOC section Built-in Modules--> <!--TOC section Built-in Modules-->
@ -511,8 +578,8 @@ Following options used by many modules, so they described in separate section.<B
Many modules define handlers for processing IQ queries of different namespaces Many modules define handlers for processing IQ queries of different namespaces
to this server or to user (e.&nbsp;g. to <TT>myjabber.org</TT> or to to this server or to user (e.&nbsp;g. to <TT>myjabber.org</TT> or to
<TT>user@myjabber.org</TT>). This option defines processing discipline of this <TT>user@myjabber.org</TT>). This option defines processing discipline of
queries. Possible values are: these queries. Possible values are:
<DL COMPACT=compact><DT> <DL COMPACT=compact><DT>
<B><TT>no_queue</TT></B><DD> All queries of namespace with this processing <B><TT>no_queue</TT></B><DD> All queries of namespace with this processing
discipline processed immediately. This also means that no other packets can discipline processed immediately. This also means that no other packets can

173
doc/guide.tex
View File

@ -39,7 +39,7 @@
\author{Alexey Shchepin \\ \author{Alexey Shchepin \\
\ahrefurl{mailto:alexey@sevcom.net} \\ \ahrefurl{mailto:alexey@sevcom.net} \\
\ahrefurl{xmpp:aleksey@jabber.ru}} \ahrefurl{xmpp:aleksey@jabber.ru}}
\date{February 3, 2003} \date{February 11, 2003}
\begin{document} \begin{document}
\begin{titlepage} \begin{titlepage}
@ -51,23 +51,23 @@
} }
\end{titlepage} \end{titlepage}
%\newpage %\newpage
%\tableofcontents{} \tableofcontents{}
\newpage \newpage
\section{Introduction} \section{Introduction}
\label{sec:intro} \label{sec:intro}
\ejabberd{} is a Free and Open Source distributed fault-tolerant \Jabber{} \ejabberd{} is a Free and Open Source fault-tolerant distributed \Jabber{}
server. It is writen mostly in Erlang. server. It is writen mostly in Erlang.
Main features of ejabberd is: The main features of \ejabberd{} is:
\begin{itemize} \begin{itemize}
\item Distributed. You can run ejabberd on a cluster of machines and \item Distributed: You may run \ejabberd{} on a cluster of machines and all of
all of them will serve one Jabber domain. them will serve one Jabber domain.
\item Fault-tolerance. You can setup an ejabberd cluster so that all \item Fault-tolerance: You may setup an \ejabberd{} cluster so that all the
information required for a properly working service will be stored information required for a properly working service will be stored
permanently on more then one node. This means that if one of the permanently on more then one node. This means that if one of the nodes
nodes crashed, then the others continue working without disruption. crashes, then the others will continue working without disruption.
You can also add or replace more nodes ``on the fly''. You can also add or replace more nodes ``on the fly''.
\item Support for \item Support for
\footahref{http://www.jabber.org/jeps/jep-0030.html}{JEP-0030} \footahref{http://www.jabber.org/jeps/jep-0030.html}{JEP-0030}
@ -89,7 +89,7 @@ Main features of ejabberd is:
\subsection{Installation Requirements} \subsection{Installation Requirements}
\label{sec:installreq} \label{sec:installreq}
To compile \ejabberd{}, you need following packages: To compile \ejabberd{}, you will need the following packages:
\begin{itemize} \begin{itemize}
\item GNU Make; \item GNU Make;
\item GCC; \item GCC;
@ -102,7 +102,7 @@ To compile \ejabberd{}, you need following packages:
Currently no stable version has been released. Currently no stable version has been released.
The latest alpha version can be retrieved via CVS\@. Do following steps: The latest alpha version can be retrieved from CVS\@.
\begin{itemize} \begin{itemize}
\item \texttt{export CVSROOT=:pserver:cvs@www.jabber.ru:/var/spool/cvs} \item \texttt{export CVSROOT=:pserver:cvs@www.jabber.ru:/var/spool/cvs}
\item \texttt{cvs login} \item \texttt{cvs login}
@ -134,7 +134,7 @@ TBD
\subsection{Starting} \subsection{Starting}
\label{sec:starting} \label{sec:starting}
\ldots{} To use more then 1024 connections, you need to set environment \ldots{} To use more then 1024 connections, you will need to set environment
variable \texttt{ERL\_MAX\_PORTS}: variable \texttt{ERL\_MAX\_PORTS}:
\begin{verbatim} \begin{verbatim}
export ERL_MAX_PORTS=32000 export ERL_MAX_PORTS=32000
@ -156,15 +156,18 @@ TBD
%\verbatiminput{../src/ejabberd.cfg} %\verbatiminput{../src/ejabberd.cfg}
Configuration file is loaded after first start of \ejabberd{}. It consists of The configuration file is initially loaded the first time \ejabberd{} is
sequence of Erlang terms. Parts of lines after \texttt{`\%'} sign are ignored. executed, when it is parsed and stored in a database. Subsiquently the
Each term is tuple, where first element is name of option, and other are option configuration is loaded from the database and any commands in the configuration
values. Note, that after first start all values from this file stored in file are appended to the entries in the database. The configuration file
database, and in next time they will be APPENDED to existing values. E.\,g.\ consists of a sequence of Erlang terms. Parts of lines after \texttt{`\%'} sign
if this file will not contain ``host'' definition, then old value will be are ignored. Each term is tuple, where first element is name of option, and
used. other are option values. E.\,g.\ if this file does not contain a ``host''
definition, then old value stored in the database will be used.
To override old values following lines can be added in config:
To override old values stored in the database the following lines can be added
in config:
\begin{verbatim} \begin{verbatim}
override_global. override_global.
override_local. override_local.
@ -190,8 +193,8 @@ serves. E.\,g.\ to use \texttt{jabber.org} domain add following line in config:
\subsubsection{Access Rules} \subsubsection{Access Rules}
\label{sec:configaccess} \label{sec:configaccess}
Access control in \ejabberd{} is done via Access Control Lists (ACL). Access control in \ejabberd{} is performed via Access Control Lists (ACL). The
Declaration of ACL in config file have following syntax: declarations of ACL in config file have following syntax:
\begin{verbatim} \begin{verbatim}
{acl, <aclname>, {<acltype>, ...}}. {acl, <aclname>, {<acltype>, ...}}.
\end{verbatim} \end{verbatim}
@ -218,13 +221,13 @@ Declaration of ACL in config file have following syntax:
{acl, jabberorg, {server, "jabber.org"}}. {acl, jabberorg, {server, "jabber.org"}}.
\end{verbatim} \end{verbatim}
\item[\texttt{\{user\_regexp, <regexp>\}}] Matches local user with name that \item[\texttt{\{user\_regexp, <regexp>\}}] Matches local user with name that
mathes \texttt{<regexp>}. Example: matches \texttt{<regexp>}. Example:
\begin{verbatim} \begin{verbatim}
{acl, tests, {user, "^test[0-9]*$"}}. {acl, tests, {user, "^test[0-9]*$"}}.
\end{verbatim} \end{verbatim}
%$ %$
\item[\texttt{\{user\_regexp, <regexp>, <server>\}}] Matches user with name \item[\texttt{\{user\_regexp, <regexp>, <server>\}}] Matches user with name
that mathes \texttt{<regexp>} and from server \texttt{<server>}. Example: that matches \texttt{<regexp>} and from server \texttt{<server>}. Example:
\begin{verbatim} \begin{verbatim}
{acl, tests, {user, "^test", "localhost"}}. {acl, tests, {user, "^test", "localhost"}}.
\end{verbatim} \end{verbatim}
@ -234,7 +237,7 @@ Declaration of ACL in config file have following syntax:
{acl, icq, {server, "^icq\\."}}. {acl, icq, {server, "^icq\\."}}.
\end{verbatim} \end{verbatim}
\item[\texttt{\{node\_regexp, <user\_regexp>, <server\_regexp>\}}] Matches user \item[\texttt{\{node\_regexp, <user\_regexp>, <server\_regexp>\}}] Matches user
with name that mathes \texttt{<user\_regexp>} and from server that matches with name that matches \texttt{<user\_regexp>} and from server that matches
\texttt{<server\_regexp>}. Example: \texttt{<server\_regexp>}. Example:
\begin{verbatim} \begin{verbatim}
{acl, aleksey, {node_regexp, "^aleksey", "^jabber.(ru|org)$"}}. {acl, aleksey, {node_regexp, "^aleksey", "^jabber.(ru|org)$"}}.
@ -244,8 +247,8 @@ Declaration of ACL in config file have following syntax:
\item[\texttt{\{user\_glob, <glob>, <server>\}}] \item[\texttt{\{user\_glob, <glob>, <server>\}}]
\item[\texttt{\{server\_glob, <glob>\}}] \item[\texttt{\{server\_glob, <glob>\}}]
\item[\texttt{\{node\_glob, <user\_glob>, <server\_glob>\}}] This is same as \item[\texttt{\{node\_glob, <user\_glob>, <server\_glob>\}}] This is same as
above, but use shell glob patterns instead of regexp. This patterns can have above, but uses shell glob patterns instead of regexp. These patterns can
following special characters: have following special characters:
\begin{description} \begin{description}
\item[\texttt{*}] matches any string including the null string. \item[\texttt{*}] matches any string including the null string.
\item[\texttt{?}] matches any single character. \item[\texttt{?}] matches any single character.
@ -256,23 +259,23 @@ Declaration of ACL in config file have following syntax:
\end{description} \end{description}
\end{description} \end{description}
Following ACLs pre-defined: The following ACLs pre-defined:
\begin{description} \begin{description}
\item[\texttt{all}] Matches all JIDs. \item[\texttt{all}] Matches all JIDs.
\item[\texttt{none}] Matches none JIDs. \item[\texttt{none}] Matches none JIDs.
\end{description} \end{description}
Allowing or denying of different services is like this: An entry allowing or denying different services would look similar to this:
\begin{verbatim} \begin{verbatim}
{access, <accessname>, [{allow, <aclname>}, {access, <accessname>, [{allow, <aclname>},
{deny, <aclname>}, {deny, <aclname>},
... ...
]}. ]}.
\end{verbatim} \end{verbatim}
When JID is checked to have access to \texttt{<accessname>}, server When a JID is checked to have access to \texttt{<accessname>}, the server
sequentially checks if this JID in one of the ACLs that are second elements in sequentially checks if this JID mathes one of the ACLs that are second elements
each tuple in list. If one of them matched, then returned first element of in each tuple in list. If it is matched, then the first element of matched
matched tuple. Else returned ``\texttt{deny}''. tuple is returned else ``\texttt{deny}'' is returned.
Example: Example:
\begin{verbatim} \begin{verbatim}
@ -300,7 +303,7 @@ runned on them. Each element of list is a tuple with following elements:
\item Options to this module. \item Options to this module.
\end{itemize} \end{itemize}
Currently three modules implemented: Currently three modules are implemented:
\begin{description} \begin{description}
\item[\texttt{ejabberd\_c2s}] This module serves C2S connections. \item[\texttt{ejabberd\_c2s}] This module serves C2S connections.
@ -311,13 +314,13 @@ Currently three modules implemented:
\end{description} \end{description}
\item[\texttt{ejabberd\_s2s\_in}] This module serves incoming S2S connections. \item[\texttt{ejabberd\_s2s\_in}] This module serves incoming S2S connections.
\item[\texttt{ejabberd\_service}] This module serves connections to \Jabber{} \item[\texttt{ejabberd\_service}] This module serves connections to \Jabber{}
services (i.\,e.\ that use \texttt{jabber:component:accept} namespace). services (i.\,e.\ that use the \texttt{jabber:component:accept} namespace).
\end{description} \end{description}
For example, following configuration defines that C2S connections listened on For example, the following configuration defines that C2S connections are
port 5222 and denied for user ``\texttt{bad}'', S2S on port 5269 and that listened on port 5222 and denied for user ``\texttt{bad}'', S2S on port 5269
service \texttt{conference.jabber.org} must be connected to port 8888 with and that service \texttt{conference.jabber.org} must be connected to port 8888
password ``\texttt{secret}''. with a password ``\texttt{secret}''.
\begin{verbatim} \begin{verbatim}
{acl, blocked, {user, "bad"}}. {acl, blocked, {user, "bad"}}.
@ -337,9 +340,9 @@ password ``\texttt{secret}''.
\subsubsection{Modules} \subsubsection{Modules}
\label{sec:configmodules} \label{sec:configmodules}
Option \texttt{modules} defines list of modules that will be loaded after Option \texttt{modules} defines the list of modules that will be loaded after
\ejabberd{} startup. Each list element is a tuple where first element is a \ejabberd{} startup. Each list element is a tuple where first element is a
name of module and second is list of options to this module. See name of a module and second is list of options to this module. See
section~\ref{sec:modules} for detailed information on each module. section~\ref{sec:modules} for detailed information on each module.
Example: Example:
@ -363,14 +366,17 @@ Example:
\subsection{Online Configuration and Monitoring} \subsection{Online Configuration and Monitoring}
\label{sec:onlineconfig} \label{sec:onlineconfig}
To use facility of online reconfiguration of \ejabberd{} needed to have To perform online reconfiguration of \ejabberd{} you will need to have
\modconfigure{} loaded (see section~\ref{sec:modconfigure}). Also highly \modconfigure{} loaded (see section~\ref{sec:modconfigure}). It is also highly
recommended to load \moddisco{} (see section~\ref{sec:moddisco}), because recommended to load \moddisco{} as well (see section~\ref{sec:moddisco}),
\modconfigure{} highly integrates with it. Also recommended to use disco- and because \modconfigure{} is highly integrated with it. Additionally it is
xdata-capable client recommended to use a disco- and xdata-capable client such as
(\footahref{http://www.jabber.ru/projects/tkabber/index\_en.html}{Tkabber} \footahref{http://www.jabber.ru/projects/tkabber/index\_en.html}{Tkabber}
developed synchronously with \ejabberd{}, its CVS version use most of (which was developed synchronously with \ejabberd{}, its CVS version
\ejabberd{} features). supports most of \ejabberd{} features).
On disco query \ejabberd{} returns following items: On disco query \ejabberd{} returns following items:
\begin{itemize} \begin{itemize}
@ -388,13 +394,13 @@ On disco query \ejabberd{} returns following items:
\subsubsection{Node \texttt{config}: Global Configuration} \subsubsection{Node \texttt{config}: Global Configuration}
Under this node exists following nodes: Under this node the following nodes exists:
\paragraph{Node \texttt{config/hostname}} \paragraph{Node \texttt{config/hostname}}
Via \ns{jabber:x:data} queries to this node possible to change host name of Via \ns{jabber:x:data} queries to this node possible to change host name of
this \ejabberd{} server. (See figure~\ref{fig:hostname}) (Currently will work this \ejabberd{} server. (See figure~\ref{fig:hostname}) (Currently this works
correctly only after restart) correctly only after a restart)
\begin{figure}[htbp] \begin{figure}[htbp]
\centering \centering
\insimg{confhostname.png} \insimg{confhostname.png}
@ -405,8 +411,8 @@ correctly only after restart)
\paragraph{Node \texttt{config/acls}} \paragraph{Node \texttt{config/acls}}
Via \ns{jabber:x:data} queries to this node possible to edit ACLs list. (See Via \ns{jabber:x:data} queries to this node it is possible to edit ACLs list.
figure~\ref{fig:acls}) (See figure~\ref{fig:acls})
\begin{figure}[htbp] \begin{figure}[htbp]
\centering \centering
\insimg{confacls.png} \insimg{confacls.png}
@ -417,12 +423,13 @@ figure~\ref{fig:acls})
\paragraph{Node \texttt{config/access}} \paragraph{Node \texttt{config/access}}
Via \ns{jabber:x:data} queries to this node possible to edit access rules. Via \ns{jabber:x:data} queries to this node it is possible to edit access
rules.
\paragraph{Node \texttt{config/remusers}} \paragraph{Node \texttt{config/remusers}}
Via \ns{jabber:x:data} queries to this node possible to remove users. If Via \ns{jabber:x:data} queries to this node it is possible to remove users. If
removed user is online, then he will be disconnected. Also user-related data removed user is online, then he will be disconnected. Also user-related data
(e.g. his roster) is removed (but appropriate module must be loaded). (e.g. his roster) is removed (but appropriate module must be loaded).
@ -472,15 +479,19 @@ TBD
\subsection{How it works} \subsection{How it works}
\label{sec:howitworks} \label{sec:howitworks}
\Jabber{} domain is served by one or more \ejabberd{} nodes. This nodes can be
runned on different machines that can be connected via network. They all must
have access to connect to port 4369 of all another nodes, and must have same A \Jabber{} domain is served by one or more \ejabberd{} nodes. These nodes can
magic cookie (see Erlang/OTP documentation, in short file be run on different machines that are connected via a network. They all must
have the ability to connect to port 4369 of all another nodes, and must have
the same magic cookie (see Erlang/OTP documentation, in other words the file
\texttt{\~{}ejabberd/.erlang.cookie} must be the same on all nodes). This is \texttt{\~{}ejabberd/.erlang.cookie} must be the same on all nodes). This is
needed because all nodes exchange information about connected users, S2S needed because all nodes exchange information about connected users, S2S
connections, registered services, etc\ldots connections, registered services, etc\ldots
Each \ejabberd{} node run following modules:
Each \ejabberd{} node must run following modules:
\begin{itemize} \begin{itemize}
\item router; \item router;
\item local router. \item local router.
@ -491,36 +502,38 @@ Each \ejabberd{} node run following modules:
\subsubsection{Router} \subsubsection{Router}
This module is the main router of \Jabber{} packets on each node. It route This module is the main router of \Jabber{} packets on each node. It routes
them based on their destanations domains. It have two tables: local and global them based on their destinations domains. It has two tables: local and global
routes. First, domain of packet destination searched in local table, and if it routes. First, domain of packet destination searched in local table, and if it
finded, then packet routed to appropriate process. If no, then it searched in found, then the packet is routed to appropriate process. If no, then it
global table, and routed to appropriate \ejabberd{} node or process. If it not searches in global table, and is routed to the appropriate \ejabberd{} node or
exists in both tables, then it sended to S2S manager. process. If itdoes not exists in either table, then it sent to the S2S
manager.
\subsubsection{Local Router} \subsubsection{Local Router}
This module route packets which have destination domain equal to this server This module routes packets which have a destination domain equal to this server
name. If destination JID have node, then it routed to session manager, else it name. If destination JID has a node, then it routed to the session manager,
processed depending on it content. else it is processed depending on it's content.
\subsubsection{Session Manager} \subsubsection{Session Manager}
This module route packets to local users. It search to what user resource This module routes packets to local users. It searches for what user resource
packet must be sended via presence table. If this reseouce connected to this packet must be sended via presence table. If this resource is connected to
node, it routed to C2S process, if it connected via another node, then packet this node, it is routed to C2S process, if it connected via another node, then
sended to session manager on it. the packet is sent to session manager on that node.
\subsubsection{S2S Manager} \subsubsection{S2S Manager}
This module route packets to another \Jabber{} servers. First, it check if This module routes packets to other \Jabber{} servers. First, it checks if an
already exists opened S2S connection from domain of packet source to domain of open S2S connection from the domain of the packet source to the domain of
destination. If it opened on another node, then it routed to S2S manager on packet destination already exists. If it is open on another node, then it
that node, if it opened on this node, then it routed to process that serve this routes the packet to S2S manager on that node, if it is open on this node, then
connection, and if this connection not exists, then it opened and registered. it is routed to the process that serves this connection, and if a connection
does not exist, then it is opened and registered.
@ -541,8 +554,8 @@ Following options used by many modules, so they described in separate section.
Many modules define handlers for processing IQ queries of different namespaces Many modules define handlers for processing IQ queries of different namespaces
to this server or to user (e.\,g.\ to \texttt{myjabber.org} or to to this server or to user (e.\,g.\ to \texttt{myjabber.org} or to
\texttt{user@myjabber.org}). This option defines processing discipline of this \texttt{user@myjabber.org}). This option defines processing discipline of
queries. Possible values are: these queries. Possible values are:
\begin{description} \begin{description}
\item[\texttt{no\_queue}] All queries of namespace with this processing \item[\texttt{no\_queue}] All queries of namespace with this processing
discipline processed immediately. This also means that no other packets can discipline processed immediately. This also means that no other packets can