mirror of
https://github.com/processone/ejabberd.git
synced 2024-11-22 16:20:52 +01:00
Support XEP-0199 Ping (thanks to Brian Cully and Evgeniy Khramtsov)(EJAB-974)
SVN Revision: 2419
This commit is contained in:
Badlop
parent
a321ab3653
commit
14399e3d57
227
doc/guide.html
227
doc/guide.html
@ -148,72 +148,73 @@ BLOCKQUOTE.figure DIV.center DIV.center HR{display:none;}
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc46">3.3.9  <TT>mod_muc</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc47">3.3.10  <TT>mod_muc_log</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc48">3.3.11  <TT>mod_offline</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc49">3.3.12  <TT>mod_privacy</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc50">3.3.13  <TT>mod_private</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc51">3.3.14  <TT>mod_proxy65</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc52">3.3.15  <TT>mod_pubsub</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc53">3.3.16  <TT>mod_register</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc54">3.3.17  <TT>mod_roster</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc55">3.3.18  <TT>mod_service_log</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc56">3.3.19  <TT>mod_shared_roster</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc57">3.3.20  <TT>mod_stats</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc58">3.3.21  <TT>mod_time</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc59">3.3.22  <TT>mod_vcard</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc60">3.3.23  <TT>mod_vcard_ldap</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc61">3.3.24  <TT>mod_version</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc49">3.3.12  <TT>mod_ping</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc50">3.3.13  <TT>mod_privacy</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc51">3.3.14  <TT>mod_private</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc52">3.3.15  <TT>mod_proxy65</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc53">3.3.16  <TT>mod_pubsub</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc54">3.3.17  <TT>mod_register</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc55">3.3.18  <TT>mod_roster</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc56">3.3.19  <TT>mod_service_log</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc57">3.3.20  <TT>mod_shared_roster</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc58">3.3.21  <TT>mod_stats</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc59">3.3.22  <TT>mod_time</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc60">3.3.23  <TT>mod_vcard</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc61">3.3.24  <TT>mod_vcard_ldap</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc62">3.3.25  <TT>mod_version</TT></A>
|
||||
</LI></UL>
|
||||
</LI></UL>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc62">Chapter 4  Managing an <TT>ejabberd</TT> Server</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc63">Chapter 4  Managing an <TT>ejabberd</TT> Server</A>
|
||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||
<A HREF="#htoc63">4.1  <TT>ejabberdctl</TT></A>
|
||||
<A HREF="#htoc64">4.1  <TT>ejabberdctl</TT></A>
|
||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||
<A HREF="#htoc64">4.1.1  ejabberdctl Commands</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc65">4.1.2  Erlang Runtime System</A>
|
||||
<A HREF="#htoc65">4.1.1  ejabberdctl Commands</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc66">4.1.2  Erlang Runtime System</A>
|
||||
</LI></UL>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc66">4.2  <TT>ejabberd</TT> Commands</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc67">4.2  <TT>ejabberd</TT> Commands</A>
|
||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||
<A HREF="#htoc67">4.2.1  List of ejabberd Commands</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc68">4.2.2  Restrict Execution with AccessCommands</A>
|
||||
<A HREF="#htoc68">4.2.1  List of ejabberd Commands</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc69">4.2.2  Restrict Execution with AccessCommands</A>
|
||||
</LI></UL>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc69">4.3  Web Admin</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc70">4.4  Ad-hoc Commands</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc71">4.5  Change Computer Hostname</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc70">4.3  Web Admin</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc71">4.4  Ad-hoc Commands</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc72">4.5  Change Computer Hostname</A>
|
||||
</LI></UL>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc72">Chapter 5  Securing <TT>ejabberd</TT></A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc73">Chapter 5  Securing <TT>ejabberd</TT></A>
|
||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||
<A HREF="#htoc73">5.1  Firewall Settings</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc74">5.2  epmd</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc75">5.3  Erlang Cookie</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc76">5.4  Erlang Node Name</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc77">5.5  Securing Sensible Files</A>
|
||||
<A HREF="#htoc74">5.1  Firewall Settings</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc75">5.2  epmd</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc76">5.3  Erlang Cookie</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc77">5.4  Erlang Node Name</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc78">5.5  Securing Sensible Files</A>
|
||||
</LI></UL>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc78">Chapter 6  Clustering</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc79">Chapter 6  Clustering</A>
|
||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||
<A HREF="#htoc79">6.1  How it Works</A>
|
||||
<A HREF="#htoc80">6.1  How it Works</A>
|
||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||
<A HREF="#htoc80">6.1.1  Router</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc81">6.1.2  Local Router</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc82">6.1.3  Session Manager</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc83">6.1.4  s2s Manager</A>
|
||||
<A HREF="#htoc81">6.1.1  Router</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc82">6.1.2  Local Router</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc83">6.1.3  Session Manager</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc84">6.1.4  s2s Manager</A>
|
||||
</LI></UL>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc84">6.2  Clustering Setup</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc85">6.3  Service Load-Balancing</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc85">6.2  Clustering Setup</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc86">6.3  Service Load-Balancing</A>
|
||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||
<A HREF="#htoc86">6.3.1  Components Load-Balancing</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc87">6.3.2  Domain Load-Balancing Algorithm</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc88">6.3.3  Load-Balancing Buckets</A>
|
||||
<A HREF="#htoc87">6.3.1  Components Load-Balancing</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc88">6.3.2  Domain Load-Balancing Algorithm</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc89">6.3.3  Load-Balancing Buckets</A>
|
||||
</LI></UL>
|
||||
</LI></UL>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc89">Chapter 7  Debugging</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc90">Chapter 7  Debugging</A>
|
||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||
<A HREF="#htoc90">7.1  Log Files</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc91">7.2  Debug Console</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc92">7.3  Watchdog Alerts</A>
|
||||
<A HREF="#htoc91">7.1  Log Files</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc92">7.2  Debug Console</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc93">7.3  Watchdog Alerts</A>
|
||||
</LI></UL>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc93">Appendix A  Internationalization and Localization</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc94">Appendix B  Release Notes</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc95">Appendix C  Acknowledgements</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc96">Appendix D  Copyright Information</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc94">Appendix A  Internationalization and Localization</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc95">Appendix B  Release Notes</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc96">Appendix C  Acknowledgements</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc97">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</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-->
|
||||
@ -492,7 +493,7 @@ There are two ways to register a Jabber 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 Jabber client and In-Band Registration (see section <A HREF="#modregister">3.3.16</A>).
|
||||
</PRE></LI><LI CLASS="li-enumerate">Using a Jabber client and In-Band Registration (see section <A HREF="#modregister">3.3.17</A>).
|
||||
</LI></OL>
|
||||
</LI><LI CLASS="li-enumerate">Edit the <TT>ejabberd</TT> configuration file to give administration rights to the Jabber account you created:
|
||||
<PRE CLASS="verbatim">{acl, admins, {user, "admin1", "example.org"}}.
|
||||
@ -1786,6 +1787,7 @@ all entries end with a comma:
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#modmuclog"><TT>mod_muc_log</TT></A></TD><TD ALIGN=left NOWRAP>Multi-User Chat room logging</TD><TD ALIGN=left NOWRAP><TT>mod_muc</TT></TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#modoffline"><TT>mod_offline</TT></A></TD><TD ALIGN=left NOWRAP>Offline message storage (<A HREF="http://www.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://www.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://www.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="#modprivate"><TT>mod_private</TT></A></TD><TD ALIGN=left NOWRAP>Private XML Storage (<A HREF="http://www.xmpp.org/extensions/xep-0049.html">XEP-0049</A>)</TD><TD ALIGN=left NOWRAP> </TD></TR>
|
||||
@ -2506,7 +2508,8 @@ top link will be the default <CODE><a href="/">Home</a></CODE>.
|
||||
]}.
|
||||
</PRE></LI></UL><P> <A NAME="modoffline"></A> </P><!--TOC subsection <TT>mod_offline</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc48">3.3.11</A>  <A HREF="#modoffline"><TT>mod_offline</TT></A></H3><!--SEC END --><P> <A NAME="modoffline"></A>
|
||||
</P><P>This module implements offline message storage. This means that all messages
|
||||
</P><P>This module implements offline message storage (<A HREF="http://www.xmpp.org/extensions/xep-0160.html">XEP-0160</A>).
|
||||
This means that all messages
|
||||
sent to an offline user will be stored on the server until that user comes
|
||||
online again. Thus it is very similar to how email works. Note that
|
||||
<TT>ejabberdctl</TT> has a command to delete expired messages
|
||||
@ -2535,8 +2538,36 @@ and all the other users up to 100.
|
||||
{mod_offline, [ {access_max_user_messages, max_user_offline_messages} ]},
|
||||
...
|
||||
]}.
|
||||
</PRE><P> <A NAME="modping"></A> </P><!--TOC subsection <TT>mod_ping</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc49">3.3.12</A>  <A HREF="#modping"><TT>mod_ping</TT></A></H3><!--SEC END --><P> <A NAME="modping"></A>
|
||||
</P><P>This module implements support for XMPP Ping (<A HREF="http://www.xmpp.org/extensions/xep-0199.html">XEP-0199</A>) and periodic keepalives.
|
||||
When this module is enabled ejabberd responds correctly to
|
||||
ping requests, as defined in the protocol.</P><P>Configuration options:
|
||||
</P><DL CLASS="description"><DT CLASS="dt-description">
|
||||
<B><TT>{send_pings, true | false}</TT></B></DT><DD CLASS="dd-description">
|
||||
If this option is set to <TT>true</TT>, the server sends pings to connected clients
|
||||
that are not active in a given interval <TT>ping_interval</TT>.
|
||||
This is useful to keep client connections alive or checking availability.
|
||||
By default this option is disabled.
|
||||
</DD><DT CLASS="dt-description"><B><TT>{ping_interval, Seconds}</TT></B></DT><DD CLASS="dd-description">
|
||||
How often to send pings to connected clients, if the previous option is enabled.
|
||||
If a client connection does not send or receive any stanza in this interval,
|
||||
a ping request is sent to the client.
|
||||
The default value is 60 seconds.
|
||||
</DD><DT CLASS="dt-description"><B><TT>{timeout_action, none | kill}</TT></B></DT><DD CLASS="dd-description">
|
||||
What to do when a client does not answer to a server ping request in less than 32 seconds.
|
||||
The default is to do nothing.
|
||||
</DD></DL><P>This example enables Ping responses, configures the module to send pings
|
||||
to client connections that are inactive for 4 minutes,
|
||||
and if a client does not answer to the ping in less than 32 seconds, its connection is closed:
|
||||
</P><PRE CLASS="verbatim">{modules,
|
||||
[
|
||||
...
|
||||
{mod_ping, [{send_pings, true}, {ping_interval, 240}, {timeout_action, kill}]},
|
||||
...
|
||||
]}.
|
||||
</PRE><P> <A NAME="modprivacy"></A> </P><!--TOC subsection <TT>mod_privacy</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc49">3.3.12</A>  <A HREF="#modprivacy"><TT>mod_privacy</TT></A></H3><!--SEC END --><P> <A NAME="modprivacy"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc50">3.3.13</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 Jabber client, they will be able to:
|
||||
@ -2564,7 +2595,7 @@ subscription type (or globally).
|
||||
<B><TT>iqdisc</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="htoc50">3.3.13</A>  <A HREF="#modprivate"><TT>mod_private</TT></A></H3><!--SEC END --><P> <A NAME="modprivate"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc51">3.3.14</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://www.xmpp.org/extensions/xep-0049.html">XEP-0049</A>):
|
||||
</P><BLOCKQUOTE CLASS="quote">
|
||||
Using this method, Jabber entities can store private data on the server and
|
||||
@ -2576,7 +2607,7 @@ of client-specific preferences; another is Bookmark Storage (<A HREF="http://www
|
||||
<B><TT>iqdisc</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="htoc51">3.3.14</A>  <A HREF="#modproxy"><TT>mod_proxy65</TT></A></H3><!--SEC END --><P> <A NAME="modproxy"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc52">3.3.15</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://www.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:
|
||||
@ -2631,7 +2662,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="htoc52">3.3.15</A>  <A HREF="#modpubsub"><TT>mod_pubsub</TT></A></H3><!--SEC END --><P> <A NAME="modpubsub"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc53">3.3.16</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://www.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://www.xmpp.org/extensions/xep-0163.html">XEP-0163</A>)
|
||||
@ -2677,7 +2708,7 @@ The following example will use node_tune instead of node_pep for every PEP node
|
||||
...
|
||||
]}.
|
||||
</PRE><P> <A NAME="modregister"></A> </P><!--TOC subsection <TT>mod_register</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc53">3.3.16</A>  <A HREF="#modregister"><TT>mod_register</TT></A></H3><!--SEC END --><P> <A NAME="modregister"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc54">3.3.17</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://www.xmpp.org/extensions/xep-0077.html">XEP-0077</A>). This protocol
|
||||
enables end users to use a Jabber client to:
|
||||
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
|
||||
@ -2750,13 +2781,13 @@ Also define a registration timeout of one hour:
|
||||
...
|
||||
]}.
|
||||
</PRE></LI></UL><P> <A NAME="modroster"></A> </P><!--TOC subsection <TT>mod_roster</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc54">3.3.17</A>  <A HREF="#modroster"><TT>mod_roster</TT></A></H3><!--SEC END --><P> <A NAME="modroster"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc55">3.3.18</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://www.xmpp.org/specs/rfc3921.html#roster">RFC 3921: XMPP IM</A>.</P><P>Options:
|
||||
</P><DL CLASS="description"><DT CLASS="dt-description">
|
||||
<B><TT>iqdisc</TT></B></DT><DD CLASS="dd-description"> This specifies
|
||||
the processing discipline for Roster Management (<TT>jabber:iq:roster</TT>) IQ queries (see section <A HREF="#modiqdiscoption">3.3.2</A>).
|
||||
</DD></DL><P> <A NAME="modservicelog"></A> </P><!--TOC subsection <TT>mod_service_log</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc55">3.3.18</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="htoc56">3.3.19</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 Jabber message
|
||||
auditing service such as
|
||||
<A HREF="http://www.funkypenguin.info/project/bandersnatch/">Bandersnatch</A>. All user
|
||||
@ -2786,7 +2817,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="htoc56">3.3.19</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="htoc57">3.3.20</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
|
||||
@ -2861,7 +2892,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="modstats"></A> </P><!--TOC subsection <TT>mod_stats</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc57">3.3.20</A>  <A HREF="#modstats"><TT>mod_stats</TT></A></H3><!--SEC END --><P> <A NAME="modstats"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc58">3.3.21</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://www.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">
|
||||
@ -2893,14 +2924,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="htoc58">3.3.21</A>  <A HREF="#modtime"><TT>mod_time</TT></A></H3><!--SEC END --><P> <A NAME="modtime"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc59">3.3.22</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://www.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</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="htoc59">3.3.22</A>  <A HREF="#modvcard"><TT>mod_vcard</TT></A></H3><!--SEC END --><P> <A NAME="modvcard"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc60">3.3.23</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://www.xmpp.org/extensions/xep-0054.html">XEP-0054</A>). The module also
|
||||
implements an uncomplicated Jabber User Directory based on the vCards of
|
||||
@ -2955,7 +2986,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="htoc60">3.3.23</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="htoc61">3.3.24</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>Note that <TT>ejabberd</TT> treats LDAP as a read-only storage:
|
||||
@ -3131,7 +3162,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="modversion"></A> </P><!--TOC subsection <TT>mod_version</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc61">3.3.24</A>  <A HREF="#modversion"><TT>mod_version</TT></A></H3><!--SEC END --><P> <A NAME="modversion"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc62">3.3.25</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://www.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">
|
||||
@ -3140,8 +3171,8 @@ The default value is <TT>true</TT>.
|
||||
</DD><DT CLASS="dt-description"><B><TT>iqdisc</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="htoc62">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="htoc63">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="htoc63">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="htoc64">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
|
||||
@ -3153,7 +3184,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="htoc64">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="htoc65">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">
|
||||
@ -3189,7 +3220,7 @@ robot1
|
||||
testuser1
|
||||
testuser2
|
||||
</PRE><P> <A NAME="erlangconfiguration"></A> </P><!--TOC subsection Erlang Runtime System-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc65">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="htoc66">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>,
|
||||
@ -3262,7 +3293,7 @@ Starts the Erlang system detached from the system console.
|
||||
</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="htoc66">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="htoc67">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>.
|
||||
@ -3270,7 +3301,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="htoc67">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="htoc68">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
|
||||
@ -3310,7 +3341,7 @@ exist tutorials to <A HREF="http://www.ejabberd.im/migrate-to-ejabberd">migrate
|
||||
in offline storage. This might be useful when the number of offline messages
|
||||
is very high.
|
||||
</DD></DL><P> <A NAME="accesscommands"></A> </P><!--TOC subsection Restrict Execution with AccessCommands-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc68">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="htoc69">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:
|
||||
@ -3356,7 +3387,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="htoc69">4.3</A>  <A HREF="#webadmin">Web Admin</A></H2><!--SEC END --><P> <A NAME="webadmin"></A>
|
||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc70">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
|
||||
@ -3428,13 +3459,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="htoc70">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="htoc71">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 Jabber client.
|
||||
The client must support Ad-Hoc Commands (<A HREF="http://www.xmpp.org/extensions/xep-0050.html">XEP-0050</A>),
|
||||
and you must login in the Jabber 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="htoc71">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="htoc72">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.
|
||||
@ -3471,8 +3502,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="htoc72">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="htoc73">5.1</A>  <A HREF="#firewall">Firewall Settings</A></H2><!--SEC END --><P> <A NAME="firewall"></A>
|
||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc73">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="htoc74">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>
|
||||
@ -3483,7 +3514,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="htoc74">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="htoc75">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.
|
||||
@ -3508,7 +3539,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="htoc75">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="htoc76">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.
|
||||
@ -3522,7 +3553,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="htoc76">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="htoc77">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
|
||||
@ -3531,7 +3562,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 Sensible Files-->
|
||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc77">5.5</A>  <A HREF="#secure-files">Securing Sensible Files</A></H2><!--SEC END --><P> <A NAME="secure-files"></A> </P><P><TT>ejabberd</TT> stores sensible data in the file system either in plain text or binary files.
|
||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc78">5.5</A>  <A HREF="#secure-files">Securing Sensible Files</A></H2><!--SEC END --><P> <A NAME="secure-files"></A> </P><P><TT>ejabberd</TT> stores sensible 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">
|
||||
@ -3551,9 +3582,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="htoc78">Chapter 6</A>  <A HREF="#clustering">Clustering</A></H1><!--SEC END --><P> <A NAME="clustering"></A>
|
||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc79">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="htoc79">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="htoc80">6.1</A>  <A HREF="#howitworks">How it Works</A></H2><!--SEC END --><P> <A NAME="howitworks"></A>
|
||||
</P><P>A Jabber 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
|
||||
@ -3567,29 +3598,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="htoc80">6.1.1</A>  <A HREF="#router">Router</A></H3><!--SEC END --><P> <A NAME="router"></A>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc81">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 Jabber 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="htoc81">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="htoc82">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="htoc82">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="htoc83">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="htoc83">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="htoc84">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 Jabber 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="htoc84">6.2</A>  <A HREF="#cluster">Clustering Setup</A></H2><!--SEC END --><P> <A NAME="cluster"></A>
|
||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc85">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">
|
||||
@ -3627,10 +3658,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="htoc85">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="htoc86">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="htoc86">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="htoc87">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="htoc87">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="htoc88">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><PRE CLASS="verbatim">{domain_balancing, "component.example.com", <balancing_criterium>}.
|
||||
</PRE><P>Several balancing criteria are available:
|
||||
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
|
||||
@ -3639,13 +3670,13 @@ 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="htoc88">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="htoc89">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 the following:
|
||||
</P><PRE CLASS="verbatim">{domain_balancing_component_number, "component.example.com", N}
|
||||
</PRE><P> <A NAME="debugging"></A> </P><!--TOC chapter Debugging-->
|
||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc89">Chapter 7</A>  <A HREF="#debugging">Debugging</A></H1><!--SEC END --><P> <A NAME="debugging"></A>
|
||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc90">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="htoc90">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="htoc91">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>sasl.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)
|
||||
@ -3667,12 +3698,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="htoc91">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="htoc92">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="htoc92">7.3</A>  <A HREF="#watchdog">Watchdog Alerts</A></H2><!--SEC END --><P> <A NAME="watchdog"></A>
|
||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc93">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,
|
||||
@ -3690,7 +3721,7 @@ or in a conversation with the watchdog alert bot.</P><P>Example configuration:
|
||||
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="htoc93">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="htoc94">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
|
||||
@ -3725,9 +3756,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="htoc94">Appendix B</A>  <A HREF="#releasenotes">Release Notes</A></H1><!--SEC END --><P> <A NAME="releasenotes"></A>
|
||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc95">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="htoc95">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="htoc96">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>)
|
||||
@ -3739,7 +3770,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="htoc96">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="htoc97">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 — 2009 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
|
||||
|
||||
@ -76,6 +76,7 @@
|
||||
\newcommand{\modmuclog}{\module{mod\_muc\_log}}
|
||||
\newcommand{\modoffline}{\module{mod\_offline}}
|
||||
\newcommand{\modofflineodbc}{\module{mod\_offline\_odbc}}
|
||||
\newcommand{\modping}{\module{mod\_ping}}
|
||||
\newcommand{\modprivacy}{\module{mod\_privacy}}
|
||||
\newcommand{\modprivacyodbc}{\module{mod\_privacy\_odbc}}
|
||||
\newcommand{\modprivate}{\module{mod\_private}}
|
||||
@ -2375,6 +2376,7 @@ The following table lists all modules included in \ejabberd{}.
|
||||
\hline \ahrefloc{modmuclog}{\modmuclog{}} & Multi-User Chat room logging & \modmuc{} \\
|
||||
\hline \ahrefloc{modoffline}{\modoffline{}} & Offline message storage (\xepref{0160}) & \\
|
||||
\hline \ahrefloc{modoffline}{\modofflineodbc{}} & Offline message storage (\xepref{0160}) & supported DB (*) \\
|
||||
\hline \ahrefloc{modping}{\modping{}} & XMPP Ping and periodic keepalives (\xepref{0199}) & \\
|
||||
\hline \ahrefloc{modprivacy}{\modprivacy{}} & Blocking Communication (XMPP IM) & \\
|
||||
\hline \ahrefloc{modprivacy}{\modprivacyodbc{}} & Blocking Communication (XMPP IM) & supported DB (*) \\
|
||||
\hline \ahrefloc{modprivate}{\modprivate{}} & Private XML Storage (\xepref{0049}) & \\
|
||||
@ -3224,7 +3226,8 @@ Examples:
|
||||
\makesubsection{modoffline}{\modoffline{}}
|
||||
\ind{modules!\modoffline{}}
|
||||
|
||||
This module implements offline message storage. This means that all messages
|
||||
This module implements offline message storage (\xepref{0160}).
|
||||
This means that all messages
|
||||
sent to an offline user will be stored on the server until that user comes
|
||||
online again. Thus it is very similar to how email works. Note that
|
||||
\term{ejabberdctl}\ind{ejabberdctl} has a command to delete expired messages
|
||||
@ -3260,6 +3263,43 @@ and all the other users up to 100.
|
||||
]}.
|
||||
\end{verbatim}
|
||||
|
||||
\makesubsection{modping}{\modping{}}
|
||||
\ind{modules!\modping{}}
|
||||
|
||||
This module implements support for XMPP Ping (\xepref{0199}) and periodic keepalives.
|
||||
When this module is enabled ejabberd responds correctly to
|
||||
ping requests, as defined in the protocol.
|
||||
|
||||
Configuration options:
|
||||
\begin{description}
|
||||
\titem{\{send\_pings, true | false\}}\ind{options!send\_pings}
|
||||
If this option is set to \term{true}, the server sends pings to connected clients
|
||||
that are not active in a given interval \term{ping\_interval}.
|
||||
This is useful to keep client connections alive or checking availability.
|
||||
By default this option is disabled.
|
||||
% because it is mostly not needed and consumes resources.
|
||||
\titem{\{ping\_interval, Seconds\}}\ind{options!ping\_interval}
|
||||
How often to send pings to connected clients, if the previous option is enabled.
|
||||
If a client connection does not send or receive any stanza in this interval,
|
||||
a ping request is sent to the client.
|
||||
The default value is 60 seconds.
|
||||
\titem{\{timeout\_action, none | kill\}}\ind{options!timeout\_action}
|
||||
What to do when a client does not answer to a server ping request in less than 32 seconds.
|
||||
% Those 32 seconds are defined in ejabberd_local.erl: -define(IQ_TIMEOUT, 32000).
|
||||
The default is to do nothing.
|
||||
\end{description}
|
||||
|
||||
This example enables Ping responses, configures the module to send pings
|
||||
to client connections that are inactive for 4 minutes,
|
||||
and if a client does not answer to the ping in less than 32 seconds, its connection is closed:
|
||||
\begin{verbatim}
|
||||
{modules,
|
||||
[
|
||||
...
|
||||
{mod_ping, [{send_pings, true}, {ping_interval, 240}, {timeout_action, kill}]},
|
||||
...
|
||||
]}.
|
||||
\end{verbatim}
|
||||
|
||||
\makesubsection{modprivacy}{\modprivacy{}}
|
||||
\ind{modules!\modprivacy{}}\ind{Blocking Communication}\ind{Privacy Rules}\ind{protocols!RFC 3921: XMPP IM}
|
||||
|
||||
@ -494,6 +494,7 @@
|
||||
]},
|
||||
%%{mod_muc_log,[]},
|
||||
{mod_offline, [{access_max_user_messages, max_user_offline_messages}]},
|
||||
{mod_ping, []},
|
||||
{mod_privacy, []},
|
||||
{mod_private, []},
|
||||
%%{mod_proxy65,[]},
|
||||
|
||||
@ -32,6 +32,7 @@
|
||||
|
||||
%% External exports
|
||||
-export([start/2,
|
||||
stop/1,
|
||||
start_link/2,
|
||||
send_text/2,
|
||||
send_element/2,
|
||||
@ -150,6 +151,9 @@ get_presence(FsmRef) ->
|
||||
get_state(FsmRef) ->
|
||||
gen_fsm:sync_send_all_state_event(FsmRef, get_state, 1000).
|
||||
|
||||
stop(FsmRef) ->
|
||||
gen_fsm:send_event(FsmRef, closed).
|
||||
|
||||
%%%----------------------------------------------------------------------
|
||||
%%% Callback functions from gen_fsm
|
||||
%%%----------------------------------------------------------------------
|
||||
|
||||
@ -33,6 +33,8 @@
|
||||
-export([start_link/0]).
|
||||
|
||||
-export([route/3,
|
||||
route_iq/4,
|
||||
process_iq_reply/3,
|
||||
register_iq_handler/4,
|
||||
register_iq_handler/5,
|
||||
register_iq_response_handler/4,
|
||||
@ -52,10 +54,13 @@
|
||||
|
||||
-record(state, {}).
|
||||
|
||||
-record(iq_response, {id, module, function}).
|
||||
-record(iq_response, {id, module, function, timer}).
|
||||
|
||||
-define(IQTABLE, local_iqtable).
|
||||
|
||||
%% This value is used in SIP and Megaco for a transaction lifetime.
|
||||
-define(IQ_TIMEOUT, 32000).
|
||||
|
||||
% These are the namespace already declared by the stream opening. This is
|
||||
% used at serialization time.
|
||||
-define(DEFAULT_NS, ?NS_JABBER_CLIENT).
|
||||
@ -94,35 +99,25 @@ process_iq(From, To, Packet) ->
|
||||
Err = exmpp_iq:error(Packet, 'feature-not-implemented'),
|
||||
ejabberd_router:route(To, From, Err)
|
||||
end;
|
||||
#iq{kind = response} = IQ_Rec ->
|
||||
process_iq_reply(From, To, IQ_Rec);
|
||||
#iq{kind = response} = IQReply ->
|
||||
%%IQReply = jlib:iq_query_or_response_info(IQ_Rec),
|
||||
process_iq_reply(From, To, IQReply);
|
||||
_ ->
|
||||
Err = exmpp_iq:error(Packet, 'bad-request'),
|
||||
ejabberd_router:route(To, From, Err),
|
||||
ok
|
||||
end.
|
||||
|
||||
process_iq_reply(From, To, #iq{id = ID} = IQ_Rec) ->
|
||||
case catch mnesia:dirty_read(iq_response, ID) of
|
||||
[] ->
|
||||
process_iq_reply(From, To, #iq{id = ID} = IQ) ->
|
||||
case get_iq_callback(ID) of
|
||||
{ok, undefined, Function} ->
|
||||
Function(IQ),
|
||||
ok;
|
||||
{ok, Module, Function} ->
|
||||
Module:Function(From, To, IQ),
|
||||
ok;
|
||||
_ ->
|
||||
F = fun() ->
|
||||
case mnesia:read({iq_response, ID}) of
|
||||
[] ->
|
||||
nothing;
|
||||
[#iq_response{module = Module,
|
||||
function = Function}] ->
|
||||
mnesia:delete({iq_response, ID}),
|
||||
{Module, Function}
|
||||
end
|
||||
end,
|
||||
case mnesia:transaction(F) of
|
||||
{atomic, {Module, Function}} ->
|
||||
Module:Function(From, To, IQ_Rec);
|
||||
_ ->
|
||||
ok
|
||||
end
|
||||
nothing
|
||||
end.
|
||||
|
||||
route(FromOld, ToOld, #xmlelement{} = PacketOld) ->
|
||||
@ -144,8 +139,21 @@ route(From, To, Packet) ->
|
||||
ok
|
||||
end.
|
||||
|
||||
route_iq(From, To, #iq{type = Type} = IQ, F) when is_function(F) ->
|
||||
Packet = if Type == set; Type == get ->
|
||||
ID = list_to_binary(randoms:get_string()),
|
||||
Host = exmpp_jid:prep_domain(From),
|
||||
register_iq_response_handler(Host, ID, undefined, F),
|
||||
exmpp_iq:iq_to_xmlel(IQ#iq{id = ID});
|
||||
true ->
|
||||
exmpp_iq:iq_to_xmlel(IQ)
|
||||
end,
|
||||
ejabberd_router:route(From, To, Packet).
|
||||
|
||||
register_iq_response_handler(Host, ID, Module, Fun) ->
|
||||
ejabberd_local ! {register_iq_response_handler, Host, ID, Module, Fun}.
|
||||
gen_server:call(ejabberd_local,
|
||||
{register_iq_response_handler,
|
||||
Host, ID, Module, Fun}).
|
||||
|
||||
register_iq_handler(Host, XMLNS, Module, Fun) ->
|
||||
ejabberd_local ! {register_iq_handler, Host, XMLNS, Module, Fun}.
|
||||
@ -153,8 +161,9 @@ register_iq_handler(Host, XMLNS, Module, Fun) ->
|
||||
register_iq_handler(Host, XMLNS, Module, Fun, Opts) ->
|
||||
ejabberd_local ! {register_iq_handler, Host, XMLNS, Module, Fun, Opts}.
|
||||
|
||||
unregister_iq_response_handler(Host, ID) ->
|
||||
ejabberd_local ! {unregister_iq_response_handler, Host, ID}.
|
||||
unregister_iq_response_handler(_Host, ID) ->
|
||||
catch get_iq_callback(ID),
|
||||
ok.
|
||||
|
||||
unregister_iq_handler(Host, XMLNS) ->
|
||||
ejabberd_local ! {unregister_iq_handler, Host, XMLNS}.
|
||||
@ -186,6 +195,7 @@ init([]) ->
|
||||
?MODULE, bounce_resource_packet, 100)
|
||||
end, ?MYHOSTS),
|
||||
catch ets:new(?IQTABLE, [named_table, public]),
|
||||
update_table(),
|
||||
mnesia:create_table(iq_response,
|
||||
[{ram_copies, [node()]},
|
||||
{attributes, record_info(fields, iq_response)}]),
|
||||
@ -201,6 +211,14 @@ init([]) ->
|
||||
%% {stop, Reason, State}
|
||||
%% Description: Handling call messages
|
||||
%%--------------------------------------------------------------------
|
||||
handle_call({register_iq_response_handler, _Host,
|
||||
ID, Module, Function}, _From, State) ->
|
||||
TRef = erlang:start_timer(?IQ_TIMEOUT, self(), ID),
|
||||
mnesia:dirty_write(#iq_response{id = ID,
|
||||
module = Module,
|
||||
function = Function,
|
||||
timer = TRef}),
|
||||
{reply, ok, State};
|
||||
handle_call(_Request, _From, State) ->
|
||||
Reply = ok,
|
||||
{reply, Reply, State}.
|
||||
@ -239,12 +257,6 @@ handle_info({route, From, To, Packet}, State) ->
|
||||
ok
|
||||
end,
|
||||
{noreply, State};
|
||||
handle_info({register_iq_response_handler, _Host, ID, Module, Function}, State) ->
|
||||
mnesia:dirty_write(#iq_response{id = ID, module = Module, function = Function}),
|
||||
{noreply, State};
|
||||
handle_info({unregister_iq_response_handler, _Host, ID}, State) ->
|
||||
mnesia:dirty_delete({iq_response, ID}),
|
||||
{noreply, State};
|
||||
handle_info({register_iq_handler, Host, XMLNS, Module, Function}, State) ->
|
||||
ets:insert(?IQTABLE, {{XMLNS, Host}, Module, Function}),
|
||||
catch mod_disco:register_feature(Host, XMLNS),
|
||||
@ -276,6 +288,9 @@ handle_info(refresh_iq_handlers, State) ->
|
||||
end
|
||||
end, ets:tab2list(?IQTABLE)),
|
||||
{noreply, State};
|
||||
handle_info({timeout, _TRef, ID}, State) ->
|
||||
process_iq_timeout(ID),
|
||||
{noreply, State};
|
||||
handle_info(_Info, State) ->
|
||||
{noreply, State}.
|
||||
|
||||
@ -330,3 +345,52 @@ do_route(From, To, Packet) ->
|
||||
end
|
||||
end.
|
||||
|
||||
update_table() ->
|
||||
case catch mnesia:table_info(iq_response, attributes) of
|
||||
[id, module, function] ->
|
||||
mnesia:delete_table(iq_response);
|
||||
[id, module, function, timer] ->
|
||||
ok;
|
||||
{'EXIT', _} ->
|
||||
ok
|
||||
end.
|
||||
|
||||
get_iq_callback(ID) ->
|
||||
case mnesia:dirty_read(iq_response, ID) of
|
||||
[#iq_response{module = Module, timer = TRef,
|
||||
function = Function}] ->
|
||||
cancel_timer(TRef),
|
||||
mnesia:dirty_delete(iq_response, ID),
|
||||
{ok, Module, Function};
|
||||
_ ->
|
||||
error
|
||||
end.
|
||||
|
||||
process_iq_timeout(ID) ->
|
||||
spawn(fun process_iq_timeout/0) ! ID.
|
||||
|
||||
process_iq_timeout() ->
|
||||
receive
|
||||
ID ->
|
||||
case get_iq_callback(ID) of
|
||||
{ok, undefined, Function} ->
|
||||
Function(timeout);
|
||||
_ ->
|
||||
ok
|
||||
end
|
||||
after 5000 ->
|
||||
ok
|
||||
end.
|
||||
|
||||
cancel_timer(TRef) ->
|
||||
case erlang:cancel_timer(TRef) of
|
||||
false ->
|
||||
receive
|
||||
{timeout, TRef, _} ->
|
||||
ok
|
||||
after 0 ->
|
||||
ok
|
||||
end;
|
||||
_ ->
|
||||
ok
|
||||
end.
|
||||
|
||||
243
src/mod_ping.erl
Normal file
243
src/mod_ping.erl
Normal file
@ -0,0 +1,243 @@
|
||||
%%%----------------------------------------------------------------------
|
||||
%%% File : mod_ping.erl
|
||||
%%% Author : Brian Cully <bjc@kublai.com>
|
||||
%%% Purpose : Support XEP-0199 XMPP Ping and periodic keepalives
|
||||
%%% Created : 11 Jul 2009 by Brian Cully <bjc@kublai.com>
|
||||
%%%
|
||||
%%%
|
||||
%%% ejabberd, Copyright (C) 2002-2009 ProcessOne
|
||||
%%%
|
||||
%%% This program 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 of the
|
||||
%%% License, or (at your option) any later version.
|
||||
%%%
|
||||
%%% This program is distributed in the hope that it will be useful,
|
||||
%%% but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
%%% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
||||
%%% General Public License for more details.
|
||||
%%%
|
||||
%%% You should have received a copy of the GNU General Public License
|
||||
%%% along with this program; if not, write to the Free Software
|
||||
%%% Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
|
||||
%%% 02111-1307 USA
|
||||
%%%
|
||||
%%%----------------------------------------------------------------------
|
||||
|
||||
-module(mod_ping).
|
||||
-author('bjc@kublai.com').
|
||||
|
||||
-behavior(gen_mod).
|
||||
-behavior(gen_server).
|
||||
|
||||
-include("ejabberd.hrl").
|
||||
-include_lib("exmpp/include/exmpp.hrl").
|
||||
|
||||
-define(SUPERVISOR, ejabberd_sup).
|
||||
-define(DEFAULT_SEND_PINGS, false). % bool()
|
||||
-define(DEFAULT_PING_INTERVAL, 60). % seconds
|
||||
|
||||
-define(DICT, dict).
|
||||
|
||||
%% API
|
||||
-export([start_link/2, start_ping/2, stop_ping/2]).
|
||||
|
||||
%% gen_mod callbacks
|
||||
-export([start/2, stop/1]).
|
||||
|
||||
%% gen_server callbacks
|
||||
-export([init/1, terminate/2, handle_call/3, handle_cast/2,
|
||||
handle_info/2, code_change/3]).
|
||||
|
||||
%% Hook callbacks
|
||||
-export([iq_ping/3, user_online/3, user_offline/3, user_send/3]).
|
||||
|
||||
-record(state, {host = "",
|
||||
send_pings = ?DEFAULT_SEND_PINGS,
|
||||
ping_interval = ?DEFAULT_PING_INTERVAL,
|
||||
timeout_action = none,
|
||||
timers = ?DICT:new()}).
|
||||
|
||||
%%====================================================================
|
||||
%% API
|
||||
%%====================================================================
|
||||
start_link(Host, Opts) ->
|
||||
Proc = gen_mod:get_module_proc(Host, ?MODULE),
|
||||
gen_server:start_link({local, Proc}, ?MODULE, [Host, Opts], []).
|
||||
|
||||
start_ping(Host, JID) ->
|
||||
Proc = gen_mod:get_module_proc(Host, ?MODULE),
|
||||
gen_server:cast(Proc, {start_ping, JID}).
|
||||
|
||||
stop_ping(Host, JID) ->
|
||||
Proc = gen_mod:get_module_proc(Host, ?MODULE),
|
||||
gen_server:cast(Proc, {stop_ping, JID}).
|
||||
|
||||
%%====================================================================
|
||||
%% gen_mod callbacks
|
||||
%%====================================================================
|
||||
start(Host, Opts) ->
|
||||
Proc = gen_mod:get_module_proc(Host, ?MODULE),
|
||||
PingSpec = {Proc, {?MODULE, start_link, [Host, Opts]},
|
||||
transient, 2000, worker, [?MODULE]},
|
||||
supervisor:start_child(?SUPERVISOR, PingSpec).
|
||||
|
||||
stop(Host) ->
|
||||
Proc = gen_mod:get_module_proc(Host, ?MODULE),
|
||||
gen_server:call(Proc, stop),
|
||||
supervisor:delete_child(?SUPERVISOR, Proc).
|
||||
|
||||
%%====================================================================
|
||||
%% gen_server callbacks
|
||||
%%====================================================================
|
||||
init([Host, Opts]) ->
|
||||
HostB = list_to_binary(Host),
|
||||
SendPings = gen_mod:get_opt(send_pings, Opts, ?DEFAULT_SEND_PINGS),
|
||||
PingInterval = gen_mod:get_opt(ping_interval, Opts, ?DEFAULT_PING_INTERVAL),
|
||||
TimeoutAction = gen_mod:get_opt(timeout_action, Opts, none),
|
||||
IQDisc = gen_mod:get_opt(iqdisc, Opts, one_queue),
|
||||
mod_disco:register_feature(Host, ?NS_PING),
|
||||
gen_iq_handler:add_iq_handler(ejabberd_sm, HostB, ?NS_PING,
|
||||
?MODULE, iq_ping, IQDisc),
|
||||
gen_iq_handler:add_iq_handler(ejabberd_local, HostB, ?NS_PING,
|
||||
?MODULE, iq_ping, IQDisc),
|
||||
case SendPings of
|
||||
true ->
|
||||
ejabberd_hooks:add(sm_register_connection_hook, HostB,
|
||||
?MODULE, user_online, 100),
|
||||
ejabberd_hooks:add(sm_remove_connection_hook, HostB,
|
||||
?MODULE, user_offline, 100),
|
||||
ejabberd_hooks:add(user_send_packet, HostB,
|
||||
?MODULE, user_send, 100);
|
||||
_ ->
|
||||
ok
|
||||
end,
|
||||
{ok, #state{host = Host,
|
||||
send_pings = SendPings,
|
||||
ping_interval = PingInterval,
|
||||
timeout_action = TimeoutAction,
|
||||
timers = ?DICT:new()}}.
|
||||
|
||||
terminate(_Reason, #state{host = Host}) ->
|
||||
HostB = list_to_binary(Host),
|
||||
ejabberd_hooks:delete(sm_remove_connection_hook, HostB,
|
||||
?MODULE, user_offline, 100),
|
||||
ejabberd_hooks:delete(sm_register_connection_hook, HostB,
|
||||
?MODULE, user_online, 100),
|
||||
ejabberd_hooks:delete(user_send_packet, HostB,
|
||||
?MODULE, user_send, 100),
|
||||
gen_iq_handler:remove_iq_handler(ejabberd_local, HostB, ?NS_PING),
|
||||
gen_iq_handler:remove_iq_handler(ejabberd_sm, HostB, ?NS_PING),
|
||||
mod_disco:unregister_feature(Host, ?NS_PING).
|
||||
|
||||
handle_call(stop, _From, State) ->
|
||||
{stop, normal, ok, State};
|
||||
handle_call(_Req, _From, State) ->
|
||||
{reply, {error, badarg}, State}.
|
||||
|
||||
handle_cast({start_ping, JID}, State) ->
|
||||
Timers = add_timer(JID, State#state.ping_interval, State#state.timers),
|
||||
{noreply, State#state{timers = Timers}};
|
||||
handle_cast({stop_ping, JID}, State) ->
|
||||
Timers = del_timer(JID, State#state.timers),
|
||||
{noreply, State#state{timers = Timers}};
|
||||
handle_cast({iq_pong, JID, timeout}, State) ->
|
||||
Timers = del_timer(JID, State#state.timers),
|
||||
ejabberd_hooks:run(user_ping_timeout, list_to_binary(State#state.host), [JID]),
|
||||
case State#state.timeout_action of
|
||||
kill ->
|
||||
case ejabberd_sm:get_session_pid(JID) of
|
||||
Pid when is_pid(Pid) ->
|
||||
ejabberd_c2s:stop(Pid);
|
||||
_ ->
|
||||
ok
|
||||
end;
|
||||
_ ->
|
||||
ok
|
||||
end,
|
||||
{noreply, State#state{timers = Timers}};
|
||||
handle_cast(_Msg, State) ->
|
||||
{noreply, State}.
|
||||
|
||||
handle_info({timeout, _TRef, {ping, JID}}, State) ->
|
||||
%%IQ = #iq{type = get,
|
||||
%% sub_el = [{xmlelement, "ping", [{"xmlns", ?NS_PING}], []}]},
|
||||
|
||||
%% Build an iq:query request
|
||||
%%IQ = exmpp_iq:get(?NS_PING, #xmlel{ns = ?NS_PING, name = 'ping'}),
|
||||
IQ = #iq{type = get, payload = #xmlel{name = 'ping', ns = ?NS_PING}},
|
||||
|
||||
Pid = self(),
|
||||
F = fun(Response) ->
|
||||
gen_server:cast(Pid, {iq_pong, JID, Response})
|
||||
end,
|
||||
From = exmpp_jid:make(State#state.host),
|
||||
ejabberd_local:route_iq(From, JID, IQ, F),
|
||||
Timers = add_timer(JID, State#state.ping_interval, State#state.timers),
|
||||
{noreply, State#state{timers = Timers}};
|
||||
handle_info(_Info, State) ->
|
||||
{noreply, State}.
|
||||
|
||||
code_change(_OldVsn, State, _Extra) ->
|
||||
{ok, State}.
|
||||
|
||||
%%====================================================================
|
||||
%% Hook callbacks
|
||||
%%====================================================================
|
||||
iq_ping(_From, _To, #iq{type = Type, payload = SubEl} = IQ) ->
|
||||
case {Type, SubEl} of
|
||||
{get, #xmlel{name = ping, ns = ?NS_PING}} ->
|
||||
exmpp_iq:result(IQ);
|
||||
_ ->
|
||||
exmpp_iq:error(IQ, 'feature-not-implemented')
|
||||
end.
|
||||
|
||||
user_online(_SID, JID, _Info) ->
|
||||
Host = exmpp_jid:prep_domain_as_list(JID),
|
||||
start_ping(Host, JID).
|
||||
|
||||
user_offline(_SID, JID, _Info) ->
|
||||
Host = exmpp_jid:prep_domain_as_list(JID),
|
||||
start_ping(Host, JID).
|
||||
|
||||
user_send(JID, _From, _Packet) ->
|
||||
Host = exmpp_jid:prep_domain_as_list(JID),
|
||||
start_ping(Host, JID).
|
||||
|
||||
%%====================================================================
|
||||
%% Internal functions
|
||||
%%====================================================================
|
||||
add_timer(JID, Interval, Timers) ->
|
||||
LJID = exmpp_jid:prep_to_binary(JID),
|
||||
NewTimers = case ?DICT:find(LJID, Timers) of
|
||||
{ok, OldTRef} ->
|
||||
cancel_timer(OldTRef),
|
||||
?DICT:erase(LJID, Timers);
|
||||
_ ->
|
||||
Timers
|
||||
end,
|
||||
TRef = erlang:start_timer(Interval * 1000, self(), {ping, JID}),
|
||||
?DICT:store(LJID, TRef, NewTimers).
|
||||
|
||||
del_timer(JID, Timers) ->
|
||||
LJID = exmpp_jid:prep_to_binary(JID),
|
||||
case ?DICT:find(LJID, Timers) of
|
||||
{ok, TRef} ->
|
||||
cancel_timer(TRef),
|
||||
?DICT:erase(LJID, Timers);
|
||||
_ ->
|
||||
Timers
|
||||
end.
|
||||
|
||||
cancel_timer(TRef) ->
|
||||
case erlang:cancel_timer(TRef) of
|
||||
false ->
|
||||
receive
|
||||
{timeout, TRef, _} ->
|
||||
ok
|
||||
after 0 ->
|
||||
ok
|
||||
end;
|
||||
_ ->
|
||||
ok
|
||||
end.
|
||||
Loading…
Reference in New Issue
Block a user