From 77a62670d3f1687c9041b80beb5628fe3ec711f6 Mon Sep 17 00:00:00 2001 From: Badlop Date: Tue, 16 Jun 2009 13:53:25 +0000 Subject: [PATCH] Add permanent section about mod_http_fileserver to the Guide. Example config. SVN Revision: 2197 --- doc/Makefile | 3 - doc/guide.html | 259 +++++++++++++++++++++++---------------- doc/guide.tex | 59 ++++++++- src/ejabberd.cfg.example | 12 +- 4 files changed, 219 insertions(+), 114 deletions(-) diff --git a/doc/Makefile b/doc/Makefile index 3cc89b059..aa1a71673 100644 --- a/doc/Makefile +++ b/doc/Makefile @@ -6,9 +6,6 @@ CONTRIBUTED_MODULES = "" ifeq ($(shell ls mod_http_bind.tex),mod_http_bind.tex) CONTRIBUTED_MODULES += "\\n\\setboolean{modhttpbind}{true}" endif -ifeq ($(shell ls mod_http_fileserver.tex),mod_http_fileserver.tex) - CONTRIBUTED_MODULES += "\\n\\setboolean{modhttpfileserver}{true}" -endif all: release pdf html diff --git a/doc/guide.html b/doc/guide.html index 464f60eec..fdfaf3baf 100644 --- a/doc/guide.html +++ b/doc/guide.html @@ -142,76 +142,77 @@ BLOCKQUOTE.figure DIV.center DIV.center HR{display:none;}
  • 3.3.3  mod_announce
  • 3.3.4  mod_disco
  • 3.3.5  mod_echo -
  • 3.3.6  mod_last -
  • 3.3.7  mod_muc -
  • 3.3.8  mod_muc_log -
  • 3.3.9  mod_offline -
  • 3.3.10  mod_privacy -
  • 3.3.11  mod_private -
  • 3.3.12  mod_proxy65 -
  • 3.3.13  mod_pubsub -
  • 3.3.14  mod_register -
  • 3.3.15  mod_roster -
  • 3.3.16  mod_service_log -
  • 3.3.17  mod_shared_roster -
  • 3.3.18  mod_stats -
  • 3.3.19  mod_time -
  • 3.3.20  mod_vcard -
  • 3.3.21  mod_vcard_ldap -
  • 3.3.22  mod_version +
  • 3.3.6  mod_http_fileserver +
  • 3.3.7  mod_last +
  • 3.3.8  mod_muc +
  • 3.3.9  mod_muc_log +
  • 3.3.10  mod_offline +
  • 3.3.11  mod_privacy +
  • 3.3.12  mod_private +
  • 3.3.13  mod_proxy65 +
  • 3.3.14  mod_pubsub +
  • 3.3.15  mod_register +
  • 3.3.16  mod_roster +
  • 3.3.17  mod_service_log +
  • 3.3.18  mod_shared_roster +
  • 3.3.19  mod_stats +
  • 3.3.20  mod_time +
  • 3.3.21  mod_vcard +
  • 3.3.22  mod_vcard_ldap +
  • 3.3.23  mod_version
    • -
  • Chapter 4  Managing an ejabberd Server +
  • Chapter 4  Managing an ejabberd Server -
  • Chapter 5  Securing ejabberd +
  • Chapter 5  Securing ejabberd -
  • Chapter 6  Clustering +
  • Chapter 6  Clustering -
  • Chapter 7  Debugging +
  • Chapter 7  Debugging -
  • Appendix A  Internationalization and Localization -
  • Appendix B  Release Notes -
  • Appendix C  Acknowledgements -
  • Appendix D  Copyright Information +
  • Appendix A  Internationalization and Localization +
  • Appendix B  Release Notes +
  • Appendix C  Acknowledgements +
  • Appendix D  Copyright Information

    • Chapter 1  Introduction

    ejabberd is a free and open source instant messaging server written in Erlang.

    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.

    @@ -489,7 +490,7 @@ There are two ways to register a Jabber account:
    1. Using ejabberdctl (see section 4.1): 
      ejabberdctl register admin1 example.org FgT5bk3
-
    2. Using a Jabber client and In-Band Registration (see section 3.3.14). +
    3. Using a Jabber client and In-Band Registration (see section 3.3.15).
  • Edit the ejabberd configuration file to give administration rights to the Jabber account you created: 
    {acl, admins, {user, "admin1", "example.org"}}.
