mirror of
https://github.com/processone/ejabberd.git
synced 2024-11-26 16:26:24 +01:00
* doc/guide.tex: Document new ejabberdctl option. New section that
documents AccessCommands. (EJAB-910) * doc/guide.html: Likewise SVN Revision: 2025
This commit is contained in:
parent
fd967d6976
commit
554a9a72f1
@ -1,5 +1,9 @@
|
|||||||
2009-04-17 Badlop <badlop@process-one.net>
|
2009-04-17 Badlop <badlop@process-one.net>
|
||||||
|
|
||||||
|
* doc/guide.tex: Document new ejabberdctl option. New section that
|
||||||
|
documents AccessCommands. (EJAB-910)
|
||||||
|
* doc/guide.html: Likewise
|
||||||
|
|
||||||
* src/ejabberd_ctl.erl: New option to require auth in ejabberdctl
|
* src/ejabberd_ctl.erl: New option to require auth in ejabberdctl
|
||||||
and restrict what commands and arguments can execute (EJAB-910)
|
and restrict what commands and arguments can execute (EJAB-910)
|
||||||
* src/ejabberd_config.erl: Likewise
|
* src/ejabberd_config.erl: Likewise
|
||||||
|
306
doc/guide.html
306
doc/guide.html
@ -165,48 +165,53 @@ BLOCKQUOTE.figure DIV.center DIV.center HR{display:none;}
|
|||||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||||
<A HREF="#htoc61">4.1  <TT>ejabberdctl</TT></A>
|
<A HREF="#htoc61">4.1  <TT>ejabberdctl</TT></A>
|
||||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||||
<A HREF="#htoc62">4.1.1  Commands</A>
|
<A HREF="#htoc62">4.1.1  ejabberdctl Commands</A>
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc63">4.1.2  Erlang Runtime System</A>
|
</LI><LI CLASS="li-toc"><A HREF="#htoc63">4.1.2  Erlang Runtime System</A>
|
||||||
</LI></UL>
|
</LI></UL>
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc64">4.2  Web Admin</A>
|
</LI><LI CLASS="li-toc"><A HREF="#htoc64">4.2  <TT>ejabberd</TT> Commands</A>
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc65">4.3  Ad-hoc Commands</A>
|
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc66">4.4  Change Computer Hostname</A>
|
|
||||||
</LI></UL>
|
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc67">Chapter 5  Securing <TT>ejabberd</TT></A>
|
|
||||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||||
<A HREF="#htoc68">5.1  Firewall Settings</A>
|
<A HREF="#htoc65">4.2.1  List of ejabberd Commands</A>
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc69">5.2  epmd</A>
|
</LI><LI CLASS="li-toc"><A HREF="#htoc66">4.2.2  Restrict Execution with AccessCommands</A>
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc70">5.3  Erlang Cookie</A>
|
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc71">5.4  Erlang Node Name</A>
|
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc72">5.5  Securing Sensible Files</A>
|
|
||||||
</LI></UL>
|
</LI></UL>
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc73">Chapter 6  Clustering</A>
|
</LI><LI CLASS="li-toc"><A HREF="#htoc67">4.3  Web Admin</A>
|
||||||
|
</LI><LI CLASS="li-toc"><A HREF="#htoc68">4.4  Ad-hoc Commands</A>
|
||||||
|
</LI><LI CLASS="li-toc"><A HREF="#htoc69">4.5  Change Computer Hostname</A>
|
||||||
|
</LI></UL>
|
||||||
|
</LI><LI CLASS="li-toc"><A HREF="#htoc70">Chapter 5  Securing <TT>ejabberd</TT></A>
|
||||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||||
<A HREF="#htoc74">6.1  How it Works</A>
|
<A HREF="#htoc71">5.1  Firewall Settings</A>
|
||||||
|
</LI><LI CLASS="li-toc"><A HREF="#htoc72">5.2  epmd</A>
|
||||||
|
</LI><LI CLASS="li-toc"><A HREF="#htoc73">5.3  Erlang Cookie</A>
|
||||||
|
</LI><LI CLASS="li-toc"><A HREF="#htoc74">5.4  Erlang Node Name</A>
|
||||||
|
</LI><LI CLASS="li-toc"><A HREF="#htoc75">5.5  Securing Sensible Files</A>
|
||||||
|
</LI></UL>
|
||||||
|
</LI><LI CLASS="li-toc"><A HREF="#htoc76">Chapter 6  Clustering</A>
|
||||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||||
<A HREF="#htoc75">6.1.1  Router</A>
|
<A HREF="#htoc77">6.1  How it Works</A>
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc76">6.1.2  Local Router</A>
|
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc77">6.1.3  Session Manager</A>
|
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc78">6.1.4  s2s Manager</A>
|
|
||||||
</LI></UL>
|
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc79">6.2  Clustering Setup</A>
|
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc80">6.3  Service Load-Balancing</A>
|
|
||||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||||
<A HREF="#htoc81">6.3.1  Components Load-Balancing</A>
|
<A HREF="#htoc78">6.1.1  Router</A>
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc82">6.3.2  Domain Load-Balancing Algorithm</A>
|
</LI><LI CLASS="li-toc"><A HREF="#htoc79">6.1.2  Local Router</A>
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc83">6.3.3  Load-Balancing Buckets</A>
|
</LI><LI CLASS="li-toc"><A HREF="#htoc80">6.1.3  Session Manager</A>
|
||||||
|
</LI><LI CLASS="li-toc"><A HREF="#htoc81">6.1.4  s2s Manager</A>
|
||||||
</LI></UL>
|
</LI></UL>
|
||||||
</LI></UL>
|
</LI><LI CLASS="li-toc"><A HREF="#htoc82">6.2  Clustering Setup</A>
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc84">Chapter 7  Debugging</A>
|
</LI><LI CLASS="li-toc"><A HREF="#htoc83">6.3  Service Load-Balancing</A>
|
||||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||||
<A HREF="#htoc85">7.1  Log Files</A>
|
<A HREF="#htoc84">6.3.1  Components Load-Balancing</A>
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc86">7.2  Debug Console</A>
|
</LI><LI CLASS="li-toc"><A HREF="#htoc85">6.3.2  Domain Load-Balancing Algorithm</A>
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc87">7.3  Watchdog Alerts</A>
|
</LI><LI CLASS="li-toc"><A HREF="#htoc86">6.3.3  Load-Balancing Buckets</A>
|
||||||
</LI></UL>
|
</LI></UL>
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc88">Appendix A  Internationalization and Localization</A>
|
</LI></UL>
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc89">Appendix B  Release Notes</A>
|
</LI><LI CLASS="li-toc"><A HREF="#htoc87">Chapter 7  Debugging</A>
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc90">Appendix C  Acknowledgements</A>
|
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||||
</LI><LI CLASS="li-toc"><A HREF="#htoc91">Appendix D  Copyright Information</A>
|
<A HREF="#htoc88">7.1  Log Files</A>
|
||||||
|
</LI><LI CLASS="li-toc"><A HREF="#htoc89">7.2  Debug Console</A>
|
||||||
|
</LI><LI CLASS="li-toc"><A HREF="#htoc90">7.3  Watchdog Alerts</A>
|
||||||
|
</LI></UL>
|
||||||
|
</LI><LI CLASS="li-toc"><A HREF="#htoc91">Appendix A  Internationalization and Localization</A>
|
||||||
|
</LI><LI CLASS="li-toc"><A HREF="#htoc92">Appendix B  Release Notes</A>
|
||||||
|
</LI><LI CLASS="li-toc"><A HREF="#htoc93">Appendix C  Acknowledgements</A>
|
||||||
|
</LI><LI CLASS="li-toc"><A HREF="#htoc94">Appendix D  Copyright Information</A>
|
||||||
</LI></UL><!--TOC chapter Introduction-->
|
</LI></UL><!--TOC chapter Introduction-->
|
||||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc1">Chapter 1</A>  Introduction</H1><!--SEC END --><P>
|
<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-->
|
<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-->
|
||||||
@ -795,7 +800,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 5269 listens for s2s connections with STARTTLS. The socket is set for IPv6 instead of IPv4.
|
||||||
</LI><LI CLASS="li-itemize">Port 5280 listens for HTTP requests, and serves the HTTP Poll service.
|
</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, and serves the Web Admin using HTTPS as explained in
|
||||||
section <A HREF="#webadmin">4.2</A>. The socket only listens connections to the IP address 127.0.0.1.
|
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"]}.
|
</LI></UL><PRE CLASS="verbatim">{hosts, ["example.com", "example.org", "example.net"]}.
|
||||||
{listen,
|
{listen,
|
||||||
[
|
[
|
||||||
@ -839,7 +844,7 @@ only two servers can connect: "jabber.example.org" and "example.com".
|
|||||||
</LI><LI CLASS="li-itemize">Port 5280 is serving the Web Admin and the HTTP Polling service
|
</LI><LI CLASS="li-itemize">Port 5280 is serving the Web Admin and the HTTP Polling service
|
||||||
in all the IPv4 addresses. Note
|
in all the IPv4 addresses. Note
|
||||||
that it is also possible to serve them on different ports. The second
|
that it is also possible to serve them on different ports. The second
|
||||||
example in section <A HREF="#webadmin">4.2</A> shows how exactly this can be done.
|
example in section <A HREF="#webadmin">4.3</A> shows how exactly this can be done.
|
||||||
</LI><LI CLASS="li-itemize">All users except for the administrators have a traffic of limit
|
</LI><LI CLASS="li-itemize">All users except for the administrators have a traffic of limit
|
||||||
1,000 Bytes/second
|
1,000 Bytes/second
|
||||||
</LI><LI CLASS="li-itemize">The
|
</LI><LI CLASS="li-itemize">The
|
||||||
@ -2953,9 +2958,19 @@ The default value is <TT>true</TT>.
|
|||||||
the processing discipline for Software Version (<TT>jabber:iq:version</TT>) IQ queries (see section <A HREF="#modiqdiscoption">3.3.2</A>).
|
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-->
|
</DD></DL><P> <A NAME="manage"></A> </P><!--TOC chapter Managing an <TT>ejabberd</TT> Server-->
|
||||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc60">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>-->
|
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc60">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="htoc61">4.1</A>  <A HREF="#ejabberdctl"><TT>ejabberdctl</TT></A></H2><!--SEC END --><P> <A NAME="ejabberdctl"></A> </P><P> <A NAME="commands"></A> </P><!--TOC subsection Commands-->
|
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc61">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
|
||||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc62">4.1.1</A>  <A HREF="#commands">Commands</A></H3><!--SEC END --><P> <A NAME="commands"></A> </P><P>The <TT>ejabberdctl</TT> command line administration script allows to start, stop and perform
|
you can execute <TT>ejabberdctl commands</TT> (described in the next section, <A HREF="#ectl-commands">4.1.1</A>)
|
||||||
many other administrative tasks in a local or remote <TT>ejabberd</TT> server.</P><P>When <TT>ejabberdctl</TT> is executed without any parameter,
|
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
|
||||||
|
in a local or remote <TT>ejabberd</TT> server (by providing the argument <TT>--node NODENAME</TT>).</P><P>The <TT>ejabberdctl</TT> script can be configured in the file <TT>ejabberdctl.cfg</TT>.
|
||||||
|
This file includes detailed information about each configurable option. See section <A HREF="#erlangconfiguration">4.1.2</A>.</P><P>The <TT>ejabberdctl</TT> script returns a numerical status code.
|
||||||
|
Success is represented by <TT>0</TT>,
|
||||||
|
error is represented by <TT>1</TT>,
|
||||||
|
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="htoc62">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,
|
it displays the available options. If there isn’t an <TT>ejabberd</TT> server running,
|
||||||
the available parameters are:
|
the available parameters are:
|
||||||
</P><DL CLASS="description"><DT CLASS="dt-description">
|
</P><DL CLASS="description"><DT CLASS="dt-description">
|
||||||
@ -2963,45 +2978,34 @@ the available parameters are:
|
|||||||
</DD><DT CLASS="dt-description"><B><TT>debug</TT></B></DT><DD CLASS="dd-description"> Attach an Erlang shell to an already existing <TT>ejabberd</TT> server. This allows to execute commands interactively in the <TT>ejabberd</TT> server.
|
</DD><DT CLASS="dt-description"><B><TT>debug</TT></B></DT><DD CLASS="dd-description"> Attach an Erlang shell to an already existing <TT>ejabberd</TT> server. This allows to execute commands interactively in the <TT>ejabberd</TT> server.
|
||||||
</DD><DT CLASS="dt-description"><B><TT>live</TT></B></DT><DD CLASS="dd-description"> Start <TT>ejabberd</TT> in live mode: the shell keeps attached to the started server, showing log messages and allowing to execute interactive commands.
|
</DD><DT CLASS="dt-description"><B><TT>live</TT></B></DT><DD CLASS="dd-description"> Start <TT>ejabberd</TT> in live mode: the shell keeps attached to the started server, showing log messages and allowing to execute interactive commands.
|
||||||
</DD></DL><P>If there is an <TT>ejabberd</TT> server running in the system,
|
</DD></DL><P>If there is an <TT>ejabberd</TT> server running in the system,
|
||||||
<TT>ejabberdctl</TT> shows all the available commands in that server.
|
<TT>ejabberdctl</TT> shows the <TT>ejabberdctl commands</TT> described bellow
|
||||||
The more interesting ones are:
|
and all the <TT>ejabberd commands</TT> available in that server (see <A HREF="#list-eja-commands">4.2.1</A>).</P><P>The <TT>ejabberdctl commands</TT> are:
|
||||||
</P><DL CLASS="description"><DT CLASS="dt-description">
|
</P><DL CLASS="description"><DT CLASS="dt-description">
|
||||||
<B><TT>help</TT></B></DT><DD CLASS="dd-description"> Get help about ejabberdctl or any available command. Try <TT>ejabberdctl help help</TT>.
|
<B><TT>help</TT></B></DT><DD CLASS="dd-description"> Get help about ejabberdctl or any available command. Try <TT>ejabberdctl help help</TT>.
|
||||||
</DD><DT CLASS="dt-description"><B><TT>status</TT></B></DT><DD CLASS="dd-description"> Check the status of the <TT>ejabberd</TT> server.
|
</DD><DT CLASS="dt-description"><B><TT>status</TT></B></DT><DD CLASS="dd-description"> Check the status of the <TT>ejabberd</TT> server.
|
||||||
</DD><DT CLASS="dt-description"><B><TT>stop</TT></B></DT><DD CLASS="dd-description"> Stop the <TT>ejabberd</TT> server which is running in the machine.
|
</DD><DT CLASS="dt-description"><B><TT>stop</TT></B></DT><DD CLASS="dd-description"> Stop the <TT>ejabberd</TT> server.
|
||||||
</DD><DT CLASS="dt-description"><B><TT>reopen-log</TT></B></DT><DD CLASS="dd-description"> Reopen the log files after they were renamed.
|
</DD><DT CLASS="dt-description"><B><TT>restart</TT></B></DT><DD CLASS="dd-description"> Restart the <TT>ejabberd</TT> server.
|
||||||
If the old files were not renamed before calling this command,
|
</DD><DT CLASS="dt-description"><B><TT>mnesia</TT></B></DT><DD CLASS="dd-description"> Get information about the Mnesia database.
|
||||||
they are automatically renamed to <TT>"*-old.log"</TT>. See section <A HREF="#logfiles">7.1</A>.
|
</DD></DL><P>The <TT>ejabberdctl</TT> script can be restricted to require authentication
|
||||||
</DD><DT CLASS="dt-description"><B><TT>backup ejabberd.backup</TT></B></DT><DD CLASS="dd-description">
|
and execute some <TT>ejabberd commands</TT>; see <A HREF="#accesscommands">4.2.2</A>.
|
||||||
Store internal Mnesia database to a binary backup file.
|
Add the option to the file <TT>ejabberd.cfg</TT>.
|
||||||
</DD><DT CLASS="dt-description"><B><TT>restore ejabberd.backup</TT></B></DT><DD CLASS="dd-description">
|
In this example there is no restriction:
|
||||||
Restore immediately from a binary backup file the internal Mnesia database.
|
</P><PRE CLASS="verbatim">{ejabberdctl_access_commands, []}.
|
||||||
This will consume quite some memory for big servers.
|
</PRE><P>If account <TT>robot1@example.org</TT> is registered in <TT>ejabberd</TT> with password <TT>abcdef</TT>
|
||||||
</DD><DT CLASS="dt-description"><B><TT>install-fallback ejabberd.backup</TT></B></DT><DD CLASS="dd-description">
|
(which MD5 is E8B501798950FC58AAD83C8C14978E),
|
||||||
The binary backup file is installed as fallback:
|
and <TT>ejabberd.cfg</TT> contains this setting:
|
||||||
it will be used to restore the database at the next ejabberd start.
|
</P><PRE CLASS="verbatim">{hosts, ["example.org"]}.
|
||||||
Similar to <TT>restore</TT>, but requires less memory.
|
{acl, bots, {user, "robot1", "example.org"}}.
|
||||||
</DD><DT CLASS="dt-description"><B><TT>dump ejabberd.dump</TT></B></DT><DD CLASS="dd-description">
|
{access, ctlaccess, [{allow, bots}]}.
|
||||||
Dump internal Mnesia database to a text file dump.
|
{ejabberdctl_access_commands, [ {ctlaccess, [registered_users, register], []} ]}.
|
||||||
</DD><DT CLASS="dt-description"><B><TT>load ejabberd.dump</TT></B></DT><DD CLASS="dd-description">
|
</PRE><P>then you can do this in the shell:
|
||||||
Restore immediately from a text file dump.
|
</P><PRE CLASS="verbatim">$ ejabberdctl registered_users example.org
|
||||||
This is not recommended for big databases, as it will consume much time,
|
Error: no_auth_provided
|
||||||
memory and processor. In that case it’s preferable to use <TT>backup</TT> and <TT>install-fallback</TT>.
|
$ ejabberdctl --auth robot1 example.org E8B501798950FC58AAD83C8C14978E registered_users example.org
|
||||||
</DD><DT CLASS="dt-description"><B><TT>import-file, import-dir</TT></B></DT><DD CLASS="dd-description">
|
robot1
|
||||||
These options can be used to migrate from other Jabber/XMPP servers. There
|
testuser1
|
||||||
exist tutorials to <A HREF="http://www.ejabberd.im/migrate-to-ejabberd">migrate from other software to ejabberd</A>.
|
testuser2
|
||||||
</DD><DT CLASS="dt-description"><B><TT>delete-expired-messages</TT></B></DT><DD CLASS="dd-description"> This option can be used to delete old messages
|
</PRE><P> <A NAME="erlangconfiguration"></A> </P><!--TOC subsection Erlang Runtime System-->
|
||||||
in offline storage. This might be useful when the number of offline messages
|
|
||||||
is very high.
|
|
||||||
</DD></DL><P>The <TT>ejabberdctl</TT> script also allows the argument <TT>--node NODENAME</TT>.
|
|
||||||
This allows to administer a remote node.</P><P>The <TT>ejabberdctl</TT> script can be configured in the file <TT>ejabberdctl.cfg</TT>.
|
|
||||||
This file includes detailed information about each configurable option.</P><P>The <TT>ejabberdctl</TT> script returns a numerical status code.
|
|
||||||
Success is represented by <TT>0</TT>,
|
|
||||||
error is represented by <TT>1</TT>,
|
|
||||||
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="erlangconfiguration"></A> </P><!--TOC subsection Erlang Runtime System-->
|
|
||||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc63">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="htoc63">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.
|
This system is configured using environment variables and command line parameters.
|
||||||
The <TT>ejabberdctl</TT> administration script uses many of those possibilities.
|
The <TT>ejabberdctl</TT> administration script uses many of those possibilities.
|
||||||
@ -3070,8 +3074,102 @@ Starts the Erlang system detached from the system console.
|
|||||||
Open an Erlang shell in a remote Erlang node.
|
Open an Erlang shell in a remote Erlang node.
|
||||||
</DD></DL><P>
|
</DD></DL><P>
|
||||||
Note that some characters need to be escaped when used in shell scripts, for instance <CODE>"</CODE> and <CODE>{}</CODE>.
|
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="webadmin"></A> </P><!--TOC section Web Admin-->
|
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="htoc64">4.2</A>  <A HREF="#webadmin">Web Admin</A></H2><!--SEC END --><P> <A NAME="webadmin"></A>
|
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc64">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>.
|
||||||
|
Other known frontends that can be installed to execute ejabberd commands in different ways are:
|
||||||
|
<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="htoc65">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
|
||||||
|
Usage: ejabberdctl [--node nodename] [--auth user host password] command [options]
|
||||||
|
|
||||||
|
Available commands in this ejabberd node:
|
||||||
|
backup file Store the database to backup file
|
||||||
|
connected_users List all established sessions
|
||||||
|
connected_users_number Get the number of established sessions
|
||||||
|
delete_expired_messages Delete expired offline messages from database
|
||||||
|
delete_old_messages days Delete offline messages older than DAYS
|
||||||
|
...
|
||||||
|
</PRE><P>The more interesting ones are:
|
||||||
|
</P><DL CLASS="description"><DT CLASS="dt-description">
|
||||||
|
<B><TT>reopen-log</TT></B></DT><DD CLASS="dd-description"> Reopen the log files after they were renamed.
|
||||||
|
If the old files were not renamed before calling this command,
|
||||||
|
they are automatically renamed to <TT>"*-old.log"</TT>. See section <A HREF="#logfiles">7.1</A>.
|
||||||
|
</DD><DT CLASS="dt-description"><B><TT>backup ejabberd.backup</TT></B></DT><DD CLASS="dd-description">
|
||||||
|
Store internal Mnesia database to a binary backup file.
|
||||||
|
</DD><DT CLASS="dt-description"><B><TT>restore ejabberd.backup</TT></B></DT><DD CLASS="dd-description">
|
||||||
|
Restore immediately from a binary backup file the internal Mnesia database.
|
||||||
|
This will consume quite some memory for big servers.
|
||||||
|
</DD><DT CLASS="dt-description"><B><TT>install-fallback ejabberd.backup</TT></B></DT><DD CLASS="dd-description">
|
||||||
|
The binary backup file is installed as fallback:
|
||||||
|
it will be used to restore the database at the next ejabberd start.
|
||||||
|
Similar to <TT>restore</TT>, but requires less memory.
|
||||||
|
</DD><DT CLASS="dt-description"><B><TT>dump ejabberd.dump</TT></B></DT><DD CLASS="dd-description">
|
||||||
|
Dump internal Mnesia database to a text file dump.
|
||||||
|
</DD><DT CLASS="dt-description"><B><TT>load ejabberd.dump</TT></B></DT><DD CLASS="dd-description">
|
||||||
|
Restore immediately from a text file dump.
|
||||||
|
This is not recommended for big databases, as it will consume much time,
|
||||||
|
memory and processor. In that case it’s preferable to use <TT>backup</TT> and <TT>install-fallback</TT>.
|
||||||
|
</DD><DT CLASS="dt-description"><B><TT>import-file, import-dir</TT></B></DT><DD CLASS="dd-description">
|
||||||
|
These options can be used to migrate from other Jabber/XMPP servers. There
|
||||||
|
exist tutorials to <A HREF="http://www.ejabberd.im/migrate-to-ejabberd">migrate from other software to ejabberd</A>.
|
||||||
|
</DD><DT CLASS="dt-description"><B><TT>delete-expired-messages</TT></B></DT><DD CLASS="dd-description"> This option can be used to delete old messages
|
||||||
|
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="htoc66">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:
|
||||||
|
</P><PRE CLASS="verbatim">AccessCommands = [ {Access, CommandNames, Arguments} ]
|
||||||
|
Access = atom()
|
||||||
|
CommandNames = all | [CommandName]
|
||||||
|
CommandName = atom()
|
||||||
|
Arguments = [{ArgumentName, ArgumentValue}]
|
||||||
|
ArgumentName = atom()
|
||||||
|
ArgumentValue = any()
|
||||||
|
</PRE><P>The default value is to not define any restriction: <TT>[]</TT>.
|
||||||
|
If at least one restriction is defined, then the frontend expects
|
||||||
|
that authentication information is provided when executing a command.
|
||||||
|
The authentication information is Username, Hostname and Password of a local Jabber account
|
||||||
|
that has permission to execute the corresponding command.
|
||||||
|
This means that the account must be registered in the local ejabberd,
|
||||||
|
because the information will be verified.
|
||||||
|
It is possible to provide the plaintext password or its MD5 sum.</P><P>When one or several access restrictions are defined and the
|
||||||
|
authentication information is provided,
|
||||||
|
each restriction is verified until one matches completely:
|
||||||
|
the account matches the Access rule,
|
||||||
|
the command name is listed in CommandNames,
|
||||||
|
and the provided arguments do not contradict Arguments.</P><P>As an example to understand the syntax, let’s suppose those options:
|
||||||
|
</P><PRE CLASS="verbatim">{hosts, ["example.org"]}.
|
||||||
|
{acl, bots, {user, "robot1", "example.org"}}.
|
||||||
|
{access, commaccess, [{allow, bots}]}.
|
||||||
|
</PRE><P>This list of access restrictions allows only <TT>robot1@example.org</TT> to execute all commands:
|
||||||
|
</P><PRE CLASS="verbatim">[{commaccess, all, []}]
|
||||||
|
</PRE><P>See another list of restrictions (the corresponding ACL and ACCESS are not shown):
|
||||||
|
</P><PRE CLASS="verbatim">[
|
||||||
|
%% This bot can execute all commands:
|
||||||
|
{bot, all, []},
|
||||||
|
%% This bot can only execute the command 'dump'. No argument restriction:
|
||||||
|
{bot_backups, [dump], []}
|
||||||
|
%% This bot can execute all commands,
|
||||||
|
%% but if a 'host' argument is provided, it must be "example.org":
|
||||||
|
{bot_all_example, all, [{host, "example.org"}]},
|
||||||
|
%% This bot can only execute the command 'register',
|
||||||
|
%% and if argument 'host' is provided, it must be "example.org":
|
||||||
|
{bot_reg_example, [register], [{host, "example.org"}]},
|
||||||
|
%% This bot can execute the commands 'register' and 'unregister',
|
||||||
|
%% if argument host is provided, it must be "test.org":
|
||||||
|
{_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="htoc67">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:
|
</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
|
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
|
section <A HREF="#listened">3.1.3</A>) is included in the listening ports. Then you can open
|
||||||
@ -3143,13 +3241,13 @@ The file is searched by default in
|
|||||||
The directory of the documentation can be specified in
|
The directory of the documentation can be specified in
|
||||||
the environment variable <TT>EJABBERD_DOC_PATH</TT>.
|
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-->
|
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="htoc65">4.3</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="htoc68">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>
|
you can perform several administrative tasks in <TT>ejabberd</TT>
|
||||||
with a Jabber client.
|
with a Jabber client.
|
||||||
The client must support Ad-Hoc Commands (<A HREF="http://www.xmpp.org/extensions/xep-0050.html">XEP-0050</A>),
|
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
|
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-->
|
an account with proper privileges.</P><P> <A NAME="changeerlangnodename"></A> </P><!--TOC section Change Computer Hostname-->
|
||||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc66">4.4</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="htoc69">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,
|
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>).
|
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.
|
The name of an Erlang node includes the hostname of the computer.
|
||||||
@ -3165,8 +3263,8 @@ you must follow these instructions:
|
|||||||
For example:
|
For example:
|
||||||
<PRE CLASS="verbatim">ejabberdctl restore /tmp/ejabberd-oldhost.backup
|
<PRE CLASS="verbatim">ejabberdctl restore /tmp/ejabberd-oldhost.backup
|
||||||
</PRE></LI></OL><P> <A NAME="secure"></A> </P><!--TOC chapter Securing <TT>ejabberd</TT>-->
|
</PRE></LI></OL><P> <A NAME="secure"></A> </P><!--TOC chapter Securing <TT>ejabberd</TT>-->
|
||||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc67">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-->
|
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc70">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="htoc68">5.1</A>  <A HREF="#firewall">Firewall Settings</A></H2><!--SEC END --><P> <A NAME="firewall"></A>
|
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc71">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><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>
|
</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>
|
<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>
|
||||||
@ -3177,7 +3275,7 @@ you must follow these instructions:
|
|||||||
<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>
|
<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>
|
</TABLE>
|
||||||
<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></DIV></BLOCKQUOTE><P> <A NAME="epmd"></A> </P><!--TOC section epmd-->
|
<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="htoc69">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="htoc72">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
|
is a small name server included in Erlang/OTP
|
||||||
and used by Erlang programs when establishing distributed Erlang communications.
|
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.
|
<TT>ejabberd</TT> needs <TT>epmd</TT> to use <TT>ejabberdctl</TT> and also when clustering <TT>ejabberd</TT> nodes.
|
||||||
@ -3202,7 +3300,7 @@ but can be configured in the file <TT>ejabberdctl.cfg</TT>.
|
|||||||
The Erlang command-line parameter used internally is, for example:
|
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
|
</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-->
|
</PRE><P> <A NAME="cookie"></A> </P><!--TOC section Erlang Cookie-->
|
||||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc70">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="htoc73">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>.
|
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 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.
|
If this file does not exist, it is created immediately with a random cookie.
|
||||||
@ -3216,7 +3314,7 @@ to prevent unauthorized access or intrusion to an Erlang node.
|
|||||||
The communication between Erlang nodes are not encrypted,
|
The communication between Erlang nodes are not encrypted,
|
||||||
so the cookie could be read sniffing the traffic on the network.
|
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-->
|
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="htoc71">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="htoc74">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>)
|
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>).
|
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
|
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
|
||||||
@ -3225,7 +3323,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
|
because it may be possible to fake the fact that you are on another network
|
||||||
using a modified version of Erlang <TT>epmd</TT>.
|
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-->
|
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="htoc72">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="htoc75">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,
|
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">
|
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">
|
<B><TT>ejabberd configuration file: /etc/ejabberd/ejabberd.cfg</TT></B></DT><DD CLASS="dd-description">
|
||||||
@ -3245,9 +3343,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">
|
</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>.
|
See section <A HREF="#cookie">5.3</A>.
|
||||||
</DD></DL><P> <A NAME="clustering"></A> </P><!--TOC chapter Clustering-->
|
</DD></DL><P> <A NAME="clustering"></A> </P><!--TOC chapter Clustering-->
|
||||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc73">Chapter 6</A>  <A HREF="#clustering">Clustering</A></H1><!--SEC END --><P> <A NAME="clustering"></A>
|
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc76">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-->
|
</P><P> <A NAME="howitworks"></A> </P><!--TOC section How it Works-->
|
||||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc74">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="htoc77">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
|
</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
|
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
|
must have the ability to connect to port 4369 of all another nodes, and must
|
||||||
@ -3261,29 +3359,29 @@ router,
|
|||||||
</LI><LI CLASS="li-itemize">session manager,
|
</LI><LI CLASS="li-itemize">session manager,
|
||||||
</LI><LI CLASS="li-itemize">s2s manager.
|
</LI><LI CLASS="li-itemize">s2s manager.
|
||||||
</LI></UL><P> <A NAME="router"></A> </P><!--TOC subsection Router-->
|
</LI></UL><P> <A NAME="router"></A> </P><!--TOC subsection Router-->
|
||||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc75">6.1.1</A>  <A HREF="#router">Router</A></H3><!--SEC END --><P> <A NAME="router"></A>
|
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc78">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
|
</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
|
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. The domain of the packet’s destination is searched in the
|
||||||
routing table, and if it is found, the packet is routed to 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-->
|
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="htoc76">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="htoc79">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
|
</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
|
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
|
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-->
|
on its content.</P><P> <A NAME="sessionmanager"></A> </P><!--TOC subsection Session Manager-->
|
||||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc77">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="htoc80">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
|
</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
|
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
|
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-->
|
storage, or bounced back.</P><P> <A NAME="s2smanager"></A> </P><!--TOC subsection s2s Manager-->
|
||||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc78">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="htoc81">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
|
</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
|
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,
|
source to the domain of the packet’s destination exists. If that is the case,
|
||||||
the s2s manager routes the packet to the process
|
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-->
|
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="htoc79">6.2</A>  <A HREF="#cluster">Clustering Setup</A></H2><!--SEC END --><P> <A NAME="cluster"></A>
|
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc82">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>),
|
</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
|
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">
|
following steps:</P><OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
|
||||||
@ -3321,10 +3419,10 @@ and ‘<CODE>access</CODE>’ options because they will be taken from
|
|||||||
enabled only on one machine in the cluster.
|
enabled only on one machine in the cluster.
|
||||||
</LI></OL><P>You can repeat these steps for other machines supposed to serve this
|
</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-->
|
domain.</P><P> <A NAME="servicelb"></A> </P><!--TOC section Service Load-Balancing-->
|
||||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc80">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="htoc83">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-->
|
</P><P> <A NAME="componentlb"></A> </P><!--TOC subsection Components Load-Balancing-->
|
||||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc81">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="htoc84">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="htoc82">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="htoc85">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>}.
|
</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:
|
</PRE><P>Several balancing criteria are available:
|
||||||
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
|
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
|
||||||
@ -3333,13 +3431,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_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><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-->
|
</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="htoc83">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="htoc86">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><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}
|
</P><PRE CLASS="verbatim">{domain_balancing_component_number, "component.example.com", N}
|
||||||
</PRE><P> <A NAME="debugging"></A> </P><!--TOC chapter Debugging-->
|
</PRE><P> <A NAME="debugging"></A> </P><!--TOC chapter Debugging-->
|
||||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc84">Chapter 7</A>  <A HREF="#debugging">Debugging</A></H1><!--SEC END --><P> <A NAME="debugging"></A>
|
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc87">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-->
|
</P><P> <A NAME="logfiles"></A> </P><!--TOC section Log Files-->
|
||||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc85">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="htoc88">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">
|
</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
|
<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)
|
</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)
|
||||||
@ -3357,16 +3455,16 @@ For example, the default configuration is:
|
|||||||
</P><PRE CLASS="verbatim">{loglevel, 4}.
|
</P><PRE CLASS="verbatim">{loglevel, 4}.
|
||||||
</PRE><P>The log files grow continually, so it is recommended to rotate them periodically.
|
</PRE><P>The log files grow continually, so it is recommended to rotate them periodically.
|
||||||
To rotate the log files, rename the files and then reopen them.
|
To rotate the log files, rename the files and then reopen them.
|
||||||
The ejabberd command <TT>reopen-log</TT>
|
The ejabberdctl command <TT>reopen-log</TT>
|
||||||
(please refer to section <A HREF="#commands">4.1.1</A>)
|
(please refer to section <A HREF="#ectl-commands">4.1.1</A>)
|
||||||
reopens the log files,
|
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-->
|
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="htoc86">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="htoc89">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,
|
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.
|
so it is important to use it with extremely care.
|
||||||
There are some simple and safe examples in the article
|
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-->
|
<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="htoc87">7.3</A>  <A HREF="#watchdog">Watchdog Alerts</A></H2><!--SEC END --><P> <A NAME="watchdog"></A>
|
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc90">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
|
</P><P><TT>ejabberd</TT> includes a watchdog mechanism that may be useful to developers
|
||||||
when troubleshooting a problem related to memory usage.
|
when troubleshooting a problem related to memory usage.
|
||||||
If a process in the <TT>ejabberd</TT> server consumes more memory than the configured threshold,
|
If a process in the <TT>ejabberd</TT> server consumes more memory than the configured threshold,
|
||||||
@ -3384,7 +3482,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:
|
To remove all watchdog admins, set the option with an empty list:
|
||||||
</P><PRE CLASS="verbatim">{watchdog_admins, []}.
|
</P><PRE CLASS="verbatim">{watchdog_admins, []}.
|
||||||
</PRE><P> <A NAME="i18ni10n"></A> </P><!--TOC chapter Internationalization and Localization-->
|
</PRE><P> <A NAME="i18ni10n"></A> </P><!--TOC chapter Internationalization and Localization-->
|
||||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc88">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="htoc91">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.
|
</P><P>The source code of <TT>ejabberd</TT> supports localization.
|
||||||
The translators can edit the
|
The translators can edit the
|
||||||
<A HREF="http://www.gnu.org/software/gettext/">gettext</A> .po files
|
<A HREF="http://www.gnu.org/software/gettext/">gettext</A> .po files
|
||||||
@ -3419,9 +3517,9 @@ HTTP header ‘Accept-Language: ru’</TD></TR>
|
|||||||
</TABLE></DIV>
|
</TABLE></DIV>
|
||||||
<A NAME="fig:webadmmainru"></A>
|
<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-->
|
<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="htoc89">Appendix B</A>  <A HREF="#releasenotes">Release Notes</A></H1><!--SEC END --><P> <A NAME="releasenotes"></A>
|
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc92">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-->
|
</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="htoc90">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="htoc93">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">
|
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
|
||||||
Alexey Shchepin (<A HREF="xmpp:aleksey@jabber.ru"><TT>xmpp:aleksey@jabber.ru</TT></A>)
|
Alexey Shchepin (<A HREF="xmpp:aleksey@jabber.ru"><TT>xmpp:aleksey@jabber.ru</TT></A>)
|
||||||
</LI><LI CLASS="li-itemize">Badlop (<A HREF="xmpp:badlop@jabberes.org"><TT>xmpp:badlop@jabberes.org</TT></A>)
|
</LI><LI CLASS="li-itemize">Badlop (<A HREF="xmpp:badlop@jabberes.org"><TT>xmpp:badlop@jabberes.org</TT></A>)
|
||||||
@ -3433,7 +3531,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">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><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-->
|
</LI></UL><P> <A NAME="copyright"></A> </P><!--TOC chapter Copyright Information-->
|
||||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc91">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="htoc94">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
|
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
|
modify it under the terms of the GNU General Public License
|
||||||
as published by the Free Software Foundation; either version 2
|
as published by the Free Software Foundation; either version 2
|
||||||
|
222
doc/guide.tex
222
doc/guide.tex
@ -3809,10 +3809,24 @@ Options:
|
|||||||
|
|
||||||
\makesection{ejabberdctl}{\term{ejabberdctl}}
|
\makesection{ejabberdctl}{\term{ejabberdctl}}
|
||||||
|
|
||||||
\makesubsection{commands}{Commands}
|
With the \term{ejabberdctl} command line administration script
|
||||||
|
you can execute \term{ejabberdctl commands} (described in the next section, \ref{ectl-commands})
|
||||||
|
and also many general \term{ejabberd commands} (described in section \ref{eja-commands}).
|
||||||
|
This means you can start, stop and perform many other administrative tasks
|
||||||
|
in a local or remote \ejabberd{} server (by providing the argument \term{--node NODENAME}).
|
||||||
|
|
||||||
The \term{ejabberdctl} command line administration script allows to start, stop and perform
|
The \term{ejabberdctl} script can be configured in the file \term{ejabberdctl.cfg}.
|
||||||
many other administrative tasks in a local or remote \ejabberd{} server.
|
This file includes detailed information about each configurable option. See section \ref{erlangconfiguration}.
|
||||||
|
|
||||||
|
The \term{ejabberdctl} script returns a numerical status code.
|
||||||
|
Success is represented by \term{0},
|
||||||
|
error is represented by \term{1},
|
||||||
|
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: \term{echo \$?}
|
||||||
|
|
||||||
|
\makesubsection{ectl-commands}{ejabberdctl Commands}
|
||||||
|
|
||||||
When \term{ejabberdctl} is executed without any parameter,
|
When \term{ejabberdctl} is executed without any parameter,
|
||||||
it displays the available options. If there isn't an \ejabberd{} server running,
|
it displays the available options. If there isn't an \ejabberd{} server running,
|
||||||
@ -3824,53 +3838,44 @@ the available parameters are:
|
|||||||
\end{description}
|
\end{description}
|
||||||
|
|
||||||
If there is an \ejabberd{} server running in the system,
|
If there is an \ejabberd{} server running in the system,
|
||||||
\term{ejabberdctl} shows all the available commands in that server.
|
\term{ejabberdctl} shows the \term{ejabberdctl commands} described bellow
|
||||||
The more interesting ones are:
|
and all the \term{ejabberd commands} available in that server (see \ref{list-eja-commands}).
|
||||||
|
|
||||||
|
The \term{ejabberdctl commands} are:
|
||||||
\begin{description}
|
\begin{description}
|
||||||
\titem{help} Get help about ejabberdctl or any available command. Try \term{ejabberdctl help help}.
|
\titem{help} Get help about ejabberdctl or any available command. Try \term{ejabberdctl help help}.
|
||||||
\titem{status} Check the status of the \ejabberd{} server.
|
\titem{status} Check the status of the \ejabberd{} server.
|
||||||
\titem{stop} Stop the \ejabberd{} server which is running in the machine.
|
\titem{stop} Stop the \ejabberd{} server.
|
||||||
\titem{reopen-log} Reopen the log files after they were renamed.
|
\titem{restart} Restart the \ejabberd{} server.
|
||||||
If the old files were not renamed before calling this command,
|
\titem{mnesia} Get information about the Mnesia database.
|
||||||
they are automatically renamed to \term{"*-old.log"}. See section \ref{logfiles}.
|
|
||||||
\titem {backup ejabberd.backup}
|
|
||||||
Store internal Mnesia database to a binary backup file.
|
|
||||||
\titem {restore ejabberd.backup}
|
|
||||||
Restore immediately from a binary backup file the internal Mnesia database.
|
|
||||||
This will consume quite some memory for big servers.
|
|
||||||
\titem {install-fallback ejabberd.backup}
|
|
||||||
The binary backup file is installed as fallback:
|
|
||||||
it will be used to restore the database at the next ejabberd start.
|
|
||||||
Similar to \term{restore}, but requires less memory.
|
|
||||||
\titem {dump ejabberd.dump}
|
|
||||||
Dump internal Mnesia database to a text file dump.
|
|
||||||
\titem {load ejabberd.dump}
|
|
||||||
Restore immediately from a text file dump.
|
|
||||||
This is not recommended for big databases, as it will consume much time,
|
|
||||||
memory and processor. In that case it's preferable to use \term{backup} and \term{install-fallback}.
|
|
||||||
%%More information about backuping can
|
|
||||||
%% be found in section~\ref{backup}.
|
|
||||||
\titem{import-file, import-dir} \ind{migration from other software}
|
|
||||||
These options can be used to migrate from other \Jabber{}/XMPP servers. There
|
|
||||||
exist tutorials to \footahref{http://www.ejabberd.im/migrate-to-ejabberd}{migrate from other software to ejabberd}.
|
|
||||||
\titem{delete-expired-messages} This option can be used to delete old messages
|
|
||||||
in offline storage. This might be useful when the number of offline messages
|
|
||||||
is very high.
|
|
||||||
\end{description}
|
\end{description}
|
||||||
|
|
||||||
The \term{ejabberdctl} script also allows the argument \term{--node NODENAME}.
|
The \term{ejabberdctl} script can be restricted to require authentication
|
||||||
This allows to administer a remote node.
|
and execute some \term{ejabberd commands}; see \ref{accesscommands}.
|
||||||
|
Add the option to the file \term{ejabberd.cfg}.
|
||||||
|
In this example there is no restriction:
|
||||||
|
\begin{verbatim}
|
||||||
|
{ejabberdctl_access_commands, []}.
|
||||||
|
\end{verbatim}
|
||||||
|
|
||||||
The \term{ejabberdctl} script can be configured in the file \term{ejabberdctl.cfg}.
|
If account \term{robot1@example.org} is registered in \ejabberd{} with password \term{abcdef}
|
||||||
This file includes detailed information about each configurable option.
|
(which MD5 is E8B501798950FC58AAD83C8C14978E),
|
||||||
|
and \term{ejabberd.cfg} contains this setting:
|
||||||
The \term{ejabberdctl} script returns a numerical status code.
|
\begin{verbatim}
|
||||||
Success is represented by \term{0},
|
{hosts, ["example.org"]}.
|
||||||
error is represented by \term{1},
|
{acl, bots, {user, "robot1", "example.org"}}.
|
||||||
and other codes may be used for specific results.
|
{access, ctlaccess, [{allow, bots}]}.
|
||||||
This can be used by other scripts to determine automatically
|
{ejabberdctl_access_commands, [ {ctlaccess, [registered_users, register], []} ]}.
|
||||||
if a command succeeded or failed,
|
\end{verbatim}
|
||||||
for example using: \term{echo \$?}
|
then you can do this in the shell:
|
||||||
|
\begin{verbatim}
|
||||||
|
$ ejabberdctl registered_users example.org
|
||||||
|
Error: no_auth_provided
|
||||||
|
$ ejabberdctl --auth robot1 example.org E8B501798950FC58AAD83C8C14978E registered_users example.org
|
||||||
|
robot1
|
||||||
|
testuser1
|
||||||
|
testuser2
|
||||||
|
\end{verbatim}
|
||||||
|
|
||||||
|
|
||||||
\makesubsection{erlangconfiguration}{Erlang Runtime System}
|
\makesubsection{erlangconfiguration}{Erlang Runtime System}
|
||||||
@ -3949,6 +3954,131 @@ The command line parameters:
|
|||||||
Note that some characters need to be escaped when used in shell scripts, for instance \verb|"| and \verb|{}|.
|
Note that some characters need to be escaped when used in shell scripts, for instance \verb|"| and \verb|{}|.
|
||||||
You can find other options in the Erlang manual page (\shell{erl -man erl}).
|
You can find other options in the Erlang manual page (\shell{erl -man erl}).
|
||||||
|
|
||||||
|
\makesection{eja-commands}{\ejabberd{} Commands}
|
||||||
|
|
||||||
|
An \term{ejabberd command} 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 \term{ejabberd\_commands} service.
|
||||||
|
Those commands can be defined in any Erlang module and executed using any valid frontend.
|
||||||
|
|
||||||
|
\ejabberd{} includes a frontend to execute \term{ejabberd commands}: the script \term{ejabberdctl}.
|
||||||
|
Other known frontends that can be installed to execute ejabberd commands in different ways are:
|
||||||
|
\term{ejabberd\_xmlrpc} (XML-RPC service),
|
||||||
|
\term{mod\_rest} (HTTP POST service),
|
||||||
|
\term{mod\_shcommands} (ejabberd WebAdmin page).
|
||||||
|
|
||||||
|
\makesubsection{list-eja-commands}{List of ejabberd Commands}
|
||||||
|
|
||||||
|
\ejabberd{} includes a few ejabberd Commands by default.
|
||||||
|
When more modules are installed, new commands may be available in the frontends.
|
||||||
|
|
||||||
|
The easiest way to get a list of the available commands, and get help for them is to use
|
||||||
|
the ejabberdctl script:
|
||||||
|
\begin{verbatim}
|
||||||
|
$ ejabberdctl help
|
||||||
|
Usage: ejabberdctl [--node nodename] [--auth user host password] command [options]
|
||||||
|
|
||||||
|
Available commands in this ejabberd node:
|
||||||
|
backup file Store the database to backup file
|
||||||
|
connected_users List all established sessions
|
||||||
|
connected_users_number Get the number of established sessions
|
||||||
|
delete_expired_messages Delete expired offline messages from database
|
||||||
|
delete_old_messages days Delete offline messages older than DAYS
|
||||||
|
...
|
||||||
|
\end{verbatim}
|
||||||
|
|
||||||
|
The more interesting ones are:
|
||||||
|
\begin{description}
|
||||||
|
\titem{reopen-log} Reopen the log files after they were renamed.
|
||||||
|
If the old files were not renamed before calling this command,
|
||||||
|
they are automatically renamed to \term{"*-old.log"}. See section \ref{logfiles}.
|
||||||
|
\titem {backup ejabberd.backup}
|
||||||
|
Store internal Mnesia database to a binary backup file.
|
||||||
|
\titem {restore ejabberd.backup}
|
||||||
|
Restore immediately from a binary backup file the internal Mnesia database.
|
||||||
|
This will consume quite some memory for big servers.
|
||||||
|
\titem {install-fallback ejabberd.backup}
|
||||||
|
The binary backup file is installed as fallback:
|
||||||
|
it will be used to restore the database at the next ejabberd start.
|
||||||
|
Similar to \term{restore}, but requires less memory.
|
||||||
|
\titem {dump ejabberd.dump}
|
||||||
|
Dump internal Mnesia database to a text file dump.
|
||||||
|
\titem {load ejabberd.dump}
|
||||||
|
Restore immediately from a text file dump.
|
||||||
|
This is not recommended for big databases, as it will consume much time,
|
||||||
|
memory and processor. In that case it's preferable to use \term{backup} and \term{install-fallback}.
|
||||||
|
%%More information about backuping can
|
||||||
|
%% be found in section~\ref{backup}.
|
||||||
|
\titem{import-file, import-dir} \ind{migration from other software}
|
||||||
|
These options can be used to migrate from other \Jabber{}/XMPP servers. There
|
||||||
|
exist tutorials to \footahref{http://www.ejabberd.im/migrate-to-ejabberd}{migrate from other software to ejabberd}.
|
||||||
|
\titem{delete-expired-messages} This option can be used to delete old messages
|
||||||
|
in offline storage. This might be useful when the number of offline messages
|
||||||
|
is very high.
|
||||||
|
\end{description}
|
||||||
|
|
||||||
|
\makesubsection{accesscommands}{Restrict Execution with AccessCommands}
|
||||||
|
|
||||||
|
The frontends can be configured to restrict access to certain commands.
|
||||||
|
In that case, authentication information must be provided.
|
||||||
|
In each frontend the \term{AccessCommands} option is defined
|
||||||
|
in a different place. But in all cases the option syntax is the same:
|
||||||
|
\begin{verbatim}
|
||||||
|
AccessCommands = [ {Access, CommandNames, Arguments} ]
|
||||||
|
Access = atom()
|
||||||
|
CommandNames = all | [CommandName]
|
||||||
|
CommandName = atom()
|
||||||
|
Arguments = [{ArgumentName, ArgumentValue}]
|
||||||
|
ArgumentName = atom()
|
||||||
|
ArgumentValue = any()
|
||||||
|
\end{verbatim}
|
||||||
|
|
||||||
|
The default value is to not define any restriction: \term{[]}.
|
||||||
|
If at least one restriction is defined, then the frontend expects
|
||||||
|
that authentication information is provided when executing a command.
|
||||||
|
The authentication information is Username, Hostname and Password of a local Jabber account
|
||||||
|
that has permission to execute the corresponding command.
|
||||||
|
This means that the account must be registered in the local ejabberd,
|
||||||
|
because the information will be verified.
|
||||||
|
It is possible to provide the plaintext password or its MD5 sum.
|
||||||
|
|
||||||
|
When one or several access restrictions are defined and the
|
||||||
|
authentication information is provided,
|
||||||
|
each restriction is verified until one matches completely:
|
||||||
|
the account matches the Access rule,
|
||||||
|
the command name is listed in CommandNames,
|
||||||
|
and the provided arguments do not contradict Arguments.
|
||||||
|
|
||||||
|
As an example to understand the syntax, let's suppose those options:
|
||||||
|
\begin{verbatim}
|
||||||
|
{hosts, ["example.org"]}.
|
||||||
|
{acl, bots, {user, "robot1", "example.org"}}.
|
||||||
|
{access, commaccess, [{allow, bots}]}.
|
||||||
|
\end{verbatim}
|
||||||
|
|
||||||
|
This list of access restrictions allows only \term{robot1@example.org} to execute all commands:
|
||||||
|
\begin{verbatim}
|
||||||
|
[{commaccess, all, []}]
|
||||||
|
\end{verbatim}
|
||||||
|
|
||||||
|
See another list of restrictions (the corresponding ACL and ACCESS are not shown):
|
||||||
|
\begin{verbatim}
|
||||||
|
[
|
||||||
|
%% This bot can execute all commands:
|
||||||
|
{bot, all, []},
|
||||||
|
%% This bot can only execute the command 'dump'. No argument restriction:
|
||||||
|
{bot_backups, [dump], []}
|
||||||
|
%% This bot can execute all commands,
|
||||||
|
%% but if a 'host' argument is provided, it must be "example.org":
|
||||||
|
{bot_all_example, all, [{host, "example.org"}]},
|
||||||
|
%% This bot can only execute the command 'register',
|
||||||
|
%% and if argument 'host' is provided, it must be "example.org":
|
||||||
|
{bot_reg_example, [register], [{host, "example.org"}]},
|
||||||
|
%% This bot can execute the commands 'register' and 'unregister',
|
||||||
|
%% if argument host is provided, it must be "test.org":
|
||||||
|
{_bot_reg_test, [register, unregister], [{host, "test.org"}]}
|
||||||
|
]
|
||||||
|
\end{verbatim}
|
||||||
|
|
||||||
\makesection{webadmin}{Web Admin}
|
\makesection{webadmin}{Web Admin}
|
||||||
\ind{web admin}
|
\ind{web admin}
|
||||||
@ -4408,8 +4538,8 @@ For example, the default configuration is:
|
|||||||
|
|
||||||
The log files grow continually, so it is recommended to rotate them periodically.
|
The log files grow continually, so it is recommended to rotate them periodically.
|
||||||
To rotate the log files, rename the files and then reopen them.
|
To rotate the log files, rename the files and then reopen them.
|
||||||
The ejabberd command \term{reopen-log}
|
The ejabberdctl command \term{reopen-log}
|
||||||
(please refer to section \ref{commands})
|
(please refer to section \ref{ectl-commands})
|
||||||
reopens the log files,
|
reopens the log files,
|
||||||
and also renames the old ones if you didn't rename them.
|
and also renames the old ones if you didn't rename them.
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user