From 554a9a72f10c629c6bd0fa7a253cebf1dbcfcd09 Mon Sep 17 00:00:00 2001 From: Badlop Date: Fri, 17 Apr 2009 13:53:20 +0000 Subject: [PATCH] * doc/guide.tex: Document new ejabberdctl option. New section that documents AccessCommands. (EJAB-910) * doc/guide.html: Likewise SVN Revision: 2025 --- ChangeLog | 4 + doc/guide.html | 306 ++++++++++++++++++++++++++++++++----------------- doc/guide.tex | 222 +++++++++++++++++++++++++++-------- 3 files changed, 382 insertions(+), 150 deletions(-) diff --git a/ChangeLog b/ChangeLog index 58c038417..d91136760 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,9 @@ 2009-04-17 Badlop + * doc/guide.tex: Document new ejabberdctl option. New section that + documents AccessCommands. (EJAB-910) + * doc/guide.html: Likewise + * src/ejabberd_ctl.erl: New option to require auth in ejabberdctl and restrict what commands and arguments can execute (EJAB-910) * src/ejabberd_config.erl: Likewise diff --git a/doc/guide.html b/doc/guide.html index 4723b9f0e..9b5d2596d 100644 --- a/doc/guide.html +++ b/doc/guide.html @@ -165,48 +165,53 @@ BLOCKQUOTE.figure DIV.center DIV.center HR{display:none;} -
  • Chapter 5  Securing ejabberd +
  • 4.2  ejabberd Commands -
  • Chapter 6  Clustering +
  • 4.3  Web Admin +
  • 4.4  Ad-hoc Commands +
  • 4.5  Change Computer Hostname +
    • +
  • Chapter 5  Securing ejabberd +
  • Chapter 6  Clustering -
  • 6.2  Clustering Setup -
  • 6.3  Service Load-Balancing +6.1  How it Works -
    • -
  • Chapter 7  Debugging +
  • 6.2  Clustering Setup +
  • 6.3  Service Load-Balancing -
  • Appendix A  Internationalization and Localization -
  • Appendix B  Release Notes -
  • Appendix C  Acknowledgements -
  • Appendix D  Copyright Information +
    • +
  • Chapter 7  Debugging + +
  • 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.

    @@ -795,7 +800,7 @@ and also allows plain connections for old clients.
  • Port 5269 listens for s2s connections with STARTTLS. The socket is set for IPv6 instead of IPv4.
  • Port 5280 listens for HTTP requests, and serves the HTTP Poll service.
  • Port 5281 listens for HTTP requests, and serves the Web Admin using HTTPS as explained in -section 4.2. The socket only listens connections to the IP address 127.0.0.1. +section 4.3. The socket only listens connections to the IP address 127.0.0.1. 
    • {hosts, ["example.com", "example.org", "example.net"]}.
 {listen,
  [
@@ -839,7 +844,7 @@ only two servers can connect: "jabber.example.org" and "example.com".
 
  • Port 5280 is serving the Web Admin and the HTTP Polling service
 in all the IPv4 addresses. Note
 that it is also possible to serve them on different ports. The second
-example in section 4.2 shows how exactly this can be done.
+example in section 4.3 shows how exactly this can be done.
 
  • All users except for the administrators have a traffic of limit 
 1,000 Bytes/second
 
  • The
@@ -2953,9 +2958,19 @@ The default value is true.
 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
      
      
    
-
    4.1.1  Commands
      
    The ejabberdctl command line administration script allows to start, stop and perform
-many other administrative tasks in a local or remote ejabberd server.
    When ejabberdctl is executed without any parameter,
+
    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
+in a local or remote ejabberd server (by providing the argument --node NODENAME).
    The ejabberdctl script can be configured in the file ejabberdctl.cfg.
+This file includes detailed information about each configurable option. See section 4.1.2.
    The ejabberdctl script returns a numerical status code.
+Success is represented by 0,
+error is represented by 1,
+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,
 it displays the available options. If there isn’t an ejabberd server running,
 the available parameters are:
 
    
@@ -2963,45 +2978,34 @@ the available parameters are:
 
    debug
     Attach an Erlang shell to an already existing ejabberd server. This allows to execute commands interactively in the ejabberd server.
 
    live
     Start ejabberd in live mode: the shell keeps attached to the started server, showing log messages and allowing to execute interactive commands.
 
    If there is an ejabberd server running in the system,
-ejabberdctl shows all the available commands in that server.
-The more interesting ones are:
+ejabberdctl shows the ejabberdctl commands described bellow
+and all the ejabberd commands available in that server (see 4.2.1).
    The ejabberdctl commands are:
 
    
 help
     Get help about ejabberdctl or any available command. Try ejabberdctl help help.
 
    status
     Check the status of the ejabberd server.
-
    stop
     Stop the ejabberd server which is running in the machine.
-
    reopen-log
     Reopen the log files after they were renamed.
-If the old files were not renamed before calling this command,
-they are automatically renamed to "*-old.log". See section 7.1.
-
    backup ejabberd.backup
    
-Store internal Mnesia database to a binary backup file.
-
    restore ejabberd.backup
    
-Restore immediately from a binary backup file the internal Mnesia database.
-This will consume quite some memory for big servers.
-
    install-fallback ejabberd.backup
    
-The binary backup file is installed as fallback:
-it will be used to restore the database at the next ejabberd start.
-Similar to restore, but requires less memory.
-
    dump ejabberd.dump
    
-Dump internal Mnesia database to a text file dump.
-
    load ejabberd.dump
    
-Restore immediately from a text file dump.
-This is not recommended for big databases, as it will consume much time,
-memory and processor. In that case it’s preferable to use backup and install-fallback.
-
    import-file, import-dir
     
-These options can be used to migrate from other Jabber/XMPP servers. There
-exist tutorials to migrate from other software to ejabberd.
-
    delete-expired-messages
     This option can be used to delete old messages
-in offline storage. This might be useful when the number of offline messages
-is very high.
-
    The ejabberdctl script also allows the argument --node NODENAME.
-This allows to administer a remote node.
    The ejabberdctl script can be configured in the file ejabberdctl.cfg.
-This file includes detailed information about each configurable option.
    The ejabberdctl script returns a numerical status code.
-Success is represented by 0,
-error is represented by 1,
-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 $?
      
    
+
    stop
     Stop the ejabberd server.
+
    restart
     Restart the ejabberd server.
+
    mnesia
     Get information about the Mnesia database.
+
    The ejabberdctl script can be restricted to require authentication
+and execute some ejabberd commands; see 4.2.2.
+Add the option to the file ejabberd.cfg.
+In this example there is no restriction:
+
    {ejabberdctl_access_commands, []}.
+
    If account robot1@example.org is registered in ejabberd with password abcdef
+(which MD5 is E8B501798950FC58AAD83C8C14978E),
+and ejabberd.cfg contains this setting:
+
    {hosts, ["example.org"]}.
+{acl, bots, {user, "robot1", "example.org"}}.
+{access, ctlaccess, [{allow, bots}]}.
+{ejabberdctl_access_commands, [ {ctlaccess, [registered_users, register], []} ]}.
+
    then you can do this in the shell:
+
    $ ejabberdctl registered_users example.org
+Error: no_auth_provided
+$ ejabberdctl --auth robot1 example.org E8B501798950FC58AAD83C8C14978E registered_users example.org
+robot1
+testuser1
+testuser2
+
      
    
 
    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.
@@ -3070,8 +3074,102 @@ Starts the Erlang system detached from the system console.
 	Open an Erlang shell in a remote Erlang node.
 
    
 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  Web Admin
      
+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,
+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.
+Other known frontends that can be installed to execute ejabberd commands in different ways are:
+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.
+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
+Usage: ejabberdctl [--node nodename] [--auth user host password] command [options]
+
+Available commands in this ejabberd node:
+  backup file                  Store the database to backup file
+  connected_users              List all established sessions
+  connected_users_number       Get the number of established sessions
+  delete_expired_messages      Delete expired offline messages from database
+  delete_old_messages days     Delete offline messages older than DAYS
+  ...
+
    The more interesting ones are:
+
    
+reopen-log
     Reopen the log files after they were renamed.
+If the old files were not renamed before calling this command,
+they are automatically renamed to "*-old.log". See section 7.1.
+
    backup ejabberd.backup
    
+Store internal Mnesia database to a binary backup file.
+
    restore ejabberd.backup
    
+Restore immediately from a binary backup file the internal Mnesia database.
+This will consume quite some memory for big servers.
+
    install-fallback ejabberd.backup
    
+The binary backup file is installed as fallback:
+it will be used to restore the database at the next ejabberd start.
+Similar to restore, but requires less memory.
+
    dump ejabberd.dump
    
+Dump internal Mnesia database to a text file dump.
+
    load ejabberd.dump
    
+Restore immediately from a text file dump.
+This is not recommended for big databases, as it will consume much time,
+memory and processor. In that case it’s preferable to use backup and install-fallback.
+
    import-file, import-dir
     
+These options can be used to migrate from other Jabber/XMPP servers. There
+exist tutorials to migrate from other software to ejabberd.
+
    delete-expired-messages
     This option can be used to delete old messages
+in offline storage. This might be useful when the number of offline messages
+is very high.
+
      
    
+
    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:
+
    AccessCommands = [ {Access, CommandNames, Arguments} ]
+Access = atom()
+CommandNames = all | [CommandName]
+CommandName = atom()
+Arguments = [{ArgumentName, ArgumentValue}]
+ArgumentName = atom()
+ArgumentValue = any()
+
    The default value is to not define any restriction: [].
+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
+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.
+It is possible to provide the plaintext password or its MD5 sum.
    When one or several access restrictions are defined and the
+authentication information is provided,
+each restriction is verified until one matches completely:
+the account matches the Access rule,
+the command name is listed in CommandNames,
+and the provided arguments do not contradict Arguments.
    As an example to understand the syntax, let’s suppose those options:
+
    {hosts, ["example.org"]}.
+{acl, bots, {user, "robot1", "example.org"}}.
+{access, commaccess, [{allow, bots}]}.
+
    This list of access restrictions allows only robot1@example.org to execute all commands:
+
    [{commaccess, all, []}]
+
    See another list of restrictions (the corresponding ACL and ACCESS are not shown):
+
    [
+ %% This bot can execute all commands:
+ {bot, all, []},
+ %% This bot can only execute the command 'dump'. No argument restriction:
+ {bot_backups, [dump], []}
+ %% This bot can execute all commands,
+ %% but if a 'host' argument is provided, it must be "example.org":
+ {bot_all_example, all, [{host, "example.org"}]},
+ %% This bot can only execute the command 'register',
+ %% and if argument 'host' is provided, it must be "example.org":
+ {bot_reg_example, [register], [{host, "example.org"}]},
+ %% This bot can execute the commands 'register' and 'unregister',
+ %% if argument host is provided, it must be "test.org":
+ {_bot_reg_test, [register, unregister], [{host, "test.org"}]}
+]
+
      
    
+
    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
@@ -3143,13 +3241,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.3  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.4  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.
@@ -3165,8 +3263,8 @@ you must follow these instructions:
 	For example:
 
    ejabberdctl restore /tmp/ejabberd-oldhost.backup
 
    •   
    
-
    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:
 
    
 
@@ -3177,7 +3275,7 @@ you must follow these instructions:
 
    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.
@@ -3202,7 +3300,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.
@@ -3216,7 +3314,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
@@ -3225,7 +3323,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
    
@@ -3245,9 +3343,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
@@ -3261,29 +3359,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. 
@@ -3321,10 +3419,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:
 
    • 
@@ -3333,13 +3431,13 @@ 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 the following:
 
      {domain_balancing_component_number, "component.example.com", N}
 
        
      
-
      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
 	
      sasl.log
       is the Erlang/OTP system log, with the messages reported by Erlang/OTP using SASL (System Architecture Support Libraries)
@@ -3357,16 +3455,16 @@ For example, the default configuration is:
 
      {loglevel, 4}.
 
      The log files grow continually, so it is recommended to rotate them periodically.
 To rotate the log files, rename the files and then reopen them.
-The ejabberd command reopen-log 
-(please refer to section 4.1.1)
+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,
@@ -3384,7 +3482,7 @@ or in a conversation with the watchdog alert bot.
      Example configuration:
 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
@@ -3419,9 +3517,9 @@ HTTP header ‘Accept-Language: ru’
 
 
 
        
      
-
      Appendix B  Release Notes
        
+
      Appendix B  Release Notes
        
 
      Release notes are available from ejabberd Home Page
        
      
-
      Appendix C  Acknowledgements
        
      Thanks to all people who contributed to this guide:
+
      Appendix C  Acknowledgements
        
      Thanks to all people who contributed to this guide:
 
        
      
-
      Appendix D  Copyright Information
        
      Ejabberd Installation and Operation Guide.
      
+
      Appendix D  Copyright Information
        
      Ejabberd Installation and Operation Guide.
      
 Copyright © 2003 — 2009 ProcessOne
      This document is free software; you can redistribute it and/or
 modify it under the terms of the GNU General Public License
 as published by the Free Software Foundation; either version 2
diff --git a/doc/guide.tex b/doc/guide.tex
index 31481c1ef..0f691af9a 100644
--- a/doc/guide.tex
+++ b/doc/guide.tex
@@ -3809,10 +3809,24 @@ Options:
 
 \makesection{ejabberdctl}{\term{ejabberdctl}}
 
-\makesubsection{commands}{Commands}
+With the \term{ejabberdctl} command line administration script 
+you can execute \term{ejabberdctl commands} (described in the next section, \ref{ectl-commands})
+and also many general \term{ejabberd commands} (described in section \ref{eja-commands}).
+This means you can start, stop and perform many other administrative tasks
+in a local or remote \ejabberd{} server (by providing the argument \term{--node NODENAME}).
 
-The \term{ejabberdctl} command line administration script allows to start, stop and perform
-many other administrative tasks in a local or remote \ejabberd{} server.
+The \term{ejabberdctl} script can be configured in the file \term{ejabberdctl.cfg}.
+This file includes detailed information about each configurable option. See section \ref{erlangconfiguration}.
+
+The \term{ejabberdctl} script returns a numerical status code.
+Success is represented by \term{0},
+error is represented by \term{1},
+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: \term{echo \$?}
+
+\makesubsection{ectl-commands}{ejabberdctl Commands}
 
 When \term{ejabberdctl} is executed without any parameter,
 it displays the available options. If there isn't an \ejabberd{} server running,
@@ -3824,53 +3838,44 @@ the available parameters are:
 \end{description}
 
 If there is an \ejabberd{} server running in the system,
-\term{ejabberdctl} shows all the available commands in that server.
-The more interesting ones are:
+\term{ejabberdctl} shows the \term{ejabberdctl commands} described bellow
+and all the \term{ejabberd commands} available in that server (see \ref{list-eja-commands}).
+
+The \term{ejabberdctl commands} are:
 \begin{description}
 \titem{help} Get help about ejabberdctl or any available command. Try \term{ejabberdctl help help}.
 \titem{status} Check the status of the \ejabberd{} server.
-\titem{stop} Stop the \ejabberd{} server which is running in the machine.
-\titem{reopen-log} Reopen the log files after they were renamed.
-  If the old files were not renamed before calling this command,
-  they are automatically renamed to \term{"*-old.log"}. See section \ref{logfiles}.
-\titem {backup ejabberd.backup}
-  Store internal Mnesia database to a binary backup file.
-\titem {restore ejabberd.backup}
-  Restore immediately from a binary backup file the internal Mnesia database.
-  This will consume quite some memory for big servers.
-\titem {install-fallback ejabberd.backup}
-  The binary backup file is installed as fallback:
-  it will be used to restore the database at the next ejabberd start.
-  Similar to \term{restore}, but requires less memory.
-\titem {dump ejabberd.dump}
-  Dump internal Mnesia database to a text file dump.
-\titem {load ejabberd.dump}
-  Restore immediately from a text file dump.
-  This is not recommended for big databases, as it will consume much time,
-  memory and processor. In that case it's preferable to use \term{backup} and \term{install-fallback}.
-%%More information about backuping can
-%%  be found in section~\ref{backup}.
-\titem{import-file, import-dir} \ind{migration from other software}
-  These options can be used to migrate from other \Jabber{}/XMPP servers. There
-  exist tutorials to \footahref{http://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
-  in offline storage. This might be useful when the number of offline messages
-  is very high.
+\titem{stop} Stop the \ejabberd{} server.
+\titem{restart} Restart the \ejabberd{} server.
+\titem{mnesia} Get information about the Mnesia database.
 \end{description}
 
-The \term{ejabberdctl} script also allows the argument \term{--node NODENAME}.
-This allows to administer a remote node.
+The \term{ejabberdctl} script can be restricted to require authentication
+and execute some \term{ejabberd commands}; see \ref{accesscommands}.
+Add the option to the file \term{ejabberd.cfg}.
+In this example there is no restriction:
+\begin{verbatim}
+{ejabberdctl_access_commands, []}.
+\end{verbatim}
 
-The \term{ejabberdctl} script can be configured in the file \term{ejabberdctl.cfg}.
-This file includes detailed information about each configurable option.
-
-The \term{ejabberdctl} script returns a numerical status code.
-Success is represented by \term{0},
-error is represented by \term{1},
-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: \term{echo \$?}
+If account \term{robot1@example.org} is registered in \ejabberd{} with password \term{abcdef}
+(which MD5 is E8B501798950FC58AAD83C8C14978E),
+and \term{ejabberd.cfg} contains this setting:
+\begin{verbatim}
+{hosts, ["example.org"]}.
+{acl, bots, {user, "robot1", "example.org"}}.
+{access, ctlaccess, [{allow, bots}]}.
+{ejabberdctl_access_commands, [ {ctlaccess, [registered_users, register], []} ]}.
+\end{verbatim}
+then you can do this in the shell:
+\begin{verbatim}
+$ ejabberdctl registered_users example.org
+Error: no_auth_provided
+$ ejabberdctl --auth robot1 example.org E8B501798950FC58AAD83C8C14978E registered_users example.org
+robot1
+testuser1
+testuser2
+\end{verbatim}
 
 
 \makesubsection{erlangconfiguration}{Erlang Runtime System}
@@ -3949,6 +3954,131 @@ The command line parameters:
 Note that some characters need to be escaped when used in shell scripts, for instance \verb|"| and \verb|{}|.
 You can find other options in the Erlang manual page (\shell{erl -man erl}).
 
+\makesection{eja-commands}{\ejabberd{} Commands}
+
+An \term{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 \term{ejabberd\_commands} service.
+Those commands can be defined in any Erlang module and executed using any valid frontend.
+
+\ejabberd{} includes a frontend to execute \term{ejabberd commands}: the script \term{ejabberdctl}.
+Other known frontends that can be installed to execute ejabberd commands in different ways are:
+\term{ejabberd\_xmlrpc} (XML-RPC service),
+\term{mod\_rest} (HTTP POST service),
+\term{mod\_shcommands} (ejabberd WebAdmin page).
+
+\makesubsection{list-eja-commands}{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:
+\begin{verbatim}
+$ ejabberdctl help
+Usage: ejabberdctl [--node nodename] [--auth user host password] command [options]
+
+Available commands in this ejabberd node:
+  backup file                  Store the database to backup file
+  connected_users              List all established sessions
+  connected_users_number       Get the number of established sessions
+  delete_expired_messages      Delete expired offline messages from database
+  delete_old_messages days     Delete offline messages older than DAYS
+  ...
+\end{verbatim}
+
+The more interesting ones are:
+\begin{description}
+\titem{reopen-log} Reopen the log files after they were renamed.
+  If the old files were not renamed before calling this command,
+  they are automatically renamed to \term{"*-old.log"}. See section \ref{logfiles}.
+\titem {backup ejabberd.backup}
+  Store internal Mnesia database to a binary backup file.
+\titem {restore ejabberd.backup}
+  Restore immediately from a binary backup file the internal Mnesia database.
+  This will consume quite some memory for big servers.
+\titem {install-fallback ejabberd.backup}
+  The binary backup file is installed as fallback:
+  it will be used to restore the database at the next ejabberd start.
+  Similar to \term{restore}, but requires less memory.
+\titem {dump ejabberd.dump}
+  Dump internal Mnesia database to a text file dump.
+\titem {load ejabberd.dump}
+  Restore immediately from a text file dump.
+  This is not recommended for big databases, as it will consume much time,
+  memory and processor. In that case it's preferable to use \term{backup} and \term{install-fallback}.
+%%More information about backuping can
+%%  be found in section~\ref{backup}.
+\titem{import-file, import-dir} \ind{migration from other software}
+  These options can be used to migrate from other \Jabber{}/XMPP servers. There
+  exist tutorials to \footahref{http://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
+  in offline storage. This might be useful when the number of offline messages
+  is very high.
+\end{description}
+
+\makesubsection{accesscommands}{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 \term{AccessCommands} option is defined
+in a different place. But in all cases the option syntax is the same:
+\begin{verbatim}
+AccessCommands = [ {Access, CommandNames, Arguments} ]
+Access = atom()
+CommandNames = all | [CommandName]
+CommandName = atom()
+Arguments = [{ArgumentName, ArgumentValue}]
+ArgumentName = atom()
+ArgumentValue = any()
+\end{verbatim}
+
+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
+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.
+It is possible to provide the plaintext password or its MD5 sum.
+
+When one or several access restrictions are defined and the
+authentication information is provided,
+each restriction is verified until one matches completely:
+the account matches the Access rule,
+the command name is listed in CommandNames,
+and the provided arguments do not contradict Arguments.
+
+As an example to understand the syntax, let's suppose those options:
+\begin{verbatim}
+{hosts, ["example.org"]}.
+{acl, bots, {user, "robot1", "example.org"}}.
+{access, commaccess, [{allow, bots}]}.
+\end{verbatim}
+
+This list of access restrictions allows only \term{robot1@example.org} to execute all commands:
+\begin{verbatim}
+[{commaccess, all, []}]
+\end{verbatim}
+
+See another list of restrictions (the corresponding ACL and ACCESS are not shown):
+\begin{verbatim}
+[
+ %% This bot can execute all commands:
+ {bot, all, []},
+ %% This bot can only execute the command 'dump'. No argument restriction:
+ {bot_backups, [dump], []}
+ %% This bot can execute all commands,
+ %% but if a 'host' argument is provided, it must be "example.org":
+ {bot_all_example, all, [{host, "example.org"}]},
+ %% This bot can only execute the command 'register',
+ %% and if argument 'host' is provided, it must be "example.org":
+ {bot_reg_example, [register], [{host, "example.org"}]},
+ %% This bot can execute the commands 'register' and 'unregister',
+ %% if argument host is provided, it must be "test.org":
+ {_bot_reg_test, [register, unregister], [{host, "test.org"}]}
+]
+\end{verbatim}
 
 \makesection{webadmin}{Web Admin}
 \ind{web admin}
@@ -4408,8 +4538,8 @@ For example, the default configuration is:
 
 The log files grow continually, so it is recommended to rotate them periodically.
 To rotate the log files, rename the files and then reopen them.
-The ejabberd command \term{reopen-log} 
-(please refer to section \ref{commands})
+The ejabberdctl command \term{reopen-log} 
+(please refer to section \ref{ectl-commands})
 reopens the log files,
 and also renames the old ones if you didn't rename them.