mirror of
https://github.com/processone/ejabberd.git
synced 2024-12-24 17:29:28 +01:00
Replace several mentions of Jabber to XMPP (thanks to Nicolas Vérité)
SVN Revision: 2613
This commit is contained in:
parent
4936c2dc58
commit
3c3cd099de
@ -146,7 +146,7 @@ Support for virtual hosting.
|
||||
</LI></UL>
|
||||
</LI></UL><!--TOC section How it Works-->
|
||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc3">3</A>  How it Works</H2><!--SEC END --><P>
|
||||
<A NAME="howitworks"></A></P><P>A Jabber domain is served by one or more <TT>ejabberd</TT> nodes. These nodes can
|
||||
<A NAME="howitworks"></A></P><P>A XMPP 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
|
||||
@ -159,7 +159,7 @@ router;
|
||||
</LI><LI CLASS="li-itemize">session manager;
|
||||
</LI><LI CLASS="li-itemize">S2S manager;
|
||||
</LI></UL><!--TOC subsection Router-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc4">3.1</A>  Router</H3><!--SEC END --><P>This module is the main router of Jabber packets on each node. It routes
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc4">3.1</A>  Router</H3><!--SEC END --><P>This module is the main router of XMPP packets on each node. It routes
|
||||
them based on their destinations domains. It has two tables: local and global
|
||||
routes. First, domain of packet destination searched in local table, and if it
|
||||
found, then the packet is routed to appropriate process. If no, then it
|
||||
@ -173,7 +173,7 @@ session manager, else it is processed depending on it’s content.</P><!--T
|
||||
packet must be sended via presence table. If this resource is connected to
|
||||
this node, it is routed to C2S process, if it connected via another node, then
|
||||
the packet is sent to session manager on that node.</P><!--TOC subsection S2S Manager-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc7">3.4</A>  S2S Manager</H3><!--SEC END --><P>This module routes packets to other Jabber servers. First, it checks if an
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc7">3.4</A>  S2S Manager</H3><!--SEC END --><P>This module routes packets to other XMPP servers. First, it checks if an
|
||||
open S2S connection from the domain of the packet source to the domain of
|
||||
packet destination already exists. If it is open on another node, then it
|
||||
routes the packet to S2S manager on that node, if it is open on this node, then
|
||||
|
@ -26,6 +26,7 @@
|
||||
\newcommand{\ns}[1]{\texttt{#1}}
|
||||
\newcommand{\ejabberd}{\texttt{ejabberd}}
|
||||
\newcommand{\Jabber}{Jabber}
|
||||
\newcommand{\XMPP}{XMPP}
|
||||
|
||||
%% Modules
|
||||
\newcommand{\module}[1]{\texttt{#1}}
|
||||
@ -100,7 +101,7 @@
|
||||
\label{howitworks}
|
||||
|
||||
|
||||
A \Jabber{} domain is served by one or more \ejabberd{} nodes. These nodes can
|
||||
A \XMPP{} 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
|
||||
@ -121,7 +122,7 @@ Each \ejabberd{} node have following modules:
|
||||
|
||||
\subsection{Router}
|
||||
|
||||
This module is the main router of \Jabber{} packets on each node. It routes
|
||||
This module is the main router of \XMPP{} packets on each node. It routes
|
||||
them based on their destinations domains. It has two tables: local and global
|
||||
routes. First, domain of packet destination searched in local table, and if it
|
||||
found, then the packet is routed to appropriate process. If no, then it
|
||||
@ -147,7 +148,7 @@ the packet is sent to session manager on that node.
|
||||
|
||||
\subsection{S2S Manager}
|
||||
|
||||
This module routes packets to other \Jabber{} servers. First, it checks if an
|
||||
This module routes packets to other \XMPP{} servers. First, it checks if an
|
||||
open S2S connection from the domain of the packet source to the domain of
|
||||
packet destination already exists. If it is open on another node, then it
|
||||
routes the packet to S2S manager on that node, if it is open on this node, then
|
||||
|
@ -70,7 +70,7 @@
|
||||
%% Fancy header
|
||||
\fancyhf{}
|
||||
\pagestyle{fancy}
|
||||
\rhead{\textcolor{ejblue}{The Expandable Jabber Daemon.}}
|
||||
\rhead{\textcolor{ejblue}{The Expandable Jabber/XMPP Daemon.}}
|
||||
\renewcommand{\headrule}{{\color{ejblue}%
|
||||
\hrule width\headwidth height\headrulewidth \vskip-\headrulewidth}}
|
||||
\lhead{\setlength{\unitlength}{-6mm}
|
||||
@ -133,4 +133,4 @@
|
||||
% "What I find interesting is that *no* XMPP servers truly provide clustering. This includes all the commercial
|
||||
% servers. The one partial exception appears to be ejabberd, which can cluster certain data such as sessions,
|
||||
% but not all services such as MUC."
|
||||
% * try it today: links to migration tutorials
|
||||
% * try it today: links to migration tutorials
|
||||
|
@ -109,7 +109,7 @@ BLOCKQUOTE.figure DIV.center DIV.center HR{display:none;}
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc15">2.4.7  Specific Notes for Sun Solaris</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc16">2.4.8  Specific Notes for Microsoft Windows</A>
|
||||
</LI></UL>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc17">2.5  Create a Jabber Account for Administration</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc17">2.5  Create a XMPP Account for Administration</A>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc18">2.6  Upgrading <TT>ejabberd</TT></A>
|
||||
</LI></UL>
|
||||
</LI><LI CLASS="li-toc"><A HREF="#htoc19">Chapter 3  Configuring <TT>ejabberd</TT></A>
|
||||
@ -385,7 +385,7 @@ To get the full list run the command:
|
||||
See section <A HREF="#database">3.2</A> for more information.<P> </P></DD><DT CLASS="dt-description"><B><TT>--enable-full-xml</TT></B></DT><DD CLASS="dd-description">
|
||||
Enable the use of XML based optimisations.
|
||||
It will for example use CDATA to escape characters in the XMPP stream.
|
||||
Use this option only if you are sure your Jabber clients include a fully compliant XML parser.<P> </P></DD><DT CLASS="dt-description"><B><TT>--disable-transient-supervisors</TT></B></DT><DD CLASS="dd-description">
|
||||
Use this option only if you are sure your XMPP clients include a fully compliant XML parser.<P> </P></DD><DT CLASS="dt-description"><B><TT>--disable-transient-supervisors</TT></B></DT><DD CLASS="dd-description">
|
||||
Disable the use of Erlang/OTP supervision for transient processes.
|
||||
</DD></DL><P> <A NAME="install"></A> </P><!--TOC subsection Install-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc12">2.4.4</A>  <A HREF="#install">Install</A></H3><!--SEC END --><P> <A NAME="install"></A>
|
||||
@ -503,22 +503,22 @@ variable.
|
||||
nmake -f Makefile.win32
|
||||
</PRE></LI><LI CLASS="li-enumerate">Edit the file <CODE>ejabberd\src\ejabberd.cfg</CODE> and run
|
||||
<PRE CLASS="verbatim">werl -s ejabberd -name ejabberd
|
||||
</PRE></LI></OL><P> <A NAME="initialadmin"></A> </P><!--TOC section Create a Jabber Account for Administration-->
|
||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc17">2.5</A>  <A HREF="#initialadmin">Create a Jabber Account for Administration</A></H2><!--SEC END --><P> <A NAME="initialadmin"></A> </P><P>You need a Jabber account and grant him administrative privileges
|
||||
</PRE></LI></OL><P> <A NAME="initialadmin"></A> </P><!--TOC section Create a XMPP Account for Administration-->
|
||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc17">2.5</A>  <A HREF="#initialadmin">Create a XMPP Account for Administration</A></H2><!--SEC END --><P> <A NAME="initialadmin"></A> </P><P>You need a XMPP account and grant him administrative privileges
|
||||
to enter the <TT>ejabberd</TT> Web Admin:
|
||||
</P><OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
|
||||
Register a Jabber account on your <TT>ejabberd</TT> server, for example <TT>admin1@example.org</TT>.
|
||||
There are two ways to register a Jabber account:
|
||||
Register a XMPP account on your <TT>ejabberd</TT> server, for example <TT>admin1@example.org</TT>.
|
||||
There are two ways to register a XMPP account:
|
||||
<OL CLASS="enumerate" type=a><LI CLASS="li-enumerate">
|
||||
Using <TT>ejabberdctl</TT> (see section <A HREF="#ejabberdctl">4.1</A>):
|
||||
<PRE CLASS="verbatim">ejabberdctl register admin1 example.org FgT5bk3
|
||||
</PRE></LI><LI CLASS="li-enumerate">Using a Jabber client and In-Band Registration (see section <A HREF="#modregister">3.3.18</A>).
|
||||
</PRE></LI><LI CLASS="li-enumerate">Using a XMPP client and In-Band Registration (see section <A HREF="#modregister">3.3.18</A>).
|
||||
</LI></OL>
|
||||
</LI><LI CLASS="li-enumerate">Edit the <TT>ejabberd</TT> configuration file to give administration rights to the Jabber account you created:
|
||||
</LI><LI CLASS="li-enumerate">Edit the <TT>ejabberd</TT> configuration file to give administration rights to the XMPP account you created:
|
||||
<PRE CLASS="verbatim">{acl, admins, {user, "admin1", "example.org"}}.
|
||||
{access, configure, [{allow, admins}]}.
|
||||
</PRE>You can grant administrative privileges to many Jabber accounts,
|
||||
and also to accounts in other Jabber servers.
|
||||
</PRE>You can grant administrative privileges to many XMPP accounts,
|
||||
and also to accounts in other XMPP servers.
|
||||
</LI><LI CLASS="li-enumerate">Restart <TT>ejabberd</TT> to load the new configuration.
|
||||
</LI><LI CLASS="li-enumerate">Open the Web Admin (<CODE>http://server:port/admin/</CODE>) in your
|
||||
favourite browser. Make sure to enter the <EM>full</EM> JID as username (in this
|
||||
@ -715,8 +715,8 @@ This option enables HTTP Binding (<A HREF="http://xmpp.org/extensions/xep-0124.h
|
||||
enables access via HTTP requests to <TT>ejabberd</TT> from behind firewalls which
|
||||
do not allow outgoing sockets on port 5222.<P>Remember that you must also install and enable the module mod_http_bind.</P><P>If HTTP Bind is enabled, it will be available at
|
||||
<CODE>http://server:port/http-bind/</CODE>. Be aware that support for HTTP Bind
|
||||
is also needed in the Jabber client. Remark also that HTTP Bind can be
|
||||
interesting to host a web-based Jabber client such as
|
||||
is also needed in the XMPP client. Remark also that HTTP Bind can be
|
||||
interesting to host a web-based XMPP client such as
|
||||
<A HREF="http://jwchat.sourceforge.net/">JWChat</A>
|
||||
(check the tutorials to install JWChat with ejabberd and an
|
||||
<A HREF="http://www.ejabberd.im/jwchat-localserver">embedded local web server</A>
|
||||
@ -726,8 +726,8 @@ This option enables HTTP Polling (<A HREF="http://xmpp.org/extensions/xep-0025.h
|
||||
enables access via HTTP requests to <TT>ejabberd</TT> from behind firewalls which
|
||||
do not allow outgoing sockets on port 5222.<P>If HTTP Polling is enabled, it will be available at
|
||||
<CODE>http://server:port/http-poll/</CODE>. Be aware that support for HTTP Polling
|
||||
is also needed in the Jabber client. Remark also that HTTP Polling can be
|
||||
interesting to host a web-based Jabber client such as
|
||||
is also needed in the XMPP client. Remark also that HTTP Polling can be
|
||||
interesting to host a web-based XMPP client such as
|
||||
<A HREF="http://jwchat.sourceforge.net/">JWChat</A>.</P><P>The maximum period of time to keep a client session active without
|
||||
an incoming POST request can be configured with the global option
|
||||
<TT>http_poll_timeout</TT>. The default value is five minutes.
|
||||
@ -798,7 +798,7 @@ Define properties to use for DNS resolving.
|
||||
Allowed Properties are: <TT>timeout</TT> in seconds which default value is <TT>10</TT>
|
||||
and <TT>retries</TT> which default value is <TT>2</TT>.
|
||||
</DD><DT CLASS="dt-description"><B><TT>{s2s_default_policy, allow|deny}</TT></B></DT><DD CLASS="dd-description">
|
||||
The default policy for incoming and outgoing s2s connections to other Jabber servers.
|
||||
The default policy for incoming and outgoing s2s connections to other XMPP servers.
|
||||
The default value is <TT>allow</TT>.
|
||||
</DD><DT CLASS="dt-description"><B><TT>{{s2s_host, Host}, allow|deny}</TT></B></DT><DD CLASS="dd-description">
|
||||
Defines if incoming and outgoing s2s connections with a specific remote host are allowed or denied.
|
||||
@ -859,7 +859,7 @@ on port 5223 (SSL, IP 192.168.0.1 and fdca:8ab6:a243:75ef::1) and denied
|
||||
for the user called ‘<TT>bad</TT>’.
|
||||
</LI><LI CLASS="li-itemize">s2s connections are listened for on port 5269 (all IPv4 addresses)
|
||||
with STARTTLS for secured traffic enabled.
|
||||
Incoming and outgoing connections of remote Jabber servers are denied,
|
||||
Incoming and outgoing connections of remote XMPP servers are denied,
|
||||
only two servers can connect: "jabber.example.org" and "example.com".
|
||||
</LI><LI CLASS="li-itemize">Port 5280 is serving the Web Admin and the HTTP Polling service
|
||||
in all the IPv4 addresses. Note
|
||||
@ -957,7 +957,7 @@ you have to make the transports log and do XDB by themselves:
|
||||
</log>
|
||||
|
||||
<!--
|
||||
Some Jabber server implementations do not provide
|
||||
Some XMPP server implementations do not provide
|
||||
XDB services (for example, jabberd2 and ejabberd).
|
||||
xdb_file.so is loaded in to handle all XDB requests.
|
||||
-->
|
||||
@ -1170,10 +1170,10 @@ can be either a number, or <TT>infinity</TT>. The default value is
|
||||
<TT>infinity</TT>.</P><P>The syntax is:
|
||||
</P><DL CLASS="description"><DT CLASS="dt-description"><B><TT>{access, max_user_sessions, [ {MaxNumber, ACLName}, ...]}.</TT></B></DT></DL><P>This example limits the number of sessions per user to 5 for all users, and to 10 for admins:
|
||||
</P><PRE CLASS="verbatim">{access, max_user_sessions, [{10, admin}, {5, all}]}.
|
||||
</PRE><P> <A NAME="configmaxs2sconns"></A> </P><!--TOC subsubsection Several connections to a remote Jabber server with ACL-->
|
||||
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A HREF="#configmaxs2sconns">Several connections to a remote Jabber server with ACL</A></H4><!--SEC END --><P> <A NAME="configmaxs2sconns"></A>
|
||||
</PRE><P> <A NAME="configmaxs2sconns"></A> </P><!--TOC subsubsection Several connections to a remote XMPP server with ACL-->
|
||||
<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A HREF="#configmaxs2sconns">Several connections to a remote XMPP server with ACL</A></H4><!--SEC END --><P> <A NAME="configmaxs2sconns"></A>
|
||||
</P><P>The special access <TT>max_s2s_connections</TT> specifies how many
|
||||
simultaneus S2S connections can be established to a specific remote Jabber server.
|
||||
simultaneus S2S connections can be established to a specific remote XMPP server.
|
||||
The default value is <TT>1</TT>.
|
||||
There’s also available the access <TT>max_s2s_connections_per_node</TT>.</P><P>The syntax is:
|
||||
</P><DL CLASS="description"><DT CLASS="dt-description"><B><TT>{access, max_s2s_connections, [ {MaxNumber, ACLName}, ...]}.</TT></B></DT></DL><P>Examples:
|
||||
@ -1202,7 +1202,7 @@ To define a shaper named ‘<TT>normal</TT>’ with traffic speed limi
|
||||
</PRE></LI></UL><P> <A NAME="language"></A> </P><!--TOC subsection Default Language-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc27">3.1.7</A>  <A HREF="#language">Default Language</A></H3><!--SEC END --><P> <A NAME="language"></A>
|
||||
</P><P>The option <TT>language</TT> defines the default language of server strings that
|
||||
can be seen by Jabber clients. If a Jabber client does not support
|
||||
can be seen by XMPP clients. If a XMPP client does not support
|
||||
<TT>xml:lang</TT>, the specified language is used.</P><P>The option syntax is:
|
||||
</P><DL CLASS="description"><DT CLASS="dt-description"><B><TT>{language, Language}.</TT></B></DT></DL><P>The default value is <TT>en</TT>.
|
||||
In order to take effect there must be a translation file
|
||||
@ -1794,7 +1794,7 @@ all entries end with a comma:
|
||||
<TR><TD ALIGN=left NOWRAP><TT>mod_caps</TT></TD><TD ALIGN=left NOWRAP>Entity Capabilities (<A HREF="http://xmpp.org/extensions/xep-0115.html">XEP-0115</A>)</TD><TD ALIGN=left NOWRAP> </TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><TT>mod_configure</TT></TD><TD ALIGN=left NOWRAP>Server configuration using Ad-Hoc</TD><TD ALIGN=left NOWRAP><TT>mod_adhoc</TT></TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#moddisco"><TT>mod_disco</TT></A></TD><TD ALIGN=left NOWRAP>Service Discovery (<A HREF="http://xmpp.org/extensions/xep-0030.html">XEP-0030</A>)</TD><TD ALIGN=left NOWRAP> </TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#modecho"><TT>mod_echo</TT></A></TD><TD ALIGN=left NOWRAP>Echoes Jabber packets</TD><TD ALIGN=left NOWRAP> </TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#modecho"><TT>mod_echo</TT></A></TD><TD ALIGN=left NOWRAP>Echoes XMPP stanzas</TD><TD ALIGN=left NOWRAP> </TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#modirc"><TT>mod_irc</TT></A></TD><TD ALIGN=left NOWRAP>IRC transport</TD><TD ALIGN=left NOWRAP> </TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#modlast"><TT>mod_last</TT></A></TD><TD ALIGN=left NOWRAP>Last Activity (<A HREF="http://xmpp.org/extensions/xep-0012.html">XEP-0012</A>)</TD><TD ALIGN=left NOWRAP> </TD></TR>
|
||||
<TR><TD ALIGN=left NOWRAP><A HREF="#modlast"><TT>mod_last_odbc</TT></A></TD><TD ALIGN=left NOWRAP>Last Activity (<A HREF="http://xmpp.org/extensions/xep-0012.html">XEP-0012</A>)</TD><TD ALIGN=left NOWRAP>supported DB (*)</TD></TR>
|
||||
@ -1908,7 +1908,7 @@ the "@HOST@" keyword must be used:
|
||||
</P><P>This module enables configured users to broadcast announcements and to set
|
||||
the message of the day (MOTD).
|
||||
Configured users can perform these actions with a
|
||||
Jabber client either using Ad-hoc commands
|
||||
XMPP client either using Ad-hoc commands
|
||||
or sending messages to specific JIDs.</P><P>The Ad-hoc commands are listed in the Server Discovery.
|
||||
For this feature to work, <TT>mod_adhoc</TT> must be enabled.</P><P>The specific JIDs where messages can be sent are listed bellow.
|
||||
The first JID in each entry will apply only to the specified virtual host
|
||||
@ -1975,9 +1975,9 @@ disabled for instances of <TT>ejabberd</TT> with hundreds of thousands users.</P
|
||||
|
||||
</P><P>This module adds support for Service Discovery (<A HREF="http://xmpp.org/extensions/xep-0030.html">XEP-0030</A>). With
|
||||
this module enabled, services on your server can be discovered by
|
||||
Jabber clients. Note that <TT>ejabberd</TT> has no modules with support
|
||||
XMPP clients. Note that <TT>ejabberd</TT> has no modules with support
|
||||
for the superseded Jabber Browsing (<A HREF="http://xmpp.org/extensions/xep-0011.html">XEP-0011</A>) and Agent Information
|
||||
(<A HREF="http://xmpp.org/extensions/xep-0094.html">XEP-0094</A>). Accordingly, Jabber clients need to have support for
|
||||
(<A HREF="http://xmpp.org/extensions/xep-0094.html">XEP-0094</A>). Accordingly, XMPP clients need to have support for
|
||||
the newer Service Discovery protocol if you want them be able to discover
|
||||
the services you offer.</P><P>Options:
|
||||
</P><DL CLASS="description"><DT CLASS="dt-description">
|
||||
@ -2043,9 +2043,9 @@ and admin addresses for both the main server and the vJUD service:
|
||||
]}.
|
||||
</PRE></LI></UL><P> <A NAME="modecho"></A> </P><!--TOC subsection <TT>mod_echo</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc43">3.3.5</A>  <A HREF="#modecho"><TT>mod_echo</TT></A></H3><!--SEC END --><P> <A NAME="modecho"></A>
|
||||
</P><P>This module simply echoes any Jabber
|
||||
</P><P>This module simply echoes any XMPP
|
||||
packet back to the sender. This mirror can be of interest for
|
||||
<TT>ejabberd</TT> and Jabber client debugging.</P><P>Options:
|
||||
<TT>ejabberd</TT> and XMPP client debugging.</P><P>Options:
|
||||
</P><DL CLASS="description"><DT CLASS="dt-description">
|
||||
|
||||
<B><TT>{host, HostName}</TT></B></DT><DD CLASS="dd-description"> This option defines the Jabber ID of the
|
||||
@ -2088,7 +2088,7 @@ resource at which this service will be hosted.</P><P>To use HTTP-Binding, enable
|
||||
</PRE><P>With this configuration, the module will serve the requests sent to
|
||||
<CODE>http://example.org:5280/http-bind/</CODE>
|
||||
Remember that this page is not designed to be used by web browsers,
|
||||
it is used by Jabber clients that support XMPP over Bosh.</P><P>If you want to set the service in a different URI path or use a different module,
|
||||
it is used by XMPP clients that support XMPP over Bosh.</P><P>If you want to set the service in a different URI path or use a different module,
|
||||
you can configure it manually using the option <CODE>request_handlers</CODE>.
|
||||
For example:
|
||||
</P><PRE CLASS="verbatim">{listen,
|
||||
@ -2180,10 +2180,10 @@ To use this module you must enable it:
|
||||
servers.</P><P>End user information:
|
||||
|
||||
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
|
||||
A Jabber client with ‘groupchat 1.0’ support or Multi-User
|
||||
A XMPP client with ‘groupchat 1.0’ support or Multi-User
|
||||
Chat support (<A HREF="http://xmpp.org/extensions/xep-0045.html">XEP-0045</A>) is necessary to join IRC channels.
|
||||
</LI><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
|
||||
XMPP 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
|
||||
to the IRC transport instead of the Multi-User Chat service.
|
||||
@ -2193,7 +2193,7 @@ to the IRC transport instead of the Multi-User Chat service.
|
||||
to <TT>nickserver!irc.example.org@irc.jabberserver.org</TT>.
|
||||
</LI><LI CLASS="li-itemize">The IRC transport provides Ad-Hoc Commands (<A HREF="http://xmpp.org/extensions/xep-0050.html">XEP-0050</A>)
|
||||
to join a channel, and to set custom IRC username and encoding.
|
||||
</LI><LI CLASS="li-itemize">When using a popular Jabber server, it can occur that no
|
||||
</LI><LI CLASS="li-itemize">When using a popular XMPP server, it can occur that no
|
||||
connection can be achieved with some IRC servers because they limit the
|
||||
number of conections from one IP.
|
||||
</LI></UL><P>Options:
|
||||
@ -2258,7 +2258,7 @@ Sending public and private messages to room occupants.
|
||||
</LI></UL><P>The MUC service allows any Jabber ID to register a nickname,
|
||||
so nobody else can use that nickname in any room in the MUC service.
|
||||
To register a nickname, open the Service Discovery in your
|
||||
Jabber client and register in the MUC service.</P><P>This module supports clustering and load
|
||||
XMPP client and register in the MUC service.</P><P>This module supports clustering and load
|
||||
balancing. One module can be started per cluster node. Rooms are
|
||||
distributed at creation time on all available MUC module
|
||||
instances. The multi-user chat module is clustered but the rooms
|
||||
@ -2349,7 +2349,7 @@ discarded. A good value for this option is 4 seconds.
|
||||
</DD><DT CLASS="dt-description"><B><TT>{default_room_options, [ {OptionName, OptionValue}, ...]}</TT></B></DT><DD CLASS="dd-description">
|
||||
This module option allows to define the desired default room options.
|
||||
Note that the creator of a room can modify the options of his room
|
||||
at any time using a Jabber client with MUC capability.
|
||||
at any time using a XMPP client with MUC capability.
|
||||
The available room options and the default values are:
|
||||
<DL CLASS="description"><DT CLASS="dt-description">
|
||||
<B><TT>{allow_change_subj, true|false}</TT></B></DT><DD CLASS="dd-description"> Allow occupants to change the subject.
|
||||
@ -2386,7 +2386,7 @@ In the first example everyone is allowed to use the Multi-User Chat
|
||||
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 XMPP 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>,
|
||||
it will be displayed in all active rooms. In this example the history
|
||||
@ -2471,7 +2471,7 @@ the newly created rooms have by default those options.
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc49">3.3.11</A>  <A HREF="#modmuclog"><TT>mod_muc_log</TT></A></H3><!--SEC END --><P> <A NAME="modmuclog"></A>
|
||||
</P><P>This module enables optional logging of Multi-User Chat (MUC) public conversations to
|
||||
HTML. Once you enable this module, users can join a room using a MUC capable
|
||||
Jabber client, and if they have enough privileges, they can request the
|
||||
XMPP client, and if they have enough privileges, they can request the
|
||||
configuration form in which they can set the option to enable room logging.</P><P>Features:
|
||||
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
|
||||
Room details are added on top of each page: room title, JID,
|
||||
@ -2650,7 +2650,7 @@ and if a client does not answer to the ping in less than 32 seconds, its connect
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc52">3.3.14</A>  <A HREF="#modprivacy"><TT>mod_privacy</TT></A></H3><!--SEC END --><P> <A NAME="modprivacy"></A>
|
||||
</P><P>This module implements Blocking Communication (also known as Privacy Rules)
|
||||
as defined in section 10 from XMPP IM. If end users have support for it in
|
||||
their Jabber client, they will be able to:
|
||||
their XMPP client, they will be able to:
|
||||
</P><BLOCKQUOTE CLASS="quote">
|
||||
<UL CLASS="itemize"><LI CLASS="li-itemize">
|
||||
Retrieving one’s privacy lists.
|
||||
@ -2678,7 +2678,7 @@ the processing discipline for Blocking Communication (<TT>jabber:iq:privacy</TT>
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc53">3.3.15</A>  <A HREF="#modprivate"><TT>mod_private</TT></A></H3><!--SEC END --><P> <A NAME="modprivate"></A>
|
||||
</P><P>This module adds support for Private XML Storage (<A HREF="http://xmpp.org/extensions/xep-0049.html">XEP-0049</A>):
|
||||
</P><BLOCKQUOTE CLASS="quote">
|
||||
Using this method, Jabber entities can store private data on the server and
|
||||
Using this method, XMPP entities can store private data on the server and
|
||||
retrieve it whenever necessary. The data stored might be anything, as long as
|
||||
it is valid XML. One typical usage for this namespace is the server-side storage
|
||||
of client-specific preferences; another is Bookmark Storage (<A HREF="http://xmpp.org/extensions/xep-0048.html">XEP-0048</A>).
|
||||
@ -2818,7 +2818,7 @@ with ODBC usage:
|
||||
</PRE><P> <A NAME="modregister"></A> </P><!--TOC subsection <TT>mod_register</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc56">3.3.18</A>  <A HREF="#modregister"><TT>mod_register</TT></A></H3><!--SEC END --><P> <A NAME="modregister"></A>
|
||||
</P><P>This module adds support for In-Band Registration (<A HREF="http://xmpp.org/extensions/xep-0077.html">XEP-0077</A>). This protocol
|
||||
enables end users to use a Jabber client to:
|
||||
enables end users to use a XMPP client to:
|
||||
</P><UL CLASS="itemize"><LI CLASS="li-itemize">
|
||||
Register a new account on the server.
|
||||
</LI><LI CLASS="li-itemize">Change the password from an existing account on the server.
|
||||
@ -2922,7 +2922,7 @@ Important: if you use <TT>mod_shared_roster</TT>, you must disable this option.
|
||||
]}.
|
||||
</PRE><P> <A NAME="modservicelog"></A> </P><!--TOC subsection <TT>mod_service_log</TT>-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc58">3.3.20</A>  <A HREF="#modservicelog"><TT>mod_service_log</TT></A></H3><!--SEC END --><P> <A NAME="modservicelog"></A>
|
||||
</P><P>This module adds support for logging end user packets via a Jabber message
|
||||
</P><P>This module adds support for logging end user packets via a XMPP message
|
||||
auditing service such as
|
||||
<A HREF="http://www.funkypenguin.info/project/bandersnatch/">Bandersnatch</A>. All user
|
||||
packets are encapsulated in a <CODE><route/></CODE> element and sent to the specified
|
||||
@ -2957,7 +2957,7 @@ create groups of people that can see members from (other) groups in their
|
||||
rosters. The big advantages of this feature are that end users do not need to
|
||||
manually add all users to their rosters, and that they cannot permanently delete
|
||||
users from the shared roster groups.
|
||||
A shared roster group can have members from any Jabber server,
|
||||
A shared roster group can have members from any XMPP server,
|
||||
but the presence will only be available from and to members
|
||||
of the same virtual host where the group is created.</P><P>Shared roster groups can be edited <EM>only</EM> via the Web Admin. Each group
|
||||
has a unique identification and the following parameters:
|
||||
@ -3507,7 +3507,7 @@ ArgumentValue = any()
|
||||
</PRE><P>The default value is to not define any restriction: <TT>[]</TT>.
|
||||
If at least one restriction is defined, then the frontend expects
|
||||
that authentication information is provided when executing a command.
|
||||
The authentication information is Username, Hostname and Password of a local Jabber account
|
||||
The authentication information is Username, Hostname and Password of a local XMPP account
|
||||
that has permission to execute the corresponding command.
|
||||
This means that the account must be registered in the local ejabberd,
|
||||
because the information will be verified.
|
||||
@ -3613,9 +3613,9 @@ the environment variable <TT>EJABBERD_DOC_PATH</TT>.
|
||||
See section <A HREF="#erlangconfiguration">4.1.2</A>.</P><P> <A NAME="adhoccommands"></A> </P><!--TOC section Ad-hoc Commands-->
|
||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc73">4.4</A>  <A HREF="#adhoccommands">Ad-hoc Commands</A></H2><!--SEC END --><P> <A NAME="adhoccommands"></A> </P><P>If you enable <TT>mod_configure</TT> and <TT>mod_adhoc</TT>,
|
||||
you can perform several administrative tasks in <TT>ejabberd</TT>
|
||||
with a Jabber client.
|
||||
with a XMPP client.
|
||||
The client must support Ad-Hoc Commands (<A HREF="http://xmpp.org/extensions/xep-0050.html">XEP-0050</A>),
|
||||
and you must login in the Jabber server with
|
||||
and you must login in the XMPP server with
|
||||
an account with proper privileges.</P><P> <A NAME="changeerlangnodename"></A> </P><!--TOC section Change Computer Hostname-->
|
||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc74">4.5</A>  <A HREF="#changeerlangnodename">Change Computer Hostname</A></H2><!--SEC END --><P> <A NAME="changeerlangnodename"></A> </P><P><TT>ejabberd</TT> uses the distributed Mnesia database.
|
||||
Being distributed, Mnesia enforces consistency of its file,
|
||||
@ -3737,7 +3737,7 @@ See section <A HREF="#cookie">5.3</A>.
|
||||
<H1 CLASS="chapter"><!--SEC ANCHOR --><A NAME="htoc81">Chapter 6</A>  <A HREF="#clustering">Clustering</A></H1><!--SEC END --><P> <A NAME="clustering"></A>
|
||||
</P><P> <A NAME="howitworks"></A> </P><!--TOC section How it Works-->
|
||||
<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc82">6.1</A>  <A HREF="#howitworks">How it Works</A></H2><!--SEC END --><P> <A NAME="howitworks"></A>
|
||||
</P><P>A Jabber domain is served by one or more <TT>ejabberd</TT> nodes. These nodes can
|
||||
</P><P>A XMPP 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
|
||||
@ -3751,7 +3751,7 @@ router,
|
||||
</LI><LI CLASS="li-itemize">s2s manager.
|
||||
</LI></UL><P> <A NAME="router"></A> </P><!--TOC subsection Router-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc83">6.1.1</A>  <A HREF="#router">Router</A></H3><!--SEC END --><P> <A NAME="router"></A>
|
||||
</P><P>This module is the main router of Jabber packets on each node. It
|
||||
</P><P>This module is the main router of XMPP 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
|
||||
@ -3767,7 +3767,7 @@ resource a packet must be sent via a presence table. Then the packet is
|
||||
either routed to the appropriate c2s process, or stored in offline
|
||||
storage, or bounced back.</P><P> <A NAME="s2smanager"></A> </P><!--TOC subsection s2s Manager-->
|
||||
<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc86">6.1.4</A>  <A HREF="#s2smanager">s2s Manager</A></H3><!--SEC END --><P> <A NAME="s2smanager"></A>
|
||||
</P><P>This module routes packets to other Jabber servers. First, it
|
||||
</P><P>This module routes packets to other XMPP 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
|
||||
@ -3858,7 +3858,7 @@ There are some simple and safe examples in the article
|
||||
</P><P><TT>ejabberd</TT> includes a watchdog mechanism that may be useful to developers
|
||||
when troubleshooting a problem related to memory usage.
|
||||
If a process in the <TT>ejabberd</TT> server consumes more memory than the configured threshold,
|
||||
a message is sent to the Jabber accounts defined with the option
|
||||
a message is sent to the XMPP accounts defined with the option
|
||||
<TT>watchdog_admins</TT>
|
||||
in the <TT>ejabberd</TT> configuration file.</P><P>The syntax is:
|
||||
</P><DL CLASS="description"><DT CLASS="dt-description"><B><TT>{watchdog_admins, [JID, ...]}.</TT></B></DT></DL><P>The memory consumed is measured in <TT>words</TT>:
|
||||
|
101
doc/guide.tex
101
doc/guide.tex
@ -59,6 +59,7 @@
|
||||
\newcommand{\shell}[1]{\texttt{#1}}
|
||||
\newcommand{\ejabberd}{\texttt{ejabberd}}
|
||||
\newcommand{\Jabber}{Jabber}
|
||||
\newcommand{\XMPP}{XMPP}
|
||||
\newcommand{\esyntax}[1]{\begin{description}\titem{#1}\end{description}}
|
||||
|
||||
%% Modules
|
||||
@ -373,7 +374,7 @@ Some options that you may be interested in modifying:
|
||||
\titem{--enable-full-xml}
|
||||
Enable the use of XML based optimisations.
|
||||
It will for example use CDATA to escape characters in the XMPP stream.
|
||||
Use this option only if you are sure your Jabber clients include a fully compliant XML parser.
|
||||
Use this option only if you are sure your XMPP clients include a fully compliant XML parser.
|
||||
|
||||
\titem{--disable-transient-supervisors}
|
||||
Disable the use of Erlang/OTP supervision for transient processes.
|
||||
@ -555,27 +556,27 @@ werl -s ejabberd -name ejabberd
|
||||
%TODO: how to compile database support on windows?
|
||||
|
||||
|
||||
\makesection{initialadmin}{Create a Jabber Account for Administration}
|
||||
\makesection{initialadmin}{Create a XMPP Account for Administration}
|
||||
|
||||
You need a Jabber account and grant him administrative privileges
|
||||
You need a XMPP account and grant him administrative privileges
|
||||
to enter the \ejabberd{} Web Admin:
|
||||
\begin{enumerate}
|
||||
\item Register a Jabber account on your \ejabberd{} server, for example \term{admin1@example.org}.
|
||||
There are two ways to register a Jabber account:
|
||||
\item Register a XMPP account on your \ejabberd{} server, for example \term{admin1@example.org}.
|
||||
There are two ways to register a XMPP account:
|
||||
\begin{enumerate}
|
||||
\item Using \term{ejabberdctl}\ind{ejabberdctl} (see section~\ref{ejabberdctl}):
|
||||
\begin{verbatim}
|
||||
ejabberdctl register admin1 example.org FgT5bk3
|
||||
\end{verbatim}
|
||||
\item Using a Jabber client and In-Band Registration (see section~\ref{modregister}).
|
||||
\item Using a XMPP client and In-Band Registration (see section~\ref{modregister}).
|
||||
\end{enumerate}
|
||||
\item Edit the \ejabberd{} configuration file to give administration rights to the Jabber account you created:
|
||||
\item Edit the \ejabberd{} configuration file to give administration rights to the XMPP account you created:
|
||||
\begin{verbatim}
|
||||
{acl, admins, {user, "admin1", "example.org"}}.
|
||||
{access, configure, [{allow, admins}]}.
|
||||
\end{verbatim}
|
||||
You can grant administrative privileges to many Jabber accounts,
|
||||
and also to accounts in other Jabber servers.
|
||||
You can grant administrative privileges to many XMPP accounts,
|
||||
and also to accounts in other XMPP servers.
|
||||
\item Restart \ejabberd{} to load the new configuration.
|
||||
\item Open the Web Admin (\verb|http://server:port/admin/|) in your
|
||||
favourite browser. Make sure to enter the \emph{full} JID as username (in this
|
||||
@ -841,7 +842,7 @@ This is a detailed description of each option allowed by the listening modules:
|
||||
as seen in an example below.
|
||||
\titem{captcha} \ind{options!http-captcha}
|
||||
Simple web page that allows a user to fill a CAPTCHA challenge (see section \ref{captcha}).
|
||||
\titem{http\_bind} \ind{options!http\_bind}\ind{protocols!XEP-0206: HTTP Binding}\ind{JWChat}\ind{web-based Jabber client}
|
||||
\titem{http\_bind} \ind{options!http\_bind}\ind{protocols!XEP-0206: HTTP Binding}\ind{JWChat}\ind{web-based XMPP client}
|
||||
This option enables HTTP Binding (\xepref{0124} and \xepref{0206}) support. HTTP Bind
|
||||
enables access via HTTP requests to \ejabberd{} from behind firewalls which
|
||||
do not allow outgoing sockets on port 5222.
|
||||
@ -850,21 +851,21 @@ This is a detailed description of each option allowed by the listening modules:
|
||||
|
||||
If HTTP Bind is enabled, it will be available at
|
||||
\verb|http://server:port/http-bind/|. Be aware that support for HTTP Bind
|
||||
is also needed in the \Jabber{} client. Remark also that HTTP Bind can be
|
||||
interesting to host a web-based \Jabber{} client such as
|
||||
is also needed in the \XMPP{} client. Remark also that HTTP Bind can be
|
||||
interesting to host a web-based \XMPP{} client such as
|
||||
\footahref{http://jwchat.sourceforge.net/}{JWChat}
|
||||
(check the tutorials to install JWChat with ejabberd and an
|
||||
\footahref{http://www.ejabberd.im/jwchat-localserver}{embedded local web server}
|
||||
or \footahref{http://www.ejabberd.im/jwchat-apache}{Apache}).
|
||||
\titem{http\_poll} \ind{options!http\_poll}\ind{protocols!XEP-0025: HTTP Polling}\ind{JWChat}\ind{web-based Jabber client}
|
||||
\titem{http\_poll} \ind{options!http\_poll}\ind{protocols!XEP-0025: HTTP Polling}\ind{JWChat}\ind{web-based XMPP client}
|
||||
This option enables HTTP Polling (\xepref{0025}) support. HTTP Polling
|
||||
enables access via HTTP requests to \ejabberd{} from behind firewalls which
|
||||
do not allow outgoing sockets on port 5222.
|
||||
|
||||
If HTTP Polling is enabled, it will be available at
|
||||
\verb|http://server:port/http-poll/|. Be aware that support for HTTP Polling
|
||||
is also needed in the \Jabber{} client. Remark also that HTTP Polling can be
|
||||
interesting to host a web-based \Jabber{} client such as
|
||||
is also needed in the \XMPP{} client. Remark also that HTTP Polling can be
|
||||
interesting to host a web-based \XMPP{} client such as
|
||||
\footahref{http://jwchat.sourceforge.net/}{JWChat}.
|
||||
|
||||
The maximum period of time to keep a client session active without
|
||||
@ -941,7 +942,7 @@ There are some additional global options that can be specified in the ejabberd c
|
||||
Allowed Properties are: \term{timeout} in seconds which default value is \term{10}
|
||||
and \term{retries} which default value is \term{2}.
|
||||
\titem{\{s2s\_default\_policy, allow|deny\}}
|
||||
The default policy for incoming and outgoing s2s connections to other Jabber servers.
|
||||
The default policy for incoming and outgoing s2s connections to other XMPP servers.
|
||||
The default value is \term{allow}.
|
||||
\titem{\{\{s2s\_host, Host\}, allow|deny\}}
|
||||
Defines if incoming and outgoing s2s connections with a specific remote host are allowed or denied.
|
||||
@ -1009,7 +1010,7 @@ In this example, the following configuration defines that:
|
||||
for the user called `\term{bad}'.
|
||||
\item s2s connections are listened for on port 5269 (all IPv4 addresses)
|
||||
with STARTTLS for secured traffic enabled.
|
||||
Incoming and outgoing connections of remote Jabber servers are denied,
|
||||
Incoming and outgoing connections of remote XMPP servers are denied,
|
||||
only two servers can connect: "jabber.example.org" and "example.com".
|
||||
\item Port 5280 is serving the Web Admin and the HTTP Polling service
|
||||
in all the IPv4 addresses. Note
|
||||
@ -1111,7 +1112,7 @@ you have to make the transports log and do \ind{XDB}XDB by themselves:
|
||||
</log>
|
||||
|
||||
<!--
|
||||
Some Jabber server implementations do not provide
|
||||
Some XMPP server implementations do not provide
|
||||
XDB services (for example, jabberd2 and ejabberd).
|
||||
xdb_file.so is loaded in to handle all XDB requests.
|
||||
-->
|
||||
@ -1434,11 +1435,11 @@ This example limits the number of sessions per user to 5 for all users, and to 1
|
||||
{access, max_user_sessions, [{10, admin}, {5, all}]}.
|
||||
\end{verbatim}
|
||||
|
||||
\makesubsubsection{configmaxs2sconns}{Several connections to a remote Jabber server with ACL}
|
||||
\makesubsubsection{configmaxs2sconns}{Several connections to a remote XMPP server with ACL}
|
||||
\ind{options!max\_s2s\_connections}
|
||||
|
||||
The special access \term{max\_s2s\_connections} specifies how many
|
||||
simultaneus S2S connections can be established to a specific remote Jabber server.
|
||||
simultaneus S2S connections can be established to a specific remote XMPP server.
|
||||
The default value is \term{1}.
|
||||
There's also available the access \term{max\_s2s\_connections\_per\_node}.
|
||||
|
||||
@ -1485,7 +1486,7 @@ Examples:
|
||||
\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 does not support
|
||||
can be seen by \XMPP{} clients. If a \XMPP{} client does not support
|
||||
\option{xml:lang}, the specified language is used.
|
||||
|
||||
The option syntax is:
|
||||
@ -2389,7 +2390,7 @@ The following table lists all modules included in \ejabberd{}.
|
||||
\hline \modcaps{} & Entity Capabilities (\xepref{0115}) & \\
|
||||
\hline \modconfigure{} & Server configuration using Ad-Hoc & \modadhoc{} \\
|
||||
\hline \ahrefloc{moddisco}{\moddisco{}} & Service Discovery (\xepref{0030}) & \\
|
||||
\hline \ahrefloc{modecho}{\modecho{}} & Echoes Jabber packets & \\
|
||||
\hline \ahrefloc{modecho}{\modecho{}} & Echoes XMPP stanzas & \\
|
||||
\hline \ahrefloc{modirc}{\modirc{}} & IRC transport & \\
|
||||
\hline \ahrefloc{modlast}{\modlast{}} & Last Activity (\xepref{0012}) & \\
|
||||
\hline \ahrefloc{modlast}{\modlastodbc{}} & Last Activity (\xepref{0012}) & supported DB (*) \\
|
||||
@ -2544,7 +2545,7 @@ the "@HOST@" keyword must be used:
|
||||
This module enables configured users to broadcast announcements and to set
|
||||
the message of the day (MOTD).
|
||||
Configured users can perform these actions with a
|
||||
\Jabber{} client either using Ad-hoc commands
|
||||
\XMPP{} client either using Ad-hoc commands
|
||||
or sending messages to specific JIDs.
|
||||
|
||||
The Ad-hoc commands are listed in the Server Discovery.
|
||||
@ -2628,9 +2629,9 @@ disabled for instances of \ejabberd{} with hundreds of thousands users.
|
||||
|
||||
This module adds support for Service Discovery (\xepref{0030}). With
|
||||
this module enabled, services on your server can be discovered by
|
||||
\Jabber{} clients. Note that \ejabberd{} has no modules with support
|
||||
\XMPP{} clients. Note that \ejabberd{} has no modules with support
|
||||
for the superseded Jabber Browsing (\xepref{0011}) and Agent Information
|
||||
(\xepref{0094}). Accordingly, \Jabber{} clients need to have support for
|
||||
(\xepref{0094}). Accordingly, \XMPP{} clients need to have support for
|
||||
the newer Service Discovery protocol if you want them be able to discover
|
||||
the services you offer.
|
||||
|
||||
@ -2710,9 +2711,9 @@ and admin addresses for both the main server and the vJUD service:
|
||||
\makesubsection{modecho}{\modecho{}}
|
||||
\ind{modules!\modecho{}}\ind{debugging}
|
||||
|
||||
This module simply echoes any \Jabber{}
|
||||
This module simply echoes any \XMPP{}
|
||||
packet back to the sender. This mirror can be of interest for
|
||||
\ejabberd{} and \Jabber{} client debugging.
|
||||
\ejabberd{} and \XMPP{} client debugging.
|
||||
|
||||
Options:
|
||||
\begin{description}
|
||||
@ -2764,7 +2765,7 @@ and add \verb|http_bind| in the HTTP service. For example:
|
||||
With this configuration, the module will serve the requests sent to
|
||||
\verb|http://example.org:5280/http-bind/|
|
||||
Remember that this page is not designed to be used by web browsers,
|
||||
it is used by Jabber clients that support XMPP over Bosh.
|
||||
it is used by XMPP clients that support XMPP over Bosh.
|
||||
|
||||
If you want to set the service in a different URI path or use a different module,
|
||||
you can configure it manually using the option \verb|request_handlers|.
|
||||
@ -2884,10 +2885,10 @@ servers.
|
||||
End user information:
|
||||
\ind{protocols!groupchat 1.0}\ind{protocols!XEP-0045: Multi-User Chat}
|
||||
\begin{itemize}
|
||||
\item A \Jabber{} client with `groupchat 1.0' support or Multi-User
|
||||
\item A \XMPP{} client with `groupchat 1.0' support or Multi-User
|
||||
Chat support (\xepref{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
|
||||
\XMPP{} 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
|
||||
to the IRC transport instead of the Multi-User Chat service.
|
||||
@ -2897,7 +2898,7 @@ End user information:
|
||||
to \jid{nickserver!irc.example.org@irc.jabberserver.org}.
|
||||
\item The IRC transport provides Ad-Hoc Commands (\xepref{0050})
|
||||
to join a channel, and to set custom IRC username and encoding.
|
||||
\item When using a popular \Jabber{} server, it can occur that no
|
||||
\item When using a popular \XMPP{} server, it can occur that no
|
||||
connection can be achieved with some IRC servers because they limit the
|
||||
number of conections from one IP.
|
||||
\end{itemize}
|
||||
@ -2976,7 +2977,7 @@ Some of the features of Multi-User Chat:
|
||||
The MUC service allows any Jabber ID to register a nickname,
|
||||
so nobody else can use that nickname in any room in the MUC service.
|
||||
To register a nickname, open the Service Discovery in your
|
||||
Jabber client and register in the MUC service.
|
||||
XMPP client and register in the MUC service.
|
||||
|
||||
This module supports clustering and load
|
||||
balancing. One module can be started per cluster node. Rooms are
|
||||
@ -3066,7 +3067,7 @@ Module options:
|
||||
\titem{\{default\_room\_options, [ \{OptionName, OptionValue\}, ...]\}} \ind{options!default\_room\_options}
|
||||
This module option allows to define the desired default room options.
|
||||
Note that the creator of a room can modify the options of his room
|
||||
at any time using a Jabber client with MUC capability.
|
||||
at any time using a XMPP client with MUC capability.
|
||||
The available room options and the default values are:
|
||||
\begin{description}
|
||||
\titem{\{allow\_change\_subj, true|false\}} Allow occupants to change the subject.
|
||||
@ -3105,7 +3106,7 @@ 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 \XMPP{} 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},
|
||||
it will be displayed in all active rooms. In this example the history
|
||||
@ -3205,7 +3206,7 @@ defined, but some user restriction could be added as well:
|
||||
|
||||
This module enables optional logging of Multi-User Chat (MUC) public conversations to
|
||||
HTML. Once you enable this module, users can join a room using a MUC capable
|
||||
Jabber client, and if they have enough privileges, they can request the
|
||||
XMPP client, and if they have enough privileges, they can request the
|
||||
configuration form in which they can set the option to enable room logging.
|
||||
|
||||
Features:
|
||||
@ -3415,7 +3416,7 @@ and if a client does not answer to the ping in less than 32 seconds, its connect
|
||||
|
||||
This module implements Blocking Communication (also known as Privacy Rules)
|
||||
as defined in section 10 from XMPP IM. If end users have support for it in
|
||||
their \Jabber{} client, they will be able to:
|
||||
their \XMPP{} client, they will be able to:
|
||||
\begin{quote}
|
||||
\begin{itemize}
|
||||
\item Retrieving one's privacy lists.
|
||||
@ -3447,7 +3448,7 @@ Options:
|
||||
|
||||
This module adds support for Private XML Storage (\xepref{0049}):
|
||||
\begin{quote}
|
||||
Using this method, Jabber entities can store private data on the server and
|
||||
Using this method, XMPP entities can store private data on the server and
|
||||
retrieve it whenever necessary. The data stored might be anything, as long as
|
||||
it is valid XML. One typical usage for this namespace is the server-side storage
|
||||
of client-specific preferences; another is Bookmark Storage (\xepref{0048}).
|
||||
@ -3612,7 +3613,7 @@ with ODBC usage:
|
||||
\ind{modules!\modregister{}}\ind{protocols!XEP-0077: In-Band Registration}\ind{public registration}
|
||||
|
||||
This module adds support for In-Band Registration (\xepref{0077}). This protocol
|
||||
enables end users to use a \Jabber{} client to:
|
||||
enables end users to use a \XMPP{} client to:
|
||||
\begin{itemize}
|
||||
\item Register a new account on the server.
|
||||
\item Change the password from an existing account on the server.
|
||||
@ -3741,7 +3742,7 @@ This example configuration enables Roster Versioning with storage of current id:
|
||||
\makesubsection{modservicelog}{\modservicelog{}}
|
||||
\ind{modules!\modservicelog{}}\ind{message auditing}\ind{Bandersnatch}
|
||||
|
||||
This module adds support for logging end user packets via a \Jabber{} message
|
||||
This module adds support for logging end user packets via a \XMPP{} message
|
||||
auditing service such as
|
||||
\footahref{http://www.funkypenguin.info/project/bandersnatch/}{Bandersnatch}. All user
|
||||
packets are encapsulated in a \verb|<route/>| element and sent to the specified
|
||||
@ -3787,7 +3788,7 @@ create groups of people that can see members from (other) groups in their
|
||||
rosters. The big advantages of this feature are that end users do not need to
|
||||
manually add all users to their rosters, and that they cannot permanently delete
|
||||
users from the shared roster groups.
|
||||
A shared roster group can have members from any Jabber server,
|
||||
A shared roster group can have members from any XMPP server,
|
||||
but the presence will only be available from and to members
|
||||
of the same virtual host where the group is created.
|
||||
|
||||
@ -4442,14 +4443,14 @@ The most interesting ones are:
|
||||
\titem{import\_piefxis, export\_piefxis, export\_piefxis\_host} \ind{migrate between servers}
|
||||
These options can be used to migrate accounts
|
||||
using \xepref{0227} formatted XML files
|
||||
from/to other \Jabber{}/XMPP servers
|
||||
from/to other Jabber/XMPP servers
|
||||
or move users of a vhost to another ejabberd installation.
|
||||
See also
|
||||
\footahref{https://support.process-one.net/doc/display/P1/ejabberd+migration+kit}{ejabberd migration kit}.
|
||||
\titem{import\_file, import\_dir} \ind{migration from other software}
|
||||
These options can be used to migrate accounts
|
||||
using jabberd1.4 formatted XML files.
|
||||
from other \Jabber{}/XMPP servers
|
||||
from other Jabber/XMPP servers
|
||||
There exist tutorials to
|
||||
\footahref{http://www.ejabberd.im/migrate-to-ejabberd}{migrate from other software to ejabberd}.
|
||||
\titem{delete\_expired\_messages} This option can be used to delete old messages
|
||||
@ -4479,7 +4480,7 @@ ArgumentValue = any()
|
||||
The default value is to not define any restriction: \term{[]}.
|
||||
If at least one restriction is defined, then the frontend expects
|
||||
that authentication information is provided when executing a command.
|
||||
The authentication information is Username, Hostname and Password of a local Jabber account
|
||||
The authentication information is Username, Hostname and Password of a local XMPP account
|
||||
that has permission to execute the corresponding command.
|
||||
This means that the account must be registered in the local ejabberd,
|
||||
because the information will be verified.
|
||||
@ -4612,9 +4613,9 @@ See section \ref{erlangconfiguration}.
|
||||
|
||||
If you enable \modconfigure\ and \modadhoc,
|
||||
you can perform several administrative tasks in \ejabberd{}
|
||||
with a Jabber client.
|
||||
with a XMPP client.
|
||||
The client must support Ad-Hoc Commands (\xepref{0050}),
|
||||
and you must login in the Jabber server with
|
||||
and you must login in the XMPP server with
|
||||
an account with proper privileges.
|
||||
|
||||
|
||||
@ -4813,7 +4814,7 @@ write and execute those files and directories.
|
||||
\makesection{howitworks}{How it Works}
|
||||
\ind{clustering!how it works}
|
||||
|
||||
A \Jabber{} domain is served by one or more \ejabberd{} nodes. These nodes can
|
||||
A \XMPP{} 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
|
||||
@ -4832,7 +4833,7 @@ Each \ejabberd{} node has the following modules:
|
||||
\makesubsection{router}{Router}
|
||||
\ind{clustering!router}
|
||||
|
||||
This module is the main router of \Jabber{} packets on each node. It
|
||||
This module is the main router of \XMPP{} 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
|
||||
@ -4857,7 +4858,7 @@ storage, or bounced back.
|
||||
\makesubsection{s2smanager}{s2s Manager}
|
||||
\ind{clustering!s2s manager}
|
||||
|
||||
This module routes packets to other \Jabber{} servers. First, it
|
||||
This module routes packets to other \XMPP{} 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
|
||||
@ -5048,7 +5049,7 @@ To exit the shell, close the window or press the keys: control+c control+c.
|
||||
\ejabberd{} includes a watchdog mechanism that may be useful to developers
|
||||
when troubleshooting a problem related to memory usage.
|
||||
If a process in the \ejabberd{} server consumes more memory than the configured threshold,
|
||||
a message is sent to the Jabber accounts defined with the option
|
||||
a message is sent to the XMPP accounts defined with the option
|
||||
\term{watchdog\_admins}
|
||||
\ind{options!watchdog\_admins} in the \ejabberd{} configuration file.
|
||||
|
||||
@ -5192,7 +5193,7 @@ Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
||||
%\titem{Regular Expression}
|
||||
%\titem{ACL} (Access Control List) <Wikipedia>
|
||||
%\titem{IPv6} <Wikipedia>
|
||||
%\titem{Jabber}
|
||||
%\titem{XMPP}
|
||||
%\titem{LDAP} (Lightweight Directory Access Protocol) <Wikipedia>
|
||||
%\titem{ODBC} (Open Database Connectivity) <Wikipedia>
|
||||
%\titem{Virtual Hosting} <Wikipedia>
|
||||
|
Loading…
Reference in New Issue
Block a user