From d563284ade9ccb916251642bdbccf3856b5d6b2f Mon Sep 17 00:00:00 2001 From: Alexey Shchepin Date: Tue, 11 Feb 2003 18:09:14 +0000 Subject: *** empty log message *** SVN Revision: 70 --- doc/guide.html | 229 +++++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 148 insertions(+), 81 deletions(-) (limited to 'doc/guide.html') diff --git a/doc/guide.html b/doc/guide.html index 91582eda1..ed721228e 100644 --- a/doc/guide.html +++ b/doc/guide.html @@ -21,7 +21,7 @@ mailto:alexey@sevcom.net
xmpp:aleksey@jabber.ru -

February 3, 2003

+

February 11, 2003

@@ -30,24 +30,86 @@
-
-
+ + +

Table of Contents

+ + +

1  Introduction

-ejabberd is a Free and Open Source distributed fault-tolerant Jabber +ejabberd is a Free and Open Source fault-tolerant distributed Jabber server. It is writen mostly in Erlang.

-Main features of ejabberd is: +The main features of ejabberd is:
  • -Distributed. You can run ejabberd on a cluster of machines and - all of them will serve one Jabber domain. -
  • Fault-tolerance. You can setup an ejabberd cluster so that all +Distributed: You may run ejabberd on a cluster of machines and all of + them will serve one Jabber domain. +
  • Fault-tolerance: You may setup an ejabberd cluster so that all the information required for a properly working service will be stored - permanently on more then one node. This means that if one of the - nodes crashed, then the others continue working without disruption. + permanently on more then one node. This means that if one of the nodes + crashes, then the others will continue working without disruption. You can also add or replace more nodes ``on the fly''.
  • Support for JEP-0030 @@ -68,7 +130,7 @@ Distributed. You can run ejabberd on a cluster of machines and

    2.1  Installation Requirements

    -To compile ejabberd, you need following packages: +To compile ejabberd, you will need the following packages:
    • GNU Make;
    • GCC; @@ -82,7 +144,7 @@ GNU Make; Currently no stable version has been released.

      -The latest alpha version can be retrieved via CVS. Do following steps: +The latest alpha version can be retrieved from CVS.
      • export CVSROOT=:pserver:cvs@www.jabber.ru:/var/spool/cvs
      • cvs login @@ -105,7 +167,7 @@ TBD

        2.4  Starting

        -... To use more then 1024 connections, you need to set environment +... To use more then 1024 connections, you will need to set environment variable ERL_MAX_PORTS: 
         export ERL_MAX_PORTS=32000
@@ -126,15 +188,17 @@ TBD
        
 
        3.1  Initial Configuration
        
 
 
-Configuration file is loaded after first start of ejabberd. It consists of
-sequence of Erlang terms. Parts of lines after `%' sign are ignored.
-Each term is tuple, where first element is name of option, and other are option
-values. Note, that after first start all values from this file stored in
-database, and in next time they will be APPENDED to existing values. E. g.
-if this file will not contain ``host'' definition, then old value will be
-used.
        
+The configuration file is initially loaded the first time ejabberd is
+executed, when it is parsed and stored in a database. Subsiquently the
+configuration is loaded from the database and any commands in the configuration
+file are appended to the entries in the database. The configuration file
+consists of a sequence of Erlang terms. Parts of lines after `%' sign
+are ignored. Each term is tuple, where first element is name of option, and
+other are option values. E. g. if this file does not contain a ``host''
+definition, then old value stored in the database will be used.
        
 
        
-To override old values following lines can be added in config:
+To override old values stored in the database the following lines can be added
+in config:
 
         override_global.
 override_local.
@@ -157,8 +221,8 @@ serves. E. g. to use jabber.org domain add following line in confi
 
        3.1.2  Access Rules
        
 
 
-Access control in ejabberd is done via Access Control Lists (ACL).
-Declaration of ACL in config file have following syntax:
+Access control in ejabberd is performed via Access Control Lists (ACL). The
+declarations of ACL in config file have following syntax:
 
         {acl, <aclname>, {<acltype>, ...}}.
 
        
@@ -180,11 +244,11 @@ Declaration of ACL in config file have following syntax:
 
         {acl, jabberorg, {server, "jabber.org"}}.
 
        {user_regexp, <regexp>}
         Matches local user with name that
- mathes <regexp>. Example:
+ matches <regexp>. Example:
 
         {acl, tests, {user, "^test[0-9]*$"}}.
 
        {user_regexp, <regexp>, <server>}
         Matches user with name
- that mathes <regexp> and from server <server>. Example:
+ that matches <regexp> and from server <server>. Example:
 
         {acl, tests, {user, "^test", "localhost"}}.
 
        {server_regexp, <regexp>}
         Matches any JID from server that
