mirror of
https://github.com/processone/ejabberd.git
synced 2024-12-02 16:37:52 +01:00
* 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 SVN Revision: 1413
This commit is contained in:
parent
00c3bc2450
commit
8032533f26
@ -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
108
doc/guide.html
@ -178,34 +178,35 @@ BLOCKQUOTE.figure DIV.center DIV.center HR{display:none;}
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc69">5.2  epmd</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><LI CLASS="li-toc"><A HREF="#htoc72">Chapter 6  Clustering</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc73">Chapter 6  Clustering</A>
|
||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||
<A HREF="#htoc73">6.1  How it Works</A>
|
||||
<A HREF="#htoc74">6.1  How it Works</A>
|
||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||
<A HREF="#htoc74">6.1.1  Router</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc75">6.1.2  Local Router</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc76">6.1.3  Session Manager</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc77">6.1.4  s2s Manager</A>
|
||||
<A HREF="#htoc75">6.1.1  Router</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="#htoc78">6.2  Clustering Setup</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc79">6.3  Service Load-Balancing</A>
|
||||
</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">
|
||||
<A HREF="#htoc80">6.3.1  Components Load-Balancing</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc81">6.3.2  Domain Load-Balancing Algorithm</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc82">6.3.3  Load-Balancing Buckets</A>
|
||||
<A HREF="#htoc81">6.3.1  Components Load-Balancing</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc82">6.3.2  Domain Load-Balancing Algorithm</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc83">6.3.3  Load-Balancing Buckets</A>
|
||||
</LI></UL>
|
||||
</LI></UL>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc83">Chapter 7  Debugging</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc84">Chapter 7  Debugging</A>
|
||||
<UL CLASS="toc"><LI CLASS="li-toc">
|
||||
<A HREF="#htoc84">7.1  Watchdog Alerts</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc85">7.2  Log Files</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc86">7.3  Debug Console</A>
|
||||
<A HREF="#htoc85">7.1  Watchdog Alerts</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc86">7.2  Log Files</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc87">7.3  Debug Console</A>
|
||||
</LI></UL>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc87">Appendix A  Internationalization and Localization</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc88">Appendix B  Release Notes</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc89">Appendix C  Acknowledgements</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc90">Appendix D  Copyright Information</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc88">Appendix A  Internationalization and Localization</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc89">Appendix B  Release Notes</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc90">Appendix C  Acknowledgements</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc91">Appendix D  Copyright Information</A>
|
||||
</LI></UL><!--TOC chapter Introduction-->
|
||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc1">Chapter 1</A>  Introduction</H1><!--SEC END --><P>
|
||||
<A NAME="intro"></A></P><P><TT>ejabberd</TT> is a free and open source instant messaging server written in <A HREF="http://www.erlang.org/">Erlang</A>.</P><P><TT>ejabberd</TT> is cross-platform, distributed, fault-tolerant, and based on open standards to achieve real-time communication.</P><P><TT>ejabberd</TT> is designed to be a rock-solid and feature rich XMPP server.</P><P><TT>ejabberd</TT> is suitable for small deployments, whether they need to be scalable or not, as well as extremely big deployments.</P><!--TOC section Key Features-->
|
||||
@ -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">
|
||||
@ -2966,7 +2967,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>  <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,
|
||||
@ -3017,8 +3018,9 @@ You can limit the range of ports when starting Erlang with a command-line parame
|
||||
</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>  <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,
|
||||
@ -3037,10 +3039,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 6</A>  <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>  <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 6</A>  <A HREF="#clustering">Clustering</A></H1><!--SEC END --><P> <A NAME="clustering"></A>
|
||||
</P><P> <A NAME="howitworks"></A> </P><!--TOC section How it Works-->
|
||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc73">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="htoc74">6.1</A>  <A HREF="#howitworks">How it Works</A></H2><!--SEC END --><P> <A NAME="howitworks"></A>
|
||||
</P><P>A Jabber domain is served by one or more <TT>ejabberd</TT> nodes. These nodes can
|
||||
be run on different machines that are connected via a network. They all
|
||||
must have the ability to connect to port 4369 of all another nodes, and must
|
||||
@ -3054,29 +3076,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>  <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>  <A HREF="#router">Router</A></H3><!--SEC END --><P> <A NAME="router"></A>
|
||||
</P><P>This module is the main router of Jabber packets on each node. It
|
||||
routes them based on their destination’s domains. It uses a global
|
||||
routing table. The domain of the packet’s destination is searched in the
|
||||
routing table, and if it is found, the packet is routed to the
|
||||
appropriate process. If not, it is sent to the s2s manager.</P><P> <A NAME="localrouter"></A> </P><!--TOC subsection Local Router-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc75">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="htoc76">6.1.2</A>  <A HREF="#localrouter">Local Router</A></H3><!--SEC END --><P> <A NAME="localrouter"></A>
|
||||
</P><P>This module routes packets which have a destination domain equal to
|
||||
one of this server’s host names. If the destination JID has a non-empty user
|
||||
part, it is routed to the session manager, otherwise it is processed depending
|
||||
on its content.</P><P> <A NAME="sessionmanager"></A> </P><!--TOC subsection Session Manager-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc76">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="htoc77">6.1.3</A>  <A HREF="#sessionmanager">Session Manager</A></H3><!--SEC END --><P> <A NAME="sessionmanager"></A>
|
||||
</P><P>This module routes packets to local users. It looks up to which user
|
||||
resource a packet must be sent via a presence table. Then the packet is
|
||||
either routed to the appropriate c2s process, or stored in offline
|
||||
storage, or bounced back.</P><P> <A NAME="s2smanager"></A> </P><!--TOC subsection s2s Manager-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc77">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="htoc78">6.1.4</A>  <A HREF="#s2smanager">s2s Manager</A></H3><!--SEC END --><P> <A NAME="s2smanager"></A>
|
||||
</P><P>This module routes packets to other Jabber servers. First, it
|
||||
checks if an opened s2s connection from the domain of the packet’s
|
||||
source to the domain of the packet’s destination exists. If that is the case,
|
||||
the s2s manager routes the packet to the process
|
||||
serving this connection, otherwise a new connection is opened.</P><P> <A NAME="cluster"></A> </P><!--TOC section Clustering Setup-->
|
||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc78">6.2</A>  <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>  <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">
|
||||
@ -3110,10 +3132,10 @@ and ‘<CODE>access</CODE>’ options — 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>  <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>  <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>  <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>  <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>  <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>
|
||||
</P><P><TT>ejabberd</TT> includes an algorithm to load balance the components that are plugged on an <TT>ejabberd</TT> cluster. It means that you can plug one or several instances of the same component on each <TT>ejabberd</TT> cluster and that the traffic will be automatically distributed.</P><P>The default distribution algorithm try to deliver to a local instance of a component. If several local instances are available, one instance is chosen randomly. If no instance is available locally, one instance is chosen randomly among the remote component instances.</P><P>If you need a different behaviour, you can change the load balancing behaviour with the option <TT>domain_balancing</TT>. The syntax of the option is the following:</P><PRE CLASS="verbatim">{domain_balancing, "component.example.com", <balancing_criterium>}.
|
||||
</PRE><P>Several balancing criteria are available:
|
||||
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
|
||||
@ -3122,13 +3144,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>  <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>  <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 7</A>  <A HREF="#debugging">Debugging</A></H1><!--SEC END --><P> <A NAME="debugging"></A>
|
||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc84">Chapter 7</A>  <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>  <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>  <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
|
||||
@ -3140,7 +3162,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>  <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>  <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)
|
||||
@ -3157,12 +3179,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>  <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>  <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 A</A>  <A HREF="#i18ni10n">Internationalization and Localization</A></H1><!--SEC END --><P> <A NAME="i18ni10n"></A>
|
||||
<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>
|
||||
</P><P>All built-in modules support the <TT>xml:lang</TT> attribute inside IQ queries.
|
||||
Figure <A HREF="#fig:discorus">A.1</A>, for example, shows the reply to the following query:
|
||||
</P><PRE CLASS="verbatim"><iq id='5'
|
||||
@ -3189,9 +3211,9 @@ HTTP header ‘Accept-Language: ru’</TD></TR>
|
||||
</TABLE></DIV>
|
||||
<A NAME="fig:webadmmainru"></A>
|
||||
<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></DIV></BLOCKQUOTE><P> <A NAME="releasenotes"></A> </P><!--TOC chapter Release Notes-->
|
||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc88">Appendix B</A>  <A HREF="#releasenotes">Release Notes</A></H1><!--SEC END --><P> <A NAME="releasenotes"></A>
|
||||
<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>
|
||||
</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 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="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:
|
||||
</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>)
|
||||
@ -3203,7 +3225,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 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="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>
|
||||
Copyright © 2003 — 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
|
||||
|
@ -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}
|
||||
@ -3652,7 +3652,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,
|
||||
@ -3731,8 +3731,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.
|
||||
@ -3764,6 +3765,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}
|
||||
|
||||
|
@ -58,6 +58,7 @@ DESTDIR =
|
||||
|
||||
EJABBERDDIR = $(DESTDIR)@localstatedir@/lib/ejabberd
|
||||
BEAMDIR = $(EJABBERDDIR)/ebin
|
||||
SPOOLDIR = $(EJABBERDDIR)/db
|
||||
PRIVDIR = $(EJABBERDDIR)/priv
|
||||
SODIR = $(PRIVDIR)/lib
|
||||
PBINDIR = $(PRIVDIR)/bin
|
||||
@ -107,20 +108,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
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user