Chapril
/
xmpp.chapril.org-ejabberd
mirror of https://github.com/processone/ejabberd.git
24
1
Fork 0
Code Releases Activity

Recompile the Guide

This commit is contained in:
Badlop 2010-12-13 11:12:43 +01:00
parent 6242fd2bb8
commit fbcb9bb154
4 changed files with 343 additions and 104 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/dev.html
View File

@ -2,7 +2,7 @@
"http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Ejabberd 2.1.x Developers Guide
<TITLE>Ejabberd 2.1.6 Developers Guide
</TITLE>
<META http-equiv="Content-Type" content="text/html; charset=US-ASCII">
@ -49,7 +49,7 @@ TD P{margin:0px;}
<!--HEVEA command line is: /usr/bin/hevea -fix -pedantic dev.tex -->
<!--CUT DEF section 1 --><P><A NAME="titlepage"></A>
</P><TABLE CLASS="title"><TR><TD><H1 CLASS="titlemain">Ejabberd 2.1.x Developers Guide</H1><H3 CLASS="titlerest">Alexey Shchepin<BR>
</P><TABLE CLASS="title"><TR><TD><H1 CLASS="titlemain">Ejabberd 2.1.6 Developers Guide</H1><H3 CLASS="titlerest">Alexey Shchepin<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></TD></TR>
</TABLE><DIV CLASS="center">

4
doc/features.html
View File

@ -2,7 +2,7 @@
"http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Ejabberd 2.1.x Feature Sheet
<TITLE>Ejabberd 2.1.6 Feature Sheet
</TITLE>
<META http-equiv="Content-Type" content="text/html; charset=US-ASCII">
@ -50,7 +50,7 @@ SPAN{width:20%; float:right; text-align:left; margin-left:auto;}
<!--HEVEA command line is: /usr/bin/hevea -fix -pedantic features.tex -->
<!--CUT DEF section 1 --><P><A NAME="titlepage"></A>
</P><TABLE CLASS="title"><TR><TD><H1 CLASS="titlemain">Ejabberd 2.1.x Feature Sheet</H1><H3 CLASS="titlerest">Sander Devrieze<BR>
</P><TABLE CLASS="title"><TR><TD><H1 CLASS="titlemain">Ejabberd 2.1.6 Feature Sheet</H1><H3 CLASS="titlerest">Sander Devrieze<BR>
<A HREF="mailto:s.devrieze@pandora.be"><TT>mailto:s.devrieze@pandora.be</TT></A><BR>
<A HREF="xmpp:sander@devrieze.dyndns.org"><TT>xmpp:sander@devrieze.dyndns.org</TT></A></H3></TD></TR>
</TABLE><DIV CLASS="center">

437
doc/guide.html
View File

