<HEAD>
-<TITLE>Ejabberd 1.1.1 Installation and Operation Guide</TITLE>
+<TITLE>Ejabberd 1.1.2 Installation and Operation Guide</TITLE>
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<META name="GENERATOR" content="hevea 1.08">
PRE{text-align:left;margin-left:0ex;margin-right:auto;}
BLOCKQUOTE{margin-left:4ex;margin-right:4ex;text-align:left;}
.part{margin:auto;text-align:center}
+SPAN{width:20%; float:right; text-align:left; margin-left:auto;}
</STYLE>
</HEAD>
<BODY >
-<!--HEVEA command line is: hevea guide.tex -->
+<!--HEVEA command line is: hevea -fix -noiso -pedantic guide.tex -->
<!--HTMLHEAD-->
<!--ENDHTML-->
<!--PREFIX <ARG ></ARG>-->
<BR>
<BR>
-<A NAME="sec:titlepage"></A>
+<A NAME="titlepage"></A>
<TABLE CLASS="title">
<TR><TD>
-<H1 CLASS="titlemain">Ejabberd 1.1.1 Installation and Operation Guide</H1>
+<H1 CLASS="titlemain">Ejabberd 1.1.2 Installation and Operation Guide</H1>
<H3 CLASS="titlerest">Alexey Shchepin<BR>
<A HREF="mailto:alexey@sevcom.net"><TT>mailto:alexey@sevcom.net</TT></A><BR>
<A HREF="xmpp:aleksey@jabber.ru"><TT>xmpp:aleksey@jabber.ru</TT></A></H3></TD>
<BR>
<DIV CLASS="center">
- <IMG SRC="logo.png">
+ <IMG SRC="logo.png" ALT="logo.png">
<BR>
<BR>
</DIV>
-<BLOCKQUOTE CLASS="quotation"><I>I can thoroughly recommend ejabberd for ease of setup –
+<BLOCKQUOTE CLASS="quotation"><I>I can thoroughly recommend ejabberd for ease of setup —
Kevin Smith, Current maintainer of the Psi project</I></BLOCKQUOTE>
<!--TOC section Contents-->
<UL CLASS="toc"><LI CLASS="li-toc">
<A HREF="#htoc5">2.1 Installation Requirements</A>
<UL CLASS="toc"><LI CLASS="li-toc">
-<A HREF="#htoc6">2.1.1 “Unix-like” operating systems</A>
+<A HREF="#htoc6">2.1.1 `Unix-like' operating systems</A>
<LI CLASS="li-toc"><A HREF="#htoc7">2.1.2 Windows</A>
</UL>
<LI CLASS="li-toc"><A HREF="#htoc8">2.2 Obtaining <TT>ejabberd</TT></A>
<LI CLASS="li-toc"><A HREF="#htoc9">2.3 Compilation</A>
<UL CLASS="toc"><LI CLASS="li-toc">
-<A HREF="#htoc10">2.3.1 “Unix-like” operating systems</A>
+<A HREF="#htoc10">2.3.1 `Unix-like' operating systems</A>
<LI CLASS="li-toc"><A HREF="#htoc11">2.3.2 Windows</A>
</UL>
<LI CLASS="li-toc"><A HREF="#htoc12">2.4 Starting</A>
</UL>
-<LI CLASS="li-toc"><A HREF="#htoc13">3 Configuration</A>
+<LI CLASS="li-toc"><A HREF="#htoc13">3 Basic Configuration</A>
<UL CLASS="toc"><LI CLASS="li-toc">
-<A HREF="#htoc14">3.1 Initial Configuration</A>
+<A HREF="#htoc14">3.1 Host Names</A>
+<LI CLASS="li-toc"><A HREF="#htoc15">3.2 Virtual Hosting</A>
+<LI CLASS="li-toc"><A HREF="#htoc16">3.3 Listened Sockets</A>
+<LI CLASS="li-toc"><A HREF="#htoc17">3.4 Authentication</A>
<UL CLASS="toc"><LI CLASS="li-toc">
-<A HREF="#htoc15">3.1.1 Host Names</A>
-<LI CLASS="li-toc"><A HREF="#htoc16">3.1.2 Default Language</A>
-<LI CLASS="li-toc"><A HREF="#htoc17">3.1.3 Access Rules</A>
-<LI CLASS="li-toc"><A HREF="#htoc18">3.1.4 Shapers</A>
-<LI CLASS="li-toc"><A HREF="#htoc19">3.1.5 Limitation of the number of opened sessions</A>
-<LI CLASS="li-toc"><A HREF="#htoc20">3.1.6 Listened Sockets</A>
-<LI CLASS="li-toc"><A HREF="#htoc21">3.1.7 Modules</A>
-<LI CLASS="li-toc"><A HREF="#htoc22">3.1.8 Virtual Hosting</A>
-<LI CLASS="li-toc"><A HREF="#htoc23">3.1.9 SASL anonymous and anonymous login</A>
+<A HREF="#htoc18">3.4.1 Internal</A>
+<LI CLASS="li-toc"><A HREF="#htoc19">3.4.2 SASL Anonymous and Anonymous Login</A>
</UL>
-<LI CLASS="li-toc"><A HREF="#htoc24">3.2 Relational Database Support</A>
+<LI CLASS="li-toc"><A HREF="#htoc20">3.5 Access Rules</A>
+<LI CLASS="li-toc"><A HREF="#htoc21">3.6 Shapers</A>
+<LI CLASS="li-toc"><A HREF="#htoc22">3.7 Limiting Opened Sessions</A>
+<LI CLASS="li-toc"><A HREF="#htoc23">3.8 Default Language</A>
+</UL>
+<LI CLASS="li-toc"><A HREF="#htoc24">4 Database Configuration</A>
+<UL CLASS="toc"><LI CLASS="li-toc">
+<A HREF="#htoc25">4.1 MySQL</A>
<UL CLASS="toc"><LI CLASS="li-toc">
-<A HREF="#htoc25">3.2.1 Preliminary steps</A>
-<LI CLASS="li-toc"><A HREF="#htoc26">3.2.2 Authentication against a relational database</A>
-<LI CLASS="li-toc"><A HREF="#htoc27">3.2.3 Relational database for other modules</A>
+<A HREF="#htoc26">4.1.1 Driver Compilation</A>
+<LI CLASS="li-toc"><A HREF="#htoc27">4.1.2 Authentication</A>
+<LI CLASS="li-toc"><A HREF="#htoc28">4.1.3 Storage</A>
</UL>
-<LI CLASS="li-toc"><A HREF="#htoc28">3.3 Creating an Initial Administrator</A>
-<LI CLASS="li-toc"><A HREF="#htoc29">3.4 Online Configuration and Monitoring</A>
+<LI CLASS="li-toc"><A HREF="#htoc29">4.2 Microsoft SQL Server</A>
<UL CLASS="toc"><LI CLASS="li-toc">
-<A HREF="#htoc30">3.4.1 Web Interface</A>
-<LI CLASS="li-toc"><A HREF="#htoc31">3.4.2 <TT>ejabberdctl</TT></A>
+<A HREF="#htoc30">4.2.1 Driver Compilation</A>
+<LI CLASS="li-toc"><A HREF="#htoc31">4.2.2 Authentication</A>
+<LI CLASS="li-toc"><A HREF="#htoc32">4.2.3 Storage</A>
</UL>
+<LI CLASS="li-toc"><A HREF="#htoc33">4.3 PostgreSQL</A>
+<UL CLASS="toc"><LI CLASS="li-toc">
+<A HREF="#htoc34">4.3.1 Driver Compilation</A>
+<LI CLASS="li-toc"><A HREF="#htoc35">4.3.2 Authentication</A>
+<LI CLASS="li-toc"><A HREF="#htoc36">4.3.3 Storage</A>
</UL>
-<LI CLASS="li-toc"><A HREF="#htoc32">4 Firewall Settings</A>
-<LI CLASS="li-toc"><A HREF="#htoc33">5 SRV Records</A>
-<LI CLASS="li-toc"><A HREF="#htoc34">6 Clustering</A>
+<LI CLASS="li-toc"><A HREF="#htoc37">4.4 ODBC Compatible</A>
<UL CLASS="toc"><LI CLASS="li-toc">
-<A HREF="#htoc35">6.1 How it Works</A>
+<A HREF="#htoc38">4.4.1 Compilation</A>
+<LI CLASS="li-toc"><A HREF="#htoc39">4.4.2 Authentication</A>
+<LI CLASS="li-toc"><A HREF="#htoc40">4.4.3 Storage</A>
+</UL>
+<LI CLASS="li-toc"><A HREF="#htoc41">4.5 LDAP</A>
<UL CLASS="toc"><LI CLASS="li-toc">
-<A HREF="#htoc36">6.1.1 Router</A>
-<LI CLASS="li-toc"><A HREF="#htoc37">6.1.2 Local Router</A>
-<LI CLASS="li-toc"><A HREF="#htoc38">6.1.3 Session Manager</A>
-<LI CLASS="li-toc"><A HREF="#htoc39">6.1.4 s2s Manager</A>
+<A HREF="#htoc42">4.5.1 Connection</A>
+<LI CLASS="li-toc"><A HREF="#htoc43">4.5.2 Authentication</A>
+<LI CLASS="li-toc"><A HREF="#htoc44">4.5.3 Examples</A>
</UL>
-<LI CLASS="li-toc"><A HREF="#htoc40">6.2 Clustering Setup</A>
</UL>
-<LI CLASS="li-toc"><A HREF="#htoc41">A Built-in Modules</A>
+<LI CLASS="li-toc"><A HREF="#htoc45">5 Modules Configuration</A>
<UL CLASS="toc"><LI CLASS="li-toc">
-<A HREF="#htoc42">A.1 Overview</A>
-<LI CLASS="li-toc"><A HREF="#htoc43">A.2 Common Options</A>
+<A HREF="#htoc46">5.1 Overview</A>
+<LI CLASS="li-toc"><A HREF="#htoc47">5.2 Common Options</A>
<UL CLASS="toc"><LI CLASS="li-toc">
-<A HREF="#htoc44">A.2.1 <TT>iqdisc</TT></A>
-<LI CLASS="li-toc"><A HREF="#htoc45">A.2.2 <TT>hosts</TT></A>
+<A HREF="#htoc48">5.2.1 <TT>iqdisc</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc49">5.2.2 <TT>hosts</TT></A>
</UL>
-<LI CLASS="li-toc"><A HREF="#htoc46">A.3 <TT>mod_announce</TT></A>
-<LI CLASS="li-toc"><A HREF="#htoc47">A.4 <TT>mod_disco</TT></A>
-<LI CLASS="li-toc"><A HREF="#htoc48">A.5 <TT>mod_echo</TT></A>
-<LI CLASS="li-toc"><A HREF="#htoc49">A.6 <TT>mod_irc</TT></A>
-<LI CLASS="li-toc"><A HREF="#htoc50">A.7 <TT>mod_last</TT></A>
-<LI CLASS="li-toc"><A HREF="#htoc51">A.8 <TT>mod_muc</TT></A>
-<LI CLASS="li-toc"><A HREF="#htoc52">A.9 <TT>mod_muc_log</TT></A>
-<LI CLASS="li-toc"><A HREF="#htoc53">A.10 <TT>mod_offline</TT></A>
-<LI CLASS="li-toc"><A HREF="#htoc54">A.11 <TT>mod_privacy</TT></A>
-<LI CLASS="li-toc"><A HREF="#htoc55">A.12 <TT>mod_private</TT></A>
-<LI CLASS="li-toc"><A HREF="#htoc56">A.13 <TT>mod_pubsub</TT></A>
-<LI CLASS="li-toc"><A HREF="#htoc57">A.14 <TT>mod_register</TT></A>
-<LI CLASS="li-toc"><A HREF="#htoc58">A.15 <TT>mod_roster</TT></A>
-<LI CLASS="li-toc"><A HREF="#htoc59">A.16 <TT>mod_service_log</TT></A>
-<LI CLASS="li-toc"><A HREF="#htoc60">A.17 <TT>mod_shared_roster</TT></A>
-<LI CLASS="li-toc"><A HREF="#htoc61">A.18 <TT>mod_stats</TT></A>
-<LI CLASS="li-toc"><A HREF="#htoc62">A.19 <TT>mod_time</TT></A>
-<LI CLASS="li-toc"><A HREF="#htoc63">A.20 <TT>mod_vcard</TT></A>
-<LI CLASS="li-toc"><A HREF="#htoc64">A.21 LDAP and <TT>mod_vcard_ldap</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc50">5.3 <TT>mod_announce</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc51">5.4 <TT>mod_disco</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc52">5.5 <TT>mod_echo</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc53">5.6 <TT>mod_irc</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc54">5.7 <TT>mod_last</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc55">5.8 <TT>mod_muc</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc56">5.9 <TT>mod_muc_log</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc57">5.10 <TT>mod_offline</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc58">5.11 <TT>mod_privacy</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc59">5.12 <TT>mod_private</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc60">5.13 <TT>mod_pubsub</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc61">5.14 <TT>mod_register</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc62">5.15 <TT>mod_roster</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc63">5.16 <TT>mod_service_log</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc64">5.17 <TT>mod_shared_roster</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc65">5.18 <TT>mod_stats</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc66">5.19 <TT>mod_time</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc67">5.20 <TT>mod_vcard</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc68">5.21 <TT>mod_vcard_ldap</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc69">5.22 <TT>mod_version</TT></A>
+</UL>
+<LI CLASS="li-toc"><A HREF="#htoc70">6 Creating an Initial Administrator</A>
+<LI CLASS="li-toc"><A HREF="#htoc71">7 Online Configuration and Monitoring</A>
+<UL CLASS="toc"><LI CLASS="li-toc">
+<A HREF="#htoc72">7.1 Web Interface</A>
+<LI CLASS="li-toc"><A HREF="#htoc73">7.2 <TT>ejabberdctl</TT></A>
+</UL>
+<LI CLASS="li-toc"><A HREF="#htoc74">8 Firewall Settings</A>
+<LI CLASS="li-toc"><A HREF="#htoc75">9 SRV Records</A>
+<LI CLASS="li-toc"><A HREF="#htoc76">10 Clustering</A>
+<UL CLASS="toc"><LI CLASS="li-toc">
+<A HREF="#htoc77">10.1 How it Works</A>
<UL CLASS="toc"><LI CLASS="li-toc">
-<A HREF="#htoc65">A.21.1 Features</A>
-<LI CLASS="li-toc"><A HREF="#htoc66">A.21.2 Connection</A>
-<LI CLASS="li-toc"><A HREF="#htoc67">A.21.3 Authentication</A>
-<LI CLASS="li-toc"><A HREF="#htoc68">A.21.4 vCards and Search</A>
-<LI CLASS="li-toc"><A HREF="#htoc69">A.21.5 Examples</A>
+<A HREF="#htoc78">10.1.1 Router</A>
+<LI CLASS="li-toc"><A HREF="#htoc79">10.1.2 Local Router</A>
+<LI CLASS="li-toc"><A HREF="#htoc80">10.1.3 Session Manager</A>
+<LI CLASS="li-toc"><A HREF="#htoc81">10.1.4 s2s Manager</A>
</UL>
-<LI CLASS="li-toc"><A HREF="#htoc70">A.22 <TT>mod_version</TT></A>
+<LI CLASS="li-toc"><A HREF="#htoc82">10.2 Clustering Setup</A>
</UL>
-<LI CLASS="li-toc"><A HREF="#htoc71">B Internationalization and Localization</A>
-<LI CLASS="li-toc"><A HREF="#htoc72">C Release Notes</A>
+<LI CLASS="li-toc"><A HREF="#htoc83">A Internationalization and Localization</A>
+<LI CLASS="li-toc"><A HREF="#htoc84">B Release Notes</A>
<UL CLASS="toc"><LI CLASS="li-toc">
-<A HREF="#htoc73">C.1 ejabberd 0.9</A>
-<LI CLASS="li-toc"><A HREF="#htoc74">C.2 ejabberd 0.9.1</A>
-<LI CLASS="li-toc"><A HREF="#htoc75">C.3 ejabberd 0.9.8</A>
-<LI CLASS="li-toc"><A HREF="#htoc76">C.4 ejabberd 1.0.0</A>
-<LI CLASS="li-toc"><A HREF="#htoc77">C.5 ejabberd 1.1.0</A>
-<LI CLASS="li-toc"><A HREF="#htoc78">C.6 ejabberd 1.1.1</A>
+<A HREF="#htoc85">B.1 ejabberd 0.9</A>
+<LI CLASS="li-toc"><A HREF="#htoc86">B.2 ejabberd 0.9.1</A>
+<LI CLASS="li-toc"><A HREF="#htoc87">B.3 ejabberd 0.9.8</A>
+<LI CLASS="li-toc"><A HREF="#htoc88">B.4 ejabberd 1.0.0</A>
+<LI CLASS="li-toc"><A HREF="#htoc89">B.5 ejabberd 1.1.0</A>
+<LI CLASS="li-toc"><A HREF="#htoc90">B.6 ejabberd 1.1.1</A>
</UL>
-<LI CLASS="li-toc"><A HREF="#htoc79">D Acknowledgements</A>
+<LI CLASS="li-toc"><A HREF="#htoc91">C Acknowledgements</A>
+<LI CLASS="li-toc"><A HREF="#htoc92">D Copyright Information</A>
</UL>
<!--TOC section Introduction-->
-<H2 CLASS="section"><A NAME="htoc1">1</A> Introduction</H2><!--SEC END -->
+<H2 CLASS="section"><A NAME="htoc1">1</A> <A NAME="intro">Introduction</A></H2><!--SEC END -->
-<A NAME="sec:intr"></A>
+<A NAME="sec:intro"></A>
-<TT>ejabberd</TT> is a free
(GPL) distributed fault-tolerant Jabber/XMPP server and is mainly written in <A HREF="http://www.erlang.org/">Erlang</A>.<BR>
+<TT>ejabberd</TT> is a free
and open source instant messaging server written in <A HREF="http://www.erlang.org/">Erlang</A>.<BR>
<BR>
-<TT>ejabberd</TT> is designed to be a stable, standards compliant, and feature rich Jabber/XMPP server.<BR>
+<TT>ejabberd</TT> is cross-platform, distributed, fault-tolerant, and based on open standards to achieve real-time communication.<BR>
<BR>
-<TT>ejabberd</TT> is suitable for small servers, whether they need to be scalable or not, as well as extremely big servers.<BR>
+<TT>ejabberd</TT> is designed to be a rock-solid and feature rich XMPP server.<BR>
+<BR>
+<TT>ejabberd</TT> is suitable for small deployments, whether they need to be scalable or not, as well as extremely big deployments.<BR>
<BR>
<!--TOC subsection Key Features-->
-<H3 CLASS="subsection"><A NAME="htoc2">1.1</A> Key Features</H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc2">1.1</A> <A NAME="keyfeatures">Key Features</A></H3><!--SEC END -->
<A NAME="sec:keyfeatures"></A>
<TT>ejabberd</TT> is:
<UL CLASS="itemize"><LI CLASS="li-itemize">
-Multiplatform: <TT>ejabberd</TT> runs under Microsoft Windows and Unix derived systems such as Linux, FreeBSD and NetBSD.<BR>
+Cross-platform: <TT>ejabberd</TT> runs under Microsoft Windows and Unix derived systems such as Linux, FreeBSD and NetBSD.<BR>
<BR>
<LI CLASS="li-itemize">Distributed: You can run <TT>ejabberd</TT> on a cluster of machines and all of them will serve the same Jabber domain(s). When you need more capacity you can simply add a new cheap node to your cluster. Accordingly, you do not need to buy an expensive high-end machine to support tens of thousands concurrent users.<BR>
<BR>
-<LI CLASS="li-itemize">Fault-tolerant: You can deploy an <TT>ejabberd</TT> cluster so that all the information required for a properly working service will be replicated permanently on all nodes. This means that if one of the nodes crashes, the others will continue working without disruption. In addition, nodes also can be added or replaced “on the fly”.<BR>
+<LI CLASS="li-itemize">Fault-tolerant: You can deploy an <TT>ejabberd</TT> cluster so that all the information required for a properly working service will be replicated permanently on all nodes. This means that if one of the nodes crashes, the others will continue working without disruption. In addition, nodes also can be added or replaced `on the fly'.<BR>
<BR>
<LI CLASS="li-itemize">Administrator Friendly: <TT>ejabberd</TT> is built on top of the Open Source Erlang. As a result you do not need to install an external database, an external web server, amongst others because everything is already included, and ready to run out of the box. Other administrator benefits include:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Comprehensive documentation.
-<LI CLASS="li-itemize">Straightforward installers for Linux, Mac OS X, and Windows.
+<LI CLASS="li-itemize">Straightforward installers for Linux, Mac OS X, and Windows.<SPAN STYLE="font-variant:small-caps">improved</SPAN>
<LI CLASS="li-itemize">Web interface for administration tasks.
<LI CLASS="li-itemize">Shared Roster Groups.
<LI CLASS="li-itemize">Command line administration tool.
<BR>
<LI CLASS="li-itemize">Open Standards: <TT>ejabberd</TT> is the first Open Source Jabber server claiming to fully comply to the XMPP standard.
<UL CLASS="itemize"><LI CLASS="li-itemize">
-Fully XMPP compliant
-<LI CLASS="li-itemize">XML-based protocol
+Fully XMPP compliant.
+<LI CLASS="li-itemize">XML-based protocol.
<LI CLASS="li-itemize"><A HREF="http://ejabberd.jabber.ru/protocols">Many JEPs supported</A>.
</UL></UL>
<!--TOC subsection Additional Features-->
-<H3 CLASS="subsection"><A NAME="htoc3">1.2</A> Additional Features</H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc3">1.2</A> <A NAME="addfeatures">Additional Features</A></H3><!--SEC END -->
<A NAME="sec:addfeatures"></A>
-Besides common Jabber server features, <TT>ejabberd</TT> comes with a wide range of other features:
+Moreover, <TT>ejabberd</TT> comes with a wide range of other state-of-the-art features:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Modular
<UL CLASS="itemize"><LI CLASS="li-itemize">
Native MySQL support.
<LI CLASS="li-itemize">Native PostgreSQL support.
<LI CLASS="li-itemize">Mnesia.
-<LI CLASS="li-itemize">ODBC data storage support.
-<LI CLASS="li-itemize">Microsoft SQL Server support (via ODBC).
+<LI CLASS="li-itemize">ODBC data storage support.
+<LI CLASS="li-itemize">Microsoft SQL Server support.<SPAN STYLE="font-variant:small-caps">new</SPAN>
</UL>
<LI CLASS="li-itemize">Authentication
<UL CLASS="itemize"><LI CLASS="li-itemize">
-LDAP and ODBC.
+LDAP and ODBC.
<LI CLASS="li-itemize">External Authentication script.
<LI CLASS="li-itemize">Internal Authentication.
</UL>
<LI CLASS="li-itemize">Interface with networks such as AIM, ICQ and MSN.
<LI CLASS="li-itemize">Statistics via Statistics Gathering (<A HREF="http://www.jabber.org/jeps/jep-0039.html">JEP-0039</A>).
<LI CLASS="li-itemize">IPv6 support both for c2s and s2s connections.
-<LI CLASS="li-itemize"><A HREF="http://www.jabber.org/jeps/jep-0045.html">Multi-User Chat</A> module with logging.
+<LI CLASS="li-itemize"><A HREF="http://www.jabber.org/jeps/jep-0045.html">Multi-User Chat</A> module with logging.<SPAN STYLE="font-variant:small-caps">improved</SPAN>
<LI CLASS="li-itemize">Users Directory based on users vCards.
<LI CLASS="li-itemize"><A HREF="http://www.jabber.org/jeps/jep-0060.html">Publish-Subscribe</A> component.
-<LI CLASS="li-itemize">Support for virtual hosting.
+<LI CLASS="li-itemize">Support for virtual hosting.
<LI CLASS="li-itemize"><A HREF="http://www.jabber.org/jeps/jep-0025.html">HTTP Polling</A> service.
<LI CLASS="li-itemize">IRC transport.
</UL>
</UL>
<!--TOC section Installation from Source-->
-<H2 CLASS="section"><A NAME="htoc4">2</A> Installation from Source</H2><!--SEC END -->
+<H2 CLASS="section"><A NAME="htoc4">2</A> <A NAME="installsource">Installation from Source</A></H2><!--SEC END -->
-<A NAME="sec:installation"></A>
+<A NAME="sec:installsource"></A>
<!--TOC subsection Installation Requirements-->
-<H3 CLASS="subsection"><A NAME="htoc5">2.1</A> Installation Requirements</H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc5">2.1</A> <A NAME="installreq">Installation Requirements</A></H3><!--SEC END -->
<A NAME="sec:installreq"></A>
-<!--TOC subsubsection “Unix-like” operating systems-->
-<H4 CLASS="subsubsection"><A NAME="htoc6">2.1.1</A> “Unix-like” operating systems</H4><!--SEC END -->
+<!--TOC subsubsection `Unix-like' operating systems-->
-<A NAME="sec:installrequnix"></A>
+<H4 CLASS="subsubsection"><A NAME="htoc6">2.1.1</A> <A NAME="installrequnix">`Unix-like' operating systems</A></H4><!--SEC END -->
-To compile <TT>ejabberd</TT> on a “Unix-like” operating system, you need:
+<A NAME="sec:installrequnix"></A>
+To compile <TT>ejabberd</TT> on a `Unix-like' operating system, you need:
<UL CLASS="itemize"><LI CLASS="li-itemize">
-GNU Make;
-<LI CLASS="li-itemize">GCC;
-<LI CLASS="li-itemize">libexpat 1.95 or higher;
-<LI CLASS="li-itemize">Erlang/OTP R9C-2 or higher;
-<LI CLASS="li-itemize">OpenSSL 0.9.6 or higher (optional).
-<LI CLASS="li-itemize">Zlib 1.2.3 or higher (optional).
-<LI CLASS="li-itemize">GNU Iconv 1.8 or higher (optional, not needed at all on systems with GNU libc).
+GNU Make
+<LI CLASS="li-itemize">GCC
+<LI CLASS="li-itemize">libexpat 1.95 or higher
+<LI CLASS="li-itemize">Erlang/OTP R9C-2 or higher
+<LI CLASS="li-itemize">OpenSSL 0.9.6 or higher (optional)
+<LI CLASS="li-itemize">Zlib 1.2.3 or higher (optional)
+<LI CLASS="li-itemize">GNU Iconv 1.8 or higher (optional, not needed on systems with GNU libc)
</UL>
<!--TOC subsubsection Windows-->
-<H4 CLASS="subsubsection"><A NAME="htoc7">2.1.2</A> Windows</H4><!--SEC END -->
+<H4 CLASS="subsubsection"><A NAME="htoc7">2.1.2</A> <A NAME="installreqwin">Windows</A></H4><!--SEC END -->
<A NAME="sec:installreqwin"></A>
-
To compile <TT>ejabberd</TT> on a Windows flavour, you need:
<UL CLASS="itemize"><LI CLASS="li-itemize">
MS Visual C++ 6.0 Compiler
</UL>
<!--TOC subsection Obtaining <TT>ejabberd</TT>-->
-<H3 CLASS="subsection"><A NAME="htoc8">2.2</A> Obtaining <TT>ejabberd</TT></H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc8">2.2</A> <A NAME="obtaining">Obtaining <TT>ejabberd</TT></A></H3><!--SEC END -->
<A NAME="sec:obtaining"></A>
</PRE>
<!--TOC subsection Compilation-->
-<H3 CLASS="subsection"><A NAME="htoc9">2.3</A> Compilation</H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc9">2.3</A> <A NAME="compile">Compilation</A></H3><!--SEC END -->
-<A NAME="sec:compilation"></A>
+<A NAME="sec:compile"></A>
-<!--TOC subsubsection “Unix-like” operating systems-->
+<!--TOC subsubsection `Unix-like' operating systems-->
-<H4 CLASS="subsubsection"><A NAME="htoc10">2.3.1</A> “Unix-like” operating systems</H4><!--SEC END -->
+<H4 CLASS="subsubsection"><A NAME="htoc10">2.3.1</A> <A NAME="compileunix">`Unix-like' operating systems</A></H4><!--SEC END -->
-<A NAME="sec:compilationunix"></A>
-
-Compile <TT>ejabberd</TT> on a “Unix-like” operating system by executing:
+<A NAME="sec:compileunix"></A>
+Compile <TT>ejabberd</TT> on a `Unix-like' operating system by executing:
<PRE CLASS="verbatim">
./configure
make
<LI CLASS="li-itemize">install the configuration file into <CODE>/etc/ejabberd</CODE>,
<LI CLASS="li-itemize">create a directory called <CODE>/var/log/ejabberd</CODE> to store log files.
</UL>
+Note: if you want to use an external database, you need to execute the configure
+script with the option(s) <TT>–enable-odbc</TT> or <TT>–enable-odbc
+–enable-mssql</TT>. See section <A HREF="#sec:database">4</A> for more information.<BR>
+<BR>
<!--TOC subsubsection Windows-->
-<H4 CLASS="subsubsection"><A NAME="htoc11">2.3.2</A> Windows</H4><!--SEC END -->
-
-<A NAME="sec:compilationwin"></A>
+<H4 CLASS="subsubsection"><A NAME="htoc11">2.3.2</A> <A NAME="compilewin">Windows</A></H4><!--SEC END -->
+<A NAME="sec:compilewin"></A>
<UL CLASS="itemize"><LI CLASS="li-itemize">
Install Erlang emulator (for example, into <CODE>C:\Program Files\erl5.3</CODE>).
<LI CLASS="li-itemize">Install Expat library into <CODE>C:\Program Files\Expat-1.95.7</CODE>
</PRE></UL>
<!--TOC subsection Starting-->
-<H3 CLASS="subsection"><A NAME="htoc12">2.4</A> Starting</H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc12">2.4</A> <A NAME="start">Starting</A></H3><!--SEC END -->
+
+<A NAME="sec:start"></A>
-<A NAME="sec:starting"></A>
Execute the following command to start <TT>ejabberd</TT>:
<PRE CLASS="verbatim">
<PRE CLASS="verbatim">
erl -pa /var/lib/ejabberd/ebin -sname ejabberd -s ejabberd
</PRE>In the latter case the Erlang node will be identified using only the first part
-of the host name, i. e. other Erlang nodes outside this domain can't contact
+of the host name, i. e. other Erlang nodes outside this domain cannot contact
this node.<BR>
<BR>
Note that when using the above command, <TT>ejabberd</TT> will search for the
export ERL_FULLSWEEP_AFTER=0
</PRE>But in this case <TT>ejabberd</TT> can start to work slower.<BR>
<BR>
-<!--TOC section Configuration-->
+<!--TOC section Basic Configuration-->
-<H2 CLASS="section"><A NAME="htoc13">3</A> Configuration</H2><!--SEC END -->
+<H2 CLASS="section"><A NAME="htoc13">3</A> <A NAME="basicconfig">Basic Configuration</A></H2><!--SEC END -->
-<A NAME="sec:configuration"></A>
-<!--TOC subsection Initial Configuration-->
-
-<H3 CLASS="subsection"><A NAME="htoc14">3.1</A> Initial Configuration</H3><!--SEC END -->
-
-<A NAME="sec:initconfig"></A>
+<A NAME="sec:basicconfig"></A>
The configuration file will be loaded the first time you start <TT>ejabberd</TT>. The
content from this file will be parsed and stored in a database. Subsequently the
configuration file contains a sequence of Erlang terms. Lines beginning with a
<TT>`%'</TT> sign are ignored. Each term is a tuple of which the first element is
the name of an option, and any further elements are that option's values. If the
-configuration file do not contain for instance the “hosts” option, the old
+configuration file do not contain for instance the `hosts' option, the old
host name(s) stored in the database will be used.<BR>
<BR>
You can override the old values stored in the database by adding next lines to
</PRE>With these lines the old global options, local options and ACLs will be removed
before new ones are added.<BR>
<BR>
-<!--TOC subsubsection Host Names-->
+<!--TOC subsection Host Names-->
-<H4 CLASS="subsubsection"><A NAME="htoc15">3.1.1</A> Host Names</H4><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc14">3.1</A> <A NAME="hostnames">Host Names</A></H3><!--SEC END -->
-<A NAME="sec:confighostname"></A>
+<A NAME="sec:hostnames"></A>
The option <TT>hosts</TT> defines a list containing one or more domains that
<TT>ejabberd</TT> will serve.<BR>
Examples:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Serving one domain:
-<UL CLASS="itemize"><LI CLASS="li-itemize">
-<PRE CLASS="verbatim">
+ <PRE CLASS="verbatim">
{hosts, ["example.org"]}.
-</PRE><LI CLASS="li-itemize">Backwards compatibility with older <TT>ejabberd</TT> versions can be retained
- with:
+</PRE><LI CLASS="li-itemize">Serving one domain, and backwards compatible with older <TT>ejabberd</TT>
+ versions:
<PRE CLASS="verbatim">
{host, "example.org"}.
-</PRE></UL>
-<LI CLASS="li-itemize">Serving two domains:
+</PRE><LI CLASS="li-itemize">Serving two domains:
<PRE CLASS="verbatim">
{hosts, ["example.net", "example.com"]}.
</PRE></UL>
-<!--TOC subsubsection Default Language-->
-
-<H4 CLASS="subsubsection"><A NAME="htoc16">3.1.2</A> Default Language</H4><!--SEC END -->
-
-<A NAME="sec:configlanguage"></A>
-
-The option <TT>language</TT> defines the default language of server strings that
-can be seen by Jabber clients. If a Jabber client do not support
-<TT>xml:lang</TT>, the specified language is used. The default value for the
-option <TT>language</TT> is <TT>"en"</TT>. In order to take effect there must be a
-translation file <TT><language>.msg</TT> in <TT>ejabberd</TT>'s <TT>msgs</TT> directory.<BR>
-<BR>
-Examples:
-<UL CLASS="itemize"><LI CLASS="li-itemize">
-To set Russian as default language:
-<PRE CLASS="verbatim">
- {language, "ru"}.
-</PRE><LI CLASS="li-itemize">To set Spanish as default language:
-<PRE CLASS="verbatim">
- {language, "es"}.
-</PRE></UL>
-<!--TOC subsubsection Access Rules-->
+<!--TOC subsection Virtual Hosting-->
-<H4 CLASS="subsubsection"><A NAME="htoc17">3.1.3</A> Access Rules</H4><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc15">3.2</A> <A NAME="virtualhost">Virtual Hosting</A></H3><!--SEC END -->
-<A NAME="sec:configaccess"></A>
+<A NAME="sec:virtualhost"></A>
-Access control in <TT>ejabberd</TT> is performed via Access Control Lists (ACLs). The
-declarations of ACLs in the configuration file have the following syntax:
-<PRE CLASS="verbatim">
- {acl, <aclname>, {<acltype>, ...}}.
-</PRE>
-<TT><acltype></TT> can be one of the following:
-<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
-<B><TT>all</TT></B><DD CLASS="dd-description"> Matches all JIDs. Example:
-<PRE CLASS="verbatim">
-{acl, all, all}.
-</PRE><DT CLASS="dt-description"><B><TT>{user, <username>}</TT></B><DD CLASS="dd-description"> Matches the user with the name
- <TT><username></TT> at the first virtual host. Example:
-<PRE CLASS="verbatim">
-{acl, admin, {user, "yozhik"}}.
-</PRE><DT CLASS="dt-description"><B><TT>{user, <username>, <server>}</TT></B><DD CLASS="dd-description"> Matches the user with the JID
- <TT><username>@<server></TT> and any resource. Example:
-<PRE CLASS="verbatim">
-{acl, admin, {user, "yozhik", "example.org"}}.
-</PRE><DT CLASS="dt-description"><B><TT>{server, <server>}</TT></B><DD CLASS="dd-description"> Matches any JID from server
- <TT><server></TT>. Example:
-<PRE CLASS="verbatim">
-{acl, exampleorg, {server, "example.org"}}.
-</PRE><DT CLASS="dt-description"><B><TT>{user_regexp, <regexp>}</TT></B><DD CLASS="dd-description"> Matches any local user with a name that
- matches <TT><regexp></TT> at the first virtual host. Example:
-<PRE CLASS="verbatim">
-{acl, tests, {user, "^test[0-9]*$"}}.
-</PRE><DT CLASS="dt-description"><B><TT>{user_regexp, <regexp>, <server>}</TT></B><DD CLASS="dd-description"> Matches any user with a name
- that matches <TT><regexp></TT> at server <TT><server></TT>. Example:
-<PRE CLASS="verbatim">
-{acl, tests, {user, "^test", "example.org"}}.
-</PRE><DT CLASS="dt-description"><B><TT>{server_regexp, <regexp>}</TT></B><DD CLASS="dd-description"> Matches any JID from the server that
- matches <TT><regexp></TT>. Example:
-<PRE CLASS="verbatim">
-{acl, icq, {server, "^icq\\."}}.
-</PRE><DT CLASS="dt-description"><B><TT>{node_regexp, <user_regexp>, <server_regexp>}</TT></B><DD CLASS="dd-description"> Matches any user
- with a name that matches <TT><user_regexp></TT> at any server that matches
- <TT><server_regexp></TT>. Example:
-<PRE CLASS="verbatim">
-{acl, yohzik, {node_regexp, "^yohzik$", "^example.(com|org)$"}}.
-</PRE><DT CLASS="dt-description"><B><TT>{user_glob, <glob>}</TT></B><DD CLASS="dd-description">
-<DT CLASS="dt-description"><B><TT>{user_glob, <glob>, <server>}</TT></B><DD CLASS="dd-description">
-<DT CLASS="dt-description"><B><TT>{server_glob, <glob>}</TT></B><DD CLASS="dd-description">
-<DT CLASS="dt-description"><B><TT>{node_glob, <user_glob>, <server_glob>}</TT></B><DD CLASS="dd-description"> This is the same as
- above. However, it uses shell glob patterns instead of regexp. These patterns
- can have the following special characters:
- <DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
- <B><TT>*</TT></B><DD CLASS="dd-description"> matches any string including the null string.
- <DT CLASS="dt-description"><B><TT>?</TT></B><DD CLASS="dd-description"> matches any single character.
- <DT CLASS="dt-description"><B><TT>[...]</TT></B><DD CLASS="dd-description"> matches any of the enclosed characters. Character
- ranges are specified by a pair of characters separated by a <TT>`-'</TT>.
- If the first character after <TT>`['</TT> is a <TT>`!'</TT>, any
- character not enclosed is matched.
- </DL>
-</DL>
-The following ACLs are pre-defined:
-<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
-<B><TT>all</TT></B><DD CLASS="dd-description"> Matches any JID.
-<DT CLASS="dt-description"><B><TT>none</TT></B><DD CLASS="dd-description"> Matches no JID.
-</DL>
-An entry allowing or denying access to different services looks similar to
-this:
-<PRE CLASS="verbatim">
- {access, <accessname>, [{allow, <aclname>},
- {deny, <aclname>},
- ...
- ]}.
-</PRE>When a JID is checked to have access to <TT><accessname></TT>, the server
-sequentially checks if that JID mathes any of the ACLs that are named in the
-second elements of the tuples in the list. If it matches, the first element of
-the first matched tuple is returned, otherwise “<TT>deny</TT>” is returned.<BR>
-<BR>
-Example:
+Options can be defined separately for every virtual host using the
+<TT>host_config</TT> option. It has the following
+syntax:
<PRE CLASS="verbatim">
- {access, configure, [{allow, admin}]}.
- {access, something, [{deny, badmans},
- {allow, all}]}.
+ {host_config, <hostname>, [<option>, <option>, ...]}.
</PRE>
-The following access rules are pre-defined:
-<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
-<B><TT>all</TT></B><DD CLASS="dd-description"> Always returns “<TT>allow</TT>”
-<DT CLASS="dt-description"><B><TT>none</TT></B><DD CLASS="dd-description"> Always returns “<TT>deny</TT>”
-</DL>
-<!--TOC subsubsection Shapers-->
-
-<H4 CLASS="subsubsection"><A NAME="htoc18">3.1.4</A> Shapers</H4><!--SEC END -->
-
-<A NAME="sec:configshaper"></A>
-
-Shapers enable you to limit connection traffic. The syntax of
-shapers is like this:
-<PRE CLASS="verbatim">
- {shaper, <shapername>, <kind>}.
-</PRE>Currently only one kind of shaper called <TT>maxrate</TT> is available. It has the
-following syntax:
-<PRE CLASS="verbatim">
- {maxrate, <rate>}
-</PRE>where <TT><rate></TT> stands for the maximum allowed incomig rate in bytes per
-second.<BR>
-<BR>
Examples:
<UL CLASS="itemize"><LI CLASS="li-itemize">
-To define a shaper named “<TT>normal</TT>” with traffic speed limited to
-1,000 bytes/second:
-<PRE CLASS="verbatim">
- {shaper, normal, {maxrate, 1000}}.
-</PRE><LI CLASS="li-itemize">To define a shaper named “<TT>fast</TT>” with traffic speed limited to
-50,000 bytes/second:
+Domain <TT>example.net</TT> is using the internal authentication method while
+ domain <TT>example.com</TT> is using the LDAP server running on the
+ domain <TT>localhost</TT> to perform authentication:
<PRE CLASS="verbatim">
- {shaper, fast, {maxrate, 50000}}.
-</PRE></UL>
-<!--TOC subsubsection Limitation of the number of opened sessions-->
-
-<H4 CLASS="subsubsection"><A NAME="htoc19">3.1.5</A> Limitation of the number of opened sessions</H4><!--SEC END -->
+{host_config, "example.net", [{auth_method, internal}]}.
-<A NAME="sec:configmaxsessions"></A>
+{host_config, "example.com", [{auth_method, ldap},
+ {ldap_servers, ["localhost"]},
+ {ldap_uidattr, "uid"},
+ {ldap_rootdn, "dc=localdomain"},
+ {ldap_rootdn, "dc=example,dc=com"},
+ {ldap_password, ""}]}.
+</PRE><LI CLASS="li-itemize">Domain <TT>example.net</TT> is using ODBC to perform authentication
+ while domain <TT>example.com</TT> is using the LDAP servers running on the domains
+ <TT>localhost</TT> and <TT>otherhost</TT>:
+<PRE CLASS="verbatim">
+{host_config, "example.net", [{auth_method, odbc},
+ {odbc_server, "DSN=ejabberd;UID=ejabberd;PWD=ejabberd"}]}.
-This option specifies the maximum number of sessions (authenticated
-connections) per user. If a user tries to open more than the maximum number of
-allowed sessions, with different resources, the first opened session will be
-disconnected. The error “<TT>session replaced</TT>” is send to the
-disconnected session. This value is either a number or <TT>infinity</TT>. For
-example <CODE>{max\_user\_sessions, 10}</CODE>. The default value is <TT>10</TT>.<BR>
-<BR>
-This option can be define per virtual host. See section <A HREF="#sec:configvirtualhost">3.1.8</A>.<BR>
-<BR>
-<!--TOC subsubsection Listened Sockets-->
+{host_config, "example.com", [{auth_method, ldap},
+ {ldap_servers, ["localhost", "otherhost"]},
+ {ldap_uidattr, "uid"},
+ {ldap_rootdn, "dc=localdomain"},
+ {ldap_rootdn, "dc=example,dc=com"},
+ {ldap_password, ""}]}.
+</PRE></UL>
+<!--TOC subsection Listened Sockets-->
-<H4 CLASS="subsubsection"><A NAME="htoc20">3.1.6</A> Listened Sockets</H4><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc16">3.3</A> <A NAME="listened">Listened Sockets</A></H3><!--SEC END -->
-<A NAME="sec:configlistened"></A>
+<A NAME="sec:listened"></A>
The option <TT>listen</TT> defines for which addresses and ports <TT>ejabberd</TT>
will listen and what services will be run on them. Each element of the list is a
The following options are available:
<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
<B><TT>{access, <access rule>}</TT></B><DD CLASS="dd-description"> This option defines
- access to the port. The default value is “<TT>all</TT>”.
+ access to the port. The default value is <TT>all</TT>.
<DT CLASS="dt-description"><B><TT>{certfile, Path}</TT></B><DD CLASS="dd-description"> Path to a file containing the SSL certificate.
<DT CLASS="dt-description"><B><TT>{hosts, [Hostnames], [HostOptions]}</TT></B><DD CLASS="dd-description"> This option
defines one or more hostnames of connected services and enables you to
<DT CLASS="dt-description"><B><TT>{ip, IPAddress}</TT></B><DD CLASS="dd-description"> This option specifies which network
interface to listen for. For example <CODE>{ip, {192, 168, 1, 1}}</CODE>.
<DT CLASS="dt-description"><B><TT>{max_stanza_size, Size}</TT></B><DD CLASS="dd-description"> This
- option specifies an approximate maximal size in bytes of XML stanzas.
- For example <CODE>{max\_stanza\_size, 65536}</CODE>. The default value
- is “<TT>infinity</TT>”.
+ option specifies an approximate maximum size in bytes of XML stanzas.
+ Approximate, because it is calculated with the precision of one block of
+ readed data. For example <CODE>{max\_stanza\_size, 65536}</CODE>. The default
+ value is <TT>infinity</TT>.
<DT CLASS="dt-description"><B><TT>{shaper, <access rule>}</TT></B><DD CLASS="dd-description"> This option defines a
- shaper for the port (see section <A HREF="#sec:configshaper">3.1.4</A>). The default value
- is “<TT>none</TT>”.
+ shaper for the port (see section <A HREF="#sec:shapers">3.6</A>). The default value
+ is <TT>none</TT>.
<DT CLASS="dt-description"><B><TT>ssl</TT></B><DD CLASS="dd-description"> This option specifies that traffic on
the port will be encrypted using SSL. You should also set the
<TT>certfile</TT> option. It is recommended to use the <TT>tls</TT> option
should also set the <TT>certfile</TT> option.
<DT CLASS="dt-description"><B><TT>zlib</TT></B><DD CLASS="dd-description"> This
option specifies that Zlib stream compression (as defined in <A HREF="http://www.jabber.org/jeps/jep-0138.html">JEP-0138</A>)
- is available on connections to the port. Client cannot use stream compression and
- stream encryption simultaneously, so if you specify both <TT>tls</TT> (or <TT>ssl</TT>)
- and <TT>zlib</TT> the latter option will not affect connection at all.
+ is available on connections to the port. Client connections cannot use
+ stream compression and stream encryption simultaneously. Hence, if you
+ specify both <TT>tls</TT> (or <TT>ssl</TT>) and <TT>zlib</TT>, the latter
+ option will not affect connections (there will be no stream compression).
<DT CLASS="dt-description"><B><TT>web_admin</TT></B><DD CLASS="dd-description"> This option
enables the web interface for <TT>ejabberd</TT> administration which is available
at <CODE>http://server:port/admin/</CODE>. Login and password are the username and
password of one of the registered users who are granted access by the
- “configure” access rule.
+ `configure' access rule.
</DL>
-Also the following global options are available for s2s connections:
+In addition, the following options are available for s2s connections:
<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
<B><TT>{s2s_use_starttls, true|false}</TT></B><DD CLASS="dd-description">
- This option defines whether to use STARTTLS
- for s2s connections.
- <DT CLASS="dt-description"><B><TT>{s2s_certfile, Path}</TT></B><DD CLASS="dd-description"> Path to the
- file containing the SSL certificate.
+ This option defines whether to
+ use STARTTLS for s2s connections.
+ <DT CLASS="dt-description"><B><TT>{s2s_certfile, Path}</TT></B><DD CLASS="dd-description"> Path to a
+ file containing a SSL certificate.
<DT CLASS="dt-description"><B><TT>{domain_certfile, Domain, Path}</TT></B><DD CLASS="dd-description"> Path
to the file containing the SSL certificate for the specified domain.
</DL>
For instance, the following configuration defines that:
<UL CLASS="itemize"><LI CLASS="li-itemize">
c2s connections are listened for on port 5222 and 5223 (SSL) and denied
- for the user “<TT>bad</TT>”
+ for the user called `<TT>bad</TT>'.
<LI CLASS="li-itemize">s2s connections are listened for on port 5269 with STARTTLS for secured
traffic enabled.
<LI CLASS="li-itemize">Port 5280 is serving the web interface and the HTTP Polling service. Note
that it is also possible to serve them on different ports. The second
- example in section <A HREF="#sec:webadm">3.4.1</A> shows how exactly this can be done.
+ example in section <A HREF="#sec:webinterface">7.1</A> shows how exactly this can be done.
<LI CLASS="li-itemize">All users except for the administrators have a traffic of limit
1,000 Bytes/second
<LI CLASS="li-itemize">The
<A HREF="http://ejabberd.jabber.ru/pyaimt">AIM transport</A>
<TT>aim.example.org</TT> is connected to port 5233 with password
- “<TT>aimsecret</TT>”
+ `<TT>aimsecret</TT>'.
<LI CLASS="li-itemize">The ICQ transport JIT (<TT>icq.example.org</TT> and
<TT>sms.example.org</TT>) is connected to port 5234 with password
- “<TT>jitsecret</TT>”
+ `<TT>jitsecret</TT>'.
<LI CLASS="li-itemize">The
<A HREF="http://ejabberd.jabber.ru/pymsnt">MSN transport</A>
<TT>msn.example.org</TT> is connected to port 5235 with password
- “<TT>msnsecret</TT>”
+ `<TT>msnsecret</TT>'.
<LI CLASS="li-itemize">The
<A HREF="http://ejabberd.jabber.ru/yahoo-transport-2">Yahoo! transport</A>
<TT>yahoo.example.org</TT> is connected to port 5236 with password
- “<TT>yahoosecret</TT>”
+ `<TT>yahoosecret</TT>'.
<LI CLASS="li-itemize">The <A HREF="http://ejabberd.jabber.ru/jabber-gg-transport">Gadu-Gadu transport</A> <TT>gg.example.org</TT> is
- connected to port 5237 with password “<TT>ggsecret</TT>”
+ connected to port 5237 with password `<TT>ggsecret</TT>'.
<LI CLASS="li-itemize">The
<A HREF="http://ejabberd.jabber.ru/jmc">Jabber Mail Component</A>
<TT>jmc.example.org</TT> is connected to port 5238 with password
- “<TT>jmcsecret</TT>”
+ `<TT>jmcsecret</TT>'.
</UL>
<PRE CLASS="verbatim">
{acl, blocked, {user, "bad"}}.
</xdb_file>
</xdb>
</PRE>
-<!--TOC subsubsection Modules-->
+<!--TOC subsection Authentication-->
-<H4 CLASS="subsubsection"><A NAME="htoc21">3.1.7</A> Modules</H4><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc17">3.4</A> <A NAME="auth">Authentication</A></H3><!--SEC END -->
-<A NAME="sec:configmodules"></A>
+<A NAME="sec:auth"></A>
-The option <TT>modules</TT> defines the list of modules that will be loaded after
-<TT>ejabberd</TT>'s startup. Each entry in the list is a tuple in which the first
-element is the name of a module and the second is a list of options for that
-module. Read section <A HREF="#sec:modules">A</A> for detailed information about modules.<BR>
-<BR>
-Examples:
+The option <TT>auth_method</TT> defines the authentication method that is used
+for user authentication:
+<PRE CLASS="verbatim">
+ {auth_method, [<method>]}.
+</PRE>
+The following authentication methods are supported by <TT>ejabberd</TT>:
<UL CLASS="itemize"><LI CLASS="li-itemize">
-In this simple example, only the module <TT>mod_echo</TT> is loaded and no
- options are specified between square brackets:
- <PRE CLASS="verbatim">
- {modules,
- [{mod_echo, []}
- ]}.
-</PRE><LI CLASS="li-itemize">The second example is also simple: the modules <TT>mod_echo</TT>, <TT>mod_time</TT>, and
- <TT>mod_version</TT> are loaded without options. Remark that, besides the last entry,
- all entries end with a comma:
- <PRE CLASS="verbatim">
- {modules,
- [{mod_echo, []},
- {mod_time, []},
- {mod_version, []}
- ]}.
-</PRE></UL>
-<!--TOC subsubsection Virtual Hosting-->
+internal (default) — See section <A HREF="#sec:internalauth">3.4.1</A>.
+<LI CLASS="li-itemize">external — There are <A HREF="http://ejabberd.jabber.ru/extauth">some
+ example authentication scripts</A>.
+<LI CLASS="li-itemize">ldap — See section <A HREF="#sec:ldap">4.5</A>.
+<LI CLASS="li-itemize">odbc — See section <A HREF="#sec:mysql">4.1</A>, <A HREF="#sec:pgsql">4.3</A>,
+ <A HREF="#sec:mssql">4.2</A> and <A HREF="#sec:odbc">4.4</A>.
+<LI CLASS="li-itemize">anonymous — See section <A HREF="#sec:saslanonymous">3.4.2</A>.
+</UL>
+<!--TOC subsubsection Internal-->
-<H4 CLASS="subsubsection"><A NAME="htoc22">3.1.8</A> Virtual Hosting</H4><!--SEC END -->
+<H4 CLASS="subsubsection"><A NAME="htoc18">3.4.1</A> <A NAME="internalauth">Internal</A></H4><!--SEC END -->
-<A NAME="sec:configvirtualhost"></A>
+<A NAME="sec:internalauth"></A>
-Options can be defined separately for every virtual host using the
-<TT>host_config</TT> option. It has the following
-syntax:
-<PRE CLASS="verbatim">
- {host_config, <hostname>, [<option>, <option>, ...]}.
-</PRE>
+<TT>ejabberd</TT> uses its internal Mnesia database as the default authentication method.
+<UL CLASS="itemize"><LI CLASS="li-itemize">
+<TT>auth_method</TT>: The value <TT>internal</TT> will enable the internal
+ authentication method.
+</UL>
Examples:
<UL CLASS="itemize"><LI CLASS="li-itemize">
-Domain <TT>example.net</TT> is using the internal authentication method while
- domain <TT>example.com</TT> is using the LDAP server running on the domain
- <TT>localhost</TT> to perform authentication:
-<PRE CLASS="verbatim">
-{host_config, "example.net", [{auth_method, internal}]}.
-
-{host_config, "example.com", [{auth_method, ldap},
- {ldap_servers, ["localhost"]},
- {ldap_uidattr, "uid"},
- {ldap_rootdn, "dc=localdomain"},
- {ldap_rootdn, "dc=example,dc=com"},
- {ldap_password, ""}]}.
-</PRE><LI CLASS="li-itemize">Domain <TT>example.net</TT> is using ODBC to perform authentication
- while domain <TT>example.com</TT> is using the LDAP servers running on the domains
- <TT>localhost</TT> and <TT>otherhost</TT>:
-<PRE CLASS="verbatim">
-{host_config, "example.net", [{auth_method, odbc},
- {odbc_server, "DSN=ejabberd;UID=ejabberd;PWD=ejabberd"}]}.
-
-{host_config, "example.com", [{auth_method, ldap},
- {ldap_servers, ["localhost", "otherhost"]},
- {ldap_uidattr, "uid"},
- {ldap_rootdn, "dc=localdomain"},
- {ldap_rootdn, "dc=example,dc=com"},
- {ldap_password, ""}]}.
+To use internal authentication on <TT>example.org</TT> and LDAP
+ authentication on <TT>example.net</TT>:
+ <PRE CLASS="verbatim">
+{host_config, "example.org", [{auth_method, [internal]}]}.
+{host_config, "example.net", [{auth_method, [ldap]}]}.
+</PRE><LI CLASS="li-itemize">To use internal authentication on all virtual hosts:
+ <PRE CLASS="verbatim">
+{auth_method, internal}.
</PRE></UL>
-<!--TOC subsubsection SASL anonymous and anonymous login-->
+<!--TOC subsubsection SASL Anonymous and Anonymous Login-->
-<H4 CLASS="subsubsection"><A NAME="htoc23">3.1.9</A> SASL anonymous and anonymous login</H4><!--SEC END -->
+<H4 CLASS="subsubsection"><A NAME="htoc19">3.4.2</A> <A NAME="saslanonymous">SASL Anonymous and Anonymous Login</A></H4><!--SEC END -->
-<A NAME="sec:configsaslanonymous"></A>
+<A NAME="sec:saslanonymous"></A>
-The configuration of the anonymous mode can be done with three
-<TT>host_config</TT> parameters:
-<UL CLASS="itemize"><LI CLASS="li-itemize">
-<TT>auth_method</TT>: This value is used for defining the authentication method:
-internal, odbc, ldap, external). You now have a special extra option to enable
-anonymous mode: anonymous.<BR>
-<BR>
-<LI CLASS="li-itemize"><TT>allow_multiple_connections</TT>: This option can be either true or false and
-is only used when the anonymous mode is enabled. Setting it to true means that
-the same username will be able to be taken several time in anonymous login
-mode if different resource are used to connect. This option is only useful in
-very special cases. It defaults to false.<BR>
-<BR>
+The anonymous authentication method can be configured with the following
+options. Remember that you can use the <TT>host_config</TT> option to set virtual
+host specific options (see section <A HREF="#sec:virtualhost">3.2</A>). Note that there also
+is a detailed tutorial regarding <A HREF="http://support.process-one.net/doc/display/MESSENGER/Anonymous+users+support">SASL
+Anonymous and anonymous login configuration</A>.
+<UL CLASS="itemize"><LI CLASS="li-itemize">
+<TT>auth_method</TT>: The value <TT>anonymous</TT> will enable the anonymous
+ authentication method.
+<LI CLASS="li-itemize"><TT>allow_multiple_connections</TT>: This value for this option can be
+ either <TT>true</TT> or <TT>false</TT> and is only used when the anonymous mode is
+ enabled. Setting it to <TT>true</TT> means that the same username can be taken
+ multiple times in anonymous login mode if different resource are used to
+ connect. This option is only useful in very special occasions. The default
+ value is <TT>false</TT>.
<LI CLASS="li-itemize"><TT>anonymous_protocol</TT>: This option can take three values:
- <TT>sasl_anon</TT>, <TT>login_anon</TT> or both. <TT>sasl_anon</TT> means that
- SASL anonymous mode is enabled. <TT>login_anon</TT> means that anonymous
- login mode is enabled. both means that SASL anonymous and login anonymous are
- enabled.
+ <TT>sasl_anon</TT>, <TT>login_anon</TT> or <TT>both</TT>. <TT>sasl_anon</TT> means
+ that the SASL Anonymous method will be used. <TT>login_anon</TT> means that the
+ anonymous login method will be used. <TT>both</TT> means that SASL Anonymous and
+ login anonymous are both enabled.
</UL>
Those options are defined for each virtual host with the <TT>host_config</TT>
-parameter (see section <A HREF="#sec:configvirtualhost">3.1.8</A>).<BR>
+parameter (see section <A HREF="#sec:virtualhost">3.2</A>).<BR>
<BR>
Examples:
<UL CLASS="itemize"><LI CLASS="li-itemize">
-To enable anonymous login on a virtual host:
-<PRE CLASS="verbatim">
-{host_config, "public.example.org", [{auth_method, anonymous},
+To enable anonymous login on all virtual hosts:
+ <PRE CLASS="verbatim">
+{auth_method, [anonymous]}.
+{anonymous_protocol, login_anon}.
+ </PRE><LI CLASS="li-itemize">Similar as previous example, but limited to <TT>public.example.org</TT>:
+ <PRE CLASS="verbatim">
+{host_config, "public.example.org", [{auth_method, [anonymous]},
{anonymous_protocol, login_anon}]}.
</PRE><LI CLASS="li-itemize">To enable anonymous login and internal authentication on a virtual host:
-<PRE CLASS="verbatim">
{host_config, "public.example.org", [{auth_method, [anonymous,internal]},
{anonymous_protocol, login_anon}]}.
-</PRE><LI CLASS="li-itemize">To enable SASL anonymous on a virtual host:
-<PRE CLASS="verbatim">
+</PRE><LI CLASS="li-itemize">To enable SASL Anonymous on a virtual host:
{host_config, "public.example.org", [{auth_method, [anonymous]},
{anonymous_protocol, sasl_anon}]}.
-</PRE><LI CLASS="li-itemize">To enable SASL anonymous and anonymous login on a virtual host:
-<PRE CLASS="verbatim">
+</PRE><LI CLASS="li-itemize">To enable SASL Anonymous and anonymous login on a virtual host:
{host_config, "public.example.org", [{auth_method, [anonymous]},
{anonymous_protocol, both}]}.
-</PRE><LI CLASS="li-itemize">To enable SASL anonymous, anonymous login and internal authentication on
+</PRE><LI CLASS="li-itemize">To enable SASL Anonymous, anonymous login, and internal authentication on
a virtual host:
-<PRE CLASS="verbatim">
{host_config, "public.example.org", [{auth_method, [anonymous,internal]},
{anonymous_protocol, both}]}.
</PRE></UL>
-A detailled tutorial on SASL anonymous and anonymous login support is
-available from:
-<A HREF="http://support.process-one.net/doc/display/MESSENGER/Anonymous+users+support"><TT>http://support.process-one.net/doc/display/MESSENGER/Anonymous+users+support</TT></A><BR>
-<BR>
-<!--TOC subsection Relational Database Support-->
+<!--TOC subsection Access Rules-->
-<H3 CLASS="subsection"><A NAME="htoc24">3.2</A> Relational Database Support</H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc20">3.5</A> <A NAME="accessrules">Access Rules</A></H3><!--SEC END -->
-<A NAME="sec:relationaldatabase"></A>
-<!--TOC subsubsection Preliminary steps-->
+<A NAME="sec:accessrules"></A>
-<H4 CLASS="subsubsection"><A NAME="htoc25">3.2.1</A> Preliminary steps</H4><!--SEC END -->
-
-<A NAME="sec:relationaldatabasecompilation"></A>
-If you have installed ejabberd using a binary version, the compilation steps
-are not needed as they have already been done correctly.<BR>
-<BR>
-Otherwise, to be able to use ejabberd with a relational database you need to
-enable ODBC modules during compilation, even if you want to use ejabberd with
-MySQL or PostgreSQL in native mode. The following <TT>configure</TT> command can
-be used to enable the relational modules:
+Access control in <TT>ejabberd</TT> is performed via Access Control Lists (ACLs). The
+declarations of ACLs in the configuration file have the following syntax:
<PRE CLASS="verbatim">
-./configure --enable-odbc
+ {acl, <aclname>, {<acltype>, ...}}.
</PRE>
-If you are planning to use Microsoft SQL Server with ODBC, you need to specify
-it from the <TT>configure</TT> command before compilation:
+<TT><acltype></TT> can be one of the following:
+<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
+<B><TT>all</TT></B><DD CLASS="dd-description"> Matches all JIDs. Example:
<PRE CLASS="verbatim">
-./configure --enable-odbc --enable-mssql
-</PRE>
-<!--TOC subsubsection Authentication against a relational database-->
-
-<H4 CLASS="subsubsection"><A NAME="htoc26">3.2.2</A> Authentication against a relational database</H4><!--SEC END -->
-
-<A NAME="sec:relationaldatabaseauth"></A>
-ejabberd use its internal Mnesia database as a default. It is however possible
-to use relational database to store persistant, long-living data. When
-switching the <TT>auth_method</TT> from internal to <TT>odbc</TT>, you are
-telling ejabberd to use a relational database for authentication. Different
-<TT>auth_method</TT> values can be used for different virtual hosts in the
-system.<BR>
-<BR>
-The option value name be misleading, as the method name is use both for access
-to relational database through ODBC or through the native interface. In any
-case, the first step is to define the odbc <TT>auth_method</TT>. For example:
+{acl, all, all}.
+</PRE><DT CLASS="dt-description"><B><TT>{user, <username>}</TT></B><DD CLASS="dd-description"> Matches the user with the name
+ <TT><username></TT> at the first virtual host. Example:
<PRE CLASS="verbatim">
-{host_config, "public.example.org", [{auth_method, [odbc]}]}.
-</PRE>
-The actual database access is defined in the option <TT>odbc_server</TT>. Its
-value is use to defined if we want to use ODBC, or one of the two native
-interface available, PostgreSQL or MySQL.<BR>
-<BR>
-To use a relational database through ODBC, you can pass the ODBC connection
-string as <TT>odbc_server</TT> parameter. For example:
+{acl, admin, {user, "yozhik"}}.
+</PRE><DT CLASS="dt-description"><B><TT>{user, <username>, <server>}</TT></B><DD CLASS="dd-description"> Matches the user with the JID
+ <TT><username>@<server></TT> and any resource. Example:
<PRE CLASS="verbatim">
-{odbc_server, "DSN=database;UID=ejabberd;PWD=password"}.
-</PRE>
-To use the native PostgreSQL interface, you can pass a tuple of the following form as
-parameter:
+{acl, admin, {user, "yozhik", "example.org"}}.
+</PRE><DT CLASS="dt-description"><B><TT>{server, <server>}</TT></B><DD CLASS="dd-description"> Matches any JID from server
+ <TT><server></TT>. Example:
<PRE CLASS="verbatim">
-{pgsql, "Server", "Database", "Username", "Password"}
+{acl, exampleorg, {server, "example.org"}}.
+</PRE><DT CLASS="dt-description"><B><TT>{user_regexp, <regexp>}</TT></B><DD CLASS="dd-description"> Matches any local user with a name that
+ matches <TT><regexp></TT> at the first virtual host. Example:
+<PRE CLASS="verbatim">
+{acl, tests, {user, "^test[0-9]*$"}}.
+</PRE><DT CLASS="dt-description"><B><TT>{user_regexp, <regexp>, <server>}</TT></B><DD CLASS="dd-description"> Matches any user with a name
+ that matches <TT><regexp></TT> at server <TT><server></TT>. Example:
+<PRE CLASS="verbatim">
+{acl, tests, {user, "^test", "example.org"}}.
+</PRE><DT CLASS="dt-description"><B><TT>{server_regexp, <regexp>}</TT></B><DD CLASS="dd-description"> Matches any JID from the server that
+ matches <TT><regexp></TT>. Example:
+<PRE CLASS="verbatim">
+{acl, icq, {server, "^icq\\."}}.
+</PRE><DT CLASS="dt-description"><B><TT>{node_regexp, <user_regexp>, <server_regexp>}</TT></B><DD CLASS="dd-description"> Matches any user
+ with a name that matches <TT><user_regexp></TT> at any server that matches
+ <TT><server_regexp></TT>. Example:
+<PRE CLASS="verbatim">
+{acl, yohzik, {node_regexp, "^yohzik$", "^example.(com|org)$"}}.
+</PRE><DT CLASS="dt-description"><B><TT>{user_glob, <glob>}</TT></B><DD CLASS="dd-description">
+<DT CLASS="dt-description"><B><TT>{user_glob, <glob>, <server>}</TT></B><DD CLASS="dd-description">
+<DT CLASS="dt-description"><B><TT>{server_glob, <glob>}</TT></B><DD CLASS="dd-description">
+<DT CLASS="dt-description"><B><TT>{node_glob, <user_glob>, <server_glob>}</TT></B><DD CLASS="dd-description"> This is the same as
+ above. However, it uses shell glob patterns instead of regexp. These patterns
+ can have the following special characters:
+ <DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
+ <B><TT>*</TT></B><DD CLASS="dd-description"> matches any string including the null string.
+ <DT CLASS="dt-description"><B><TT>?</TT></B><DD CLASS="dd-description"> matches any single character.
+ <DT CLASS="dt-description"><B><TT>[...]</TT></B><DD CLASS="dd-description"> matches any of the enclosed characters. Character
+ ranges are specified by a pair of characters separated by a <TT>`-'</TT>.
+ If the first character after <TT>`['</TT> is a <TT>`!'</TT>, any
+ character not enclosed is matched.
+ </DL>
+</DL>
+The following ACLs are pre-defined:
+<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
+<B><TT>all</TT></B><DD CLASS="dd-description"> Matches any JID.
+<DT CLASS="dt-description"><B><TT>none</TT></B><DD CLASS="dd-description"> Matches no JID.
+</DL>
+An entry allowing or denying access to different services looks similar to
+this:
+<PRE CLASS="verbatim">
+ {access, <accessname>, [{allow, <aclname>},
+ {deny, <aclname>},
+ ...
+ ]}.
+</PRE>When a JID is checked to have access to <TT><accessname></TT>, the server
+sequentially checks if that JID mathes any of the ACLs that are named in the
+second elements of the tuples in the list. If it matches, the first element of
+the first matched tuple is returned, otherwise the value `<TT>deny</TT>' is
+returned.<BR>
+<BR>
+Example:
+<PRE CLASS="verbatim">
+ {access, configure, [{allow, admin}]}.
+ {access, something, [{deny, badmans},
+ {allow, all}]}.
</PRE>
-<TT>pgsql</TT> is a keyword that should be kept as is. For example:
+The following access rules are pre-defined:
+<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
+<B><TT>all</TT></B><DD CLASS="dd-description"> Always returns the value `<TT>allow</TT>'.
+<DT CLASS="dt-description"><B><TT>none</TT></B><DD CLASS="dd-description"> Always returns the value `<TT>deny</TT>'.
+</DL>
+<!--TOC subsection Shapers-->
+
+<H3 CLASS="subsection"><A NAME="htoc21">3.6</A> <A NAME="shapers">Shapers</A></H3><!--SEC END -->
+
+<A NAME="sec:shapers"></A>
+
+Shapers enable you to limit connection traffic. The syntax of
+shapers is like this:
<PRE CLASS="verbatim">
-{odbc_server, {pgsql, "localhost", "database", "ejabberd", "password"}}.
+ {shaper, <shapername>, <kind>}.
+</PRE>Currently only one kind of shaper called <TT>maxrate</TT> is available. It has the
+following syntax:
+<PRE CLASS="verbatim">
+ {maxrate, <rate>}
+</PRE>where <TT><rate></TT> stands for the maximum allowed incomig rate in bytes per
+second.<BR>
+<BR>
+Examples:
+<UL CLASS="itemize"><LI CLASS="li-itemize">
+To define a shaper named `<TT>normal</TT>' with traffic speed limited to
+1,000 bytes/second:
+<PRE CLASS="verbatim">
+ {shaper, normal, {maxrate, 1000}}.
+</PRE><LI CLASS="li-itemize">To define a shaper named `<TT>fast</TT>' with traffic speed limited to
+50,000 bytes/second:
+<PRE CLASS="verbatim">
+ {shaper, fast, {maxrate, 50000}}.
+</PRE></UL>
+<!--TOC subsection Limiting Opened Sessions-->
+
+<H3 CLASS="subsection"><A NAME="htoc22">3.7</A> Limiting Opened Sessions</H3><!--SEC END -->
+
+<A NAME="sec:configmaxsessions"></A>
+
+This option specifies the maximum number of sessions (authenticated
+connections) per user. If a user tries to open more sessions by using different
+resources, the first opened session will be disconnected. The error
+<TT>session replaced</TT> will be sent to the disconnected session. The value
+for this option can be either a number, or <TT>infinity</TT>. The default
+value is <TT>10</TT>.<BR>
+<BR>
+Examples:
+<UL CLASS="itemize"><LI CLASS="li-itemize">
+To limit the number of sessions per user to 10 on all virtual
+hosts:
+<PRE CLASS="verbatim">
+ {max\_user\_sessions, 10}.
+</PRE><LI CLASS="li-itemize">This option can be defined per virtual host (see
+section <A HREF="#sec:virtualhost">3.2</A>). In next example the number of
+sessions per user on the first host is six, while there is no limit on the
+second host:
+<PRE CLASS="verbatim">
+ {host_config, "example.net", [{max\_user\_sessions, 6}]}.
+ {host_config, "example.com", [{max\_user\_sessions, infinity}]}.
+</PRE></UL>
+<!--TOC subsection Default Language-->
+
+<H3 CLASS="subsection"><A NAME="htoc23">3.8</A> <A NAME="language">Default Language</A></H3><!--SEC END -->
+
+<A NAME="sec:language"></A>
+
+The option <TT>language</TT> defines the default language of server strings that
+can be seen by Jabber clients. If a Jabber client do not support
+<TT>xml:lang</TT>, the specified language is used. The default value is
+<TT>en</TT>. In order to take effect there must be a translation file
+<TT><language>.msg</TT> in <TT>ejabberd</TT>'s <TT>msgs</TT> directory.<BR>
+<BR>
+Examples:
+<UL CLASS="itemize"><LI CLASS="li-itemize">
+To set Russian as default language:
+<PRE CLASS="verbatim">
+ {language, "ru"}.
+</PRE><LI CLASS="li-itemize">To set Spanish as default language:
+<PRE CLASS="verbatim">
+ {language, "es"}.
+</PRE></UL>
+<!--TOC section Database Configuration-->
+
+<H2 CLASS="section"><A NAME="htoc24">4</A> <A NAME="database">Database Configuration</A></H2><!--SEC END -->
+
+<A NAME="sec:database"></A>
+
+
+<TT>ejabberd</TT> uses its internal Mnesia database by default. However, it is
+possible to use a relational database or an LDAP server to store persistant,
+long-living data. <TT>ejabberd</TT> is very flexible: you can configure different
+authentication methods for different virtual hosts, you can configure different
+authentication mechanisms for the same virtual host (fallback), you can set
+different storage systems for modules, and so forth.<BR>
+<BR>
+The following databases are supported by <TT>ejabberd</TT>:
+<UL CLASS="itemize"><LI CLASS="li-itemize">
+<A HREF="http://www.microsoft.com/sql/">Microsoft SQL Server</A>
+<LI CLASS="li-itemize"><A HREF="http://www.erlang.org/doc/doc-5.5.1/lib/mnesia-4.3.2/doc/">Mnesia</A>
+<LI CLASS="li-itemize"><A HREF="http://mysql.com/">MySQL</A>
+<LI CLASS="li-itemize"><A HREF="http://en.wikipedia.org/wiki/Open_Database_Connectivity">Any ODBC compatible database</A>
+<LI CLASS="li-itemize"><A HREF="http://www.postgresql.org/">PostgreSQL</A>
+</UL>
+The following LDAP servers are tested with <TT>ejabberd</TT>:
+<UL CLASS="itemize"><LI CLASS="li-itemize">
+<A HREF="http://www.microsoft.com/activedirectory/">Active Directory</A>
+ (see section <A HREF="#sec:ad">4.5.3</A>)
+<LI CLASS="li-itemize"><A HREF="http://www.openldap.org/">OpenLDAP</A>
+<LI CLASS="li-itemize">Normally any LDAP compatible server should work; inform us about your
+ success with a not-listed server so that we can list it here.
+</UL>
+<!--TOC subsection MySQL-->
+
+<H3 CLASS="subsection"><A NAME="htoc25">4.1</A> <A NAME="mysql">MySQL</A></H3><!--SEC END -->
+
+<A NAME="sec:mysql"></A>
+
+Although this section will describe <TT>ejabberd</TT>'s configuration when you want to
+use the native MySQL driver, it does not describe MySQL's installation and
+database creation. Check the MySQL documentation and the tutorial <A HREF="http://support.process-one.net/doc/display/MESSENGER/Using+ejabberd+with+MySQL+native+driver">Using ejabberd with MySQL native driver</A> for information regarding these topics.
+Note that the tutorial contains information about <TT>ejabberd</TT>'s configuration
+which is duplicate to this section.<BR>
+<BR>
+Moreover, the file mysql.sql in the directory src/odbc might be interesting for
+you. This file contains the ejabberd schema for MySQL. At the end of the file
+you can find information to update your database schema.<BR>
+<BR>
+<!--TOC subsubsection Driver Compilation-->
+
+<H4 CLASS="subsubsection"><A NAME="htoc26">4.1.1</A> <A NAME="compilemysql">Driver Compilation</A></H4><!--SEC END -->
+
+<A NAME="sec:compilemysql"></A>
+
+You can skip this step if you installed <TT>ejabberd</TT> using a binary installer or
+if the binary packages of <TT>ejabberd</TT> you are using include support for MySQL.
+<OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
+First, install the <A HREF="http://support.process-one.net/doc/display/CONTRIBS/Yxa">Erlang
+ MySQL library</A>. Make sure the compiled files are in your Erlang path; you can
+ put them for example in the same directory as your ejabberd .beam files.
+<LI CLASS="li-enumerate">Then, configure and install <TT>ejabberd</TT> with ODBC support enabled (this is
+ also needed for native MySQL support!). This can be done, by using next
+ commands:
+ <PRE CLASS="verbatim">
+./configure --enable-odbc && make install
+</PRE></OL>
+<!--TOC subsubsection Authentication-->
+
+<H4 CLASS="subsubsection"><A NAME="htoc27">4.1.2</A> <A NAME="mysqlauth">Authentication</A></H4><!--SEC END -->
+
+<A NAME="sec:mysqlauth"></A>
+
+The option value name may be misleading, as the <TT>auth_method</TT> name is used
+for access to a relational database through ODBC, as well as through the native
+MySQL interface. Anyway, the first configuration step is to define the odbc
+<TT>auth_method</TT>. For example:
+<PRE CLASS="verbatim">
+{host_config, "public.example.org", [{auth_method, [odbc]}]}.
</PRE>
-Note that you need to install the Erlang PgSQL library first. This library is
-available from Sourceforge: <A HREF="http://cvs.sourceforge.net/viewcvs.py/jungerl/jungerl/lib/pgsql/"><TT>http://cvs.sourceforge.net/viewcvs.py/jungerl/jungerl/lib/pgsql/</TT></A><BR>
+The actual database access is defined in the option <TT>odbc_server</TT>. Its
+value is used to define if we want to use ODBC, or one of the two native
+interface available, PostgreSQL or MySQL.<BR>
<BR>
-To use the native MySQL interface, the same tuple should be passed, except
-that you now have to use the <TT>mysql</TT> keyword instead of the <TT>pgsql</TT>
-keyword:
+To use the native MySQL interface, you can pass a tuple of the following form as
+parameter:
<PRE CLASS="verbatim">
{mysql, "Server", "Database", "Username", "Password"}
</PRE>
<PRE CLASS="verbatim">
{odbc_server, {mysql, "localhost", "test", "root", "password"}}.
</PRE>
-Note that you need to install the Erlang MySQL library first. This library is
-directly available from Process-one website: <A HREF="http://support.process-one.net/doc/display/CONTRIBS/Yxa"><TT>http://support.process-one.net/doc/display/CONTRIBS/Yxa</TT></A><BR>
+<!--TOC subsubsection Storage-->
+
+<H4 CLASS="subsubsection"><A NAME="htoc28">4.1.3</A> <A NAME="mysqlstorage">Storage</A></H4><!--SEC END -->
+
+<A NAME="sec:mysqlstorage"></A>
+
+MySQL also can be used to store information into from several <TT>ejabberd</TT>
+modules. See section <A HREF="#sec:modoverview">5.1</A> to see which modules have a version
+with the `_odbc'. This suffix indicates that the module can be used with
+relational databases like MySQL. To enable storage to your database, just make
+sure that your database is running well (see previous sections), and replace the
+suffix-less or ldap module variant with the odbc module variant. Keep in mind
+that you cannot have several variants of the same module loaded!<BR>
+<BR>
+<!--TOC subsection Microsoft SQL Server-->
+
+<H3 CLASS="subsection"><A NAME="htoc29">4.2</A> <A NAME="mssql">Microsoft SQL Server</A></H3><!--SEC END -->
+
+<A NAME="sec:mssql"></A>
+
+Although this section will describe <TT>ejabberd</TT>'s configuration when you want to
+use Microsoft SQL Server, it does not describe Microsoft SQL Server's
+installation and database creation. Check the MySQL documentation and the
+tutorial <A HREF="http://support.process-one.net/doc/display/MESSENGER/Using+ejabberd+with+MySQL+native+driver">Using ejabberd with MySQL native driver</A> for information regarding these topics.
+Note that the tutorial contains information about <TT>ejabberd</TT>'s configuration
+which is duplicate to this section.<BR>
<BR>
-A detailled tutorial to set-up <TT>ejabberd</TT> using the native MySQL interface is
-available from: <A HREF="http://support.process-one.net/doc/display/MESSENGER/Using+ejabberd+with+MySQL+native+driver"><TT>http://support.process-one.net/doc/display/MESSENGER/Using+ejabberd+with+MySQL+native+driver</TT></A><BR>
+Moreover, the file mssql.sql in the directory src/odbc might be interesting for
+you. This file contains the ejabberd schema for Microsoft SQL Server. At the end
+of the file you can find information to update your database schema.<BR>
<BR>
-<!--TOC subsubsection Relational database for other modules-->
+<!--TOC subsubsection Driver Compilation-->
-<H4 CLASS="subsubsection"><A NAME="htoc27">3.2.3</A> Relational database for other modules</H4><!--SEC END -->
+<H4 CLASS="subsubsection"><A NAME="htoc30">4.2.1</A> <A NAME="compilemssql">Driver Compilation</A></H4><!--SEC END -->
-<A NAME="sec:relationaldatabaseextra"></A>
-It is possible to use a relational database to store pieces of
-information. You can do this by changing the module name to a name with an
-<TT>_odbc</TT> suffix in <TT>ejabberd</TT> config file. You can use a relational
-database for the following data:
-<UL CLASS="itemize"><LI CLASS="li-itemize">
-Last connection date and time: Use <TT>mod_last_odbc</TT> instead of
- <TT>mod_last</TT>.
-<LI CLASS="li-itemize">Offline messages: Use <TT>mod_offline_odbc</TT> instead of
- <TT>mod_offline</TT>.
-<LI CLASS="li-itemize">Rosters: Use <TT>mod_roster_odbc</TT> instead of <TT>mod_roster</TT>.
-<LI CLASS="li-itemize">Users' VCARD: Use <TT>mod_vcard_odbc</TT> instead of <TT>mod_vcard</TT>.
-</UL>
-<!--TOC subsection Creating an Initial Administrator-->
+<A NAME="sec:compilemssql"></A>
+
+You can skip this step if you installed <TT>ejabberd</TT> using a binary installer or
+if the binary packages of <TT>ejabberd</TT> you are using include support for ODBC.<BR>
+<BR>
+If you want to use Microsoft SQL Server with ODBC, you need to configure,
+compile and install <TT>ejabberd</TT> with support for ODBC and Microsoft SQL Server
+enabled. This can be done, by using next commands:
+<PRE CLASS="verbatim">
+./configure --enable-odbc --enable-mssql && make install
+</PRE>
+<!--TOC subsubsection Authentication-->
-<H3 CLASS="subsection"><A NAME="htoc28">3.3</A> Creating an Initial Administrator</H3><!--SEC END -->
+<H4 CLASS="subsubsection"><A NAME="htoc31">4.2.2</A> <A NAME="mssqlauth">Authentication</A></H4><!--SEC END -->
-<A NAME="sec:initialadmin"></A>
-Before the web interface can be entered to perform administration tasks, an
-account with administrator rights is needed on your <TT>ejabberd</TT> deployment.<BR>
+<A NAME="sec:mssqlauth"></A>
+
+The configuration of Microsoft SQL Server is the same as the configuration of
+ODBC compatible serers (see section <A HREF="#sec:odbcauth">4.4.2</A>).<BR>
<BR>
-Instructions to create an initial administrator account:
+<!--TOC subsubsection Storage-->
+
+<H4 CLASS="subsubsection"><A NAME="htoc32">4.2.3</A> <A NAME="mssqlstorage">Storage</A></H4><!--SEC END -->
+
+<A NAME="sec:mssqlstorage"></A>
+
+Microsoft SQL Server also can be used to store information into from several
+<TT>ejabberd</TT> modules. See section <A HREF="#sec:modoverview">5.1</A> to see which modules have
+a version with the `_odbc'. This suffix indicates that the module can be used
+with relational databases like Microsoft SQL Server. To enable storage to your
+database, just make sure that your database is running well (see previous
+sections), and replace the suffix-less or ldap module variant with the odbc
+module variant. Keep in mind that you cannot have several variants of the same
+module loaded!<BR>
+<BR>
+<!--TOC subsection PostgreSQL-->
+
+<H3 CLASS="subsection"><A NAME="htoc33">4.3</A> <A NAME="pgsql">PostgreSQL</A></H3><!--SEC END -->
+
+<A NAME="sec:pgsql"></A>
+
+Although this section will describe <TT>ejabberd</TT>'s configuration when you want to
+use the native PostgreSQL driver, it does not describe PostgreSQL's installation
+and database creation. Check the PostgreSQL documentation and the tutorial <A HREF="http://support.process-one.net/doc/display/MESSENGER/Using+ejabberd+with+MySQL+native+driver">Using ejabberd with MySQL native driver</A> for information regarding these topics.
+Note that the tutorial contains information about <TT>ejabberd</TT>'s configuration
+which is duplicate to this section.<BR>
+<BR>
+Also the file pg.sql in the directory src/odbc might be interesting for you.
+This file contains the ejabberd schema for PostgreSQL. At the end of the file
+you can find information to update your database schema.<BR>
+<BR>
+<!--TOC subsubsection Driver Compilation-->
+
+<H4 CLASS="subsubsection"><A NAME="htoc34">4.3.1</A> <A NAME="compilepgsql">Driver Compilation</A></H4><!--SEC END -->
+
+<A NAME="sec:compilepgsql"></A>
+
+You can skip this step if you installed <TT>ejabberd</TT> using a binary installer or
+if the binary packages of <TT>ejabberd</TT> you are using include support for
+PostgreSQL.
<OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
-Register an account on your <TT>ejabberd</TT> deployment. An account can be
- created in two ways:
- <OL CLASS="enumerate" type=a><LI CLASS="li-enumerate">
- Using the tool <TT>ejabberdctl</TT> (see
- section <A HREF="#sec:ejabberdctl">3.4.2</A>):
- <PRE CLASS="verbatim">
-% ejabberdctl node@host register admin example.org password
-</PRE><LI CLASS="li-enumerate">Using In-Band Registration (see section <A HREF="#sec:modregister">A.14</A>): you can
- use a Jabber client to register an account.
- </OL>
-<LI CLASS="li-enumerate">Edit the configuration file to promote the account created in the previous
- step to an account with administrator rights. Note that if you want to add
- more administrators, a seperate acl entry is needed for each administrator.
+First, install the Erlang PgSQL library from
+ <A HREF="http://jungerl.sourceforge.net/">Jungerl</A>. Make sure the compiled
+ files are in your Erlang path; you can put them for example in the same
+ directory as your ejabberd .beam files.
+<LI CLASS="li-enumerate">Then, configure, compile and install <TT>ejabberd</TT> with ODBC support enabled
+ (this is also needed for native PostgreSQL support!). This can be done, by
+ using next commands:
<PRE CLASS="verbatim">
- {acl, admins, {user, "admin", "example.org"}}.
- {access, configure, [{allow, admins}]}.
-</PRE><LI CLASS="li-enumerate">Restart <TT>ejabberd</TT> to load the new configuration.
-<LI CLASS="li-enumerate">Open the web interface (<CODE>http://server:port/admin/</CODE>) in your
- favourite browser. Make sure to enter the <EM>full</EM> JID as username (in this
- example: <TT>admin@example.org</TT>. The reason that you also need to enter the
- suffix, is because <TT>ejabberd</TT>'s virtual hosting support.
-</OL>
-<!--TOC subsection Online Configuration and Monitoring-->
+./configure --enable-odbc && make install
+</PRE></OL>
+<!--TOC subsubsection Authentication-->
-<H3 CLASS="subsection"><A NAME="htoc29">3.4</A> Online Configuration and Monitoring</H3><!--SEC END -->
+<H4 CLASS="subsubsection"><A NAME="htoc35">4.3.2</A> <A NAME="pgsqlauth">Authentication</A></H4><!--SEC END -->
-<A NAME="sec:onlineconfig"></A>
-<!--TOC subsubsection Web Interface-->
+<A NAME="sec:pgsqlauth"></A>
-<H4 CLASS="subsubsection"><A NAME="htoc30">3.4.1</A> Web Interface</H4><!--SEC END -->
+The option value name may be misleading, as the <TT>auth_method</TT> name is used
+for access to a relational database through ODBC, as well as through the native
+PostgreSQL interface. Anyway, the first configuration step is to define the odbc
+<TT>auth_method</TT>. For example:
+<PRE CLASS="verbatim">
+{host_config, "public.example.org", [{auth_method, [odbc]}]}.
+</PRE>
+The actual database access is defined in the option <TT>odbc_server</TT>. Its
+value is used to define if we want to use ODBC, or one of the two native
+interface available, PostgreSQL or MySQL.<BR>
+<BR>
+To use the native PostgreSQL interface, you can pass a tuple of the following
+form as parameter:
+<PRE CLASS="verbatim">
+{pgsql, "Server", "Database", "Username", "Password"}
+</PRE>
+<TT>pgsql</TT> is a keyword that should be kept as is. For example:
+<PRE CLASS="verbatim">
+{odbc_server, {pgsql, "localhost", "database", "ejabberd", "password"}}.
+</PRE>
+<!--TOC subsubsection Storage-->
-<A NAME="sec:webadm"></A>
+<H4 CLASS="subsubsection"><A NAME="htoc36">4.3.3</A> <A NAME="pgsqlstorage">Storage</A></H4><!--SEC END -->
-To perform online configuration of <TT>ejabberd</TT> you need to enable the
-<TT>ejabberd_http</TT> listener with the option <TT>web_admin</TT> (see
-section <A HREF="#sec:configlistened">3.1.6</A>). Then you can open
-<CODE>http://server:port/admin/</CODE> in your favourite web browser. You
-will be asked to enter the username (the <EM>full</EM> Jabber ID) and password
-of an <TT>ejabberd</TT> user with administrator rights. After authentication
-you will see a page similar to figure <A HREF="#fig:webadmmain">1</A>.
-<BLOCKQUOTE CLASS="figure"><DIV CLASS="center"><DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV>
-
- <IMG SRC="webadmmain.png">
-
+<A NAME="sec:pgsqlstorage"></A>
- <BR>
+PostgreSQL also can be used to store information into from several <TT>ejabberd</TT>
+modules. See section <A HREF="#sec:modoverview">5.1</A> to see which modules have a version
+with the `_odbc'. This suffix indicates that the module can be used with
+relational databases like PostgreSQL. To enable storage to your database, just
+make sure that your database is running well (see previous sections), and
+replace the suffix-less or ldap module variant with the odbc module variant.
+Keep in mind that you cannot have several variants of the same module loaded!<BR>
<BR>
-<DIV CLASS="center">Figure 1: Top page from the web interface</DIV><BR>
+<!--TOC subsection ODBC Compatible-->
+
+<H3 CLASS="subsection"><A NAME="htoc37">4.4</A> <A NAME="odbc">ODBC Compatible</A></H3><!--SEC END -->
+
+<A NAME="sec:odbc"></A>
+
+Although this section will describe <TT>ejabberd</TT>'s configuration when you want to
+use the ODBC driver, it does not describe the installation and database creation
+of your database. Check the documentation of your database. The tutorial <A HREF="http://support.process-one.net/doc/display/MESSENGER/Using+ejabberd+with+MySQL+native+driver">Using ejabberd with MySQL native driver</A> also can help you. Note that the tutorial
+contains information about <TT>ejabberd</TT>'s configuration which is duplicate to
+this section.<BR>
<BR>
+<!--TOC subsubsection Compilation-->
- <A NAME="fig:webadmmain"></A>
-<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></DIV></BLOCKQUOTE>
-Here you can edit access restrictions, manage users, create backups,
-manage the database, enable/disable ports listened for, view server
-statistics,...<BR>
+<H4 CLASS="subsubsection"><A NAME="htoc38">4.4.1</A> <A NAME="compileodbc">Compilation</A></H4><!--SEC END -->
+
+<A NAME="sec:compileodbc"></A>
+You can skip this step if you installed <TT>ejabberd</TT> using a binary installer or
+if the binary packages of <TT>ejabberd</TT> you are using include support for
+ODBC.
+<OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
+First, install the <A HREF="http://support.process-one.net/doc/display/CONTRIBS/Yxa">Erlang
+ MySQL library</A>. Make sure the compiled files are in your Erlang path; you can
+ put them for example in the same directory as your ejabberd .beam files.
+<LI CLASS="li-enumerate">Then, configure, compile and install <TT>ejabberd</TT> with ODBC support
+ enabled. This can be done, by using next commands:
+ <PRE CLASS="verbatim">
+./configure --enable-odbc && make install
+</PRE></OL>
+<!--TOC subsubsection Authentication-->
+
+<H4 CLASS="subsubsection"><A NAME="htoc39">4.4.2</A> <A NAME="odbcauth">Authentication</A></H4><!--SEC END -->
+
+<A NAME="sec:odbcauth"></A>
+
+The first configuration step is to define the odbc <TT>auth_method</TT>. For
+example:
+<PRE CLASS="verbatim">
+{host_config, "public.example.org", [{auth_method, [odbc]}]}.
+</PRE>
+The actual database access is defined in the option <TT>odbc_server</TT>. Its
+value is used to defined if we want to use ODBC, or one of the two native
+interface available, PostgreSQL or MySQL.<BR>
<BR>
-Examples:
-<UL CLASS="itemize"><LI CLASS="li-itemize">
-You can serve the web interface on the same port as the
- HTTP Polling interface. In this example
- you should point your web browser to <CODE>http://example.org:5280/admin/</CODE> to
- administer all virtual hosts or to
- <CODE>http://example.org:5280/admin/server/example.com/</CODE> to administer only
- the virtual host <TT>example.com</TT>. Before you get access to the web interface
- you need to enter as username, the JID and password from a registered user
- that is allowed to configure <TT>ejabberd</TT>. In this example you can enter as
- username “<TT>admin@example.net</TT>” to administer all virtual hosts (first
- URL). If you log in with “<TT>admin@example.com</TT>” on<BR>
-<CODE>http://example.org:5280/admin/server/example.com/</CODE> you can only
- administer the virtual host <TT>example.com</TT>.
- <PRE CLASS="verbatim">
- ...
- {acl, admins, {user, "admin", "example.net"}}.
- {host_config, "example.com", [{acl, admins, {user, "admin", "example.com"}}]}.
- {access, configure, [{allow, admins}]}.
- ...
- {hosts, ["example.org"]}.
- ...
- {listen,
- [...
- {5280, ejabberd_http, [http_poll, web_admin]},
- ...
- ]
- }.
-</PRE><LI CLASS="li-itemize">For security reasons, you can serve the web interface on a secured
- connection, on a port differing from the HTTP Polling interface, and bind it
- to the internal LAN IP. The web interface will be accessible by pointing your
- web browser to <CODE>https://192.168.1.1:5280/admin/</CODE>:
- <PRE CLASS="verbatim">
- ...
- {hosts, ["example.org"]}.
- ...
- {listen,
- [...
- {5270, ejabberd_http, [http_poll]},
- {5280, ejabberd_http, [web_admin, {ip, {192, 168, 1, 1}},
- tls, {certfile, "/usr/local/etc/server.pem"}]},
- ...
- ]
- }.
-</PRE></UL>
-<!--TOC subsubsection <TT>ejabberdctl</TT>-->
-
-<H4 CLASS="subsubsection"><A NAME="htoc31">3.4.2</A> <TT>ejabberdctl</TT></H4><!--SEC END -->
-
-<A NAME="sec:ejabberdctl"></A>
-It is possible to do some administration operations using the command
-line tool <TT>ejabberdctl</TT>. You can list all available options by
-running <TT>ejabberdctl</TT> without arguments:
+To use a relational database through ODBC, you can pass the ODBC connection
+string as <TT>odbc_server</TT> parameter. For example:
<PRE CLASS="verbatim">
-% ejabberdctl
-Usage: ejabberdctl node command
-
-Available commands:
- status get ejabberd status
- stop stop ejabberd
- restart restart ejabberd
- reopen-log reopen log file
- register user server password register a user
- unregister user server unregister a user
- backup file store a database backup to file
- restore file restore a database backup from file
- install-fallback file install a database fallback from file
- dump file dump a database to a text file
- load file restore a database from a text file
- import-file file import user data from jabberd 1.4 spool file
- import-dir dir import user data from jabberd 1.4 spool directory
- registered-users list all registered users
- delete-expired-messages delete expired offline messages from database
-
-Example:
- ejabberdctl ejabberd@host restart
+{odbc_server, "DSN=database;UID=ejabberd;PWD=password"}.
</PRE>
-Additional information:
-<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
-<B><TT>reopen-log </TT></B><DD CLASS="dd-description"> If you use a tool to rotate logs, you have to configure it
- so that this command is executed after each rotation.
-<DT CLASS="dt-description"><B><TT>backup, restore, install-fallback, dump, load</TT></B><DD CLASS="dd-description"> You can use these
- commands to create and restore backups.
-<DT CLASS="dt-description"><B><TT>import-file, import-dir</TT></B><DD CLASS="dd-description">
- These options can be used to migrate from other Jabber/XMPP servers. There
- exist tutorials to <A HREF="http://ejabberd.jabber.ru/jabberd1-to-ejabberd">migrate from jabberd 1.4</A>
- and to <A HREF="http://ejabberd.jabber.ru/jabberd2-to-ejabberd">migrate from jabberd2</A>.
-<DT CLASS="dt-description"><B><TT>delete-expired-messages</TT></B><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.
-</DL>
-<!--TOC section Firewall Settings-->
-
-<H2 CLASS="section"><A NAME="htoc32">4</A> Firewall Settings</H2><!--SEC END -->
-
-<A NAME="sec:firewall"></A>
-
-You need to take the following TCP ports in mind when configuring your firewall:
-<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>Port</TD>
-<TD ALIGN=left NOWRAP>Description</TD>
-</TR>
-<TR><TD ALIGN=left NOWRAP>5222</TD>
-<TD ALIGN=left NOWRAP>SASL and unencrypted c2s connections.</TD>
-</TR>
-<TR><TD ALIGN=left NOWRAP>5223</TD>
-<TD ALIGN=left NOWRAP>Obsolete SSL c2s connections.</TD>
-</TR>
-<TR><TD ALIGN=left NOWRAP>5269</TD>
-<TD ALIGN=left NOWRAP>s2s connections.</TD>
-</TR>
-<TR><TD ALIGN=left NOWRAP>4369</TD>
-<TD ALIGN=left NOWRAP>Only for clustering (see <A HREF="#sec:clustering">6</A>).</TD>
-</TR>
-<TR><TD ALIGN=left NOWRAP>port range</TD>
-<TD ALIGN=left NOWRAP>Only for clustring (see <A HREF="#sec:clustering">6</A>). This range
- is configurable (see <A HREF="#sec:starting">2.4</A>).</TD>
-</TR></TABLE>
-<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></DIV></BLOCKQUOTE>
-<!--TOC section SRV Records-->
-
-<H2 CLASS="section"><A NAME="htoc33">5</A> SRV Records</H2><!--SEC END -->
-
-<A NAME="sec:srv"></A>
-
-<UL CLASS="itemize"><LI CLASS="li-itemize">
-General information:
- <A HREF="http://en.wikipedia.org/wiki/SRV_record">SRV record</A>
-<LI CLASS="li-itemize">Practical information:
- <A HREF="http://jabberd.jabberstudio.org/2/docs/section05.html#5_7">Setting DNS SRV Records</A>
-</UL>
-<!--TOC section Clustering-->
-
-<H2 CLASS="section"><A NAME="htoc34">6</A> Clustering</H2><!--SEC END -->
-
-<A NAME="sec:clustering"></A>
+<!--TOC subsubsection Storage-->
-<!--TOC subsection How it Works-->
-
-<H3 CLASS="subsection"><A NAME="htoc35">6.1</A> How it Works</H3><!--SEC END -->
+<H4 CLASS="subsubsection"><A NAME="htoc40">4.4.3</A> <A NAME="odbcstorage">Storage</A></H4><!--SEC END -->
-<A NAME="sec:howitworks"></A>
+<A NAME="sec:odbcstorage"></A>
-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
-have the same magic cookie (see Erlang/OTP documentation, in other words the
-file <TT>~ejabberd/.erlang.cookie</TT> must be the same on all nodes). This is
-needed because all nodes exchange information about connected users, s2s
-connections, registered services, etc...<BR>
+An ODBC compatible database also can be used to store information into from
+several <TT>ejabberd</TT> modules. See section <A HREF="#sec:modoverview">5.1</A> to see which
+modules have a version with the `_odbc'. This suffix indicates that the module
+can be used with ODBC compatible relational databases. To enable storage to your
+database, just make sure that your database is running well (see previous
+sections), and replace the suffix-less or ldap module variant with the odbc
+module variant. Keep in mind that you cannot have several variants of the same
+module loaded!<BR>
<BR>
-Each <TT>ejabberd</TT> node has the following modules:
-<UL CLASS="itemize"><LI CLASS="li-itemize">
-router,
-<LI CLASS="li-itemize">local router,
-<LI CLASS="li-itemize">session manager,
-<LI CLASS="li-itemize">s2s manager.
-</UL>
-<!--TOC subsubsection Router-->
+<!--TOC subsection LDAP-->
-<H4 CLASS="subsubsection"><A NAME="htoc36">6.1.1</A> Router</H4><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc41">4.5</A> <A NAME="ldap">LDAP</A></H3><!--SEC END -->
+<A NAME="sec:ldap"></A>
-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.<BR>
+<TT>ejabberd</TT> has built-in LDAP support. You can authenticate users against LDAP
+server and use LDAP directory as vCard storage. Shared rosters are not supported
+yet.<BR>
<BR>
-<!--TOC subsubsection Local Router-->
-
-<H4 CLASS="subsubsection"><A NAME="htoc37">6.1.2</A> Local Router</H4><!--SEC END -->
+<!--TOC subsubsection Connection-->
+<H4 CLASS="subsubsection"><A NAME="htoc42">4.5.1</A> <A NAME="ldapconnection">Connection</A></H4><!--SEC END -->
-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.<BR>
+<A NAME="sec:ldapconnection"></A>
+Parameters:
+<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
+<B><TT>ldap_server</TT></B><DD CLASS="dd-description"> IP address or dns name of your
+LDAP server. This option is required.
+<DT CLASS="dt-description"><B><TT>ldap_port</TT></B><DD CLASS="dd-description"> Port to connect to your LDAP server.
+ The default value is 389.
+<DT CLASS="dt-description"><B><TT>ldap_rootdn</TT></B><DD CLASS="dd-description"> Bind DN. The default value
+ is <TT>""</TT> which means `anonymous connection'.
+<DT CLASS="dt-description"><B><TT>ldap_password</TT></B><DD CLASS="dd-description"> Bind password. The default
+ value is <TT>""</TT>.
+</DL>
+Example:
+<PRE CLASS="verbatim">
+ {auth_method, ldap}.
+ {ldap_servers, ["ldap.example.org"]}.
+ {ldap_port, 389}.
+ {ldap_rootdn, "cn=Manager,dc=domain,dc=org"}.
+ {ldap_password, "secret"}.
+</PRE>
+Note that current LDAP implementation does not support SSL secured communication
+and SASL authentication.<BR>
<BR>
-<!--TOC subsubsection Session Manager-->
+<!--TOC subsubsection Authentication-->
-<H4 CLASS="subsubsection"><A NAME="htoc38">6.1.3</A> Session Manager</H4><!--SEC END -->
+<H4 CLASS="subsubsection"><A NAME="htoc43">4.5.2</A> <A NAME="ldapauth">Authentication</A></H4><!--SEC END -->
+<A NAME="sec:ldapauth"></A>
+You can authenticate users against an LDAP directory. Available options are:
+<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
+<B><TT>ldap_base</TT></B><DD CLASS="dd-description">LDAP base directory which stores users
+ accounts. This option is required.
+<DT CLASS="dt-description"><B><TT>ldap_uidattr</TT></B><DD CLASS="dd-description">LDAP attribute which holds
+ the user's part of a JID. The default value is <TT>"uid"</TT>.
+<DT CLASS="dt-description"><B><TT>ldap_uidattr_format</TT></B><DD CLASS="dd-description">Format of the
+ <TT>ldap_uidattr</TT> variable. The format <EM>must</EM> contain one and only one
+ pattern variable <TT>"%u"</TT> which will be replaced by the user's part of a
+ JID. For example, <TT>"%u@example.org"</TT>. The default value is <TT>"%u"</TT>.
+<DT CLASS="dt-description"><B><TT>ldap_filter</TT></B><DD CLASS="dd-description">
+ <A HREF="http://www.faqs.org/rfcs/rfc2254.html">RFC 2254</A> LDAP filter. The
+ default is <TT>none</TT>. Example:
+ <TT>"(&(objectClass=shadowAccount)(memberOf=Jabber Users))"</TT>. Please, do
+ not forget to close brackets and do not use superfluous whitespaces. Also you
+ <EM>must not</EM> use <TT>ldap_uidattr</TT> attribute in filter because this
+ attribute will be substituted in LDAP filter automatically.
+</DL>
+<!--TOC subsubsection Examples-->
-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.<BR>
-<BR>
-<!--TOC subsubsection s2s Manager-->
+<H4 CLASS="subsubsection"><A NAME="htoc44">4.5.3</A> <A NAME="ldapexamples">Examples</A></H4><!--SEC END -->
-<H4 CLASS="subsubsection"><A NAME="htoc39">6.1.4</A> s2s Manager</H4><!--SEC END -->
+<A NAME="sec:ldapexamples"></A>
+<!--TOC paragraph Common example-->
+<H5 CLASS="paragraph"><A NAME="ldapcommonexample">Common example</A></H5><!--SEC END -->
-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.<BR>
+Let's say <TT>ldap.example.org</TT> is the name of our LDAP server. We have
+users with their passwords in <TT>"ou=Users,dc=example,dc=org"</TT> directory.
+Also we have addressbook, which contains users emails and their additional
+infos in <TT>"ou=AddressBook,dc=example,dc=org"</TT> directory. Corresponding
+authentication section should looks like this:
+<PRE CLASS="verbatim">
+ %% authentication method
+ {auth_method, ldap}.
+ %% DNS name of our LDAP server
+ {ldap_servers, ["ldap.example.org"]}.
+ %% Bind to LDAP server as "cn=Manager,dc=example,dc=org" with password "secret"
+ {ldap_rootdn, "cn=Manager,dc=example,dc=org"}.
+ {ldap_password, "secret"}.
+ %% define the user's base
+ {ldap_base, "ou=Users,dc=example,dc=org"}.
+ %% We want to authorize users from 'shadowAccount' object class only
+ {ldap_filter, "(objectClass=shadowAccount)"}.
+</PRE>
+Now we want to use users LDAP-info as their vCards. We have four attributes
+defined in our LDAP schema: <TT>"mail"</TT> — email address, <TT>"givenName"</TT>
+— first name, <TT>"sn"</TT> — second name, <TT>"birthDay"</TT> — birthday.
+Also we want users to search each other. Let's see how we can set it up:
+<PRE CLASS="verbatim">
+ {modules,
+ ...
+ {mod_vcard_ldap,
+ [
+ %% We use the same server and port, but want to bind anonymously because
+ %% our LDAP server accepts anonymous requests to
+ %% "ou=AddressBook,dc=example,dc=org" subtree.
+ {ldap_rootdn, ""},
+ {ldap_password, ""},
+ %% define the addressbook's base
+ {ldap_base, "ou=AddressBook,dc=example,dc=org"},
+ %% user's part of JID is located in the "mail" attribute
+ {ldap_uidattr, "mail"},
+ %% common format for our emails
+ {ldap_uidattr_format, "%u@mail.example.org"},
+ %% We have to define empty filter here, because entries in addressbook does not
+ %% belong to shadowAccount object class
+ {ldap_filter, ""},
+ %% Now we want to define vCard pattern
+ {ldap_vcard_map,
+ [{"NICKNAME", "%u", []}, % just use user's part of JID as his nickname
+ {"GIVEN", "%s", ["givenName"]},
+ {"FAMILY", "%s", ["sn"]},
+ {"FN", "%s, %s", ["sn", "givenName"]}, % example: "Smith, John"
+ {"EMAIL", "%s", ["mail"]},
+ {"BDAY", "%s", ["birthDay"]}]},
+ %% Search form
+ {ldap_search_fields,
+ [{"User", "%u"},
+ {"Name", "givenName"},
+ {"Family Name", "sn"},
+ {"Email", "mail"},
+ {"Birthday", "birthDay"}]},
+ %% vCard fields to be reported
+ %% Note that JID is always returned with search results
+ {ldap_search_reported,
+ [{"Full Name", "FN"},
+ {"Nickname", "NICKNAME"},
+ {"Birthday", "BDAY"}]}
+ ]}
+ ...
+ }.
+</PRE>
+Note that <TT>mod_vcard_ldap</TT> module checks for the existence of the user before
+searching in his information in LDAP.<BR>
<BR>
-<!--TOC subsection Clustering Setup-->
+<!--TOC paragraph Active Directory-->
-<H3 CLASS="subsection"><A NAME="htoc40">6.2</A> Clustering Setup</H3><!--SEC END -->
+<H5 CLASS="paragraph"><A NAME="ad">Active Directory</A></H5><!--SEC END -->
-<A NAME="sec:cluster"></A>
+<A NAME="sec:ad"></A>
-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:
-<OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
-Copy <CODE>~ejabberd/.erlang.cookie</CODE> file from <TT>first</TT> to
- <TT>second</TT>.<BR>
-<BR>
-(alt) You can also add “<CODE>-cookie content_of_.erlang.cookie</CODE>”
- option to all “<TT>erl</TT>” commands below.<BR>
-<BR>
-<LI CLASS="li-enumerate">On <TT>second</TT> run as the `<TT>ejabberd</TT>' user in the directory
- where <TT>ejabberd</TT> will work later the following command:
+Active Directory is just an LDAP-server with predefined attributes. A sample
+configuration is showed below:
<PRE CLASS="verbatim">
-erl -sname ejabberd \
- -mnesia extra_db_nodes "['ejabberd@first']" \
- -s mnesia
-</PRE>
- This will start Mnesia serving the same database as <TT>ejabberd@first</TT>.
- You can check this by running the command “<CODE>mnesia:info().</CODE>”. You
- should see a lot of remote tables and a line like the following:
-<PRE CLASS="verbatim">
-running db nodes = [ejabberd@first, ejabberd@second]
-</PRE><BR>
-<BR>
-<LI CLASS="li-enumerate">Now run the following in the same “<TT>erl</TT>” session:
-<PRE CLASS="verbatim">
-mnesia:change_table_copy_type(schema, node(), disc_copies).
+ {auth_method, ldap}.
+ {ldap_servers, ["office.org"]}. % List of LDAP servers
+ {ldap_base, "DC=office,DC=org"}. % Search base of LDAP directory
+ {ldap_rootdn, "CN=Administrator,CN=Users,DC=office,DC=org"}. % LDAP manager
+ {ldap_password, "*******"}. % Password to LDAP manager
+ {ldap_uidattr, "sAMAccountName"}.
+ {ldap_filter, "(memberOf=*)"}.
+
+ {mod_vcard_ldap,
+ [{ldap_vcard_map,
+ [{"NICKNAME", "%u", []},
+ {"GIVEN", "%s", ["givenName"]},
+ {"MIDDLE", "%s", ["initials"]},
+ {"FAMILY", "%s", ["sn"]},
+ {"FN", "%s", ["displayName"]},
+ {"EMAIL", "%s", ["mail"]},
+ {"ORGNAME", "%s", ["company"]},
+ {"ORGUNIT", "%s", ["department"]},
+ {"CTRY", "%s", ["c"]},
+ {"LOCALITY", "%s", ["l"]},
+ {"STREET", "%s", ["streetAddress"]},
+ {"REGION", "%s", ["st"]},
+ {"PCODE", "%s", ["postalCode"]},
+ {"TITLE", "%s", ["title"]},
+ {"URL", "%s", ["wWWHomePage"]},
+ {"DESC", "%s", ["description"]},
+ {"TEL", "%s", ["telephoneNumber"]}]},
+ {ldap_search_fields,
+ [{"User", "%u"},
+ {"Name", "givenName"},
+ {"Family Name", "sn"},
+ {"Email", "mail"},
+ {"Company", "company"},
+ {"Department", "department"},
+ {"Role", "title"},
+ {"Description", "description"},
+ {"Phone", "telephoneNumber"}]},
+ {ldap_search_reported,
+ [{"Full Name", "FN"},
+ {"Nickname", "NICKNAME"},
+ {"Email", "EMAIL"}]}
+ ]
+ }.
</PRE>
- This will create local disc storage for the database.<BR>
-<BR>
-(alt) Change storage type of `<TT>scheme</TT>' table to “RAM and disc
- copy” on the second node via the web interface.<BR>
-<BR>
-<LI CLASS="li-enumerate">Now you can add replicas of various tables to this node with
- “<CODE>mnesia:add_table_copy</CODE>” or
- “<CODE>mnesia:change_table_copy_type</CODE>” as above (just replace
- “<CODE>schema</CODE>” with another table name and “<CODE>disc_copies</CODE>”
- can be replaced with “<CODE>ram_copies</CODE>” or
- “<CODE>disc_only_copies</CODE>”).<BR>
-<BR>
-Which tables to replicate is very dependant on your needs, you can get
- some hints from the command “<CODE>mnesia:info().</CODE>”, by looking at the
- size of tables and the default storage type for each table on 'first'.<BR>
-<BR>
-Replicating a table makes lookups in this table faster on this node.
- Writing, on the other hand, will be slower. And of course if machine with one
- of the replicas is down, other replicas will be used.<BR>
-<BR>
-Also <A HREF="http://www.erlang.se/doc/doc-5.4.9/lib/mnesia-4.2.2/doc/html/Mnesia_chap5.html#5.3">section 5.3 (Table Fragmentation) of Mnesia User's Guide</A> can be helpful.
- <BR>
-<BR>
- (alt) Same as in previous item, but for other tables.<BR>
-<BR>
-<LI CLASS="li-enumerate">Run “<CODE>init:stop().</CODE>” or just “<CODE>q().</CODE>” to exit from
- the Erlang shell. This probably can take some time if Mnesia has not yet
- transfered and processed all data it needed from <TT>first</TT>.<BR>
-<BR>
-<LI CLASS="li-enumerate">Now run <TT>ejabberd</TT> on <TT>second</TT> with almost the same config as
- on <TT>first</TT> (you probably don't need to duplicate “<CODE>acl</CODE>”
- and “<CODE>access</CODE>” options — they will be taken from
- <TT>first</TT>, and <CODE>mod_muc</CODE> and <CODE>mod_irc</CODE> should be
- enabled only on one machine in the cluster).
-</OL>
-You can repeat these steps for other machines supposed to serve this
-domain.<BR>
-<BR>
-
-<!--TOC section Built-in Modules-->
+<!--TOC section Modules Configuration-->
-<H2 CLASS="section"><A NAME="htoc41">A</A> Built-in Modules</H2><!--SEC END -->
+<H2 CLASS="section"><A NAME="htoc45">5</A> <A NAME="modules">Modules Configuration</A></H2><!--SEC END -->
<A NAME="sec:modules"></A>
+The option <TT>modules</TT> defines the list of modules that will be loaded after
+<TT>ejabberd</TT>'s startup. Each entry in the list is a tuple in which the first
+element is the name of a module and the second is a list of options for that
+module.<BR>
+<BR>
+Examples:
+<UL CLASS="itemize"><LI CLASS="li-itemize">
+In this example only the module <TT>mod_echo</TT> is loaded and no module
+ options are specified between the square brackets:
+ <PRE CLASS="verbatim">
+ {modules,
+ [{mod_echo, []}
+ ]}.
+</PRE><LI CLASS="li-itemize">In the second example the modules <TT>mod_echo</TT>, <TT>mod_time</TT>, and
+ <TT>mod_version</TT> are loaded without options. Remark that, besides the last entry,
+ all entries end with a comma:
+ <PRE CLASS="verbatim">
+ {modules,
+ [{mod_echo, []},
+ {mod_time, []},
+ {mod_version, []}
+ ]}.
+</PRE></UL>
<!--TOC subsection Overview-->
-<H3 CLASS="subsection"><A NAME="htoc42">A.1</A> Overview</H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc46">5.1</A> <A NAME="modoverview">Overview</A></H3><!--SEC END -->
<A NAME="sec:modoverview"></A>
The following table lists all modules available in the official <TT>ejabberd</TT>
distribution. You can find more
<A HREF="http://ejabberd.jabber.ru/contributions">contributed modules</A> on the
-ejabberd website. Please remember that these contributions might not work or
+<TT>ejabberd</TT> website. Please remember that these contributions might not work or
that they can contain severe bugs and security leaks. Therefore, use them at
your own risk!<BR>
<BR>
You can see which database backend each module needs by looking at the suffix:
<UL CLASS="itemize"><LI CLASS="li-itemize">
-“_ldap”, this means that the module needs an LDAP server as backend.
-<LI CLASS="li-itemize">“_odbc”, this means that the module needs an ODBC compatible database,
- a MySQL database, or a PostgreSQL database as backend.
-<LI CLASS="li-itemize">Nothing, this means that the modules uses Erlang's built-in database
+`_ldap', this means that the module needs an LDAP server as backend.
+<LI CLASS="li-itemize">`_odbc', this means that the module needs a supported database
+ (see <A HREF="#sec:database">4</A>) as backend.
+<LI CLASS="li-itemize">No suffix, this means that the modules uses Erlang's built-in database
Mnesia as backend.
</UL>
+If you want to
+It is possible to use a relational database to store pieces of
+information. You can do this by changing the module name to a name with an
+<TT>_odbc</TT> suffix in <TT>ejabberd</TT> config file. You can use a relational
+database for the following data:
+<UL CLASS="itemize"><LI CLASS="li-itemize">
+Last connection date and time: Use <TT>mod_last_odbc</TT> instead of
+ <TT>mod_last</TT>.
+<LI CLASS="li-itemize">Offline messages: Use <TT>mod_offline_odbc</TT> instead of
+ <TT>mod_offline</TT>.
+<LI CLASS="li-itemize">Rosters: Use <TT>mod_roster_odbc</TT> instead of <TT>mod_roster</TT>.
+<LI CLASS="li-itemize">Users' VCARD: Use <TT>mod_vcard_odbc</TT> instead of <TT>mod_vcard</TT>.
+</UL>
<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>Module</TD>
<TD ALIGN=left NOWRAP>No</TD>
</TR>
<TR><TD ALIGN=left NOWRAP> </TD>
-<TD ALIGN=left NOWRAP>configuration of ejabberd</TD>
+<TD ALIGN=left NOWRAP>configuration of <TT>ejabberd</TT></TD>
<TD ALIGN=left NOWRAP> </TD>
<TD ALIGN=left NOWRAP> </TD>
</TR>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>mod_last_odbc</TT></TD>
<TD ALIGN=left NOWRAP>Last Activity (<A HREF="http://www.jabber.org/jeps/jep-0012.html">JEP-0012</A>)</TD>
-<TD ALIGN=left NOWRAP>ODBC compatible</TD>
+<TD ALIGN=left NOWRAP>supported database (*)</TD>
<TD ALIGN=left NOWRAP>No</TD>
</TR>
-<TR><TD ALIGN=left NOWRAP> </TD>
-<TD ALIGN=left NOWRAP> </TD>
-<TD ALIGN=left NOWRAP>database, MySQL</TD>
-<TD ALIGN=left NOWRAP> </TD>
-</TR>
-<TR><TD ALIGN=left NOWRAP> </TD>
-<TD ALIGN=left NOWRAP> </TD>
-<TD ALIGN=left NOWRAP>or PostgreSQL</TD>
-<TD ALIGN=left NOWRAP> </TD>
-</TR>
<TR><TD ALIGN=left NOWRAP><TT>mod_muc</TT></TD>
<TD ALIGN=left NOWRAP>Multi-User Chat (<A HREF="http://www.jabber.org/jeps/jep-0045.html">JEP-0045</A>)</TD>
<TD ALIGN=left NOWRAP> </TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>mod_offline_odbc</TT></TD>
<TD ALIGN=left NOWRAP>Offline message storage</TD>
-<TD ALIGN=left NOWRAP>ODBC compatible</TD>
+<TD ALIGN=left NOWRAP>supported database (*)</TD>
<TD ALIGN=left NOWRAP>No</TD>
</TR>
-<TR><TD ALIGN=left NOWRAP> </TD>
-<TD ALIGN=left NOWRAP> </TD>
-<TD ALIGN=left NOWRAP>database, MySQL</TD>
-<TD ALIGN=left NOWRAP> </TD>
-</TR>
-<TR><TD ALIGN=left NOWRAP> </TD>
-<TD ALIGN=left NOWRAP> </TD>
-<TD ALIGN=left NOWRAP>or PostgreSQL</TD>
-<TD ALIGN=left NOWRAP> </TD>
-</TR>
<TR><TD ALIGN=left NOWRAP><TT>mod_privacy</TT></TD>
<TD ALIGN=left NOWRAP>Blocking Communication</TD>
<TD ALIGN=left NOWRAP> </TD>
<TR><TD ALIGN=left NOWRAP><TT>mod_roster</TT></TD>
<TD ALIGN=left NOWRAP>Roster management</TD>
<TD ALIGN=left NOWRAP> </TD>
-<TD ALIGN=left NOWRAP>Yes (*)</TD>
+<TD ALIGN=left NOWRAP>Yes (**)</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>mod_roster_odbc</TT></TD>
<TD ALIGN=left NOWRAP>Roster management</TD>
-<TD ALIGN=left NOWRAP>ODBC compatible</TD>
-<TD ALIGN=left NOWRAP>Yes (*)</TD>
-</TR>
-<TR><TD ALIGN=left NOWRAP> </TD>
-<TD ALIGN=left NOWRAP> </TD>
-<TD ALIGN=left NOWRAP>database, MySQL</TD>
-<TD ALIGN=left NOWRAP> </TD>
-</TR>
-<TR><TD ALIGN=left NOWRAP> </TD>
-<TD ALIGN=left NOWRAP> </TD>
-<TD ALIGN=left NOWRAP>or PostgreSQL</TD>
-<TD ALIGN=left NOWRAP> </TD>
+<TD ALIGN=left NOWRAP>supported database (*)</TD>
+<TD ALIGN=left NOWRAP>Yes (**)</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>mod_service_log</TT></TD>
<TD ALIGN=left NOWRAP>Copy user messages to logger service</TD>
</TR>
<TR><TD ALIGN=left NOWRAP><TT>mod_vcard_odbc</TT></TD>
<TD ALIGN=left NOWRAP>vcard-temp (<A HREF="http://www.jabber.org/jeps/jep-0054.html">JEP-0054</A>)</TD>
-<TD ALIGN=left NOWRAP>ODBC compatible</TD>
+<TD ALIGN=left NOWRAP>supported database (*)</TD>
<TD ALIGN=left NOWRAP>No</TD>
</TR>
-<TR><TD ALIGN=left NOWRAP> </TD>
-<TD ALIGN=left NOWRAP> </TD>
-<TD ALIGN=left NOWRAP>database, MySQL</TD>
-<TD ALIGN=left NOWRAP> </TD>
-</TR>
-<TR><TD ALIGN=left NOWRAP> </TD>
-<TD ALIGN=left NOWRAP> </TD>
-<TD ALIGN=left NOWRAP>or PostgreSQL</TD>
-<TD ALIGN=left NOWRAP> </TD>
-</TR>
<TR><TD ALIGN=left NOWRAP><TT>mod_version</TT></TD>
<TD ALIGN=left NOWRAP>Software Version (<A HREF="http://www.jabber.org/jeps/jep-0092.html">JEP-0092</A>)</TD>
<TD ALIGN=left NOWRAP> </TD>
<TD ALIGN=left NOWRAP>No</TD>
</TR></TABLE>
<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></DIV></BLOCKQUOTE>
-(*) This module or a similar one with another database backend is needed for
-XMPP compliancy.<BR>
-<BR>
+<UL CLASS="itemize"><LI CLASS="li-itemize">
+(*) For a list of supported databases, see section <A HREF="#sec:database">4</A>.
+<LI CLASS="li-itemize">(**) This module or a similar one with another database backend is needed for
+XMPP compliancy.
+</UL>
<!--TOC subsection Common Options-->
-<H3 CLASS="subsection"><A NAME="htoc43">A.2</A> Common Options</H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc47">5.2</A> <A NAME="modcommonoptions">Common Options</A></H3><!--SEC END -->
-<A NAME="sec:modcommonopts"></A>
+<A NAME="sec:modcommonoptions"></A>
The following options are used by many modules. Therefore, they are described in
this separate section.<BR>
<BR>
<!--TOC subsubsection <TT>iqdisc</TT>-->
-<H4 CLASS="subsubsection"><A NAME="htoc44">A.2.1</A> <TT>iqdisc</TT></H4><!--SEC END -->
+<H4 CLASS="subsubsection"><A NAME="htoc48">5.2.1</A> <A NAME="modiqdiscoption"><TT>iqdisc</TT></A></H4><!--SEC END -->
<A NAME="sec:modiqdiscoption"></A>
</PRE>
<!--TOC subsubsection <TT>hosts</TT>-->
-<H4 CLASS="subsubsection"><A NAME="htoc45">A.2.2</A> <TT>hosts</TT></H4><!--SEC END -->
+<H4 CLASS="subsubsection"><A NAME="htoc49">5.2.2</A> <A NAME="modhostsoption"><TT>hosts</TT></A></H4><!--SEC END -->
<A NAME="sec:modhostsoption"></A>
{mod_echo, [{hosts, ["echo.example.org"]}]},
...
]}.
-</PRE><LI CLASS="li-itemize">Backwards compatibility with older ejabberd versions can be retained
+</PRE><LI CLASS="li-itemize">Backwards compatibility with older <TT>ejabberd</TT> versions can be retained
with:
<PRE CLASS="verbatim">
{modules,
</PRE></UL>
<!--TOC subsection <TT>mod_announce</TT>-->
-<H3 CLASS="subsection"><A NAME="htoc46">A.3</A> <TT>mod_announce</TT></H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc50">5.3</A> <A NAME="modannounce"><TT>mod_announce</TT></A></H3><!--SEC END -->
<A NAME="sec:modannounce"></A>
to several resources, only the resource with the highest priority will receive
the message. If the registered user is not connected, the message will be
stored offline in assumption that offline storage
- (see section <A HREF="#sec:modoffline">A.10</A>) is enabled.
+ (see section <A HREF="#sec:modoffline">5.10</A>) is enabled.
<DT CLASS="dt-description"><B><TT>example.org/announce/online (example.org/announce/all-hosts/online)</TT></B><DD CLASS="dd-description">The
message is sent to all connected users. If the user is online and connected
to several resources, all resources will receive the message.
</PRE></UL>
<!--TOC subsection <TT>mod_disco</TT>-->
-<H3 CLASS="subsection"><A NAME="htoc47">A.4</A> <TT>mod_disco</TT></H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc51">5.4</A> <A NAME="moddisco"><TT>mod_disco</TT></A></H3><!--SEC END -->
<A NAME="sec:moddisco"></A>
<B><TT>iqdisc</TT></B><DD CLASS="dd-description"> This specifies
the processing discipline for Service Discovery (<TT>http://jabber.org/protocol/disco#items</TT> and
<TT>http://jabber.org/protocol/disco#info</TT>) IQ queries
-(see section <A HREF="#sec:modiqdiscoption">A.2.1</A>).
+(see section <A HREF="#sec:modiqdiscoption">5.2.1</A>).
<DT CLASS="dt-description"><B><TT>extra_domains</TT></B><DD CLASS="dd-description"> With this option,
extra domains can be added to the Service Discovery item list.
</DL>
</PRE></UL>
<!--TOC subsection <TT>mod_echo</TT>-->
-<H3 CLASS="subsection"><A NAME="htoc48">A.5</A> <TT>mod_echo</TT></H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc52">5.5</A> <A NAME="modecho"><TT>mod_echo</TT></A></H3><!--SEC END -->
<A NAME="sec:modecho"></A>
<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
<B><TT>hosts</TT></B><DD CLASS="dd-description"> This option defines the hostnames of the
- service (see section <A HREF="#sec:modhostsoption">A.2.2</A>). If neither <TT>hosts</TT> nor
- the old <TT>host</TT> is present, the prefix “<TT>echo.</TT>” is added to all
+ service (see section <A HREF="#sec:modhostsoption">5.2.2</A>). If neither <TT>hosts</TT> nor
+ the old <TT>host</TT> is present, the prefix `<TT>echo.</TT>' is added to all
<TT>ejabberd</TT> hostnames.
</DL>
...
]}.
</PRE><LI CLASS="li-itemize">If you still do not understand the inner workings of <TT>mod_echo</TT>,
- you can find a few more examples in section <A HREF="#sec:modhostsoption">A.2.2</A>.
+ you can find a few more examples in section <A HREF="#sec:modhostsoption">5.2.2</A>.
</UL>
<!--TOC subsection <TT>mod_irc</TT>-->
-<H3 CLASS="subsection"><A NAME="htoc49">A.6</A> <TT>mod_irc</TT></H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc53">5.6</A> <A NAME="modirc"><TT>mod_irc</TT></A></H3><!--SEC END -->
<A NAME="sec:modirc"></A>
End user information:
<UL CLASS="itemize"><LI CLASS="li-itemize">
-A Jabber client with “groupchat 1.0” support or Multi-User
+A Jabber client with `groupchat 1.0' support or Multi-User
Chat support (<A HREF="http://www.jabber.org/jeps/jep-0045.html">JEP-0045</A>) is necessary to join IRC channels.
<LI CLASS="li-itemize">An IRC channel can be joined in nearly the same way as joining a
Jabber Multi-User Chat room. The difference is that the room name will
- be “channel%<TT>irc.example.org</TT>” in case <TT>irc.example.org</TT> is
- the IRC server hosting “channel”. And of course the host should point
+ be `channel%<TT>irc.example.org</TT>' in case <TT>irc.example.org</TT> is
+ the IRC server hosting `channel'. And of course the host should point
to the IRC transport instead of the Multi-User Chat service.
-<LI CLASS="li-itemize">You can register your nickame by sending “IDENTIFY password” to<BR>
+<LI CLASS="li-itemize">You can register your nickame by sending `IDENTIFY password' to<BR>
<TT>nickserver!irc.example.org@irc.jabberserver.org</TT>.
-<LI CLASS="li-itemize">Entering your password is possible by sending “LOGIN nick password”<BR>
+<LI CLASS="li-itemize">Entering your password is possible by sending `LOGIN nick password'<BR>
to <TT>nickserver!irc.example.org@irc.jabberserver.org</TT>.
<LI CLASS="li-itemize">When using a popular Jabber server, it can occur that no
connection can be achieved with some IRC servers because they limit the
<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
<B><TT>hosts</TT></B><DD CLASS="dd-description"> This option defines the hostnames of the
- service (see section <A HREF="#sec:modhostsoption">A.2.2</A>). If neither <TT>hosts</TT> nor
- the old <TT>host</TT> is present, the prefix “<TT>irc.</TT>” is added to all
+ service (see section <A HREF="#sec:modhostsoption">5.2.2</A>). If neither <TT>hosts</TT> nor
+ the old <TT>host</TT> is present, the prefix `<TT>irc.</TT>' is added to all
<TT>ejabberd</TT> hostnames.
<DT CLASS="dt-description"><B><TT>access</TT></B><DD CLASS="dd-description"> This option can be used to specify who
Examples:
<UL CLASS="itemize"><LI CLASS="li-itemize">
In the first example, the IRC transport is available on (all) your
- virtual host(s) with the prefix “<TT>irc.</TT>”. Furthermore, anyone is
+ virtual host(s) with the prefix `<TT>irc.</TT>'. Furthermore, anyone is
able to use the transport.
<PRE CLASS="verbatim">
{modules,
</PRE></UL>
<!--TOC subsection <TT>mod_last</TT>-->
-<H3 CLASS="subsection"><A NAME="htoc50">A.7</A> <TT>mod_last</TT></H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc54">5.7</A> <A NAME="modlast"><TT>mod_last</TT></A></H3><!--SEC END -->
<A NAME="sec:modlast"></A>
<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
<B><TT>iqdisc</TT></B><DD CLASS="dd-description"> This specifies
the processing discipline for Last activity (<TT>jabber:iq:last</TT>) IQ queries
-(see section <A HREF="#sec:modiqdiscoption">A.2.1</A>).
+(see section <A HREF="#sec:modiqdiscoption">5.2.1</A>).
</DL>
<!--TOC subsection <TT>mod_muc</TT>-->
-<H3 CLASS="subsection"><A NAME="htoc51">A.8</A> <TT>mod_muc</TT></H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc55">5.8</A> <A NAME="modmuc"><TT>mod_muc</TT></A></H3><!--SEC END -->
<A NAME="sec:modmuc"></A>
<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
<B><TT>hosts</TT></B><DD CLASS="dd-description"> This option defines the hostnames of the
- service (see section <A HREF="#sec:modhostsoption">A.2.2</A>). If neither <TT>hosts</TT> nor
- the old <TT>host</TT> is present, the prefix “<TT>conference.</TT>” is added to all
+ service (see section <A HREF="#sec:modhostsoption">5.2.2</A>). If neither <TT>hosts</TT> nor
+ the old <TT>host</TT> is present, the prefix `<TT>conference.</TT>' is added to all
<TT>ejabberd</TT> hostnames.
<DT CLASS="dt-description"><B><TT>access</TT></B><DD CLASS="dd-description"> You can specify who is allowed to use
value is <TT>none</TT>, which means that only the room creator can
administer his room). By sending a message to the service JID,
administrators can send service messages that will be displayed in every
- active room.<BR>
-<BR>
-<DT CLASS="dt-description"><B><TT>history_size</TT></B><DD CLASS="dd-description"> a small history of the
- current discussion is send to users when they enter the room. This option make
- it possible to define the number of history messages to keep and send to the
- user joining the room. The value is a integer. Setting the value to <TT>0</TT>
- disable the history feature and nothing is kept in memory. The default value
- is <TT>20</TT>. This value is global and affects all MUC rooms on the server.
+ active room.
+<DT CLASS="dt-description"><B><TT>history_size</TT></B><DD CLASS="dd-description"> A small history of the
+ current discussion is sent to users when they enter the room. With this option
+ you can define the number of history messages to keep and send to users
+ joining the room. The value is an integer. Setting the value to <TT>0</TT>
+ disables the history feature and, as a result, nothing is kept in memory. The
+ default value is <TT>20</TT>. This value is global and thus affects all rooms on
+ the server.
</DL>
Examples:
<UL CLASS="itemize"><LI CLASS="li-itemize">
service. Everyone will also be able to create new rooms but only the user
<TT>admin@example.org</TT> is allowed to administrate any room. In this
example he is also a global administrator. When <TT>admin@example.org</TT>
- sends a message such as “Tomorrow, the Jabber server will be moved
+ sends a message such as `Tomorrow, the Jabber server will be moved
to new hardware. This will involve service breakdowns around 23:00 UMT.
- We apologise for this inconvenience.” to <TT>conference.example.org</TT>,
+ We apologise for this inconvenience.' to <TT>conference.example.org</TT>,
it will be displayed in all active rooms. In this example the history
feature is disabled.
<PRE CLASS="verbatim">
paying customers registered on our domains and on other servers. Of course
the administrator is also allowed to access rooms. In addition, he is the
only authority able to create and administer rooms. When
- <TT>admin@example.org</TT> sends a message such as “Tomorrow, the Jabber
+ <TT>admin@example.org</TT> sends a message such as `Tomorrow, the Jabber
server will be moved to new hardware. This will involve service breakdowns
- around 23:00 UMT. We apologise for this inconvenience.” to
+ around 23:00 UMT. We apologise for this inconvenience.' to
<TT>conference.example.org</TT>, it will be displayed in all active rooms. No
<TT>history_size</TT> option is used, this means that the feature is enabled
and the default value of 20 history messages will be send to the users.
</PRE></UL>
<!--TOC subsection <TT>mod_muc_log</TT>-->
-<H3 CLASS="subsection"><A NAME="htoc52">A.9</A> <TT>mod_muc_log</TT></H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc56">5.9</A> <A NAME="modmuclog"><TT>mod_muc_log</TT></A></H3><!--SEC END -->
<A NAME="sec:modmuclog"></A>
-This module enables optional logging of Multi-User Chat conversations to HTML.
-Once you enable this module, join a chatroom with enought privileges using a MUC capable Jabber client,
-request the configuration form and there you will have an option to enable chatroom logging.<BR>
+This module enables optional logging of Multi-User Chat (MUC) conversations to
+HTML. Once you enable this module, users can join a chatroom using a MUC capable
+Jabber client, and if they have enough privileges, they can request the
+configuration form in which they can set the option to enable chatroom logging.<BR>
<BR>
-Some of the features of generated logs:
+Features:
<UL CLASS="itemize"><LI CLASS="li-itemize">
-A lot of information about chatroom is added on top of the page: Room title, JID, subject author, subject and configuration.
-<LI CLASS="li-itemize">Room title and JID are links to join the chatroom (using XMPP-IRI).
+Chatroom details are added on top of each page: room title, JID,
+ author, subject and configuration.
+<LI CLASS="li-itemize">
+ Room title and JID are links to join the chatroom (using
+ <A HREF="http://www.ietf.org/rfc/rfc4622.txt">XMPP URIs</A>).
<LI CLASS="li-itemize">Subject and chatroom configuration changes are tracked and displayed.
-<LI CLASS="li-itemize">Joins, leaves, nick changes, kicks, bans and /me are tracked and displayed, including the reason when available.
+<LI CLASS="li-itemize">Joins, leaves, nick changes, kicks, bans and `/me' are tracked and
+ displayed, including the reason if available.
<LI CLASS="li-itemize">Generated HTML files are XHTML 1.0 Transitional and CSS compliant.
<LI CLASS="li-itemize">Timestamps are self-referencing links.
<LI CLASS="li-itemize">Links on top for quicker navigation: Previous day, Next day, Up.
<LI CLASS="li-itemize">CSS is used for style definition, and a custom CSS file can be used.
<LI CLASS="li-itemize">URLs on messages and subjects are converted to hyperlinks.
<LI CLASS="li-itemize">Timezone used on timestamps is shown on the log files.
-<LI CLASS="li-itemize">A custom link can be added on top of page.
+<LI CLASS="li-itemize">A custom link can be added on top of each page.
</UL>
Options:
<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
<B><TT>access_log</TT></B><DD CLASS="dd-description">
- Restricts which users are allowed to enable or disable chatroom logging using ACL and ACCESS.
- Default: <TT>muc_admin</TT>.
- If you want to allow any chatroom owner put: <TT>muc</TT>.
+ This option restricts which users are allowed to enable or disable chatroom
+ logging. The default value is <TT>muc_admin</TT>. Note for this default setting
+ you need to have an access rule for <TT>muc_admin</TT> in order to take effect.
<DT CLASS="dt-description"><B><TT>cssfile</TT></B><DD CLASS="dd-description">
- If HTMLs will use a custom CSS file or the embedded one.
- Allowed values:
- <TT>false</TT>: HTMLs will include the standard CSS code;
- <TT>"CSS-URL"</TT>: the URL of the CSS file (for example: "http://example.com/my.css").
- Default: <TT>false</TT>.
+ With this option you can set whether the HTML files should have a custom CSS
+ file or if they need to use the embedded CSS file. Allowed values are
+ <TT>false</TT> and an URL to a CSS file. With the first value, HTML files will
+ include the embedded CSS code. With the latter, you can specify the URL of the
+ custom CSS file (for example: `http://example.com/my.css'). The default value
+ is <TT>false</TT>.
<DT CLASS="dt-description"><B><TT>dirtype</TT></B><DD CLASS="dd-description">
- Type of directory that will be created.
- Allowed values:
- <TT>subdirs</TT>: creates subdirectories for year and month;
- <TT>plain</TT>: the filename contains the full date, no subdirs.
- Default: <TT>subdirs</TT>.
+ The type of the created directories can be specified with this option. Allowed
+ values are <TT>subdirs</TT> and <TT>plain</TT>. With the first value,
+ subdirectories are created for each year and month. With the latter, the
+ names of the log files contain the full date, and there are no subdirectories.
+ The default value is <TT>subdirs</TT>.
<DT CLASS="dt-description"><B><TT>outdir</TT></B><DD CLASS="dd-description">
- Full path to the directory where html will be generated.
- Make sure the system user has write access on that directory.
- Default: <TT>"www/muc"</TT>.
+ This option sets the full path to the directory in which the HTML files should
+ be stored. Make sure the <TT>ejabberd</TT> daemon user has write access on that
+ directory. The default value is <TT>"www/muc"</TT>.
<DT CLASS="dt-description"><B><TT>timezone</TT></B><DD CLASS="dd-description">
- What timezone should be used.
- Allowed values:
- <TT>local</TT>: use local time, as reported to Erlang by the operating system;
- <TT>universal</TT>: use GMT/UTC time.
- Default: <TT>local</TT>.
+ The time zone for the logs is configurable with this option. Allowed values
+ are <TT>local</TT> and <TT>universal</TT>. With the first value, the local time,
+ as reported to Erlang by the operating system, will be used. With the latter,
+ GMT/UTC time will be used. The default value is <TT>local</TT>.
<DT CLASS="dt-description"><B><TT>top_link</TT></B><DD CLASS="dd-description">
- Customizable link on top right corner. Syntax of this option: <TT>{"URL", "Text"}</TT>.
- Default: <TT>{"/", "Home"}</TT>.
+ With this option you can customize the link on the top right corner of each
+ log file. The syntax of this option is <TT>{"URL", "Text"}</TT>. The default
+ value is <TT>{"/", "Home"}</TT>.
</DL>
-Example configuration:
-<PRE CLASS="verbatim">
+Examples:
+<UL CLASS="itemize"><LI CLASS="li-itemize">
+In the first example any chatroom owner can enable logging, and a
+ custom CSS file will be used (http://example.com/my.css). Further, the names
+ of the log files will contain the full date, and there will be no
+ subdirectories. The log files will be stored in /var/www/muclogs, and the
+ time zone will be GMT/UTC. Finally, the top link will be
+ <CODE><a href="http://www.jabber.ru">Jabber.ru</a></CODE>.
+ <PRE CLASS="verbatim">
+ {access, muc, [{allow, all}]}.
+ ...
{modules,
[
...
]},
...
]}.
-</PRE>
+</PRE><LI CLASS="li-itemize">In the second example only <TT>admin1@example.org</TT> and
+ <TT>admin2@example.net</TT> can enable logging, and the embedded CSS file will be
+ used. Further, the names of the log files will only contain the day (number),
+ and there will be subdirectories for each year and month. The log files will
+ be stored in /var/www/muclogs, and the local time will be used. Finally, the
+ top link will be the default <CODE><a href="/">Home</a></CODE>.
+ <PRE CLASS="verbatim">
+ {acl, admins, {user, "admin1", "example.org"}}.
+ {acl, admins, {user, "admin2", "example.net"}}.
+ ...
+ {access, muc_log, [{allow, admins},
+ {deny, all}]}.
+ ...
+ {modules,
+ [
+ ...
+ {mod_muc_log, [
+ {access_log, muc_log},
+ {cssfile, false},
+ {dirtype, subdirs},
+ {outdir, "/var/www/muclogs"},
+ {timezone, local}
+ ]},
+ ...
+ ]}.
+</PRE></UL>
<!--TOC subsection <TT>mod_offline</TT>-->
-<H3 CLASS="subsection"><A NAME="htoc53">A.10</A> <TT>mod_offline</TT></H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc57">5.10</A> <A NAME="modoffline"><TT>mod_offline</TT></A></H3><!--SEC END -->
<A NAME="sec:modoffline"></A>
sent to an offline user will be stored on the server until that user comes
online again. Thus it is very similar to how email works. Note that
<TT>ejabberdctl</TT> has a command to delete expired messages
-(see section <A HREF="#sec:ejabberdctl">3.4.2</A>).<BR>
+(see section <A HREF="#sec:ejabberdctl">7.2</A>).<BR>
<BR>
<!--TOC subsection <TT>mod_privacy</TT>-->
-<H3 CLASS="subsection"><A NAME="htoc54">A.11</A> <TT>mod_privacy</TT></H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc58">5.11</A> <A NAME="modprivacy"><TT>mod_privacy</TT></A></H3><!--SEC END -->
<A NAME="sec:modprivacy"></A>
their Jabber client, they will be able to:
<BLOCKQUOTE CLASS="quote">
<UL CLASS="itemize"><LI CLASS="li-itemize">
-Retrieving one's privacy lists.
-<LI CLASS="li-itemize">Adding, removing, and editing one's privacy lists.
-<LI CLASS="li-itemize">Setting, changing, or declining active lists.
+Retrieving one's privacy lists.
+<LI CLASS="li-itemize">Adding, removing, and editing one's privacy lists.
+<LI CLASS="li-itemize">Setting, changing, or declining active lists.
<LI CLASS="li-itemize">Setting, changing, or declining the default list (i.e., the list that
- is active by default).
+ is active by default).
<LI CLASS="li-itemize">Allowing or blocking messages based on JID, group, or subscription type
- (or globally).
+ (or globally).
<LI CLASS="li-itemize">Allowing or blocking inbound presence notifications based on JID, group,
- or subscription type (or globally).
+ or subscription type (or globally).
<LI CLASS="li-itemize">Allowing or blocking outbound presence notifications based on JID, group,
- or subscription type (or globally).
+ or subscription type (or globally).
<LI CLASS="li-itemize">Allowing or blocking IQ stanzas based on JID, group, or subscription type
- (or globally).
+ (or globally).
<LI CLASS="li-itemize">Allowing or blocking all communications based on JID, group, or
subscription type (or globally).
</UL>
<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
<B><TT>iqdisc</TT></B><DD CLASS="dd-description"> This specifies
the processing discipline for Blocking Communication (<TT>jabber:iq:privacy</TT>) IQ queries
-(see section <A HREF="#sec:modiqdiscoption">A.2.1</A>).
+(see section <A HREF="#sec:modiqdiscoption">5.2.1</A>).
</DL>
<!--TOC subsection <TT>mod_private</TT>-->
-<H3 CLASS="subsection"><A NAME="htoc55">A.12</A> <TT>mod_private</TT></H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc59">5.12</A> <A NAME="modprivate"><TT>mod_private</TT></A></H3><!--SEC END -->
<A NAME="sec:modprivate"></A>
<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
<B><TT>iqdisc</TT></B><DD CLASS="dd-description"> This specifies
the processing discipline for Private XML Storage (<TT>jabber:iq:private</TT>) IQ queries
-(see section <A HREF="#sec:modiqdiscoption">A.2.1</A>).
+(see section <A HREF="#sec:modiqdiscoption">5.2.1</A>).
</DL>
<!--TOC subsection <TT>mod_pubsub</TT>-->
-<H3 CLASS="subsection"><A NAME="htoc56">A.13</A> <TT>mod_pubsub</TT></H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc60">5.13</A> <A NAME="modpubsub"><TT>mod_pubsub</TT></A></H3><!--SEC END -->
<A NAME="sec:modpubsub"></A>
<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
<B><TT>hosts</TT></B><DD CLASS="dd-description"> This option defines the hostnames of the
- service (see section <A HREF="#sec:modhostsoption">A.2.2</A>). If neither <TT>hosts</TT> nor
- the old <TT>host</TT> is present, the prefix “<TT>pubsub.</TT>” is added to all
+ service (see section <A HREF="#sec:modhostsoption">5.2.2</A>). If neither <TT>hosts</TT> nor
+ the old <TT>host</TT> is present, the prefix `<TT>pubsub.</TT>' is added to all
<TT>ejabberd</TT> hostnames.
<DT CLASS="dt-description"><B><TT>served_hosts</TT></B><DD CLASS="dd-description"> To specify which hosts needs to
be served, you can use this option. If absent, only the main <TT>ejabberd</TT>
host is served. <DT CLASS="dt-description"><B><TT>access_createnode</TT></B><DD CLASS="dd-description">
- Restricts which users are allowed to create pubsub nodes using ACL and ACCESS.
- Default: <TT>pubsub_createnode</TT>.
-</DL>
+ This option restricts which users are allowed to create pubsub nodes using
+ ACL and ACCESS. The default value is <TT>pubsub_createnode</TT>. </DL>
Example:
<PRE CLASS="verbatim">
{modules,
</PRE>
<!--TOC subsection <TT>mod_register</TT>-->
-<H3 CLASS="subsection"><A NAME="htoc57">A.14</A> <TT>mod_register</TT></H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc61">5.14</A> <A NAME="modregister"><TT>mod_register</TT></A></H3><!--SEC END -->
<A NAME="sec:modregister"></A>
Options:
<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
<B><TT>access</TT></B><DD CLASS="dd-description"> This option can be configured to specify
- rules to restrict registration. If a rule returns “deny” on the requested
+ rules to restrict registration. If a rule returns `deny' on the requested
user name, registration for that user name is dennied. (there are no
restrictions by default).
<DT CLASS="dt-description"><B><TT>iqdisc</TT></B><DD CLASS="dd-description"> This specifies
the processing discipline for In-Band Registration (<TT>jabber:iq:register</TT>) IQ queries
-(see section <A HREF="#sec:modiqdiscoption">A.2.1</A>).
+(see section <A HREF="#sec:modiqdiscoption">5.2.1</A>).
</DL>
Examples:
<UL CLASS="itemize"><LI CLASS="li-itemize">
</PRE></UL>
<!--TOC subsection <TT>mod_roster</TT>-->
-<H3 CLASS="subsection"><A NAME="htoc58">A.15</A> <TT>mod_roster</TT></H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc62">5.15</A> <A NAME="modroster"><TT>mod_roster</TT></A></H3><!--SEC END -->
<A NAME="sec:modroster"></A>
<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
<B><TT>iqdisc</TT></B><DD CLASS="dd-description"> This specifies
the processing discipline for Roster Management (<TT>jabber:iq:roster</TT>) IQ queries
-(see section <A HREF="#sec:modiqdiscoption">A.2.1</A>).
+(see section <A HREF="#sec:modiqdiscoption">5.2.1</A>).
</DL>
<!--TOC subsection <TT>mod_service_log</TT>-->
-<H3 CLASS="subsection"><A NAME="htoc59">A.16</A> <TT>mod_service_log</TT></H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc63">5.16</A> <A NAME="modservicelog"><TT>mod_service_log</TT></A></H3><!--SEC END -->
<A NAME="sec:modservicelog"></A>
</PRE></UL>
<!--TOC subsection <TT>mod_shared_roster</TT>-->
-<H3 CLASS="subsection"><A NAME="htoc60">A.17</A> <TT>mod_shared_roster</TT></H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc64">5.17</A> <A NAME="modsharedroster"><TT>mod_shared_roster</TT></A></H3><!--SEC END -->
<A NAME="sec:modsharedroster"></A>
has a unique identification and the following parameters:
<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
<B>Name</B><DD CLASS="dd-description"> The name of the group, which will be displayed in the roster.
-<DT CLASS="dt-description"><B>Description</B><DD CLASS="dd-description"> The description of the group. This parameter doesn't affect
+<DT CLASS="dt-description"><B>Description</B><DD CLASS="dd-description"> The description of the group. This parameter does not affect
anything.
<DT CLASS="dt-description"><B>Members</B><DD CLASS="dd-description"> A list of full JIDs of group members, entered one per line in
the web interface.
</UL>
<!--TOC subsection <TT>mod_stats</TT>-->
-<H3 CLASS="subsection"><A NAME="htoc61">A.18</A> <TT>mod_stats</TT></H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc65">5.18</A> <A NAME="modstats"><TT>mod_stats</TT></A></H3><!--SEC END -->
+
+<A NAME="sec:modstats"></A>
+
+This module adds support for Statistics Gathering (<A HREF="http://www.jabber.org/jeps/jep-0039.html">JEP-0039</A>). This protocol
+allows you to retrieve next statistics from your <TT>ejabberd</TT> deployment:
+<UL CLASS="itemize"><LI CLASS="li-itemize">
+Total number of registered users on the current virtual host (users/total).
+<LI CLASS="li-itemize">Total number of registered users on all virtual hosts (users/all-hosts/total).
+<LI CLASS="li-itemize">Total number of online users on the current virtual host (users/online).
+<LI CLASS="li-itemize">Total number of online users on all virtual hosts (users/all-hosts/online).
+</UL>
+Options:
+<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
+<B><TT>iqdisc</TT></B><DD CLASS="dd-description"> This specifies
+the processing discipline for Statistics Gathering (<TT>http://jabber.org/protocol/stats</TT>) IQ queries
+(see section <A HREF="#sec:modiqdiscoption">5.2.1</A>).
+</DL>
+As there are only a small amount of clients (for example
+<A HREF="http://tkabber.jabber.ru/">Tkabber</A>) and software libraries with
+support for this JEP, a few examples are given of the XML you need to send
+in order to get the statistics. Here they are:
+<UL CLASS="itemize"><LI CLASS="li-itemize">
+You can request the number of online users on the current virtual host
+ (<TT>example.org</TT>) by sending:
+ <PRE CLASS="verbatim">
+<iq to='example.org' type='get'>
+ <query xmlns='http://jabber.org/protocol/stats'>
+ <stat name='users/online'/>
+ </query>
+</iq>
+</PRE><LI CLASS="li-itemize">You can request the total number of registered users on all virtual hosts
+ by sending:
+ <PRE CLASS="verbatim">
+<iq to='example.org' type='get'>
+ <query xmlns='http://jabber.org/protocol/stats'>
+ <stat name='users/all-hosts/total'/>
+ </query>
+</iq>
+</PRE></UL>
+<!--TOC subsection <TT>mod_time</TT>-->
+
+<H3 CLASS="subsection"><A NAME="htoc66">5.19</A> <A NAME="modtime"><TT>mod_time</TT></A></H3><!--SEC END -->
+
+<A NAME="sec:modtime"></A>
+
+This module features support for Entity Time (<A HREF="http://www.jabber.org/jeps/jep-0090.html">JEP-0090</A>). By using this JEP,
+you are able to discover the time at another entity's location.<BR>
+<BR>
+Options:
+<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
+<B><TT>iqdisc</TT></B><DD CLASS="dd-description"> This specifies
+the processing discipline for Entity Time (<TT>jabber:iq:time</TT>) IQ queries
+(see section <A HREF="#sec:modiqdiscoption">5.2.1</A>).
+</DL>
+<!--TOC subsection <TT>mod_vcard</TT>-->
+
+<H3 CLASS="subsection"><A NAME="htoc67">5.20</A> <A NAME="modvcard"><TT>mod_vcard</TT></A></H3><!--SEC END -->
+
+<A NAME="sec:modvcard"></A>
+
+This module allows end users to store and retrieve their vCard, and to retrieve
+other users vCards, as defined in vcard-temp (<A HREF="http://www.jabber.org/jeps/jep-0054.html">JEP-0054</A>). The module also
+implements an uncomplicated Jabber User Directory based on the vCards of
+these users. Moreover, it enables the server to send its vCard when queried.<BR>
+<BR>
+Options:
+<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
+
+ <B><TT>hosts</TT></B><DD CLASS="dd-description"> This option defines the hostnames of the
+ service (see section <A HREF="#sec:modhostsoption">5.2.2</A>). If neither <TT>hosts</TT> nor
+ the old <TT>host</TT> is present, the prefix `<TT>vjud.</TT>' is added to all
+ <TT>ejabberd</TT> hostnames.
+
+<DT CLASS="dt-description"><B><TT>iqdisc</TT></B><DD CLASS="dd-description"> This specifies
+the processing discipline for <TT>vcard-temp</TT> IQ queries
+(see section <A HREF="#sec:modiqdiscoption">5.2.1</A>).
+<DT CLASS="dt-description"><B><TT>search</TT></B><DD CLASS="dd-description">This option specifies whether the search
+ functionality is enabled (value: <TT>true</TT>) or disabled (value:
+ <TT>false</TT>). If disabled, the option <TT>hosts</TT> will be ignored and the
+ Jabber User Directory service will not appear in the Service Discovery item
+ list. The default value is <TT>true</TT>.
+<DT CLASS="dt-description"><B><TT>matches</TT></B><DD CLASS="dd-description">With this option, the number of reported
+ search results can be limited. If the option's value is set to <TT>infinity</TT>,
+ all search results are reported. The default value is <TT>30</TT>.
+<DT CLASS="dt-description"><B><TT>allow_return_all</TT></B><DD CLASS="dd-description">This option enables
+ you to specify if search operations with empty input fields should return all
+ users who added some information to their vCard. The default value is
+ <TT>false</TT>.
+<DT CLASS="dt-description"><B><TT>search_all_hosts</TT></B><DD CLASS="dd-description">If this option is set
+ to <TT>true</TT>, search operations will apply to all virtual hosts. Otherwise
+ only the current host will be searched. The default value is <TT>true</TT>.
+</DL>
+Examples:
+<UL CLASS="itemize"><LI CLASS="li-itemize">
+In this first situation, search results are limited to twenty items,
+ every user who added information to their vCard will be listed when people
+ do an empty search, and only users from the current host will be returned:
+ <PRE CLASS="verbatim">
+ {modules,
+ [
+ ...
+ {mod_vcard, [{search, true},
+ {matches, 20},
+ {allow_return_all, true},
+ {search_all_hosts, false}]},
+ ...
+ ]}.
+</PRE><LI CLASS="li-itemize">The second situation differs in a way that search results are not limited,
+ and that all virtual hosts will be searched instead of only the current one:
+ <PRE CLASS="verbatim">
+ {modules,
+ [
+ ...
+ {mod_vcard, [{search, true},
+ {matches, infinity},
+ {allow_return_all, true}]},
+ ...
+ ]}.
+</PRE></UL>
+<!--TOC subsection <TT>mod_vcard_ldap</TT>-->
+
+<H3 CLASS="subsection"><A NAME="htoc68">5.21</A> <A NAME="modvcardldap"><TT>mod_vcard_ldap</TT></A></H3><!--SEC END -->
+
+<A NAME="sec:modvcardldap"></A>
+
+<TT>ejabberd</TT> can map LDAP attributes to vCard fields. This behaviour is
+implemented in the <TT>mod_vcard_ldap</TT> module. This module does not depend on the
+authentication method (see <A HREF="#sec:ldapauth">4.5.2</A>). The <TT>mod_vcard_ldap</TT> module
+has its own optional parameters. The first group of parameters has the same
+meaning as the top-level LDAP parameters to set the authentication method:
+<TT>ldap_servers</TT>, <TT>ldap_port</TT>, <TT>ldap_rootdn</TT>,
+<TT>ldap_password</TT>, <TT>ldap_base</TT>, <TT>ldap_uidattr</TT>,
+<TT>ldap_uidattr_format</TT> and <TT>ldap_filter</TT>. See
+section <A HREF="#sec:ldapauth">4.5.2</A> for detailed information about these options. If one
+of these options is not set, <TT>ejabberd</TT> will look for the top-level option with
+the same name. The second group of parameters consists of the following
+<TT>mod_vcard_ldap</TT>-specific options:
+<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
+
+ <B><TT>hosts</TT></B><DD CLASS="dd-description"> This option defines the hostnames of the
+ service (see section <A HREF="#sec:modhostsoption">5.2.2</A>). If neither <TT>hosts</TT> nor
+ the old <TT>host</TT> is present, the prefix `<TT>vjud.</TT>' is added to all
+ <TT>ejabberd</TT> hostnames.
+
+<DT CLASS="dt-description"><B><TT>iqdisc</TT></B><DD CLASS="dd-description"> This specifies
+the processing discipline for <TT>vcard-temp</TT> IQ queries
+(see section <A HREF="#sec:modiqdiscoption">5.2.1</A>).
+<DT CLASS="dt-description"><B><TT>search</TT></B><DD CLASS="dd-description">This option specifies whether the search
+ functionality is enabled (value: <TT>true</TT>) or disabled (value:
+ <TT>false</TT>). If disabled, the option <TT>hosts</TT> will be ignored and the
+ Jabber User Directory service will not appear in the Service Discovery item
+ list. The default value is <TT>true</TT>.
+<DT CLASS="dt-description"><B><TT>ldap_vcard_map</TT></B><DD CLASS="dd-description">With this option you can
+ set the table that maps LDAP attributes to vCard fields. The format is:
+ <TT>[Name_of_vCard_field, Pattern, List_of_LDAP_attributes, ...]</TT>.
+ <TT>Name_of_vcard_field</TT> is the type name of the vCard as defined in
+ <A HREF="http://www.ietf.org/rfc/rfc2426.txt">RFC 2426</A>. <TT>Pattern</TT> is a
+ string which contains pattern variables <TT>"%u"</TT>, <TT>"%d"</TT> or
+ <TT>"%s"</TT>. <TT>List_of_LDAP_attributes</TT> is the list containing LDAP
+ attributes. The pattern variables <TT>"%s"</TT> will be sequentially replaced
+ with the values of LDAP attributes from <TT>List_of_LDAP_attributes</TT>,
+ <TT>"%u"</TT> will be replaced with the user part of a JID, and <TT>"%d"</TT>
+ will be replaced with the domain part of a JID. The default is:
+ <PRE CLASS="verbatim">
+ [{"NICKNAME", "%u", []},
+ {"FN", "%s", ["displayName"]},
+ {"FAMILY", "%s", ["sn"]},
+ {"GIVEN", "%s", ["givenName"]},
+ {"MIDDLE", "%s", ["initials"]},
+ {"ORGNAME", "%s", ["o"]},
+ {"ORGUNIT", "%s", ["ou"]},
+ {"CTRY", "%s", ["c"]},
+ {"LOCALITY", "%s", ["l"]},
+ {"STREET", "%s", ["street"]},
+ {"REGION", "%s", ["st"]},
+ {"PCODE", "%s", ["postalCode"]},
+ {"TITLE", "%s", ["title"]},
+ {"URL", "%s", ["labeleduri"]},
+ {"DESC", "%s", ["description"]},
+ {"TEL", "%s", ["telephoneNumber"]},
+ {"EMAIL", "%s", ["mail"]},
+ {"BDAY", "%s", ["birthDay"]},
+ {"ROLE", "%s", ["employeeType"]},
+ {"PHOTO", "%s", ["jpegPhoto"]}]
+</PRE><DT CLASS="dt-description"><B><TT>ldap_search_fields</TT></B><DD CLASS="dd-description">This option
+ defines the search form and the LDAP attributes to search within. The format
+ is: <TT>[Name, Attribute, ...]</TT>. <TT>Name</TT> is the name of a search form
+ field which will be automatically translated by using the translation
+ files (see <TT>msgs/*.msg</TT> for available words). <TT>Attribute</TT> is the
+ LDAP attribute or the pattern <TT>"%u"</TT>. The default is:
+ <PRE CLASS="verbatim">
+ [{"User", "%u"},
+ {"Full Name", "displayName"},
+ {"Given Name", "givenName"},
+ {"Middle Name", "initials"},
+ {"Family Name", "sn"},
+ {"Nickname", "%u"},
+ {"Birthday", "birthDay"},
+ {"Country", "c"},
+ {"City", "l"},
+ {"Email", "mail"},
+ {"Organization Name", "o"},
+ {"Organization Unit", "ou"}]
+</PRE><DT CLASS="dt-description"><B><TT>ldap_search_reported</TT></B><DD CLASS="dd-description">This option
+ defines which search fields should be reported. The format is:
+ <TT>[Name, vCard_Name, ...]</TT>. <TT>Name</TT> is the name of a search form
+ field which will be automatically translated by using the translation
+ files (see <TT>msgs/*.msg</TT> for available words). <TT>vCard_Name</TT> is the
+ vCard field name defined in the <TT>ldap_vcard_map</TT> option. The default
+ is:
+<PRE CLASS="verbatim">
+ [{"Full Name", "FN"},
+ {"Given Name", "GIVEN"},
+ {"Middle Name", "MIDDLE"},
+ {"Family Name", "FAMILY"},
+ {"Nickname", "NICKNAME"},
+ {"Birthday", "BDAY"},
+ {"Country", "CTRY"},
+ {"City", "LOCALITY"},
+ {"Email", "EMAIL"},
+ {"Organization Name", "ORGNAME"},
+ {"Organization Unit", "ORGUNIT"}]
+</PRE></DL>
+Examples:
+<UL CLASS="itemize"><LI CLASS="li-itemize">
+<BR>
+<BR>
+Let's say <TT>ldap.example.org</TT> is the name of our LDAP server. We have
+users with their passwords in <TT>"ou=Users,dc=example,dc=org"</TT> directory.
+Also we have addressbook, which contains users emails and their additional
+infos in <TT>"ou=AddressBook,dc=example,dc=org"</TT> directory. Corresponding
+authentication section should looks like this:
+<PRE CLASS="verbatim">
+ %% authentication method
+ {auth_method, ldap}.
+ %% DNS name of our LDAP server
+ {ldap_servers, ["ldap.example.org"]}.
+ %% We want to authorize users from 'shadowAccount' object class only
+ {ldap_filter, "(objectClass=shadowAccount)"}.
+</PRE>
+Now we want to use users LDAP-info as their vCards. We have four attributes
+defined in our LDAP schema: <TT>"mail"</TT> — email address, <TT>"givenName"</TT>
+— first name, <TT>"sn"</TT> — second name, <TT>"birthDay"</TT> — birthday.
+Also we want users to search each other. Let's see how we can set it up:
+<PRE CLASS="verbatim">
+ {modules,
+ ...
+ {mod_vcard_ldap,
+ [
+ %% We use the same server and port, but want to bind anonymously because
+ %% our LDAP server accepts anonymous requests to
+ %% "ou=AddressBook,dc=example,dc=org" subtree.
+ {ldap_rootdn, ""},
+ {ldap_password, ""},
+ %% define the addressbook's base
+ {ldap_base, "ou=AddressBook,dc=example,dc=org"},
+ %% user's part of JID is located in the "mail" attribute
+ {ldap_uidattr, "mail"},
+ %% common format for our emails
+ {ldap_uidattr_format, "%u@mail.example.org"},
+ %% We have to define empty filter here, because entries in addressbook does not
+ %% belong to shadowAccount object class
+ {ldap_filter, ""},
+ %% Now we want to define vCard pattern
+ {ldap_vcard_map,
+ [{"NICKNAME", "%u", []}, % just use user's part of JID as his nickname
+ {"GIVEN", "%s", ["givenName"]},
+ {"FAMILY", "%s", ["sn"]},
+ {"FN", "%s, %s", ["sn", "givenName"]}, % example: "Smith, John"
+ {"EMAIL", "%s", ["mail"]},
+ {"BDAY", "%s", ["birthDay"]}]},
+ %% Search form
+ {ldap_search_fields,
+ [{"User", "%u"},
+ {"Name", "givenName"},
+ {"Family Name", "sn"},
+ {"Email", "mail"},
+ {"Birthday", "birthDay"}]},
+ %% vCard fields to be reported
+ %% Note that JID is always returned with search results
+ {ldap_search_reported,
+ [{"Full Name", "FN"},
+ {"Nickname", "NICKNAME"},
+ {"Birthday", "BDAY"}]}
+ ]}
+ ...
+ }.
+</PRE>
+Note that <TT>mod_vcard_ldap</TT> module checks an existence of the user before
+searching his info in LDAP.<BR>
+<BR>
+<LI CLASS="li-itemize"><TT>ldap_vcard_map</TT> example:
+<PRE CLASS="verbatim">
+ {ldap_vcard_map,
+ [{"NICKNAME", "%u", []},
+ {"FN", "%s", ["displayName"]},
+ {"CTRY", "Russia", []},
+ {"EMAIL", "%u@%d", []},
+ {"DESC", "%s\n%s", ["title", "description"]}
+ ]},
+</PRE><LI CLASS="li-itemize"><TT>ldap_search_fields</TT> example:
+<PRE CLASS="verbatim">
+ {ldap_search_fields,
+ [{"User", "uid"},
+ {"Full Name", "displayName"},
+ {"Email", "mail"}
+ ]},
+</PRE><LI CLASS="li-itemize"><TT>ldap_search_reported</TT> example:
+<PRE CLASS="verbatim">
+ {ldap_search_reported,
+ [{"Full Name", "FN"},
+ {"Email", "EMAIL"},
+ {"Birthday", "BDAY"},
+ {"Nickname", "NICKNAME"}
+ ]},
+</PRE></UL>
+<!--TOC subsection <TT>mod_version</TT>-->
+
+<H3 CLASS="subsection"><A NAME="htoc69">5.22</A> <A NAME="modversion"><TT>mod_version</TT></A></H3><!--SEC END -->
+
+<A NAME="sec:modversion"></A>
+
+This module implements Software Version (<A HREF="http://www.jabber.org/jeps/jep-0092.html">JEP-0092</A>). Consequently, it
+answers <TT>ejabberd</TT>'s version when queried.<BR>
+<BR>
+Options:
+<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
+<B><TT>iqdisc</TT></B><DD CLASS="dd-description"> This specifies
+the processing discipline for Software Version (<TT>jabber:iq:version</TT>) IQ queries
+(see section <A HREF="#sec:modiqdiscoption">5.2.1</A>).
+</DL>
+<!--TOC section Creating an Initial Administrator-->
+
+<H2 CLASS="section"><A NAME="htoc70">6</A> <A NAME="initialadmin">Creating an Initial Administrator</A></H2><!--SEC END -->
+
+<A NAME="sec:initialadmin"></A>
+Before the web interface can be entered to perform administration tasks, an
+account with administrator rights is needed on your <TT>ejabberd</TT> deployment.<BR>
+<BR>
+Instructions to create an initial administrator account:
+<OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
+Register an account on your <TT>ejabberd</TT> deployment. An account can be
+ created in two ways:
+ <OL CLASS="enumerate" type=a><LI CLASS="li-enumerate">
+ Using the tool <TT>ejabberdctl</TT> (see
+ section <A HREF="#sec:ejabberdctl">7.2</A>):
+ <PRE CLASS="verbatim">
+% ejabberdctl node@host register admin example.org password
+</PRE><LI CLASS="li-enumerate">Using In-Band Registration (see section <A HREF="#sec:modregister">5.14</A>): you can
+ use a Jabber client to register an account.
+ </OL>
+<LI CLASS="li-enumerate">Edit the configuration file to promote the account created in the previous
+ step to an account with administrator rights. Note that if you want to add
+ more administrators, a seperate acl entry is needed for each administrator.
+ <PRE CLASS="verbatim">
+ {acl, admins, {user, "admin", "example.org"}}.
+ {access, configure, [{allow, admins}]}.
+</PRE><LI CLASS="li-enumerate">Restart <TT>ejabberd</TT> to load the new configuration.
+<LI CLASS="li-enumerate">Open the web interface (<CODE>http://server:port/admin/</CODE>) in your
+ favourite browser. Make sure to enter the <EM>full</EM> JID as username (in this
+ example: <TT>admin@example.org</TT>. The reason that you also need to enter the
+ suffix, is because <TT>ejabberd</TT>'s virtual hosting support.
+</OL>
+<!--TOC section Online Configuration and Monitoring-->
+
+<H2 CLASS="section"><A NAME="htoc71">7</A> <A NAME="onlineconfig">Online Configuration and Monitoring</A></H2><!--SEC END -->
+
+<A NAME="sec:onlineconfig"></A>
+<!--TOC subsection Web Interface-->
+
+<H3 CLASS="subsection"><A NAME="htoc72">7.1</A> <A NAME="webinterface">Web Interface</A></H3><!--SEC END -->
+
+<A NAME="sec:webinterface"></A>
+
+To perform online configuration of <TT>ejabberd</TT> you need to enable the
+<TT>ejabberd_http</TT> listener with the option <TT>web_admin</TT> (see
+section <A HREF="#sec:listened">3.3</A>). Then you can open
+<CODE>http://server:port/admin/</CODE> in your favourite web browser. You
+will be asked to enter the username (the <EM>full</EM> Jabber ID) and password
+of an <TT>ejabberd</TT> user with administrator rights. After authentication
+you will see a page similar to figure <A HREF="#fig:webadmmain">1</A>.
+<BLOCKQUOTE CLASS="figure"><DIV CLASS="center"><DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV>
+
+ <IMG SRC="webadmmain.png" ALT="webadmmain.png">
+
-<A NAME="sec:modstats"></A>
+ <BR>
+<BR>
+<DIV CLASS="center">Figure 1: Top page from the web interface</DIV><BR>
+<BR>
-This module adds support for Statistics Gathering (<A HREF="http://www.jabber.org/jeps/jep-0039.html">JEP-0039</A>). This protocol
-allows you to retrieve next statistics from your <TT>ejabberd</TT> deployment:
-<UL CLASS="itemize"><LI CLASS="li-itemize">
-Total number of registered users on the current virtual host (users/total).
-<LI CLASS="li-itemize">Total number of registered users on all virtual hosts (users/all-hosts/total).
-<LI CLASS="li-itemize">Total number of online users on the current virtual host (users/online).
-<LI CLASS="li-itemize">Total number of online users on all virtual hosts (users/all-hosts/online).
-</UL>
-Options:
-<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
-<B><TT>iqdisc</TT></B><DD CLASS="dd-description"> This specifies
-the processing discipline for Statistics Gathering (<TT>http://jabber.org/protocol/stats</TT>) IQ queries
-(see section <A HREF="#sec:modiqdiscoption">A.2.1</A>).
-</DL>
-As there are only a small amount of clients (for example
-<A HREF="http://tkabber.jabber.ru/">Tkabber</A>) and software libraries with
-support for this JEP, a few examples are given of the XML you need to send
-in order to get the statistics. Here they are:
+ <A NAME="fig:webadmmain"></A>
+<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></DIV></BLOCKQUOTE>
+Here you can edit access restrictions, manage users, create backups,
+manage the database, enable/disable ports listened for, view server
+statistics,...<BR>
+<BR>
+Examples:
<UL CLASS="itemize"><LI CLASS="li-itemize">
-You can request the number of online users on the current virtual host
- (<TT>example.org</TT>) by sending:
+You can serve the web interface on the same port as the
+ HTTP Polling interface. In this example
+ you should point your web browser to <CODE>http://example.org:5280/admin/</CODE> to
+ administer all virtual hosts or to
+ <CODE>http://example.org:5280/admin/server/example.com/</CODE> to administer only
+ the virtual host <TT>example.com</TT>. Before you get access to the web interface
+ you need to enter as username, the JID and password from a registered user
+ that is allowed to configure <TT>ejabberd</TT>. In this example you can enter as
+ username `<TT>admin@example.net</TT>' to administer all virtual hosts (first
+ URL). If you log in with `<TT>admin@example.com</TT>' on<BR>
+<CODE>http://example.org:5280/admin/server/example.com/</CODE> you can only
+ administer the virtual host <TT>example.com</TT>.
<PRE CLASS="verbatim">
-<iq to='example.org' type='get'>
- <query xmlns='http://jabber.org/protocol/stats'>
- <stat name='users/online'/>
- </query>
-</iq>
-</PRE><LI CLASS="li-itemize">You can request the total number of registered users on all virtual hosts
- by sending:
+ ...
+ {acl, admins, {user, "admin", "example.net"}}.
+ {host_config, "example.com", [{acl, admins, {user, "admin", "example.com"}}]}.
+ {access, configure, [{allow, admins}]}.
+ ...
+ {hosts, ["example.org"]}.
+ ...
+ {listen,
+ [...
+ {5280, ejabberd_http, [http_poll, web_admin]},
+ ...
+ ]
+ }.
+</PRE><LI CLASS="li-itemize">For security reasons, you can serve the web interface on a secured
+ connection, on a port differing from the HTTP Polling interface, and bind it
+ to the internal LAN IP. The web interface will be accessible by pointing your
+ web browser to <CODE>https://192.168.1.1:5280/admin/</CODE>:
<PRE CLASS="verbatim">
-<iq to='example.org' type='get'>
- <query xmlns='http://jabber.org/protocol/stats'>
- <stat name='users/all-hosts/total'/>
- </query>
-</iq>
+ ...
+ {hosts, ["example.org"]}.
+ ...
+ {listen,
+ [...
+ {5270, ejabberd_http, [http_poll]},
+ {5280, ejabberd_http, [web_admin, {ip, {192, 168, 1, 1}},
+ tls, {certfile, "/usr/local/etc/server.pem"}]},
+ ...
+ ]
+ }.
</PRE></UL>
-<!--TOC subsection <TT>mod_time</TT>-->
+<!--TOC subsection <TT>ejabberdctl</TT>-->
-<H3 CLASS="subsection"><A NAME="htoc62">A.19</A> <TT>mod_time</TT></H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc73">7.2</A> <A NAME="ejabberdctl"><TT>ejabberdctl</TT></A></H3><!--SEC END -->
-<A NAME="sec:modtime"></A>
+<A NAME="sec:ejabberdctl"></A>
-This module features support for Entity Time (<A HREF="http://www.jabber.org/jeps/jep-0090.html">JEP-0090</A>). By using this JEP,
-you are able to discover the time at another entity's location.<BR>
-<BR>
-Options:
+It is possible to do some administration operations using the command
+line tool <TT>ejabberdctl</TT>. You can list all available options by
+running <TT>ejabberdctl</TT> without arguments:
+<PRE CLASS="verbatim">
+% ejabberdctl
+Usage: ejabberdctl node command
+
+Available commands:
+ status get ejabberd status
+ stop stop ejabberd
+ restart restart ejabberd
+ reopen-log reopen log file
+ register user server password register a user
+ unregister user server unregister a user
+ backup file store a database backup to file
+ restore file restore a database backup from file
+ install-fallback file install a database fallback from file
+ dump file dump a database to a text file
+ load file restore a database from a text file
+ import-file file import user data from jabberd 1.4 spool file
+ import-dir dir import user data from jabberd 1.4 spool directory
+ registered-users list all registered users
+ delete-expired-messages delete expired offline messages from database
+
+Example:
+ ejabberdctl ejabberd@host restart
+</PRE>
+Additional information:
<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
-<B><TT>iqdisc</TT></B><DD CLASS="dd-description"> This specifies
-the processing discipline for Entity Time (<TT>jabber:iq:time</TT>) IQ queries
-(see section <A HREF="#sec:modiqdiscoption">A.2.1</A>).
+<B><TT>reopen-log </TT></B><DD CLASS="dd-description"> If you use a tool to rotate logs, you have to configure it
+ so that this command is executed after each rotation.
+<DT CLASS="dt-description"><B><TT>backup, restore, install-fallback, dump, load</TT></B><DD CLASS="dd-description"> You can use these
+ commands to create and restore backups.
+<DT CLASS="dt-description"><B><TT>import-file, import-dir</TT></B><DD CLASS="dd-description">
+ These options can be used to migrate from other Jabber/XMPP servers. There
+ exist tutorials to <A HREF="http://ejabberd.jabber.ru/migrate-to-ejabberd">migrate from other software to ejabberd</A>.
+<DT CLASS="dt-description"><B><TT>delete-expired-messages</TT></B><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.
</DL>
-<!--TOC subsection <TT>mod_vcard</TT>-->
+<!--TOC section Firewall Settings-->
-<H3 CLASS="subsection"><A NAME="htoc63">A.20</A> <TT>mod_vcard</TT></H3><!--SEC END -->
+<H2 CLASS="section"><A NAME="htoc74">8</A> <A NAME="firewall">Firewall Settings</A></H2><!--SEC END -->
-<A NAME="sec:modvcard"></A>
+<A NAME="sec:firewall"></A>
-This module allows end users to store and retrieve their vCard, and to retrieve
-other users vCards, as defined in vcard-temp (<A HREF="http://www.jabber.org/jeps/jep-0054.html">JEP-0054</A>). The module also
-implements an uncomplicated Jabber User Directory based on the vCards of
-these users. Moreover, it enables the server to send its vCard when queried.<BR>
-<BR>
-Options:
-<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
+You need to take the following TCP ports in mind when configuring your firewall:
+<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>Port</TD>
+<TD ALIGN=left NOWRAP>Description</TD>
+</TR>
+<TR><TD ALIGN=left NOWRAP>5222</TD>
+<TD ALIGN=left NOWRAP>SASL and unencrypted c2s connections.</TD>
+</TR>
+<TR><TD ALIGN=left NOWRAP>5223</TD>
+<TD ALIGN=left NOWRAP>Obsolete SSL c2s connections.</TD>
+</TR>
+<TR><TD ALIGN=left NOWRAP>5269</TD>
+<TD ALIGN=left NOWRAP>s2s connections.</TD>
+</TR>
+<TR><TD ALIGN=left NOWRAP>4369</TD>
+<TD ALIGN=left NOWRAP>Only for clustering (see <A HREF="#sec:clustering">10</A>).</TD>
+</TR>
+<TR><TD ALIGN=left NOWRAP>port range</TD>
+<TD ALIGN=left NOWRAP>Only for clustring (see <A HREF="#sec:clustering">10</A>). This range
+ is configurable (see <A HREF="#sec:start">2.4</A>).</TD>
+</TR></TABLE>
+<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></DIV></BLOCKQUOTE>
+<!--TOC section SRV Records-->
- <B><TT>hosts</TT></B><DD CLASS="dd-description"> This option defines the hostnames of the
- service (see section <A HREF="#sec:modhostsoption">A.2.2</A>). If neither <TT>hosts</TT> nor
- the old <TT>host</TT> is present, the prefix “<TT>vjud.</TT>” is added to all
- <TT>ejabberd</TT> hostnames.
+<H2 CLASS="section"><A NAME="htoc75">9</A> <A NAME="srv">SRV Records</A></H2><!--SEC END -->
+
+<A NAME="sec:srv"></A>
-<DT CLASS="dt-description"><B><TT>iqdisc</TT></B><DD CLASS="dd-description"> This specifies
-the processing discipline for <TT>vcard-temp</TT> IQ queries
-(see section <A HREF="#sec:modiqdiscoption">A.2.1</A>).
-<DT CLASS="dt-description"><B><TT>search</TT></B><DD CLASS="dd-description"> This option specifies whether the search
- functionality is enabled (value: <TT>true</TT>) or disabled
- (value: <TT>false</TT>). If disabled, the option <TT>hosts</TT> will be
- ignored and the Jabber User Directory service will not appear in the
- Service Discovery item list. The default value is <TT>true</TT>.
-<DT CLASS="dt-description"><B><TT>matches</TT></B><DD CLASS="dd-description"> With this option, the number of reported
- search results can be limited. If the option's value is set to <TT>infinity</TT>,
- all search results are reported. The default value is <TT>30</TT>.
-<DT CLASS="dt-description"><B><TT>allow_return_all</TT></B><DD CLASS="dd-description"> This option enables
- you to specify if search operations with empty input fields should return
- all users who added some information to their vCard. The default value is
- <TT>false</TT>.
-<DT CLASS="dt-description"><B><TT>search_all_hosts</TT></B><DD CLASS="dd-description"> If this option is
- set to <TT>true</TT>, search operations will apply to all virtual hosts.
- Otherwise only the current host will be searched. The default value is
- <TT>true</TT>.
-</DL>
-Examples:
<UL CLASS="itemize"><LI CLASS="li-itemize">
-In this first situation, search results are limited to twenty items,
- every user who added information to their vCard will be listed when people
- do an empty search, and only users from the current host will be returned:
- <PRE CLASS="verbatim">
- {modules,
- [
- ...
- {mod_vcard, [{search, true},
- {matches, 20},
- {allow_return_all, true},
- {search_all_hosts, false}]},
- ...
- ]}.
-</PRE><LI CLASS="li-itemize">The second situation differs in a way that search results are not limited,
- and that all virtual hosts will be searched instead of only the current one:
- <PRE CLASS="verbatim">
- {modules,
- [
- ...
- {mod_vcard, [{search, true},
- {matches, infinity},
- {allow_return_all, true}]},
- ...
- ]}.
-</PRE></UL>
-<!--TOC subsection LDAP and <TT>mod_vcard_ldap</TT>-->
+General information:
+ <A HREF="http://en.wikipedia.org/wiki/SRV_record">SRV record</A>
+<LI CLASS="li-itemize">Practical information:
+ <A HREF="http://jabberd.jabberstudio.org/2/docs/section05.html#5_7">Setting DNS SRV Records</A>
+</UL>
+<!--TOC section Clustering-->
-<H3 CLASS="subsection"><A NAME="htoc64">A.21</A> LDAP and <TT>mod_vcard_ldap</TT></H3><!--SEC END -->
+<H2 CLASS="section"><A NAME="htoc76">10</A> <A NAME="clustering">Clustering</A></H2><!--SEC END -->
-<A NAME="sec:ldap"></A>
+<A NAME="sec:clustering"></A>
-<!--TOC subsubsection Features-->
+<!--TOC subsection How it Works-->
-<H4 CLASS="subsubsection"><A NAME="htoc65">A.21.1</A> Features</H4><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc77">10.1</A> <A NAME="howitworks">How it Works</A></H3><!--SEC END -->
-<A NAME="sec:ldapfeatures"></A>
-<TT>ejabberd</TT> has built-in LDAP support. You can authenticate users against LDAP
-server and use LDAP directory as vCard storage. Shared rosters are not
-supported yet.<BR>
+<A NAME="sec:howitworks"></A>
+
+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
+have the same magic cookie (see Erlang/OTP documentation, in other words the
+file <TT>~ejabberd/.erlang.cookie</TT> must be the same on all nodes). This is
+needed because all nodes exchange information about connected users, s2s
+connections, registered services, etc...<BR>
<BR>
-<!--TOC subsubsection Connection-->
+Each <TT>ejabberd</TT> node has the following modules:
+<UL CLASS="itemize"><LI CLASS="li-itemize">
+router,
+<LI CLASS="li-itemize">local router,
+<LI CLASS="li-itemize">session manager,
+<LI CLASS="li-itemize">s2s manager.
+</UL>
+<!--TOC subsubsection Router-->
-<H4 CLASS="subsubsection"><A NAME="htoc66">A.21.2</A> Connection</H4><!--SEC END -->
+<H4 CLASS="subsubsection"><A NAME="htoc78">10.1.1</A> <A NAME="router">Router</A></H4><!--SEC END -->
-<A NAME="sec:ldapconnection"></A>
-Parameters:
-<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
-<B><TT>ldap_server</TT></B><DD CLASS="dd-description"> IP address or dns name of your
-LDAP server. This option is required.
-<DT CLASS="dt-description"><B><TT>ldap_port</TT></B><DD CLASS="dd-description"> Port to connect to LDAP server.
-Default is 389.
-<DT CLASS="dt-description"><B><TT>ldap_rootdn</TT></B><DD CLASS="dd-description"> Bind DN. Default is <TT>""</TT>
-which means anonymous connection.
-<DT CLASS="dt-description"><B><TT>ldap_password</TT></B><DD CLASS="dd-description"> Bind password. Default
-is <TT>""</TT>.
-</DL>
-Example:
-<PRE CLASS="verbatim">
- {auth_method, ldap}.
- {ldap_servers, ["ldap.mydomain.org"]}.
- {ldap_port, 389}.
- {ldap_rootdn, "cn=Manager,dc=domain,dc=org"}.
- {ldap_password, "secret"}.
-</PRE>
-Note that current LDAP implementation doesn't support SSL connection and SASL
-authentication.<BR>
+<A NAME="sec:router"></A>
+
+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.<BR>
<BR>
-<!--TOC subsubsection Authentication-->
+<!--TOC subsubsection Local Router-->
-<H4 CLASS="subsubsection"><A NAME="htoc67">A.21.3</A> Authentication</H4><!--SEC END -->
+<H4 CLASS="subsubsection"><A NAME="htoc79">10.1.2</A> <A NAME="localrouter">Local Router</A></H4><!--SEC END -->
-<A NAME="sec:ldapauthentication"></A>
-You can authenticate users against LDAP directory. Available parameters are
-listed below:
-<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
-<B><TT>ldap_base</TT></B><DD CLASS="dd-description"> LDAP base directory which stores users
-accounts. This option is required.
-<DT CLASS="dt-description"><B><TT>ldap_uidattr</TT></B><DD CLASS="dd-description"> LDAP attribute which holds
-user's part of JID. Default is <TT>"uid"</TT>.
-<DT CLASS="dt-description"><B><TT>ldap_uidattr_format</TT></B><DD CLASS="dd-description"> Format of the
-<TT>ldap_uidattr</TT> variable. Format MUST contain one and only one pattern
-variable <TT>"%u"</TT> which will be replaced by user's part of JID. For example,
-<TT>"%u@mydomain.org"</TT>. Default value is <TT>"%u"</TT>.
-<DT CLASS="dt-description"><B><TT>ldap_filter</TT></B><DD CLASS="dd-description"> RFC 2254 LDAP filter. Default is
-<TT>none</TT>. Example: <TT>"(&(objectClass=shadowAccount)(memberOf=Jabber
- Users))"</TT>. Please, don't forget closing brackets and don't use superfluous
-whitespaces. Also you MUST NOT use <TT>ldap_uidattr</TT> attribute in filter
-because this attribute will be substituted in LDAP filter automatically.
-</DL>
-<!--TOC subsubsection vCards and Search-->
+<A NAME="sec:localrouter"></A>
-<H4 CLASS="subsubsection"><A NAME="htoc68">A.21.4</A> vCards and Search</H4><!--SEC END -->
+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.<BR>
+<BR>
+<!--TOC subsubsection Session Manager-->
-<A NAME="sec:modvcardldap"></A>
-<TT>ejabberd</TT> can map LDAP attributes to vCard fields. This behaviour is
-implemented in <TT>mod_vcard_ldap</TT> module. This module doesn't depend on
-authentication method. <TT>mod_vcard_ldap</TT> module has it's own optional
-parameters. The first group of parameters has the same meaning as top-level
-LDAP parameters: <TT>ldap_servers</TT>, <TT>ldap_port</TT>,
-<TT>ldap_rootdn</TT>, <TT>ldap_password</TT>, <TT>ldap_base</TT>,
-<TT>ldap_uidattr</TT>, <TT>ldap_uidattr_format</TT> and
-<TT>ldap_filter</TT>. If one of this option is not set <TT>ejabberd</TT> will look
-for top-level option with the same name. The second group of parameters
-consists of the following options:
-<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
+<H4 CLASS="subsubsection"><A NAME="htoc80">10.1.3</A> <A NAME="sessionmanager">Session Manager</A></H4><!--SEC END -->
- <B><TT>hosts</TT></B><DD CLASS="dd-description"> This option defines the hostnames of the
- service (see section <A HREF="#sec:modhostsoption">A.2.2</A>). If neither <TT>hosts</TT> nor
- the old <TT>host</TT> is present, the prefix “<TT>vjud.</TT>” is added to all
- <TT>ejabberd</TT> hostnames.
+<A NAME="sec:sessionmanager"></A>
-<DT CLASS="dt-description"><B><TT>iqdisc</TT></B><DD CLASS="dd-description"> This specifies
-the processing discipline for <TT>vcard-temp</TT> IQ queries
-(see section <A HREF="#sec:modiqdiscoption">A.2.1</A>).
-<DT CLASS="dt-description"><B><TT>search</TT></B><DD CLASS="dd-description"> This option specifies whether the search
- functionality is enabled (value: <TT>true</TT>) or disabled
- (value: <TT>false</TT>). If disabled, the option <TT>hosts</TT> will be
- ignored and the Jabber User Directory service will not appear in the
- Service Discovery item list. The default value is <TT>true</TT>.
-<DT CLASS="dt-description"><B><TT>ldap_vcard_map</TT></B><DD CLASS="dd-description"> the table which defines
-reflection of LDAP attributes to vCard fields.
- Format is:
- <TT>[Name_of_vcard_field, Pattern, List_of_LDAP_attributes, ...]</TT>
- where
- <TT>Name_of_vcard_field</TT> is the type name of vCard as defined
- in RFC 2426,
- Pattern is a string which contains pattern variables <TT>"%u"</TT>, <TT>"%d"</TT> or <TT>"%s"</TT>,
- <TT>List_of_LDAP_attributes</TT> is the list which contains of LDAP attributes.
- Pattern variables <TT>"%s"</TT> will be sequentially replaced with the values of
- LDAP attributes from <TT>List_of_LDAP_attributes</TT>; <TT>"%u"</TT> will be replaced with
- user's part of JID and <TT>"%d"</TT> will be replaced with domain part of JID.
- Example:
-<PRE CLASS="verbatim">
- {ldap_vcard_map,
- [{"NICKNAME", "%u", []},
- {"FN", "%s", ["displayName"]},
- {"CTRY", "Russia", []},
- {"EMAIL", "%u@%d", []},
- {"DESC", "%s\n%s", ["title", "description"]}
- ]},
-</PRE>
-Default is:
-<PRE CLASS="verbatim">
- [{"NICKNAME", "%u", []},
- {"FN", "%s", ["displayName"]},
- {"FAMILY", "%s", ["sn"]},
- {"GIVEN", "%s", ["givenName"]},
- {"MIDDLE", "%s", ["initials"]},
- {"ORGNAME", "%s", ["o"]},
- {"ORGUNIT", "%s", ["ou"]},
- {"CTRY", "%s", ["c"]},
- {"LOCALITY", "%s", ["l"]},
- {"STREET", "%s", ["street"]},
- {"REGION", "%s", ["st"]},
- {"PCODE", "%s", ["postalCode"]},
- {"TITLE", "%s", ["title"]},
- {"URL", "%s", ["labeleduri"]},
- {"DESC", "%s", ["description"]},
- {"TEL", "%s", ["telephoneNumber"]},
- {"EMAIL", "%s", ["mail"]},
- {"BDAY", "%s", ["birthDay"]},
- {"ROLE", "%s", ["employeeType"]},
- {"PHOTO", "%s", ["jpegPhoto"]}]
-</PRE><DT CLASS="dt-description"><B><TT>ldap_search_fields</TT></B><DD CLASS="dd-description"> This option defines
-search form and LDAP attributes to search.
- Format:
- <TT>[Name, Attribute, ...]</TT>
- where
- <TT>Name</TT> is the name of field in the search form. Will be automatically
- translated according to definitions in translation files (see
- <TT>msgs/*.msg</TT> for available words).
- Attribute is the LDAP attribute or the pattern <TT>"%u"</TT>
- Example:
-<PRE CLASS="verbatim">
- {ldap_search_fields,
- [{"User", "uid"},
- {"Full Name", "displayName"},
- {"Email", "mail"}
- ]},
-</PRE>
-Default is:
-<PRE CLASS="verbatim">
- [{"User", "%u"},
- {"Full Name", "displayName"},
- {"Given Name", "givenName"},
- {"Middle Name", "initials"},
- {"Family Name", "sn"},
- {"Nickname", "%u"},
- {"Birthday", "birthDay"},
- {"Country", "c"},
- {"City", "l"},
- {"Email", "mail"},
- {"Organization Name", "o"},
- {"Organization Unit", "ou"}]
-</PRE><DT CLASS="dt-description"><B><TT>ldap_search_reported</TT></B><DD CLASS="dd-description"> This option defines search fields to be reported.
- Format:
- <TT>[Name, VCard_Name, ...]</TT>
- where
- <TT>Name</TT> is the name of field in the search form. Will be automatically
- translated according to definitions in translation files (see
- <TT>msgs/*.msg</TT> for available words).
- <TT>VCard_Name</TT> is the name of vCard field defined in <TT>ldap_vcard_map</TT> option.
- Example:
-<PRE CLASS="verbatim">
- {ldap_search_reported,
- [{"Full Name", "FN"},
- {"Email", "EMAIL"},
- {"Birthday", "BDAY"},
- {"Nickname", "NICKNAME"}
- ]},
-</PRE>
-Default is:
-<PRE CLASS="verbatim">
- [{"Full Name", "FN"},
- {"Given Name", "GIVEN"},
- {"Middle Name", "MIDDLE"},
- {"Family Name", "FAMILY"},
- {"Nickname", "NICKNAME"},
- {"Birthday", "BDAY"},
- {"Country", "CTRY"},
- {"City", "LOCALITY"},
- {"Email", "EMAIL"},
- {"Organization Name", "ORGNAME"},
- {"Organization Unit", "ORGUNIT"}]
-</PRE></DL>
-<!--TOC subsubsection Examples-->
+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.<BR>
+<BR>
+<!--TOC subsubsection s2s Manager-->
-<H4 CLASS="subsubsection"><A NAME="htoc69">A.21.5</A> Examples</H4><!--SEC END -->
+<H4 CLASS="subsubsection"><A NAME="htoc81">10.1.4</A> <A NAME="s2smanager">s2s Manager</A></H4><!--SEC END -->
-<A NAME="sec:ldapexamples"></A>
-<!--TOC paragraph Common example-->
+<A NAME="sec:s2smanager"></A>
+
+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.<BR>
+<BR>
+<!--TOC subsection Clustering Setup-->
-<H5 CLASS="paragraph">Common example</H5><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc82">10.2</A> <A NAME="cluster">Clustering Setup</A></H3><!--SEC END -->
-Let's say <TT>ldap.mydomain.org</TT> is the name of our LDAP server. We have
-users with their passwords in <TT>"ou=Users,dc=mydomain,dc=org"</TT> directory.
-Also we have addressbook, which contains users emails and their additional
-infos in <TT>"ou=AddressBook,dc=mydomain,dc=org"</TT> directory. Corresponding
-authentication section should looks like this:
+<A NAME="sec:cluster"></A>
+
+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:
+<OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
+Copy <CODE>~ejabberd/.erlang.cookie</CODE> file from <TT>first</TT> to
+ <TT>second</TT>.<BR>
+<BR>
+(alt) You can also add `<CODE>-cookie content_of_.erlang.cookie</CODE>'
+ option to all `<TT>erl</TT>' commands below.<BR>
+<BR>
+<LI CLASS="li-enumerate">On <TT>second</TT> run the following command as the <TT>ejabberd</TT> daemon user,
+ in the working directory of <TT>ejabberd</TT>:
<PRE CLASS="verbatim">
- %% authentication method
- {auth_method, ldap}.
- %% DNS name of our LDAP server
- {ldap_servers, ["ldap.mydomain.org"]}.
- %% Bind to LDAP server as "cn=Manager,dc=mydomain,dc=org" with password "secret"
- {ldap_rootdn, "cn=Manager,dc=mydomain,dc=org"}.
- {ldap_password, "secret"}.
- %% define the user's base
- {ldap_base, "ou=Users,dc=mydomain,dc=org"}.
- %% We want to authorize users from 'shadowAccount' object class only
- {ldap_filter, "(objectClass=shadowAccount)"}.
+erl -sname ejabberd \
+ -mnesia extra_db_nodes "['ejabberd@first']" \
+ -s mnesia
</PRE>
-Now we want to use users LDAP-info as their vCards. We have four attributes
-defined in our LDAP schema: <TT>"mail"</TT> — email address, <TT>"givenName"</TT>
-— first name, <TT>"sn"</TT> — second name, <TT>"birthDay"</TT> — birthday.
-Also we want users to search each other. Let's see how we can set it up:
+ This will start Mnesia serving the same database as <TT>ejabberd@first</TT>.
+ You can check this by running the command `<CODE>mnesia:info().</CODE>'. You
+ should see a lot of remote tables and a line like the following:
<PRE CLASS="verbatim">
- {modules,
- ...
- {mod_vcard_ldap,
- [
- %% We use the same server and port, but want to bind anonymously because
- %% our LDAP server accepts anonymous requests to
- %% "ou=AddressBook,dc=mydomain,dc=org" subtree.
- {ldap_rootdn, ""},
- {ldap_password, ""},
- %% define the addressbook's base
- {ldap_base, "ou=AddressBook,dc=mydomain,dc=org"},
- %% user's part of JID is located in the "mail" attribute
- {ldap_uidattr, "mail"},
- %% common format for our emails
- {ldap_uidattr_format, "%u@mail.mydomain.org"},
- %% We have to define empty filter here, because entries in addressbook doesn't
- %% belong to shadowAccount object class
- {ldap_filter, ""},
- %% Now we want to define vCard pattern
- {ldap_vcard_map,
- [{"NICKNAME", "%u", []}, % just use user's part of JID as his nickname
- {"GIVEN", "%s", ["givenName"]},
- {"FAMILY", "%s", ["sn"]},
- {"FN", "%s, %s", ["sn", "givenName"]}, % example: "Smith, John"
- {"EMAIL", "%s", ["mail"]},
- {"BDAY", "%s", ["birthDay"]}]},
- %% Search form
- {ldap_search_fields,
- [{"User", "%u"},
- {"Name", "givenName"},
- {"Family Name", "sn"},
- {"Email", "mail"},
- {"Birthday", "birthDay"}]},
- %% vCard fields to be reported
- %% Note that JID is always returned with search results
- {ldap_search_reported,
- [{"Full Name", "FN"},
- {"Nickname", "NICKNAME"},
- {"Birthday", "BDAY"}]}
- ]}
- ...
- }.
-</PRE>
-Note that <TT>mod_vcard_ldap</TT> module checks an existence of the user before
-searching his info in LDAP.<BR>
+running db nodes = [ejabberd@first, ejabberd@second]
+</PRE><BR>
<BR>
-<!--TOC paragraph Active Directory-->
-
-<H5 CLASS="paragraph">Active Directory</H5><!--SEC END -->
-
-Active Directory is just an LDAP-server with predefined attributes. Sample
-config file is listed below:
+<LI CLASS="li-enumerate">Now run the following in the same `<TT>erl</TT>' session:
<PRE CLASS="verbatim">
- {auth_method, ldap}.
- {ldap_servers, ["office.org"]}. % List of LDAP servers
- {ldap_base, "DC=office,DC=org"}. % Search base of LDAP directory
- {ldap_rootdn, "CN=Administrator,CN=Users,DC=office,DC=org"}. % LDAP manager
- {ldap_password, "*******"}. % Password to LDAP manager
- {ldap_uidattr, "sAMAccountName"}.
- {ldap_filter, "(memberOf=*)"}.
-
- {mod_vcard_ldap,
- [{ldap_vcard_map,
- [{"NICKNAME", "%u", []},
- {"GIVEN", "%s", ["givenName"]},
- {"MIDDLE", "%s", ["initials"]},
- {"FAMILY", "%s", ["sn"]},
- {"FN", "%s", ["displayName"]},
- {"EMAIL", "%s", ["mail"]},
- {"ORGNAME", "%s", ["company"]},
- {"ORGUNIT", "%s", ["department"]},
- {"CTRY", "%s", ["c"]},
- {"LOCALITY", "%s", ["l"]},
- {"STREET", "%s", ["streetAddress"]},
- {"REGION", "%s", ["st"]},
- {"PCODE", "%s", ["postalCode"]},
- {"TITLE", "%s", ["title"]},
- {"URL", "%s", ["wWWHomePage"]},
- {"DESC", "%s", ["description"]},
- {"TEL", "%s", ["telephoneNumber"]}]},
- {ldap_search_fields,
- [{"User", "%u"},
- {"Name", "givenName"},
- {"Family Name", "sn"},
- {"Email", "mail"},
- {"Company", "company"},
- {"Department", "department"},
- {"Role", "title"},
- {"Description", "description"},
- {"Phone", "telephoneNumber"}]},
- {ldap_search_reported,
- [{"Full Name", "FN"},
- {"Nickname", "NICKNAME"},
- {"Email", "EMAIL"}]}
- ]
- }.
+mnesia:change_table_copy_type(schema, node(), disc_copies).
</PRE>
-<!--TOC subsection <TT>mod_version</TT>-->
-
-<H3 CLASS="subsection"><A NAME="htoc70">A.22</A> <TT>mod_version</TT></H3><!--SEC END -->
-
-<A NAME="sec:modversion"></A>
-
-This module implements Software Version (<A HREF="http://www.jabber.org/jeps/jep-0092.html">JEP-0092</A>). Consequently, it
-answers <TT>ejabberd</TT>'s version when queried.<BR>
+ This will create local disc storage for the database.<BR>
<BR>
-Options:
-<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
-<B><TT>iqdisc</TT></B><DD CLASS="dd-description"> This specifies
-the processing discipline for Software Version (<TT>jabber:iq:version</TT>) IQ queries
-(see section <A HREF="#sec:modiqdiscoption">A.2.1</A>).
-</DL>
+(alt) Change storage type of the <TT>scheme</TT> table to `RAM and disc
+ copy' on the second node via the web interface.<BR>
+<BR>
+<LI CLASS="li-enumerate">Now you can add replicas of various tables to this node with
+ `<CODE>mnesia:add_table_copy</CODE>' or
+ `<CODE>mnesia:change_table_copy_type</CODE>' as above (just replace
+ `<CODE>schema</CODE>' with another table name and `<CODE>disc_copies</CODE>'
+ can be replaced with `<CODE>ram_copies</CODE>' or
+ `<CODE>disc_only_copies</CODE>').<BR>
+<BR>
+Which tables to replicate is very dependant on your needs, you can get
+ some hints from the command `<CODE>mnesia:info().</CODE>', by looking at the
+ size of tables and the default storage type for each table on 'first'.<BR>
+<BR>
+Replicating a table makes lookups in this table faster on this node.
+ Writing, on the other hand, will be slower. And of course if machine with one
+ of the replicas is down, other replicas will be used.<BR>
+<BR>
+Also <A HREF="http://www.erlang.se/doc/doc-5.4.9/lib/mnesia-4.2.2/doc/html/Mnesia_chap5.html#5.3">section 5.3 (Table Fragmentation) of Mnesia User's Guide</A> can be helpful.
+ <BR>
+<BR>
+ (alt) Same as in previous item, but for other tables.<BR>
+<BR>
+<LI CLASS="li-enumerate">Run `<CODE>init:stop().</CODE>' or just `<CODE>q().</CODE>' to exit from
+ the Erlang shell. This probably can take some time if Mnesia has not yet
+ transfered and processed all data it needed from <TT>first</TT>.<BR>
+<BR>
+<LI CLASS="li-enumerate">Now run <TT>ejabberd</TT> on <TT>second</TT> with almost the same config as
+ on <TT>first</TT> (you probably do not need to duplicate `<CODE>acl</CODE>'
+ and `<CODE>access</CODE>' options — they will be taken from
+ <TT>first</TT>, and <CODE>mod_muc</CODE> and <CODE>mod_irc</CODE> should be
+ enabled only on one machine in the cluster).
+</OL>
+You can repeat these steps for other machines supposed to serve this
+domain.<BR>
+<BR>
+
<!--TOC section Internationalization and Localization-->
-<H2 CLASS="section"><A NAME="htoc71">B</A> Internationalization and Localization</H2><!--SEC END -->
+<H2 CLASS="section"><A NAME="htoc83">A</A> <A NAME="i18nl10n">Internationalization and Localization</A></H2><!--SEC END -->
<A NAME="sec:i18nl10n"></A>
</PRE>
<BLOCKQUOTE CLASS="figure"><DIV CLASS="center"><DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV>
- <IMG SRC="discorus.png">
+ <IMG SRC="discorus.png" ALT="discorus.png">
<BR>
figure <A HREF="#fig:webadmmainru">3</A> with figure <A HREF="#fig:webadmmain">1</A>)
<BLOCKQUOTE CLASS="figure"><DIV CLASS="center"><DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV>
- <IMG SRC="webadmmainru.png">
+ <IMG SRC="webadmmainru.png" ALT="webadmmainru.png">
<BR>
<BR>
<DIV CLASS="center">Figure 3: Top page from the web interface with HTTP header
- “Accept-Language: ru”</DIV><BR>
+ `Accept-Language: ru'</DIV><BR>
<BR>
<A NAME="fig:webadmmainru"></A>
<DIV CLASS="center"><HR WIDTH="80%" SIZE=2></DIV></DIV></BLOCKQUOTE>
<!--TOC section Release Notes-->
-<H2 CLASS="section"><A NAME="htoc72">C</A> Release Notes</H2><!--SEC END -->
+<H2 CLASS="section"><A NAME="htoc84">B</A> <A NAME="releasenotes">Release Notes</A></H2><!--SEC END -->
<A NAME="sec:releasenotes"></A>
<!--TOC subsection ejabberd 0.9-->
-<H3 CLASS="subsection"><A NAME="htoc73">C.1</A> ejabberd 0.9</H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc85">B.1</A> ejabberd 0.9</H3><!--SEC END -->
<PRE CLASS="verbatim">
Release notes
</PRE>
<!--TOC subsection ejabberd 0.9.1-->
-<H3 CLASS="subsection"><A NAME="htoc74">C.2</A> ejabberd 0.9.1</H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc86">B.2</A> ejabberd 0.9.1</H3><!--SEC END -->
<PRE CLASS="verbatim">
Release notes
</PRE>
<!--TOC subsection ejabberd 0.9.8-->
-<H3 CLASS="subsection"><A NAME="htoc75">C.3</A> ejabberd 0.9.8</H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc87">B.3</A> ejabberd 0.9.8</H3><!--SEC END -->
<PRE CLASS="verbatim">
Release notes
</PRE>
<!--TOC subsection ejabberd 1.0.0-->
-<H3 CLASS="subsection"><A NAME="htoc76">C.4</A> ejabberd 1.0.0</H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc88">B.4</A> ejabberd 1.0.0</H3><!--SEC END -->
<PRE CLASS="verbatim">
Release Notes
</PRE>
<!--TOC subsection ejabberd 1.1.0-->
-<H3 CLASS="subsection"><A NAME="htoc77">C.5</A> ejabberd 1.1.0</H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc89">B.5</A> ejabberd 1.1.0</H3><!--SEC END -->
<PRE CLASS="verbatim">
Release Notes
</PRE>
<!--TOC subsection ejabberd 1.1.1-->
-<H3 CLASS="subsection"><A NAME="htoc78">C.6</A> ejabberd 1.1.1</H3><!--SEC END -->
+<H3 CLASS="subsection"><A NAME="htoc90">B.6</A> ejabberd 1.1.1</H3><!--SEC END -->
<PRE CLASS="verbatim">
Release Notes
</PRE>
<!--TOC section Acknowledgements-->
-<H2 CLASS="section"><A NAME="htoc79">D</A> Acknowledgements</H2><!--SEC END -->
+<H2 CLASS="section"><A NAME="htoc91">C</A> <A NAME="acknowledgements">Acknowledgements</A></H2><!--SEC END -->
<A NAME="sec:acknowledgements"></A>
-
Thanks to all people who contributed to this guide:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Alexey Shchepin (<A HREF="xmpp:aleksey@jabber.ru"><TT>xmpp:aleksey@jabber.ru</TT></A>)
+<LI CLASS="li-itemize">Badlop (<A HREF="xmpp:badlop@jabberes.org"><TT>xmpp:badlop@jabberes.org</TT></A>)
+<LI CLASS="li-itemize">Evgeniy Khramtsov (<A HREF="xmpp:xram@jabber.ru"><TT>xmpp:xram@jabber.ru</TT></A>)
<LI CLASS="li-itemize">Florian Zumbiehl (<A HREF="xmpp:florz@florz.de"><TT>xmpp:florz@florz.de</TT></A>)
<LI CLASS="li-itemize">Michael Grigutsch (<A HREF="xmpp:migri@jabber.i-pobox.net"><TT>xmpp:migri@jabber.i-pobox.net</TT></A>)
<LI CLASS="li-itemize">Mickael Remond (<A HREF="xmpp:mremond@erlang-projects.org"><TT>xmpp:mremond@erlang-projects.org</TT></A>)
<LI CLASS="li-itemize">Sergei Golovan (<A HREF="xmpp:sgolovan@nes.ru"><TT>xmpp:sgolovan@nes.ru</TT></A>)
<LI CLASS="li-itemize">Vsevolod Pelipas (<A HREF="xmpp:vsevoload@jabber.ru"><TT>xmpp:vsevoload@jabber.ru</TT></A>)
</UL>
+<!--TOC section Copyright Information-->
+
+<H2 CLASS="section"><A NAME="htoc92">D</A> <A NAME="copyright">Copyright Information</A></H2><!--SEC END -->
+
+<A NAME="sec:copyright"></A>
+Ejabberd Installation and Operation Guide.<BR>
+Copyright © January 23, 2003 — Alexey Shchepin<BR>
+<BR>
+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
+of the License, or (at your option) any later version.<BR>
+<BR>
+This document is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.<BR>
+<BR>
+You should have received a copy of the GNU General Public License along with
+this document; if not, write to the Free Software Foundation, Inc., 51 Franklin
+Street, Fifth Floor, Boston, MA 02110-1301, USA.<BR>
+<BR>
<!--HTMLFOOT-->
<!--ENDHTML-->
<!--FOOTER-->
\newcommand{\hostitem}[1]{
\titem{hosts} \ind{options!hosts} This option defines the hostnames of the
service (see section~\ref{sec:modhostsoption}). If neither \texttt{hosts} nor
- the old \texttt{host} is present, the prefix ``\jid{#1.}'' is added to all
+ the old \texttt{host} is present, the prefix `\jid{#1.}' is added to all
\ejabberd{} hostnames.
}
+%\newcommand{\quoting}[2][yozhik]{\begin{quotation}\textcolor{#1}{\textit{#2}}\end{quotation}} % Quotes enabled
+%\renewcommand{command}[args][default]{def}
+%\renewcommand{\headrule}{{\color{ejblue}%
+%\hrule width\headwidth height\headrulewidth \vskip-\headrulewidth}}
+
%% Title page
\include{version}
\title{Ejabberd \version\ Installation and Operation Guide}
%% Options
\newcommand{\marking}[1]{#1} % Marking disabled
\newcommand{\quoting}[2][yozhik]{} % Quotes disabled
-\newcommand{\new}{\begin{latexonly}\marginpar{\textsc{new}}\end{latexonly}} % Highlight new features
-\newcommand{\improved}{\begin{latexonly}\marginpar{\textsc{improved}}\end{latexonly}} % Highlight improved features
-\newcommand{\moreinfo}[1]{} % Hide details
+\newcommand{\new}{\marginpar{\textsc{new}}} % Highlight new features
+\newcommand{\improved}{\marginpar{\textsc{improved}}} % Highlight improved features
+
+%% To by-pass errors in the HTML version.
+\newstyle{SPAN}{width:20\%; float:right; text-align:left; margin-left:auto;}
%% Footnotes
\begin{latexonly}
\begin{document}
-\label{sec:titlepage}
+\label{titlepage}
\begin{titlepage}
\maketitle{}
}
\end{center}
- \begin{quotation}\textit{I can thoroughly recommend ejabberd for ease of setup --
+ \begin{quotation}\textit{I can thoroughly recommend ejabberd for ease of setup ---
Kevin Smith, Current maintainer of the Psi project}\end{quotation}
\end{titlepage}
% Input introduction.tex
\input{introduction}
-\section{Installation from Source}
-\label{sec:installation}
+\section{\aname{installsource}{Installation from Source}}
+\label{sec:installsource}
\ind{installation}
-\subsection{Installation Requirements}
+\subsection{\aname{installreq}{Installation Requirements}}
\label{sec:installreq}
+\ind{installation!requirements}
-\subsubsection{``Unix-like'' operating systems}
+\subsubsection{\aname{installrequnix}{`Unix-like' operating systems}}
\label{sec:installrequnix}
-\ind{installation!requirements for ``Unix-like'' operating systems}
-To compile \ejabberd{} on a ``Unix-like'' operating system, you need:
+To compile \ejabberd{} on a `Unix-like' operating system, you need:
\begin{itemize}
-\item GNU Make;
-\item GCC;
-\item libexpat 1.95 or higher;
-\item Erlang/OTP R9C-2 or higher;
-\item OpenSSL 0.9.6 or higher (optional).
-\item Zlib 1.2.3 or higher (optional).
-\item GNU Iconv 1.8 or higher (optional, not needed at all on systems with GNU libc).
+\item GNU Make
+\item GCC
+\item libexpat 1.95 or higher
+\item Erlang/OTP R9C-2 or higher
+\item OpenSSL 0.9.6 or higher (optional)
+\item Zlib 1.2.3 or higher (optional)
+\item GNU Iconv 1.8 or higher (optional, not needed on systems with GNU libc)
\end{itemize}
-\subsubsection{Windows}
+\subsubsection{\aname{installreqwin}{Windows}}
\label{sec:installreqwin}
-\ind{installation!requirements for Windows}
To compile \ejabberd{} on a Windows flavour, you need:
\begin{itemize}
\item \footahref{http://www.zlib.net/}{Zlib 1.2.3 or higher}
\end{itemize}
-\subsection{Obtaining \ejabberd{}}
+\subsection{\aname{obtaining}{Obtaining \ejabberd{}}}
\label{sec:obtaining}
\ind{download}
svn co http://svn.process-one.net/ejabberd/trunk ejabberd
\end{verbatim}
-\subsection{Compilation}
-\label{sec:compilation}
-\ind{compilation}
+\subsection{\aname{compile}{Compilation}}
+\label{sec:compile}
+\ind{installation!compilation}
-\subsubsection{``Unix-like'' operating systems}
-\label{sec:compilationunix}
-\ind{compilation!on ``Unix-like'' operating systems}
+\subsubsection{\aname{compileunix}{`Unix-like' operating systems}}
+\label{sec:compileunix}
-Compile \ejabberd{} on a ``Unix-like'' operating system by executing:
+Compile \ejabberd{} on a `Unix-like' operating system by executing:
\begin{verbatim}
./configure
\item create a directory called \verb|/var/log/ejabberd| to store log files.
\end{itemize}
-\subsubsection{Windows}
-\label{sec:compilationwin}
-\ind{compilation!on Windows}
+Note: if you want to use an external database, you need to execute the configure
+script with the option(s) \term{--enable-odbc} or \term{--enable-odbc
+--enable-mssql}. See section~\ref{sec:database} for more information.
+
+\subsubsection{\aname{compilewin}{Windows}}
+\label{sec:compilewin}
\begin{itemize}
\item Install Erlang emulator (for example, into \verb|C:\Program Files\erl5.3|).
\end{verbatim}
\end{itemize}
-\subsection{Starting}
-\label{sec:starting}
+%TODO: how to compile database support on windows?
+
+\subsection{\aname{start}{Starting}}
+\label{sec:start}
\ind{starting}
+%TODO: update when the ejabberdctl script is made more userfriendly
Execute the following command to start \ejabberd{}:
\begin{verbatim}
erl -pa /var/lib/ejabberd/ebin -sname ejabberd -s ejabberd
\end{verbatim}
In the latter case the Erlang node will be identified using only the first part
-of the host name, i.\,e. other Erlang nodes outside this domain can't contact
+of the host name, i.\,e. other Erlang nodes outside this domain cannot contact
this node.
Note that when using the above command, \ejabberd{} will search for the
But in this case \ejabberd{} can start to work slower.
-\section{Configuration}
-\label{sec:configuration}
-
-\subsection{Initial Configuration}
-\label{sec:initconfig}
+\section{\aname{basicconfig}{Basic Configuration}}
+\label{sec:basicconfig}
\ind{configuration file}
The configuration file will be loaded the first time you start \ejabberd{}. The
configuration file contains a sequence of Erlang terms. Lines beginning with a
\term{`\%'} sign are ignored. Each term is a tuple of which the first element is
the name of an option, and any further elements are that option's values. If the
-configuration file do not contain for instance the ``hosts'' option, the old
+configuration file do not contain for instance the `hosts' option, the old
host name(s) stored in the database will be used.
With these lines the old global options, local options and ACLs will be removed
before new ones are added.
-\subsubsection{Host Names}
-\label{sec:confighostname}
+\subsection{\aname{hostnames}{Host Names}}
+\label{sec:hostnames}
\ind{options!hosts}\ind{host names}
The option \option{hosts} defines a list containing one or more domains that
Examples:
\begin{itemize}
\item Serving one domain:
-\begin{itemize}
-\item \begin{verbatim}
+ \begin{verbatim}
{hosts, ["example.org"]}.
\end{verbatim}
-\item Backwards compatibility with older \ejabberd{} versions can be retained
- with:
+\item Serving one domain, and backwards compatible with older \ejabberd{}
+ versions:
\begin{verbatim}
{host, "example.org"}.
\end{verbatim}
-\end{itemize}
\item Serving two domains:
\begin{verbatim}
{hosts, ["example.net", "example.com"]}.
\end{verbatim}
\end{itemize}
-\subsubsection{Default Language}
-\label{sec:configlanguage}
-\ind{options!language}\ind{language}
-
-The option \option{language} defines the default language of server strings that
-can be seen by \Jabber{} clients. If a \Jabber{} client do not support
-\option{xml:lang}, the specified language is used. The default value for the
-option \option{language} is \term{"en"}. In order to take effect there must be a
-translation file \term{<language>.msg} in \ejabberd{}'s \term{msgs} directory.
-
-Examples:
-\begin{itemize}
-\item To set Russian as default language:
-\begin{verbatim}
- {language, "ru"}.
-\end{verbatim}
-\item To set Spanish as default language:
-\begin{verbatim}
- {language, "es"}.
-\end{verbatim}
-\end{itemize}
-
-\subsubsection{Access Rules}
-\label{sec:configaccess}
-\ind{options!acl}\ind{access rules}\ind{ACL}\ind{Access Control List}
-
-Access control in \ejabberd{} is performed via Access Control Lists (ACLs). The
-declarations of ACLs in the configuration file have the following syntax:
-\begin{verbatim}
- {acl, <aclname>, {<acltype>, ...}}.
-\end{verbatim}
-
-\term{<acltype>} can be one of the following:
-\begin{description}
-\titem{all} Matches all JIDs. Example:
-\begin{verbatim}
-{acl, all, all}.
-\end{verbatim}
-\titem{\{user, <username>\}} Matches the user with the name
- \term{<username>} at the first virtual host. Example:
-\begin{verbatim}
-{acl, admin, {user, "yozhik"}}.
-\end{verbatim}
-\titem{\{user, <username>, <server>\}} Matches the user with the JID
- \term{<username>@<server>} and any resource. Example:
-\begin{verbatim}
-{acl, admin, {user, "yozhik", "example.org"}}.
-\end{verbatim}
-\titem{\{server, <server>\}} Matches any JID from server
- \term{<server>}. Example:
-\begin{verbatim}
-{acl, exampleorg, {server, "example.org"}}.
-\end{verbatim}
-\titem{\{user\_regexp, <regexp>\}} Matches any local user with a name that
- matches \term{<regexp>} at the first virtual host. Example:
-\begin{verbatim}
-{acl, tests, {user, "^test[0-9]*$"}}.
-\end{verbatim}
-%$
-\titem{\{user\_regexp, <regexp>, <server>\}} Matches any user with a name
- that matches \term{<regexp>} at server \term{<server>}. Example:
-\begin{verbatim}
-{acl, tests, {user, "^test", "example.org"}}.
-\end{verbatim}
-\titem{\{server\_regexp, <regexp>\}} Matches any JID from the server that
- matches \term{<regexp>}. Example:
-\begin{verbatim}
-{acl, icq, {server, "^icq\\."}}.
-\end{verbatim}
-\titem{\{node\_regexp, <user\_regexp>, <server\_regexp>\}} Matches any user
- with a name that matches \term{<user\_regexp>} at any server that matches
- \term{<server\_regexp>}. Example:
-\begin{verbatim}
-{acl, yohzik, {node_regexp, "^yohzik$", "^example.(com|org)$"}}.
-\end{verbatim}
-\titem{\{user\_glob, <glob>\}}
-\titem{\{user\_glob, <glob>, <server>\}}
-\titem{\{server\_glob, <glob>\}}
-\titem{\{node\_glob, <user\_glob>, <server\_glob>\}} This is the same as
- above. However, it uses shell glob patterns instead of regexp. These patterns
- can have the following special characters:
- \begin{description}
- \titem{*} matches any string including the null string.
- \titem{?} matches any single character.
- \titem{[...]} matches any of the enclosed characters. Character
- ranges are specified by a pair of characters separated by a \term{`-'}.
- If the first character after \term{`['} is a \term{`!'}, any
- character not enclosed is matched.
- \end{description}
-\end{description}
-
-The following ACLs are pre-defined:
-\begin{description}
-\titem{all} Matches any JID.
-\titem{none} Matches no JID.
-\end{description}
-
-An entry allowing or denying access to different services looks similar to
-this:
-\begin{verbatim}
- {access, <accessname>, [{allow, <aclname>},
- {deny, <aclname>},
- ...
- ]}.
-\end{verbatim}
-When a JID is checked to have access to \term{<accessname>}, the server
-sequentially checks if that JID mathes any of the ACLs that are named in the
-second elements of the tuples in the list. If it matches, the first element of
-the first matched tuple is returned, otherwise ``\term{deny}'' is returned.
-
-Example:
-\begin{verbatim}
- {access, configure, [{allow, admin}]}.
- {access, something, [{deny, badmans},
- {allow, all}]}.
-\end{verbatim}
-
-The following access rules are pre-defined:
-\begin{description}
-\titem{all} Always returns ``\term{allow}''
-\titem{none} Always returns ``\term{deny}''
-\end{description}
-
-\subsubsection{Shapers}
-\label{sec:configshaper}
-\ind{options!shaper}\ind{options!maxrate}\ind{shapers}\ind{maxrate}\ind{traffic speed}
+\subsection{\aname{virtualhost}{Virtual Hosting}}
+\label{sec:virtualhost}
+\ind{virtual hosting}\ind{virtual hosts}\ind{virtual domains}
-Shapers enable you to limit connection traffic. The syntax of
-shapers is like this:
-\begin{verbatim}
- {shaper, <shapername>, <kind>}.
-\end{verbatim}
-Currently only one kind of shaper called \term{maxrate} is available. It has the
-following syntax:
+Options can be defined separately for every virtual host using the
+\term{host\_config} option.\ind{options!host\_config} It has the following
+syntax:
\begin{verbatim}
- {maxrate, <rate>}
+ {host_config, <hostname>, [<option>, <option>, ...]}.
\end{verbatim}
-where \term{<rate>} stands for the maximum allowed incomig rate in bytes per
-second.
Examples:
\begin{itemize}
-\item To define a shaper named ``\term{normal}'' with traffic speed limited to
-1,000\,bytes/second:
+\item Domain \jid{example.net} is using the internal authentication method while
+ domain \jid{example.com} is using the \ind{LDAP}LDAP server running on the
+ domain \jid{localhost} to perform authentication:
\begin{verbatim}
- {shaper, normal, {maxrate, 1000}}.
+{host_config, "example.net", [{auth_method, internal}]}.
+
+{host_config, "example.com", [{auth_method, ldap},
+ {ldap_servers, ["localhost"]},
+ {ldap_uidattr, "uid"},
+ {ldap_rootdn, "dc=localdomain"},
+ {ldap_rootdn, "dc=example,dc=com"},
+ {ldap_password, ""}]}.
\end{verbatim}
-\item To define a shaper named ``\term{fast}'' with traffic speed limited to
-50,000\,bytes/second:
+\item Domain \jid{example.net} is using \ind{ODBC}ODBC to perform authentication
+ while domain \jid{example.com} is using the LDAP servers running on the domains
+ \jid{localhost} and \jid{otherhost}:
\begin{verbatim}
- {shaper, fast, {maxrate, 50000}}.
+{host_config, "example.net", [{auth_method, odbc},
+ {odbc_server, "DSN=ejabberd;UID=ejabberd;PWD=ejabberd"}]}.
+
+{host_config, "example.com", [{auth_method, ldap},
+ {ldap_servers, ["localhost", "otherhost"]},
+ {ldap_uidattr, "uid"},
+ {ldap_rootdn, "dc=localdomain"},
+ {ldap_rootdn, "dc=example,dc=com"},
+ {ldap_password, ""}]}.
\end{verbatim}
\end{itemize}
-\subsubsection{Limitation of the number of opened sessions}
-\label{sec:configmaxsessions}
-\ind{options!max\_user\_sessions}
-
-This option specifies the maximum number of sessions (authenticated
-connections) per user. If a user tries to open more than the maximum number of
-allowed sessions, with different resources, the first opened session will be
-disconnected. The error ``\term{session replaced}'' is send to the
-disconnected session. This value is either a number or \term{infinity}. For
-example \verb|{max\_user\_sessions, 10}|. The default value is \term{10}.
-
-This option can be define per virtual host. See section~\ref{sec:configvirtualhost}.
-
-\subsubsection{Listened Sockets}
-\label{sec:configlistened}
+\subsection{\aname{listened}{Listened Sockets}}
+\label{sec:listened}
\ind{options!listen}
The option \option{listen} defines for which addresses and ports \ejabberd{}
The following options are available:
\begin{description}
\titem{\{access, <access rule>\}} \ind{options!access}This option defines
- access to the port. The default value is ``\term{all}''.
+ access to the port. The default value is \term{all}.
\titem{\{certfile, Path\}} Path to a file containing the SSL certificate.
\titem{\{hosts, [Hostnames], [HostOptions]\}} \ind{options!hosts}This option
defines one or more hostnames of connected services and enables you to
\titem{\{ip, IPAddress\}} \ind{options!ip}This option specifies which network
interface to listen for. For example \verb|{ip, {192, 168, 1, 1}}|.
\titem{\{max\_stanza\_size, Size\}} \ind{options!max\_stanza\_size}This
- option specifies an approximate maximal size in bytes of XML stanzas.
- For example \verb|{max\_stanza\_size, 65536}|. The default value
- is ``\term{infinity}''.
+ option specifies an approximate maximum size in bytes of XML stanzas.
+ Approximate, because it is calculated with the precision of one block of
+ readed data. For example \verb|{max\_stanza\_size, 65536}|. The default
+ value is \term{infinity}.
\titem{\{shaper, <access rule>\}} \ind{options!shaper}This option defines a
- shaper for the port (see section~\ref{sec:configshaper}). The default value
- is ``\term{none}''.
+ shaper for the port (see section~\ref{sec:shapers}). The default value
+ is \term{none}.
\titem{ssl} \ind{options!ssl}\ind{SSL}This option specifies that traffic on
the port will be encrypted using SSL. You should also set the
\option{certfile} option. It is recommended to use the \term{tls} option
instead.
- \titem{starttls} \ind{options!starttls}\ind{modules!STARTTLS}This option
+ \titem{starttls} \ind{options!starttls}\ind{STARTTLS}This option
specifies that STARTTLS encryption is available on connections to the port.
You should also set the \option{certfile} option.
\titem{starttls\_required} \ind{options!starttls\_required}This option
should also set the \option{certfile} option.
\titem{zlib} \ind{options!zlib}\ind{protocols!JEP-0138: Stream Compression}\ind{Zlib}This
option specifies that Zlib stream compression (as defined in \jepref{0138})
- is available on connections to the port. Client cannot use stream compression and
- stream encryption simultaneously, so if you specify both \option{tls} (or \option{ssl})
- and \option{zlib} the latter option will not affect connection at all.
+ is available on connections to the port. Client connections cannot use
+ stream compression and stream encryption simultaneously. Hence, if you
+ specify both \option{tls} (or \option{ssl}) and \option{zlib}, the latter
+ option will not affect connections (there will be no stream compression).
\titem{web\_admin} \ind{options!web\_admin}\ind{web interface}This option
enables the web interface for \ejabberd{} administration which is available
at \verb|http://server:port/admin/|. Login and password are the username and
password of one of the registered users who are granted access by the
- ``configure'' access rule.
+ `configure' access rule.
\end{description}
-Also the following global options are available for s2s connections:
+In addition, the following options are available for s2s connections:
\begin{description}
\titem{\{s2s\_use\_starttls, true|false\}}
- \ind{options!s2s\_use\_starttls}This option defines whether to use STARTTLS
- for s2s connections.
- \titem{\{s2s\_certfile, Path\}} \ind{options!s2s\_certificate}Path to the
- file containing the SSL certificate.
+ \ind{options!s2s\_use\_starttls}\ind{STARTTLS}This option defines whether to
+ use STARTTLS for s2s connections.
+ \titem{\{s2s\_certfile, Path\}} \ind{options!s2s\_certificate}Path to a
+ file containing a SSL certificate.
\titem{\{domain\_certfile, Domain, Path\}} \ind{options!domain\_certfile}Path
to the file containing the SSL certificate for the specified domain.
\end{description}
For instance, the following configuration defines that:
\begin{itemize}
\item c2s connections are listened for on port 5222 and 5223 (SSL) and denied
- for the user ``\term{bad}''
+ for the user called `\term{bad}'.
\item s2s connections are listened for on port 5269 with STARTTLS for secured
traffic enabled.
\item Port 5280 is serving the web interface and the HTTP Polling service. Note
that it is also possible to serve them on different ports. The second
- example in section~\ref{sec:webadm} shows how exactly this can be done.
+ example in section~\ref{sec:webinterface} shows how exactly this can be done.
\item All users except for the administrators have a traffic of limit
1,000\,Bytes/second
\item \ind{transports!AIM}The
\footahref{http://ejabberd.jabber.ru/pyaimt}{AIM transport}
\jid{aim.example.org} is connected to port 5233 with password
- ``\term{aimsecret}''
+ `\term{aimsecret}'.
\item \ind{transports!ICQ}The ICQ transport JIT (\jid{icq.example.org} and
\jid{sms.example.org}) is connected to port 5234 with password
- ``\term{jitsecret}''
+ `\term{jitsecret}'.
\item \ind{transports!MSN}The
\footahref{http://ejabberd.jabber.ru/pymsnt}{MSN transport}
\jid{msn.example.org} is connected to port 5235 with password
- ``\term{msnsecret}''
+ `\term{msnsecret}'.
\item \ind{transports!Yahoo}The
\footahref{http://ejabberd.jabber.ru/yahoo-transport-2}{Yahoo! transport}
\jid{yahoo.example.org} is connected to port 5236 with password
- ``\term{yahoosecret}''
+ `\term{yahoosecret}'.
\item \ind{transports!Gadu-Gadu}The \footahref{http://ejabberd.jabber.ru/jabber-gg-transport}{Gadu-Gadu transport} \jid{gg.example.org} is
- connected to port 5237 with password ``\term{ggsecret}''
+ connected to port 5237 with password `\term{ggsecret}'.
\item \ind{transports!email notifier}The
\footahref{http://ejabberd.jabber.ru/jmc}{Jabber Mail Component}
\jid{jmc.example.org} is connected to port 5238 with password
- ``\term{jmcsecret}''
+ `\term{jmcsecret}'.
\end{itemize}
\begin{verbatim}
{acl, blocked, {user, "bad"}}.
</xdb>
\end{verbatim}
-\subsubsection{Modules}
-\label{sec:configmodules}
-\ind{modules}
+\subsection{\aname{auth}{Authentication}}
+\label{sec:auth}
+\ind{authentication}\ind{options!auth\_method}
-The option \term{modules} defines the list of modules that will be loaded after
-\ejabberd{}'s startup. Each entry in the list is a tuple in which the first
-element is the name of a module and the second is a list of options for that
-module. Read section~\ref{sec:modules} for detailed information about modules.
+The option \option{auth\_method} defines the authentication method that is used
+for user authentication:
+\begin{verbatim}
+ {auth_method, [<method>]}.
+\end{verbatim}
-Examples:
+The following authentication methods are supported by \ejabberd{}:
\begin{itemize}
-\item In this simple example, only the module \modecho{} is loaded and no
- options are specified between square brackets:
- \begin{verbatim}
- {modules,
- [{mod_echo, []}
- ]}.
-\end{verbatim}
-\item The second example is also simple: the modules \modecho{}, \modtime{}, and
- \modversion{} are loaded without options. Remark that, besides the last entry,
- all entries end with a comma:
- \begin{verbatim}
- {modules,
- [{mod_echo, []},
- {mod_time, []},
- {mod_version, []}
- ]}.
-\end{verbatim}
+\item internal (default) --- See section~\ref{sec:internalauth}.
+\item external --- There are \footahref{http://ejabberd.jabber.ru/extauth}{some
+ example authentication scripts}.
+\item ldap --- See section~\ref{sec:ldap}.
+\item odbc --- See section~\ref{sec:mysql}, \ref{sec:pgsql},
+ \ref{sec:mssql} and \ref{sec:odbc}.
+\item anonymous --- See section~\ref{sec:saslanonymous}.
\end{itemize}
-\subsubsection{Virtual Hosting}
-\label{sec:configvirtualhost}
-\ind{virtual hosting}\ind{virtual hosts}
+\subsubsection{\aname{internalauth}{Internal}}
+\label{sec:internalauth}
+\ind{internal authentication}\ind{Mnesia}
-Options can be defined separately for every virtual host using the
-\term{host\_config} option.\ind{options!host\_config} It has the following
-syntax:
-\begin{verbatim}
- {host_config, <hostname>, [<option>, <option>, ...]}.
-\end{verbatim}
+\ejabberd{} uses its internal Mnesia database as the default authentication method.
-Examples:
\begin{itemize}
-\item Domain \jid{example.net} is using the internal authentication method while
- domain \jid{example.com} is using the \ind{LDAP}LDAP server running on the domain
- \jid{localhost} to perform authentication:
-\begin{verbatim}
-{host_config, "example.net", [{auth_method, internal}]}.
+\item \term{auth\_method}: The value \term{internal} will enable the internal
+ authentication method.
+\end{itemize}
-{host_config, "example.com", [{auth_method, ldap},
- {ldap_servers, ["localhost"]},
- {ldap_uidattr, "uid"},
- {ldap_rootdn, "dc=localdomain"},
- {ldap_rootdn, "dc=example,dc=com"},
- {ldap_password, ""}]}.
+Examples:
+\begin{itemize}
+\item To use internal authentication on \jid{example.org} and LDAP
+ authentication on \jid{example.net}:
+ \begin{verbatim}
+{host_config, "example.org", [{auth_method, [internal]}]}.
+{host_config, "example.net", [{auth_method, [ldap]}]}.
\end{verbatim}
-\item Domain \jid{example.net} is using \ind{ODBC}ODBC to perform authentication
- while domain \jid{example.com} is using the LDAP servers running on the domains
- \jid{localhost} and \jid{otherhost}:
-\begin{verbatim}
-{host_config, "example.net", [{auth_method, odbc},
- {odbc_server, "DSN=ejabberd;UID=ejabberd;PWD=ejabberd"}]}.
-
-{host_config, "example.com", [{auth_method, ldap},
- {ldap_servers, ["localhost", "otherhost"]},
- {ldap_uidattr, "uid"},
- {ldap_rootdn, "dc=localdomain"},
- {ldap_rootdn, "dc=example,dc=com"},
- {ldap_password, ""}]}.
+\item To use internal authentication on all virtual hosts:
+ \begin{verbatim}
+{auth_method, internal}.
\end{verbatim}
\end{itemize}
-\subsubsection{SASL anonymous and anonymous login}
-\label{sec:configsaslanonymous}
+\subsubsection{\aname{saslanonymous}{SASL Anonymous and Anonymous Login}}
+\label{sec:saslanonymous}
\ind{sasl anonymous}\ind{anonymous login}
-The configuration of the anonymous mode can be done with three
-\term{host\_config} parameters:
-
-\begin{itemize}
-\item \term{auth\_method}: This value is used for defining the authentication method:
-internal, odbc, ldap, external). You now have a special extra option to enable
-anonymous mode: anonymous.
-
-\item \term{allow\_multiple\_connections}: This option can be either true or false and
-is only used when the anonymous mode is enabled. Setting it to true means that
-the same username will be able to be taken several time in anonymous login
-mode if different resource are used to connect. This option is only useful in
-very special cases. It defaults to false.
+%TODO: introduction; tell what people can do with this
+The anonymous authentication method can be configured with the following
+options. Remember that you can use the \term{host\_config} option to set virtual
+host specific options (see section~\ref{sec:virtualhost}). Note that there also
+is a detailed tutorial regarding \footahref{http://support.process-one.net/doc/display/MESSENGER/Anonymous+users+support}{SASL
+Anonymous and anonymous login configuration}.
+\begin{itemize}
+\item \term{auth\_method}: The value \term{anonymous} will enable the anonymous
+ authentication method.
+\item \term{allow\_multiple\_connections}: This value for this option can be
+ either \term{true} or \term{false} and is only used when the anonymous mode is
+ enabled. Setting it to \term{true} means that the same username can be taken
+ multiple times in anonymous login mode if different resource are used to
+ connect. This option is only useful in very special occasions. The default
+ value is \term{false}.
\item \term{anonymous\_protocol}: This option can take three values:
- \term{sasl\_anon}, \term{login\_anon} or both. \term{sasl\_anon} means that
- SASL anonymous mode is enabled. \term{login\_anon} means that anonymous
- login mode is enabled. both means that SASL anonymous and login anonymous are
- enabled.
+ \term{sasl\_anon}, \term{login\_anon} or \term{both}. \term{sasl\_anon} means
+ that the SASL Anonymous method will be used. \term{login\_anon} means that the
+ anonymous login method will be used. \term{both} means that SASL Anonymous and
+ login anonymous are both enabled.
\end{itemize}
Those options are defined for each virtual host with the \term{host\_config}
-parameter (see section~\ref{sec:configvirtualhost}).
+parameter (see section~\ref{sec:virtualhost}).
Examples:
\begin{itemize}
-\item To enable anonymous login on a virtual host:
-\begin{verbatim}
-{host_config, "public.example.org", [{auth_method, anonymous},
+\item To enable anonymous login on all virtual hosts:
+ \begin{verbatim}
+{auth_method, [anonymous]}.
+{anonymous_protocol, login_anon}.
+ \end{verbatim}
+\item Similar as previous example, but limited to \jid{public.example.org}:
+ \begin{verbatim}
+{host_config, "public.example.org", [{auth_method, [anonymous]},
{anonymous_protocol, login_anon}]}.
\end{verbatim}
\item To enable anonymous login and internal authentication on a virtual host:
-\begin{verbatim}
+ \begin{verbatim}
{host_config, "public.example.org", [{auth_method, [anonymous,internal]},
{anonymous_protocol, login_anon}]}.
\end{verbatim}
-\item To enable SASL anonymous on a virtual host:
-\begin{verbatim}
+\item To enable SASL Anonymous on a virtual host:
+ \begin{verbatim}
{host_config, "public.example.org", [{auth_method, [anonymous]},
{anonymous_protocol, sasl_anon}]}.
\end{verbatim}
-\item To enable SASL anonymous and anonymous login on a virtual host:
-\begin{verbatim}
+\item To enable SASL Anonymous and anonymous login on a virtual host:
+ \begin{verbatim}
{host_config, "public.example.org", [{auth_method, [anonymous]},
{anonymous_protocol, both}]}.
\end{verbatim}
-\item To enable SASL anonymous, anonymous login and internal authentication on
+\item To enable SASL Anonymous, anonymous login, and internal authentication on
a virtual host:
-\begin{verbatim}
+ \begin{verbatim}
{host_config, "public.example.org", [{auth_method, [anonymous,internal]},
{anonymous_protocol, both}]}.
\end{verbatim}
\end{itemize}
-A detailled tutorial on SASL anonymous and anonymous login support is
-available from:
-\ahrefurl{http://support.process-one.net/doc/display/MESSENGER/Anonymous+users+support}
-
-\subsection{Relational Database Support}
-\label{sec:relationaldatabase}
-
-\subsubsection{Preliminary steps}
-\label{sec:relationaldatabasecompilation}
-
-If you have installed ejabberd using a binary version, the compilation steps
-are not needed as they have already been done correctly.
+\subsection{\aname{accessrules}{Access Rules}}
+\label{sec:accessrules}
+\ind{options!acl}\ind{access rules}\ind{ACL}\ind{Access Control List}
-Otherwise, to be able to use ejabberd with a relational database you need to
-enable ODBC modules during compilation, even if you want to use ejabberd with
-MySQL or PostgreSQL in native mode. The following \term{configure} command can
-be used to enable the relational modules:
+Access control in \ejabberd{} is performed via Access Control Lists (ACLs). The
+declarations of ACLs in the configuration file have the following syntax:
\begin{verbatim}
-./configure --enable-odbc
+ {acl, <aclname>, {<acltype>, ...}}.
\end{verbatim}
-If you are planning to use Microsoft SQL Server with ODBC, you need to specify
-it from the \term{configure} command before compilation:
+\term{<acltype>} can be one of the following:
+\begin{description}
+\titem{all} Matches all JIDs. Example:
\begin{verbatim}
-./configure --enable-odbc --enable-mssql
+{acl, all, all}.
\end{verbatim}
-
-\subsubsection{Authentication against a relational database}
-\label{sec:relationaldatabaseauth}
-
-ejabberd use its internal Mnesia database as a default. It is however possible
-to use relational database to store persistant, long-living data. When
-switching the \term{auth\_method} from internal to \term{odbc}, you are
-telling ejabberd to use a relational database for authentication. Different
-\term{auth\_method} values can be used for different virtual hosts in the
-system.
-
-The option value name be misleading, as the method name is use both for access
-to relational database through ODBC or through the native interface. In any
-case, the first step is to define the odbc \term{auth\_method}. For example:
+\titem{\{user, <username>\}} Matches the user with the name
+ \term{<username>} at the first virtual host. Example:
\begin{verbatim}
-{host_config, "public.example.org", [{auth_method, [odbc]}]}.
+{acl, admin, {user, "yozhik"}}.
\end{verbatim}
+\titem{\{user, <username>, <server>\}} Matches the user with the JID
+ \term{<username>@<server>} and any resource. Example:
+\begin{verbatim}
+{acl, admin, {user, "yozhik", "example.org"}}.
+\end{verbatim}
+\titem{\{server, <server>\}} Matches any JID from server
+ \term{<server>}. Example:
+\begin{verbatim}
+{acl, exampleorg, {server, "example.org"}}.
+\end{verbatim}
+\titem{\{user\_regexp, <regexp>\}} Matches any local user with a name that
+ matches \term{<regexp>} at the first virtual host. Example:
+\begin{verbatim}
+{acl, tests, {user, "^test[0-9]*$"}}.
+\end{verbatim}
+%$
+\titem{\{user\_regexp, <regexp>, <server>\}} Matches any user with a name
+ that matches \term{<regexp>} at server \term{<server>}. Example:
+\begin{verbatim}
+{acl, tests, {user, "^test", "example.org"}}.
+\end{verbatim}
+\titem{\{server\_regexp, <regexp>\}} Matches any JID from the server that
+ matches \term{<regexp>}. Example:
+\begin{verbatim}
+{acl, icq, {server, "^icq\\."}}.
+\end{verbatim}
+\titem{\{node\_regexp, <user\_regexp>, <server\_regexp>\}} Matches any user
+ with a name that matches \term{<user\_regexp>} at any server that matches
+ \term{<server\_regexp>}. Example:
+\begin{verbatim}
+{acl, yohzik, {node_regexp, "^yohzik$", "^example.(com|org)$"}}.
+\end{verbatim}
+\titem{\{user\_glob, <glob>\}}
+\titem{\{user\_glob, <glob>, <server>\}}
+\titem{\{server\_glob, <glob>\}}
+\titem{\{node\_glob, <user\_glob>, <server\_glob>\}} This is the same as
+ above. However, it uses shell glob patterns instead of regexp. These patterns
+ can have the following special characters:
+ \begin{description}
+ \titem{*} matches any string including the null string.
+ \titem{?} matches any single character.
+ \titem{[...]} matches any of the enclosed characters. Character
+ ranges are specified by a pair of characters separated by a \term{`-'}.
+ If the first character after \term{`['} is a \term{`!'}, any
+ character not enclosed is matched.
+ \end{description}
+\end{description}
-The actual database access is defined in the option \term{odbc\_server}. Its
-value is use to defined if we want to use ODBC, or one of the two native
-interface available, PostgreSQL or MySQL.
-
-To use a relational database through ODBC, you can pass the ODBC connection
-string as \term{odbc\_server} parameter. For example:
+The following ACLs are pre-defined:
+\begin{description}
+\titem{all} Matches any JID.
+\titem{none} Matches no JID.
+\end{description}
+
+An entry allowing or denying access to different services looks similar to
+this:
\begin{verbatim}
-{odbc_server, "DSN=database;UID=ejabberd;PWD=password"}.
+ {access, <accessname>, [{allow, <aclname>},
+ {deny, <aclname>},
+ ...
+ ]}.
\end{verbatim}
+When a JID is checked to have access to \term{<accessname>}, the server
+sequentially checks if that JID mathes any of the ACLs that are named in the
+second elements of the tuples in the list. If it matches, the first element of
+the first matched tuple is returned, otherwise the value `\term{deny}' is
+returned.
-To use the native PostgreSQL interface, you can pass a tuple of the following form as
-parameter:
+Example:
\begin{verbatim}
-{pgsql, "Server", "Database", "Username", "Password"}
+ {access, configure, [{allow, admin}]}.
+ {access, something, [{deny, badmans},
+ {allow, all}]}.
\end{verbatim}
-\term{pgsql} is a keyword that should be kept as is. For example:
+The following access rules are pre-defined:
+\begin{description}
+\titem{all} Always returns the value `\term{allow}'.
+\titem{none} Always returns the value `\term{deny}'.
+\end{description}
+
+\subsection{\aname{shapers}{Shapers}}
+\label{sec:shapers}
+\ind{options!shaper}\ind{options!maxrate}\ind{shapers}\ind{maxrate}\ind{traffic speed}
+
+Shapers enable you to limit connection traffic. The syntax of
+shapers is like this:
\begin{verbatim}
-{odbc_server, {pgsql, "localhost", "database", "ejabberd", "password"}}.
+ {shaper, <shapername>, <kind>}.
+\end{verbatim}
+Currently only one kind of shaper called \term{maxrate} is available. It has the
+following syntax:
+\begin{verbatim}
+ {maxrate, <rate>}
+\end{verbatim}
+where \term{<rate>} stands for the maximum allowed incomig rate in bytes per
+second.
+
+Examples:
+\begin{itemize}
+\item To define a shaper named `\term{normal}' with traffic speed limited to
+1,000\,bytes/second:
+\begin{verbatim}
+ {shaper, normal, {maxrate, 1000}}.
+\end{verbatim}
+\item To define a shaper named `\term{fast}' with traffic speed limited to
+50,000\,bytes/second:
+\begin{verbatim}
+ {shaper, fast, {maxrate, 50000}}.
\end{verbatim}
+\end{itemize}
+
+\subsection{Limiting Opened Sessions}
+\label{sec:configmaxsessions}
+\ind{options!max\_user\_sessions}
-Note that you need to install the Erlang PgSQL library first. This library is
-available from Sourceforge: \ahrefurl{http://cvs.sourceforge.net/viewcvs.py/jungerl/jungerl/lib/pgsql/}
+This option specifies the maximum number of sessions (authenticated
+connections) per user. If a user tries to open more sessions by using different
+resources, the first opened session will be disconnected. The error
+\term{session replaced} will be sent to the disconnected session. The value
+for this option can be either a number, or \term{infinity}. The default
+value is \term{10}.
-To use the native MySQL interface, the same tuple should be passed, except
-that you now have to use the \term{mysql} keyword instead of the \term{pgsql}
-keyword:
+Examples:
+\begin{itemize}
+\item To limit the number of sessions per user to 10 on all virtual
+hosts:
\begin{verbatim}
-{mysql, "Server", "Database", "Username", "Password"}
+ {max\_user\_sessions, 10}.
+\end{verbatim}
+\item This option can be defined per virtual host (see
+section~\ref{sec:virtualhost}). In next example the number of
+sessions per user on the first host is six, while there is no limit on the
+second host:
+\begin{verbatim}
+ {host_config, "example.net", [{max\_user\_sessions, 6}]}.
+ {host_config, "example.com", [{max\_user\_sessions, infinity}]}.
\end{verbatim}
+\end{itemize}
-\term{mysql} is a keyword that should be kept as is. For example:
+\subsection{\aname{language}{Default Language}}
+\label{sec:language}
+\ind{options!language}\ind{language}
+
+The option \option{language} defines the default language of server strings that
+can be seen by \Jabber{} clients. If a \Jabber{} client do not support
+\option{xml:lang}, the specified language is used. The default value is
+\term{en}. In order to take effect there must be a translation file
+\term{<language>.msg} in \ejabberd{}'s \term{msgs} directory.
+
+Examples:
+\begin{itemize}
+\item To set Russian as default language:
\begin{verbatim}
-{odbc_server, {mysql, "localhost", "test", "root", "password"}}.
+ {language, "ru"}.
+\end{verbatim}
+\item To set Spanish as default language:
+\begin{verbatim}
+ {language, "es"}.
\end{verbatim}
+\end{itemize}
-Note that you need to install the Erlang MySQL library first. This library is
-directly available from Process-one website: \ahrefurl{http://support.process-one.net/doc/display/CONTRIBS/Yxa}
-A detailled tutorial to set-up \ejabberd{} using the native MySQL interface is
-available from: \ahrefurl{http://support.process-one.net/doc/display/MESSENGER/Using+ejabberd+with+MySQL+native+driver}
+\section{\aname{database}{Database Configuration}}
+\label{sec:database}
+\ind{database}
+%TODO: this whole section is not yet 100% optimized
-\subsubsection{Relational database for other modules}
-\label{sec:relationaldatabaseextra}
+\ejabberd{} uses its internal Mnesia database by default. However, it is
+possible to use a relational database or an LDAP server to store persistant,
+long-living data. \ejabberd{} is very flexible: you can configure different
+authentication methods for different virtual hosts, you can configure different
+authentication mechanisms for the same virtual host (fallback), you can set
+different storage systems for modules, and so forth.
-It is possible to use a relational database to store pieces of
-information. You can do this by changing the module name to a name with an
-\term{\_odbc} suffix in \ejabberd{} config file. You can use a relational
-database for the following data:
+The following databases are supported by \ejabberd{}:
+\begin{itemize}
+\item \footahref{http://www.microsoft.com/sql/}{Microsoft SQL Server}
+\item \footahref{http://www.erlang.org/doc/doc-5.5.1/lib/mnesia-4.3.2/doc/}{Mnesia}
+\item \footahref{http://mysql.com/}{MySQL}
+\item \footahref{http://en.wikipedia.org/wiki/Open\_Database\_Connectivity}{Any ODBC compatible database}
+\item \footahref{http://www.postgresql.org/}{PostgreSQL}
+\end{itemize}
+The following LDAP servers are tested with \ejabberd{}:
\begin{itemize}
-\item Last connection date and time: Use \term{mod\_last\_odbc} instead of
- \term{mod\_last}.
-\item Offline messages: Use \term{mod\_offline\_odbc} instead of
- \term{mod\_offline}.
-\item Rosters: Use \term{mod\_roster\_odbc} instead of \term{mod\_roster}.
-\item Users' VCARD: Use \term{mod\_vcard\_odbc} instead of \term{mod\_vcard}.
+\item \footahref{http://www.microsoft.com/activedirectory/}{Active Directory}
+ (see section~\ref{sec:ad})
+\item \footahref{http://www.openldap.org/}{OpenLDAP}
+\item Normally any LDAP compatible server should work; inform us about your
+ success with a not-listed server so that we can list it here.
\end{itemize}
-\subsection{Creating an Initial Administrator}
-\label{sec:initialadmin}
+\subsection{\aname{mysql}{MySQL}}
+\label{sec:mysql}
+\ind{MySQL}\ind{MySQL!schema}
-Before the web interface can be entered to perform administration tasks, an
-account with administrator rights is needed on your \ejabberd{} deployment.
+Although this section will describe \ejabberd{}'s configuration when you want to
+use the native MySQL driver, it does not describe MySQL's installation and
+database creation. Check the MySQL documentation and the tutorial \footahref{http://support.process-one.net/doc/display/MESSENGER/Using+ejabberd+with+MySQL+native+driver}{Using ejabberd with MySQL native driver} for information regarding these topics.
+Note that the tutorial contains information about \ejabberd{}'s configuration
+which is duplicate to this section.
+
+Moreover, the file mysql.sql in the directory src/odbc might be interesting for
+you. This file contains the ejabberd schema for MySQL. At the end of the file
+you can find information to update your database schema.
+
+\subsubsection{\aname{compilemysql}{Driver Compilation}}
+\label{sec:compilemysql}
+\ind{MySQL!Driver Compilation}
+
+You can skip this step if you installed \ejabberd{} using a binary installer or
+if the binary packages of \ejabberd{} you are using include support for MySQL.
-Instructions to create an initial administrator account:
\begin{enumerate}
-\item Register an account on your \ejabberd{} deployment. An account can be
- created in two ways:
- \begin{enumerate}
- \item Using the tool \term{ejabberdctl}\ind{ejabberdctl} (see
- section~\ref{sec:ejabberdctl}):
- \begin{verbatim}
-% ejabberdctl node@host register admin example.org password
-\end{verbatim}
- \item Using In-Band Registration (see section~\ref{sec:modregister}): you can
- use a \Jabber{} client to register an account.
- \end{enumerate}
-\item Edit the configuration file to promote the account created in the previous
- step to an account with administrator rights. Note that if you want to add
- more administrators, a seperate acl entry is needed for each administrator.
+\item First, install the \footahref{http://support.process-one.net/doc/display/CONTRIBS/Yxa}{Erlang
+ MySQL library}. Make sure the compiled files are in your Erlang path; you can
+ put them for example in the same directory as your ejabberd .beam files.
+\item Then, configure and install \ejabberd{} with ODBC support enabled (this is
+ also needed for native MySQL support!). This can be done, by using next
+ commands:
\begin{verbatim}
- {acl, admins, {user, "admin", "example.org"}}.
- {access, configure, [{allow, admins}]}.
-\end{verbatim}
-\item Restart \ejabberd{} to load the new configuration.
-\item Open the web interface (\verb|http://server:port/admin/|) in your
- favourite browser. Make sure to enter the \emph{full} JID as username (in this
- example: \jid{admin@example.org}. The reason that you also need to enter the
- suffix, is because \ejabberd{}'s virtual hosting support.
+./configure --enable-odbc && make install
+\end{verbatim}
\end{enumerate}
-\subsection{Online Configuration and Monitoring}
-\label{sec:onlineconfig}
-
-\subsubsection{Web Interface}
-\label{sec:webadm}
-\ind{web interface}
+\subsubsection{\aname{mysqlauth}{Authentication}}
+\label{sec:mysqlauth}
+\ind{MySQL!authentication}
-To perform online configuration of \ejabberd{} you need to enable the
-\term{ejabberd\_http} listener with the option \term{web\_admin} (see
-section~\ref{sec:configlistened}). Then you can open
-\verb|http://server:port/admin/| in your favourite web browser. You
-will be asked to enter the username (the \emph{full} \Jabber{} ID) and password
-of an \ejabberd{} user with administrator rights. After authentication
-you will see a page similar to figure~\ref{fig:webadmmain}.
+The option value name may be misleading, as the \term{auth\_method} name is used
+for access to a relational database through ODBC, as well as through the native
+MySQL interface. Anyway, the first configuration step is to define the odbc
+\term{auth\_method}. For example:
+\begin{verbatim}
+{host_config, "public.example.org", [{auth_method, [odbc]}]}.
+\end{verbatim}
-\begin{figure}[htbp]
- \centering
- \insimg{webadmmain.png}
- \caption{Top page from the web interface}
- \label{fig:webadmmain}
-\end{figure}
-Here you can edit access restrictions, manage users, create backups,
-manage the database, enable/disable ports listened for, view server
-statistics,\ldots
+The actual database access is defined in the option \term{odbc\_server}. Its
+value is used to define if we want to use ODBC, or one of the two native
+interface available, PostgreSQL or MySQL.
-Examples:
-\begin{itemize}
-\item You can serve the web interface on the same port as the
- \ind{protocols!JEP-0025: HTTP Polling}HTTP Polling interface. In this example
- you should point your web browser to \verb|http://example.org:5280/admin/| to
- administer all virtual hosts or to
- \verb|http://example.org:5280/admin/server/example.com/| to administer only
- the virtual host \jid{example.com}. Before you get access to the web interface
- you need to enter as username, the JID and password from a registered user
- that is allowed to configure \ejabberd{}. In this example you can enter as
- username ``\jid{admin@example.net}'' to administer all virtual hosts (first
- URL). If you log in with ``\jid{admin@example.com}'' on \\
- \verb|http://example.org:5280/admin/server/example.com/| you can only
- administer the virtual host \jid{example.com}.
- \begin{verbatim}
- ...
- {acl, admins, {user, "admin", "example.net"}}.
- {host_config, "example.com", [{acl, admins, {user, "admin", "example.com"}}]}.
- {access, configure, [{allow, admins}]}.
- ...
- {hosts, ["example.org"]}.
- ...
- {listen,
- [...
- {5280, ejabberd_http, [http_poll, web_admin]},
- ...
- ]
- }.
+To use the native MySQL interface, you can pass a tuple of the following form as
+parameter:
+\begin{verbatim}
+{mysql, "Server", "Database", "Username", "Password"}
\end{verbatim}
-\item For security reasons, you can serve the web interface on a secured
- connection, on a port differing from the HTTP Polling interface, and bind it
- to the internal LAN IP. The web interface will be accessible by pointing your
- web browser to \verb|https://192.168.1.1:5280/admin/|:
- \begin{verbatim}
- ...
- {hosts, ["example.org"]}.
- ...
- {listen,
- [...
- {5270, ejabberd_http, [http_poll]},
- {5280, ejabberd_http, [web_admin, {ip, {192, 168, 1, 1}},
- tls, {certfile, "/usr/local/etc/server.pem"}]},
- ...
- ]
- }.
+
+\term{mysql} is a keyword that should be kept as is. For example:
+\begin{verbatim}
+{odbc_server, {mysql, "localhost", "test", "root", "password"}}.
\end{verbatim}
-\end{itemize}
-\subsubsection{\term{ejabberdctl}}
-\label{sec:ejabberdctl}
+\subsubsection{\aname{mysqlstorage}{Storage}}
+\label{sec:mysqlstorage}
+\ind{MySQL!storage}
-It is possible to do some administration operations using the command
-line tool \term{ejabberdctl}. You can list all available options by
-running \term{ejabberdctl} without arguments:
-\begin{verbatim}
-% ejabberdctl
-Usage: ejabberdctl node command
+MySQL also can be used to store information into from several \ejabberd{}
+modules. See section~\ref{sec:modoverview} to see which modules have a version
+with the `\_odbc'. This suffix indicates that the module can be used with
+relational databases like MySQL. To enable storage to your database, just make
+sure that your database is running well (see previous sections), and replace the
+suffix-less or ldap module variant with the odbc module variant. Keep in mind
+that you cannot have several variants of the same module loaded!
-Available commands:
- status get ejabberd status
- stop stop ejabberd
- restart restart ejabberd
- reopen-log reopen log file
- register user server password register a user
- unregister user server unregister a user
- backup file store a database backup to file
- restore file restore a database backup from file
- install-fallback file install a database fallback from file
- dump file dump a database to a text file
- load file restore a database from a text file
- import-file file import user data from jabberd 1.4 spool file
- import-dir dir import user data from jabberd 1.4 spool directory
- registered-users list all registered users
- delete-expired-messages delete expired offline messages from database
+\subsection{\aname{mssql}{Microsoft SQL Server}}
+\label{sec:mssql}
+\ind{Microsoft SQL Server}\ind{Microsoft SQL Server!schema}
-Example:
- ejabberdctl ejabberd@host restart
+Although this section will describe \ejabberd{}'s configuration when you want to
+use Microsoft SQL Server, it does not describe Microsoft SQL Server's
+installation and database creation. Check the MySQL documentation and the
+tutorial \footahref{http://support.process-one.net/doc/display/MESSENGER/Using+ejabberd+with+MySQL+native+driver}{Using ejabberd with MySQL native driver} for information regarding these topics.
+Note that the tutorial contains information about \ejabberd{}'s configuration
+which is duplicate to this section.
+
+Moreover, the file mssql.sql in the directory src/odbc might be interesting for
+you. This file contains the ejabberd schema for Microsoft SQL Server. At the end
+of the file you can find information to update your database schema.
+
+\subsubsection{\aname{compilemssql}{Driver Compilation}}
+\label{sec:compilemssql}
+\ind{Microsoft SQL Server!Driver Compilation}
+
+You can skip this step if you installed \ejabberd{} using a binary installer or
+if the binary packages of \ejabberd{} you are using include support for ODBC.
+
+If you want to use Microsoft SQL Server with ODBC, you need to configure,
+compile and install \ejabberd{} with support for ODBC and Microsoft SQL Server
+enabled. This can be done, by using next commands:
+\begin{verbatim}
+./configure --enable-odbc --enable-mssql && make install
\end{verbatim}
-Additional information:
-\begin{description}
-\titem{reopen-log } If you use a tool to rotate logs, you have to configure it
- so that this command is executed after each rotation.
-\titem {backup, restore, install-fallback, dump, load} You can use these
- commands to create and restore backups.
-%%More information about backuping can
-%% be found in section~\ref{sec:backup}.
-\titem{import-file, import-dir} \ind{migration!from jabberd 1.4}\ind{migration!from jabberd2}
- These options can be used to migrate from other \Jabber{}/XMPP servers. There
- exist tutorials to \footahref{http://ejabberd.jabber.ru/jabberd1-to-ejabberd}{migrate from jabberd 1.4}
- and to \footahref{http://ejabberd.jabber.ru/jabberd2-to-ejabberd}{migrate from jabberd2}.
-\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}
+\subsubsection{\aname{mssqlauth}{Authentication}}
+\label{sec:mssqlauth}
+\ind{Microsoft SQL Server!authentication}
+%TODO: not sure if this section is right!!!!!!
-\section{Firewall Settings}
-\label{sec:firewall}
-\ind{firewall}\ind{ports}\ind{SASL}\ind{TLS}\ind{clustering!ports}
+The configuration of Microsoft SQL Server is the same as the configuration of
+ODBC compatible serers (see section~\ref{sec:odbcauth}).
-You need to take the following TCP ports in mind when configuring your firewall:
-\begin{table}[H]
- \centering
- \begin{tabular}{|l|l|}
- \hline Port& Description\\
- \hline \hline 5222& SASL and unencrypted c2s connections.\\
- \hline 5223& Obsolete SSL c2s connections.\\
- \hline 5269& s2s connections.\\
- \hline 4369& Only for clustering (see~\ref{sec:clustering}).\\
- \hline port range& Only for clustring (see~\ref{sec:clustering}). This range
- is configurable (see~\ref{sec:starting}).\\
- \hline
- \end{tabular}
-\end{table}
+\subsubsection{\aname{mssqlstorage}{Storage}}
+\label{sec:mssqlstorage}
+\ind{Microsoft SQL Server!storage}
+Microsoft SQL Server also can be used to store information into from several
+\ejabberd{} modules. See section~\ref{sec:modoverview} to see which modules have
+a version with the `\_odbc'. This suffix indicates that the module can be used
+with relational databases like Microsoft SQL Server. To enable storage to your
+database, just make sure that your database is running well (see previous
+sections), and replace the suffix-less or ldap module variant with the odbc
+module variant. Keep in mind that you cannot have several variants of the same
+module loaded!
-\section{SRV Records}
-\label{sec:srv}
-\ind{SRV Records}\ind{clustering!SRV Records}
+\subsection{\aname{pgsql}{PostgreSQL}}
+\label{sec:pgsql}
+\ind{PostgreSQL}\ind{PostgreSQL!schema}
-\begin{itemize}
-\item General information:
- \footahref{http://en.wikipedia.org/wiki/SRV\_record}{SRV record}
-\item Practical information:
- \footahref{http://jabberd.jabberstudio.org/2/docs/section05.html\#5\_7}{Setting DNS SRV Records}
-\end{itemize}
+Although this section will describe \ejabberd{}'s configuration when you want to
+use the native PostgreSQL driver, it does not describe PostgreSQL's installation
+and database creation. Check the PostgreSQL documentation and the tutorial \footahref{http://support.process-one.net/doc/display/MESSENGER/Using+ejabberd+with+MySQL+native+driver}{Using ejabberd with MySQL native driver} for information regarding these topics.
+Note that the tutorial contains information about \ejabberd{}'s configuration
+which is duplicate to this section.
+Also the file pg.sql in the directory src/odbc might be interesting for you.
+This file contains the ejabberd schema for PostgreSQL. At the end of the file
+you can find information to update your database schema.
-\section{Clustering}
-\label{sec:clustering}
-\ind{clustering}
+\subsubsection{\aname{compilepgsql}{Driver Compilation}}
+\label{sec:compilepgsql}
+\ind{PostgreSQL!Driver Compilation}
-\subsection{How it Works}
-\label{sec:howitworks}
-\ind{clustering!how it works}
+You can skip this step if you installed \ejabberd{} using a binary installer or
+if the binary packages of \ejabberd{} you are using include support for
+PostgreSQL.
-A \Jabber{} domain is served by one or more \ejabberd{} 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
-have the same magic cookie (see Erlang/OTP documentation, in other words the
-file \term{\~{}ejabberd/.erlang.cookie} must be the same on all nodes). This is
-needed because all nodes exchange information about connected users, s2s
-connections, registered services, etc\ldots
+\begin{enumerate}
+\item First, install the Erlang PgSQL library from
+ \footahref{http://jungerl.sourceforge.net/}{Jungerl}. Make sure the compiled
+ files are in your Erlang path; you can put them for example in the same
+ directory as your ejabberd .beam files.
+\item Then, configure, compile and install \ejabberd{} with ODBC support enabled
+ (this is also needed for native PostgreSQL support!). This can be done, by
+ using next commands:
+ \begin{verbatim}
+./configure --enable-odbc && make install
+\end{verbatim}
+\end{enumerate}
-Each \ejabberd{} node has the following modules:
-\begin{itemize}
-\item router,
-\item local router,
-\item session manager,
-\item s2s manager.
-\end{itemize}
+\subsubsection{\aname{pgsqlauth}{Authentication}}
+\label{sec:pgsqlauth}
+\ind{PostgreSQL!authentication}
-\subsubsection{Router}
-\ind{clustering!router}
+The option value name may be misleading, as the \term{auth\_method} name is used
+for access to a relational database through ODBC, as well as through the native
+PostgreSQL interface. Anyway, the first configuration step is to define the odbc
+\term{auth\_method}. For example:
+\begin{verbatim}
+{host_config, "public.example.org", [{auth_method, [odbc]}]}.
+\end{verbatim}
-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.
+The actual database access is defined in the option \term{odbc\_server}. Its
+value is used to define if we want to use ODBC, or one of the two native
+interface available, PostgreSQL or MySQL.
-\subsubsection{Local Router}
-\ind{clustering!local router}
+To use the native PostgreSQL interface, you can pass a tuple of the following
+form as parameter:
+\begin{verbatim}
+{pgsql, "Server", "Database", "Username", "Password"}
+\end{verbatim}
-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.
+\term{pgsql} is a keyword that should be kept as is. For example:
+\begin{verbatim}
+{odbc_server, {pgsql, "localhost", "database", "ejabberd", "password"}}.
+\end{verbatim}
-\subsubsection{Session Manager}
-\ind{clustering!session manager}
+\subsubsection{\aname{pgsqlstorage}{Storage}}
+\label{sec:pgsqlstorage}
+\ind{PostgreSQL!storage}
-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.
+PostgreSQL also can be used to store information into from several \ejabberd{}
+modules. See section~\ref{sec:modoverview} to see which modules have a version
+with the `\_odbc'. This suffix indicates that the module can be used with
+relational databases like PostgreSQL. To enable storage to your database, just
+make sure that your database is running well (see previous sections), and
+replace the suffix-less or ldap module variant with the odbc module variant.
+Keep in mind that you cannot have several variants of the same module loaded!
-\subsubsection{s2s Manager}
-\ind{clustering!s2s manager}
+\subsection{\aname{odbc}{ODBC Compatible}}
+\label{sec:odbc}
+\ind{databases!ODBC}
-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.
+Although this section will describe \ejabberd{}'s configuration when you want to
+use the ODBC driver, it does not describe the installation and database creation
+of your database. Check the documentation of your database. The tutorial \footahref{http://support.process-one.net/doc/display/MESSENGER/Using+ejabberd+with+MySQL+native+driver}{Using ejabberd with MySQL native driver} also can help you. Note that the tutorial
+contains information about \ejabberd{}'s configuration which is duplicate to
+this section.
-\subsection{Clustering Setup}
-\label{sec:cluster}
-\ind{clustering!setup}
+\subsubsection{\aname{compileodbc}{Compilation}}
+\label{sec:compileodbc}
-Suppose you already configured \ejabberd{} on one machine named (\term{first}),
-and you need to setup another one to make an \ejabberd{} cluster. Then do
-following steps:
+You can skip this step if you installed \ejabberd{} using a binary installer or
+if the binary packages of \ejabberd{} you are using include support for
+ODBC.
\begin{enumerate}
-\item Copy \verb|~ejabberd/.erlang.cookie| file from \term{first} to
- \term{second}.
-
- (alt) You can also add ``\verb|-cookie content_of_.erlang.cookie|''
- option to all ``\shell{erl}'' commands below.
+\item First, install the \footahref{http://support.process-one.net/doc/display/CONTRIBS/Yxa}{Erlang
+ MySQL library}. Make sure the compiled files are in your Erlang path; you can
+ put them for example in the same directory as your ejabberd .beam files.
+\item Then, configure, compile and install \ejabberd{} with ODBC support
+ enabled. This can be done, by using next commands:
+ \begin{verbatim}
+./configure --enable-odbc && make install
+\end{verbatim}
+\end{enumerate}
-\item On \term{second} run as the `\term{ejabberd}' user in the directory
- where \ejabberd{} will work later the following command:
+\subsubsection{\aname{odbcauth}{Authentication}}
+\label{sec:odbcauth}
+\ind{ODBC!authentication}
+The first configuration step is to define the odbc \term{auth\_method}. For
+example:
\begin{verbatim}
-erl -sname ejabberd \
- -mnesia extra_db_nodes "['ejabberd@first']" \
- -s mnesia
+{host_config, "public.example.org", [{auth_method, [odbc]}]}.
\end{verbatim}
- This will start Mnesia serving the same database as \node{ejabberd@first}.
- You can check this by running the command ``\verb|mnesia:info().|''. You
- should see a lot of remote tables and a line like the following:
+The actual database access is defined in the option \term{odbc\_server}. Its
+value is used to defined if we want to use ODBC, or one of the two native
+interface available, PostgreSQL or MySQL.
+To use a relational database through ODBC, you can pass the ODBC connection
+string as \term{odbc\_server} parameter. For example:
\begin{verbatim}
-running db nodes = [ejabberd@first, ejabberd@second]
+{odbc_server, "DSN=database;UID=ejabberd;PWD=password"}.
\end{verbatim}
+\subsubsection{\aname{odbcstorage}{Storage}}
+\label{sec:odbcstorage}
+\ind{ODBC!storage}
-\item Now run the following in the same ``\shell{erl}'' session:
+An ODBC compatible database also can be used to store information into from
+several \ejabberd{} modules. See section~\ref{sec:modoverview} to see which
+modules have a version with the `\_odbc'. This suffix indicates that the module
+can be used with ODBC compatible relational databases. To enable storage to your
+database, just make sure that your database is running well (see previous
+sections), and replace the suffix-less or ldap module variant with the odbc
+module variant. Keep in mind that you cannot have several variants of the same
+module loaded!
-\begin{verbatim}
-mnesia:change_table_copy_type(schema, node(), disc_copies).
-\end{verbatim}
+\subsection{\aname{ldap}{LDAP}}
+\label{sec:ldap}
+\ind{databases!LDAP}
- This will create local disc storage for the database.
+\ejabberd{} has built-in LDAP support. You can authenticate users against LDAP
+server and use LDAP directory as vCard storage. Shared rosters are not supported
+yet.
- (alt) Change storage type of `\term{scheme}' table to ``RAM and disc
- copy'' on the second node via the web interface.
+\subsubsection{\aname{ldapconnection}{Connection}}
+\label{sec:ldapconnection}
+Parameters:
+\begin{description}
+\titem{ldap\_server} \ind{options!ldap\_server}IP address or dns name of your
+LDAP server. This option is required.
+\titem{ldap\_port} \ind{options!ldap\_port}Port to connect to your LDAP server.
+ The default value is~389.
+\titem{ldap\_rootdn} \ind{options!ldap\_rootdn}Bind DN. The default value
+ is~\term{""} which means `anonymous connection'.
+\titem{ldap\_password} \ind{options!ldap\_password}Bind password. The default
+ value is \term{""}.
+\end{description}
-\item Now you can add replicas of various tables to this node with
- ``\verb|mnesia:add_table_copy|'' or
- ``\verb|mnesia:change_table_copy_type|'' as above (just replace
- ``\verb|schema|'' with another table name and ``\verb|disc_copies|''
- can be replaced with ``\verb|ram_copies|'' or
- ``\verb|disc_only_copies|'').
+Example:
+\begin{verbatim}
+ {auth_method, ldap}.
+ {ldap_servers, ["ldap.example.org"]}.
+ {ldap_port, 389}.
+ {ldap_rootdn, "cn=Manager,dc=domain,dc=org"}.
+ {ldap_password, "secret"}.
+\end{verbatim}
- Which tables to replicate is very dependant on your needs, you can get
- some hints from the command ``\verb|mnesia:info().|'', by looking at the
- size of tables and the default storage type for each table on 'first'.
+Note that current LDAP implementation does not support SSL secured communication
+and SASL authentication.
- Replicating a table makes lookups in this table faster on this node.
- Writing, on the other hand, will be slower. And of course if machine with one
- of the replicas is down, other replicas will be used.
+\subsubsection{\aname{ldapauth}{Authentication}}
+\label{sec:ldapauth}
- Also \footahref{http://www.erlang.se/doc/doc-5.4.9/lib/mnesia-4.2.2/doc/html/Mnesia\_chap5.html\#5.3}
- {section 5.3 (Table Fragmentation) of Mnesia User's Guide} can be helpful.
- % The above URL needs update every Erlang release!
+You can authenticate users against an LDAP directory. Available options are:
- (alt) Same as in previous item, but for other tables.
+\begin{description}
+\titem{ldap\_base}\ind{options!ldap\_base}LDAP base directory which stores users
+ accounts. This option is required.
+\titem{ldap\_uidattr}\ind{options!ldap\_uidattr}LDAP attribute which holds
+ the user's part of a JID. The default value is \term{"uid"}.
+\titem{ldap\_uidattr\_format}\ind{options!ldap\_uidattr\_format}Format of the
+ \term{ldap\_uidattr} variable. The format \emph{must} contain one and only one
+ pattern variable \term{"\%u"} which will be replaced by the user's part of a
+ JID. For example, \term{"\%u@example.org"}. The default value is \term{"\%u"}.
+\titem{ldap\_filter}\ind{options!ldap\_filter}\ind{protocols!RFC 2254: The String Representation of LDAP Search Filters}
+ \footahref{http://www.faqs.org/rfcs/rfc2254.html}{RFC 2254} LDAP filter. The
+ default is \term{none}. Example:
+ \term{"(\&(objectClass=shadowAccount)(memberOf=Jabber Users))"}. Please, do
+ not forget to close brackets and do not use superfluous whitespaces. Also you
+ \emph{must not} use \option{ldap\_uidattr} attribute in filter because this
+ attribute will be substituted in LDAP filter automatically.
+\end{description}
+\subsubsection{\aname{ldapexamples}{Examples}}
+\label{sec:ldapexamples}
-\item Run ``\verb|init:stop().|'' or just ``\verb|q().|'' to exit from
- the Erlang shell. This probably can take some time if Mnesia has not yet
- transfered and processed all data it needed from \term{first}.
+\paragraph{\aname{ldapcommonexample}{Common example}}
+Let's say \term{ldap.example.org} is the name of our LDAP server. We have
+users with their passwords in \term{"ou=Users,dc=example,dc=org"} directory.
+Also we have addressbook, which contains users emails and their additional
+infos in \term{"ou=AddressBook,dc=example,dc=org"} directory. Corresponding
+authentication section should looks like this:
-\item Now run \ejabberd{} on \term{second} with almost the same config as
- on \term{first} (you probably don't need to duplicate ``\verb|acl|''
- and ``\verb|access|'' options --- they will be taken from
- \term{first}, and \verb|mod_muc| and \verb|mod_irc| should be
- enabled only on one machine in the cluster).
-\end{enumerate}
+\begin{verbatim}
+ %% authentication method
+ {auth_method, ldap}.
+ %% DNS name of our LDAP server
+ {ldap_servers, ["ldap.example.org"]}.
+ %% Bind to LDAP server as "cn=Manager,dc=example,dc=org" with password "secret"
+ {ldap_rootdn, "cn=Manager,dc=example,dc=org"}.
+ {ldap_password, "secret"}.
+ %% define the user's base
+ {ldap_base, "ou=Users,dc=example,dc=org"}.
+ %% We want to authorize users from 'shadowAccount' object class only
+ {ldap_filter, "(objectClass=shadowAccount)"}.
+\end{verbatim}
-You can repeat these steps for other machines supposed to serve this
-domain.
+Now we want to use users LDAP-info as their vCards. We have four attributes
+defined in our LDAP schema: \term{"mail"} --- email address, \term{"givenName"}
+--- first name, \term{"sn"} --- second name, \term{"birthDay"} --- birthday.
+Also we want users to search each other. Let's see how we can set it up:
-% TODO
-% See also the section about ejabberdctl!!!!
-%\section{Backup and Restore}
-%\label{sec:backup}
-%\ind{backup}
+\begin{verbatim}
+ {modules,
+ ...
+ {mod_vcard_ldap,
+ [
+ %% We use the same server and port, but want to bind anonymously because
+ %% our LDAP server accepts anonymous requests to
+ %% "ou=AddressBook,dc=example,dc=org" subtree.
+ {ldap_rootdn, ""},
+ {ldap_password, ""},
+ %% define the addressbook's base
+ {ldap_base, "ou=AddressBook,dc=example,dc=org"},
+ %% user's part of JID is located in the "mail" attribute
+ {ldap_uidattr, "mail"},
+ %% common format for our emails
+ {ldap_uidattr_format, "%u@mail.example.org"},
+ %% We have to define empty filter here, because entries in addressbook does not
+ %% belong to shadowAccount object class
+ {ldap_filter, ""},
+ %% Now we want to define vCard pattern
+ {ldap_vcard_map,
+ [{"NICKNAME", "%u", []}, % just use user's part of JID as his nickname
+ {"GIVEN", "%s", ["givenName"]},
+ {"FAMILY", "%s", ["sn"]},
+ {"FN", "%s, %s", ["sn", "givenName"]}, % example: "Smith, John"
+ {"EMAIL", "%s", ["mail"]},
+ {"BDAY", "%s", ["birthDay"]}]},
+ %% Search form
+ {ldap_search_fields,
+ [{"User", "%u"},
+ {"Name", "givenName"},
+ {"Family Name", "sn"},
+ {"Email", "mail"},
+ {"Birthday", "birthDay"}]},
+ %% vCard fields to be reported
+ %% Note that JID is always returned with search results
+ {ldap_search_reported,
+ [{"Full Name", "FN"},
+ {"Nickname", "NICKNAME"},
+ {"Birthday", "BDAY"}]}
+ ]}
+ ...
+ }.
+\end{verbatim}
-\appendix{}
-\section{Built-in Modules}
-\label{sec:modules}
-\ind{modules}
+Note that \modvcardldap{} module checks for the existence of the user before
+searching in his information in LDAP.
-\subsection{Overview}
-\label{sec:modoverview}
-\ind{modules!overview}\ind{XMPP compliancy}
-The following table lists all modules available in the official \ejabberd{}
-distribution. You can find more
-\footahref{http://ejabberd.jabber.ru/contributions}{contributed modules} on the
-ejabberd website. Please remember that these contributions might not work or
-that they can contain severe bugs and security leaks. Therefore, use them at
-your own risk!
+\paragraph{\aname{ad}{Active Directory}}
+\label{sec:ad}
+\ind{databases!Active Directory}
-You can see which database backend each module needs by looking at the suffix:
-\begin{itemize}
-\item ``\_ldap'', this means that the module needs an LDAP server as backend.
-\item ``\_odbc'', this means that the module needs an ODBC compatible database,
- a MySQL database, or a PostgreSQL database as backend.
-\item Nothing, this means that the modules uses Erlang's built-in database
- Mnesia as backend.
-\end{itemize}
+Active Directory is just an LDAP-server with predefined attributes. A sample
+configuration is showed below:
-\begin{table}[H]
- \centering
- \begin{tabular}{|l|l|l|l|}
- \hline Module & Feature & Dependencies & Needed for XMPP? \\
- \hline \hline \modadhoc{} & Ad-Hoc Commands (\jepref{0050}) & & No \\
- \hline \modannounce{} & Manage announcements & \modadhoc{} & No \\
- \hline \modconfigure{} & Support for online & \modadhoc{} & No \\
- & configuration of ejabberd & & \\
- \hline \moddisco{} & Service Discovery (\jepref{0030}) & & No \\
- \hline \modecho{} & Echoes Jabber packets & & No \\
+\begin{verbatim}
+ {auth_method, ldap}.
+ {ldap_servers, ["office.org"]}. % List of LDAP servers
+ {ldap_base, "DC=office,DC=org"}. % Search base of LDAP directory
+ {ldap_rootdn, "CN=Administrator,CN=Users,DC=office,DC=org"}. % LDAP manager
+ {ldap_password, "*******"}. % Password to LDAP manager
+ {ldap_uidattr, "sAMAccountName"}.
+ {ldap_filter, "(memberOf=*)"}.
+
+ {mod_vcard_ldap,
+ [{ldap_vcard_map,
+ [{"NICKNAME", "%u", []},
+ {"GIVEN", "%s", ["givenName"]},
+ {"MIDDLE", "%s", ["initials"]},
+ {"FAMILY", "%s", ["sn"]},
+ {"FN", "%s", ["displayName"]},
+ {"EMAIL", "%s", ["mail"]},
+ {"ORGNAME", "%s", ["company"]},
+ {"ORGUNIT", "%s", ["department"]},
+ {"CTRY", "%s", ["c"]},
+ {"LOCALITY", "%s", ["l"]},
+ {"STREET", "%s", ["streetAddress"]},
+ {"REGION", "%s", ["st"]},
+ {"PCODE", "%s", ["postalCode"]},
+ {"TITLE", "%s", ["title"]},
+ {"URL", "%s", ["wWWHomePage"]},
+ {"DESC", "%s", ["description"]},
+ {"TEL", "%s", ["telephoneNumber"]}]},
+ {ldap_search_fields,
+ [{"User", "%u"},
+ {"Name", "givenName"},
+ {"Family Name", "sn"},
+ {"Email", "mail"},
+ {"Company", "company"},
+ {"Department", "department"},
+ {"Role", "title"},
+ {"Description", "description"},
+ {"Phone", "telephoneNumber"}]},
+ {ldap_search_reported,
+ [{"Full Name", "FN"},
+ {"Nickname", "NICKNAME"},
+ {"Email", "EMAIL"}]}
+ ]
+ }.
+\end{verbatim}
+
+
+\section{\aname{modules}{Modules Configuration}}
+\label{sec:modules}
+\ind{modules}
+
+The option \term{modules} defines the list of modules that will be loaded after
+\ejabberd{}'s startup. Each entry in the list is a tuple in which the first
+element is the name of a module and the second is a list of options for that
+module.
+
+Examples:
+\begin{itemize}
+\item In this example only the module \modecho{} is loaded and no module
+ options are specified between the square brackets:
+ \begin{verbatim}
+ {modules,
+ [{mod_echo, []}
+ ]}.
+\end{verbatim}
+\item In the second example the modules \modecho{}, \modtime{}, and
+ \modversion{} are loaded without options. Remark that, besides the last entry,
+ all entries end with a comma:
+ \begin{verbatim}
+ {modules,
+ [{mod_echo, []},
+ {mod_time, []},
+ {mod_version, []}
+ ]}.
+\end{verbatim}
+\end{itemize}
+
+\subsection{\aname{modoverview}{Overview}}
+\label{sec:modoverview}
+\ind{modules!overview}\ind{XMPP compliancy}
+
+The following table lists all modules available in the official \ejabberd{}
+distribution. You can find more
+\footahref{http://ejabberd.jabber.ru/contributions}{contributed modules} on the
+\ejabberd{} website. Please remember that these contributions might not work or
+that they can contain severe bugs and security leaks. Therefore, use them at
+your own risk!
+
+You can see which database backend each module needs by looking at the suffix:
+\begin{itemize}
+\item `\_ldap', this means that the module needs an LDAP server as backend.
+\item `\_odbc', this means that the module needs a supported database
+ (see~\ref{sec:database}) as backend.
+\item No suffix, this means that the modules uses Erlang's built-in database
+ Mnesia as backend.
+\end{itemize}
+
+If you want to
+It is possible to use a relational database to store pieces of
+information. You can do this by changing the module name to a name with an
+\term{\_odbc} suffix in \ejabberd{} config file. You can use a relational
+database for the following data:
+
+\begin{itemize}
+\item Last connection date and time: Use \term{mod\_last\_odbc} instead of
+ \term{mod\_last}.
+\item Offline messages: Use \term{mod\_offline\_odbc} instead of
+ \term{mod\_offline}.
+\item Rosters: Use \term{mod\_roster\_odbc} instead of \term{mod\_roster}.
+\item Users' VCARD: Use \term{mod\_vcard\_odbc} instead of \term{mod\_vcard}.
+\end{itemize}
+
+
+\begin{table}[H]
+ \centering
+ \begin{tabular}{|l|l|l|l|}
+ \hline Module & Feature & Dependencies & Needed for XMPP? \\
+ \hline \hline \modadhoc{} & Ad-Hoc Commands (\jepref{0050}) & & No \\
+ \hline \modannounce{} & Manage announcements & \modadhoc{} & No \\
+ \hline \modconfigure{} & Support for online & \modadhoc{} & No \\
+ & configuration of \ejabberd{} & & \\
+ \hline \moddisco{} & Service Discovery (\jepref{0030}) & & No \\
+ \hline \modecho{} & Echoes Jabber packets & & No \\
\hline \modirc{} & IRC transport & & No \\
\hline \modlast{} & Last Activity (\jepref{0012}) & & No \\
- \hline \modlastodbc{} & Last Activity (\jepref{0012}) & ODBC compatible & No \\
- & & database, MySQL & \\
- & & or PostgreSQL & \\
+ \hline \modlastodbc{} & Last Activity (\jepref{0012}) & supported database (*) & No \\
\hline \modmuc{} & Multi-User Chat (\jepref{0045}) & & No \\
\hline \modmuclog{} & Multi-User Chat room logging & \modmuc{} & No \\
\hline \modoffline{} & Offline message storage & & No \\
- \hline \modofflineodbc{} & Offline message storage & ODBC compatible & No \\
- & & database, MySQL & \\
- & & or PostgreSQL & \\
+ \hline \modofflineodbc{} & Offline message storage & supported database (*) & No \\
\hline \modprivacy{} & Blocking Communication & & Yes \\
\hline \modprivate{} & Private XML Storage (\jepref{0049}) & & No \\
\hline \modpubsub{} & Publish-Subscribe (\jepref{0060}) & & No \\
\hline \modregister{} & In-Band Registration (\jepref{0077}) & & No \\
- \hline \modroster{} & Roster management & & Yes (*) \\
- \hline \modrosterodbc{} & Roster management & ODBC compatible & Yes (*) \\
- & & database, MySQL & \\
- & & or PostgreSQL & \\
+ \hline \modroster{} & Roster management & & Yes (**) \\
+ \hline \modrosterodbc{} & Roster management & supported database (*) & Yes (**) \\
\hline \modservicelog{} & Copy user messages to logger service & & No \\
\hline \modsharedroster{} & Shared roster management & \modroster{} or & No \\
& & \modrosterodbc{} & \\
\hline \modtime{} & Entity Time (\jepref{0090}) & & No \\
\hline \modvcard{} & vcard-temp (\jepref{0054}) & & No \\
\hline \modvcardldap{} & vcard-temp (\jepref{0054}) & LDAP server & No \\
- \hline \modvcardodbc{} & vcard-temp (\jepref{0054}) & ODBC compatible & No \\
- & & database, MySQL & \\
- & & or PostgreSQL & \\
+ \hline \modvcardodbc{} & vcard-temp (\jepref{0054}) & supported database (*) & No \\
\hline \modversion{} & Software Version (\jepref{0092}) & & No\\
\hline
\end{tabular}
\end{table}
-(*) This module or a similar one with another database backend is needed for
+\begin{itemize}
+\item (*) For a list of supported databases, see section~\ref{sec:database}.
+\item (**) This module or a similar one with another database backend is needed for
XMPP compliancy.
+\end{itemize}
-\subsection{Common Options}
-\label{sec:modcommonopts}
+\subsection{\aname{modcommonoptions}{Common Options}}
+\label{sec:modcommonoptions}
The following options are used by many modules. Therefore, they are described in
this separate section.
-\subsubsection{\option{iqdisc}}
+\subsubsection{\option{\aname{modiqdiscoption}{iqdisc}}}
\label{sec:modiqdiscoption}
\ind{options!iqdisc}
]}.
\end{verbatim}
-\subsubsection{\option{hosts}}
+\subsubsection{\option{\aname{modhostsoption}{hosts}}}
\label{sec:modhostsoption}
\ind{options!hosts}
...
]}.
\end{verbatim}
- \item Backwards compatibility with older ejabberd versions can be retained
+ \item Backwards compatibility with older \ejabberd{} versions can be retained
with:
\begin{verbatim}
{modules,
\end{verbatim}
\end{itemize}
-\subsection{\modannounce{}}
+\subsection{\aname{modannounce}{\modannounce{}}}
\label{sec:modannounce}
\ind{modules!\modannounce{}}\ind{MOTD}\ind{message of the day}\ind{announcements}
\end{verbatim}
\end{itemize}
-\subsection{\moddisco{}}
+\subsection{\aname{moddisco}{\moddisco{}}}
\label{sec:moddisco}
\ind{modules!\moddisco{}}\ind{protocols!JEP-0030: Service Discovery}\ind{protocols!JEP-0011: Jabber Browsing}\ind{protocols!JEP-0094: Agent Information}
\end{itemize}
-\subsection{\modecho{}}
+\subsection{\aname{modecho}{\modecho{}}}
\label{sec:modecho}
\ind{modules!\modecho{}}\ind{debugging}
you can find a few more examples in section~\ref{sec:modhostsoption}.
\end{itemize}
-\subsection{\modirc{}}
+\subsection{\aname{modirc}{\modirc{}}}
\label{sec:modirc}
\ind{modules!\modirc{}}\ind{IRC}
End user information:
\ind{protocols!groupchat 1.0}\ind{protocols!JEP-0045: Multi-User Chat}
\begin{itemize}
-\item A \Jabber{} client with ``groupchat 1.0'' support or Multi-User
+\item A \Jabber{} client with `groupchat 1.0' support or Multi-User
Chat support (\jepref{0045}) is necessary to join IRC channels.
\item An IRC channel can be joined in nearly the same way as joining a
\Jabber{} Multi-User Chat room. The difference is that the room name will
- be ``channel\%\jid{irc.example.org}'' in case \jid{irc.example.org} is
- the IRC server hosting ``channel''. And of course the host should point
+ be `channel\%\jid{irc.example.org}' in case \jid{irc.example.org} is
+ the IRC server hosting `channel'. And of course the host should point
to the IRC transport instead of the Multi-User Chat service.
-\item You can register your nickame by sending ``IDENTIFY password'' to \\
+\item You can register your nickame by sending `IDENTIFY password' to \\
\jid{nickserver!irc.example.org@irc.jabberserver.org}.
-\item Entering your password is possible by sending ``LOGIN nick password'' \\
+\item Entering your password is possible by sending `LOGIN nick password' \\
to \jid{nickserver!irc.example.org@irc.jabberserver.org}.
\item When using a popular \Jabber{} server, it can occur that no
connection can be achieved with some IRC servers because they limit the
Examples:
\begin{itemize}
\item In the first example, the IRC transport is available on (all) your
- virtual host(s) with the prefix ``\jid{irc.}''. Furthermore, anyone is
+ virtual host(s) with the prefix `\jid{irc.}'. Furthermore, anyone is
able to use the transport.
\begin{verbatim}
{modules,
...
]}.
\end{verbatim}
-% bug in current svn!!: irc-transport.example.com will *not* show up in the service discovery items; instead you will see irc.example.com!!!!
+%TODO: bug in current svn!: irc-transport.example.com will *not* show up in the
+% service discovery items; instead you will see irc.example.com
\item In next example the IRC transport is available on the two virtual hosts
\jid{example.net} and \jid{example.com} with different prefixes on each host.
Moreover, the transport is only accessible by paying customers registered on
\end{verbatim}
\end{itemize}
-\subsection{\modlast{}}
+\subsection{\aname{modlast}{\modlast{}}}
\label{sec:modlast}
\ind{modules!\modlast{}}\ind{protocols!JEP-0012: Last Activity}
\iqdiscitem{Last activity (\ns{jabber:iq:last})}
\end{description}
-\subsection{\modmuc{}}
+\subsection{\aname{modmuc}{\modmuc{}}}
\label{sec:modmuc}
\ind{modules!\modmuc{}}\ind{protocols!JEP-0045: Multi-User Chat}\ind{conferencing}
administer his room). By sending a message to the service JID,
administrators can send service messages that will be displayed in every
active room.
-
- \titem{history\_size} \ind{options!history\_size}a small history of the
- current discussion is send to users when they enter the room. This option make
- it possible to define the number of history messages to keep and send to the
- user joining the room. The value is a integer. Setting the value to \term{0}
- disable the history feature and nothing is kept in memory. The default value
- is \term{20}. This value is global and affects all MUC rooms on the server.
+\titem{history\_size} \ind{options!history\_size}A small history of the
+ current discussion is sent to users when they enter the room. With this option
+ you can define the number of history messages to keep and send to users
+ joining the room. The value is an integer. Setting the value to \term{0}
+ disables the history feature and, as a result, nothing is kept in memory. The
+ default value is \term{20}. This value is global and thus affects all rooms on
+ the server.
\end{description}
Examples:
service. Everyone will also be able to create new rooms but only the user
\jid{admin@example.org} is allowed to administrate any room. In this
example he is also a global administrator. When \jid{admin@example.org}
- sends a message such as ``Tomorrow, the \Jabber{} server will be moved
+ sends a message such as `Tomorrow, the \Jabber{} server will be moved
to new hardware. This will involve service breakdowns around 23:00 UMT.
- We apologise for this inconvenience.'' to \jid{conference.example.org},
+ We apologise for this inconvenience.' to \jid{conference.example.org},
it will be displayed in all active rooms. In this example the history
feature is disabled.
\begin{verbatim}
paying customers registered on our domains and on other servers. Of course
the administrator is also allowed to access rooms. In addition, he is the
only authority able to create and administer rooms. When
- \jid{admin@example.org} sends a message such as ``Tomorrow, the \Jabber{}
+ \jid{admin@example.org} sends a message such as `Tomorrow, the \Jabber{}
server will be moved to new hardware. This will involve service breakdowns
- around 23:00 UMT. We apologise for this inconvenience.'' to
+ around 23:00 UMT. We apologise for this inconvenience.' to
\jid{conference.example.org}, it will be displayed in all active rooms. No
\term{history\_size} option is used, this means that the feature is enabled
and the default value of 20 history messages will be send to the users.
\end{verbatim}
\end{itemize}
-\subsection{\modmuclog{}}
+\subsection{\aname{modmuclog}{\modmuclog{}}}
\label{sec:modmuclog}
\ind{modules!\modmuclog{}}
-This module enables optional logging of Multi-User Chat conversations to HTML.
-Once you enable this module, join a chatroom with enought privileges using a MUC capable Jabber client,
-request the configuration form and there you will have an option to enable chatroom logging.
+This module enables optional logging of Multi-User Chat (MUC) conversations to
+HTML. Once you enable this module, users can join a chatroom using a MUC capable
+Jabber client, and if they have enough privileges, they can request the
+configuration form in which they can set the option to enable chatroom logging.
-Some of the features of generated logs:
+Features:
\begin{itemize}
-\item A lot of information about chatroom is added on top of the page: Room title, JID, subject author, subject and configuration.
-\item Room title and JID are links to join the chatroom (using XMPP-IRI).
+\item Chatroom details are added on top of each page: room title, JID,
+ author, subject and configuration.
+\item \ind{protocols!RFC 4622: Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)}
+ Room title and JID are links to join the chatroom (using
+ \footahref{http://www.ietf.org/rfc/rfc4622.txt}{XMPP URIs}).
\item Subject and chatroom configuration changes are tracked and displayed.
-\item Joins, leaves, nick changes, kicks, bans and /me are tracked and displayed, including the reason when available.
+\item Joins, leaves, nick changes, kicks, bans and `/me' are tracked and
+ displayed, including the reason if available.
\item Generated HTML files are XHTML 1.0 Transitional and CSS compliant.
\item Timestamps are self-referencing links.
\item Links on top for quicker navigation: Previous day, Next day, Up.
\item CSS is used for style definition, and a custom CSS file can be used.
\item URLs on messages and subjects are converted to hyperlinks.
\item Timezone used on timestamps is shown on the log files.
-\item A custom link can be added on top of page.
+\item A custom link can be added on top of each page.
\end{itemize}
Options:
\begin{description}
\titem{access\_log}\ind{options!access\_log}
- Restricts which users are allowed to enable or disable chatroom logging using ACL and ACCESS.
- Default: \term{muc\_admin}.
- If you want to allow any chatroom owner put: \term{muc}.
+ This option restricts which users are allowed to enable or disable chatroom
+ logging. The default value is \term{muc\_admin}. Note for this default setting
+ you need to have an access rule for \term{muc\_admin} in order to take effect.
\titem{cssfile}\ind{options!cssfile}
- If HTMLs will use a custom CSS file or the embedded one.
- Allowed values:
- \term{false}: HTMLs will include the standard CSS code;
- \term{"CSS-URL"}: the URL of the CSS file (for example: "http://example.com/my.css").
- Default: \term{false}.
+ With this option you can set whether the HTML files should have a custom CSS
+ file or if they need to use the embedded CSS file. Allowed values are
+ \term{false} and an URL to a CSS file. With the first value, HTML files will
+ include the embedded CSS code. With the latter, you can specify the URL of the
+ custom CSS file (for example: `http://example.com/my.css'). The default value
+ is \term{false}.
\titem{dirtype}\ind{options!dirtype}
- Type of directory that will be created.
- Allowed values:
- \term{subdirs}: creates subdirectories for year and month;
- \term{plain}: the filename contains the full date, no subdirs.
- Default: \term{subdirs}.
+ The type of the created directories can be specified with this option. Allowed
+ values are \term{subdirs} and \term{plain}. With the first value,
+ subdirectories are created for each year and month. With the latter, the
+ names of the log files contain the full date, and there are no subdirectories.
+ The default value is \term{subdirs}.
\titem{outdir}\ind{options!outdir}
- Full path to the directory where html will be generated.
- Make sure the system user has write access on that directory.
- Default: \term{"www/muc"}.
+ This option sets the full path to the directory in which the HTML files should
+ be stored. Make sure the \ejabberd{} daemon user has write access on that
+ directory. The default value is \term{"www/muc"}.
\titem{timezone}\ind{options!timezone}
- What timezone should be used.
- Allowed values:
- \term{local}: use local time, as reported to Erlang by the operating system;
- \term{universal}: use GMT/UTC time.
- Default: \term{local}.
+ The time zone for the logs is configurable with this option. Allowed values
+ are \term{local} and \term{universal}. With the first value, the local time,
+ as reported to Erlang by the operating system, will be used. With the latter,
+ GMT/UTC time will be used. The default value is \term{local}.
\titem{top\_link}\ind{options!top\_link}
- Customizable link on top right corner. Syntax of this option: \term{\{"URL", "Text"\}}.
- Default: \term{\{"/", "Home"\}}.
+ With this option you can customize the link on the top right corner of each
+ log file. The syntax of this option is \term{\{"URL", "Text"\}}. The default
+ value is \term{\{"/", "Home"\}}.
\end{description}
-Example configuration:
-\begin{verbatim}
+Examples:
+\begin{itemize}
+\item In the first example any chatroom owner can enable logging, and a
+ custom CSS file will be used (http://example.com/my.css). Further, the names
+ of the log files will contain the full date, and there will be no
+ subdirectories. The log files will be stored in /var/www/muclogs, and the
+ time zone will be GMT/UTC. Finally, the top link will be
+ \verb|<a href="http://www.jabber.ru">Jabber.ru</a>|.
+ \begin{verbatim}
+ {access, muc, [{allow, all}]}.
+ ...
{modules,
[
...
...
]}.
\end{verbatim}
+ \item In the second example only \jid{admin1@example.org} and
+ \jid{admin2@example.net} can enable logging, and the embedded CSS file will be
+ used. Further, the names of the log files will only contain the day (number),
+ and there will be subdirectories for each year and month. The log files will
+ be stored in /var/www/muclogs, and the local time will be used. Finally, the
+ top link will be the default \verb|<a href="/">Home</a>|.
+ \begin{verbatim}
+ {acl, admins, {user, "admin1", "example.org"}}.
+ {acl, admins, {user, "admin2", "example.net"}}.
+ ...
+ {access, muc_log, [{allow, admins},
+ {deny, all}]}.
+ ...
+ {modules,
+ [
+ ...
+ {mod_muc_log, [
+ {access_log, muc_log},
+ {cssfile, false},
+ {dirtype, subdirs},
+ {outdir, "/var/www/muclogs"},
+ {timezone, local}
+ ]},
+ ...
+ ]}.
+\end{verbatim}
+\end{itemize}
-\subsection{\modoffline{}}
+\subsection{\aname{modoffline}{\modoffline{}}}
\label{sec:modoffline}
\ind{modules!\modoffline{}}
\term{ejabberdctl}\ind{ejabberdctl} has a command to delete expired messages
(see section~\ref{sec:ejabberdctl}).
-\subsection{\modprivacy{}}
+\subsection{\aname{modprivacy}{\modprivacy{}}}
\label{sec:modprivacy}
\ind{modules!\modprivacy{}}\ind{Blocking Communication}\ind{Privacy Rules}\ind{protocols!RFC 3921: XMPP IM}
their \Jabber{} client, they will be able to:
\begin{quote}
\begin{itemize}
-\item Retrieving one's privacy lists.
-\item Adding, removing, and editing one's privacy lists.
-\item Setting, changing, or declining active lists.
+\item Retrieving one's privacy lists.
+\item Adding, removing, and editing one's privacy lists.
+\item Setting, changing, or declining active lists.
\item Setting, changing, or declining the default list (i.e., the list that
- is active by default).
+ is active by default).
\item Allowing or blocking messages based on JID, group, or subscription type
- (or globally).
+ (or globally).
\item Allowing or blocking inbound presence notifications based on JID, group,
- or subscription type (or globally).
+ or subscription type (or globally).
\item Allowing or blocking outbound presence notifications based on JID, group,
- or subscription type (or globally).
+ or subscription type (or globally).
\item Allowing or blocking IQ stanzas based on JID, group, or subscription type
- (or globally).
+ (or globally).
\item Allowing or blocking all communications based on JID, group, or
subscription type (or globally).
\end{itemize}
\iqdiscitem{Blocking Communication (\ns{jabber:iq:privacy})}
\end{description}
-\subsection{\modprivate{}}
+\subsection{\aname{modprivate}{\modprivate{}}}
\label{sec:modprivate}
\ind{modules!\modprivate{}}\ind{protocols!JEP-0049: Private XML Storage}\ind{protocols!JEP-0048: Bookmark Storage}
\iqdiscitem{Private XML Storage (\ns{jabber:iq:private})}
\end{description}
-\subsection{\modpubsub{}}
+\subsection{\aname{modpubsub}{\modpubsub{}}}
\label{sec:modpubsub}
\ind{modules!\modpubsub{}}\ind{protocols!JEP-0060: Publish-Subscribe}
be served, you can use this option. If absent, only the main \ejabberd{}
host is served. % Not a straigtforward description! This needs to be improved!
\titem{access\_createnode} \ind{options!access\_createnode}
- Restricts which users are allowed to create pubsub nodes using ACL and ACCESS.
- Default: \term{pubsub\_createnode}.
+ This option restricts which users are allowed to create pubsub nodes using
+ ACL and ACCESS. The default value is \term{pubsub\_createnode}. % Not clear enough + do not use abbreviations.
\end{description}
Example:
]}.
\end{verbatim}
-\subsection{\modregister{}}
+\subsection{\aname{modregister}{\modregister{}}}
\label{sec:modregister}
\ind{modules!\modregister{}}\ind{protocols!JEP-0077: In-Band Registration}\ind{public registration}
Options:
\begin{description}
\titem{access} \ind{options!access}This option can be configured to specify
- rules to restrict registration. If a rule returns ``deny'' on the requested
+ rules to restrict registration. If a rule returns `deny' on the requested
user name, registration for that user name is dennied. (there are no
restrictions by default).
\iqdiscitem{In-Band Registration (\ns{jabber:iq:register})}
\end{verbatim}
\end{itemize}
-\subsection{\modroster{}}
+\subsection{\aname{modroster}{\modroster{}}}
\label{sec:modroster}
\ind{modules!\modroster{}}\ind{roster management}\ind{protocols!RFC 3921: XMPP IM}
\iqdiscitem{Roster Management (\ns{jabber:iq:roster})}
\end{description}
-\subsection{\modservicelog{}}
+\subsection{\aname{modservicelog}{\modservicelog{}}}
\label{sec:modservicelog}
\ind{modules!\modservicelog{}}\ind{message auditing}\ind{Bandersnatch}
\end{verbatim}
\end{itemize}
-\subsection{\modsharedroster{}}
+\subsection{\aname{modsharedroster}{\modsharedroster{}}}
\label{sec:modsharedroster}
\ind{modules!\modsharedroster{}}\ind{shared roster groups}
has a unique identification and the following parameters:
\begin{description}
\item[Name] The name of the group, which will be displayed in the roster.
-\item[Description] The description of the group. This parameter doesn't affect
+\item[Description] The description of the group. This parameter does not affect
anything.
\item[Members] A list of full JIDs of group members, entered one per line in
the web interface.
\end{table}
\end{itemize}
-\subsection{\modstats{}}
+\subsection{\aname{modstats}{\modstats{}}}
\label{sec:modstats}
\ind{modules!\modstats{}}\ind{protocols!JEP-0039: Statistics Gathering}\ind{statistics}
\end{verbatim}
\end{itemize}
-\subsection{\modtime{}}
+\subsection{\aname{modtime}{\modtime{}}}
\label{sec:modtime}
\ind{modules!\modtime{}}\ind{protocols!JEP-0090: Entity Time}
\iqdiscitem{Entity Time (\ns{jabber:iq:time})}
\end{description}
-\subsection{\modvcard{}}
+\subsection{\aname{modvcard}{\modvcard{}}}
\label{sec:modvcard}
\ind{modules!\modvcard{}}\ind{JUD}\ind{Jabber User Directory}\ind{vCard}\ind{protocols!JEP-0054: vcard-temp}
\begin{description}
\hostitem{vjud}
\iqdiscitem{\ns{vcard-temp}}
-\titem{search} \ind{options!search}This option specifies whether the search
- functionality is enabled (value: \term{true}) or disabled
- (value: \term{false}). If disabled, the option \term{hosts} will be
- ignored and the \Jabber{} User Directory service will not appear in the
- Service Discovery item list. The default value is \term{true}.
-\titem{matches} \ind{options!matches}With this option, the number of reported
+\titem{search}\ind{options!search}This option specifies whether the search
+ functionality is enabled (value: \term{true}) or disabled (value:
+ \term{false}). If disabled, the option \term{hosts} will be ignored and the
+ \Jabber{} User Directory service will not appear in the Service Discovery item
+ list. The default value is \term{true}.
+\titem{matches}\ind{options!matches}With this option, the number of reported
search results can be limited. If the option's value is set to \term{infinity},
all search results are reported. The default value is \term{30}.
-\titem{allow\_return\_all} \ind{options!allow\_return\_all}This option enables
- you to specify if search operations with empty input fields should return
- all users who added some information to their vCard. The default value is
+\titem{allow\_return\_all}\ind{options!allow\_return\_all}This option enables
+ you to specify if search operations with empty input fields should return all
+ users who added some information to their vCard. The default value is
\term{false}.
-\titem{search\_all\_hosts} \ind{options!search\_all\_hosts}If this option is
- set to \term{true}, search operations will apply to all virtual hosts.
- Otherwise only the current host will be searched. The default value is
- \term{true}.
+\titem{search\_all\_hosts}\ind{options!search\_all\_hosts}If this option is set
+ to \term{true}, search operations will apply to all virtual hosts. Otherwise
+ only the current host will be searched. The default value is \term{true}.
\end{description}
Examples:
\end{verbatim}
\end{itemize}
-\subsection{LDAP and \modvcardldap{}}
-\label{sec:ldap}
+\subsection{\aname{modvcardldap}{\modvcardldap{}}}
+\label{sec:modvcardldap}
\ind{modules!\modvcardldap{}}\ind{JUD}\ind{Jabber User Directory}\ind{vCard}\ind{protocols!JEP-0054: vcard-temp}
+%TODO: verify if the referers to the LDAP section are still correct
+
+\ejabberd{} can map LDAP attributes to vCard fields. This behaviour is
+implemented in the \modvcardldap{} module. This module does not depend on the
+authentication method (see~\ref{sec:ldapauth}). The \modvcardldap{} module
+has its own optional parameters. The first group of parameters has the same
+meaning as the top-level LDAP parameters to set the authentication method:
+\option{ldap\_servers}, \option{ldap\_port}, \option{ldap\_rootdn},
+\option{ldap\_password}, \option{ldap\_base}, \option{ldap\_uidattr},
+\option{ldap\_uidattr\_format} and \option{ldap\_filter}. See
+section~\ref{sec:ldapauth} for detailed information about these options. If one
+of these options is not set, \ejabberd{} will look for the top-level option with
+the same name. The second group of parameters consists of the following
+\modvcardldap{}-specific options:
+
+\begin{description}
+\hostitem{vjud}
+\iqdiscitem{\ns{vcard-temp}}
+\titem{search}\ind{options!search}This option specifies whether the search
+ functionality is enabled (value: \term{true}) or disabled (value:
+ \term{false}). If disabled, the option \term{hosts} will be ignored and the
+ \Jabber{} User Directory service will not appear in the Service Discovery item
+ list. The default value is \term{true}.
+\titem{ldap\_vcard\_map}\ind{options!ldap\_vcard\_map}With this option you can
+ set the table that maps LDAP attributes to vCard fields. The format is:
+ \term{[{Name\_of\_vCard\_field, Pattern, List\_of\_LDAP\_attributes}, ...]}.\ind{protocols!RFC 2426: vCard MIME Directory Profile}
+ \term{Name\_of\_vcard\_field} is the type name of the vCard as defined in
+ \footahref{http://www.ietf.org/rfc/rfc2426.txt}{RFC 2426}. \term{Pattern} is a
+ string which contains pattern variables \term{"\%u"}, \term{"\%d"} or
+ \term{"\%s"}. \term{List\_of\_LDAP\_attributes} is the list containing LDAP
+ attributes. The pattern variables \term{"\%s"} will be sequentially replaced
+ with the values of LDAP attributes from \term{List\_of\_LDAP\_attributes},
+ \term{"\%u"} will be replaced with the user part of a JID, and \term{"\%d"}
+ will be replaced with the domain part of a JID. The default is:
+ \begin{verbatim}
+ [{"NICKNAME", "%u", []},
+ {"FN", "%s", ["displayName"]},
+ {"FAMILY", "%s", ["sn"]},
+ {"GIVEN", "%s", ["givenName"]},
+ {"MIDDLE", "%s", ["initials"]},
+ {"ORGNAME", "%s", ["o"]},
+ {"ORGUNIT", "%s", ["ou"]},
+ {"CTRY", "%s", ["c"]},
+ {"LOCALITY", "%s", ["l"]},
+ {"STREET", "%s", ["street"]},
+ {"REGION", "%s", ["st"]},
+ {"PCODE", "%s", ["postalCode"]},
+ {"TITLE", "%s", ["title"]},
+ {"URL", "%s", ["labeleduri"]},
+ {"DESC", "%s", ["description"]},
+ {"TEL", "%s", ["telephoneNumber"]},
+ {"EMAIL", "%s", ["mail"]},
+ {"BDAY", "%s", ["birthDay"]},
+ {"ROLE", "%s", ["employeeType"]},
+ {"PHOTO", "%s", ["jpegPhoto"]}]
+\end{verbatim}
+\titem{ldap\_search\_fields}\ind{options!ldap\_search\_fields}This option
+ defines the search form and the LDAP attributes to search within. The format
+ is: \term{[{Name, Attribute}, ...]}. \term{Name} is the name of a search form
+ field which will be automatically translated by using the translation
+ files (see \term{msgs/*.msg} for available words). \term{Attribute} is the
+ LDAP attribute or the pattern \term{"\%u"}. The default is:
+ \begin{verbatim}
+ [{"User", "%u"},
+ {"Full Name", "displayName"},
+ {"Given Name", "givenName"},
+ {"Middle Name", "initials"},
+ {"Family Name", "sn"},
+ {"Nickname", "%u"},
+ {"Birthday", "birthDay"},
+ {"Country", "c"},
+ {"City", "l"},
+ {"Email", "mail"},
+ {"Organization Name", "o"},
+ {"Organization Unit", "ou"}]
+\end{verbatim}
+\titem{ldap\_search\_reported}\ind{options!ldap\_search\_reported}This option
+ defines which search fields should be reported. The format is:
+ \term{[{Name, vCard\_Name}, ...]}. \term{Name} is the name of a search form
+ field which will be automatically translated by using the translation
+ files (see \term{msgs/*.msg} for available words). \term{vCard\_Name} is the
+ vCard field name defined in the \option{ldap\_vcard\_map} option. The default
+ is:
+\begin{verbatim}
+ [{"Full Name", "FN"},
+ {"Given Name", "GIVEN"},
+ {"Middle Name", "MIDDLE"},
+ {"Family Name", "FAMILY"},
+ {"Nickname", "NICKNAME"},
+ {"Birthday", "BDAY"},
+ {"Country", "CTRY"},
+ {"City", "LOCALITY"},
+ {"Email", "EMAIL"},
+ {"Organization Name", "ORGNAME"},
+ {"Organization Unit", "ORGUNIT"}]
+\end{verbatim}
+\end{description}
+
+%TODO: this examples still should be organised better
+Examples:
+\begin{itemize}
+\item
-\subsubsection{Features}
-\label{sec:ldapfeatures}
+Let's say \term{ldap.example.org} is the name of our LDAP server. We have
+users with their passwords in \term{"ou=Users,dc=example,dc=org"} directory.
+Also we have addressbook, which contains users emails and their additional
+infos in \term{"ou=AddressBook,dc=example,dc=org"} directory. Corresponding
+authentication section should looks like this:
-\ejabberd{} has built-in LDAP support. You can authenticate users against LDAP
-server and use LDAP directory as vCard storage. Shared rosters are not
-supported yet.
+\begin{verbatim}
+ %% authentication method
+ {auth_method, ldap}.
+ %% DNS name of our LDAP server
+ {ldap_servers, ["ldap.example.org"]}.
+ %% We want to authorize users from 'shadowAccount' object class only
+ {ldap_filter, "(objectClass=shadowAccount)"}.
+\end{verbatim}
+Now we want to use users LDAP-info as their vCards. We have four attributes
+defined in our LDAP schema: \term{"mail"} --- email address, \term{"givenName"}
+--- first name, \term{"sn"} --- second name, \term{"birthDay"} --- birthday.
+Also we want users to search each other. Let's see how we can set it up:
-\subsubsection{Connection}
-\label{sec:ldapconnection}
+\begin{verbatim}
+ {modules,
+ ...
+ {mod_vcard_ldap,
+ [
+ %% We use the same server and port, but want to bind anonymously because
+ %% our LDAP server accepts anonymous requests to
+ %% "ou=AddressBook,dc=example,dc=org" subtree.
+ {ldap_rootdn, ""},
+ {ldap_password, ""},
+ %% define the addressbook's base
+ {ldap_base, "ou=AddressBook,dc=example,dc=org"},
+ %% user's part of JID is located in the "mail" attribute
+ {ldap_uidattr, "mail"},
+ %% common format for our emails
+ {ldap_uidattr_format, "%u@mail.example.org"},
+ %% We have to define empty filter here, because entries in addressbook does not
+ %% belong to shadowAccount object class
+ {ldap_filter, ""},
+ %% Now we want to define vCard pattern
+ {ldap_vcard_map,
+ [{"NICKNAME", "%u", []}, % just use user's part of JID as his nickname
+ {"GIVEN", "%s", ["givenName"]},
+ {"FAMILY", "%s", ["sn"]},
+ {"FN", "%s, %s", ["sn", "givenName"]}, % example: "Smith, John"
+ {"EMAIL", "%s", ["mail"]},
+ {"BDAY", "%s", ["birthDay"]}]},
+ %% Search form
+ {ldap_search_fields,
+ [{"User", "%u"},
+ {"Name", "givenName"},
+ {"Family Name", "sn"},
+ {"Email", "mail"},
+ {"Birthday", "birthDay"}]},
+ %% vCard fields to be reported
+ %% Note that JID is always returned with search results
+ {ldap_search_reported,
+ [{"Full Name", "FN"},
+ {"Nickname", "NICKNAME"},
+ {"Birthday", "BDAY"}]}
+ ]}
+ ...
+ }.
+\end{verbatim}
-Parameters:
+Note that \modvcardldap{} module checks an existence of the user before
+searching his info in LDAP.
+\item \term{ldap\_vcard\_map} example:
+\begin{verbatim}
+ {ldap_vcard_map,
+ [{"NICKNAME", "%u", []},
+ {"FN", "%s", ["displayName"]},
+ {"CTRY", "Russia", []},
+ {"EMAIL", "%u@%d", []},
+ {"DESC", "%s\n%s", ["title", "description"]}
+ ]},
+\end{verbatim}
+\item \term{ldap\_search\_fields} example:
+\begin{verbatim}
+ {ldap_search_fields,
+ [{"User", "uid"},
+ {"Full Name", "displayName"},
+ {"Email", "mail"}
+ ]},
+\end{verbatim}
+\item \term{ldap\_search\_reported} example:
+\begin{verbatim}
+ {ldap_search_reported,
+ [{"Full Name", "FN"},
+ {"Email", "EMAIL"},
+ {"Birthday", "BDAY"},
+ {"Nickname", "NICKNAME"}
+ ]},
+\end{verbatim}
+\end{itemize}
+
+\subsection{\aname{modversion}{\modversion{}}}
+\label{sec:modversion}
+\ind{modules!\modversion{}}\ind{protocols!JEP-0092: Software Version}
+
+This module implements Software Version (\jepref{0092}). Consequently, it
+answers \ejabberd{}'s version when queried.
+
+Options:
\begin{description}
-\titem{ldap\_server} \ind{options!ldap\_server}IP address or dns name of your
-LDAP server. This option is required.
-\titem{ldap\_port} \ind{options!ldap\_port}Port to connect to LDAP server.
-Default is~389.
-\titem{ldap\_rootdn} \ind{options!ldap\_rootdn}Bind DN. Default is~\term{""}
-which means anonymous connection.
-\titem{ldap\_password} \ind{options!ldap\_password}Bind password. Default
-is~\term{""}.
+\iqdiscitem{Software Version (\ns{jabber:iq:version})}
\end{description}
-Example:
+
+\section{\aname{initialadmin}{Creating an Initial Administrator}}
+\label{sec:initialadmin}
+
+Before the web interface can be entered to perform administration tasks, an
+account with administrator rights is needed on your \ejabberd{} deployment.
+
+Instructions to create an initial administrator account:
+\begin{enumerate}
+\item Register an account on your \ejabberd{} deployment. An account can be
+ created in two ways:
+ \begin{enumerate}
+ \item Using the tool \term{ejabberdctl}\ind{ejabberdctl} (see
+ section~\ref{sec:ejabberdctl}):
+ \begin{verbatim}
+% ejabberdctl node@host register admin example.org password
+\end{verbatim}
+ \item Using In-Band Registration (see section~\ref{sec:modregister}): you can
+ use a \Jabber{} client to register an account.
+ \end{enumerate}
+\item Edit the configuration file to promote the account created in the previous
+ step to an account with administrator rights. Note that if you want to add
+ more administrators, a seperate acl entry is needed for each administrator.
+ \begin{verbatim}
+ {acl, admins, {user, "admin", "example.org"}}.
+ {access, configure, [{allow, admins}]}.
+\end{verbatim}
+\item Restart \ejabberd{} to load the new configuration.
+\item Open the web interface (\verb|http://server:port/admin/|) in your
+ favourite browser. Make sure to enter the \emph{full} JID as username (in this
+ example: \jid{admin@example.org}. The reason that you also need to enter the
+ suffix, is because \ejabberd{}'s virtual hosting support.
+\end{enumerate}
+
+
+\section{\aname{onlineconfig}{Online Configuration and Monitoring}}
+\label{sec:onlineconfig}
+
+\subsection{\aname{webinterface}{Web Interface}}
+\label{sec:webinterface}
+\ind{web interface}
+
+To perform online configuration of \ejabberd{} you need to enable the
+\term{ejabberd\_http} listener with the option \term{web\_admin} (see
+section~\ref{sec:listened}). Then you can open
+\verb|http://server:port/admin/| in your favourite web browser. You
+will be asked to enter the username (the \emph{full} \Jabber{} ID) and password
+of an \ejabberd{} user with administrator rights. After authentication
+you will see a page similar to figure~\ref{fig:webadmmain}.
+
+\begin{figure}[htbp]
+ \centering
+ \insimg{webadmmain.png}
+ \caption{Top page from the web interface}
+ \label{fig:webadmmain}
+\end{figure}
+Here you can edit access restrictions, manage users, create backups,
+manage the database, enable/disable ports listened for, view server
+statistics,\ldots
+
+Examples:
+\begin{itemize}
+\item You can serve the web interface on the same port as the
+ \ind{protocols!JEP-0025: HTTP Polling}HTTP Polling interface. In this example
+ you should point your web browser to \verb|http://example.org:5280/admin/| to
+ administer all virtual hosts or to
+ \verb|http://example.org:5280/admin/server/example.com/| to administer only
+ the virtual host \jid{example.com}. Before you get access to the web interface
+ you need to enter as username, the JID and password from a registered user
+ that is allowed to configure \ejabberd{}. In this example you can enter as
+ username `\jid{admin@example.net}' to administer all virtual hosts (first
+ URL). If you log in with `\jid{admin@example.com}' on \\
+ \verb|http://example.org:5280/admin/server/example.com/| you can only
+ administer the virtual host \jid{example.com}.
+ \begin{verbatim}
+ ...
+ {acl, admins, {user, "admin", "example.net"}}.
+ {host_config, "example.com", [{acl, admins, {user, "admin", "example.com"}}]}.
+ {access, configure, [{allow, admins}]}.
+ ...
+ {hosts, ["example.org"]}.
+ ...
+ {listen,
+ [...
+ {5280, ejabberd_http, [http_poll, web_admin]},
+ ...
+ ]
+ }.
+\end{verbatim}
+\item For security reasons, you can serve the web interface on a secured
+ connection, on a port differing from the HTTP Polling interface, and bind it
+ to the internal LAN IP. The web interface will be accessible by pointing your
+ web browser to \verb|https://192.168.1.1:5280/admin/|:
+ \begin{verbatim}
+ ...
+ {hosts, ["example.org"]}.
+ ...
+ {listen,
+ [...
+ {5270, ejabberd_http, [http_poll]},
+ {5280, ejabberd_http, [web_admin, {ip, {192, 168, 1, 1}},
+ tls, {certfile, "/usr/local/etc/server.pem"}]},
+ ...
+ ]
+ }.
+\end{verbatim}
+\end{itemize}
+
+\subsection{\aname{ejabberdctl}{\term{ejabberdctl}}}
+\label{sec:ejabberdctl}
+%TODO: update when the ejabberdctl script is made more userfriendly
+
+It is possible to do some administration operations using the command
+line tool \term{ejabberdctl}. You can list all available options by
+running \term{ejabberdctl} without arguments:
\begin{verbatim}
- {auth_method, ldap}.
- {ldap_servers, ["ldap.mydomain.org"]}.
- {ldap_port, 389}.
- {ldap_rootdn, "cn=Manager,dc=domain,dc=org"}.
- {ldap_password, "secret"}.
+% ejabberdctl
+Usage: ejabberdctl node command
+
+Available commands:
+ status get ejabberd status
+ stop stop ejabberd
+ restart restart ejabberd
+ reopen-log reopen log file
+ register user server password register a user
+ unregister user server unregister a user
+ backup file store a database backup to file
+ restore file restore a database backup from file
+ install-fallback file install a database fallback from file
+ dump file dump a database to a text file
+ load file restore a database from a text file
+ import-file file import user data from jabberd 1.4 spool file
+ import-dir dir import user data from jabberd 1.4 spool directory
+ registered-users list all registered users
+ delete-expired-messages delete expired offline messages from database
+
+Example:
+ ejabberdctl ejabberd@host restart
\end{verbatim}
-Note that current LDAP implementation doesn't support SSL connection and SASL
-authentication.
+Additional information:
+\begin{description}
+\titem{reopen-log } If you use a tool to rotate logs, you have to configure it
+ so that this command is executed after each rotation.
+\titem {backup, restore, install-fallback, dump, load} You can use these
+ commands to create and restore backups.
+%%More information about backuping can
+%% be found in section~\ref{sec: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://ejabberd.jabber.ru/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}
+
+
+\section{\aname{firewall}{Firewall Settings}}
+\label{sec:firewall}
+\ind{firewall}\ind{ports}\ind{SASL}\ind{TLS}\ind{clustering!ports}
+
+You need to take the following TCP ports in mind when configuring your firewall:
+\begin{table}[H]
+ \centering
+ \begin{tabular}{|l|l|}
+ \hline Port& Description\\
+ \hline \hline 5222& SASL and unencrypted c2s connections.\\
+ \hline 5223& Obsolete SSL c2s connections.\\
+ \hline 5269& s2s connections.\\
+ \hline 4369& Only for clustering (see~\ref{sec:clustering}).\\
+ \hline port range& Only for clustring (see~\ref{sec:clustering}). This range
+ is configurable (see~\ref{sec:start}).\\
+ \hline
+ \end{tabular}
+\end{table}
+
+
+\section{\aname{srv}{SRV Records}}
+\label{sec:srv}
+\ind{SRV Records}\ind{clustering!SRV Records}
+
+\begin{itemize}
+\item General information:
+ \footahref{http://en.wikipedia.org/wiki/SRV\_record}{SRV record}
+\item Practical information:
+ \footahref{http://jabberd.jabberstudio.org/2/docs/section05.html\#5\_7}{Setting DNS SRV Records}
+\end{itemize}
+
+
+\section{\aname{clustering}{Clustering}}
+\label{sec:clustering}
+\ind{clustering}
+
+\subsection{\aname{howitworks}{How it Works}}
+\label{sec:howitworks}
+\ind{clustering!how it works}
+
+A \Jabber{} domain is served by one or more \ejabberd{} 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
+have the same magic cookie (see Erlang/OTP documentation, in other words the
+file \term{\~{}ejabberd/.erlang.cookie} must be the same on all nodes). This is
+needed because all nodes exchange information about connected users, s2s
+connections, registered services, etc\ldots
+
+Each \ejabberd{} node has the following modules:
+\begin{itemize}
+\item router,
+\item local router,
+\item session manager,
+\item s2s manager.
+\end{itemize}
+
+\subsubsection{\aname{router}{Router}}
+\label{sec:router}
+\ind{clustering!router}
+
+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.
+
+\subsubsection{\aname{localrouter}{Local Router}}
+\label{sec:localrouter}
+\ind{clustering!local router}
+
+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.
+\subsubsection{\aname{sessionmanager}{Session Manager}}
+\label{sec:sessionmanager}
+\ind{clustering!session manager}
-\subsubsection{Authentication}
-\label{sec:ldapauthentication}
+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.
-You can authenticate users against LDAP directory. Available parameters are
-listed below:
+\subsubsection{\aname{s2smanager}{s2s Manager}}
+\label{sec:s2smanager}
+\ind{clustering!s2s manager}
-\begin{description}
-\titem{ldap\_base} \ind{options!ldap\_base}LDAP base directory which stores users
-accounts. This option is required.
-\titem{ldap\_uidattr} \ind{options!ldap\_uidattr}LDAP attribute which holds
-user's part of JID. Default is \term{"uid"}.
-\titem{ldap\_uidattr\_format} \ind{options!ldap\_uidattr\_format}Format of the
-\term{ldap\_uidattr} variable. Format MUST contain one and only one pattern
-variable \term{"\%u"} which will be replaced by user's part of JID. For example,
-\term{"\%u@mydomain.org"}. Default value is \term{"\%u"}.
-\titem{ldap\_filter} \ind{options!ldap\_filter}RFC 2254 LDAP filter. Default is
-\term{none}. Example: \term{"(\&(objectClass=shadowAccount)(memberOf=Jabber
- Users))"}. Please, don't forget closing brackets and don't use superfluous
-whitespaces. Also you MUST NOT use \option{ldap\_uidattr} attribute in filter
-because this attribute will be substituted in LDAP filter automatically.
-\end{description}
+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.
+\subsection{\aname{cluster}{Clustering Setup}}
+\label{sec:cluster}
+\ind{clustering!setup}
-\subsubsection{vCards and Search}
-\label{sec:modvcardldap}
+Suppose you already configured \ejabberd{} on one machine named (\term{first}),
+and you need to setup another one to make an \ejabberd{} cluster. Then do
+following steps:
-\ejabberd{} can map LDAP attributes to vCard fields. This behaviour is
-implemented in \modvcardldap{} module. This module doesn't depend on
-authentication method. \modvcardldap{} module has it's own optional
-parameters. The first group of parameters has the same meaning as top-level
-LDAP parameters: \option{ldap\_servers}, \option{ldap\_port},
-\option{ldap\_rootdn}, \option{ldap\_password}, \option{ldap\_base},
-\option{ldap\_uidattr}, \option{ldap\_uidattr\_format} and
-\option{ldap\_filter}. If one of this option is not set \ejabberd{} will look
-for top-level option with the same name. The second group of parameters
-consists of the following options:
+\begin{enumerate}
+\item Copy \verb|~ejabberd/.erlang.cookie| file from \term{first} to
+ \term{second}.
-\begin{description}
-\hostitem{vjud}
-\iqdiscitem{\ns{vcard-temp}}
-\titem{search} \ind{options!search}This option specifies whether the search
- functionality is enabled (value: \term{true}) or disabled
- (value: \term{false}). If disabled, the option \term{hosts} will be
- ignored and the \Jabber{} User Directory service will not appear in the
- Service Discovery item list. The default value is \term{true}.
-\titem{ldap\_vcard\_map} \ind{options!ldap\_vcard\_map}the table which defines
-reflection of LDAP attributes to vCard fields.
- Format is:
- \term{[{Name\_of\_vcard\_field, Pattern, List\_of\_LDAP\_attributes}, ...]}
- where
- \term{Name\_of\_vcard\_field} is the type name of vCard as defined
- in RFC 2426,
- Pattern is a string which contains pattern variables \term{"\%u"}, \term{"\%d"} or \term{"\%s"},
- \term{List\_of\_LDAP\_attributes} is the list which contains of LDAP attributes.
- Pattern variables \term{"\%s"} will be sequentially replaced with the values of
- LDAP attributes from \term{List\_of\_LDAP\_attributes}; \term{"\%u"} will be replaced with
- user's part of JID and \term{"\%d"} will be replaced with domain part of JID.
- Example:
-\begin{verbatim}
- {ldap_vcard_map,
- [{"NICKNAME", "%u", []},
- {"FN", "%s", ["displayName"]},
- {"CTRY", "Russia", []},
- {"EMAIL", "%u@%d", []},
- {"DESC", "%s\n%s", ["title", "description"]}
- ]},
-\end{verbatim}
+ (alt) You can also add `\verb|-cookie content_of_.erlang.cookie|'
+ option to all `\shell{erl}' commands below.
-Default is:
-\begin{verbatim}
- [{"NICKNAME", "%u", []},
- {"FN", "%s", ["displayName"]},
- {"FAMILY", "%s", ["sn"]},
- {"GIVEN", "%s", ["givenName"]},
- {"MIDDLE", "%s", ["initials"]},
- {"ORGNAME", "%s", ["o"]},
- {"ORGUNIT", "%s", ["ou"]},
- {"CTRY", "%s", ["c"]},
- {"LOCALITY", "%s", ["l"]},
- {"STREET", "%s", ["street"]},
- {"REGION", "%s", ["st"]},
- {"PCODE", "%s", ["postalCode"]},
- {"TITLE", "%s", ["title"]},
- {"URL", "%s", ["labeleduri"]},
- {"DESC", "%s", ["description"]},
- {"TEL", "%s", ["telephoneNumber"]},
- {"EMAIL", "%s", ["mail"]},
- {"BDAY", "%s", ["birthDay"]},
- {"ROLE", "%s", ["employeeType"]},
- {"PHOTO", "%s", ["jpegPhoto"]}]
-\end{verbatim}
-\titem{ldap\_search\_fields} \ind{options!ldap\_search\_fields}This option defines
-search form and LDAP attributes to search.
- Format:
- \term{[{Name, Attribute}, ...]}
- where
- \term{Name} is the name of field in the search form. Will be automatically
- translated according to definitions in translation files (see
- \term{msgs/*.msg} for available words).
- Attribute is the LDAP attribute or the pattern \term{"\%u"}
- Example:
-\begin{verbatim}
- {ldap_search_fields,
- [{"User", "uid"},
- {"Full Name", "displayName"},
- {"Email", "mail"}
- ]},
-\end{verbatim}
+\item On \term{second} run the following command as the \ejabberd{} daemon user,
+ in the working directory of \ejabberd{}:
-Default is:
-\begin{verbatim}
- [{"User", "%u"},
- {"Full Name", "displayName"},
- {"Given Name", "givenName"},
- {"Middle Name", "initials"},
- {"Family Name", "sn"},
- {"Nickname", "%u"},
- {"Birthday", "birthDay"},
- {"Country", "c"},
- {"City", "l"},
- {"Email", "mail"},
- {"Organization Name", "o"},
- {"Organization Unit", "ou"}]
-\end{verbatim}
-\titem{ldap\_search\_reported} \ind{options!ldap\_search\_reported}This option defines search fields to be reported.
- Format:
- \term{[{Name, VCard\_Name}, ...]}
- where
- \term{Name} is the name of field in the search form. Will be automatically
- translated according to definitions in translation files (see
- \term{msgs/*.msg} for available words).
- \term{VCard\_Name} is the name of vCard field defined in \option{ldap\_vcard\_map} option.
- Example:
\begin{verbatim}
- {ldap_search_reported,
- [{"Full Name", "FN"},
- {"Email", "EMAIL"},
- {"Birthday", "BDAY"},
- {"Nickname", "NICKNAME"}
- ]},
+erl -sname ejabberd \
+ -mnesia extra_db_nodes "['ejabberd@first']" \
+ -s mnesia
\end{verbatim}
-Default is:
+ This will start Mnesia serving the same database as \node{ejabberd@first}.
+ You can check this by running the command `\verb|mnesia:info().|'. You
+ should see a lot of remote tables and a line like the following:
+
\begin{verbatim}
- [{"Full Name", "FN"},
- {"Given Name", "GIVEN"},
- {"Middle Name", "MIDDLE"},
- {"Family Name", "FAMILY"},
- {"Nickname", "NICKNAME"},
- {"Birthday", "BDAY"},
- {"Country", "CTRY"},
- {"City", "LOCALITY"},
- {"Email", "EMAIL"},
- {"Organization Name", "ORGNAME"},
- {"Organization Unit", "ORGUNIT"}]
+running db nodes = [ejabberd@first, ejabberd@second]
\end{verbatim}
-\end{description}
-
-\subsubsection{Examples}
-\label{sec:ldapexamples}
-
-\paragraph{Common example}
-Let's say \term{ldap.mydomain.org} is the name of our LDAP server. We have
-users with their passwords in \term{"ou=Users,dc=mydomain,dc=org"} directory.
-Also we have addressbook, which contains users emails and their additional
-infos in \term{"ou=AddressBook,dc=mydomain,dc=org"} directory. Corresponding
-authentication section should looks like this:
+\item Now run the following in the same `\shell{erl}' session:
\begin{verbatim}
- %% authentication method
- {auth_method, ldap}.
- %% DNS name of our LDAP server
- {ldap_servers, ["ldap.mydomain.org"]}.
- %% Bind to LDAP server as "cn=Manager,dc=mydomain,dc=org" with password "secret"
- {ldap_rootdn, "cn=Manager,dc=mydomain,dc=org"}.
- {ldap_password, "secret"}.
- %% define the user's base
- {ldap_base, "ou=Users,dc=mydomain,dc=org"}.
- %% We want to authorize users from 'shadowAccount' object class only
- {ldap_filter, "(objectClass=shadowAccount)"}.
+mnesia:change_table_copy_type(schema, node(), disc_copies).
\end{verbatim}
-Now we want to use users LDAP-info as their vCards. We have four attributes
-defined in our LDAP schema: \term{"mail"} --- email address, \term{"givenName"}
---- first name, \term{"sn"} --- second name, \term{"birthDay"} --- birthday.
-Also we want users to search each other. Let's see how we can set it up:
+ This will create local disc storage for the database.
-\begin{verbatim}
- {modules,
- ...
- {mod_vcard_ldap,
- [
- %% We use the same server and port, but want to bind anonymously because
- %% our LDAP server accepts anonymous requests to
- %% "ou=AddressBook,dc=mydomain,dc=org" subtree.
- {ldap_rootdn, ""},
- {ldap_password, ""},
- %% define the addressbook's base
- {ldap_base, "ou=AddressBook,dc=mydomain,dc=org"},
- %% user's part of JID is located in the "mail" attribute
- {ldap_uidattr, "mail"},
- %% common format for our emails
- {ldap_uidattr_format, "%u@mail.mydomain.org"},
- %% We have to define empty filter here, because entries in addressbook doesn't
- %% belong to shadowAccount object class
- {ldap_filter, ""},
- %% Now we want to define vCard pattern
- {ldap_vcard_map,
- [{"NICKNAME", "%u", []}, % just use user's part of JID as his nickname
- {"GIVEN", "%s", ["givenName"]},
- {"FAMILY", "%s", ["sn"]},
- {"FN", "%s, %s", ["sn", "givenName"]}, % example: "Smith, John"
- {"EMAIL", "%s", ["mail"]},
- {"BDAY", "%s", ["birthDay"]}]},
- %% Search form
- {ldap_search_fields,
- [{"User", "%u"},
- {"Name", "givenName"},
- {"Family Name", "sn"},
- {"Email", "mail"},
- {"Birthday", "birthDay"}]},
- %% vCard fields to be reported
- %% Note that JID is always returned with search results
- {ldap_search_reported,
- [{"Full Name", "FN"},
- {"Nickname", "NICKNAME"},
- {"Birthday", "BDAY"}]}
- ]}
- ...
- }.
-\end{verbatim}
+ (alt) Change storage type of the \term{scheme} table to `RAM and disc
+ copy' on the second node via the web interface.
-Note that \modvcardldap{} module checks an existence of the user before
-searching his info in LDAP.
+\item Now you can add replicas of various tables to this node with
+ `\verb|mnesia:add_table_copy|' or
+ `\verb|mnesia:change_table_copy_type|' as above (just replace
+ `\verb|schema|' with another table name and `\verb|disc_copies|'
+ can be replaced with `\verb|ram_copies|' or
+ `\verb|disc_only_copies|').
-\paragraph{Active Directory}
+ Which tables to replicate is very dependant on your needs, you can get
+ some hints from the command `\verb|mnesia:info().|', by looking at the
+ size of tables and the default storage type for each table on 'first'.
-Active Directory is just an LDAP-server with predefined attributes. Sample
-config file is listed below:
+ Replicating a table makes lookups in this table faster on this node.
+ Writing, on the other hand, will be slower. And of course if machine with one
+ of the replicas is down, other replicas will be used.
-\begin{verbatim}
- {auth_method, ldap}.
- {ldap_servers, ["office.org"]}. % List of LDAP servers
- {ldap_base, "DC=office,DC=org"}. % Search base of LDAP directory
- {ldap_rootdn, "CN=Administrator,CN=Users,DC=office,DC=org"}. % LDAP manager
- {ldap_password, "*******"}. % Password to LDAP manager
- {ldap_uidattr, "sAMAccountName"}.
- {ldap_filter, "(memberOf=*)"}.
-
- {mod_vcard_ldap,
- [{ldap_vcard_map,
- [{"NICKNAME", "%u", []},
- {"GIVEN", "%s", ["givenName"]},
- {"MIDDLE", "%s", ["initials"]},
- {"FAMILY", "%s", ["sn"]},
- {"FN", "%s", ["displayName"]},
- {"EMAIL", "%s", ["mail"]},
- {"ORGNAME", "%s", ["company"]},
- {"ORGUNIT", "%s", ["department"]},
- {"CTRY", "%s", ["c"]},
- {"LOCALITY", "%s", ["l"]},
- {"STREET", "%s", ["streetAddress"]},
- {"REGION", "%s", ["st"]},
- {"PCODE", "%s", ["postalCode"]},
- {"TITLE", "%s", ["title"]},
- {"URL", "%s", ["wWWHomePage"]},
- {"DESC", "%s", ["description"]},
- {"TEL", "%s", ["telephoneNumber"]}]},
- {ldap_search_fields,
- [{"User", "%u"},
- {"Name", "givenName"},
- {"Family Name", "sn"},
- {"Email", "mail"},
- {"Company", "company"},
- {"Department", "department"},
- {"Role", "title"},
- {"Description", "description"},
- {"Phone", "telephoneNumber"}]},
- {ldap_search_reported,
- [{"Full Name", "FN"},
- {"Nickname", "NICKNAME"},
- {"Email", "EMAIL"}]}
- ]
- }.
-\end{verbatim}
+ Also \footahref{http://www.erlang.se/doc/doc-5.4.9/lib/mnesia-4.2.2/doc/html/Mnesia\_chap5.html\#5.3}
+ {section 5.3 (Table Fragmentation) of Mnesia User's Guide} can be helpful.
+ % The above URL needs update every Erlang release!
+ (alt) Same as in previous item, but for other tables.
-\subsection{\modversion{}}
-\label{sec:modversion}
-\ind{modules!\modversion{}}\ind{protocols!JEP-0092: Software Version}
-This module implements Software Version (\jepref{0092}). Consequently, it
-answers \ejabberd{}'s version when queried.
+\item Run `\verb|init:stop().|' or just `\verb|q().|' to exit from
+ the Erlang shell. This probably can take some time if Mnesia has not yet
+ transfered and processed all data it needed from \term{first}.
-Options:
-\begin{description}
-\iqdiscitem{Software Version (\ns{jabber:iq:version})}
-\end{description}
+\item Now run \ejabberd{} on \term{second} with almost the same config as
+ on \term{first} (you probably do not need to duplicate `\verb|acl|'
+ and `\verb|access|' options --- they will be taken from
+ \term{first}, and \verb|mod_muc| and \verb|mod_irc| should be
+ enabled only on one machine in the cluster).
+\end{enumerate}
+
+You can repeat these steps for other machines supposed to serve this
+domain.
+
+% TODO
+% See also the section about ejabberdctl!!!!
+%\section{Backup and Restore}
+%\label{sec:backup}
+%\ind{backup}
-\section{Internationalization and Localization}
+\appendix{}
+\section{\aname{i18nl10n}{Internationalization and Localization}}
\label{sec:i18nl10n}
\ind{xml:lang}\ind{internationalization}\ind{localization}\ind{i18n}\ind{l10n}
\centering
\insimg{webadmmainru.png}
\caption{Top page from the web interface with HTTP header
- ``Accept-Language: ru''}
+ `Accept-Language: ru'}
\label{fig:webadmmainru}
\end{figure}
+
+%\section{\aname{ultracomplexexample}{Ultra Complex Example}}
+%\label{sec:ultracomplexexample}
+%TODO: a very big example covering the whole guide, with a good explanation before the example: different authenticaton mechanisms, transports, ACLs, multple virtual hosts, virtual host specific settings and general settings, modules,...
+
\newpage
-\section{Release Notes}
+\section{\aname{releasenotes}{Release Notes}}
\label{sec:releasenotes}
\ind{release notes}
\subsection{ejabberd 1.1.1}
\verbatiminput{release_notes_1.1.1.txt}
-\section{Acknowledgements}
+
+\section{\aname{acknowledgements}{Acknowledgements}}
\label{sec:acknowledgements}
-\ind{acknowledgements}
Thanks to all people who contributed to this guide:
\begin{itemize}
\item Alexey Shchepin (\ahrefurl{xmpp:aleksey@jabber.ru})
+\item Badlop (\ahrefurl{xmpp:badlop@jabberes.org})
+\item Evgeniy Khramtsov (\ahrefurl{xmpp:xram@jabber.ru})
\item Florian Zumbiehl (\ahrefurl{xmpp:florz@florz.de})
\item Michael Grigutsch (\ahrefurl{xmpp:migri@jabber.i-pobox.net})
\item Mickael Remond (\ahrefurl{xmpp:mremond@erlang-projects.org})
\item Vsevolod Pelipas (\ahrefurl{xmpp:vsevoload@jabber.ru})
\end{itemize}
-% TODO
-%\section{Glossary}
+
+\section{\aname{copyright}{Copyright Information}}
+\label{sec:copyright}
+
+Ejabberd Installation and Operation Guide.\\
+Copyright \copyright{} January 23, 2003 --- \today{} Alexey Shchepin
+
+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
+of the License, or (at your option) any later version.
+
+This document is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License along with
+this document; if not, write to the Free Software Foundation, Inc., 51 Franklin
+Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+%TODO: a glossary describing common terms
+%\section{\aname{glossary}{Glossary}}
%\label{sec:glossary}
%\ind{glossary}
%\titem{Regular Expression}
%\titem{ACL} (Access Control List) <Wikipedia>
%\titem{IPv6} <Wikipedia>
-%\titem{XDB} ???
+%\titem{Jabber}
%\titem{LDAP} (Lightweight Directory Access Protocol) <Wikipedia>
%\titem{ODBC} (Open Database Connectivity) <Wikipedia>
%\titem{Virtual Hosting} <Wikipedia>
-%\titem{}
-%\titem{}
%\end{description}
projects / ejabberd / commitdiff