Jabberd 2 Documentation Project
Jabberd 2 Documentation Project
|
The router.xml file provides configuration for the
router component, which is the backbone of the Jabberd server. The
router component accepts connections from other components, and it passes
XML packets between them. The router.xml file contains these
primary sections:
As readers are probably aware, the Jabberd XML files are self-documenting. This and subsequent configuration sections attempt merely to provide an overview of the structure of these files in addition to tips not found in the files themselves.
The first three subsections of router.xml handle basic
housekeeping items. For nearly all installations, the id
section should be kept as default (router). The
pid section specifies where the router component
should write its process ID. If you do not need to be able to read the
process ID from outside of Jabberd, you may comment this section out. For
example, if you were to use D.J. Bernstein's DaemonTools to run Jabberd,
you would comment the pid section.
Jabberd logging defaults to the syslog. If you prefer the
router to write to its own log file, change the log
type to file, and specify a location for the log.
The local subsection handles network and connection settings
for the router. The ip and port tags
specify the network settings.
0.0.0.0 Specifies All Available
IP's
0.0.0.0 specifies that the component should listen on all
available IP addresses. 0.0.0.0 is the default setting for
IP addresses, and keeping this default setting should be fine for most
installations.
The users tag specifies the file containing user ID's and
passwords for users that can access the router. See the next
section for a description of this file.
The secret tags specify a shared secret for legacy services.
Legacy services are authenticated via this shared secret, as opposed to
being authenticated against the user list in the
router-users.xml file. This secret is tantamount to
the shared secret specified for Jabberd 1.4 linked configuration files. See
Section 5.8 and 5.9 for information on
setting up legacy services.
The pemfile location specifies the location of the certificate
and private key for client communications. Note that in this instance,
client refers to clients of the router, and not end-user
Jabber clients. That is to say, the pemfile specified here is used
to secure communications between other Jabberd components and the
router itself. See Section 5.2
and Appendix: Generating A Self-Signed SSL
Key for more information about setting up SSL on Jabberd. Commenting
this section has the effect of disabling SSL communication between Jabberd
components.
The i/o section controls the following input/output options:
Note that the default settings for these subsections should be fine for most installations.
Jabberd sets a limit on the number of connections via the
max_fds (maximum file descriptors) setting. Jabberd uses a
file descriptor for each connection. Thus, setting a maximum number of file
descriptors for the router has the effect of limiting the number of
concurrent connections for the Jabberd server. As the
router.xml file notes, the router itself can use up
to 4 connections (with other Jabberd components); therefore, the maximum
number of file descriptors set here is actually slightly greater than the
number of potential concurrent connections.
The limits subsection dictates throttling for individual
connections. This section is tantamount to a simplified karma
setup as found in Jabberd 1.4. The default for both bytes and
connects is 0. Thus, these limits are disabled by
default. Administrators of servers under heavy load may wish to set limits
here to prevent users from controlling excessive server resources. The
router.xml file contains examples for setting rate limiting on
connections.
The access subsection specifies IP addresses that should be
allowed or denied access to the router. IP addresses denied access
to the router cannot have their packets handled and are thus
denied access to Jabberd server functions.
The order subsection specifies the order of rule checking
(checking of allow rules then deny rules versus checking of deny rules then
allow rules). IP restrictions are set using either an allow or
a deny tag below the order within the
access subsection. Omission of both a deny and allow rule
causes all connections to be accepted — as is the default setting.
The aliases section provides support for linked legacy
services, such as MU Conference and JUD. These legacy services connect
directly to the router via linked configuration. Each
alias specifies the resolvable name for the
component and the target specifies the service id
as specified in the linked component XML file. See Section 6.5 for more information about linking legacy
services.
The aci section specifies the type of access for each user
specified in router-users.xml. By default, the
jabberd user is granted all access because the other Jabberd
components connect to the router as the Jabberd user.
Of special note in this section is the example of a user with the 'acl type
= 'log''. Such a user would be able to receive all packets that pass
through the router, and thus, all packets handled by the Jabberd server.
Although Jabberd does not have a facility for logging all packets, such a facility could be easily provided by specifying a user with 'acl = 'log'' permissions and creating a component that would connect to the router as this user. Such a component would then be able to log all Jabberd packets.
|
|
|
|
||||
|
|
||||
|
© 2003 Will Kamishlian and Robert Norris
|
||||
|
|
||||
| This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/1.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA. | ||||
|
|
||||
|
|
 |
||