jabber.xml(5) jabberd14 project jabber.xml(5)NAMEjabber.xml - jabberd daemon configuration file
SYNOPSIS
The jabber daemon jabberd is configured by an XML configuration file.
By default jabberd will read /usr/local/etc/jabber.xml. The -c command
line option can be used to specify an alternate configuration file.
FILE FORMAT
The configuration file has to be a valid XML document preferably in the
UTF-8 charset (ASCII is valid subset of UTF-8).
Within the following xpath expressions, the following namespace pre‐
fixes are used:
default namespace: "jabber:server", browse: "jabber:iq:browse", cfg:
"http://jabberd.org/ns/configfile", register: "jabber:iq:register",
vcard: "vcard-temp",
<jabber/>
This is the root element of the configuration file.
<service/>
This element is an immediate child element of the <jabber/> root
element. It defines a general purpose component in the jabber
daemon. The jabber daemon will route all stanzas to this compo‐
nent that have a domain part in the destination JID that equals
the id attribute or any defined additional domains this compo‐
nent is responsible for using the <host/> child element. An
implementation or relation to an other process is defined using
one of the following child elements: <accept/>, <connect/>,
<dynamic/>, <exec/>, <load/>, <null/>. Any child elements in own
namespaces are ignored by the core jabberd and can be used by
components to store their own configuration.
<xdb/> This element is an immediate child element of the <jabber/> root
element. It defines a component in the jabber daemon, that is
responsible for XML data storage. This components internal
address is defined by the id attribute. The <host/> child ele‐
ments define for which domains this storage component is manag‐
ing the data. An empty <host/> element defines, that it is
responsible for all components. With the <ns/> child element you
can limit the responsibility to XML chunks in a given set of
namespaces. You can then for example define one storage compo‐
nent that handles rosters and an other that handles offline mes‐
sage storage. An implementation or relation to an other process
is defined using on of the following child elements: <accept/>,
<connect/>, <dynamic/>, <exec/>, <load/>, <null/>. Any child
elements in own namespaces are ignored by the core jabberd and
can be used by components to store their own configuration.
<log/> This element is an immediate child element of the <jabber/> root
element. It defines a component in the jabber daemon, that acts
as a logging sink. This components internal address is defined
by the id attribute. The <host/> child elements define for which
domains this logging sink is logging messages. An empty <host/>
element defines, that it is responsible for all components.
With the <logtype/> child element you can select the types of
messages, that are handled by this component. Where to write
the logging information is defined with one of the following
child elements: <file/>, <stderr/>, <stdout/>, <to/>. With the
<format/> child element you define the format of the logged mes‐
sage.
<io/> This element is an immediate child element of the <jabber/> root
element. In this section of the configuration file you can
define different settings that are related to the network I/O
layer. This includes bandwidth limitations (using the <karma/>
element), assigning X.509 certificates to sockets (using the
<tls/> element), and to limit access to the server to specific
IP address ranges (using the <allow/> and <deny/> elements).
<pidfile/>
This element specifies to which file the server should write its
process ID. If this file already exists when the server is
started, it will fail. You have to remove stale pidfiles before
starting the server yourself. If you omit this element, the
server will not write nor check any pidfile.
<debug/>
This element contains configuration settings controlling the
output of debugging messages. These settings can be changed at
server runtime, the server will reread them on receiving a
SIGHUP signal.
The following elements are used inside the <service/>, <xdb/>, and
<log/>
elements, that are defining components. They are used to provide
the jabberd process with information where it can find the com‐
ponent's implementation.
<load/>
This element can be used inside any component definition. It
specifies, that the implementation of the component can be found
inside a shared object. Any child element of this element
defines a shared object file and a method in this object. jab‐
berd will load the shared object files which locations are
defined in the cdata elements inside the child elements, the
names of the elements are defining the functions that have to be
called. An optional main attribute in the <load/> element define
the main function in a component, that has to be used to ini‐
tialize it.
<accept/>
This element defines, that jabberd will wait for an incoming
connection using the jabber:component:accept protocol defined in
XEP-0114. With this it is possible to run components in their
own process, even on different hosts and connect it to the main
jabberd routing process. On the other end of the connection
there can be an instance of jabberd again that uses a section
with <connect/> to initiate the connection, but there are
libraries in many programming languages available, that imple‐
ment XEP-0114 as well. Inside this element you have to provide
an <ip/> element, that defines the IPv4 or IPv6 address to lis‐
ten on, a <port/> element that defines on which port the server
will listen for the connection, and a <secret/> element, that
defines a shared secret to authenticate the other peer.
<connect/>
This element is the opposite of the <accept/> element. Jabberd
will try to connect to an implementation of the jabber:compo‐
nent:accept protocol defined in XEP-0114. Inside this element
you have to provide an <ip/> element, that defines the IPv4 or
IPv6 address where to connect to, a <port/> element, that
defines the destination port, and a <secret/> element, that
defines a shared secret to authenticate to the other peer.
<file/>
This element can only be used inside a <log/> section. It is
used to specify that log messages should be appended to a text
file.
<null/>
This element specifies an empty component. Everything that is
sent to a JabberID with the domain part of this component is
silently discarded. It can be used to drop stanzas directed to
entities on the Jabber network, that have disappeared (e.g.
update.jabber.org).
<stderr/>
This element can only be used inside a <log/> section. It is
used to specify that log messages should be written to the stan‐
dard error output stream.
<stdout/>
This element is used to define, that the jabberd process is com‐
municating with the process, that is implementing the component.
It is the opposite of <exec/>. A process that is started by
<exec/> in an other process can use <stdout/> to implement the
other end of the connecting pipe.
<syslog/>
This element can only be used inside a <log/> section. It is
used to specify that log messages should be written to the sys‐
log.
<to/> This element can only be used inside a <log/> section. It is
used to reformat log packets as messages and resend them to an
entity with the given JabberID. The JabberID is given as cdata
child element.
<unsubscribe/>
This element can only be used inside a <service/> section. It is
used to bounce messages and iq queries and send unsubscribes to
presences, that are received. It is intended to be used as a
replacement for transports, that are removed from a server. It
will remove the roster items of this transport from the users'
rosters.
jsm setting: cfg:jabber/cfg:service/jsm:jsm/browse:browse
List of services, that should be returned as the result of a
browsing or a service discovery request. The format is as in a
browse result stanza.
jsm setting: cfg:jabber/cfg:service/jsm:jsm/disco-info:disco/disco-
info:identity
Name of the Jabber server, that should be returned in a service
discovery reply. If this is not configured, the FN field of the
server's vCard (cfg:jabber/cfg:ser‐
vice/jsm:jsm/vcard:vCard/vcard:FN) is used.
jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:admin/reply
Message, that should be returned to someone, that has sent a
message to the servers address. (These messages are forwarded to
all users having the 'adminmsg' ACL right.)
jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:agents
This configuration setting can contain a response of a iq get
query in the jabber:iq:agents namespace. Using this is depre‐
cated. You should not use this configuration setting. The jab‐
ber:iq:agents namespace is superseded by service discovery.
jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:archive
Configure the JabberIDs where mod_log should send messages about
created sessions to. The JabberIDs should be enclosed in a <ser‐
vice/> element. Multiple <service/> elements can be placed
inside the <archive/> element.
jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:auth
Redirect authentication handling (non-SASL only) to a component.
The address of the component has to be given as the textual con‐
tent of this configuration element. No default setting.
jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:history
With this element, the session manager can be configured to send
copies of received and sent messages to xdb. This can be used
for logging or to implement web-based access to the message his‐
tory. The history element contains two child elements: sent and
recv. The sent element configures how messages sent by a user
are handled. The recv element configures how messages received
by a user are handled.
jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:maxusers
The maximum number of users the server should expect per domain
(more users will get handled, but it may have performance
impacts). A prime number should be configured here. The default
setting is 3001.
jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:mod_auth_crypt/jsm:hash
The default password hashing algorithm used by mod_auth_crypt is
crypt(). With this setting you can select other algorithms by
adding their name as the text inside this element. Currently the
only other algorithm supported by mod_auth_crypt is "SHA1". It
is not recommended to use mod_auth_crypt. With hashed pass‐
words, you get problems when you want to migrate to SASL authen‐
tication.
jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:mod_offline
With this it can be configured which messages are stored off‐
line. The default is to only store normal and chat messages off‐
line (bouncing headline and groupchat messages, dropping error
messages). If the mod_offline element is present, only message
types present in this element are stored offline. Use the fol‐
lowing element names inside this element: <normal/>, <chat/>,
<headline/>, <groupchat/>, and <error/>.
jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:mod_useridpolicy
Define a policy for usernames, that should be enforced on
account registration (i.e. already registered usernames are not
affected). It is possible to block accounts from being regis‐
tered based on special names (put the username inside a <forbid‐
den/> element, e.g. <forbidden>root</forbidden>) or enforce
length constraints on the username by defining a minimum and/or
maximum length of the username in unicode characters (put the
setting inside <minlen/> and <maxlen/> elements, e.g.
<minlen>3</minlen>).
jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:mod_version
Modify the result to a jabber:iq:version request. With the
<name/> element inside this configuration option, you can
replace the product name, that is returned by the server. With
the <version/> element, you can replace the returned product
version. With the <os/> element, you can replace the operating
system identification returned by mod_version. With the
<no_os_version/> element, you can configured mod_version to
return the name of the operating system, but not its version
number.
jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:presence
This configuration option can include two different elements:
With the <presence2xdb/> element you configure jabberd14 to
store all presences of the local users to xdb. Used together
with xdb_sql this can be used to have the presence of your users
in a SQL database, e.g. to use it to display web status indica‐
tors. (Please recognize the privacy issues with web indicators
if you plan to implement this.) The other possible element
inside this configuration option is <bcc/> which can be used
multiple times. Inside the <bcc/> element you can place Jab‐
berIDs. All local presences are send to the configured Jab‐
berIDs as a copy. This can be used to forward presence to a
component, that needs to know presence of all local users. (E.g.
another way to implement a web presence indicator.)
jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:regtimeout
This configures the number of seconds an account gets blocked
against reregistration after it has been unregistered. The value
is specified as the timeout attribute of this element.
jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:serialization
With this setting the session manager can be configured to store
all necessary state information to restart the session manager
to a file. This can be used to restart the session manager
after a crash (or after it has been killed by a signal) without
the user's sessions to be dropped. This can be used to reconfig‐
ure the session manager while it is running. Please note, that
on very big jabberd14 installations you might get problems if
you serialize the state to often.
jsm setting: cfg:jabber/cfg:service/jsm:jsm/jsm:vcard2jud
If the vCard a users sets should be forwarded to the first Jab‐
ber users directory, that is configured in cfg:jabber/cfg:ser‐
vice/jsm:jsm/browse:browse.
jsm setting: cfg:jabber/cfg:service/jsm:jsm/register:register
Reply stanza to a jabber:iq:register get request. This config‐
ures what a client gets asked, if a user tries an inband account
registration.
jsm setting: cfg:jabber/cfg:service/jsm:jsm/vcard:vCard
The vCard, that gets returned, if a Jabber entity requests a
vCard for the server. No default value.
jsm setting: cfg:jabber/cfg:service/jsm:jsm/welcome
A message stanza, that should be sent to a new user. The content
of the welcome element is used as the content of the generated
message stanza. Therefore you should have a body element inside
this one, and a subject element might be good to have as well.
It is possible to use xml:lang attributes for the content of
this element. No default setting, if element is missing, no wel‐
come message is generated.
TLS settings: cfg:jabber/cfg:io/cfg:tls
Inside this configuration element you find the settings, that
configure how TLS is used inside jabberd14. Settings inside this
element are grouped together using the <credentials/> element.
Every set of settings defined within such an element is used for
the set of domains, that are configured using the <domain/> ele‐
ment inside this element. If jabberd14 searches for settings and
does not find a set that contains the relevant domain, it will
search a set that contains the <default/> element. If even no
such set is found, TLS is disabled for this domain. (Note: This
is designed to be used with the STARTTLS mechanism of the XMPP
protocol. If you are using legacy TLS connections for clients on
port 5223, you have to configure the IP addresses your are lis‐
tening on as domain as well. E.g. <domain>192.0.2.34</domain> if
you are listening on port 5223 or the IP address 192.0.2.34.)
Beside the <credentials/> element, there are three more valid
elements, that can be placed inside the <tls/> element:
TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:dhparams
If this setting is not present, jabberd14 will generate parame‐
ters for Diffie Hellman keyexchanges on the fly when starting
up. As this may take some time, you might want to use pre-calcu‐
lated parameters. Use this setting to load them. Specify the
filename containing the parameters as the content of this ele‐
ment. By default the file is expected to by PEM encoded. Add the
flag type="der" if the file is DER encoded.
TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:cacertfile
This setting defines a file containing certificates of the CAs
jabberd14 should trust when authenticating peers using certifi‐
cates. These CA certificates are used as the default CAs and can
be overwritten using the <ca/> element inside the <credentials/>
elements for each set of TLS settings.
TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:crlfile
This setting allows you to load a certificate revocation list
from a file. Place the filename as the content of this element.
By default the file is tried to be loaded as a PEM encoded file.
If the file is DER encoded, please specify the type="der"
attribute on this element.
TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:default
Define that this set of TLS settings should be used when no
explicit set of settings can be found for a domain.
TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:domain
Bind a set of settings to a domain. The domain for which the set
should be used has to be placed as the content of this element.
No whitespace should be present in the content of this element.
This element can be used multiple times inside the <creden‐
tials/> element to bind a set of settings to multiple domains.
TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:pem
This setting is used to load a server certificate of a certifi‐
cate chain, that is PEM encoded. By default jabberd14 tries to
read the private key from the same file as the certificate. If
you have your private key in a different file, please specify
the filename of this file using the private-key attribute on the
<pem/> element. If you have multiple certificates for the set
of domains (e.g. a RSA and a DSA certificate) you can place mul‐
tiple <pem/> elements inside a <credentials/> element. But if
your certificates are for different domains, you have to place
them in different <credentials/> elements.
TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:der
This is the same setting as the <pem/> element, with the only
difference that the file is expected to be DER encoded instead
of PEM encoded. Please also note, that with DER encoded certifi‐
cates you always have to place your private key in a different
file, and therefore have to use the private-key attribute of the
<der/> element.
TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:ca
Load one or many certificates of CAs the server should trust to
do certificate based authentication of peers. By default the
file is expected to be PEM encoded. If the file is DER encoded,
you have to add the type="der" attribute to this element. This
element can be used multiple times to load multiple files.
TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:openpgp
Load an OpenPGP key as certificate. Specify the file containing
the public key as the content of this element and the file con‐
taining your private key using the private-key attribute of this
element.
TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:keyring
Load an OpenPGP keyring from the file specified using the con‐
tent of this element.
TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:trustdb
Load a GnuPG trust database from the file specified using the
content of this element.
TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:protocols
This setting is used to specify which version of the TLS proto‐
col should be used and in which order they should be prefered.
If you omit this setting, the protocols and their preference are
defined by the used TLS library (GnuTLS) itself. Place the list
of protocols in the order of their preference separated by
whitespace as content of this element. Recognized values are:
TLS1_2 for TLS version 1.2 (only known if jabberd14 is compiled
with a TLS library supporting this version of TLS, otherwise
ignored), TLS1_1 for TLS version 1.1, TLS1_0 for TLS version
1.0, and SSL3 for SSL version 3.0 (predecessor of TLS 1_0). SSL
versions before 3.0 are not supported by jabberd14 anymore as
they are considered weak.
TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:kx
This setting is used to specify which key exchange algorithms
should be used and in which order they should be prefered. If
you omit this setting, the algorithms and their preference are
defined by the used TLS library (GnuTLS) itself. Place the list
of algorithms in the order of their preference separated by
whitespace as content of this element. Recognized values are:
RSA for exchanging keys on a RSA encrypted channel, DHE_RSA for
using a RSA signed Diffie Hellman keyexchange, DHE_DSS for using
a DSS signed Diffie Hellman keyexchange. The DHE_* key exchanges
might need a bit more computing power, but will result in a non-
compromized key even if your certificate gets compromized. With
a pure RSA key exchange the encrypted session gets readable if
your RSA certificate gets compromized. For RSA and DHE_RSA
keyexchanges you need a RSA certificate when being the server
side of the connection, for the DHE_DSS key exchange you need a
DSS certificate when being the server side of the connection. If
you are the server (i.e. connected) side of the TLS connection,
this setting will only select which key exchange algorithms you
support/offer as it is the client's task to select one of the
offered algorithms. Therefore the order of this setting is only
relevant if you are the connecting side of a TLS connection.
(Note: ANON_DH is supported as well and results in an anonymous
Diffie Hellman keyexchange. Normally you do not want to enable
this key exchange, please only enable it, if you know what you
are doing.)
TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:ciphers
This setting is used to specify which cipher algorithms should
be used and in which order they should be prefered. If you omit
this setting, the ciphers and their preference are defined by
the used TLS library (GnuTLS) itself. Place the list of ciphers
in the order of their preference separated by whitespace as con‐
tent of this element. Recognized values are: AES_256_CBC is the
AES cipher using a 256 b key in CBC mode, AES_128_CBC is the AES
cipher using a 128 b key in CBC mode, 3DES_CBC is the 3DES
cipher using 168 b key (effective strength is considered to be
only 112 b) in CBC mode, ARCFOUR_128 is the ARCFOUR stream
cipher using a 128 b key. (The following ciphers are recognized
as well, but you normally should not configure them: ARCFOUR_40,
RC2_40_CBC, DES_CBC, NULL. Only allow these additional ciphers,
if you know exactly what you are doing. They are considered to
be weak ciphers.)
TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:compression
This setting is used to specify which compression algorithms
should be used and in which order they should be prefered. If
you omit this setting, the compression algorithms and their
preference are defined by the used TLS library (GnuTLS) itself.
With current versions of GnuTLS this means disabling compres‐
sion. Therefore if you want to use TLS stream compression, you
have to define this setting. Place the list of compression algo‐
rithms in the order of their preference separated by whitespace
as content of this element. Recognized values are: LZO for com‐
pression using the LZO algorithm (only supported if GnuTLS extra
has been found on compilation of jabberd14, ignored otherwise),
DEFLATE for compression using the deflate/gzip algorithm, NULL
for no compression. The LZO algorithm might have a better per‐
formance than the DEFLATE algorithm.
TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:mac
This setting is used to specify which MAC algorithms should be
used and in which order they should be prefered. If you omit
this setting, the algorithms and their preference are defined by
the used TLS library (GnuTLS) itself. Place the list of mac
algorithms in the order of their preference separated by white‐
space as content of this element. Recognized values are: NULL
(for using no MAC), MD5, SHA1, RMD160, MD2 (not recommended),
SHA256, SHA386, SHA512. This setting is for expert users only.
Normally you want to leave the defaults. (SHA256, SHA386 and
SHA512 are only present if the underlying TLS library support
them.)
TLS setting: cfg:jabber/cfg:io/cfg:tls/cfg:credentials/cfg:certtypes
This setting is used to specify which certificate types should
be used and in which order they should be prefered. If you omit
this setting, the types and their preference are defined by the
used TLS library (GnuTLS) itself. With current versions of
GnuTLS this means only supporting X.509 certificates, which is
what you currently normally want to use. Place the list of types
in the order of their preference separated by whitespace as con‐
tent of this element. Recognized values are: X.509 for X.509
certificates and OpenPGP for using OpenPGP keys as certificates.
AUTHOR
jabberd14 project
1.6.1.1 02 Apr 2007 jabber.xml(5)
