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
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
section should be kept as default (
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
Jabberd logging defaults to the
syslog. If you prefer the
router to write to its own log file, change the
file, and specify a location for the log.
local subsection handles network and connection settings
for the router. The
specify the network settings.
0.0.0.0Specifies All Available IP's
0.0.0.0specifies that the component should listen on all available IP addresses.
0.0.0.0is the default setting for IP addresses, and keeping this default setting should be fine for most installations.
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.
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.
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
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.
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
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
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.
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
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.
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
as specified in the linked component XML file. See Section 6.5 for more information about linking legacy
aci section specifies the type of access for each user
router-users.xml. By default, the
jabberd user is granted all access because the other Jabberd
components connect to the router as the
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.|