Ejabberd 2.1.x Developers Guide
Alexey Shchepin
+
Ejabberd 2.1.6 Developers GuideAlexey Shchepin |
Ejabberd 2.1.x Feature SheetSander Devrieze |
Ejabberd 2.1.6 Feature SheetSander Devrieze |
-
| ejabberd 2.1.x |
| ejabberd 2.1.6 |
| Installation and Operation Guide |
@@ -160,66 +160,67 @@ BLOCKQUOTE.figure DIV.center DIV.center HR{display:none;}
Chapter 1 Introduction
ejabberd is a free and open source instant messaging server written in Erlang/OTP.
ejabberd is cross-platform, distributed, fault-tolerant, and based on open standards to achieve real-time communication.
ejabberd is designed to be a rock-solid and feature rich XMPP server.
ejabberd is suitable for small deployments, whether they need to be scalable or not, as well as extremely big deployments.
@@ -347,6 +348,7 @@ GNU MakeOptions: captcha, certfile, http_bind, http_poll, -request_handlers, tls, web_admin
+request_handlers, tls, trusted_proxies, web_admin
Options
This is a detailed description of each option allowed by the listening modules:
-
@@ -803,6 +805,10 @@ The preferable encryption method is STARTTLS on port 5222, as defined
which can be enabled in ejabberd with the option starttls.
If this option is set, you should also set the certfile option.
The option tls can also be used in ejabberd_http to support HTTPS.
+
- {trusted_proxies, all | [IpString]}
- +Specify what proxies are trusted when an HTTP request contains the header X-Forwarded-For +You can specify all to allow all proxies, or specify a list of IPs in string format. +The default value is: ["127.0.0.1"]
- web_admin
- This option
enables the Web Admin for ejabberd administration which is available
at
http://server:port/admin/. Login and password are the username and @@ -813,9 +819,12 @@ option specifies that Zlib stream compression (as defined in- -{s2s_use_starttls, true|false}
- -This option defines whether to -use STARTTLS for s2s connections. +{s2s_use_starttls, false|optional|required|required_trusted}
- +This option defines if +s2s connections don’t use STARTTLS encryption; if STARTTLS can be used optionally; +if STARTTLS is required to establish the connection; +or if STARTTLS is required and the remote certificate must be valid and trusted. +The default value is to not use STARTTLS: false.
- {s2s_certfile, Path}
- Full path to a file containing a SSL certificate.
- {domain_certfile, Domain, Path}
- @@ -903,7 +912,7 @@ section 4.3. The socket only listens connections to ]} ] }. -{s2s_use_starttls, true}. +{s2s_use_starttls, optional}. {s2s_certfile, "/etc/ejabberd/server.pem"}. {domain_certfile, "example.com", "/etc/ejabberd/example_com.pem"}. {outgoing_s2s_options, [ipv4, ipv6], 10000}. @@ -913,7 +922,7 @@ c2s connections are listened for on port 5222 (all IPv4 addresses) and on port 5223 (SSL, IP 192.168.0.1 and fdca:8ab6:a243:75ef::1) and denied for the user called ‘bad’.
3.2.5 LDAP
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.
Usually ejabberd treats LDAP as a read-only storage: +server and use LDAP directory as vCard storage.
Usually ejabberd treats LDAP as a read-only storage: it is possible to consult data, but not possible to create accounts or edit vCard that is stored in LDAP. However, it is possible to change passwords if mod_register module is enabled @@ -1928,6 +1936,8 @@ all entries end with a comma:
Examples:
-
-Next example prohibits the registration of too short account names:
+Next example prohibits the registration of too short account names,
+and allows to create accounts only to clients of the local network:
{acl, shortname, {user_glob, "?"}}. {acl, shortname, {user_glob, "??"}}. %% The same using regexp: @@ -3010,7 +3027,10 @@ Next example prohibits the registration of too short account names: {modules, [ ... - {mod_register, [{access, register}]}, + {mod_register, [{access, register}, + {ip_access, [{allow, "127.0.0.0/8"}, + {deny, "0.0.0.0/0"}]} + ]}, ... ]}. - This configuration prohibits usage of In-Band Registration @@ -3094,7 +3114,8 @@ Enabling this option reduces the load for both ejabberd and the database. This option does not affect the client in any way. This option is only useful if Roster Versioning is enabled. This option is disabled by default. -Important: if you use mod_shared_roster, you must disable this option. +Important: if you use mod_shared_roster or mod_shared_roster_ldap, +you must disable this option.
This example configuration enables Roster Versioning with storage of current id:
{modules,
[
@@ -3207,15 +3228,232 @@ roster groups as shown in the following table:
3.3.23 mod_sic
+3.3.23 mod_shared_roster_ldap
This module lets the server administrator +automatically populate users’ rosters (contact lists) with entries based on +users and groups defined in an LDAP-based directory.
+Configuration parameters
The module accepts the following configuration parameters. Some of them, if +unspecified, default to the values specified for the top level of +configuration. This lets you avoid specifying, for example, the bind password, +in multiple places.
+Filters
These parameters specify LDAP filters used to query for shared roster information.
+All of them are run against the ldap_base.
- ldap_rfilter
-
+So called “Roster Filter”. Used to find names of all “shared roster” groups.
+See also the
ldap_groupattrparameter. +If unspecified, defaults to the top-level parameter of the same name. +You must specify it in some place in the configuration, there is no default. - ldap_ufilter
-
+“User Filter” – used for retrieving the human-readable name of roster
+entries (usually full names of people in the roster).
+See also the parameters
ldap_userdescandldap_useruid. +If unspecified, defaults to the top-level parameter of the same name. +If that one also is unspecified, then the filter is assembled from values of +other parameters as follows ([ldap_SOMETHING]is used to mean “the +value of the configuration parameter ldap_SOMETHING”):(&(&([ldap_memberattr]=[ldap_memberattr_format])([ldap_groupattr]=%g))[ldap_filter]) +
Subsequently %u and %g are replaced with a *. This means +that given the defaults, the filter sent to the LDAP server is would be +
(&(memberUid=*)(cn=*)). If however the ldap_memberattr_format +is something likeuid=%u,ou=People,o=org, then the filter will be +(&(memberUid=uid=*,ou=People,o=org)(cn=*)). - ldap_gfilter
-
+“Group Filter” – used when retrieving human-readable name (a.k.a.
+“Display Name”) and the members of a group.
+See also the parameters
ldap_groupattr,ldap_groupdescandldap_memberattr. +If unspecified, defaults to the top-level parameter of the same name. +If that one also is unspecified, then the filter is constructed exactly in the +same way as User Filter. - ldap_filter
- +Additional filter which is AND-ed together with User Filter and Group Filter. +If unspecified, defaults to the top-level parameter of the same name. If that +one is also unspecified, then no additional filter is merged with the other +filters. +
Note that you will probably need to manually define the User and Group Filters (since the auto-assembled ones will not work) if: +
- +your ldap_memberattr_format is anything other than a simple %u, +
- and the attribute specified with ldap_memberattr does not support substring matches. +
+An example where it is the case is OpenLDAP and (unique)MemberName attribute from the groupOf(Unique)Names objectClass. +A symptom of this problem is that you will see messages such as the following in your slapd.log: +
get_filter: unknown filter type=130 +filter="(&(?=undefined)(?=undefined)(something=else))" ++
Attributes
These parameters specify the names of the attributes which hold interesting data +in the entries returned by running filters specified in +section 3.3.23.
- +ldap_groupattr
- +The name of the attribute that holds the group name, and that is used to differentiate between them. +Retrieved from results of the “Roster Filter” and “Group Filter”. +Defaults to cn.
- ldap_groupdesc
- +The name of the attribute which holds the human-readable group name in the +objects you use to represent groups. +Retrieved from results of the “Group Filter”. +Defaults to whatever ldap_groupattr is set.
- ldap_memberattr
-
+The name of the attribute which holds the IDs of the members of a group.
+Retrieved from results of the “Group Filter”.
+Defaults to memberUid.
The name of the attribute differs depending on the objectClass you use +for your group objects, for example: +
- +
- posixGroup → memberUid +
- groupOfNames → member +
- groupOfUniqueNames → uniqueMember +
- ldap_userdesc
- +The name of the attribute which holds the human-readable user name. +Retrieved from results of the “User Filter”. +Defaults to cn.
- ldap_useruid
- +The name of the attribute which holds the ID of a roster item. Value of this +attribute in the roster item objects needs to match the ID retrieved from the +ldap_memberattr attribute of a group object. +Retrieved from results of the “User Filter”. +Defaults to cn. +
Control parameters
These paramters control the behaviour of the module.
- ldap_memberattr_format
-
+A globbing format for extracting user ID from the value of the attribute named by
+
ldap_memberattr. +Defaults to %u, which means that the whole value is the member ID. If +you change it to something different, you may also need to specify the User +and Group Filters manually — see section 3.3.23. - ldap_memberattr_format_re
-
+A regex for extracting user ID from the value of the attribute named by
+
ldap_memberattr.An example value "CN=(\\w*),(OU=.*,)*DC=company,DC=com" works for user IDs such as the following: +
- +CN=Romeo,OU=Montague,DC=company,DC=com +
- CN=Abram,OU=Servants,OU=Montague,DC=company,DC=com +
- CN=Juliet,OU=Capulet,DC=company,DC=com +
- CN=Peter,OU=Servants,OU=Capulet,DC=company,DC=com +
In case: +
- +the option is unset, +
- or the re module in unavailable in the current Erlang environment, +
- or the regular expression does not compile, +
+then instead of a regular expression, a simple format specified by ldap_memberattr_format is used. Also, in the last two cases an error +message is logged during the module initialization.
Also, note that in all cases ldap_memberattr_format (and not the +regex version) is used for constructing the default “User/Group Filter” — +see section 3.3.23.
- ldap_auth_check
- +Whether the module should check (via the ejabberd authentication subsystem) +for existence of each user in the shared LDAP roster. See +section 3.3.23 form more information. Set to off if you +want to disable the check. +Defaults to on.
- ldap_user_cache_validity
- +Number of seconds for which the cache for roster item full names is considered +fresh after retrieval. 300 by default. See section 3.3.23 on +how it is used during roster retrieval.
- ldap_group_cache_validity
- +Number of seconds for which the cache for group membership is considered +fresh after retrieval. 300 by default. See section 3.3.23 on +how it is used during roster retrieval. +
Connection parameters
The module also accepts the connection parameters, all of which default to the +top-level parameter of the same name, if unspecified. See 3.2.5 +for more information about them.
+Retrieving the roster
When the module is called to retrieve the shared roster for a user, the +following algorithm is used:
- + A list of names of groups to display is created: the Roster Filter +is run against the base DN, retrieving the values of the attribute named by +ldap_groupattr.
- Unless the group cache is fresh (see the ldap_group_cache_validity option), it is refreshed:
- +Information for all groups is retrieved using a single query: the Group Filter is run against the Base DN, retrieving the values of attributes +named by ldap_groupattr (group ID), ldap_groupdesc (group +“Display Name”) and ldap_memberattr (IDs of group members).
- group “Display Name”, read from the attribute named by ldap_groupdesc, is stored in the cache for the given group
- the following processing takes place for each retrieved value of
+attribute named by ldap_memberattr:
+
- +the user ID part of it is extracted using ldap_memberattr_format(_re),
- then (unless ldap_auth_check is set to off) for each
+found user ID, the module checks (using the ejabberd authentication
+subsystem) whether such user exists in the given virtual host. It is
+skipped if the check is enabled and fails.
This step is here for historical reasons. If you have a tidy DIT and +properly defined “Roster Filter” and “Group Filter”, it is safe to +disable it by setting ldap_auth_check to off — it will +speed up the roster retrieval.
- the user ID is stored in the list of members in the cache for the +given group +
- For each item (group name) in the list of groups retrieved in step 1:
- +the display name of a shared roster group is retrieved from the group +cache
- for each IDs of users which belong to the group, retrieved from the
+group cache:
- +the ID is skipped if it’s the same as the one for which we are +retrieving the roster. This is so that the user does not have himself in +the roster.
- the display name of a shared roster user is retrieved:
+
- +first, unless the user name cache is fresh (see the ldap_user_cache_validity option), it is refreshed by running the +User Filter, against the Base DN, retrieving the values of +attributes named by ldap_useruid and ldap_userdesc. +
- then, the display name for the given user ID is retrieved from the +user name cache. +
Configuration examples
Since there are many possible +DIT +layouts, it will probably be easiest to understand how to configure the module +by looking at an example for a given DIT (or one resembling it).
+Flat DIT
This seems to be the kind of DIT for which this module was initially designed. +Basically there are just user objects, and group membership is stored in an +attribute individually for each user. For example in a layout shown in +figure 3.1, the group of each user is stored in its ou attribute.
+
+
+Such layout has a few downsides, including: +
- +information duplication – the group name is repeated in every member object +
- difficult group management – information about group members is not +centralized, but distributed between member objects +
- inefficiency – the list of unique group names has to be computed by iterating over all users +
This however seems to be a common DIT layout, so the module keeps supporting it. +You can use the following configuration…
{mod_shared_roster_ldap,[
+ {ldap_base, "ou=flat,dc=nodomain"},
+ {ldap_rfilter, "(objectClass=inetOrgPerson)"},
+ {ldap_groupattr, "ou"},
+ {ldap_memberattr, "cn"},
+ {ldap_filter, "(objectClass=inetOrgPerson)"},
+ {ldap_userdesc, "displayName"}
+ ]},
+…to be provided with a roster as shown in figure 3.2 upon connecting as user czesio.
+
+
+
+Deep DIT
This type of DIT contains distinctly typed objects for users and groups – see figure 3.3. +They are shown separated into different subtrees, but it’s not a requirement.
+
+
+If you use the following example module configuration with it: +
{mod_shared_roster_ldap,[
+ {ldap_base, "ou=deep,dc=nodomain"},
+ {ldap_rfilter, "(objectClass=groupOfUniqueNames)"},
+ {ldap_filter, ""},
+ {ldap_gfilter, "(&(objectClass=groupOfUniqueNames)(cn=%g))"},
+ {ldap_groupdesc, "description"},
+ {ldap_memberattr, "uniqueMember"},
+ {ldap_memberattr_format, "cn=%u,ou=people,ou=deep,dc=nodomain"},
+ {ldap_ufilter, "(&(objectClass=inetOrgPerson)(cn=%u))"},
+ {ldap_userdesc, "displayName"}
+ ]},
+…and connect as user czesio, then ejabberd will provide you with +the roster shown in figure 3.4.
+
+
+
+3.3.24 mod_sic
This module adds support for Server IP Check (XEP-0279). This protocol enables a client to discover its external IP address.
Options:
- {iqdisc, Discipline}
- This specifies the processing discipline for urn:xmpp:sic:0 IQ queries (see section 3.3.2).
3.3.24 mod_stats
3.3.25 mod_stats
This module adds support for Statistics Gathering (XEP-0039). This protocol allows you to retrieve next statistics from your ejabberd deployment:
- @@ -3247,14 +3485,14 @@ by sending: </query> </iq>
3.3.25 mod_time
3.3.26 mod_time
This module features support for Entity Time (XEP-0202). By using this XEP, you are able to discover the time at another entity’s location.
Options:
- {iqdisc, Discipline}
- This specifies the processing discipline for Entity Time (jabber:iq:time) IQ queries (see section 3.3.2).
3.3.26 mod_vcard
3.3.27 mod_vcard
This module allows end users to store and retrieve their vCard, and to retrieve other users vCards, as defined in vcard-temp (XEP-0054). The module also implements an uncomplicated Jabber User Directory based on the vCards of @@ -3309,7 +3547,7 @@ and that all virtual hosts will be searched instead of only the current one: ... ]}.
-3.3.27 mod_vcard_ldap
3.3.28 mod_vcard_ldap
ejabberd can map LDAP attributes to vCard fields. This behaviour is implemented in the mod_vcard_ldap module. This module does not depend on the authentication method (see 3.2.5).
Usually ejabberd treats LDAP as a read-only storage: @@ -3491,7 +3729,7 @@ searching his info in LDAP.
3.3.28 mod_vcard_xupdate
3.3.29 mod_vcard_xupdate
The user’s client can store an avatar in the user vCard. The vCard-Based Avatars protocol (XEP-0153) provides a method for clients to inform the contacts what is the avatar hash value. @@ -3505,7 +3743,7 @@ and each presence sent by a client produces hash retrieval and a presence stanza rewrite. For this reason, enabling this module will introduce a computational overhead in servers with clients that change frequently their presence.
-3.3.29 mod_version
3.3.30 mod_version
This module implements Software Version (XEP-0092). Consequently, it answers ejabberd’s version when queried.
Options:
-
@@ -3514,8 +3752,8 @@ The default value is true.
- {iqdisc, Discipline}
- This specifies the processing discipline for Software Version (jabber:iq:version) IQ queries (see section 3.3.2).
Chapter 4 Managing an ejabberd Server
-4.1 ejabberdctl
With the ejabberdctl command line administration script +
Chapter 4 Managing an ejabberd Server
+4.1 ejabberdctl
With the ejabberdctl command line administration script you can execute ejabberdctl commands (described in the next section, 4.1.1) and also many general ejabberd commands (described in section 4.2). This means you can start, stop and perform many other administrative tasks @@ -3527,7 +3765,7 @@ and other codes may be used for specific results. This can be used by other scripts to determine automatically if a command succeeded or failed, for example using: echo $?
-4.1.1 ejabberdctl Commands
When ejabberdctl is executed without any parameter, +
4.1.1 ejabberdctl Commands
When ejabberdctl is executed without any parameter, it displays the available options. If there isn’t an ejabberd server running, the available parameters are:
-
@@ -3563,7 +3801,7 @@ robot1
testuser1
testuser2
-
4.1.2 Erlang Runtime System
ejabberd is an Erlang/OTP application that runs inside an Erlang runtime system. +
4.1.2 Erlang Runtime System
ejabberd is an Erlang/OTP application that runs inside an Erlang runtime system. This system is configured using environment variables and command line parameters. The ejabberdctl administration script uses many of those possibilities. You can configure some of them with the file ejabberdctl.cfg, @@ -3640,7 +3878,7 @@ not “Simple Authentication and Security Layer”.
Note that some characters need to be escaped when used in shell scripts, for instance " and {}.
You can find other options in the Erlang manual page (erl -man erl).
4.2 ejabberd Commands
An ejabberd command is an abstract function identified by a name, +
4.2 ejabberd Commands
An ejabberd command is an abstract function identified by a name, with a defined number and type of calling arguments and type of result that is registered in the ejabberd_commands service. Those commands can be defined in any Erlang module and executed using any valid frontend.
ejabberd includes a frontend to execute ejabberd commands: the script ejabberdctl. @@ -3648,7 +3886,7 @@ Other known frontends that can be installed to execute ejabberd commands in diff ejabberd_xmlrpc (XML-RPC service), mod_rest (HTTP POST service), mod_shcommands (ejabberd WebAdmin page).
-4.2.1 List of ejabberd Commands
ejabberd includes a few ejabberd Commands by default. +
4.2.1 List of ejabberd Commands
ejabberd includes a few ejabberd Commands by default. When more modules are installed, new commands may be available in the frontends.
The easiest way to get a list of the available commands, and get help for them is to use the ejabberdctl script:
$ ejabberdctl help @@ -3700,7 +3938,7 @@ is very high.
4.2.2 Restrict Execution with AccessCommands
The frontends can be configured to restrict access to certain commands. +
4.2.2 Restrict Execution with AccessCommands
The frontends can be configured to restrict access to certain commands. In that case, authentication information must be provided. In each frontend the AccessCommands option is defined in a different place. But in all cases the option syntax is the same: @@ -3745,7 +3983,7 @@ and the provided arguments do not contradict Arguments.
As an example to u {_bot_reg_test, [register, unregister], [{host, "test.org"}]} ]
-4.3 Web Admin
4.3 Web Admin
The ejabberd Web Admin allows to administer most of ejabberd using a web browser.
This feature is enabled by default: a ejabberd_http listener with the option web_admin (see section 3.1.3) is included in the listening ports. Then you can open @@ -3822,13 +4060,13 @@ The file is searched by default in The directory of the documentation can be specified in the environment variable EJABBERD_DOC_PATH. See section 4.1.2.
-4.4 Ad-hoc Commands
If you enable mod_configure and mod_adhoc, +
4.4 Ad-hoc Commands
If you enable mod_configure and mod_adhoc, you can perform several administrative tasks in ejabberd with a XMPP client. The client must support Ad-Hoc Commands (XEP-0050), and you must login in the XMPP server with an account with proper privileges.
-4.5 Change Computer Hostname
ejabberd uses the distributed Mnesia database. +
4.5 Change Computer Hostname
ejabberd uses the distributed Mnesia database. Being distributed, Mnesia enforces consistency of its file, so it stores the name of the Erlang node in it (see section 5.4). The name of an Erlang node includes the hostname of the computer. @@ -3874,8 +4112,8 @@ mv /var/lib/ejabberd/*.* /var/lib/ejabberd/oldfiles/
Chapter 5 Securing ejabberd
-5.1 Firewall Settings
Chapter 5 Securing ejabberd
+5.1 Firewall Settings
You need to take the following TCP ports in mind when configuring your firewall:
-
@@ -3886,7 +4124,7 @@ After you finish, remember to delete the temporary backup files from public dire Port Description port range Used for connections between Erlang nodes. This range is configurable (see section 5.2).
5.2 epmd
epmd (Erlang Port Mapper Daemon) +
5.2 epmd
epmd (Erlang Port Mapper Daemon) is a small name server included in Erlang/OTP and used by Erlang programs when establishing distributed Erlang communications. ejabberd needs epmd to use ejabberdctl and also when clustering ejabberd nodes. @@ -3911,7 +4149,7 @@ but can be configured in the file ejabberdctl.cfg. The Erlang command-line parameter used internally is, for example:
erl ... -kernel inet_dist_listen_min 4370 inet_dist_listen_max 4375-
5.3 Erlang Cookie
The Erlang cookie is a string with numbers and letters. +
5.3 Erlang Cookie
The Erlang cookie is a string with numbers and letters. An Erlang node reads the cookie at startup from the command-line parameter -setcookie. If not indicated, the cookie is read from the cookie file $HOME/.erlang.cookie. If this file does not exist, it is created immediately with a random cookie. @@ -3925,7 +4163,7 @@ to prevent unauthorized access or intrusion to an Erlang node. The communication between Erlang nodes are not encrypted, so the cookie could be read sniffing the traffic on the network. The recommended way to secure the Erlang node is to block the port 4369.
-5.4 Erlang Node Name
An Erlang node may have a node name. +
5.4 Erlang Node Name
An Erlang node may have a node name. The name can be short (if indicated with the command-line parameter -sname) or long (if indicated with the parameter -name). Starting an Erlang node with -sname limits the communication between Erlang nodes to the LAN.
Using the option -sname instead of -name is a simple method @@ -3934,7 +4172,7 @@ However, it is not ultimately effective to prevent access to the Erlang node, because it may be possible to fake the fact that you are on another network using a modified version of Erlang epmd. The recommended way to secure the Erlang node is to block the port 4369.
-5.5 Securing Sensitive Files
ejabberd stores sensitive data in the file system either in plain text or binary files. +
5.5 Securing Sensitive Files
ejabberd stores sensitive data in the file system either in plain text or binary files. The file system permissions should be set to only allow the proper user to read, write and execute those files and directories.
- ejabberd configuration file: /etc/ejabberd/ejabberd.cfg
- @@ -3954,9 +4192,9 @@ so it is preferable to secure the whole /var/lib/ejabberd/ directory.
- Erlang cookie file: /var/lib/ejabberd/.erlang.cookie
- See section 5.3.
Chapter 6 Clustering
Chapter 6 Clustering
-6.1 How it Works
6.1 How it Works
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 @@ -3970,29 +4208,29 @@ router,
6.1.1 Router
6.1.1 Router
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 appropriate process. If not, it is sent to the s2s manager.
-6.1.2 Local Router
6.1.2 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.
-6.1.3 Session Manager
6.1.3 Session Manager
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.
-6.1.4 s2s Manager
6.1.4 s2s Manager
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 serving this connection, otherwise a new connection is opened.
-6.2 Clustering Setup
6.2 Clustering Setup
Suppose you already configured ejabberd on one machine named (first), and you need to setup another one to make an ejabberd cluster. Then do following steps:
-
@@ -4030,10 +4268,10 @@ and ‘
access’ options because they will be taken from enabled only on one machine in the cluster.
You can repeat these steps for other machines supposed to serve this domain.
-6.3 Service Load-Balancing
6.3 Service Load-Balancing
-6.3.1 Components Load-Balancing
-6.3.2 Domain Load-Balancing Algorithm
6.3.1 Components Load-Balancing
+6.3.2 Domain Load-Balancing Algorithm
ejabberd includes an algorithm to load balance the components that are plugged on an ejabberd cluster. It means that you can plug one or several instances of the same component on each ejabberd cluster and that the traffic will be automatically distributed.
The default distribution algorithm try to deliver to a local instance of a component. If several local instances are available, one instance is chosen randomly. If no instance is available locally, one instance is chosen randomly among the remote component instances.
If you need a different behaviour, you can change the load balancing behaviour with the option domain_balancing. The syntax of the option is the following:
- {domain_balancing, "component.example.com", BalancingCriteria}.
Several balancing criteria are available:
-
@@ -4042,12 +4280,12 @@ domain.
-
6.3.3 Load-Balancing Buckets
6.3.3 Load-Balancing Buckets
When there is a risk of failure for a given component, domain balancing can cause service trouble. If one component is failing the service will not work correctly unless the sessions are rebalanced.
In this case, it is best to limit the problem to the sessions handled by the failing component. This is what the domain_balancing_component_number option does, making the load balancing algorithm not dynamic, but sticky on a fix number of component instances.
The syntax is:
- {domain_balancing_component_number, "component.example.com", Number}.
Chapter 7 Debugging
Chapter 7 Debugging
-7.1 Log Files
An ejabberd node writes two log files: +
7.1 Log Files
An ejabberd node writes two log files:
- ejabberd.log
- is the ejabberd service log, with the messages reported by ejabberd code
- erlang.log
- is the Erlang/OTP system log, with the messages reported by Erlang/OTP using SASL (System Architecture Support Libraries)
@@ -4072,12 +4310,12 @@ The ejabberdctl command reopen-log
(please refer to section 4.1.1)
reopens the log files,
and also renames the old ones if you didn’t rename them.
-
7.2 Debug Console
The Debug Console is an Erlang shell attached to an already running ejabberd server. +
7.2 Debug Console
The Debug Console is an Erlang shell attached to an already running ejabberd server. With this Erlang shell, an experienced administrator can perform complex tasks.
This shell gives complete control over the ejabberd server, so it is important to use it with extremely care. There are some simple and safe examples in the article Interconnecting Erlang Nodes
To exit the shell, close the window or press the keys: control+c control+c.
-7.3 Watchdog Alerts
7.3 Watchdog Alerts
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, @@ -4097,7 +4335,7 @@ or in a conversation with the watchdog alert bot.
The syntax is: To remove all watchdog admins, set the option with an empty list:
{watchdog_admins, []}.-Appendix A Internationalization and Localization
Appendix A Internationalization and Localization
The source code of ejabberd supports localization. The translators can edit the gettext .po files @@ -4132,21 +4370,22 @@ HTTP header ‘Accept-Language: ru’