<!-- 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>/kolab//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>/kolab/etc/jabberd/jabber.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='file'>
<file>/kolab//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 realm='company'>@@@jabber-domain@@@</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>/kolab/etc/jabberd/jabber.pem</pemfile>
<!-- 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>ldap</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>/kolab//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>localhost</host>
<port>389</port>
<!-- DN to bind as for searches. If unspecified, the searches
will be done anonymously. -->
<!--
<binddn></binddn>
<bindpw></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'>@@@base_dn@@@</basedn>
<querystring>(%s=%s@@@jabber-email@@@)</querystring>
</ldap>
<!-- Pipe module configuration -->
<pipe>
<!-- Program to execute -->
<exec>/kolab//bin/pipe-auth.pl</exec>
</pipe>
</authreg>
</c2s>