Jabber 2.x Installation and Configuration Guide
From The Wiki Guide
Abstract
Jabber is an open, XML-based protocol for instant messaging and presence information. Jabber-based software is deployed on thousands of servers across the Internet and is used by over ten million people worldwide, according to the Jabber Software Foundation
Contents |
Installation
In this installation we will be using Jabber 2 with a MySQL Backend and the MU-Conference plugin that will allow users to create chat rooms. If you have not installed MySQL then proceed to this guide before continuing the installation.
Jabber
cd /usr/ports/net/jabberd make config
- Options
[ ] POSTGRESQL Use PostgreSQL for storage and authentication [X] MYSQL Use MySQL for storage and authentication [ ] LDAP Use LDAP for authentication [ ] BDB Use BDB for storage and authentication [ ] SQLITE Use SQLITE3 for storage [ ] PAM Use PAM for authentication [ ] PIPE Enable pipe auth/reg support [X] DEBUG Compile with debug information
make install
MU-Conference
cd /usr/ports/net-im/mu-conference make install
Configuration
MySQL
Now we nned to create the jabberd database in MySQL.
In order to set up MySQL for Jabberd, you must run the setup script included in the Jabberd 2 distribution. After the script is run, you should create a user and then grant that user access to the database.
First, run the MySQL setup script. This script is located in '/usr/ports/net-im/jabberd/work/jabber-2.x/tools'. Switch to the tools directory and start the MySQL console (the MySQL server should already be running). Then, run the db-setup.mysql script from the MySQL console:
mysql -u root -p
mysql>\. db-setup.mysql
Now that a database for Jabberd exists in the MySQL data directory, create a MySQL user that Jabberd can use to connect to the MySQL server.
Parameter: MySQL User and Password From the MySQL console, run the SQL statement below, replacing secret with the password you have chosen for your Jabberd MySQL user:
GRANT select,insert,delete,update ON jabberd2.*
to jabberd2@localhost IDENTIFIED by 'secret';
Note that the password secret is the default password used in the Jabberd configuration files for MySQL.
MySQL is now ready to be used with Jabberd.
After the installation is completed we will need to modify some configuration files for the Jabber server to work.
cd /usr/local/etc/jabberd
The Jabber server is made up of 8 configuration files.
c2s.xml - Configures parameters from client to server side jabber.cfg - Wrapper file that links all configuration files resolver.xml - Resolver configuration file router.xml - Jabberd router configuration file router-users.xml - Configures jabber user s2s.xml - Configures parameters from server to server side sm.xml - Configures parameters for session manager muc.xml - Configures the MU-Conference plugin.
c2s.xml
<!-- c2s configuration -->
<c2s>
<!-- Our ID on the network (default: c2s) -->
<id>c2s</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/jabberd/pid/c2s.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>secret</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>/usr/local/etc/jabberd/server.pem</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/c2s</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>/var/jabberd/log/c2s.log</file>
-->
</log>
<!-- Local network configuration -->
<local>
<!-- Who we identify ourselves as. This should correspond to the
ID (host) that the session manager thinks it is. You can
specify more than one to support virtual hosts, as long as you
have additional session manager instances on the network to
handle those hosts. The realm attribute specifies the auth/reg
or SASL authentication realm for the host. If the attribute is
not specified, the realm will be selected by the SASL
mechanism, or will be the same as the ID itself. Be aware that
users are assigned to a realm, not a host, so two hosts in the
same realm will have the same users.
If no realm is specified, it will be set to be the same as the
ID. -->
<id>jabber.foo.bar</id>
<!-- <id realm='company'>localhost</id> -->
<!-- IP address to bind to (default: 0.0.0.0) -->
<ip>0.0.0.0</ip>
<!-- Port to bind to, or 0 to disable unencrypted access to the
server (default: 5222) -->
<port>5222</port>
<!-- File containing a SSL certificate and private key for client
connections. If this is commented out, clients will not be
offered the STARTTLS stream extension -->
<pemfile>/usr/local/etc/jabberd/server.pem</pemfile>
<!-- File containing an optional SSL certificate chain file for client
SSL connections. -->
<!--
<cachain>/usr/local/etc/jabberd/cachain.pem</cachain>
-->
<!-- Require STARTTLS. If this is enabled, clients must do STARTTLS
before they can authenticate. Until the stream is encrypted,
all packets will be dropped. -->
<require-starttls/>
<!-- Older versions of jabberd support encrypted client connections
via an additional listening socket on port 5223. If you want
this (required to allow pre-STARTTLS clients to do SSL),
uncomment this -->
<ssl-port>5223</ssl-port>
</local>
<!-- Input/output settings -->
<io>
<!-- Maximum number of file descriptors. Note that the number of
possible connections will be slightly less than this, because
c2s itself can use up five on its own, and auth/reg modules may
need a few also. If the supply of file descriptors is
exhausted, new incoming connections will be denied.
(default: 1024) -->
<max_fds>1024</max_fds>
<!-- Rate limiting -->
<limits>
<!-- Maximum bytes per second - if more than X bytes are sent in Y
seconds, connection is throttled for Z seconds. The format
is:
<bytes seconds='Y' throttle='Z'>X</bytes>
Default Y is 1, default Z is 5. set X to 0 to disable. -->
<bytes>0</bytes>
<!-- Maximum connects per second - if more than X connects are
attempted from a single IP in Y seconds, that IP is throttled
for Z seconds. The format is:
<connects seconds='Y' throttle='Z'>X</connects>
Default Y is 5, default Z is 5. set X to 0 to disable. -->
<connects>0</connects>
</limits>
<!-- IP-based access controls. If a connection IP matches an allow
rule, the connection will be accepted. If a connecting IP
matches a deny rule, the connection will be refused. If the
connecting IP does not match any rules, or it matches both an
allow and a deny rule, the contents of the <order/> option
determines what happens. -->
<access>
<!-- Rule check order (default: allow,deny)
allow,deny - Check allow rules, then check deny rules.
Allow by default.
deny,allow - Check deny rules, then check allow rules.
Deny by default. -->
<order>allow,deny</order>
<!-- Allow a network. If the mask isn't specified, it defaults to
255.255.255.255 (ie allow onle the specified IP) -->
<!--
<allow ip='127.0.0.0' mask='255.0.0.0'/>
-->
<!-- Allow a single host -->
<!--
<allow ip='12.34.56.78'/>
-->
<!-- Deny a network or a host -->
<!--
<deny ip='127.0.0.1' mask='255.0.0.0'/>
<deny ip='87.65.43.21'/>
-->
</access>
<!-- Timed checks -->
<check>
<!-- Interval between checks.
Open client connections will be checked every n seconds, and
the following checks applied.
0 disables all checks. (default: 0) -->
<interval>0</interval>
<!-- Idle connection checks.
Connections that have not sent data for longer than this many
seconds will be dropped.
0 disables idle timeouts. (default: 0) -->
<idle>0</idle>
<!-- Keepalives.
Connections that have not sent data for longer than this many
seconds will have a single whitespace character sent to them.
This will force the TCP connection to be closed if they have
disconnected without us knowing about it.
0 disables keepalives. (default: 0) -->
<keepalive>0</keepalive>
</check>
</io>
<!-- Authentication/registration database configuration -->
<authreg>
<!-- Backend module to use -->
<module>mysql</module>
<!-- Registration configuration -->
<register>
<!-- Account registration is enabled by default (provided the
auth/reg module in use supports it). Comment this out to
disable. -->
<enable/>
<!-- Human-readable instructions to be returned to client when
registration is requested. -->
<instructions>Enter a username and password to register with this server.</instructions>
<!-- Password change only. When registration is disabled, it may
still be useful to allow clients to change their password. If
you want this, uncomment this when you disable registration. -->
<!--
<password/>
-->
</register>
<!-- Available authentication mechanisms -->
<mechanisms>
<!-- These are the traditional Jabber authentication mechanisms.
Comment out any that you don't want to be offered to clients.
Note that if the auth/reg module does not support one of
these mechanisms, then it will not be offered regardless of
whether or not it is enabled here.
Similarly, if <zerok/> is disabled, then zero-knowledge data
will not be created when a user is registered. -->
<traditional>
<plain/>
<digest/>
<zerok/>
</traditional>
<!-- SASL authentication mechanisms. Comment out any that you
don't want to be offered to clients. Again, if the auth/reg
module does not support one of these mechanisms, then it will
not be offered. -->
<sasl>
<plain/>
<digest-md5/>
<!--
<anonymous/>
-->
</sasl>
</mechanisms>
<!-- MySQL module configuration -->
<mysql>
<!-- Database server host and port -->
<host>localhost</host>
<port>3306</port>
<!-- Database name -->
<dbname>jabberd2</dbname>
<!-- Database username and password -->
<user>jabberd2</user>
<pass>secret</pass>
</mysql>
<!-- PostgreSQL module 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>
</pgsql>
<!-- Berkeley DB module configuration -->
<db>
<!-- Directory to store database files under -->
<path>/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>
<!-- LDAP module configuration -->
<ldap>
<!-- LDAP server host and port (default: 389) -->
<host>ldap.example.com</host>
<port>389</port>
<!-- Use LDAP v3 if possible. If disabled, v2 will be used.
Encryption options are only available if v3 is enabled. -->
<!--
<v3/>
-->
<!-- Encryption. If enabled, this will create an encrypted channel
to the LDAP server using the LDAP STARTTLS mechanism. -->
<!--
<starttls/>
-->
<!-- Encryption. If enabled, this will create an encrypted channel
to the server using the old-style "ldaps://" mechanism. It is
recommended that you use <starttls/> instead of this. -->
<!--
<ssl/>
-->
<!-- DN to bind as for searches. If unspecified, the searches
will be done anonymously. -->
<!--
<binddn>cn=Directory Manager</binddn>
<bindpw>secret</bindpw>
-->
<!-- LDAP attribute that holds the user ID (default: uid) -->
<uidattr>uid</uidattr>
<!-- base DN of the tree. You should specify a DN for each
authentication realm declared in the <local/> section above,
by using the realm attribute. -->
<basedn realm='company'>o=Company.com</basedn>
<basedn>o=Example Corp.</basedn>
</ldap>
<!-- Pipe module configuration -->
<pipe>
<!-- Program to execute -->
<exec>/usr/local/bin/pipe-auth.pl</exec>
</pipe>
</authreg>
</c2s>
jabber.cfg
# # jabberd config file # # # This file tells the jabberd wrapper what programs to launch, # and the config files to launch them with. If the config file # is left out, then the system default will be used. # # To run multiple Session Managers, just list them all seperatly # and provide the path to the appropriate config files. # # program [ path to config file ] # router /usr/local/etc/jabberd/router.xml resolver /usr/local/etc/jabberd/resolver.xml sm /usr/local/etc/jabberd/sm.xml s2s /usr/local/etc/jabberd/s2s.xml c2s /usr/local/etc/jabberd/c2s.xml
resolver.xml
<!-- Resolver configuration -->
<resolver>
<!-- Our id on the network (default: resolver) -->
<id>resolver</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/jabberd/pid/resolver.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>secret</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>/usr/local/etc/jabberd/server.pem</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/resolver</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>/var/jabberd/log/resolver.log</file>
-->
</log>
<!-- SRV records will be resolved in the following order. The first
one that returns something will be used (ie dereferenced via an
A/AAAA lookup). If no SRV records are found, resolver will
fallback to a straight A/AAAA lookup. -->
<lookup>
<!-- _xmpp-server._tcp is mandated by the XMPP spec -->
<srv>_xmpp-server._tcp</srv>
<!-- traditionally, _jabber._tcp has been used -->
<srv>_jabber._tcp</srv>
</lookup>
<!-- If this is enabled, the resolver will look up AAAA records as well
as A records. This is needed if you want s2s to use IPv6. -->
<!--
<ipv6/>
-->
</resolver>
router.xml
<!-- Router configuration -->
<router>
<!-- ID of the router on the network (default: router) -->
<id>router</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/jabberd/pid/router.pid</pidfile>
<!-- Log configuration - type is "syslog", "file" or "stdout" -->
<log type='syslog'>
<!-- If logging to syslog, this is the log ident -->
<ident>jabberd/router</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>/var/jabberd/log/router.log</file>
-->
</log>
<!-- Local network configuration -->
<local>
<!-- IP address to bind to (default: 0.0.0.0) -->
<ip>0.0.0.0</ip>
<!-- Port to bind to (default: 5347) -->
<port>5347</port>
<!-- File containing the user table. This is where the router gets
its component and secret information from for component
authentication.-->
<users>/usr/local/etc/jabberd/router-users.xml</users>
<!-- Shared secret used to identify legacy components (that is,
"jabber:component:accept" components that authenticate using
the "handshake" method). If this is commented out, support for
legacy components will be disabled. -->
<secret>secret</secret>
<!-- File containing a SSL certificate and private key for client
connections. If this is commented out, connecting components
will not be able to request a SSL-encrypted channel. -->
<pemfile>/usr/local/etc/jabberd/server.pem</pemfile>
</local>
<!-- Timed checks -->
<check>
<!-- Interval between checks.
Checks will be run every n seconds.
0 disables all checks. (default: 60) -->
<interval>60</interval>
<!-- Keepalives.
Connections that have not been used for longer than
this many seconds will have a single whitespace character sent
to them. This will force the TCP connection to be closed if
they have disconnected without us knowing about it.
0 disables keepalives. (default: 0) -->
<keepalive>0</keepalive>
</check>
<!-- input/output settings -->
<io>
<!-- Maximum number of file descriptors. Note that the number of
possible connections will be slightly less than this, because
the router itself can use up four on its own. If the supply of
file descriptors is exhausted, new incoming connections will be
denied (default: 1024) -->
<max_fds>1024</max_fds>
<!-- Rate limiting -->
<limits>
<!-- Maximum bytes per second - if more than X bytes are sent in Y
seconds, connection is throttled for Z seconds. The format
is:
<bytes seconds='Y' throttle='Z'>X</bytes>
Default Y is 1, default Z is 5. set X to 0 to disable. -->
<bytes>0</bytes>
<!-- Maximum connects per second - if more than X connects are
attempted from a single IP in Y seconds, that IP is throttled
for Z seconds. The format is:
<connects seconds='Y' throttle='Z'>X</connects>
Default Y is 5, default Z is 5. set X to 0 to disable. -->
<connects>0</connects>
</limits>
<!-- IP-based access controls. If a connection IP matches an allow
rule, the connection will be accepted. If a connecting IP
matches a deny rule, the connection will be refused. If the
connecting IP does not match any rules, or it matches both an
allow and a deny rule, the contents of the <order/> option
determines what happens. -->
<access>
<!-- Rule check order (default: allow,deny)
allow,deny - Check allow rules, then check deny rules.
Allow by default.
deny,allow - Check deny rules, then check allow rules.
Deny by default. -->
<order>allow,deny</order>
<!-- Allow a network. If the mask isn't specified, it defaults to
255.255.255.255 (ie allow onle the specified IP) -->
<!--
<allow ip='127.0.0.0' mask='255.0.0.0'/>
-->
<!-- Allow a single host -->
<!--
<allow ip='12.34.56.78'/>
-->
<!-- Deny a network or a host -->
<!--
<deny ip='127.0.0.1' mask='255.0.0.0'/>
<deny ip='87.65.43.21'/>
-->
</access>
</io>
<!-- Name aliases.
Packets destined for the domain specified in the "name" attribute
will be routed to the component that has currently bound the name
in the "target" attribute (assuming it is online).
This is usually only required for some kinds of legacy
components (particularly jabberd 1.4 "uplink" components) -->
<aliases>
<!-- Example for a MUC component running from a jabberd 1.4 uplink -->
<alias name='conference.jabber.foo.bar' target='muclinker'/>
</aliases>
<!-- Access control information -->
<aci>
<!-- The usernames listed here will get access to all restricted
functions, regardless of restrictions further down -->
<acl type='all'>
<user>jabberd</user>
</acl>
<!-- These users can bind names other than their username -->
<!--
<acl type='bind'>
</acl>
-->
<!-- These users can bind a name as a default route -->
<!--
<acl type='default-route'>
<user>s2s</user>
</acl>
-->
<!-- These users can elect to receive all packets that pass through the router -->
<!--
<acl type='log'>
<user>msglog</user>
</acl>
-->
</aci>
</router>
router-users.xml
<!-- This is the list of known router users, and their authentication
secrets. Access control is done via the settings in router.xml -->
<users>
<user>
<name>jabberd</name>
<secret>secret</secret>
</user>
</users>
s2s.xml
<!-- s2s configuration -->
<s2s>
<!-- Our ID on the network (default: s2s) -->
<id>s2s</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/jabberd/pid/s2s.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>secret</pass> <!-- default: secret -->
<!-- The router will only allow one component to be the default
route (ie the component that receives packets destined for
unknown hosts). If you want to run more than one s2s instance,
you need to uncomment this so that s2s does not try to become
the default route. Note that all outgoing s2s communication
will go to the component that is the default route. -->
<!--
<non-default/>
-->
<!-- 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>/usr/local/etc/jabberd/server.pem</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/s2s</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>/var/jabberd/log/s2s.log</file>
-->
</log>
<!-- Local network configuration -->
<local>
<!-- IP and port to listen for incoming s2s connections on
(default: 0.0.0.0, 5269) -->
<ip>0.0.0.0</ip>
<port>5269</port>
<!-- Helper DNS resolver component - if this component is not
connected, dialback connections will fail
(default: resolver) -->
<resolver>resolver</resolver>
<!-- Secret used to generate dialback keys. If you have more than
one s2s instance configured, make sure that this is the same on
all of them. If this is commented out, a random one will be
generated. -->
<!--
<secret>secret</secret>
-->
<!-- File containing a SSL certificate and private key to use when setting
up encrypted s2s connections with other servers (STARTTLS + Dialback).
If this is commented out, or the file can't be read, no attempt will be
made to establish encrypted connections with other servers. -->
<!--
<pemfile>/usr/local/etc/jabberd/server.pem</pemfile>
-->
</local>
<!-- Timed checks -->
<check>
<!-- Interval between checks.
Checks will be run every n seconds.
0 disables all checks. (default: 60) -->
<interval>60</interval>
<!-- Queue expiry and connection timeout.
While a connection is being established and dialback is in
progress, packets are queued. If a valid connection has not
been established within this many seconds, the connection
process will be aborted and the queued packets will be
bounced. Timeout checks are made for three phases of
setting up a route authenticated through dialback:
1. Connection establishment to exchange of stream headers
2. Initiating dialback (incoming connections)
3. Completing dialback (incoming and outgoing)
0 disables queue expiry. (default: 60) -->
<queue>60</queue>
<!-- Idle connection checks.
Connections that have not sent data for longer than this many
seconds will be dropped.
0 disables idle timeouts. (default: 86400) -->
<idle>86400</idle>
<!-- Keepalives.
Outgoing connections that have not been used for longer than
this many seconds will have a single whitespace character sent
to them. This will force the TCP connection to be closed if
they have disconnected without us knowing about it.
0 disables keepalives. (default: 0) -->
<keepalive>0</keepalive>
</check>
</s2s>
sm.xml
<!-- 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>jabber.foo.bar</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/jabberd/pid/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>secret</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>/usr/local/etc/jabberd/server.pem</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>/var/jabberd/log/sm.log</file>
-->
</log>
<!-- Storage database configuration -->
<storage>
<!-- By default, we use the MySQL driver for all storage -->
<driver>mysql</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>localhost</host>
<port>3306</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.
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>/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>
</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.
Enabling 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>
muc.xml
<jcr>
<!--
This is a config file for a copy of MU-Conference, compiled against
the Jabber Component Runtime (JCR). This is the same file that I use
to connect to my development server, running jabberd2 beta2
In order to connect to a jabberd v1.4 server, simply change the
<name> value to muclinker, and make sure the muclinker section is in
your main jabber.xml file, as per the MU-Conference README file.
-->
<name>muclinker</name>
<host>conference.jabber.foo.bar</host>
<ip>127.0.0.1</ip>
<port>5347</port>
<secret>secret</secret>
<spool>/var/jabberd/spool</spool>
<logdir>/var/jabberd/log</logdir>
<pidfile>/var/jabberd/pid</pidfile>
<!--
<logstderr/>
-->
<loglevel>124</loglevel>
<conference xmlns="jabber:config:conference">
<public/>
<vCard>
<FN>Public Chatrooms</FN>
<DESC>This service is for public chatrooms.</DESC>
<URL>http://conference.foo.bar/</URL>
</vCard>
<history>40</history>
<logdir>/var/jabberd/log</logdir>
<notice>
<join>has become available</join>
<leave>has left</leave>
<rename>is now known as</rename>
</notice>
<sadmin>
<user>admin@jabber.foo.bar</user>
</sadmin>
</conference>
</jcr>
SSL Configuration
This section describes how to generate a self-signed OpenSSL certificate for use with Jabberd.
Important: Key Is Self-Signed
The key generated by the instructions below is self-signed. Such a key is not part of a trust hierarchy. When used to secure communications with Jabber clients, a self-signed key will usually cause warnings to appear because its authenticity cannot be verified against a trusted key.
Generate Key Pair
From a working directory, enter the command below to begin an interactive key generation process:
openssl req -new -x509 -newkey rsa:1024 -days 3650 -keyout privkey.pem -out server.pem
You will be prompted for a passphrase for the private key. After entering and confirming your passphrase, you will be prompted for public information about your key.
Common Name
Note that you should enter your domain name as the Common Name for your certificate.
Key Lifetime
Note that the command above creates a key with a 3650 day (10 year lifetime). To change the key lifetime, use a different number of days for the -days parameter.
Remove Passphrase
Enter this command to remove the passphrase from your private key:
openssl rsa -in privkey.pem -out privkey.pem
Combine the Private and Public Key
Enter this command to combine the private and public keys into a single file:
cat privkey.pem >> server.pem
Delete Private Key
You should now delete your private key:
rm privkey.pem
Move Key and Set Permissions
You can now move your key to its permanent location. For example, to move the key to the default Jabberd pemfile location, you would enter this command (as superuser):
mv server.pem /usr/local/etc/jabberd/server.pem
Then, you should set permissions on this file so that it is owned by superuser and is readonly (as superuser):
chown root:jabber /usr/local/etc/jabberd/server.pem
chmod 640 /usr/local/etc/jabberd/server.pem
Your certificate is now ready for use by Jabberd. You should make a backup (such as to a floppy) of your certificate.
Running Jabber
For security purposes do not run the Jabber server as root
To run the jabber daemon in the background:
sudo -u jabberd -b
To run the MU-Conference:
Note: The plugin does not detach from terminal. Either use screen or daemontools to automate the process.
mu-conference -c /usr/local/etc/jabberd/muc.xml
