<!-- Session manager configuration --> <sm> <!-- Our ID on the network. Users will have this as the domain part of their JID. If you want your server to be accessible from other Jabber servers, this ID must be resolvable by DNS.s (default: localhost) --> <id>@HOSTNAME@</id> <!-- The process ID file. comment this out if you don't need to know to know the process ID from outside the process (eg for control scripts) --> <pidfile>/var/run/jabberd/sm.pid</pidfile> <!-- Router connection configuration --> <router> <!-- IP/port the router is waiting for connections on --> <ip>127.0.0.1</ip> <!-- default: 127.0.0.1 --> <port>5347</port> <!-- default: 5347 --> <!-- Username/password to authenticate as --> <user>jabberd</user> <!-- default: jabberd --> <pass>@ROUTERPASSWORD@</pass> <!-- default: secret --> <!-- File containing a SSL certificate and private key to use when setting up an encrypted channel with the router. If this is commented out, or the file can't be read, no attempt will be made to establish an encrypted channel with the router. --> <pemfile>/etc/certificates/Default.crtkey</pemfile> <!-- Router connection retry --> <retry> <!-- If the connection to the router can't be established at startup, we should try again this many times before exiting. Use -1 to retry indefinitely. [default: 3] --> <init>3</init> <!-- If we lost the connection to the router during normal operation (ie we've successfully connected to the router in the past), we should try to reconnect this many times before exiting. Use -1 to retry indefinitely. [default: 3] --> <lost>3</lost> <!-- Sleep for this many seconds before trying attempting a reconnect. [default: 2] --> <sleep>2</sleep> </retry> </router> <!-- Log configuration - type is "syslog", "file" or "stdout" --> <log type='syslog'> <!-- If logging to syslog, this is the log ident --> <ident>jabberd/sm</ident> <!-- If logging to syslog, this is the log facility (local0 - local7) [default: local3] --> <facility>local3</facility> <!-- If logging to file, this is the filename of the logfile --> <!-- <file>/usr/var/jabberd/log/sm.log</file> --> </log> <!-- Storage database configuration --> <storage> <!-- By default, we use the MySQL driver for all storage --> <driver>sqlite</driver> <!-- Its also possible to explicitly list alternate drivers for specific data types. --> <!-- Store vcards in a PostgreSQL database instead --> <!-- <driver type='vcard'>pgsql</driver> --> <!-- MySQL driver configuration --> <mysql> <!-- Database server host and port --> <host>127.0.0.1</host> <port>3308</port> <!-- Database name --> <dbname>jabberd2</dbname> <!-- Database username and password --> <user>jabber</user> <pass>@MYSQLPASSWORD@</pass> <!-- Transacation support. If this is commented out, transactions will be disabled. This might make database accesses faster, but data may be lost if jabberd crashes. This will need to be disabled if you are using a MySQL earlier than v3.23.xx, as transaction support did not appear until this version. --> <transactions/> </mysql> <!-- PostgreSQL driver configuration --> <pgsql> <!-- Database server host and port --> <host>localhost</host> <port>5432</port> <!-- Database name --> <dbname>jabberd2</dbname> <!-- Database username and password --> <user>jabberd2</user> <pass>secret</pass> <!-- Transacation support. If this is commented out, transactions will be disabled. This might make database accesses faster, but data may be lost if jabberd crashes. --> <transactions/> </pgsql> <!-- Berkeley DB driver configuration --> <db> <!-- Directory to store database files under --> <path>/usr/var/jabberd/db</path> <!-- Synchronize the database to disk after each write. If you disable this, database accesses may be faster, but data may be lost if jabberd crashes. --> <sync/> </db> <!-- Oracle driver configuration --> <oracle> <!-- Database server host and port. --> <host>localhost</host> <port>1521</port> <!-- Database name --> <dbname>jabberd2</dbname> <!-- Database username and password --> <user>jabberd2</user> <pass>secret</pass> </oracle> <!-- SQLite driver configuration --> <sqlite> <!-- Database file location --> <dbname>/private/var/jabberd/sqlite/jabberd2.db</dbname> <!-- Enable transactions --> <transactions>1</transactions> <!-- Busy timeout (ms) --> <busy-timeout>10000</busy-timeout> </sqlite> </storage> <!-- Access control information --> <aci> <!-- The JIDs listed here will get access to all restricted functions, regardless of restrictions further down --> <!-- <acl type='all'> <jid>admin@localhost</jid> </acl> --> <!-- These JIDs can send broadcast messages (announce, motd) --> <!-- <acl type='broadcast'> <jid>nocstaff1@localhost</jid> <jid>nocstaff2@localhost</jid> </acl> --> <!-- These JIDs will receive messages addressed to the sm itself (help requestes and such) --> <!-- <acl type='messages'> <jid>support@localhost</jid> </acl> --> <!-- These JIDs can discover active user/session information --> <!-- <acl type='disco'> <jid>webstatus@localhost</jid> </acl> --> </aci> <!-- Module chain configuration Modules listed in a chain are called in the order specified at the appropriate time for that chain (assuming that the module knows how to work with that chain; otherwise it simply ignores it). Removing a module from these lists will stop the module being called, even if its compiled into the server. Serveral modules have a presence in more than one chain. It is possible to remove a module from one chain but not others, but this may cause strange behaviour. Make sure you know what you're doing. --> <modules> <!-- sess-start. The modules in this chain are called when a session is first started (usually on request by c2s as part of the authentication process). This is normally used to load per-session data. --> <chain id='sess-start'/> <!-- sess-end. The modules in this chain are called just before a session is destroyed (after the client has disconnected). --> <chain id='sess-end'> <module>iq-last</module> <!-- update logout time --> </chain> <!-- in-sess. The modules in this chain are called when a packet arrives from an active user session. Note that this chain is also responsible for delivering packets to their destinations - this is usually handled by the "deliver" module. --> <chain id='in-sess'> <module>validate</module> <!-- validate packet type --> <module>privacy</module> <!-- manage privacy lists --> <module>roster</module> <!-- handle roster get/sets and s10ns --> <module>vacation</module> <!-- manage vacation settings --> <module>iq-vcard</module> <!-- store and retrieve the user's vcard --> <module>iq-private</module> <!-- manage the user's private data store --> <module>disco</module> <!-- respond to agents requests from sessions --> <module>offline</module> <!-- if we're coming online for the first time, deliver queued messages --> <module>announce</module> <!-- deliver motd --> <module>presence</module> <!-- process and distribute presence updates --> <module>deliver</module> <!-- deliver packets with full jids directly --> </chain> <!-- out-sess. The modules in this chain are called just before a packet is delivered to an active user session. --> <chain id='out-sess'/> <!-- in-router. The modules in this chain are called when a packet arrives from the router (ie another component or s2s), but before any processing is done. This is a good place to filter incoming packets. --> <chain id='in-router'> <module>session</module> <!-- perform session actions as required by c2s --> <module>validate</module> <!-- validate packet type --> <module>presence</module> <!-- drop incoming presence if user not online --> <module>privacy</module> <!-- filter incoming packets based on privacy rules --> </chain> <!-- out-router. The modules in this chain are called just before a packet is delivered to the router (destined for another component or s2s). This is a good place to filter outgoing packets. --> <chain id='out-router'> <module>privacy</module> <!-- filter outgoing packets based on privacy rules --> </chain> <!-- pkt-sm. The modules in this chain are called when a packet arrives that is addressed to the session manager itself (ie the to JID has no node part). This is normally used to provide session-manager-wide services (like service discovery). --> <chain id='pkt-sm'> <module>iq-last</module> <!-- return the server uptime --> <module>iq-time</module> <!-- return the current server time --> <module>iq-version</module> <!-- return the server name and version --> <module>disco</module> <!-- build the disco list; respond to disco queries --> <module>announce</module> <!-- send broadcast messages (announce, motd, etc) --> <module>help</module> <!-- resend sm messages to administrators --> <module>echo</module> <!-- echo messages sent to /echo --> </chain> <!-- pkt-user. The modules in this chain are called when a packet arrives that is address to a specific user. Note that this chain is also responsible for delivering packets to user sessions as appropriate - this is usually handled by the "deliver" module. --> <chain id='pkt-user'> <module>roster</module> <!-- handle s10n responses --> <module>presence</module> <!-- process and distribute incoming presence from external entities --> <module>iq-vcard</module> <!-- grab user vcards --> <module>deliver</module> <!-- deliver the packet to an active session if we can --> <module>vacation</module> <!-- send vacation messages --> <module>offline</module> <!-- save messages and s10ns for later --> <module>disco-publish</module> <!-- handle disco publishes; return information about user sessions --> <module>iq-last</module> <!-- return time since last logout --> </chain> <!-- pkt-router. The modules in this chain are called when a special-purpose packet arrives from the router (eg domain advertisements). --> <chain id='pkt-router'> <module>session</module> <!-- take sessions offline their c2s disappears --> <module>disco</module> <!-- query new components for service information --> </chain> <!-- user-load. The modules in this chain are called to load per-user data. This will happen before a user can be used (ie before a session is created). --> <chain id='user-load'> <module>active</module> <!-- get active status --> <module>roster</module> <!-- load the roster and trust list --> <module>privacy</module> <!-- load privacy lists --> <module>disco-publish</module> <!-- load published information --> <module>vacation</module> <!-- load vacation settings --> </chain> <!-- user-create. The modules in this chain are called when a user creation request is received (usually from c2s as part of a registration request). This initialises any per-user data. --> <chain id='user-create'> <module>active</module> <!-- activate new users --> <module>template-roster</module> <!-- populate roster from template --> </chain> <!-- user-delete. The modules in this chain are called when a user deletion request is received (usually from c2s as part of a registration removal request). This deletes all data that may have been previously created for the user during normal operation. --> <chain id='user-delete'> <module>active</module> <!-- deactivate users --> <module>announce</module> <!-- delete motd data --> <module>disco-publish</module> <!-- delete published information --> <module>offline</module> <!-- bounce queued messages --> <module>privacy</module> <!-- delete privacy lists --> <module>roster</module> <!-- delete roster --> <module>vacation</module> <!-- delete vacation settings --> <module>iq-last</module> <!-- delete last logout time --> <module>iq-private</module> <!-- delete private data --> <module>iq-vcard</module> <!-- delete vcard --> </chain> </modules> <!-- Service discovery configuration --> <discovery> <!-- Service identity. these specify the category, type and name of this service that will be included in discovery information responses. --> <identity> <category>server</category> <!-- default: server --> <type>im</type> <!-- default: im --> <name>Jabber IM server</name> <!-- default: Jabber IM server --> </identity> <!-- The discovery module can respond to jabber:iq:agents queries for compatibility with older clients. Comment this out to disable this. --> <agents/> <!-- Static service list. The discover module can discover disco-capable services automatically as they come online. Most legacy services, however, will not support discovery. In order to get them to appear in disco/agents lists returned to the client, they should be listed here. Note that if a disco-capable service with the same name as one listed below comes online, the information it provides will override the information listed below. The "category" and "type" attributes, and the list of supported namespaces are only used for agents compatibility. If you have disabled this above, you may omit them. --> <items> <!-- example entry for a user directory --> <!-- <item category='service' type='jud' jid='users.jabber.org' name='Jabber User Directory'/> --> <!-- example entry for a groupchat (conference) service --> <!-- <item category='conference' type='public' jid='conference.jabber.org' name='Text conferencing'/> --> </items> </discovery> <!-- User options --> <user> <!-- By default, users must explicitly created before they can start a session. The creation process is usually triggered by a c2s component in response to a client registering a new user. Enableing this option will make it so that a user create will be triggered the first time a non-existant user attempts to start a session. This is useful if you already have users in an external authentication database (eg LDAP) and you don't want them to have to register. --> <auto-create/> <!-- Templates. If defined, the contents of these files will be stored in the users data store when they are created. --> <template> <!-- <roster>/usr/local/etc/jabberd/templates/roster.xml</roster> --> </template> </user> </sm>