The sm.xml file configures the session manager component of Jabberd 2. The session manager acts as a layer between the router and the externally available components — s2s and c2s. The sm.xml file configures the following functions:
Below is an overview of the settings in the sm.xml file.
The first two sections of sm.xml specify the ID on the network and the PID file to write. The id section is important because it is this ID that becomes appended to user names to form a JID (Jabber Identification). For most installations, id will be the hostname — something like somedomain.com. This ID must be resolvable via DNS if the server is to communicate with other Jabber servers; therefore, it need not be resolvable for closed or local Jabberd systems. An IP address may be used as the 'id'; however, because an IP address is not resolvable via DNS, a system based on an IP address ID would not be able to communicate with other Jabber servers.
The pid section specifies the location of the PID file. This may be commented out if a PID file is not needed.
The router section controls communication with the router component. The default ip and port should be fine for most installations, although note that if the session manager is running on a separate server, an external IP address would be specified here.
The user and pass sub-sections specify the user name for connecting to the router. These must match against a pair specified in router-users.xml as explained in Section 9. Basic security procedures dictate that the default password should be changed for production systems.
The pemfile section specifies the certificate and private key to be used for communication with the router. 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 the session manager and router.
The retry section specifies how the session manager should try to reconnect to the router if the connection cannot be established during startup or if the connection is lost during operation. The default settings prevent the session manager from indefinitely attempting to reconnect if this connection cannot be made. These default settings will essentially cause the session manager to die if the router dies or is killed.
Jabberd logging defaults to the syslog. If you prefer the session manager to write its own log file, change the log type to file, and specify a location for the log.
The session manager handles the database connection referred to in this guide as the application data package (as opposed to the authentication data package). You need to edit only the sub-section applicable to your choice of application data package (MySQL, PostgreSQL or Berkeley DB). For database packages running on the same server as the session manager you should need to edit only the password used to connect to the database (this is not necessary for Berkeley DB). Change the host for databases running on separate machines. Note that the default password (secret) should not be used on production machines.
The acl section controls which users have access to administrative functions. Among these functions are broadcast, messages and discovery. Note that specification of an administrative user in this section does not cause that user to be created in the authentication (authreg) database. Thus, you must register a user separately. Section 7.4 describes how to use an administrative account to send messages to all users.
Administrative functions currently have only minimal support in Jabber clients; however, the JAJC client for Windows supports the administration functions discovery of online users and messages to online users.
The modules section controls module chains that are called by specific events. Events are defined in terms of receipt or delivery of a type of packet. These module chains should be edited only by experienced Jabberd administrators. Of note are the chains that are called during user creation (user-create) and user deletion (user-delete).
The discovery section contains both standard service information for instant messaging (the identity sub-section) in addition to settings for static discovery settings for legacy components (the items sub-section). If your server is running legacy components, such as JUD, MU Conferencing, MSN-T or Aimtrans, you should complete an item sub-section if the component does not support disco (discovery). Follow the examples shown in this section to add an item for static discovery for your legacy components.
The user section specifies templates that should be added to a user's data store when the user is created, and this section also specifies whether non-existent user should be created when that user logs in. This option allows an administrator to add users to the authentication database (authreg) and then have those users be created the first time they log in.
© 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.