@@ -192,7 +256,7 @@ Declaration of ACL in config file have following syntax:
 
         {acl, icq, {server, "^icq\\."}}.
 
        {node_regexp, <user_regexp>, <server_regexp>}
         Matches user
- with name that mathes <user_regexp> and from server that matches
+ with name that matches <user_regexp> and from server that matches
  <server_regexp>. Example:
 
         {acl, aleksey, {node_regexp, "^aleksey", "^jabber.(ru|org)$"}}.
@@ -200,8 +264,8 @@ Declaration of ACL in config file have following syntax:
 
        {user_glob, <glob>, <server>}
        
 
        {server_glob, <glob>}
        
 
        {node_glob, <user_glob>, <server_glob>}
         This is same as
- above, but use shell glob patterns instead of regexp. This patterns can have
- following special characters:
+ above, but uses shell glob patterns instead of regexp. These patterns can
+ have following special characters:
  
        
  *
         matches any string including the null string.
  
        ?
         matches any single character.
@@ -211,21 +275,21 @@ Declaration of ACL in config file have following syntax:
  character not enclosed is matched.
  
        
 
-Following ACLs pre-defined:
+The following ACLs pre-defined:
 
        
 all
         Matches all JIDs.
 
        none
         Matches none JIDs.
 
        
-Allowing or denying of different services is like this:
+An entry allowing or denying different services would look similar to this:
 
         {access, <accessname>, [{allow, <aclname>},
                         {deny, <aclname>},
                         ...
                        ]}.
-
        When JID is checked to have access to <accessname>, server
-sequentially checks if this JID in one of the ACLs that are second elements in
-each tuple in list. If one of them matched, then returned first element of
-matched tuple. Else returned ``deny''.
        
+
        When a JID is checked to have access to <accessname>, the server
+sequentially checks if this JID mathes one of the ACLs that are second elements
+in each tuple in list. If it is matched, then the first element of matched
+tuple is returned else ``deny'' is returned.
        
 
        
 Example:
 
        @@ -251,7 +315,7 @@ Port number;
 
      • Function in this module that starts connection (likely will be removed);
 
      • Options to this module.
      -Currently three modules implemented: +Currently three modules are implemented:
      ejabberd_c2s
      This module serves C2S connections.

      @@ -262,12 +326,12 @@ Following options defined:
      ejabberd_s2s_in
      This module serves incoming S2S connections.
      ejabberd_service
      This module serves connections to Jabber - services (i. e. that use jabber:component:accept namespace). + services (i. e. that use the jabber:component:accept namespace). -For example, following configuration defines that C2S connections listened on -port 5222 and denied for user ``bad'', S2S on port 5269 and that -service conference.jabber.org must be connected to port 8888 with -password ``secret''. +For example, the following configuration defines that C2S connections are +listened on port 5222 and denied for user ``bad'', S2S on port 5269 +and that service conference.jabber.org must be connected to port 8888 +with a password ``secret''. 
       {acl, blocked, {user, "bad"}}.
 {access, c2s, [{deny, blocked},
@@ -283,9 +347,9 @@ password ``secret''.
 
      3.1.4  Modules
      
 
 
-Option modules defines list of modules that will be loaded after
+Option modules defines the list of modules that will be loaded after
 ejabberd startup. Each list element is a tuple where first element is a
-name of module and second is list of options to this module. See
+name of a module and second is list of options to this module. See
 section A for detailed information on each module.
      
 
      
 Example:
@@ -309,14 +373,14 @@ Example:
 
      3.2  Online Configuration and Monitoring
      
 
 
-To use facility of online reconfiguration of ejabberd needed to have
-mod_configure loaded (see section A.4). Also highly
-recommended to load mod_disco (see section A.5), because
-mod_configure highly integrates with it. Also recommended to use disco- and
-xdata-capable client
-(Tkabber
-developed synchronously with ejabberd, its CVS version use most of
-ejabberd features).
      
+To perform online reconfiguration of ejabberd you will need to have
+mod_configure loaded (see section A.4). It is also highly
+recommended to load mod_disco as well (see section A.5),
+because mod_configure is highly integrated with it. Additionally it is
+recommended to use a disco- and xdata-capable client such as
+Tkabber
+(which was developed synchronously with ejabberd, its CVS version
+supports most of ejabberd features).
      
 
      
 On disco query ejabberd returns following items:
 
      • 
@@ -339,15 +403,15 @@ Identity of server.
 
 
        3.2.1  Node config: Global Configuration
        
 
-Under this node exists following nodes:
        
+Under this node the following nodes exists:
        
 
        
 
 
 
        Node config/hostname
        
 
 Via jabber:x:data queries to this node possible to change host name of
-this ejabberd server. (See figure 2) (Currently will work
-correctly only after restart)
+this ejabberd server. (See figure 2) (Currently this works
+correctly only after a restart)
 
        
  
  
@@ -362,8 +426,8 @@ correctly only after restart)
 
 
        Node config/acls
        
 
-Via jabber:x:data queries to this node possible to edit ACLs list. (See
-figure 3)
+Via jabber:x:data queries to this node it is possible to edit ACLs list.
+(See figure 3)
 
        
  
  
@@ -378,13 +442,14 @@ figure 3)
 
 
        Node config/access
        
 