@@ -1885,7 +1886,7 @@ message is sent to all registered users. If the user is online and connected
 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 3.3.9) is enabled.
+(see section 3.3.10) is enabled.
 
    example.org/announce/online (example.org/announce/all-hosts/online)
    The
 message is sent to all connected users. If the user is online and connected
 to several resources, all resources will receive the message.
@@ -1995,8 +1996,54 @@ of them all?
   {mod_echo, [{host, "mirror.example.org"}]},
   ...
  ]}.
+

    +

    3.3.6  mod_http_fileserver

    +

    This simple module serves files from the local disk over HTTP.

    Options: +

    +docroot
    +Directory to serve the files. +
    accesslog
    +File to log accesses using an Apache-like format. +No log will be recorded if this option is not specified. +
    directory_indices
    +Indicate one or more directory index files, similarly to Apache’s +DirectoryIndex variable. When a web request hits a directory +instead of a regular file, those directory indices are looked in +order, and the first one found is returned. +

    This example configuration will serve the files from +the local directory /var/www +in the address http://example.org:5280/pub/archive/. +To use this module you must enable it: +

    {modules,
+ [
+  ...
+  {mod_http_fileserver, [
+                         {docroot, "/var/www"}, 
+    {directory_indices, ["index.html", "main.htm"]},
+                         {accesslog, "/var/log/ejabberd/access.log"}
+                        ]
+  },
+  ...
+]}.
+

    And define it as a handler in the HTTP service: +

    {listen, 
+ [
+  ...
+  {5280, ejabberd_http, [
+                         ...
+                         {request_handlers, [
+                                             ...
+                                             {["pub", "archive"], mod_http_fileserver},
+                                             ...
+                                            ]
+                         },
+                         ...
+                        ]
+  },
+  ...
+]}.

    -

    3.3.6  mod_last

    +

    3.3.7  mod_last

    This module adds support for Last Activity (XEP-0012). It can be used to discover when a disconnected user last accessed the server, to know when a connected user was last active on the server, or to query the uptime of the @@ -2005,7 +2052,7 @@ connected user was last active on the server, or to query the uptime of the iqdisc

    This specifies the processing discipline for Last activity (jabber:iq:last) IQ queries (see section 3.3.2).

    -

    3.3.7  mod_muc

    +

    3.3.8  mod_muc

    This module provides a Multi-User Chat (XEP-0045) service. Users can discover existing rooms, join or create them. Occupants of a room can chat in public or have private chats.

    Some of the features of Multi-User Chat: @@ -2228,7 +2275,7 @@ the newly created rooms have by default those options. ... ]}.

    • -

    3.3.8  mod_muc_log

    +

    3.3.9  mod_muc_log

    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 @@ -2348,7 +2395,7 @@ top link will be the default <a href="/">Home</a>. ... ]}.

    -

    3.3.9  mod_offline

    +

    3.3.10  mod_offline

    This module implements offline message storage. This means that all messages 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 @@ -2379,7 +2426,7 @@ and all the other users up to 100. ... ]}.

    -

    3.3.10  mod_privacy

    +

    3.3.11  mod_privacy

    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: @@ -2407,7 +2454,7 @@ subscription type (or globally). iqdisc

    This specifies the processing discipline for Blocking Communication (jabber:iq:privacy) IQ queries (see section 3.3.2).

    -

    3.3.11  mod_private

    +

    3.3.12  mod_private

    This module adds support for Private XML Storage (XEP-0049):

    Using this method, Jabber entities can store private data on the server and @@ -2419,7 +2466,7 @@ of client-specific preferences; another is Bookmark Storage ( This specifies the processing discipline for Private XML Storage (jabber:iq:private) IQ queries (see section 3.3.2).

    -

    3.3.12  mod_proxy65

    +

    3.3.13  mod_proxy65

    This module implements SOCKS5 Bytestreams (XEP-0065). It allows ejabberd to act as a file transfer proxy between two XMPP clients.

    Options: @@ -2474,7 +2521,7 @@ The simpliest configuration of the module: ... ]}.

    -

    3.3.13  mod_pubsub

    +

    3.3.14  mod_pubsub

    This module offers a Publish-Subscribe Service (XEP-0060). The functionality in mod_pubsub can be extended using plugins. The plugin that implements PEP (Personal Eventing via Pubsub) (XEP-0163) @@ -2520,7 +2567,7 @@ The following example will use node_tune instead of node_pep for every PEP node ... ]}.

    -

    3.3.14  mod_register

    +

    3.3.15  mod_register

    This module adds support for In-Band Registration (XEP-0077). This protocol enables end users to use a Jabber client to:

    -

    3.3.15  mod_roster

    +

    3.3.16  mod_roster

    This module implements roster management as defined in RFC 3921: XMPP IM.

    Options:

    iqdisc
    This specifies the processing discipline for Roster Management (jabber:iq:roster) IQ queries (see section 3.3.2).

    -

    3.3.16  mod_service_log

    +

    3.3.17  mod_service_log

    This module adds support for logging end user packets via a Jabber message auditing service such as Bandersnatch. All user @@ -2629,7 +2676,7 @@ To log all end user packets to the Bandersnatch service running on ... ]}.

    -

    3.3.17  mod_shared_roster

    +

    3.3.18  mod_shared_roster

    This module enables you to create shared roster groups. This means that you can 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 @@ -2704,7 +2751,7 @@ roster groups as shown in the following table:

    -

    3.3.18  mod_stats

    +

    3.3.19  mod_stats

    This module adds support for Statistics Gathering (XEP-0039). This protocol allows you to retrieve next statistics from your ejabberd deployment:

    -

    3.3.19  mod_time

    +

    3.3.20  mod_time

    This module features support for Entity Time (XEP-0090). By using this XEP, you are able to discover the time at another entity’s location.

    Options:

    iqdisc
    This specifies the processing discipline for Entity Time (jabber:iq:time) IQ queries (see section 3.3.2).

    -

    3.3.20  mod_vcard

    +

    3.3.21  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 @@ -2798,7 +2845,7 @@ and that all virtual hosts will be searched instead of only the current one: ... ]}.

    -

    3.3.21  mod_vcard_ldap

    +

    3.3.22  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).

    Note that ejabberd treats LDAP as a read-only storage: @@ -2974,7 +3021,7 @@ searching his info in LDAP.

  • ldap_vcard_map

    • -

    3.3.22  mod_version

    +

    3.3.23  mod_version

    This module implements Software Version (XEP-0092). Consequently, it answers ejabberd’s version when queried.

    Options:

    @@ -2983,8 +3030,8 @@ The default value is true.
    iqdisc
    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 @@ -2996,7 +3043,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:

    @@ -3032,7 +3079,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, @@ -3101,7 +3148,7 @@ Starts the Erlang system detached from the system console.

    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. @@ -3109,7 +3156,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