@ -6,7 +6,7 @@
ejabberd 2.1.x
ejabberd 2.1.6
Installation and Operation Guide
@ -76,7 +76,7 @@ BLOCKQUOTE.figure DIV.center DIV.center HR{display:none;}
<HR SIZE=2><BR>
<BR>
<TABLE CELLSPACING=6 CELLPADDING=0><TR><TD ALIGN=right NOWRAP> <FONT SIZE=6><B>ejabberd 2.1.x </B></FONT></TD></TR>
<TABLE CELLSPACING=6 CELLPADDING=0><TR><TD ALIGN=right NOWRAP> <FONT SIZE=6><B>ejabberd 2.1.6 </B></FONT></TD></TR>
<TR><TD ALIGN=right NOWRAP>&nbsp;</TD></TR>
<TR><TD ALIGN=right NOWRAP> <FONT SIZE=6>Installation and Operation Guide</FONT></TD></TR>
</TABLE><BR>
@ -160,66 +160,67 @@ BLOCKQUOTE.figure DIV.center DIV.center HR{display:none;}
</LI><LI CLASS="li-toc"><A HREF="#htoc58">3.3.20&#XA0;&#XA0;<TT>mod_roster</TT></A>
</LI><LI CLASS="li-toc"><A HREF="#htoc59">3.3.21&#XA0;&#XA0;<TT>mod_service_log</TT></A>
</LI><LI CLASS="li-toc"><A HREF="#htoc60">3.3.22&#XA0;&#XA0;<TT>mod_shared_roster</TT></A>
</LI><LI CLASS="li-toc"><A HREF="#htoc61">3.3.23&#XA0;&#XA0;<TT>mod_sic</TT></A>
</LI><LI CLASS="li-toc"><A HREF="#htoc62">3.3.24&#XA0;&#XA0;<TT>mod_stats</TT></A>
</LI><LI CLASS="li-toc"><A HREF="#htoc63">3.3.25&#XA0;&#XA0;<TT>mod_time</TT></A>
</LI><LI CLASS="li-toc"><A HREF="#htoc64">3.3.26&#XA0;&#XA0;<TT>mod_vcard</TT></A>
</LI><LI CLASS="li-toc"><A HREF="#htoc65">3.3.27&#XA0;&#XA0;<TT>mod_vcard_ldap</TT></A>
</LI><LI CLASS="li-toc"><A HREF="#htoc66">3.3.28&#XA0;&#XA0;<TT>mod_vcard_xupdate</TT></A>
</LI><LI CLASS="li-toc"><A HREF="#htoc67">3.3.29&#XA0;&#XA0;<TT>mod_version</TT></A>
</LI><LI CLASS="li-toc"><A HREF="#htoc61">3.3.23&#XA0;&#XA0;<TT>mod_shared_roster_ldap</TT></A>
</LI><LI CLASS="li-toc"><A HREF="#htoc62">3.3.24&#XA0;&#XA0;<TT>mod_sic</TT></A>
</LI><LI CLASS="li-toc"><A HREF="#htoc63">3.3.25&#XA0;&#XA0;<TT>mod_stats</TT></A>
</LI><LI CLASS="li-toc"><A HREF="#htoc64">3.3.26&#XA0;&#XA0;<TT>mod_time</TT></A>
</LI><LI CLASS="li-toc"><A HREF="#htoc65">3.3.27&#XA0;&#XA0;<TT>mod_vcard</TT></A>
</LI><LI CLASS="li-toc"><A HREF="#htoc66">3.3.28&#XA0;&#XA0;<TT>mod_vcard_ldap</TT></A>
</LI><LI CLASS="li-toc"><A HREF="#htoc67">3.3.29&#XA0;&#XA0;<TT>mod_vcard_xupdate</TT></A>
</LI><LI CLASS="li-toc"><A HREF="#htoc68">3.3.30&#XA0;&#XA0;<TT>mod_version</TT></A>
</LI></UL>
</LI></UL>
</LI><LI CLASS="li-toc"><A HREF="#htoc68">Chapter&#XA0;4&#XA0;&#XA0;Managing an <TT>ejabberd</TT> Server</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc69">Chapter&#XA0;4&#XA0;&#XA0;Managing an <TT>ejabberd</TT> Server</A>
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc69">4.1&#XA0;&#XA0;<TT>ejabberdctl</TT></A>
<A HREF="#htoc70">4.1&#XA0;&#XA0;<TT>ejabberdctl</TT></A>
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc70">4.1.1&#XA0;&#XA0;ejabberdctl Commands</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc71">4.1.2&#XA0;&#XA0;Erlang Runtime System</A>
<A HREF="#htoc71">4.1.1&#XA0;&#XA0;ejabberdctl Commands</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc72">4.1.2&#XA0;&#XA0;Erlang Runtime System</A>
</LI></UL>
</LI><LI CLASS="li-toc"><A HREF="#htoc72">4.2&#XA0;&#XA0;<TT>ejabberd</TT> Commands</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc73">4.2&#XA0;&#XA0;<TT>ejabberd</TT> Commands</A>
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc73">4.2.1&#XA0;&#XA0;List of ejabberd Commands</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc74">4.2.2&#XA0;&#XA0;Restrict Execution with AccessCommands</A>
<A HREF="#htoc74">4.2.1&#XA0;&#XA0;List of ejabberd Commands</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc75">4.2.2&#XA0;&#XA0;Restrict Execution with AccessCommands</A>
</LI></UL>
</LI><LI CLASS="li-toc"><A HREF="#htoc75">4.3&#XA0;&#XA0;Web Admin</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc76">4.4&#XA0;&#XA0;Ad-hoc Commands</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc77">4.5&#XA0;&#XA0;Change Computer Hostname</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc76">4.3&#XA0;&#XA0;Web Admin</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc77">4.4&#XA0;&#XA0;Ad-hoc Commands</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc78">4.5&#XA0;&#XA0;Change Computer Hostname</A>
</LI></UL>
</LI><LI CLASS="li-toc"><A HREF="#htoc78">Chapter&#XA0;5&#XA0;&#XA0;Securing <TT>ejabberd</TT></A>
</LI><LI CLASS="li-toc"><A HREF="#htoc79">Chapter&#XA0;5&#XA0;&#XA0;Securing <TT>ejabberd</TT></A>
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc79">5.1&#XA0;&#XA0;Firewall Settings</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc80">5.2&#XA0;&#XA0;epmd</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc81">5.3&#XA0;&#XA0;Erlang Cookie</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc82">5.4&#XA0;&#XA0;Erlang Node Name</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc83">5.5&#XA0;&#XA0;Securing Sensitive Files</A>
<A HREF="#htoc80">5.1&#XA0;&#XA0;Firewall Settings</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc81">5.2&#XA0;&#XA0;epmd</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc82">5.3&#XA0;&#XA0;Erlang Cookie</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc83">5.4&#XA0;&#XA0;Erlang Node Name</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc84">5.5&#XA0;&#XA0;Securing Sensitive Files</A>
</LI></UL>
</LI><LI CLASS="li-toc"><A HREF="#htoc84">Chapter&#XA0;6&#XA0;&#XA0;Clustering</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc85">Chapter&#XA0;6&#XA0;&#XA0;Clustering</A>
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc85">6.1&#XA0;&#XA0;How it Works</A>
<A HREF="#htoc86">6.1&#XA0;&#XA0;How it Works</A>
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc86">6.1.1&#XA0;&#XA0;Router</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc87">6.1.2&#XA0;&#XA0;Local Router</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc88">6.1.3&#XA0;&#XA0;Session Manager</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc89">6.1.4&#XA0;&#XA0;s2s Manager</A>
<A HREF="#htoc87">6.1.1&#XA0;&#XA0;Router</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc88">6.1.2&#XA0;&#XA0;Local Router</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc89">6.1.3&#XA0;&#XA0;Session Manager</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc90">6.1.4&#XA0;&#XA0;s2s Manager</A>
</LI></UL>
</LI><LI CLASS="li-toc"><A HREF="#htoc90">6.2&#XA0;&#XA0;Clustering Setup</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc91">6.3&#XA0;&#XA0;Service Load-Balancing</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc91">6.2&#XA0;&#XA0;Clustering Setup</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc92">6.3&#XA0;&#XA0;Service Load-Balancing</A>
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc92">6.3.1&#XA0;&#XA0;Components Load-Balancing</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc93">6.3.2&#XA0;&#XA0;Domain Load-Balancing Algorithm</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc94">6.3.3&#XA0;&#XA0;Load-Balancing Buckets</A>
<A HREF="#htoc93">6.3.1&#XA0;&#XA0;Components Load-Balancing</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc94">6.3.2&#XA0;&#XA0;Domain Load-Balancing Algorithm</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc95">6.3.3&#XA0;&#XA0;Load-Balancing Buckets</A>
</LI></UL>
</LI></UL>
</LI><LI CLASS="li-toc"><A HREF="#htoc95">Chapter&#XA0;7&#XA0;&#XA0;Debugging</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc96">Chapter&#XA0;7&#XA0;&#XA0;Debugging</A>
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc96">7.1&#XA0;&#XA0;Log Files</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc97">7.2&#XA0;&#XA0;Debug Console</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc98">7.3&#XA0;&#XA0;Watchdog Alerts</A>
<A HREF="#htoc97">7.1&#XA0;&#XA0;Log Files</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc98">7.2&#XA0;&#XA0;Debug Console</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc99">7.3&#XA0;&#XA0;Watchdog Alerts</A>
</LI></UL>
</LI><LI CLASS="li-toc"><A HREF="#htoc99">Appendix&#XA0;A&#XA0;&#XA0;Internationalization and Localization</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc100">Appendix&#XA0;B&#XA0;&#XA0;Release Notes</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc101">Appendix&#XA0;C&#XA0;&#XA0;Acknowledgements</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc102">Appendix&#XA0;D&#XA0;&#XA0;Copyright Information</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc100">Appendix&#XA0;A&#XA0;&#XA0;Internationalization and Localization</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc101">Appendix&#XA0;B&#XA0;&#XA0;Release Notes</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc102">Appendix&#XA0;C&#XA0;&#XA0;Acknowledgements</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc103">Appendix&#XA0;D&#XA0;&#XA0;Copyright Information</A>
</LI></UL><!--TOC chapter Introduction-->
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc1">Chapter&#XA0;1</A>&#XA0;&#XA0;Introduction</H1><!--SEC END --><P>
<A NAME="intro"></A></P><P><TT>ejabberd</TT> is a free and open source instant messaging server written in <A HREF="http://www.erlang.org/">Erlang/OTP</A>.</P><P><TT>ejabberd</TT> is cross-platform, distributed, fault-tolerant, and based on open standards to achieve real-time communication.</P><P><TT>ejabberd</TT> is designed to be a rock-solid and feature rich XMPP server.</P><P><TT>ejabberd</TT> is suitable for small deployments, whether they need to be scalable or not, as well as extremely big deployments.</P><!--TOC section Key Features-->
@ -347,6 +348,7 @@ GNU Make
</LI><LI CLASS="li-itemize">GCC
</LI><LI CLASS="li-itemize">Libexpat 1.95 or higher
</LI><LI CLASS="li-itemize">Erlang/OTP R10B-9 or higher. The recommended versions are R12B-5 and R13B04.
Don&#X2019;t use R14A or R14B because <A HREF="http://www.erlang.org/cgi-bin/ezmlm-cgi/4/54598">they have a bug</A>.
</LI><LI CLASS="li-itemize">OpenSSL 0.9.8 or higher, for STARTTLS, SASL and SSL encryption.
</LI><LI CLASS="li-itemize">Zlib 1.2.3 or higher, for Stream Compression support (<A HREF="http://xmpp.org/extensions/xep-0138.html">XEP-0138</A>). Optional.
</LI><LI CLASS="li-itemize">Erlang mysql library. Optional. For MySQL authentication or storage. See section <A HREF="#compilemysql">3.2.1</A>.
@ -693,7 +695,7 @@ Handles STUN Binding requests as defined in
</DD><DT CLASS="dt-description"><B><TT>ejabberd_http</TT></B></DT><DD CLASS="dd-description">
Handles incoming HTTP connections.<BR>
Options: <TT>captcha</TT>, <TT>certfile</TT>, <TT>http_bind</TT>, <TT>http_poll</TT>,
<TT>request_handlers</TT>, <TT>tls</TT>, <TT>web_admin</TT><BR>
<TT>request_handlers</TT>, <TT>tls</TT>, <TT>trusted_proxies</TT>, <TT>web_admin</TT><BR>
</DD></DL><P> <A NAME="listened-options"></A> </P><!--TOC subsubsection Options-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A HREF="#listened-options">Options</A></H4><!--SEC END --><P> <A NAME="listened-options"></A> </P><P>This is a detailed description of each option allowed by the listening modules:
</P><DL CLASS="description"><DT CLASS="dt-description">
@ -803,6 +805,10 @@ The preferable encryption method is STARTTLS on port 5222, as defined
which can be enabled in <TT>ejabberd</TT> with the option <TT>starttls</TT>.
If this option is set, you should also set the <TT>certfile</TT> option.
The option <TT>tls</TT> can also be used in <TT>ejabberd_http</TT> to support HTTPS.
</DD><DT CLASS="dt-description"><B><TT>{trusted_proxies, all | [IpString]}</TT></B></DT><DD CLASS="dd-description">
Specify what proxies are trusted when an HTTP request contains the header <TT>X-Forwarded-For</TT>
You can specify <TT>all</TT> to allow all proxies, or specify a list of IPs in string format.
The default value is: <TT>["127.0.0.1"]</TT>
</DD><DT CLASS="dt-description"><B><TT>web_admin</TT></B></DT><DD CLASS="dd-description"> This option
enables the Web Admin for <TT>ejabberd</TT> administration which is available
at <CODE>http://server:port/admin/</CODE>. Login and password are the username and
@ -813,9 +819,12 @@ option specifies that Zlib stream compression (as defined in <A HREF="http://xmp
is available on connections to the port.
</DD></DL><P>There are some additional global options that can be specified in the ejabberd configuration file (outside <TT>listen</TT>):
</P><DL CLASS="description"><DT CLASS="dt-description">
<B><TT>{s2s_use_starttls, true|false}</TT></B></DT><DD CLASS="dd-description">
This option defines whether to
use STARTTLS for s2s connections.
<B><TT>{s2s_use_starttls, false|optional|required|required_trusted}</TT></B></DT><DD CLASS="dd-description">
This option defines if
s2s connections don&#X2019;t use STARTTLS encryption; if STARTTLS can be used optionally;
if STARTTLS is required to establish the connection;
or if STARTTLS is required and the remote certificate must be valid and trusted.
The default value is to not use STARTTLS: <TT>false</TT>.
</DD><DT CLASS="dt-description"><B><TT>{s2s_certfile, Path}</TT></B></DT><DD CLASS="dd-description"> Full path to a
file containing a SSL certificate.
</DD><DT CLASS="dt-description"><B><TT>{domain_certfile, Domain, Path}</TT></B></DT><DD CLASS="dd-description">
@ -903,7 +912,7 @@ section&#XA0;<A HREF="#webadmin">4.3</A>. The socket only listens connections to
]}
]
}.
{s2s_use_starttls, true}.
{s2s_use_starttls, optional}.
{s2s_certfile, "/etc/ejabberd/server.pem"}.
{domain_certfile, "example.com", "/etc/ejabberd/example_com.pem"}.
{outgoing_s2s_options, [ipv4, ipv6], 10000}.
@ -913,7 +922,7 @@ c2s connections are listened for on port 5222 (all IPv4 addresses) and
on port 5223 (SSL, IP 192.168.0.1 and fdca:8ab6:a243:75ef::1) and denied
for the user called &#X2018;<TT>bad</TT>&#X2019;.
</LI><LI CLASS="li-itemize">s2s connections are listened for on port 5269 (all IPv4 addresses)
with STARTTLS for secured traffic enabled.
with STARTTLS for secured traffic strictly required, and the certificates are verified.
Incoming and outgoing connections of remote XMPP servers are denied,
only two servers can connect: "jabber.example.org" and "example.com".
</LI><LI CLASS="li-itemize">Port 5280 is serving the Web Admin and the HTTP Polling service
@ -992,7 +1001,7 @@ connected to port 5237 with password &#X2018;<TT>ggsecret</TT>&#X2019;.
{service_check_from, false}]}
]
}.
{s2s_use_starttls, true}.
{s2s_use_starttls, required_trusted}.
{s2s_certfile, "/path/to/ssl.pem"}.
{s2s_default_policy, deny}.
{{s2s_host,"jabber.example.org"}, allow}.
@ -1663,8 +1672,7 @@ module variant. Keep in mind that you cannot have several variants of the same
module loaded!</P><P> <A NAME="ldap"></A> </P><!--TOC subsection LDAP-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc37">3.2.5</A>&#XA0;&#XA0;<A HREF="#ldap">LDAP</A></H3><!--SEC END --><P> <A NAME="ldap"></A>
</P><P><TT>ejabberd</TT> has built-in LDAP support. You can authenticate users against LDAP
server and use LDAP directory as vCard storage. Shared rosters are not supported
yet.</P><P>Usually <TT>ejabberd</TT> treats LDAP as a read-only storage:
server and use LDAP directory as vCard storage.</P><P>Usually <TT>ejabberd</TT> treats LDAP as a read-only storage:
it is possible to consult data, but not possible to
create accounts or edit vCard that is stored in LDAP.
However, it is possible to change passwords if <TT>mod_register</TT> module is enabled
@ -1928,6 +1936,8 @@ all entries end with a comma:
<TR><TD ALIGN=left NOWRAP><A HREF="#modservicelog"><TT>mod_service_log</TT></A></TD><TD ALIGN=left NOWRAP>Copy user messages to logger service</TD><TD ALIGN=left NOWRAP>&nbsp;</TD></TR>
<TR><TD ALIGN=left NOWRAP><A HREF="#modsharedroster"><TT>mod_shared_roster</TT></A></TD><TD ALIGN=left NOWRAP>Shared roster management</TD><TD ALIGN=left NOWRAP><TT>mod_roster</TT> or</TD></TR>
<TR><TD ALIGN=left NOWRAP>&nbsp;</TD><TD ALIGN=left NOWRAP>&nbsp;</TD><TD ALIGN=left NOWRAP><TT>mod_roster_odbc</TT></TD></TR>
<TR><TD ALIGN=left NOWRAP><A HREF="#modsharedrosterldap"><TT>mod_shared_roster_ldap</TT></A></TD><TD ALIGN=left NOWRAP>LDAP Shared roster management</TD><TD ALIGN=left NOWRAP><TT>mod_roster</TT> or</TD></TR>
<TR><TD ALIGN=left NOWRAP>&nbsp;</TD><TD ALIGN=left NOWRAP>&nbsp;</TD><TD ALIGN=left NOWRAP><TT>mod_roster_odbc</TT></TD></TR>
<TR><TD ALIGN=left NOWRAP><A HREF="#modsic"><TT>mod_sic</TT></A></TD><TD ALIGN=left NOWRAP>Server IP Check (<A HREF="http://xmpp.org/extensions/xep-0279.html">XEP-0279</A>)</TD><TD ALIGN=left NOWRAP>&nbsp;</TD></TR>
<TR><TD ALIGN=left NOWRAP><A HREF="#modstats"><TT>mod_stats</TT></A></TD><TD ALIGN=left NOWRAP>Statistics Gathering (<A HREF="http://xmpp.org/extensions/xep-0039.html">XEP-0039</A>)</TD><TD ALIGN=left NOWRAP>&nbsp;</TD></TR>
<TR><TD ALIGN=left NOWRAP><A HREF="#modtime"><TT>mod_time</TT></A></TD><TD ALIGN=left NOWRAP>Entity Time (<A HREF="http://xmpp.org/extensions/xep-0202.html">XEP-0202</A>)</TD><TD ALIGN=left NOWRAP>&nbsp;</TD></TR>
@ -2974,6 +2984,12 @@ change it by defining access rule in this option. Use with care: allowing regist
from s2s leads to uncontrolled massive accounts creation by rogue users.
</DD><DT CLASS="dt-description"><B><TT>{captcha_protected, false|true}</TT></B></DT><DD CLASS="dd-description">
Protect registrations with CAPTCHA (see section <A HREF="#captcha">3.1.8</A>). The default is <TT>false</TT>.
</DD><DT CLASS="dt-description"><B><TT>{ip_access, [ {allow|deny, IPaddress}, ...]}</TT></B></DT><DD CLASS="dd-description">
Define rules to allow or deny account registration depending
in the IP address of the XMPP client.
If there is no matching IP mask, the default rule is &#X201C;allow&#X201D;.
IPv6 addresses are supported, but not tested.
The default option value is an empty list: <TT>[]</TT>.
</DD><DT CLASS="dt-description"><B><TT>{password_strength, Entropy}</TT></B></DT><DD CLASS="dd-description">
This option sets the minimum informational entropy for passwords. The value <TT>Entropy</TT>
is a number of bits of entropy. The recommended minimum is 32 bits.
@ -2998,7 +3014,8 @@ To disable this limitation,
instead of an integer put a word like: <TT>infinity</TT>.
Default value: 600 seconds.</P><P>Examples:
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
Next example prohibits the registration of too short account names:
Next example prohibits the registration of too short account names,
and allows to create accounts only to clients of the local network:
<PRE CLASS="verbatim">{acl, shortname, {user_glob, "?"}}.
{acl, shortname, {user_glob, "??"}}.
%% The same using regexp:
@ -3010,7 +3027,10 @@ Next example prohibits the registration of too short account names:
{modules,
[
...
{mod_register, [{access, register}]},
{mod_register, [{access, register},
{ip_access, [{allow, "127.0.0.0/8"},
{deny, "0.0.0.0/0"}]}
]},
...
]}.
</PRE></LI><LI CLASS="li-itemize">This configuration prohibits usage of In-Band Registration
@ -3094,7 +3114,8 @@ Enabling this option reduces the load for both ejabberd and the database.
This option does not affect the client in any way.
This option is only useful if Roster Versioning is enabled.
This option is disabled by default.
Important: if you use <TT>mod_shared_roster</TT>, you must disable this option.
Important: if you use <TT>mod_shared_roster</TT> or <TT>mod_shared_roster_ldap</TT>,
you must disable this option.
</DD></DL><P>This example configuration enables Roster Versioning with storage of current id:
</P><PRE CLASS="verbatim">{modules,
[
@ -3207,15 +3228,232 @@ roster groups as shown in the following table:
</TABLE></TD></TR>
</TABLE>
<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></DIV></BLOCKQUOTE>
</LI></UL><P> <A NAME="modsic"></A> </P><!--TOC subsection <TT>mod_sic</TT>-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc61">3.3.23</A>&#XA0;&#XA0;<A HREF="#modsic"><TT>mod_sic</TT></A></H3><!--SEC END --><P> <A NAME="modsic"></A>
</LI></UL><P> <A NAME="modsharedrosterldap"></A> </P><!--TOC subsection <TT>mod_shared_roster_ldap</TT>-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc61">3.3.23</A>&#XA0;&#XA0;<A HREF="#modsharedrosterldap"><TT>mod_shared_roster_ldap</TT></A></H3><!--SEC END --><P> <A NAME="modsharedrosterldap"></A>
</P><P>This module lets the server administrator
automatically populate users&#X2019; rosters (contact lists) with entries based on
users and groups defined in an LDAP-based directory.</P><P> <A NAME="msrlconfigparams"></A> </P><!--TOC subsubsection Configuration parameters-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A HREF="#msrlconfigparams">Configuration parameters</A></H4><!--SEC END --><P> <A NAME="msrlconfigparams"></A> </P><P>The module accepts the following configuration parameters. Some of them, if
unspecified, default to the values specified for the top level of
configuration. This lets you avoid specifying, for example, the bind password,
in multiple places.</P><P> <A NAME="msrlfilters"></A> </P><!--TOC paragraph Filters-->
<H5 CLASS="paragraph"><!--SEC ANCHOR --><A HREF="#msrlfilters">Filters</A></H5><!--SEC END --><P> <A NAME="msrlfilters"></A> </P><P>These parameters specify LDAP filters used to query for shared roster information.
All of them are run against the <CODE>ldap_base</CODE>.</P><DL CLASS="description"><DT CLASS="dt-description"><B><TT>ldap_rfilter</TT></B></DT><DD CLASS="dd-description">
So called &#X201C;Roster Filter&#X201D;. Used to find names of all &#X201C;shared roster&#X201D; groups.
See also the <CODE>ldap_groupattr</CODE> parameter.
If unspecified, defaults to the top-level parameter of the same name.
You <EM>must</EM> specify it in some place in the configuration, there is no default.</DD><DT CLASS="dt-description"><B><TT>ldap_ufilter</TT></B></DT><DD CLASS="dd-description">
&#X201C;User Filter&#X201D; &#X2013; used for retrieving the human-readable name of roster
entries (usually full names of people in the roster).
See also the parameters <CODE>ldap_userdesc</CODE> and <CODE>ldap_useruid</CODE>.
If unspecified, defaults to the top-level parameter of the same name.
If that one also is unspecified, then the filter is assembled from values of
other parameters as follows (<CODE>[ldap_SOMETHING]</CODE> is used to mean &#X201C;the
value of the configuration parameter <TT>ldap_SOMETHING</TT>&#X201D;):<PRE CLASS="verbatim">(&amp;(&amp;([ldap_memberattr]=[ldap_memberattr_format])([ldap_groupattr]=%g))[ldap_filter])
</PRE><P>Subsequently <TT>%u</TT> and <TT>%g</TT> are replaced with a <TT>*</TT>. This means
that given the defaults, the filter sent to the LDAP server is would be
<CODE>(&amp;(memberUid=*)(cn=*))</CODE>. If however the <TT>ldap_memberattr_format</TT>
is something like <CODE>uid=%u,ou=People,o=org</CODE>, then the filter will be
<CODE>(&amp;(memberUid=uid=*,ou=People,o=org)(cn=*))</CODE>.</P></DD><DT CLASS="dt-description"><B><TT>ldap_gfilter</TT></B></DT><DD CLASS="dd-description">
&#X201C;Group Filter&#X201D; &#X2013; used when retrieving human-readable name (a.k.a.
&#X201C;Display Name&#X201D;) and the members of a group.
See also the parameters <CODE>ldap_groupattr</CODE>, <CODE>ldap_groupdesc</CODE> and <CODE>ldap_memberattr</CODE>.
If unspecified, defaults to the top-level parameter of the same name.
If that one also is unspecified, then the filter is constructed exactly in the
same way as <TT>User Filter</TT>.</DD><DT CLASS="dt-description"><B><TT>ldap_filter</TT></B></DT><DD CLASS="dd-description">
Additional filter which is AND-ed together with <TT>User Filter</TT> and <TT>Group Filter</TT>.
If unspecified, defaults to the top-level parameter of the same name. If that
one is also unspecified, then no additional filter is merged with the other
filters.
</DD></DL><P>Note that you will probably need to manually define the <TT>User</TT> and <TT>Group Filter</TT>s (since the auto-assembled ones will not work) if:
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
your <TT>ldap_memberattr_format</TT> is anything other than a simple <TT>%u</TT>,
</LI><LI CLASS="li-itemize"><B>and</B> the attribute specified with <TT>ldap_memberattr</TT> does not support substring matches.
</LI></UL><P>
An example where it is the case is OpenLDAP and <TT>(unique)MemberName</TT> attribute from the <TT>groupOf(Unique)Names</TT> objectClass.
A symptom of this problem is that you will see messages such as the following in your <TT>slapd.log</TT>:
</P><PRE CLASS="verbatim">get_filter: unknown filter type=130
filter="(&amp;(?=undefined)(?=undefined)(something=else))"
</PRE><P> <A NAME="msrlattrs"></A> </P><!--TOC subsubsection Attributes-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A HREF="#msrlattrs">Attributes</A></H4><!--SEC END --><P> <A NAME="msrlattrs"></A> </P><P>These parameters specify the names of the attributes which hold interesting data
in the entries returned by running filters specified in
section&#XA0;<A HREF="#msrlfilters">3.3.23</A>.</P><DL CLASS="description"><DT CLASS="dt-description">
<B><TT>ldap_groupattr</TT></B></DT><DD CLASS="dd-description">
The name of the attribute that holds the group name, and that is used to differentiate between them.
Retrieved from results of the &#X201C;Roster Filter&#X201D; and &#X201C;Group Filter&#X201D;.
Defaults to <TT>cn</TT>.</DD><DT CLASS="dt-description"><B><TT>ldap_groupdesc</TT></B></DT><DD CLASS="dd-description">
The name of the attribute which holds the human-readable group name in the
objects you use to represent groups.
Retrieved from results of the &#X201C;Group Filter&#X201D;.
Defaults to whatever <TT>ldap_groupattr</TT> is set.</DD><DT CLASS="dt-description"><B><TT>ldap_memberattr</TT></B></DT><DD CLASS="dd-description">
The name of the attribute which holds the IDs of the members of a group.
Retrieved from results of the &#X201C;Group Filter&#X201D;.
Defaults to <TT>memberUid</TT>.<P>The name of the attribute differs depending on the <TT>objectClass</TT> you use
for your group objects, for example:
</P><DL CLASS="description"><DT CLASS="dt-description">
</DT><DD CLASS="dd-description"><TT>posixGroup</TT> &#X2192; <TT>memberUid</TT>
</DD><DT CLASS="dt-description"></DT><DD CLASS="dd-description"><TT>groupOfNames</TT> &#X2192; <TT>member</TT>
</DD><DT CLASS="dt-description"></DT><DD CLASS="dd-description"><TT>groupOfUniqueNames</TT> &#X2192; <TT>uniqueMember</TT>
</DD></DL></DD><DT CLASS="dt-description"><B><TT>ldap_userdesc</TT></B></DT><DD CLASS="dd-description">
The name of the attribute which holds the human-readable user name.
Retrieved from results of the &#X201C;User Filter&#X201D;.
Defaults to <TT>cn</TT>.</DD><DT CLASS="dt-description"><B><TT>ldap_useruid</TT></B></DT><DD CLASS="dd-description">
The name of the attribute which holds the ID of a roster item. Value of this
attribute in the roster item objects needs to match the ID retrieved from the
<TT>ldap_memberattr</TT> attribute of a group object.
Retrieved from results of the &#X201C;User Filter&#X201D;.
Defaults to <TT>cn</TT>.
</DD></DL><P> <A NAME="msrlcontrolparams"></A> </P><!--TOC subsubsection Control parameters-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A HREF="#msrlcontrolparams">Control parameters</A></H4><!--SEC END --><P> <A NAME="msrlcontrolparams"></A> </P><P>These paramters control the behaviour of the module.</P><DL CLASS="description"><DT CLASS="dt-description"><B><TT>ldap_memberattr_format</TT></B></DT><DD CLASS="dd-description">
A globbing format for extracting user ID from the value of the attribute named by
<CODE>ldap_memberattr</CODE>.
Defaults to <TT>%u</TT>, which means that the whole value is the member ID. If
you change it to something different, you may also need to specify the User
and Group Filters manually &#X2014; see section&#XA0;<A HREF="#msrlfilters">3.3.23</A>.</DD><DT CLASS="dt-description"><B><TT>ldap_memberattr_format_re</TT></B></DT><DD CLASS="dd-description">
A regex for extracting user ID from the value of the attribute named by
<CODE>ldap_memberattr</CODE>.<P>An example value <TT>"CN=(</TT><TT>\\</TT><TT>w*),(OU=.*,)*DC=company,DC=com"</TT> works for user IDs such as the following:
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
<TT>CN=Romeo,OU=Montague,DC=company,DC=com</TT>
</LI><LI CLASS="li-itemize"><TT>CN=Abram,OU=Servants,OU=Montague,DC=company,DC=com</TT>
</LI><LI CLASS="li-itemize"><TT>CN=Juliet,OU=Capulet,DC=company,DC=com</TT>
</LI><LI CLASS="li-itemize"><TT>CN=Peter,OU=Servants,OU=Capulet,DC=company,DC=com</TT>
</LI></UL><P>In case:
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
the option is unset,
</LI><LI CLASS="li-itemize">or the <TT>re</TT> module in unavailable in the current Erlang environment,
</LI><LI CLASS="li-itemize">or the regular expression does not compile,
</LI></UL><P>
then instead of a regular expression, a simple format specified by <TT>ldap_memberattr_format</TT> is used. Also, in the last two cases an error
message is logged during the module initialization.</P><P>Also, note that in all cases <TT>ldap_memberattr_format</TT> (and <EM>not</EM> the
regex version) is used for constructing the default &#X201C;User/Group Filter&#X201D; &#X2014;
see section&#XA0;<A HREF="#msrlfilters">3.3.23</A>.</P></DD><DT CLASS="dt-description"><B><TT>ldap_auth_check</TT></B></DT><DD CLASS="dd-description">
Whether the module should check (via the ejabberd authentication subsystem)
for existence of each user in the shared LDAP roster. See
section&#XA0;<A HREF="#msrlconfigroster">3.3.23</A> form more information. Set to <TT>off</TT> if you
want to disable the check.
Defaults to <TT>on</TT>.</DD><DT CLASS="dt-description"><B><TT>ldap_user_cache_validity</TT></B></DT><DD CLASS="dd-description">
Number of seconds for which the cache for roster item full names is considered
fresh after retrieval. 300 by default. See section&#XA0;<A HREF="#msrlconfigroster">3.3.23</A> on
how it is used during roster retrieval.</DD><DT CLASS="dt-description"><B><TT>ldap_group_cache_validity</TT></B></DT><DD CLASS="dd-description">
Number of seconds for which the cache for group membership is considered
fresh after retrieval. 300 by default. See section&#XA0;<A HREF="#msrlconfigroster">3.3.23</A> on
how it is used during roster retrieval.
</DD></DL><P> <A NAME="msrlconnparams"></A> </P><!--TOC subsubsection Connection parameters-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A HREF="#msrlconnparams">Connection parameters</A></H4><!--SEC END --><P> <A NAME="msrlconnparams"></A> </P><P>The module also accepts the connection parameters, all of which default to the
top-level parameter of the same name, if unspecified. See&#XA0;<A HREF="#ldapconnection">3.2.5</A>
for more information about them.</P><P> <A NAME="msrlconfigroster"></A> </P><!--TOC subsubsection Retrieving the roster-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A HREF="#msrlconfigroster">Retrieving the roster</A></H4><!--SEC END --><P> <A NAME="msrlconfigroster"></A> </P><P>When the module is called to retrieve the shared roster for a user, the
following algorithm is used:</P><OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
<A NAME="step:rfilter"></A> A list of names of groups to display is created: the <TT>Roster Filter</TT>
is run against the base DN, retrieving the values of the attribute named by
<TT>ldap_groupattr</TT>.</LI><LI CLASS="li-enumerate">Unless the group cache is fresh (see the <TT>ldap_group_cache_validity</TT> option), it is refreshed:<OL CLASS="enumerate" type=a><LI CLASS="li-enumerate">
Information for all groups is retrieved using a single query: the <TT>Group Filter</TT> is run against the Base DN, retrieving the values of attributes
named by <TT>ldap_groupattr</TT> (group ID), <TT>ldap_groupdesc</TT> (group
&#X201C;Display Name&#X201D;) and <TT>ldap_memberattr</TT> (IDs of group members).</LI><LI CLASS="li-enumerate">group &#X201C;Display Name&#X201D;, read from the attribute named by <TT>ldap_groupdesc</TT>, is stored in the cache for the given group</LI><LI CLASS="li-enumerate">the following processing takes place for each retrieved value of
attribute named by <TT>ldap_memberattr</TT>:
<OL CLASS="enumerate" type=i><LI CLASS="li-enumerate">
the user ID part of it is extracted using <TT>ldap_memberattr_format(_re)</TT>,</LI><LI CLASS="li-enumerate">then (unless <TT>ldap_auth_check</TT> is set to <TT>off</TT>) for each
found user ID, the module checks (using the <TT>ejabberd</TT> authentication
subsystem) whether such user exists in the given virtual host. It is
skipped if the check is enabled and fails.<P>This step is here for historical reasons. If you have a tidy DIT and
properly defined &#X201C;Roster Filter&#X201D; and &#X201C;Group Filter&#X201D;, it is safe to
disable it by setting <TT>ldap_auth_check</TT> to <TT>off</TT> &#X2014; it will
speed up the roster retrieval.</P></LI><LI CLASS="li-enumerate">the user ID is stored in the list of members in the cache for the
given group
</LI></OL>
</LI></OL></LI><LI CLASS="li-enumerate">For each item (group name) in the list of groups retrieved in step&#XA0;<A HREF="#step:rfilter">1</A>:<OL CLASS="enumerate" type=a><LI CLASS="li-enumerate">
the display name of a shared roster group is retrieved from the group
cache</LI><LI CLASS="li-enumerate">for each IDs of users which belong to the group, retrieved from the
group cache:<OL CLASS="enumerate" type=i><LI CLASS="li-enumerate">
the ID is skipped if it&#X2019;s the same as the one for which we are
retrieving the roster. This is so that the user does not have himself in
the roster.</LI><LI CLASS="li-enumerate">the display name of a shared roster user is retrieved:
<OL CLASS="enumerate" type=A><LI CLASS="li-enumerate">
first, unless the user name cache is fresh (see the <TT>ldap_user_cache_validity</TT> option), it is refreshed by running the
<TT>User Filter</TT>, against the Base DN, retrieving the values of
attributes named by <TT>ldap_useruid</TT> and <TT>ldap_userdesc</TT>.
</LI><LI CLASS="li-enumerate">then, the display name for the given user ID is retrieved from the
user name cache.
</LI></OL>
</LI></OL></LI></OL></LI></OL><P> <A NAME="msrlconfigexample"></A> </P><!--TOC subsubsection Configuration examples-->
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A HREF="#msrlconfigexample">Configuration examples</A></H4><!--SEC END --><P> <A NAME="msrlconfigexample"></A> </P><P>Since there are many possible
<A HREF="http://en.wikipedia.org/wiki/Directory_Information_Tree">DIT</A>
layouts, it will probably be easiest to understand how to configure the module
by looking at an example for a given DIT (or one resembling it).</P><P> <A NAME="msrlconfigexampleflat"></A> </P><!--TOC paragraph Flat DIT-->
<H5 CLASS="paragraph"><!--SEC ANCHOR --><A HREF="#msrlconfigexampleflat">Flat DIT</A></H5><!--SEC END --><P> <A NAME="msrlconfigexampleflat"></A> </P><P>This seems to be the kind of DIT for which this module was initially designed.
Basically there are just user objects, and group membership is stored in an
attribute individually for each user. For example in a layout shown in
figure&#XA0;<A HREF="#fig:msrl-dit-flat">3.1</A>, the group of each user is stored in its <TT>ou</TT> attribute.</P><BLOCKQUOTE CLASS="figure"><DIV CLASS="center"><DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV>
<IMG SRC="msrl-dit-flat.png" ALT="msrl-dit-flat.png">
<DIV CLASS="caption"><TABLE CELLSPACING=6 CELLPADDING=0><TR><TD VALIGN=top ALIGN=left>Figure 3.1: Flat DIT graph</TD></TR>
</TABLE></DIV>
<A NAME="fig:msrl-dit-flat"></A>
<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></DIV></BLOCKQUOTE><P>Such layout has a few downsides, including:
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
information duplication &#X2013; the group name is repeated in every member object
</LI><LI CLASS="li-itemize">difficult group management &#X2013; information about group members is not
centralized, but distributed between member objects
</LI><LI CLASS="li-itemize">inefficiency &#X2013; the list of unique group names has to be computed by iterating over all users
</LI></UL><P>This however seems to be a common DIT layout, so the module keeps supporting it.
You can use the following configuration&#X2026;</P><PRE CLASS="verbatim"> {mod_shared_roster_ldap,[
{ldap_base, "ou=flat,dc=nodomain"},
{ldap_rfilter, "(objectClass=inetOrgPerson)"},
{ldap_groupattr, "ou"},
{ldap_memberattr, "cn"},
{ldap_filter, "(objectClass=inetOrgPerson)"},
{ldap_userdesc, "displayName"}
]},
</PRE><P>&#X2026;to be provided with a roster as shown in figure&#XA0;<A HREF="#fig:msrl-roster-flat">3.2</A> upon connecting as user <TT>czesio</TT>.</P><BLOCKQUOTE CLASS="figure"><DIV CLASS="center"><DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV>
<IMG SRC="msrl-roster-flat.png" ALT="msrl-roster-flat.png">
<DIV CLASS="caption"><TABLE CELLSPACING=6 CELLPADDING=0><TR><TD VALIGN=top ALIGN=left>Figure 3.2: Roster from flat DIT</TD></TR>
</TABLE></DIV>
<A NAME="fig:msrl-roster-flat"></A>
<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></DIV></BLOCKQUOTE><P> <A NAME="msrlconfigexampledeep"></A> </P><!--TOC paragraph Deep DIT-->
<H5 CLASS="paragraph"><!--SEC ANCHOR --><A HREF="#msrlconfigexampledeep">Deep DIT</A></H5><!--SEC END --><P> <A NAME="msrlconfigexampledeep"></A> </P><P>This type of DIT contains distinctly typed objects for users and groups &#X2013; see figure&#XA0;<A HREF="#fig:msrl-dit-deep">3.3</A>.
They are shown separated into different subtrees, but it&#X2019;s not a requirement.</P><BLOCKQUOTE CLASS="figure"><DIV CLASS="center"><DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV>
<IMG SRC="msrl-dit-deep.png" ALT="msrl-dit-deep.png">
<DIV CLASS="caption"><TABLE CELLSPACING=6 CELLPADDING=0><TR><TD VALIGN=top ALIGN=left>Figure 3.3: Example &#X201C;deep&#X201D; DIT graph</TD></TR>
</TABLE></DIV>
<A NAME="fig:msrl-dit-deep"></A>
<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></DIV></BLOCKQUOTE><P>If you use the following example module configuration with it:
</P><PRE CLASS="verbatim"> {mod_shared_roster_ldap,[
{ldap_base, "ou=deep,dc=nodomain"},
{ldap_rfilter, "(objectClass=groupOfUniqueNames)"},
{ldap_filter, ""},
{ldap_gfilter, "(&amp;(objectClass=groupOfUniqueNames)(cn=%g))"},
{ldap_groupdesc, "description"},
{ldap_memberattr, "uniqueMember"},
{ldap_memberattr_format, "cn=%u,ou=people,ou=deep,dc=nodomain"},
{ldap_ufilter, "(&amp;(objectClass=inetOrgPerson)(cn=%u))"},
{ldap_userdesc, "displayName"}
]},
</PRE><P>&#X2026;and connect as user <TT>czesio</TT>, then <TT>ejabberd</TT> will provide you with
the roster shown in figure&#XA0;<A HREF="#fig:msrl-roster-deep">3.4</A>.</P><BLOCKQUOTE CLASS="figure"><DIV CLASS="center"><DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV>
<IMG SRC="msrl-roster-deep.png" ALT="msrl-roster-deep.png">
<DIV CLASS="caption"><TABLE CELLSPACING=6 CELLPADDING=0><TR><TD VALIGN=top ALIGN=left>Figure 3.4: Example roster from &#X201C;deep&#X201D; DIT</TD></TR>
</TABLE></DIV>
<A NAME="fig:msrl-roster-deep"></A>
<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></DIV></BLOCKQUOTE><P> <A NAME="modsic"></A> </P><!--TOC subsection <TT>mod_sic</TT>-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc62">3.3.24</A>&#XA0;&#XA0;<A HREF="#modsic"><TT>mod_sic</TT></A></H3><!--SEC END --><P> <A NAME="modsic"></A>
</P><P>This module adds support for Server IP Check (<A HREF="http://xmpp.org/extensions/xep-0279.html">XEP-0279</A>). This protocol
enables a client to discover its external IP address.</P><P>Options:
</P><DL CLASS="description"><DT CLASS="dt-description">
<B><TT>{iqdisc, Discipline}</TT></B></DT><DD CLASS="dd-description"> This specifies
the processing discipline for <TT>urn:xmpp:sic:0</TT> IQ queries (see section&#XA0;<A HREF="#modiqdiscoption">3.3.2</A>).
</DD></DL><P> <A NAME="modstats"></A> </P><!--TOC subsection <TT>mod_stats</TT>-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc62">3.3.24</A>&#XA0;&#XA0;<A HREF="#modstats"><TT>mod_stats</TT></A></H3><!--SEC END --><P> <A NAME="modstats"></A>
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc63">3.3.25</A>&#XA0;&#XA0;<A HREF="#modstats"><TT>mod_stats</TT></A></H3><!--SEC END --><P> <A NAME="modstats"></A>
</P><P>This module adds support for Statistics Gathering (<A HREF="http://xmpp.org/extensions/xep-0039.html">XEP-0039</A>). This protocol
allows you to retrieve next statistics from your <TT>ejabberd</TT> deployment:
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
@ -3247,14 +3485,14 @@ by sending:
&lt;/query&gt;
&lt;/iq&gt;
</PRE></LI></UL><P> <A NAME="modtime"></A> </P><!--TOC subsection <TT>mod_time</TT>-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc63">3.3.25</A>&#XA0;&#XA0;<A HREF="#modtime"><TT>mod_time</TT></A></H3><!--SEC END --><P> <A NAME="modtime"></A>
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc64">3.3.26</A>&#XA0;&#XA0;<A HREF="#modtime"><TT>mod_time</TT></A></H3><!--SEC END --><P> <A NAME="modtime"></A>
</P><P>This module features support for Entity Time (<A HREF="http://xmpp.org/extensions/xep-0202.html">XEP-0202</A>). By using this XEP,
you are able to discover the time at another entity&#X2019;s location.</P><P>Options:
</P><DL CLASS="description"><DT CLASS="dt-description">
<B><TT>{iqdisc, Discipline}</TT></B></DT><DD CLASS="dd-description"> This specifies
the processing discipline for Entity Time (<TT>jabber:iq:time</TT>) IQ queries (see section&#XA0;<A HREF="#modiqdiscoption">3.3.2</A>).
</DD></DL><P> <A NAME="modvcard"></A> </P><!--TOC subsection <TT>mod_vcard</TT>-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc64">3.3.26</A>&#XA0;&#XA0;<A HREF="#modvcard"><TT>mod_vcard</TT></A></H3><!--SEC END --><P> <A NAME="modvcard"></A>
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc65">3.3.27</A>&#XA0;&#XA0;<A HREF="#modvcard"><TT>mod_vcard</TT></A></H3><!--SEC END --><P> <A NAME="modvcard"></A>
</P><P>This module allows end users to store and retrieve their vCard, and to retrieve
other users vCards, as defined in vcard-temp (<A HREF="http://xmpp.org/extensions/xep-0054.html">XEP-0054</A>). The module also
implements an uncomplicated Jabber User Directory based on the vCards of
@ -3309,7 +3547,7 @@ and that all virtual hosts will be searched instead of only the current one:
...
]}.
</PRE></LI></UL><P> <A NAME="modvcardldap"></A> </P><!--TOC subsection <TT>mod_vcard_ldap</TT>-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc65">3.3.27</A>&#XA0;&#XA0;<A HREF="#modvcardldap"><TT>mod_vcard_ldap</TT></A></H3><!--SEC END --><P> <A NAME="modvcardldap"></A>
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc66">3.3.28</A>&#XA0;&#XA0;<A HREF="#modvcardldap"><TT>mod_vcard_ldap</TT></A></H3><!--SEC END --><P> <A NAME="modvcardldap"></A>
</P><P><TT>ejabberd</TT> can map LDAP attributes to vCard fields. This behaviour is
implemented in the <TT>mod_vcard_ldap</TT> module. This module does not depend on the
authentication method (see&#XA0;<A HREF="#ldapauth">3.2.5</A>).</P><P>Usually <TT>ejabberd</TT> treats LDAP as a read-only storage:
@ -3491,7 +3729,7 @@ searching his info in LDAP.</P></LI><LI CLASS="li-itemize"><TT>ldap_vcard_map</T
{"Nickname", "NICKNAME"}
]},
</PRE></LI></UL><P> <A NAME="modvcardxupdate"></A> </P><!--TOC subsection <TT>mod_vcard_xupdate</TT>-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc66">3.3.28</A>&#XA0;&#XA0;<A HREF="#modvcardxupdate"><TT>mod_vcard_xupdate</TT></A></H3><!--SEC END --><P> <A NAME="modvcardxupdate"></A>
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc67">3.3.29</A>&#XA0;&#XA0;<A HREF="#modvcardxupdate"><TT>mod_vcard_xupdate</TT></A></H3><!--SEC END --><P> <A NAME="modvcardxupdate"></A>
</P><P>The user&#X2019;s client can store an avatar in the user vCard.
The vCard-Based Avatars protocol (<A HREF="http://xmpp.org/extensions/xep-0153.html">XEP-0153</A>)
provides a method for clients to inform the contacts what is the avatar hash value.
@ -3505,7 +3743,7 @@ and each presence sent by a client produces hash retrieval and a
presence stanza rewrite.
For this reason, enabling this module will introduce a computational overhead
in servers with clients that change frequently their presence.</P><P> <A NAME="modversion"></A> </P><!--TOC subsection <TT>mod_version</TT>-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc67">3.3.29</A>&#XA0;&#XA0;<A HREF="#modversion"><TT>mod_version</TT></A></H3><!--SEC END --><P> <A NAME="modversion"></A>
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc68">3.3.30</A>&#XA0;&#XA0;<A HREF="#modversion"><TT>mod_version</TT></A></H3><!--SEC END --><P> <A NAME="modversion"></A>
</P><P>This module implements Software Version (<A HREF="http://xmpp.org/extensions/xep-0092.html">XEP-0092</A>). Consequently, it
answers <TT>ejabberd</TT>&#X2019;s version when queried.</P><P>Options:
</P><DL CLASS="description"><DT CLASS="dt-description">
@ -3514,8 +3752,8 @@ The default value is <TT>true</TT>.
</DD><DT CLASS="dt-description"><B><TT>{iqdisc, Discipline}</TT></B></DT><DD CLASS="dd-description"> This specifies
the processing discipline for Software Version (<TT>jabber:iq:version</TT>) IQ queries (see section&#XA0;<A HREF="#modiqdiscoption">3.3.2</A>).
</DD></DL><P> <A NAME="manage"></A> </P><!--TOC chapter Managing an <TT>ejabberd</TT> Server-->
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc68">Chapter&#XA0;4</A>&#XA0;&#XA0;<A HREF="#manage">Managing an <TT>ejabberd</TT> Server</A></H1><!--SEC END --><P> <A NAME="manage"></A> </P><P> <A NAME="ejabberdctl"></A> </P><!--TOC section <TT>ejabberdctl</TT>-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc69">4.1</A>&#XA0;&#XA0;<A HREF="#ejabberdctl"><TT>ejabberdctl</TT></A></H2><!--SEC END --><P> <A NAME="ejabberdctl"></A> </P><P>With the <TT>ejabberdctl</TT> command line administration script
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc69">Chapter&#XA0;4</A>&#XA0;&#XA0;<A HREF="#manage">Managing an <TT>ejabberd</TT> Server</A></H1><!--SEC END --><P> <A NAME="manage"></A> </P><P> <A NAME="ejabberdctl"></A> </P><!--TOC section <TT>ejabberdctl</TT>-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc70">4.1</A>&#XA0;&#XA0;<A HREF="#ejabberdctl"><TT>ejabberdctl</TT></A></H2><!--SEC END --><P> <A NAME="ejabberdctl"></A> </P><P>With the <TT>ejabberdctl</TT> command line administration script
you can execute <TT>ejabberdctl commands</TT> (described in the next section, <A HREF="#ectl-commands">4.1.1</A>)
and also many general <TT>ejabberd commands</TT> (described in section <A HREF="#eja-commands">4.2</A>).
This means you can start, stop and perform many other administrative tasks
@ -3527,7 +3765,7 @@ and other codes may be used for specific results.
This can be used by other scripts to determine automatically
if a command succeeded or failed,
for example using: <TT>echo $?</TT></P><P> <A NAME="ectl-commands"></A> </P><!--TOC subsection ejabberdctl Commands-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc70">4.1.1</A>&#XA0;&#XA0;<A HREF="#ectl-commands">ejabberdctl Commands</A></H3><!--SEC END --><P> <A NAME="ectl-commands"></A> </P><P>When <TT>ejabberdctl</TT> is executed without any parameter,
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc71">4.1.1</A>&#XA0;&#XA0;<A HREF="#ectl-commands">ejabberdctl Commands</A></H3><!--SEC END --><P> <A NAME="ectl-commands"></A> </P><P>When <TT>ejabberdctl</TT> is executed without any parameter,
it displays the available options. If there isn&#X2019;t an <TT>ejabberd</TT> server running,
the available parameters are:
</P><DL CLASS="description"><DT CLASS="dt-description">
@ -3563,7 +3801,7 @@ robot1
testuser1
testuser2
</PRE><P> <A NAME="erlangconfiguration"></A> </P><!--TOC subsection Erlang Runtime System-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc71">4.1.2</A>&#XA0;&#XA0;<A HREF="#erlangconfiguration">Erlang Runtime System</A></H3><!--SEC END --><P> <A NAME="erlangconfiguration"></A> </P><P><TT>ejabberd</TT> is an Erlang/OTP application that runs inside an Erlang runtime system.
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc72">4.1.2</A>&#XA0;&#XA0;<A HREF="#erlangconfiguration">Erlang Runtime System</A></H3><!--SEC END --><P> <A NAME="erlangconfiguration"></A> </P><P><TT>ejabberd</TT> is an Erlang/OTP application that runs inside an Erlang runtime system.
This system is configured using environment variables and command line parameters.
The <TT>ejabberdctl</TT> administration script uses many of those possibilities.
You can configure some of them with the file <TT>ejabberdctl.cfg</TT>,
@ -3640,7 +3878,7 @@ not &#X201C;Simple Authentication and Security Layer&#X201D;.
</DD></DL><P>
Note that some characters need to be escaped when used in shell scripts, for instance <CODE>"</CODE> and <CODE>{}</CODE>.
You can find other options in the Erlang manual page (<TT>erl -man erl</TT>).</P><P> <A NAME="eja-commands"></A> </P><!--TOC section <TT>ejabberd</TT> Commands-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc72">4.2</A>&#XA0;&#XA0;<A HREF="#eja-commands"><TT>ejabberd</TT> Commands</A></H2><!--SEC END --><P> <A NAME="eja-commands"></A> </P><P>An <TT>ejabberd command</TT> is an abstract function identified by a name,
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc73">4.2</A>&#XA0;&#XA0;<A HREF="#eja-commands"><TT>ejabberd</TT> Commands</A></H2><!--SEC END --><P> <A NAME="eja-commands"></A> </P><P>An <TT>ejabberd command</TT> is an abstract function identified by a name,
with a defined number and type of calling arguments and type of result
that is registered in the <TT>ejabberd_commands</TT> service.
Those commands can be defined in any Erlang module and executed using any valid frontend.</P><P><TT>ejabberd</TT> includes a frontend to execute <TT>ejabberd commands</TT>: the script <TT>ejabberdctl</TT>.
@ -3648,7 +3886,7 @@ Other known frontends that can be installed to execute ejabberd commands in diff
<TT>ejabberd_xmlrpc</TT> (XML-RPC service),
<TT>mod_rest</TT> (HTTP POST service),
<TT>mod_shcommands</TT> (ejabberd WebAdmin page).</P><P> <A NAME="list-eja-commands"></A> </P><!--TOC subsection List of ejabberd Commands-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc73">4.2.1</A>&#XA0;&#XA0;<A HREF="#list-eja-commands">List of ejabberd Commands</A></H3><!--SEC END --><P> <A NAME="list-eja-commands"></A> </P><P><TT>ejabberd</TT> includes a few ejabberd Commands by default.
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc74">4.2.1</A>&#XA0;&#XA0;<A HREF="#list-eja-commands">List of ejabberd Commands</A></H3><!--SEC END --><P> <A NAME="list-eja-commands"></A> </P><P><TT>ejabberd</TT> includes a few ejabberd Commands by default.
When more modules are installed, new commands may be available in the frontends.</P><P>The easiest way to get a list of the available commands, and get help for them is to use
the ejabberdctl script:
</P><PRE CLASS="verbatim">$ ejabberdctl help
@ -3700,7 +3938,7 @@ is very high.
</DD><DT CLASS="dt-description"><B><TT>register user host password</TT></B></DT><DD CLASS="dd-description"> Register an account in that domain with the given password.
</DD><DT CLASS="dt-description"><B><TT>unregister user host</TT></B></DT><DD CLASS="dd-description"> Unregister the given account.
</DD></DL><P> <A NAME="accesscommands"></A> </P><!--TOC subsection Restrict Execution with AccessCommands-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc74">4.2.2</A>&#XA0;&#XA0;<A HREF="#accesscommands">Restrict Execution with AccessCommands</A></H3><!--SEC END --><P> <A NAME="accesscommands"></A> </P><P>The frontends can be configured to restrict access to certain commands.
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc75">4.2.2</A>&#XA0;&#XA0;<A HREF="#accesscommands">Restrict Execution with AccessCommands</A></H3><!--SEC END --><P> <A NAME="accesscommands"></A> </P><P>The frontends can be configured to restrict access to certain commands.
In that case, authentication information must be provided.
In each frontend the <TT>AccessCommands</TT> option is defined
in a different place. But in all cases the option syntax is the same:
@ -3745,7 +3983,7 @@ and the provided arguments do not contradict Arguments.</P><P>As an example to u
{_bot_reg_test, [register, unregister], [{host, "test.org"}]}
]
</PRE><P> <A NAME="webadmin"></A> </P><!--TOC section Web Admin-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc75">4.3</A>&#XA0;&#XA0;<A HREF="#webadmin">Web Admin</A></H2><!--SEC END --><P> <A NAME="webadmin"></A>
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc76">4.3</A>&#XA0;&#XA0;<A HREF="#webadmin">Web Admin</A></H2><!--SEC END --><P> <A NAME="webadmin"></A>
</P><P>The <TT>ejabberd</TT> Web Admin allows to administer most of <TT>ejabberd</TT> using a web browser.</P><P>This feature is enabled by default:
a <TT>ejabberd_http</TT> listener with the option <TT>web_admin</TT> (see
section&#XA0;<A HREF="#listened">3.1.3</A>) is included in the listening ports. Then you can open
@ -3822,13 +4060,13 @@ The file is searched by default in
The directory of the documentation can be specified in
the environment variable <TT>EJABBERD_DOC_PATH</TT>.
See section <A HREF="#erlangconfiguration">4.1.2</A>.</P><P> <A NAME="adhoccommands"></A> </P><!--TOC section Ad-hoc Commands-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc76">4.4</A>&#XA0;&#XA0;<A HREF="#adhoccommands">Ad-hoc Commands</A></H2><!--SEC END --><P> <A NAME="adhoccommands"></A> </P><P>If you enable <TT>mod_configure</TT> and <TT>mod_adhoc</TT>,
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc77">4.4</A>&#XA0;&#XA0;<A HREF="#adhoccommands">Ad-hoc Commands</A></H2><!--SEC END --><P> <A NAME="adhoccommands"></A> </P><P>If you enable <TT>mod_configure</TT> and <TT>mod_adhoc</TT>,
you can perform several administrative tasks in <TT>ejabberd</TT>
with a XMPP client.
The client must support Ad-Hoc Commands (<A HREF="http://xmpp.org/extensions/xep-0050.html">XEP-0050</A>),
and you must login in the XMPP server with
an account with proper privileges.</P><P> <A NAME="changeerlangnodename"></A> </P><!--TOC section Change Computer Hostname-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc77">4.5</A>&#XA0;&#XA0;<A HREF="#changeerlangnodename">Change Computer Hostname</A></H2><!--SEC END --><P> <A NAME="changeerlangnodename"></A> </P><P><TT>ejabberd</TT> uses the distributed Mnesia database.
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc78">4.5</A>&#XA0;&#XA0;<A HREF="#changeerlangnodename">Change Computer Hostname</A></H2><!--SEC END --><P> <A NAME="changeerlangnodename"></A> </P><P><TT>ejabberd</TT> uses the distributed Mnesia database.
Being distributed, Mnesia enforces consistency of its file,
so it stores the name of the Erlang node in it (see section <A HREF="#nodename">5.4</A>).
The name of an Erlang node includes the hostname of the computer.
@ -3874,8 +4112,8 @@ mv /var/lib/ejabberd/*.* /var/lib/ejabberd/oldfiles/
</PRE></LI><LI CLASS="li-enumerate">Check that the information of the old database is available: accounts, rosters...
After you finish, remember to delete the temporary backup files from public directories.
</LI></OL><P> <A NAME="secure"></A> </P><!--TOC chapter Securing <TT>ejabberd</TT>-->
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc78">Chapter&#XA0;5</A>&#XA0;&#XA0;<A HREF="#secure">Securing <TT>ejabberd</TT></A></H1><!--SEC END --><P> <A NAME="secure"></A> </P><P> <A NAME="firewall"></A> </P><!--TOC section Firewall Settings-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc79">5.1</A>&#XA0;&#XA0;<A HREF="#firewall">Firewall Settings</A></H2><!--SEC END --><P> <A NAME="firewall"></A>
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc79">Chapter&#XA0;5</A>&#XA0;&#XA0;<A HREF="#secure">Securing <TT>ejabberd</TT></A></H1><!--SEC END --><P> <A NAME="secure"></A> </P><P> <A NAME="firewall"></A> </P><!--TOC section Firewall Settings-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc80">5.1</A>&#XA0;&#XA0;<A HREF="#firewall">Firewall Settings</A></H2><!--SEC END --><P> <A NAME="firewall"></A>
</P><P>You need to take the following TCP ports in mind when configuring your firewall:
</P><BLOCKQUOTE CLASS="table"><DIV CLASS="center"><DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV>
<TABLE BORDER=1 CELLSPACING=0 CELLPADDING=1><TR><TD ALIGN=left NOWRAP><B>Port</B></TD><TD ALIGN=left NOWRAP><B>Description</B></TD></TR>
@ -3886,7 +4124,7 @@ After you finish, remember to delete the temporary backup files from public dire
<TR><TD ALIGN=left NOWRAP>port range</TD><TD ALIGN=left NOWRAP>Used for connections between Erlang nodes. This range is configurable (see section <A HREF="#epmd">5.2</A>).</TD></TR>
</TABLE>
<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></DIV></BLOCKQUOTE><P> <A NAME="epmd"></A> </P><!--TOC section epmd-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc80">5.2</A>&#XA0;&#XA0;<A HREF="#epmd">epmd</A></H2><!--SEC END --><P> <A NAME="epmd"></A> </P><P><A HREF="http://www.erlang.org/doc/man/epmd.html">epmd (Erlang Port Mapper Daemon)</A>
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc81">5.2</A>&#XA0;&#XA0;<A HREF="#epmd">epmd</A></H2><!--SEC END --><P> <A NAME="epmd"></A> </P><P><A HREF="http://www.erlang.org/doc/man/epmd.html">epmd (Erlang Port Mapper Daemon)</A>
is a small name server included in Erlang/OTP
and used by Erlang programs when establishing distributed Erlang communications.
<TT>ejabberd</TT> needs <TT>epmd</TT> to use <TT>ejabberdctl</TT> and also when clustering <TT>ejabberd</TT> nodes.
@ -3911,7 +4149,7 @@ but can be configured in the file <TT>ejabberdctl.cfg</TT>.
The Erlang command-line parameter used internally is, for example:
</P><PRE CLASS="verbatim">erl ... -kernel inet_dist_listen_min 4370 inet_dist_listen_max 4375
</PRE><P> <A NAME="cookie"></A> </P><!--TOC section Erlang Cookie-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc81">5.3</A>&#XA0;&#XA0;<A HREF="#cookie">Erlang Cookie</A></H2><!--SEC END --><P> <A NAME="cookie"></A> </P><P>The Erlang cookie is a string with numbers and letters.
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc82">5.3</A>&#XA0;&#XA0;<A HREF="#cookie">Erlang Cookie</A></H2><!--SEC END --><P> <A NAME="cookie"></A> </P><P>The Erlang cookie is a string with numbers and letters.
An Erlang node reads the cookie at startup from the command-line parameter <TT>-setcookie</TT>.
If not indicated, the cookie is read from the cookie file <TT>$HOME/.erlang.cookie</TT>.
If this file does not exist, it is created immediately with a random cookie.
@ -3925,7 +4163,7 @@ to prevent unauthorized access or intrusion to an Erlang node.
The communication between Erlang nodes are not encrypted,
so the cookie could be read sniffing the traffic on the network.
The recommended way to secure the Erlang node is to block the port 4369.</P><P> <A NAME="nodename"></A> </P><!--TOC section Erlang Node Name-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc82">5.4</A>&#XA0;&#XA0;<A HREF="#nodename">Erlang Node Name</A></H2><!--SEC END --><P> <A NAME="nodename"></A> </P><P>An Erlang node may have a node name.
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc83">5.4</A>&#XA0;&#XA0;<A HREF="#nodename">Erlang Node Name</A></H2><!--SEC END --><P> <A NAME="nodename"></A> </P><P>An Erlang node may have a node name.
The name can be short (if indicated with the command-line parameter <TT>-sname</TT>)
or long (if indicated with the parameter <TT>-name</TT>).
Starting an Erlang node with -sname limits the communication between Erlang nodes to the LAN.</P><P>Using the option <TT>-sname</TT> instead of <TT>-name</TT> is a simple method
@ -3934,7 +4172,7 @@ However, it is not ultimately effective to prevent access to the Erlang node,
because it may be possible to fake the fact that you are on another network
using a modified version of Erlang <TT>epmd</TT>.
The recommended way to secure the Erlang node is to block the port 4369.</P><P> <A NAME="secure-files"></A> </P><!--TOC section Securing Sensitive Files-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc83">5.5</A>&#XA0;&#XA0;<A HREF="#secure-files">Securing Sensitive Files</A></H2><!--SEC END --><P> <A NAME="secure-files"></A> </P><P><TT>ejabberd</TT> stores sensitive data in the file system either in plain text or binary files.
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc84">5.5</A>&#XA0;&#XA0;<A HREF="#secure-files">Securing Sensitive Files</A></H2><!--SEC END --><P> <A NAME="secure-files"></A> </P><P><TT>ejabberd</TT> stores sensitive data in the file system either in plain text or binary files.
The file system permissions should be set to only allow the proper user to read,
write and execute those files and directories.</P><DL CLASS="description"><DT CLASS="dt-description">
<B><TT>ejabberd configuration file: /etc/ejabberd/ejabberd.cfg</TT></B></DT><DD CLASS="dd-description">
@ -3954,9 +4192,9 @@ so it is preferable to secure the whole <TT>/var/lib/ejabberd/</TT> directory.
</DD><DT CLASS="dt-description"><B><TT>Erlang cookie file: /var/lib/ejabberd/.erlang.cookie</TT></B></DT><DD CLASS="dd-description">
See section <A HREF="#cookie">5.3</A>.
</DD></DL><P> <A NAME="clustering"></A> </P><!--TOC chapter Clustering-->
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc84">Chapter&#XA0;6</A>&#XA0;&#XA0;<A HREF="#clustering">Clustering</A></H1><!--SEC END --><P> <A NAME="clustering"></A>
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc85">Chapter&#XA0;6</A>&#XA0;&#XA0;<A HREF="#clustering">Clustering</A></H1><!--SEC END --><P> <A NAME="clustering"></A>
</P><P> <A NAME="howitworks"></A> </P><!--TOC section How it Works-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc85">6.1</A>&#XA0;&#XA0;<A HREF="#howitworks">How it Works</A></H2><!--SEC END --><P> <A NAME="howitworks"></A>
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc86">6.1</A>&#XA0;&#XA0;<A HREF="#howitworks">How it Works</A></H2><!--SEC END --><P> <A NAME="howitworks"></A>
</P><P>A XMPP domain is served by one or more <TT>ejabberd</TT> nodes. These nodes can
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
@ -3970,29 +4208,29 @@ router,
</LI><LI CLASS="li-itemize">session manager,
</LI><LI CLASS="li-itemize">s2s manager.
</LI></UL><P> <A NAME="router"></A> </P><!--TOC subsection Router-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc86">6.1.1</A>&#XA0;&#XA0;<A HREF="#router">Router</A></H3><!--SEC END --><P> <A NAME="router"></A>
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc87">6.1.1</A>&#XA0;&#XA0;<A HREF="#router">Router</A></H3><!--SEC END --><P> <A NAME="router"></A>
</P><P>This module is the main router of XMPP packets on each node. It
routes them based on their destination&#X2019;s domains. It uses a global
routing table. The domain of the packet&#X2019;s destination is searched in the
routing table, and if it is found, the packet is routed to the
appropriate process. If not, it is sent to the s2s manager.</P><P> <A NAME="localrouter"></A> </P><!--TOC subsection Local Router-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc87">6.1.2</A>&#XA0;&#XA0;<A HREF="#localrouter">Local Router</A></H3><!--SEC END --><P> <A NAME="localrouter"></A>
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc88">6.1.2</A>&#XA0;&#XA0;<A HREF="#localrouter">Local Router</A></H3><!--SEC END --><P> <A NAME="localrouter"></A>
</P><P>This module routes packets which have a destination domain equal to
one of this server&#X2019;s host names. If the destination JID has a non-empty user
part, it is routed to the session manager, otherwise it is processed depending
on its content.</P><P> <A NAME="sessionmanager"></A> </P><!--TOC subsection Session Manager-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc88">6.1.3</A>&#XA0;&#XA0;<A HREF="#sessionmanager">Session Manager</A></H3><!--SEC END --><P> <A NAME="sessionmanager"></A>
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc89">6.1.3</A>&#XA0;&#XA0;<A HREF="#sessionmanager">Session Manager</A></H3><!--SEC END --><P> <A NAME="sessionmanager"></A>
</P><P>This module routes packets to local users. It looks up to which user
resource a packet must be sent via a presence table. Then the packet is
either routed to the appropriate c2s process, or stored in offline
storage, or bounced back.</P><P> <A NAME="s2smanager"></A> </P><!--TOC subsection s2s Manager-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc89">6.1.4</A>&#XA0;&#XA0;<A HREF="#s2smanager">s2s Manager</A></H3><!--SEC END --><P> <A NAME="s2smanager"></A>
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc90">6.1.4</A>&#XA0;&#XA0;<A HREF="#s2smanager">s2s Manager</A></H3><!--SEC END --><P> <A NAME="s2smanager"></A>
</P><P>This module routes packets to other XMPP servers. First, it
checks if an opened s2s connection from the domain of the packet&#X2019;s
source to the domain of the packet&#X2019;s destination exists. If that is the case,
the s2s manager routes the packet to the process
serving this connection, otherwise a new connection is opened.</P><P> <A NAME="cluster"></A> </P><!--TOC section Clustering Setup-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc90">6.2</A>&#XA0;&#XA0;<A HREF="#cluster">Clustering Setup</A></H2><!--SEC END --><P> <A NAME="cluster"></A>
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc91">6.2</A>&#XA0;&#XA0;<A HREF="#cluster">Clustering Setup</A></H2><!--SEC END --><P> <A NAME="cluster"></A>
</P><P>Suppose you already configured <TT>ejabberd</TT> on one machine named (<TT>first</TT>),
and you need to setup another one to make an <TT>ejabberd</TT> cluster. Then do
following steps:</P><OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
@ -4030,10 +4268,10 @@ and &#X2018;<CODE>access</CODE>&#X2019; options because they will be taken from
enabled only on one machine in the cluster.
</LI></OL><P>You can repeat these steps for other machines supposed to serve this
domain.</P><P> <A NAME="servicelb"></A> </P><!--TOC section Service Load-Balancing-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc91">6.3</A>&#XA0;&#XA0;<A HREF="#servicelb">Service Load-Balancing</A></H2><!--SEC END --><P> <A NAME="servicelb"></A>
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc92">6.3</A>&#XA0;&#XA0;<A HREF="#servicelb">Service Load-Balancing</A></H2><!--SEC END --><P> <A NAME="servicelb"></A>
</P><P> <A NAME="componentlb"></A> </P><!--TOC subsection Components Load-Balancing-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc92">6.3.1</A>&#XA0;&#XA0;<A HREF="#componentlb">Components Load-Balancing</A></H3><!--SEC END --><P> <A NAME="componentlb"></A> </P><P> <A NAME="domainlb"></A> </P><!--TOC subsection Domain Load-Balancing Algorithm-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc93">6.3.2</A>&#XA0;&#XA0;<A HREF="#domainlb">Domain Load-Balancing Algorithm</A></H3><!--SEC END --><P> <A NAME="domainlb"></A>
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc93">6.3.1</A>&#XA0;&#XA0;<A HREF="#componentlb">Components Load-Balancing</A></H3><!--SEC END --><P> <A NAME="componentlb"></A> </P><P> <A NAME="domainlb"></A> </P><!--TOC subsection Domain Load-Balancing Algorithm-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc94">6.3.2</A>&#XA0;&#XA0;<A HREF="#domainlb">Domain Load-Balancing Algorithm</A></H3><!--SEC END --><P> <A NAME="domainlb"></A>
</P><P><TT>ejabberd</TT> includes an algorithm to load balance the components that are plugged on an <TT>ejabberd</TT> cluster. It means that you can plug one or several instances of the same component on each <TT>ejabberd</TT> cluster and that the traffic will be automatically distributed.</P><P>The default distribution algorithm try to deliver to a local instance of a component. If several local instances are available, one instance is chosen randomly. If no instance is available locally, one instance is chosen randomly among the remote component instances.</P><P>If you need a different behaviour, you can change the load balancing behaviour with the option <TT>domain_balancing</TT>. The syntax of the option is the following:
</P><DL CLASS="description"><DT CLASS="dt-description"><B><TT>{domain_balancing, "component.example.com", BalancingCriteria}.</TT></B></DT></DL><P>Several balancing criteria are available:
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
@ -4042,12 +4280,12 @@ domain.</P><P> <A NAME="servicelb"></A> </P><!--TOC section Service Load-Balanci
</LI><LI CLASS="li-itemize"><TT>bare_destination</TT>: the bare JID (without resource) of the packet <TT>to</TT> attribute is used.
</LI><LI CLASS="li-itemize"><TT>bare_source</TT>: the bare JID (without resource) of the packet <TT>from</TT> attribute is used.
</LI></UL><P>If the value corresponding to the criteria is the same, the same component instance in the cluster will be used.</P><P> <A NAME="lbbuckets"></A> </P><!--TOC subsection Load-Balancing Buckets-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc94">6.3.3</A>&#XA0;&#XA0;<A HREF="#lbbuckets">Load-Balancing Buckets</A></H3><!--SEC END --><P> <A NAME="lbbuckets"></A>
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc95">6.3.3</A>&#XA0;&#XA0;<A HREF="#lbbuckets">Load-Balancing Buckets</A></H3><!--SEC END --><P> <A NAME="lbbuckets"></A>
</P><P>When there is a risk of failure for a given component, domain balancing can cause service trouble. If one component is failing the service will not work correctly unless the sessions are rebalanced.</P><P>In this case, it is best to limit the problem to the sessions handled by the failing component. This is what the <TT>domain_balancing_component_number</TT> option does, making the load balancing algorithm not dynamic, but sticky on a fix number of component instances.</P><P>The syntax is:
</P><DL CLASS="description"><DT CLASS="dt-description"><B><TT>{domain_balancing_component_number, "component.example.com", Number}.</TT></B></DT></DL><P> <A NAME="debugging"></A> </P><!--TOC chapter Debugging-->
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc95">Chapter&#XA0;7</A>&#XA0;&#XA0;<A HREF="#debugging">Debugging</A></H1><!--SEC END --><P> <A NAME="debugging"></A>
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc96">Chapter&#XA0;7</A>&#XA0;&#XA0;<A HREF="#debugging">Debugging</A></H1><!--SEC END --><P> <A NAME="debugging"></A>
</P><P> <A NAME="logfiles"></A> </P><!--TOC section Log Files-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc96">7.1</A>&#XA0;&#XA0;<A HREF="#logfiles">Log Files</A></H2><!--SEC END --><P> <A NAME="logfiles"></A> </P><P>An <TT>ejabberd</TT> node writes two log files:
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc97">7.1</A>&#XA0;&#XA0;<A HREF="#logfiles">Log Files</A></H2><!--SEC END --><P> <A NAME="logfiles"></A> </P><P>An <TT>ejabberd</TT> node writes two log files:
</P><DL CLASS="description"><DT CLASS="dt-description">
<B><TT>ejabberd.log</TT></B></DT><DD CLASS="dd-description"> is the ejabberd service log, with the messages reported by <TT>ejabberd</TT> code
</DD><DT CLASS="dt-description"><B><TT>erlang.log</TT></B></DT><DD CLASS="dd-description"> is the Erlang/OTP system log, with the messages reported by Erlang/OTP using SASL (System Architecture Support Libraries)
@ -4072,12 +4310,12 @@ The ejabberdctl command <TT>reopen-log</TT>
(please refer to section <A HREF="#ectl-commands">4.1.1</A>)
reopens the log files,
and also renames the old ones if you didn&#X2019;t rename them.</P><P> <A NAME="debugconsole"></A> </P><!--TOC section Debug Console-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc97">7.2</A>&#XA0;&#XA0;<A HREF="#debugconsole">Debug Console</A></H2><!--SEC END --><P> <A NAME="debugconsole"></A> </P><P>The Debug Console is an Erlang shell attached to an already running <TT>ejabberd</TT> server.
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc98">7.2</A>&#XA0;&#XA0;<A HREF="#debugconsole">Debug Console</A></H2><!--SEC END --><P> <A NAME="debugconsole"></A> </P><P>The Debug Console is an Erlang shell attached to an already running <TT>ejabberd</TT> server.
With this Erlang shell, an experienced administrator can perform complex tasks.</P><P>This shell gives complete control over the <TT>ejabberd</TT> server,
so it is important to use it with extremely care.
There are some simple and safe examples in the article
<A HREF="http://www.ejabberd.im/interconnect-erl-nodes">Interconnecting Erlang Nodes</A></P><P>To exit the shell, close the window or press the keys: control+c control+c.</P><P> <A NAME="watchdog"></A> </P><!--TOC section Watchdog Alerts-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc98">7.3</A>&#XA0;&#XA0;<A HREF="#watchdog">Watchdog Alerts</A></H2><!--SEC END --><P> <A NAME="watchdog"></A>
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc99">7.3</A>&#XA0;&#XA0;<A HREF="#watchdog">Watchdog Alerts</A></H2><!--SEC END --><P> <A NAME="watchdog"></A>
</P><P><TT>ejabberd</TT> includes a watchdog mechanism that may be useful to developers
when troubleshooting a problem related to memory usage.
If a process in the <TT>ejabberd</TT> server consumes more memory than the configured threshold,
@ -4097,7 +4335,7 @@ or in a conversation with the watchdog alert bot.</P><P>The syntax is:
To remove all watchdog admins, set the option with an empty list:
</P><PRE CLASS="verbatim">{watchdog_admins, []}.
</PRE><P> <A NAME="i18ni10n"></A> </P><!--TOC chapter Internationalization and Localization-->
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc99">Appendix&#XA0;A</A>&#XA0;&#XA0;<A HREF="#i18ni10n">Internationalization and Localization</A></H1><!--SEC END --><P> <A NAME="i18ni10n"></A>
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc100">Appendix&#XA0;A</A>&#XA0;&#XA0;<A HREF="#i18ni10n">Internationalization and Localization</A></H1><!--SEC END --><P> <A NAME="i18ni10n"></A>
</P><P>The source code of <TT>ejabberd</TT> supports localization.
The translators can edit the
<A HREF="http://www.gnu.org/software/gettext/">gettext</A> .po files
@ -4132,21 +4370,22 @@ HTTP header &#X2018;Accept-Language: ru&#X2019;</TD></TR>
</TABLE></DIV>
<A NAME="fig:webadmmainru"></A>
<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></DIV></BLOCKQUOTE><P> <A NAME="releasenotes"></A> </P><!--TOC chapter Release Notes-->
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc100">Appendix&#XA0;B</A>&#XA0;&#XA0;<A HREF="#releasenotes">Release Notes</A></H1><!--SEC END --><P> <A NAME="releasenotes"></A>
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc101">Appendix&#XA0;B</A>&#XA0;&#XA0;<A HREF="#releasenotes">Release Notes</A></H1><!--SEC END --><P> <A NAME="releasenotes"></A>
</P><P>Release notes are available from <A HREF="http://www.process-one.net/en/ejabberd/release_notes/">ejabberd Home Page</A></P><P> <A NAME="acknowledgements"></A> </P><!--TOC chapter Acknowledgements-->
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc101">Appendix&#XA0;C</A>&#XA0;&#XA0;<A HREF="#acknowledgements">Acknowledgements</A></H1><!--SEC END --><P> <A NAME="acknowledgements"></A> </P><P>Thanks to all people who contributed to this guide:
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc102">Appendix&#XA0;C</A>&#XA0;&#XA0;<A HREF="#acknowledgements">Acknowledgements</A></H1><!--SEC END --><P> <A NAME="acknowledgements"></A> </P><P>Thanks to all people who contributed to this guide:
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
Alexey Shchepin (<A HREF="xmpp:aleksey@jabber.ru"><TT>xmpp:aleksey@jabber.ru</TT></A>)
</LI><LI CLASS="li-itemize">Badlop (<A HREF="xmpp:badlop@jabberes.org"><TT>xmpp:badlop@jabberes.org</TT></A>)
</LI><LI CLASS="li-itemize">Evgeniy Khramtsov (<A HREF="xmpp:xram@jabber.ru"><TT>xmpp:xram@jabber.ru</TT></A>)
</LI><LI CLASS="li-itemize">Florian Zumbiehl (<A HREF="xmpp:florz@florz.de"><TT>xmpp:florz@florz.de</TT></A>)
</LI><LI CLASS="li-itemize">Marcin Owsiany (<A HREF="xmpp:marcin.owsiany@gmail.com"><TT>xmpp:marcin.owsiany@gmail.com</TT></A>)
</LI><LI CLASS="li-itemize">Michael Grigutsch (<A HREF="xmpp:migri@jabber.i-pobox.net"><TT>xmpp:migri@jabber.i-pobox.net</TT></A>)
</LI><LI CLASS="li-itemize">Mickael Remond (<A HREF="xmpp:mremond@process-one.net"><TT>xmpp:mremond@process-one.net</TT></A>)
</LI><LI CLASS="li-itemize">Sander Devrieze (<A HREF="xmpp:s.devrieze@gmail.com"><TT>xmpp:s.devrieze@gmail.com</TT></A>)
</LI><LI CLASS="li-itemize">Sergei Golovan (<A HREF="xmpp:sgolovan@nes.ru"><TT>xmpp:sgolovan@nes.ru</TT></A>)
</LI><LI CLASS="li-itemize">Vsevolod Pelipas (<A HREF="xmpp:vsevoload@jabber.ru"><TT>xmpp:vsevoload@jabber.ru</TT></A>)
</LI></UL><P> <A NAME="copyright"></A> </P><!--TOC chapter Copyright Information-->
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc102">Appendix&#XA0;D</A>&#XA0;&#XA0;<A HREF="#copyright">Copyright Information</A></H1><!--SEC END --><P> <A NAME="copyright"></A> </P><P>Ejabberd Installation and Operation Guide.<BR>
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc103">Appendix&#XA0;D</A>&#XA0;&#XA0;<A HREF="#copyright">Copyright Information</A></H1><!--SEC END --><P> <A NAME="copyright"></A> </P><P>Ejabberd Installation and Operation Guide.<BR>
Copyright &#XA9; 2003 &#X2014; 2010 ProcessOne</P><P>This document is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2

2
doc/version.tex
View File

@ -1,2 +1,2 @@
% ejabberd version (automatically generated).
\newcommand{\version}{2.1.x}
\newcommand{\version}{2.1.6}