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

* src/Makefile.in: Spool, config and log dirs: writtable by owner,

Browse Source 
readable by group, nothing by others (EJAB-686)
* doc/guide.tex: New section Securing sensible files
* doc/guide.html: Likewise

SVN Revision: 1413
This commit is contained in:
Badlop 2008-07-07 14:52:47 +00:00
parent 19a1ddfa44
commit 9626c41817
4 changed files with 105 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
ChangeLog
View File

@ -1,5 +1,10 @@
2008-07-07 Badlop <badlop@process-one.net>
* src/Makefile.in: Spool, config and log dirs: writtable by owner,
readable by group, nothing by others (EJAB-686)
* doc/guide.tex: New section Securing sensible files
* doc/guide.html: Likewise
* doc/guide.tex: Solaris Makefile install: use ginstall (thanks to
Jonathan Auer)(EJAB-649)
* doc/guide.html: Likewise

108
doc/guide.html
View File

@ -178,34 +178,35 @@ BLOCKQUOTE.figure DIV.center DIV.center HR{display:none;}
</LI><LI CLASS="li-toc"><A HREF="#htoc69">5.2&#XA0;&#XA0;epmd</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc70">5.3&#XA0;&#XA0;Erlang Cookie</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc71">5.4&#XA0;&#XA0;Erlang node name</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc72">5.5&#XA0;&#XA0;Securing sensible files</A>
</LI></UL>
</LI><LI CLASS="li-toc"><A HREF="#htoc72">Chapter&#XA0;6&#XA0;&#XA0;Clustering</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc73">Chapter&#XA0;6&#XA0;&#XA0;Clustering</A>
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc73">6.1&#XA0;&#XA0;How it Works</A>
<A HREF="#htoc74">6.1&#XA0;&#XA0;How it Works</A>
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc74">6.1.1&#XA0;&#XA0;Router</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc75">6.1.2&#XA0;&#XA0;Local Router</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc76">6.1.3&#XA0;&#XA0;Session Manager</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc77">6.1.4&#XA0;&#XA0;s2s Manager</A>
<A HREF="#htoc75">6.1.1&#XA0;&#XA0;Router</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc76">6.1.2&#XA0;&#XA0;Local Router</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc77">6.1.3&#XA0;&#XA0;Session Manager</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc78">6.1.4&#XA0;&#XA0;s2s Manager</A>
</LI></UL>
</LI><LI CLASS="li-toc"><A HREF="#htoc78">6.2&#XA0;&#XA0;Clustering Setup</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc79">6.3&#XA0;&#XA0;Service Load-Balancing</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc79">6.2&#XA0;&#XA0;Clustering Setup</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc80">6.3&#XA0;&#XA0;Service Load-Balancing</A>
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc80">6.3.1&#XA0;&#XA0;Components Load-Balancing</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc81">6.3.2&#XA0;&#XA0;Domain Load-Balancing Algorithm</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc82">6.3.3&#XA0;&#XA0;Load-Balancing Buckets</A>
<A HREF="#htoc81">6.3.1&#XA0;&#XA0;Components Load-Balancing</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc82">6.3.2&#XA0;&#XA0;Domain Load-Balancing Algorithm</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc83">6.3.3&#XA0;&#XA0;Load-Balancing Buckets</A>
</LI></UL>
</LI></UL>
</LI><LI CLASS="li-toc"><A HREF="#htoc83">Chapter&#XA0;7&#XA0;&#XA0;Debugging</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc84">Chapter&#XA0;7&#XA0;&#XA0;Debugging</A>
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc84">7.1&#XA0;&#XA0;Watchdog Alerts</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc85">7.2&#XA0;&#XA0;Log Files</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc86">7.3&#XA0;&#XA0;Debug Console</A>
<A HREF="#htoc85">7.1&#XA0;&#XA0;Watchdog Alerts</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc86">7.2&#XA0;&#XA0;Log Files</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc87">7.3&#XA0;&#XA0;Debug Console</A>
</LI></UL>
</LI><LI CLASS="li-toc"><A HREF="#htoc87">Appendix&#XA0;A&#XA0;&#XA0;Internationalization and Localization</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc88">Appendix&#XA0;B&#XA0;&#XA0;Release Notes</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc89">Appendix&#XA0;C&#XA0;&#XA0;Acknowledgements</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc90">Appendix&#XA0;D&#XA0;&#XA0;Copyright Information</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc88">Appendix&#XA0;A&#XA0;&#XA0;Internationalization and Localization</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc89">Appendix&#XA0;B&#XA0;&#XA0;Release Notes</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc90">Appendix&#XA0;C&#XA0;&#XA0;Acknowledgements</A>
</LI><LI CLASS="li-toc"><A HREF="#htoc91">Appendix&#XA0;D&#XA0;&#XA0;Copyright Information</A>
</LI></UL><!--TOC chapter Introduction-->
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc1">Chapter&#XA0;1</A>&#XA0;&#XA0;Introduction</H1><!--SEC END --><P>
<A NAME="intro"></A></P><P><TT>ejabberd</TT> is a free and open source instant messaging server written in <A HREF="http://www.erlang.org/">Erlang</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-->
@ -361,7 +362,7 @@ To get the full list run the command:
</DD><DT CLASS="dt-description"><B><TT>/sbin/ejabberdctl</TT></B></DT><DD CLASS="dd-description"> Administration script
</DD><DT CLASS="dt-description"><B><TT>/var/lib/ejabberd/</TT></B></DT><DD CLASS="dd-description">
<DL CLASS="description"><DT CLASS="dt-description">
<B><TT>.erlang.cookie</TT></B></DT><DD CLASS="dd-description"> Erlang cookie file
<B><TT>.erlang.cookie</TT></B></DT><DD CLASS="dd-description"> Erlang cookie file (see section <A HREF="#cookie">5.3</A>)
</DD><DT CLASS="dt-description"><B><TT>db</TT></B></DT><DD CLASS="dd-description"> Mnesia database spool files
</DD><DT CLASS="dt-description"><B><TT>ebin</TT></B></DT><DD CLASS="dd-description"> Binary Erlang files (*.beam)
</DD><DT CLASS="dt-description"><B><TT>priv</TT></B></DT><DD CLASS="dd-description">
@ -2976,7 +2977,7 @@ 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="htoc66">4.4</A>&#XA0;&#XA0;<A HREF="#changeerlangnodename">Change Computer Hostname</A></H2><!--SEC END --><P> <A NAME="changeerlangnodename"></A> </P><P><TT>ejabberd</TT> uses the distributed Mnesia database.
Being distributed, Mnesia enforces consistency of its file,
so it stores the name of the Erlang node in it.
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.
So, the name of the Erlang node changes
if you change the name of the machine in which <TT>ejabberd</TT> runs,
@ -3028,8 +3029,9 @@ 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="htoc70">5.3</A>&#XA0;&#XA0;<A HREF="#cookie">Erlang Cookie</A></H2><!--SEC END --><P> <A NAME="cookie"></A> </P><P>The Erlang cookie is a string with numbers and letters.
An Erlang node reads the cookie at startup from the command-line parameter <TT>-setcookie</TT>
or from a cookie file.
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.
Two Erlang nodes communicate only if they have the same cookie.
Setting a cookie on the Erlang node allows you to structure your Erlang network
and define which nodes are allowed to connect to which.</P><P>Thanks to Erlang cookies, you can prevent access to the Erlang node by mistake,
@ -3048,10 +3050,30 @@ to difficult unauthorized access to your Erlang node.
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="clustering"></A> </P><!--TOC chapter Clustering-->
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc72">Chapter&#XA0;6</A>&#XA0;&#XA0;<A HREF="#clustering">Clustering</A></H1><!--SEC END --><P> <A NAME="clustering"></A>
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>&#XA0;&#XA0;<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">
Contains the JID of administrators
and passwords of external components.
The backup files probably contain also this information,
so it is preferable to secure the whole <TT>/etc/ejabberd/</TT> directory.
</DD><DT CLASS="dt-description"><B><TT>ejabberd service log: /var/log/ejabberd/ejabberd.log</TT></B></DT><DD CLASS="dd-description">
Contains IP addresses of clients.
If the loglevel is set to 5, it contains whole conversations and passwords.
If a logrotate system is used, there may be several log files with similar information,
so it is preferable to secure the whole <TT>/var/log/ejabberd/</TT> directory.
</DD><DT CLASS="dt-description"><B><TT>Mnesia database spool files: /var/lib/ejabberd/db/*</TT></B></DT><DD CLASS="dd-description">
The files store binary data, but some parts are still readable.
The files are generated by Mnesia and their permissions cannot be set directly,
so it is preferable to secure the whole <TT>/var/lib/ejabberd/db/</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="htoc73">Chapter&#XA0;6</A>&#XA0;&#XA0;<A HREF="#clustering">Clustering</A></H1><!--SEC END --><P> <A NAME="clustering"></A>
</P><P> <A NAME="howitworks"></A> </P><!--TOC section How it Works-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc73">6.1</A>&#XA0;&#XA0;<A HREF="#howitworks">How it Works</A></H2><!--SEC END --><P> <A NAME="howitworks"></A>
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc74">6.1</A>&#XA0;&#XA0;<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
@ -3065,29 +3087,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="htoc74">6.1.1</A>&#XA0;&#XA0;<A HREF="#router">Router</A></H3><!--SEC END --><P> <A NAME="router"></A>
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc75">6.1.1</A>&#XA0;&#XA0;<A HREF="#router">Router</A></H3><!--SEC END --><P> <A NAME="router"></A>
</P><P>This module is the main router of Jabber packets on each node. It
routes them based on their destination&#X2019;s domains. It uses a global
routing table. The domain of the packet&#X2019;s destination is searched in the
routing table, and if it is found, the packet is routed to the
appropriate process. If not, it is sent to the s2s manager.</P><P> <A NAME="localrouter"></A> </P><!--TOC subsection Local Router-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc75">6.1.2</A>&#XA0;&#XA0;<A HREF="#localrouter">Local Router</A></H3><!--SEC END --><P> <A NAME="localrouter"></A>
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc76">6.1.2</A>&#XA0;&#XA0;<A HREF="#localrouter">Local Router</A></H3><!--SEC END --><P> <A NAME="localrouter"></A>
</P><P>This module routes packets which have a destination domain equal to
one of this server&#X2019;s host names. If the destination JID has a non-empty user
part, it is routed to the session manager, otherwise it is processed depending
on its content.</P><P> <A NAME="sessionmanager"></A> </P><!--TOC subsection Session Manager-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc76">6.1.3</A>&#XA0;&#XA0;<A HREF="#sessionmanager">Session Manager</A></H3><!--SEC END --><P> <A NAME="sessionmanager"></A>
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc77">6.1.3</A>&#XA0;&#XA0;<A HREF="#sessionmanager">Session Manager</A></H3><!--SEC END --><P> <A NAME="sessionmanager"></A>
</P><P>This module routes packets to local users. It looks up to which user
resource a packet must be sent via a presence table. Then the packet is
either routed to the appropriate c2s process, or stored in offline
storage, or bounced back.</P><P> <A NAME="s2smanager"></A> </P><!--TOC subsection s2s Manager-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc77">6.1.4</A>&#XA0;&#XA0;<A HREF="#s2smanager">s2s Manager</A></H3><!--SEC END --><P> <A NAME="s2smanager"></A>
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc78">6.1.4</A>&#XA0;&#XA0;<A HREF="#s2smanager">s2s Manager</A></H3><!--SEC END --><P> <A NAME="s2smanager"></A>
</P><P>This module routes packets to other Jabber servers. First, it
checks if an opened s2s connection from the domain of the packet&#X2019;s
source to the domain of the packet&#X2019;s destination exists. If that is the case,
the s2s manager routes the packet to the process
serving this connection, otherwise a new connection is opened.</P><P> <A NAME="cluster"></A> </P><!--TOC section Clustering Setup-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc78">6.2</A>&#XA0;&#XA0;<A HREF="#cluster">Clustering Setup</A></H2><!--SEC END --><P> <A NAME="cluster"></A>
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc79">6.2</A>&#XA0;&#XA0;<A HREF="#cluster">Clustering Setup</A></H2><!--SEC END --><P> <A NAME="cluster"></A>
</P><P>Suppose you already configured <TT>ejabberd</TT> on one machine named (<TT>first</TT>),
and you need to setup another one to make an <TT>ejabberd</TT> cluster. Then do
following steps:</P><OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
@ -3121,10 +3143,10 @@ and &#X2018;<CODE>access</CODE>&#X2019; options &#X2014; 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="htoc79">6.3</A>&#XA0;&#XA0;<A HREF="#servicelb">Service Load-Balancing</A></H2><!--SEC END --><P> <A NAME="servicelb"></A>
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc80">6.3</A>&#XA0;&#XA0;<A HREF="#servicelb">Service Load-Balancing</A></H2><!--SEC END --><P> <A NAME="servicelb"></A>
</P><P> <A NAME="componentlb"></A> </P><!--TOC subsection Components Load-Balancing-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc80">6.3.1</A>&#XA0;&#XA0;<A HREF="#componentlb">Components Load-Balancing</A></H3><!--SEC END --><P> <A NAME="componentlb"></A> </P><P> <A NAME="domainlb"></A> </P><!--TOC subsection Domain Load-Balancing Algorithm-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc81">6.3.2</A>&#XA0;&#XA0;<A HREF="#domainlb">Domain Load-Balancing Algorithm</A></H3><!--SEC END --><P> <A NAME="domainlb"></A>
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc81">6.3.1</A>&#XA0;&#XA0;<A HREF="#componentlb">Components Load-Balancing</A></H3><!--SEC END --><P> <A NAME="componentlb"></A> </P><P> <A NAME="domainlb"></A> </P><!--TOC subsection Domain Load-Balancing Algorithm-->
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc82">6.3.2</A>&#XA0;&#XA0;<A HREF="#domainlb">Domain Load-Balancing Algorithm</A></H3><!--SEC END --><P> <A NAME="domainlb"></A>
</P><P><TT>ejabberd</TT> includes an algorithm to load balance the components that are plugged on an <TT>ejabberd</TT> cluster. It means that you can plug one or several instances of the same component on each <TT>ejabberd</TT> cluster and that the traffic will be automatically distributed.</P><P>The default distribution algorithm try to deliver to a local instance of a component. If several local instances are available, one instance is chosen randomly. If no instance is available locally, one instance is chosen randomly among the remote component instances.</P><P>If you need a different behaviour, you can change the load balancing behaviour with the option <TT>domain_balancing</TT>. The syntax of the option is the following:</P><PRE CLASS="verbatim">{domain_balancing, "component.example.com", &lt;balancing_criterium&gt;}.
</PRE><P>Several balancing criteria are available:
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
@ -3133,13 +3155,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="htoc82">6.3.3</A>&#XA0;&#XA0;<A HREF="#lbbuckets">Load-Balancing Buckets</A></H3><!--SEC END --><P> <A NAME="lbbuckets"></A>
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc83">6.3.3</A>&#XA0;&#XA0;<A HREF="#lbbuckets">Load-Balancing Buckets</A></H3><!--SEC END --><P> <A NAME="lbbuckets"></A>
</P><P>When there is a risk of failure for a given component, domain balancing can cause service trouble. If one component is failing the service will not work correctly unless the sessions are rebalanced.</P><P>In this case, it is best to limit the problem to the sessions handled by the failing component. This is what the <TT>domain_balancing_component_number</TT> option does, making the load balancing algorithm not dynamic, but sticky on a fix number of component instances.</P><P>The syntax is 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="htoc83">Chapter&#XA0;7</A>&#XA0;&#XA0;<A HREF="#debugging">Debugging</A></H1><!--SEC END --><P> <A NAME="debugging"></A>
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc84">Chapter&#XA0;7</A>&#XA0;&#XA0;<A HREF="#debugging">Debugging</A></H1><!--SEC END --><P> <A NAME="debugging"></A>
</P><P> <A NAME="watchdog"></A> </P><!--TOC section Watchdog Alerts-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc84">7.1</A>&#XA0;&#XA0;<A HREF="#watchdog">Watchdog Alerts</A></H2><!--SEC END --><P> <A NAME="watchdog"></A>
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc85">7.1</A>&#XA0;&#XA0;<A HREF="#watchdog">Watchdog Alerts</A></H2><!--SEC END --><P> <A NAME="watchdog"></A>
</P><P><TT>ejabberd</TT> includes a watchdog mechanism.
If a process in the <TT>ejabberd</TT> server consumes too much memory,
a message is sent to the Jabber accounts defined with the option
@ -3151,7 +3173,7 @@ Example configuration:
To remove all watchdog admins, set the option with an empty list:
</P><PRE CLASS="verbatim">{watchdog_admins, []}.
</PRE><P> <A NAME="logfiles"></A> </P><!--TOC section Log Files-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc85">7.2</A>&#XA0;&#XA0;<A HREF="#logfiles">Log Files</A></H2><!--SEC END --><P> <A NAME="logfiles"></A> </P><P>An <TT>ejabberd</TT> node writes two log files:
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc86">7.2</A>&#XA0;&#XA0;<A HREF="#logfiles">Log Files</A></H2><!--SEC END --><P> <A NAME="logfiles"></A> </P><P>An <TT>ejabberd</TT> node writes two log files:
</P><DL CLASS="description"><DT CLASS="dt-description">
<B><TT>ejabberd.log</TT></B></DT><DD CLASS="dd-description"> is the ejabberd service log, with the messages reported by <TT>ejabberd</TT> code
</DD><DT CLASS="dt-description"><B><TT>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)
@ -3168,12 +3190,12 @@ The possible levels are:
For example, the default configuration is:
</P><PRE CLASS="verbatim">{loglevel, 4}.
</PRE><P> <A NAME="debugconsole"></A> </P><!--TOC section Debug Console-->
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc86">7.3</A>&#XA0;&#XA0;<A HREF="#debugconsole">Debug Console</A></H2><!--SEC END --><P> <A NAME="debugconsole"></A> </P><P>The Debug Console is an Erlang shell attached to an already running <TT>ejabberd</TT> server.
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc87">7.3</A>&#XA0;&#XA0;<A HREF="#debugconsole">Debug Console</A></H2><!--SEC END --><P> <A NAME="debugconsole"></A> </P><P>The Debug Console is an Erlang shell attached to an already running <TT>ejabberd</TT> server.
With this Erlang shell, an experienced administrator can perform complex tasks.</P><P>This shell gives complete control over the <TT>ejabberd</TT> server,
so it is important to use it with extremely care.
There are some simple and safe examples in the article
<A HREF="http://www.ejabberd.im/interconnect-erl-nodes">Interconnecting Erlang Nodes</A></P><P>To exit the shell, close the window or press the keys: control+c control+c.</P><P> <A NAME="i18ni10n"></A> </P><!--TOC chapter Internationalization and Localization-->
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc87">Appendix&#XA0;A</A>&#XA0;&#XA0;<A HREF="#i18ni10n">Internationalization and Localization</A></H1><!--SEC END --><P> <A NAME="i18ni10n"></A>
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc88">Appendix&#XA0;A</A>&#XA0;&#XA0;<A HREF="#i18ni10n">Internationalization and Localization</A></H1><!--SEC END --><P> <A NAME="i18ni10n"></A>
</P><P>All built-in modules support the <TT>xml:lang</TT> attribute inside IQ queries.
Figure&#XA0;<A HREF="#fig:discorus">A.1</A>, for example, shows the reply to the following query:
</P><PRE CLASS="verbatim">&lt;iq id='5'
@ -3200,9 +3222,9 @@ HTTP header &#X2018;Accept-Language: ru&#X2019;</TD></TR>
</TABLE></DIV>
<A NAME="fig:webadmmainru"></A>
<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></DIV></BLOCKQUOTE><P> <A NAME="releasenotes"></A> </P><!--TOC chapter Release Notes-->
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc88">Appendix&#XA0;B</A>&#XA0;&#XA0;<A HREF="#releasenotes">Release Notes</A></H1><!--SEC END --><P> <A NAME="releasenotes"></A>
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc89">Appendix&#XA0;B</A>&#XA0;&#XA0;<A HREF="#releasenotes">Release Notes</A></H1><!--SEC END --><P> <A NAME="releasenotes"></A>
</P><P>Release notes are available from <A HREF="http://www.process-one.net/en/ejabberd/release_notes/">ejabberd Home Page</A></P><P> <A NAME="acknowledgements"></A> </P><!--TOC chapter Acknowledgements-->
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc89">Appendix&#XA0;C</A>&#XA0;&#XA0;<A HREF="#acknowledgements">Acknowledgements</A></H1><!--SEC END --><P> <A NAME="acknowledgements"></A> </P><P>Thanks to all people who contributed to this guide:
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc90">Appendix&#XA0;C</A>&#XA0;&#XA0;<A HREF="#acknowledgements">Acknowledgements</A></H1><!--SEC END --><P> <A NAME="acknowledgements"></A> </P><P>Thanks to all people who contributed to this guide:
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
Alexey Shchepin (<A HREF="xmpp:aleksey@jabber.ru"><TT>xmpp:aleksey@jabber.ru</TT></A>)
</LI><LI CLASS="li-itemize">Badlop (<A HREF="xmpp:badlop@jabberes.org"><TT>xmpp:badlop@jabberes.org</TT></A>)
@ -3214,7 +3236,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="htoc90">Appendix&#XA0;D</A>&#XA0;&#XA0;<A HREF="#copyright">Copyright Information</A></H1><!--SEC END --><P> <A NAME="copyright"></A> </P><P>Ejabberd Installation and Operation Guide.<BR>
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc91">Appendix&#XA0;D</A>&#XA0;&#XA0;<A HREF="#copyright">Copyright Information</A></H1><!--SEC END --><P> <A NAME="copyright"></A> </P><P>Ejabberd Installation and Operation Guide.<BR>
Copyright &#XA9; 2003 &#X2014; 2008 Process-one</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

35
doc/guide.tex
View File

@ -361,7 +361,7 @@ The files and directories created are, by default:
\titem{/sbin/ejabberdctl} Administration script
\titem{/var/lib/ejabberd/}
\begin{description}
\titem{.erlang.cookie} Erlang cookie file
\titem{.erlang.cookie} Erlang cookie file (see section \ref{cookie})
\titem{db} Mnesia database spool files
\titem{ebin} Binary Erlang files (*.beam)
\titem{priv}
@ -3809,7 +3809,7 @@ an account with proper privileges.
\ejabberd{} uses the distributed Mnesia database.
Being distributed, Mnesia enforces consistency of its file,
so it stores the name of the Erlang node in it.
so it stores the name of the Erlang node in it (see section \ref{nodename}).
The name of an Erlang node includes the hostname of the computer.
So, the name of the Erlang node changes
if you change the name of the machine in which \ejabberd{} runs,
@ -3889,8 +3889,9 @@ erl ... -kernel inet_dist_listen_min 4370 inet_dist_listen_max 4375
\makesection{cookie}{Erlang Cookie}
The Erlang cookie is a string with numbers and letters.
An Erlang node reads the cookie at startup from the command-line parameter \term{-setcookie}
or from a cookie file.
An Erlang node reads the cookie at startup from the command-line parameter \term{-setcookie}.
If not indicated, the cookie is read from the cookie file \term{\$HOME/.erlang.cookie}.
If this file does not exist, it is created immediately with a random cookie.
Two Erlang nodes communicate only if they have the same cookie.
Setting a cookie on the Erlang node allows you to structure your Erlang network
and define which nodes are allowed to connect to which.
@ -3922,6 +3923,32 @@ using a modified version of Erlang \term{epmd}.
The recommended way to secure the Erlang node is to block the port 4369.
\makesection{secure-files}{Securing sensible files}
\ejabberd{} 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.
\begin{description}
\titem{ejabberd configuration file: /etc/ejabberd/ejabberd.cfg}
Contains the JID of administrators
and passwords of external components.
The backup files probably contain also this information,
so it is preferable to secure the whole \term{/etc/ejabberd/} directory.
\titem{ejabberd service log: /var/log/ejabberd/ejabberd.log}
Contains IP addresses of clients.
If the loglevel is set to 5, it contains whole conversations and passwords.
If a logrotate system is used, there may be several log files with similar information,
so it is preferable to secure the whole \term{/var/log/ejabberd/} directory.
\titem{Mnesia database spool files: /var/lib/ejabberd/db/*}
The files store binary data, but some parts are still readable.
The files are generated by Mnesia and their permissions cannot be set directly,
so it is preferable to secure the whole \term{/var/lib/ejabberd/db/} directory.
\titem{Erlang cookie file: /var/lib/ejabberd/.erlang.cookie}
See section \ref{cookie}.
\end{description}
\makechapter{clustering}{Clustering}
\ind{clustering}

6
src/Makefile.in
View File

@ -60,6 +60,7 @@ DESTDIR =
EJABBERDDIR = $(DESTDIR)@localstatedir@/lib/ejabberd
BEAMDIR = $(EJABBERDDIR)/ebin
SPOOLDIR = $(EJABBERDDIR)/db
PRIVDIR = $(EJABBERDDIR)/priv
SODIR = $(PRIVDIR)/lib
PBINDIR = $(PRIVDIR)/bin
@ -116,20 +117,21 @@ install: all
install -m 644 *.beam $(BEAMDIR)
rm -f $(BEAMDIR)/configure.beam
install -m 644 *.app $(BEAMDIR)
install -d -m 750 $(SPOOLDIR)
install -d $(SODIR)
install -d $(PBINDIR)
install -m 644 *.so $(SODIR)
$(INSTALL_EPAM)
install -d $(MSGSDIR)
install -m 644 msgs/*.msg $(MSGSDIR)
install -d $(ETCDIR)
install -d -m 750 $(ETCDIR)
[ -f $(ETCDIR)/ejabberd.cfg ] && install -b -m 644 ejabberd.cfg.example $(ETCDIR)/ejabberd.cfg-new || install -b -m 644 ejabberd.cfg.example $(ETCDIR)/ejabberd.cfg
sed -e "s*@rootdir@*@prefix@*" ejabberdctl.template > ejabberdctl.example
[ -f $(ETCDIR)/ejabberdctl.cfg ] && install -b -m 644 ejabberdctl.cfg.example $(ETCDIR)/ejabberdctl.cfg-new || install -b -m 644 ejabberdctl.cfg.example $(ETCDIR)/ejabberdctl.cfg
install -b -m 644 inetrc $(ETCDIR)/inetrc
install -d $(SBINDIR)
install -m 755 ejabberdctl.example $(SBINDIR)/ejabberdctl
install -d $(LOGDIR)
install -d -m 750 $(LOGDIR)
uninstall: uninstall-binary