mirror of
https://github.com/processone/ejabberd.git
synced 2024-11-22 16:20:52 +01:00
Recompile the Guide
This commit is contained in:
parent
9f6afab09c
commit
529ab22a79
@ -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.7 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.7 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">
|
||||
@ -170,7 +170,7 @@ manager.</P><!--TOC subsection Local Router-->
|
||||
name. If destination JID has a non-empty user part, then it routed to the
|
||||
session manager, else it is processed depending on it’s content.</P><!--TOC subsection Session Manager-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc6">3.3</A>  Session Manager</H3><!--SEC END --><P>This module routes packets to local users. It searches for what user resource
|
||||
packet must be sended via presence table. If this resource is connected to
|
||||
packet must be sent via presence table. If this resource is connected to
|
||||
this node, it is routed to C2S process, if it connected via another node, then
|
||||
the packet is sent to session manager on that node.</P><!--TOC subsection S2S Manager-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc7">3.4</A>  S2S Manager</H3><!--SEC END --><P>This module routes packets to other XMPP servers. First, it checks if an
|
||||
|
@ -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.7 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.7 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">
|
||||
|
312
doc/guide.html
312
doc/guide.html
@ -6,7 +6,7 @@
|
||||
|
||||
|
||||
|
||||
ejabberd 2.1.x
|
||||
ejabberd 2.1.7
|
||||
|
||||
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.7 </B></FONT></TD></TR>
|
||||
<TR><TD ALIGN=right NOWRAP> </TD></TR>
|
||||
<TR><TD ALIGN=right NOWRAP> <FONT SIZE=6>Installation and Operation Guide</FONT></TD></TR>
|
||||
</TABLE><BR>
|
||||
@ -151,76 +151,77 @@ BLOCKQUOTE.figure DIV.center DIV.center HR{display:none;}
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc49">3.3.11  <TT>mod_muc_log</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc50">3.3.12  <TT>mod_offline</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc51">3.3.13  <TT>mod_ping</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc52">3.3.14  <TT>mod_privacy</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc53">3.3.15  <TT>mod_private</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc54">3.3.16  <TT>mod_proxy65</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc55">3.3.17  <TT>mod_pubsub</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc56">3.3.18  <TT>mod_register</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc57">3.3.19  <TT>mod_register_web</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc58">3.3.20  <TT>mod_roster</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc59">3.3.21  <TT>mod_service_log</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc60">3.3.22  <TT>mod_shared_roster</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc61">3.3.23  <TT>mod_shared_roster_ldap</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc62">3.3.24  <TT>mod_sic</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc63">3.3.25  <TT>mod_stats</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc64">3.3.26  <TT>mod_time</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc65">3.3.27  <TT>mod_vcard</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc66">3.3.28  <TT>mod_vcard_ldap</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc67">3.3.29  <TT>mod_vcard_xupdate</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc68">3.3.30  <TT>mod_version</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc52">3.3.14  <TT>mod_pres_counter</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc53">3.3.15  <TT>mod_privacy</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc54">3.3.16  <TT>mod_private</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc55">3.3.17  <TT>mod_proxy65</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc56">3.3.18  <TT>mod_pubsub</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc57">3.3.19  <TT>mod_register</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc58">3.3.20  <TT>mod_register_web</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc59">3.3.21  <TT>mod_roster</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc60">3.3.22  <TT>mod_service_log</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc61">3.3.23  <TT>mod_shared_roster</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc62">3.3.24  <TT>mod_shared_roster_ldap</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc63">3.3.25  <TT>mod_sic</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc64">3.3.26  <TT>mod_stats</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc65">3.3.27  <TT>mod_time</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc66">3.3.28  <TT>mod_vcard</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc67">3.3.29  <TT>mod_vcard_ldap</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc68">3.3.30  <TT>mod_vcard_xupdate</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc69">3.3.31  <TT>mod_version</TT></A>
|
||||
</LI></UL>
|
||||
</LI></UL>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc69">Chapter 4  Managing an <TT>ejabberd</TT> Server</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc70">Chapter 4  Managing an <TT>ejabberd</TT> Server</A>
|
||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||
<A HREF="#htoc70">4.1  <TT>ejabberdctl</TT></A>
|
||||
<A HREF="#htoc71">4.1  <TT>ejabberdctl</TT></A>
|
||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||
<A HREF="#htoc71">4.1.1  ejabberdctl Commands</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc72">4.1.2  Erlang Runtime System</A>
|
||||
<A HREF="#htoc72">4.1.1  ejabberdctl Commands</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc73">4.1.2  Erlang Runtime System</A>
|
||||
</LI></UL>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc73">4.2  <TT>ejabberd</TT> Commands</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc74">4.2  <TT>ejabberd</TT> Commands</A>
|
||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||
<A HREF="#htoc74">4.2.1  List of ejabberd Commands</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc75">4.2.2  Restrict Execution with AccessCommands</A>
|
||||
<A HREF="#htoc75">4.2.1  List of ejabberd Commands</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc76">4.2.2  Restrict Execution with AccessCommands</A>
|
||||
</LI></UL>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc76">4.3  Web Admin</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc77">4.4  Ad-hoc Commands</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc78">4.5  Change Computer Hostname</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc77">4.3  Web Admin</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc78">4.4  Ad-hoc Commands</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc79">4.5  Change Computer Hostname</A>
|
||||
</LI></UL>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc79">Chapter 5  Securing <TT>ejabberd</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc80">Chapter 5  Securing <TT>ejabberd</TT></A>
|
||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||
<A HREF="#htoc80">5.1  Firewall Settings</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc81">5.2  epmd</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc82">5.3  Erlang Cookie</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc83">5.4  Erlang Node Name</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc84">5.5  Securing Sensitive Files</A>
|
||||
<A HREF="#htoc81">5.1  Firewall Settings</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc82">5.2  epmd</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc83">5.3  Erlang Cookie</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc84">5.4  Erlang Node Name</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc85">5.5  Securing Sensitive Files</A>
|
||||
</LI></UL>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc85">Chapter 6  Clustering</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc86">Chapter 6  Clustering</A>
|
||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||
<A HREF="#htoc86">6.1  How it Works</A>
|
||||
<A HREF="#htoc87">6.1  How it Works</A>
|
||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||
<A HREF="#htoc87">6.1.1  Router</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc88">6.1.2  Local Router</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc89">6.1.3  Session Manager</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc90">6.1.4  s2s Manager</A>
|
||||
<A HREF="#htoc88">6.1.1  Router</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc89">6.1.2  Local Router</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc90">6.1.3  Session Manager</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc91">6.1.4  s2s Manager</A>
|
||||
</LI></UL>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc91">6.2  Clustering Setup</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc92">6.3  Service Load-Balancing</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc92">6.2  Clustering Setup</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc93">6.3  Service Load-Balancing</A>
|
||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||
<A HREF="#htoc93">6.3.1  Components Load-Balancing</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc94">6.3.2  Domain Load-Balancing Algorithm</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc95">6.3.3  Load-Balancing Buckets</A>
|
||||
<A HREF="#htoc94">6.3.1  Components Load-Balancing</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc95">6.3.2  Domain Load-Balancing Algorithm</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc96">6.3.3  Load-Balancing Buckets</A>
|
||||
</LI></UL>
|
||||
</LI></UL>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc96">Chapter 7  Debugging</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc97">Chapter 7  Debugging</A>
|
||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||
<A HREF="#htoc97">7.1  Log Files</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc98">7.2  Debug Console</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc99">7.3  Watchdog Alerts</A>
|
||||
<A HREF="#htoc98">7.1  Log Files</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc99">7.2  Debug Console</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc100">7.3  Watchdog Alerts</A>
|
||||
</LI></UL>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc100">Appendix A  Internationalization and Localization</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc101">Appendix B  Release Notes</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc102">Appendix C  Acknowledgements</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc103">Appendix D  Copyright Information</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc101">Appendix A  Internationalization and Localization</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc102">Appendix B  Release Notes</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc103">Appendix C  Acknowledgements</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc104">Appendix D  Copyright Information</A>
|
||||
</LI></UL><!--TOC chapter Introduction-->
|
||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc1">Chapter 1</A>  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-->
|
||||
@ -521,7 +522,7 @@ There are two ways to register a XMPP account:
|
||||
<OL CLASS="enumerate" type=a><LI CLASS="li-enumerate">
|
||||
Using <TT>ejabberdctl</TT> (see section <A HREF="#ejabberdctl">4.1</A>):
|
||||
<PRE CLASS="verbatim">ejabberdctl register admin1 example.org FgT5bk3
|
||||
</PRE></LI><LI CLASS="li-enumerate">Using a XMPP client and In-Band Registration (see section <A HREF="#modregister">3.3.18</A>).
|
||||
</PRE></LI><LI CLASS="li-enumerate">Using a XMPP client and In-Band Registration (see section <A HREF="#modregister">3.3.19</A>).
|
||||
</LI></OL>
|
||||
</LI><LI CLASS="li-enumerate">Edit the <TT>ejabberd</TT> configuration file to give administration rights to the XMPP account you created:
|
||||
<PRE CLASS="verbatim">{acl, admins, {user, "admin1", "example.org"}}.
|
||||
@ -881,7 +882,7 @@ and also allows plain connections for old clients.
|
||||
</LI><LI CLASS="li-itemize">Port 5269 listens for s2s connections with STARTTLS. The socket is set for IPv6 instead of IPv4.
|
||||
</LI><LI CLASS="li-itemize">Port 3478 listens for STUN requests over UDP.
|
||||
</LI><LI CLASS="li-itemize">Port 5280 listens for HTTP requests, and serves the HTTP Poll service.
|
||||
</LI><LI CLASS="li-itemize">Port 5281 listens for HTTP requests, and serves the Web Admin using HTTPS as explained in
|
||||
</LI><LI CLASS="li-itemize">Port 5281 listens for HTTP requests, using HTTPS to serve HTTP-Bind (BOSH) and the Web Admin as explained in
|
||||
section <A HREF="#webadmin">4.3</A>. The socket only listens connections to the IP address 127.0.0.1.
|
||||
</LI></UL><PRE CLASS="verbatim">{hosts, ["example.com", "example.org", "example.net"]}.
|
||||
{listen,
|
||||
@ -908,6 +909,7 @@ section <A HREF="#webadmin">4.3</A>. The socket only listens connections to
|
||||
]},
|
||||
{{5281, "127.0.0.1"}, ejabberd_http, [
|
||||
web_admin,
|
||||
http_bind,
|
||||
tls, {certfile, "/etc/ejabberd/server.pem"},
|
||||
]}
|
||||
]
|
||||
@ -1218,7 +1220,7 @@ matches <TT>Regexp</TT>. Example:
|
||||
</PRE></DD><DT CLASS="dt-description"><B><TT>{node_regexp, UserRegexp, ServerRegexp}</TT></B></DT><DD CLASS="dd-description"> Matches any user
|
||||
with a name that matches <TT>UserRegexp</TT> at any server that matches
|
||||
<TT>ServerRegexp</TT>. Example:
|
||||
<PRE CLASS="verbatim">{acl, yohzik, {node_regexp, "^yohzik$", "^example.(com|org)$"}}.
|
||||
<PRE CLASS="verbatim">{acl, yozhik, {node_regexp, "^yozhik$", "^example.(com|org)$"}}.
|
||||
</PRE></DD><DT CLASS="dt-description"><B><TT>{user_glob, Glob}</TT></B></DT><DD CLASS="dd-description">
|
||||
</DD><DT CLASS="dt-description"><B><TT>{user_glob, Glob, Server}</TT></B></DT><DD CLASS="dd-description">
|
||||
</DD><DT CLASS="dt-description"><B><TT>{server_glob, Glob}</TT></B></DT><DD CLASS="dd-description">
|
||||
@ -1316,17 +1318,22 @@ using ImageMagick’s Convert program.</P><P>The configurable options are:
|
||||
<B><TT>{captcha_cmd, Path}</TT></B></DT><DD CLASS="dd-description">
|
||||
Full path to a script that generates the image.
|
||||
The default value is an empty string: <TT>""</TT>
|
||||
</DD><DT CLASS="dt-description"><B><TT>{captcha_host, Host}</TT></B></DT><DD CLASS="dd-description">
|
||||
Host part of the URL sent to the user.
|
||||
You can include the port number.
|
||||
The URL sent to the user is formed by: <TT>http://Host/captcha/</TT>
|
||||
The default value is the first hostname configured.
|
||||
</DD><DT CLASS="dt-description"><B><TT>{captcha_host, ProtocolHostPort}</TT></B></DT><DD CLASS="dd-description">
|
||||
ProtocolHostPort is a string with the host, and optionally the Protocol and Port number.
|
||||
It must identify where ejabberd listens for CAPTCHA requests.
|
||||
The URL sent to the user is formed by: <TT>Protocol://Host:Port/captcha/</TT>
|
||||
The default value is: protocol <TT>http</TT>, the first hostname configured, and port <TT>80</TT>.
|
||||
If you specify a port number that does not match exactly an ejabberd listener
|
||||
(because you are using a reverse proxy or other port-forwarding tool),
|
||||
then you must specify the transfer protocol, as seen in the example below.
|
||||
</DD></DL><P>Additionally, an <TT>ejabberd_http</TT> listener must be enabled with the <TT>captcha</TT> option.
|
||||
See section <A HREF="#listened-module">3.1.3</A>.</P><P>Example configuration:
|
||||
</P><PRE CLASS="verbatim">{hosts, ["example.org"]}.
|
||||
|
||||
{captcha_cmd, "/lib/ejabberd/priv/bin/captcha.sh"}.
|
||||
{captcha_host, "example.org:5280"}.
|
||||
%% {captcha_host, "https://example.org:443"}.
|
||||
%% {captcha_host, "http://example.com"}.
|
||||
|
||||
{listen,
|
||||
[
|
||||
@ -1464,6 +1471,7 @@ different storage systems for modules, and so forth.</P><P>The following databas
|
||||
<A HREF="http://www.microsoft.com/activedirectory/">Active Directory</A>
|
||||
(see section <A HREF="#ad">3.2.5</A>)
|
||||
</LI><LI CLASS="li-itemize"><A HREF="http://www.openldap.org/">OpenLDAP</A>
|
||||
</LI><LI CLASS="li-itemize"><A HREF="http://www.communigate.com/">CommuniGate Pro</A>
|
||||
</LI><LI CLASS="li-itemize">Normally any LDAP compatible server should work; inform us about your
|
||||
success with a not-listed server so that we can list it here.
|
||||
</LI></UL><P>Important note about virtual hosting:
|
||||
@ -1908,6 +1916,7 @@ all entries end with a comma:
|
||||
<TABLE BORDER=1 CELLSPACING=0 CELLPADDING=1><TR><TD ALIGN=left NOWRAP><B>Module</B></TD><TD ALIGN=left NOWRAP><B>Feature</B></TD><TD ALIGN=left NOWRAP><B>Dependencies</B></TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><TT>mod_adhoc</TT></TD><TD ALIGN=left NOWRAP>Ad-Hoc Commands (<A HREF="http://xmpp.org/extensions/xep-0050.html">XEP-0050</A>)</TD><TD ALIGN=left NOWRAP> </TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#modannounce"><TT>mod_announce</TT></A></TD><TD ALIGN=left NOWRAP>Manage announcements</TD><TD ALIGN=left NOWRAP>recommends <TT>mod_adhoc</TT></TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><TT>mod_blocking</TT></TD><TD ALIGN=left NOWRAP>Simple Communications Blocking (<A HREF="http://xmpp.org/extensions/xep-0191.html">XEP-0191</A>)</TD><TD ALIGN=left NOWRAP><TT>mod_privacy</TT></TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><TT>mod_caps</TT></TD><TD ALIGN=left NOWRAP>Entity Capabilities (<A HREF="http://xmpp.org/extensions/xep-0115.html">XEP-0115</A>)</TD><TD ALIGN=left NOWRAP> </TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><TT>mod_configure</TT></TD><TD ALIGN=left NOWRAP>Server configuration using Ad-Hoc</TD><TD ALIGN=left NOWRAP><TT>mod_adhoc</TT></TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#moddisco"><TT>mod_disco</TT></A></TD><TD ALIGN=left NOWRAP>Service Discovery (<A HREF="http://xmpp.org/extensions/xep-0030.html">XEP-0030</A>)</TD><TD ALIGN=left NOWRAP> </TD></TR>
|
||||
@ -1922,8 +1931,9 @@ all entries end with a comma:
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#modoffline"><TT>mod_offline</TT></A></TD><TD ALIGN=left NOWRAP>Offline message storage (<A HREF="http://xmpp.org/extensions/xep-0160.html">XEP-0160</A>)</TD><TD ALIGN=left NOWRAP> </TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#modoffline"><TT>mod_offline_odbc</TT></A></TD><TD ALIGN=left NOWRAP>Offline message storage (<A HREF="http://xmpp.org/extensions/xep-0160.html">XEP-0160</A>)</TD><TD ALIGN=left NOWRAP>supported DB (*)</TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#modping"><TT>mod_ping</TT></A></TD><TD ALIGN=left NOWRAP>XMPP Ping and periodic keepalives (<A HREF="http://xmpp.org/extensions/xep-0199.html">XEP-0199</A>)</TD><TD ALIGN=left NOWRAP> </TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#modprivacy"><TT>mod_privacy</TT></A></TD><TD ALIGN=left NOWRAP>Blocking Communication (XMPP IM)</TD><TD ALIGN=left NOWRAP> </TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#modprivacy"><TT>mod_privacy_odbc</TT></A></TD><TD ALIGN=left NOWRAP>Blocking Communication (XMPP IM)</TD><TD ALIGN=left NOWRAP>supported DB (*)</TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#modprescounter"><TT>mod_privacy</TT></A></TD><TD ALIGN=left NOWRAP>Detect presence subscription flood</TD><TD ALIGN=left NOWRAP> </TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#modprivacy"><TT>mod_privacy</TT></A></TD><TD ALIGN=left NOWRAP>Blocking Communication (<A HREF="http://xmpp.org/extensions/xep-0016.html">XEP-0016</A>)</TD><TD ALIGN=left NOWRAP> </TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#modprivacy"><TT>mod_privacy_odbc</TT></A></TD><TD ALIGN=left NOWRAP>Blocking Communication (<A HREF="http://xmpp.org/extensions/xep-0016.html">XEP-0016</A>)</TD><TD ALIGN=left NOWRAP>supported DB (*)</TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#modprivate"><TT>mod_private</TT></A></TD><TD ALIGN=left NOWRAP>Private XML Storage (<A HREF="http://xmpp.org/extensions/xep-0049.html">XEP-0049</A>)</TD><TD ALIGN=left NOWRAP> </TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#modprivate"><TT>mod_private_odbc</TT></A></TD><TD ALIGN=left NOWRAP>Private XML Storage (<A HREF="http://xmpp.org/extensions/xep-0049.html">XEP-0049</A>)</TD><TD ALIGN=left NOWRAP>supported DB (*)</TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#modproxy"><TT>mod_proxy65</TT></A></TD><TD ALIGN=left NOWRAP>SOCKS5 Bytestreams (<A HREF="http://xmpp.org/extensions/xep-0065.html">XEP-0065</A>)</TD><TD ALIGN=left NOWRAP> </TD></TR>
|
||||
@ -1985,7 +1995,8 @@ these queries.</P><P>The syntax is:
|
||||
</P><DL CLASS="description"><DT CLASS="dt-description"><B><TT>{iqdisc, Value}</TT></B></DT></DL><P>Possible <TT>Value</TT> are:
|
||||
</P><DL CLASS="description"><DT CLASS="dt-description">
|
||||
<B><TT>no_queue</TT></B></DT><DD CLASS="dd-description"> All queries of a namespace with this processing discipline are
|
||||
processed immediately. This also means that no other packets can be processed
|
||||
processed directly. This means that the XMPP connection that sends this IQ query gets blocked:
|
||||
no other packets can be processed
|
||||
until this one has been completely processed. Hence this discipline is not
|
||||
recommended if the processing of a query can take a relatively long time.
|
||||
</DD><DT CLASS="dt-description"><B><TT>one_queue</TT></B></DT><DD CLASS="dd-description"> In this case a separate queue is created for the processing
|
||||
@ -1993,7 +2004,7 @@ of IQ queries of a namespace with this discipline. In addition, the processing
|
||||
of this queue is done in parallel with that of other packets. This discipline
|
||||
is most recommended.
|
||||
</DD><DT CLASS="dt-description"><B><TT>{queues, N}</TT></B></DT><DD CLASS="dd-description"> N separate queues are created to process the
|
||||
queries. The queries are thus process in parallel, but in a
|
||||
queries. The queries are thus processed in parallel, but in a
|
||||
controlled way.
|
||||
</DD><DT CLASS="dt-description"><B><TT>parallel</TT></B></DT><DD CLASS="dd-description"> For every packet with this discipline a separate Erlang process
|
||||
is spawned. Consequently, all these packets are processed in parallel.
|
||||
@ -2327,7 +2338,7 @@ to the IRC transport instead of the Multi-User Chat service.
|
||||
to join a channel, and to set custom IRC username and encoding.
|
||||
</LI><LI CLASS="li-itemize">When using a popular XMPP server, it can occur that no
|
||||
connection can be achieved with some IRC servers because they limit the
|
||||
number of conections from one IP.
|
||||
number of connections from one IP.
|
||||
</LI></UL><P>Options:
|
||||
</P><DL CLASS="description"><DT CLASS="dt-description">
|
||||
|
||||
@ -2782,8 +2793,33 @@ and if a client does not answer to the ping in less than 32 seconds, its connect
|
||||
{mod_ping, [{send_pings, true}, {ping_interval, 240}, {timeout_action, kill}]},
|
||||
...
|
||||
]}.
|
||||
</PRE><P> <A NAME="modprescounter"></A> </P><!--TOC subsection <TT>mod_pres_counter</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc52">3.3.14</A>  <A HREF="#modprescounter"><TT>mod_pres_counter</TT></A></H3><!--SEC END --><P> <A NAME="modprescounter"></A>
|
||||
</P><P>This module detects flood/spam in presence subscription stanza traffic.
|
||||
If a user sends or receives more of those stanzas in a time interval,
|
||||
the exceeding stanzas are silently dropped, and warning is logged.</P><P>Configuration options:
|
||||
</P><DL CLASS="description"><DT CLASS="dt-description">
|
||||
<B><TT>{count, StanzaNumber}</TT></B></DT><DD CLASS="dd-description">
|
||||
The number of subscription presence stanzas
|
||||
(subscribe, unsubscribe, subscribed, unsubscribed)
|
||||
allowed for any direction (input or output)
|
||||
per time interval.
|
||||
Please note that two users subscribing to each other usually generate
|
||||
4 stanzas, so the recommended value is 4 or more.
|
||||
The default value is: 5.
|
||||
</DD><DT CLASS="dt-description"><B><TT>{interval, Seconds}</TT></B></DT><DD CLASS="dd-description">
|
||||
The time interval defined in seconds.
|
||||
The default value is 60.
|
||||
</DD></DL><P>This example enables the module, and allows up to 5 presence subscription stanzas
|
||||
to be sent or received by the users in 60 seconds:
|
||||
</P><PRE CLASS="verbatim">{modules,
|
||||
[
|
||||
...
|
||||
{mod_pres_counter, [{count, 5}, {interval, 60}]},
|
||||
...
|
||||
]}.
|
||||
</PRE><P> <A NAME="modprivacy"></A> </P><!--TOC subsection <TT>mod_privacy</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc52">3.3.14</A>  <A HREF="#modprivacy"><TT>mod_privacy</TT></A></H3><!--SEC END --><P> <A NAME="modprivacy"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc53">3.3.15</A>  <A HREF="#modprivacy"><TT>mod_privacy</TT></A></H3><!--SEC END --><P> <A NAME="modprivacy"></A>
|
||||
</P><P>This module implements Blocking Communication (also known as Privacy Rules)
|
||||
as defined in section 10 from XMPP IM. If end users have support for it in
|
||||
their XMPP client, they will be able to:
|
||||
@ -2811,7 +2847,7 @@ subscription type (or globally).
|
||||
<B><TT>{iqdisc, Discipline}</TT></B></DT><DD CLASS="dd-description"> This specifies
|
||||
the processing discipline for Blocking Communication (<TT>jabber:iq:privacy</TT>) IQ queries (see section <A HREF="#modiqdiscoption">3.3.2</A>).
|
||||
</DD></DL><P> <A NAME="modprivate"></A> </P><!--TOC subsection <TT>mod_private</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc53">3.3.15</A>  <A HREF="#modprivate"><TT>mod_private</TT></A></H3><!--SEC END --><P> <A NAME="modprivate"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc54">3.3.16</A>  <A HREF="#modprivate"><TT>mod_private</TT></A></H3><!--SEC END --><P> <A NAME="modprivate"></A>
|
||||
</P><P>This module adds support for Private XML Storage (<A HREF="http://xmpp.org/extensions/xep-0049.html">XEP-0049</A>):
|
||||
</P><BLOCKQUOTE CLASS="quote">
|
||||
Using this method, XMPP entities can store private data on the server and
|
||||
@ -2823,7 +2859,7 @@ of client-specific preferences; another is Bookmark Storage (<A HREF="http://xmp
|
||||
<B><TT>{iqdisc, Discipline}</TT></B></DT><DD CLASS="dd-description"> This specifies
|
||||
the processing discipline for Private XML Storage (<TT>jabber:iq:private</TT>) IQ queries (see section <A HREF="#modiqdiscoption">3.3.2</A>).
|
||||
</DD></DL><P> <A NAME="modproxy"></A> </P><!--TOC subsection <TT>mod_proxy65</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc54">3.3.16</A>  <A HREF="#modproxy"><TT>mod_proxy65</TT></A></H3><!--SEC END --><P> <A NAME="modproxy"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc55">3.3.17</A>  <A HREF="#modproxy"><TT>mod_proxy65</TT></A></H3><!--SEC END --><P> <A NAME="modproxy"></A>
|
||||
</P><P>This module implements SOCKS5 Bytestreams (<A HREF="http://xmpp.org/extensions/xep-0065.html">XEP-0065</A>).
|
||||
It allows <TT>ejabberd</TT> to act as a file transfer proxy between two
|
||||
XMPP clients.</P><P>Options:
|
||||
@ -2887,7 +2923,7 @@ The simpliest configuration of the module:
|
||||
...
|
||||
]}.
|
||||
</PRE></LI></UL><P> <A NAME="modpubsub"></A> </P><!--TOC subsection <TT>mod_pubsub</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc55">3.3.17</A>  <A HREF="#modpubsub"><TT>mod_pubsub</TT></A></H3><!--SEC END --><P> <A NAME="modpubsub"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc56">3.3.18</A>  <A HREF="#modpubsub"><TT>mod_pubsub</TT></A></H3><!--SEC END --><P> <A NAME="modpubsub"></A>
|
||||
</P><P>This module offers a Publish-Subscribe Service (<A HREF="http://xmpp.org/extensions/xep-0060.html">XEP-0060</A>).
|
||||
The functionality in <TT>mod_pubsub</TT> can be extended using plugins.
|
||||
The plugin that implements PEP (Personal Eventing via Pubsub) (<A HREF="http://xmpp.org/extensions/xep-0163.html">XEP-0163</A>)
|
||||
@ -2965,7 +3001,7 @@ with ODBC usage:
|
||||
...
|
||||
]}.
|
||||
</PRE><P> <A NAME="modregister"></A> </P><!--TOC subsection <TT>mod_register</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc56">3.3.18</A>  <A HREF="#modregister"><TT>mod_register</TT></A></H3><!--SEC END --><P> <A NAME="modregister"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc57">3.3.19</A>  <A HREF="#modregister"><TT>mod_register</TT></A></H3><!--SEC END --><P> <A NAME="modregister"></A>
|
||||
</P><P>This module adds support for In-Band Registration (<A HREF="http://xmpp.org/extensions/xep-0077.html">XEP-0077</A>). This protocol
|
||||
enables end users to use a XMPP client to:
|
||||
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
|
||||
@ -2974,10 +3010,11 @@ Register a new account on the server.
|
||||
</LI><LI CLASS="li-itemize">Delete an existing account on the server.
|
||||
</LI></UL><P>Options:
|
||||
</P><DL CLASS="description"><DT CLASS="dt-description">
|
||||
<B><TT>{access, AccessName}</TT></B></DT><DD CLASS="dd-description"> This option can be configured to specify
|
||||
rules to restrict registration. If a rule returns ‘deny’ on the requested
|
||||
user name, registration for that user name is denied. (there are no
|
||||
restrictions by default).
|
||||
<B><TT>{access, AccessName}</TT></B></DT><DD CLASS="dd-description">
|
||||
Specify rules to restrict what usernames can be registered and unregistered.
|
||||
If a rule returns ‘deny’ on the requested username,
|
||||
registration and unregistration of that user name is denied.
|
||||
There are no restrictions by default.
|
||||
</DD><DT CLASS="dt-description"><B><TT>{access_from, AccessName}</TT></B></DT><DD CLASS="dd-description"> By default, <TT>ejabberd</TT>
|
||||
doesn’t allow to register new accounts from s2s or existing c2s sessions. You can
|
||||
change it by defining access rule in this option. Use with care: allowing registration
|
||||
@ -3066,7 +3103,7 @@ Also define a registration timeout of one hour:
|
||||
...
|
||||
]}.
|
||||
</PRE></LI></UL><P> <A NAME="modregisterweb"></A> </P><!--TOC subsection <TT>mod_register_web</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc57">3.3.19</A>  <A HREF="#modregisterweb"><TT>mod_register_web</TT></A></H3><!--SEC END --><P> <A NAME="modregisterweb"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc58">3.3.20</A>  <A HREF="#modregisterweb"><TT>mod_register_web</TT></A></H3><!--SEC END --><P> <A NAME="modregisterweb"></A>
|
||||
</P><P>This module provides a web page where people can:
|
||||
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
|
||||
Register a new account on the server.
|
||||
@ -3097,7 +3134,7 @@ list of JIDs which will be notified each time a new account is registered.
|
||||
</PRE><P>The users can visit this page: https://localhost:5281/register/
|
||||
It is important to include the last / character in the URL,
|
||||
otherwise the subpages URL will be incorrect.</P><P> <A NAME="modroster"></A> </P><!--TOC subsection <TT>mod_roster</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc58">3.3.20</A>  <A HREF="#modroster"><TT>mod_roster</TT></A></H3><!--SEC END --><P> <A NAME="modroster"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc59">3.3.21</A>  <A HREF="#modroster"><TT>mod_roster</TT></A></H3><!--SEC END --><P> <A NAME="modroster"></A>
|
||||
</P><P>This module implements roster management as defined in
|
||||
<A HREF="http://xmpp.org/rfcs/rfc3921.html#roster">RFC 3921: XMPP IM</A>.
|
||||
It also supports Roster Versioning (<A HREF="http://xmpp.org/extensions/xep-0237.html">XEP-0237</A>).</P><P>Options:
|
||||
@ -3124,7 +3161,7 @@ you must disable this option.
|
||||
...
|
||||
]}.
|
||||
</PRE><P> <A NAME="modservicelog"></A> </P><!--TOC subsection <TT>mod_service_log</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc59">3.3.21</A>  <A HREF="#modservicelog"><TT>mod_service_log</TT></A></H3><!--SEC END --><P> <A NAME="modservicelog"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc60">3.3.22</A>  <A HREF="#modservicelog"><TT>mod_service_log</TT></A></H3><!--SEC END --><P> <A NAME="modservicelog"></A>
|
||||
</P><P>This module adds support for logging end user packets via a XMPP message
|
||||
auditing service such as
|
||||
<A HREF="http://www.funkypenguin.info/project/bandersnatch/">Bandersnatch</A>. All user
|
||||
@ -3154,7 +3191,7 @@ To log all end user packets to the Bandersnatch service running on
|
||||
...
|
||||
]}.
|
||||
</PRE></LI></UL><P> <A NAME="modsharedroster"></A> </P><!--TOC subsection <TT>mod_shared_roster</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc60">3.3.22</A>  <A HREF="#modsharedroster"><TT>mod_shared_roster</TT></A></H3><!--SEC END --><P> <A NAME="modsharedroster"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc61">3.3.23</A>  <A HREF="#modsharedroster"><TT>mod_shared_roster</TT></A></H3><!--SEC END --><P> <A NAME="modsharedroster"></A>
|
||||
</P><P>This module enables you to create shared roster groups. This means that you can
|
||||
create groups of people that can see members from (other) groups in their
|
||||
rosters. The big advantages of this feature are that end users do not need to
|
||||
@ -3168,11 +3205,13 @@ has a unique identification and the following parameters:
|
||||
<B>Name</B></DT><DD CLASS="dd-description"> The name of the group, which will be displayed in the roster.
|
||||
</DD><DT CLASS="dt-description"><B>Description</B></DT><DD CLASS="dd-description"> The description of the group. This parameter does not affect
|
||||
anything.
|
||||
</DD><DT CLASS="dt-description"><B>Members</B></DT><DD CLASS="dd-description"> A list of full JIDs of group members, entered one per line in
|
||||
</DD><DT CLASS="dt-description"><B>Members</B></DT><DD CLASS="dd-description"> A list of JIDs of group members, entered one per line in
|
||||
the Web Admin.
|
||||
To put as members all the registered users in the virtual hosts,
|
||||
you can use the special directive: @all@.
|
||||
Note that this directive is designed for a small server with just a few hundred users.
|
||||
The special member directive <TT>@all@</TT>
|
||||
represents all the registered users in the virtual host;
|
||||
which is only recommended for a small server with just a few hundred users.
|
||||
The special member directive <TT>@online@</TT>
|
||||
represents the online users in the virtual host.
|
||||
</DD><DT CLASS="dt-description"><B>Displayed groups</B></DT><DD CLASS="dd-description"> A list of groups that will be in the rosters of this
|
||||
group’s members.
|
||||
</DD></DL><P>Examples:
|
||||
@ -3229,7 +3268,7 @@ roster groups as shown in the following table:
|
||||
</TABLE>
|
||||
<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></DIV></BLOCKQUOTE>
|
||||
</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>  <A HREF="#modsharedrosterldap"><TT>mod_shared_roster_ldap</TT></A></H3><!--SEC END --><P> <A NAME="modsharedrosterldap"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc62">3.3.24</A>  <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’ 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-->
|
||||
@ -3277,7 +3316,7 @@ filter="(&(?=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 <A HREF="#msrlfilters">3.3.23</A>.</P><DL CLASS="description"><DT CLASS="dt-description">
|
||||
section <A HREF="#msrlfilters">3.3.24</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 “Roster Filter” and “Group Filter”.
|
||||
@ -3309,7 +3348,7 @@ A globbing format for extracting user ID from the value of the attribute named b
|
||||
<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 — see section <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">
|
||||
and Group Filters manually — see section <A HREF="#msrlfilters">3.3.24</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">
|
||||
@ -3326,17 +3365,17 @@ the option is unset,
|
||||
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 “User/Group Filter” —
|
||||
see section <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">
|
||||
see section <A HREF="#msrlfilters">3.3.24</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 <A HREF="#msrlconfigroster">3.3.23</A> form more information. Set to <TT>off</TT> if you
|
||||
section <A HREF="#msrlconfigroster">3.3.24</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 <A HREF="#msrlconfigroster">3.3.23</A> on
|
||||
fresh after retrieval. 300 by default. See section <A HREF="#msrlconfigroster">3.3.24</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 <A HREF="#msrlconfigroster">3.3.23</A> on
|
||||
fresh after retrieval. 300 by default. See section <A HREF="#msrlconfigroster">3.3.24</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
|
||||
@ -3446,14 +3485,14 @@ the roster shown in figure <A HREF="#fig:msrl-roster-deep">3.4</A>.</P><BLO
|
||||
</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>  <A HREF="#modsic"><TT>mod_sic</TT></A></H3><!--SEC END --><P> <A NAME="modsic"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc63">3.3.25</A>  <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 <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="htoc63">3.3.25</A>  <A HREF="#modstats"><TT>mod_stats</TT></A></H3><!--SEC END --><P> <A NAME="modstats"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc64">3.3.26</A>  <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">
|
||||
@ -3485,14 +3524,14 @@ by sending:
|
||||
</query>
|
||||
</iq>
|
||||
</PRE></LI></UL><P> <A NAME="modtime"></A> </P><!--TOC subsection <TT>mod_time</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc64">3.3.26</A>  <A HREF="#modtime"><TT>mod_time</TT></A></H3><!--SEC END --><P> <A NAME="modtime"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc65">3.3.27</A>  <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’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 <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="htoc65">3.3.27</A>  <A HREF="#modvcard"><TT>mod_vcard</TT></A></H3><!--SEC END --><P> <A NAME="modvcard"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc66">3.3.28</A>  <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
|
||||
@ -3547,7 +3586,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="htoc66">3.3.28</A>  <A HREF="#modvcardldap"><TT>mod_vcard_ldap</TT></A></H3><!--SEC END --><P> <A NAME="modvcardldap"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc67">3.3.29</A>  <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 <A HREF="#ldapauth">3.2.5</A>).</P><P>Usually <TT>ejabberd</TT> treats LDAP as a read-only storage:
|
||||
@ -3729,7 +3768,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="htoc67">3.3.29</A>  <A HREF="#modvcardxupdate"><TT>mod_vcard_xupdate</TT></A></H3><!--SEC END --><P> <A NAME="modvcardxupdate"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc68">3.3.30</A>  <A HREF="#modvcardxupdate"><TT>mod_vcard_xupdate</TT></A></H3><!--SEC END --><P> <A NAME="modvcardxupdate"></A>
|
||||
</P><P>The user’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.
|
||||
@ -3743,7 +3782,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="htoc68">3.3.30</A>  <A HREF="#modversion"><TT>mod_version</TT></A></H3><!--SEC END --><P> <A NAME="modversion"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc69">3.3.31</A>  <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>’s version when queried.</P><P>Options:
|
||||
</P><DL CLASS="description"><DT CLASS="dt-description">
|
||||
@ -3752,8 +3791,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 <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="htoc69">Chapter 4</A>  <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>  <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="htoc70">Chapter 4</A>  <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="htoc71">4.1</A>  <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
|
||||
@ -3765,7 +3804,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="htoc71">4.1.1</A>  <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="htoc72">4.1.1</A>  <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’t an <TT>ejabberd</TT> server running,
|
||||
the available parameters are:
|
||||
</P><DL CLASS="description"><DT CLASS="dt-description">
|
||||
@ -3801,7 +3840,7 @@ robot1
|
||||
testuser1
|
||||
testuser2
|
||||
</PRE><P> <A NAME="erlangconfiguration"></A> </P><!--TOC subsection Erlang Runtime System-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc72">4.1.2</A>  <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="htoc73">4.1.2</A>  <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>,
|
||||
@ -3847,6 +3886,9 @@ This is only useful if you plan to setup an <TT>ejabberd</TT> cluster with nodes
|
||||
If using <TT>-sname</TT>, specify either this option or <TT>ERL_INETRC</TT>.
|
||||
</DD><DT CLASS="dt-description"><B><TT>-kernel inet_dist_listen_min 4200 inet_dist_listen_min 4210</TT></B></DT><DD CLASS="dd-description">
|
||||
Define the first and last ports that <TT>epmd</TT> (section <A HREF="#epmd">5.2</A>) can listen to.
|
||||
</DD><DT CLASS="dt-description"><B><TT>-kernel inet_dist_use_interface "{ 127,0,0,1 }"</TT></B></DT><DD CLASS="dd-description">
|
||||
Define the IP address where this Erlang node listens for other nodes
|
||||
connections (see section <A HREF="#epmd">5.2</A>).
|
||||
</DD><DT CLASS="dt-description"><B><TT>-detached</TT></B></DT><DD CLASS="dd-description">
|
||||
Starts the Erlang system detached from the system console.
|
||||
Useful for running daemons and backgrounds processes.
|
||||
@ -3878,7 +3920,7 @@ not “Simple Authentication and Security Layer”.
|
||||
</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="htoc73">4.2</A>  <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="htoc74">4.2</A>  <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>.
|
||||
@ -3886,7 +3928,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="htoc74">4.2.1</A>  <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="htoc75">4.2.1</A>  <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
|
||||
@ -3938,7 +3980,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="htoc75">4.2.2</A>  <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="htoc76">4.2.2</A>  <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:
|
||||
@ -3983,7 +4025,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="htoc76">4.3</A>  <A HREF="#webadmin">Web Admin</A></H2><!--SEC END --><P> <A NAME="webadmin"></A>
|
||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc77">4.3</A>  <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 <A HREF="#listened">3.1.3</A>) is included in the listening ports. Then you can open
|
||||
@ -4060,13 +4102,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="htoc77">4.4</A>  <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="htoc78">4.4</A>  <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="htoc78">4.5</A>  <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="htoc79">4.5</A>  <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.
|
||||
@ -4112,8 +4154,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="htoc79">Chapter 5</A>  <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>  <A HREF="#firewall">Firewall Settings</A></H2><!--SEC END --><P> <A NAME="firewall"></A>
|
||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc80">Chapter 5</A>  <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="htoc81">5.1</A>  <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>
|
||||
@ -4124,7 +4166,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="htoc81">5.2</A>  <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="htoc82">5.2</A>  <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.
|
||||
@ -4148,8 +4190,12 @@ The ports used in this case by default are random,
|
||||
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>It is also possible to configure in <TT>ejabberdctl.cfg</TT>
|
||||
the network interface where the Erlang node will listen and accept connections.
|
||||
The Erlang command-line parameter used internally is, for example:
|
||||
</P><PRE CLASS="verbatim">erl ... -kernel inet_dist_use_interface "{127,0,0,1}"
|
||||
</PRE><P> <A NAME="cookie"></A> </P><!--TOC section Erlang Cookie-->
|
||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc82">5.3</A>  <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="htoc83">5.3</A>  <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.
|
||||
@ -4163,7 +4209,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="htoc83">5.4</A>  <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="htoc84">5.4</A>  <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
|
||||
@ -4172,7 +4218,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="htoc84">5.5</A>  <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="htoc85">5.5</A>  <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">
|
||||
@ -4192,9 +4238,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="htoc85">Chapter 6</A>  <A HREF="#clustering">Clustering</A></H1><!--SEC END --><P> <A NAME="clustering"></A>
|
||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc86">Chapter 6</A>  <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="htoc86">6.1</A>  <A HREF="#howitworks">How it Works</A></H2><!--SEC END --><P> <A NAME="howitworks"></A>
|
||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc87">6.1</A>  <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
|
||||
@ -4208,29 +4254,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="htoc87">6.1.1</A>  <A HREF="#router">Router</A></H3><!--SEC END --><P> <A NAME="router"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc88">6.1.1</A>  <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’s domains. It uses a global
|
||||
routing table. The domain of the packet’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="htoc88">6.1.2</A>  <A HREF="#localrouter">Local Router</A></H3><!--SEC END --><P> <A NAME="localrouter"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc89">6.1.2</A>  <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’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="htoc89">6.1.3</A>  <A HREF="#sessionmanager">Session Manager</A></H3><!--SEC END --><P> <A NAME="sessionmanager"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc90">6.1.3</A>  <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="htoc90">6.1.4</A>  <A HREF="#s2smanager">s2s Manager</A></H3><!--SEC END --><P> <A NAME="s2smanager"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc91">6.1.4</A>  <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’s
|
||||
source to the domain of the packet’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="htoc91">6.2</A>  <A HREF="#cluster">Clustering Setup</A></H2><!--SEC END --><P> <A NAME="cluster"></A>
|
||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc92">6.2</A>  <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">
|
||||
@ -4268,10 +4314,10 @@ and ‘<CODE>access</CODE>’ 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="htoc92">6.3</A>  <A HREF="#servicelb">Service Load-Balancing</A></H2><!--SEC END --><P> <A NAME="servicelb"></A>
|
||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc93">6.3</A>  <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="htoc93">6.3.1</A>  <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>  <A HREF="#domainlb">Domain Load-Balancing Algorithm</A></H3><!--SEC END --><P> <A NAME="domainlb"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc94">6.3.1</A>  <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="htoc95">6.3.2</A>  <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">
|
||||
@ -4280,12 +4326,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="htoc95">6.3.3</A>  <A HREF="#lbbuckets">Load-Balancing Buckets</A></H3><!--SEC END --><P> <A NAME="lbbuckets"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc96">6.3.3</A>  <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="htoc96">Chapter 7</A>  <A HREF="#debugging">Debugging</A></H1><!--SEC END --><P> <A NAME="debugging"></A>
|
||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc97">Chapter 7</A>  <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="htoc97">7.1</A>  <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="htoc98">7.1</A>  <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)
|
||||
@ -4310,12 +4356,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’t rename them.</P><P> <A NAME="debugconsole"></A> </P><!--TOC section Debug Console-->
|
||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc98">7.2</A>  <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="htoc99">7.2</A>  <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="htoc99">7.3</A>  <A HREF="#watchdog">Watchdog Alerts</A></H2><!--SEC END --><P> <A NAME="watchdog"></A>
|
||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc100">7.3</A>  <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,
|
||||
@ -4335,7 +4381,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="htoc100">Appendix A</A>  <A HREF="#i18ni10n">Internationalization and Localization</A></H1><!--SEC END --><P> <A NAME="i18ni10n"></A>
|
||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc101">Appendix A</A>  <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
|
||||
@ -4370,9 +4416,9 @@ HTTP header ‘Accept-Language: ru’</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="htoc101">Appendix B</A>  <A HREF="#releasenotes">Release Notes</A></H1><!--SEC END --><P> <A NAME="releasenotes"></A>
|
||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc102">Appendix B</A>  <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="htoc102">Appendix C</A>  <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="htoc103">Appendix C</A>  <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>)
|
||||
@ -4385,7 +4431,7 @@ Alexey Shchepin (<A HREF="xmpp:aleksey@jabber.ru"><TT>xmpp:aleksey@jabber.ru</TT
|
||||
</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="htoc103">Appendix D</A>  <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="htoc104">Appendix D</A>  <A HREF="#copyright">Copyright Information</A></H1><!--SEC END --><P> <A NAME="copyright"></A> </P><P>Ejabberd Installation and Operation Guide.<BR>
|
||||
Copyright © 2003 — 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
|
||||
|
@ -1,2 +1,2 @@
|
||||
% ejabberd version (automatically generated).
|
||||
\newcommand{\version}{2.1.x}
|
||||
\newcommand{\version}{2.1.7}
|
||||
|
Loading…
Reference in New Issue
Block a user