-Via jabber:x:data queries to this node possible to edit access rules.
        
+Via jabber:x:data queries to this node it is possible to edit access
+rules.
        
 
        
 
 
 
        Node config/remusers
        
 
-Via jabber:x:data queries to this node possible to remove users. If
+Via jabber:x:data queries to this node it is possible to remove users. If
 removed user is online, then he will be disconnected. Also user-related data
 (e.g. his roster) is removed (but appropriate module must be loaded).
        
 
        
@@ -440,15 +505,15 @@ TBD
        
 
        4.1  How it works
        
 
 
-Jabber domain is served by one or more ejabberd nodes. This nodes can be
-runned on different machines that can be connected via network. They all must
-have access to connect to port 4369 of all another nodes, and must have same
-magic cookie (see Erlang/OTP documentation, in short file
+A Jabber domain is served by one or more ejabberd nodes. These nodes can
+be run on different machines that are connected via a network. They all must
+have the ability to connect to port 4369 of all another nodes, and must have
+the same magic cookie (see Erlang/OTP documentation, in other words the file
 ~ejabberd/.erlang.cookie must be the same on all nodes). This is
 needed because all nodes exchange information about connected users, S2S
 connections, registered services, etc...
        
 
        
-Each ejabberd node run following modules:
+Each ejabberd node must run following modules:
 
        • 
 router;
 
        • local router.
@@ -459,39 +524,41 @@ router;
 
 
          4.1.1  Router
          
 
-This module is the main router of Jabber packets on each node. It route
-them based on their destanations domains. It have two tables: local and global
+This module is the main router of Jabber packets on each node. It routes
+them based on their destinations domains. It has two tables: local and global
 routes. First, domain of packet destination searched in local table, and if it
-finded, then packet routed to appropriate process. If no, then it searched in
-global table, and routed to appropriate ejabberd node or process. If it not
-exists in both tables, then it sended to S2S manager.
          
+found, then the packet is routed to appropriate process. If no, then it
+searches in global table, and is routed to the appropriate ejabberd node or
+process. If itdoes not exists in either table, then it sent to the S2S
+manager.
          
 
          
 
 
 
          4.1.2  Local Router
          
 
-This module route packets which have destination domain equal to this server
-name. If destination JID have node, then it routed to session manager, else it
-processed depending on it content.
          
+This module routes packets which have a destination domain equal to this server
+name. If destination JID has a node, then it routed to the session manager,
+else it is processed depending on it's content.
          
 
          
 
 
 
          4.1.3  Session Manager
          
 
-This module route packets to local users. It search to what user resource
-packet must be sended via presence table. If this reseouce connected to this
-node, it routed to C2S process, if it connected via another node, then packet
-sended to session manager on it.
          
+This module routes packets to local users. It searches for what user resource
+packet must be sended via presence table. If this resource is connected to
+this node, it is routed to C2S process, if it connected via another node, then
+the packet is sent to session manager on that node.
          
 
          
 
 
 
          4.1.4  S2S Manager
          
 
-This module route packets to another Jabber servers. First, it check if
-already exists opened S2S connection from domain of packet source to domain of
-destination. If it opened on another node, then it routed to S2S manager on
-that node, if it opened on this node, then it routed to process that serve this
-connection, and if this connection not exists, then it opened and registered.
          
+This module routes packets to other Jabber servers. First, it checks if an
+open S2S connection from the domain of the packet source to the domain of
+packet destination already exists. If it is open on another node, then it
+routes the packet to S2S manager on that node, if it is open on this node, then
+it is routed to the process that serves this connection, and if a connection
+does not exist, then it is opened and registered.
          
 
          
 
 
@@ -511,8 +578,8 @@ Following options used by many modules, so they described in separate section.myjabber.org or to
-user@myjabber.org). This option defines processing discipline of this
-queries. Possible values are:
+user@myjabber.org). This option defines processing discipline of
+these queries. Possible values are:
 
          
 no_queue
           All queries of namespace with this processing
  discipline processed immediately. This also means that no other packets can
-- 
cgit v1.2.3