@@ -3149,7 +3196,7 @@ exist tutorials to migrate
 in offline storage. This might be useful when the number of offline messages
 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:
@@ -3195,7 +3242,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 @@ -3267,13 +3314,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 Jabber client. The client must support Ad-Hoc Commands (XEP-0050), and you must login in the Jabber 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. @@ -3310,8 +3357,8 @@ mv /var/lib/ejabberd/*.* /var/lib/ejabberd/oldfiles/

  • Check that the information of the old database is available: accounts, rosters... After you finish, remember to delete the temporary backup files from public directories.

    • -

    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:

    @@ -3322,7 +3369,7 @@ After you finish, remember to delete the temporary backup files from public dire
    PortDescription
    port rangeUsed 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. @@ -3347,7 +3394,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. @@ -3361,7 +3408,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 @@ -3370,7 +3417,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 Sensible Files

    ejabberd stores sensible data in the file system either in plain text or binary files. +

    5.5  Securing Sensible Files

    ejabberd stores sensible data in the file system either in plain text or binary files. The file system permissions should be set to only allow the proper user to read, write and execute those files and directories.

    ejabberd configuration file: /etc/ejabberd/ejabberd.cfg
    @@ -3390,9 +3437,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 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 @@ -3406,29 +3453,29 @@ router,

  • session manager,
  • s2s manager.

    • -

    6.1.1  Router

    +

    6.1.1  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.

    -

    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 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.

    -

    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:

    1. @@ -3466,10 +3513,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", <balancing_criterium>}.

    Several balancing criteria are available: