hasufell/etc-gentoo
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

committing changes in /etc after emerge run

Browse Source 
Package changes:
+net-im/jabberd2-2.3.3
This commit is contained in:
Hans Wurst 2015-08-16 15:36:54 +02:00
parent 324ee9b554
commit 1e56c52b50
9 changed files with 4205 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

97
init.d/._cfg0000_jabberd Executable file
View File

@ -0,0 +1,97 @@
#!/sbin/runscript
# Copyright 1999-2014 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$
extra_commands="reload"
depend() {
need net
use mysql postgresql slapd
provide jabber-server
}
stopJabberServices() {
eindent
for pidfile in /var/run/jabber/*.pid; do
if [ -f "${pidfile}" ]; then
service=$(basename ${pidfile} .pid)
ebegin "Stopping ${service}"
start-stop-daemon \
--stop \
--pidfile ${pidfile}
eend $?
fi
done
eoutdent
}
start_pre() {
checkpath -d -o jabber /var/run/jabber
}
start() {
einfo "Starting Jabber Server ..."
local services executable cfgfile pidfile
services=$(grep -v ^# /etc/jabber/jabberd.cfg | grep '..*' | awk '{print $1 ":" $2}')
eindent
for service in ${services}; do
cfgfile=$(echo ${service} | cut -d ':' -f 2)
service=$(echo ${service} | cut -d ':' -f 1)
if [ ! -f "${cfgfile}" ]; then
if [ -f "/etc/jabber/${service}.xml" ]; then
cfgfile="/etc/jabber/${service}.xml"
else
eerror "Can't find: ${cfgfile} or default /etc/jabber/${service}.xml"
stopJabberServices
return 1
fi
fi
executable=/usr/bin/${service}
if [ ! -f "${executable}" ]; then
eerror "Can't find executable: ${executable}"
stopJabberServices
return 1
fi
ebegin "Starting ${service} (${cfgfile})"
pidfile="$(grep -v ^# ${cfgfile} | grep '<pidfile>' | sed 's#<.\?pidfile>##g')"
start-stop-daemon \
--background \
--start \
--user jabber:jabber \
--exec /usr/bin/${service} \
--pid ${pidfile} \
-- -c ${cfgfile}
eend $?
done
eoutdent
}
reload() {
eindent
for pidfile in /var/run/jabber/*.pid; do
if [ -f "${pidfile}" ]; then
service=$(basename ${pidfile} .pid)
ebegin "Reloading ${service}"
kill -HUP $(cat ${pidfile})
eend $?
fi
done
eoutdent
}
stop() {
einfo "Stopping Jabber Server"
stopJabberServices
}

705
jabber/._cfg0000_c2s.xml Normal file
View File

@ -0,0 +1,705 @@
<!-- 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
the process ID from outside the process (eg for control scripts) -->
<pidfile>/var/run/jabber/${id}.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 an SSL certificate and private key to use when
setting up an encrypted channel with the router. From
SSL_CTX_use_certificate_chain_file(3): "The certificates must be
in PEM format and must be sorted starting with the subject's
certificate (actual client or server certificate), followed
by intermediate CA certificates if applicable, and ending
at the highest level (root) CA" (the latter one being optional).
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/jabber/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/log/jabber/c2s.log</file>
-->
<!-- Filename of the debug logfile -->
<!--
<debug>/var/log/jabber/debug-${id}.log</debug>
-->
</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.
You may leave the content of the <id/> empty to setup default
virtual host setup, that will be used for all present but not
configured otherwise SM domains.
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.
If empty "" realm is specified, the PAM backend wil authenticate
using plain usernames, not JIDs.
pemfile
attribute specifies the file containing a SSL certificate and
private key for client connections. If this is non existant,
clients will not be offered the STARTTLS stream extension
From SSL_CTX_use_certificate_chain_file(3):
"The certificates must be in PEM format and must be sorted
starting with the subject's certificate (actual client or server
certificate), followed by intermediate CA certificates if
applicable, and ending at the highest level (root) CA"
(the latter one being optional).
verify-mode
SSL verify mode - see SSL_CTX_set_verify(3), mode parameter.
Sum of the following options:
SSL_VERIFY_NONE 0x00
SSL_VERIFY_PEER 0x01
SSL_VERIFY_FAIL_IF_NO_PEER_CERT 0x02
SSL_VERIFY_CLIENT_ONCE 0x04
Use 7 to require all clients to present _valid_ certificates.
cachain
SSL CA chain. Used to verify client certificates.
CA names published to client upon connection.
require-starttls
If this attribute is set to any value, clients must do STARTTLS
before they can authenticate. Until the stream is encrypted,
all packets will be dropped.
register-enable
Remove this attribute to disable account registrations.
instructions
Human-readable instructions to be returned to client when
registration is requested.
register-oob
URL to be attached as an alternative, out-of-band registration
method. Usually web-based http:// URL.
password-change
Password change only. When registration is disabled, it may
still be useful to allow clients to change their password. If
you want this, add this attribute with any value, when you need
registration disabled.
-->
<id register-enable='mu'>localhost.localdomain</id>
<!-- or
<id realm='company.int'
pemfile='/etc/jabber/server.pem'
verify-mode='7'
cachain='/etc/jabber/client_ca_certs.pem'
require-starttls='mu'
register-enable='mu'
instructions='Enter a username and password to register with this server.'
register-oob='http://example.org/register'
password-change='mu'
>example.net</id> -->
<!-- or the default host
<id password-change='mu' /> -->
<!-- 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>
<!-- 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>
-->
<!-- File containing an SSL certificate and private key for client
connections. From SSL_CTX_use_certificate_chain_file(3):
"The certificates must be in PEM format and must be sorted
starting with the subject's certificate (actual client or server
certificate), followed by intermediate CA certificates if
applicable, and ending at the highest level (root) CA"
(the latter one being optional).
Note: This certificate is ONLY used for old style SSL
connections on port 5223 (pre-STARTTLS). If you want to
use STARTTLS over the standard XMPP port 5222 then you
MUST specify the pemfile in the 'id' tag above. -->
<!--
<pemfile>/etc/jabber/server.pem</pemfile>
-->
<!-- SSL verify mode - see SSL_CTX_set_verify(3), mode parameter -->
<!--
<verify-mode>7</verify-mode>
-->
<!-- SSL CA chain. Used to verify client certificates. CA names published to client upon connection -->
<!--
<cachain>/etc/jabber/client_ca_certs.pem</cachain>
-->
<!-- Forward incoming HTTP clients to a real HTTP server -->
<!--
<httpforward>http://www.jabber.org/</httpforward>
-->
</local>
<!-- Input/output settings -->
<io>
<!-- Maximum number of file descriptors. This value sets an upper
limit on the number of users who may be logged in to this
server at a given time. Each user consumers one file
descriptor.
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.
Also note that this value only affects how many file descriptors
jabberd is able to handle internally. You may also need to
tell your operating system to allow jabberd to use more file
descriptors. On Linux this can be done using ulimit -n or by
changing the value of /proc/sys/fd/file-max.
(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 number of stanzas per second - if more than X stanzas
are sent in Y seconds, connection is throttled for Z seconds.
The format is:
<stanzas seconds='Y' throttle='Z'>X</stanzas>
Default Y 1, default Z is 5. Set X to 0 to disable -->
<stanzas>1000</stanzas>
<!-- 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>
<!-- Maximum stanza size - if more than given number of bytes
are read in one incoming stanza, the stream is closed
with policy-violation error.
Set to 0 to disable.
Values less than 16384 might not work. -->
<stanzasize>65535</stanzasize>
</limits>
<!-- Enable XEP-0138: Stream Compression -->
<!--
<compression/>
-->
<!-- 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>
<!-- Statistics -->
<stats>
<!-- file containing count of packets that went through -->
<!--
<packet>/var/spool/jabber/stats/c2s.packets</packet>
-->
</stats>
<!-- PBX integration -->
<pbx>
<!-- Commands named pipe path. Allows creating "fake" sessions
with given resource and status -->
<!--
<pipe>/var/run/jabber/pbx</pipe>
-->
<!-- Available commands:
START jid/resource [[priority ]status] [description]
STOP jid/resource [description]
where priority is integer between -128 and +127
and status is one of: CHAT, ONLINE, DND, AWAY, XA
-->
</pbx>
<!-- see-other-host error stream redirection support
This will redirect connections to specified domains to other host:port
Usefull when migrating service and DNS change did not propagate yet.
Note that to_address should be RFC 3986 compliant. -->
<stream_redirect>
<!--
<redirect requested_domain="some.domain" to_address="other.hostname" to_port="5269" />
<redirect requested_domain="other.domain" to_address="other.host" to_port="1234" />
-->
</stream_redirect>
<!-- Authentication/registration database configuration -->
<authreg>
<!-- Dynamic authreg modules path -->
<path>/usr/lib64/jabberd</path>
<!-- Backend module to use -->
<module>db</module>
<!-- 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. -->
<traditional>
<plain/>
<digest/>
</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/>
<gssapi/>
-->
</sasl>
</mechanisms>
<!-- Additional mechanisms that are also available when the
connection is encrypted. Ie. when START-TLS had been
negotiated, or user connected on SSL-wrapped port. -->
<ssl-mechanisms>
<!-- it's advisable that you disable plain in the above
<mechanisms/> section -->
<traditional>
<plain/>
</traditional>
<sasl>
<plain/>
<external/>
</sasl>
</ssl-mechanisms>
<!-- SQLite driver configuration -->
<sqlite>
<!-- Database name -->
<dbname>/var/spool/jabber/db/sqlite.db</dbname>
<!-- 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/>
<!-- SQLite busy-timeout in milliseconds. -->
<busy-timeout>2000</busy-timeout>
<!-- Passwords in DB may be stored in plain or hashed format -->
<!-- NOTE: If you are using hashed passwords, the only auth
method that will work is PLAIN.
Make sure that you disabled others in 'mechanisms'
sections of the config file. -->
<password_type>
<!-- only one may be enabled here -->
<plaintext/>
<!-- use crypt(3)ed passwords
<crypt/>
-->
<!-- use A1HASH passwords
This stores the MD5 digest of user:realm:password in the database
<a1hash/>
-->
</password_type>
</sqlite>
<!-- 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>
<!-- Passwords in DB may be stored in plain or hashed format -->
<!-- NOTE: If you are using hashed passwords, the only auth
method that will work is PLAIN.
Make sure that you disabled others in 'mechanisms'
sections of the config file. -->
<password_type>
<!-- only one may be enabled here -->
<plaintext/>
<!-- use crypt(3)ed passwords
<crypt/>
-->
<!-- use A1HASH passwords
This stores the MD5 digest of user:realm:password in the database
<a1hash/>
-->
<!-- use bcrypt passwords
NOTE: cost has to be higher than 3 and lower than 32
<bcrypt cost='10'/>
-->
</password_type>
</mysql>
<!-- PostgreSQL module configuration -->
<pgsql>
<!-- PostgreSQL connection info.
For the rest of the options see
http://www.postgresql.org/docs/8.0/interactive/libpq.html -->
<conninfo>dbname=jabberd2 user=jabberd2 password=secret</conninfo>
<!-- Alternatively you may set connection settings separately.
These are used only in absence of 'conninfo' -->
<!-- Database server host and port -->
<host>localhost</host>
<port>5432</port>
<!-- Database name -->
<dbname>jabberd2</dbname>
<!-- Database schema -->
<schema>public</schema>
<!-- Database username and password -->
<user>jabberd2</user>
<pass>secret</pass>
<!-- Passwords in DB may be stored in plain or hashed format -->
<!-- NOTE: If you are using hashed passwords, the only auth
method that will work is PLAIN.
Make sure that you disabled others in 'mechanisms'
sections of the config file. -->
<password_type>
<!-- only one may be enabled here -->
<plaintext/>
<!-- use crypt(3)ed passwords
<crypt/>
-->
<!-- use A1HASH passwords
This stores the MD5 digest of user:realm:password in the database
<a1hash/>
-->
</password_type>
</pgsql>
<!-- 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>
<!-- Berkeley DB module configuration -->
<db>
<!-- Directory to store database files under -->
<path>/var/spool/jabber/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>
<!-- LDAPFULL module configuration -->
<ldapfull>
<!-- LDAP server host and port (default: 389) -->
<uri>ldap://localhost/ ldaps://ldap.example.com/</uri>
<!-- DN to bind as for searches. If unspecified, the searches
will be done anonymously. -->
<!--
<binddn>cn=Directory Manager</binddn>
<bindpw>secret</bindpw>
-->
<!-- Type of LDAP server. Currently "ad" for active directory and "ldap"
for other ldap servers. If not specified, then it is ldap. -->
<!--
<type>ad</type>
-->
<!-- LDAP attribute that holds the user ID (default: uid) -->
<uidattr>uid</uidattr>
<objectclass>posixAccount</objectclass>
<!-- LDAP attribute that holds the cleartext or hashed password
(not needed when pwscheme is set to 'bind') -->
<pwattr>userPassword</pwattr>
<!-- if you use included jabberd.schema use this:
<uidattr>jid</uidattr>
<objectclass>jabberUser</objectclass>
<pwattr>jabberPassword</pwattr>
-->
<!-- Attribute that holds jabber account status. Must be TRUE for AD,
and 1 for other LDAP server.
If not specified, then it will not be used. -->
<!--
<validattr>valid</validattr>
-->
<!-- Group that users must be members of
If this is set, only user that are members of the specified LDAP
group can log in. The group must be specified with its full
distinguished name -->
<!--
<group_dn>cn=jabberdusers,ou=servicegroups,dc=example,dc=com</group_dn>
-->
<fulluid/>
<!-- If pwscheme is not defined, then passwords are stored in clear
text and digest authentication may be done.
If passwords are hashed, then you cannot use digest authentication
and should use plain text authentication.
Any of sha, ssha, crypt, bind and clear may be specified.
'sha' specifies that the attribute in pwattr holds a base-64
encoded SHA-1 hashed password beginning with the string {SHA}.
'ssha' specifies that the attribute in pwattr holds a base-64
SHA-1 hashed password appended with 32 bits of salt and beginning
with the string {SSHA}.
'crypt' specifies that the attribute in pwattr holds a UNIX-style
crypt(3) hashed password.
'bind' specifies that the password is not stored in an attribute
but is authenticated directly by the LDAP server by binding
using the user's DN. This should be compatible with the
widest variety of LDAP servers.
-->
<!-- <pwscheme>bind</pwscheme> -->
<!-- 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>
</ldapfull>
<!-- LDAP module configuration -->
<!-- Remember that you need to use PLAIN auth with LDAP backend -->
<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>
<!-- Enable the append-realm element if you want to append
realm value (usernam@realm) to the uidattr value
<append-realm/>
-->
<!-- Alternatively to <uidattr/> and <append-realm/> you may
specify full LDAP search <query/> that will be used to
get user objects from directory.
The following replacements take place:
%u is replaced by user login name
%r is replaced by user login realm
When <query/> is specified, <uidattr/> and <append-realm/>
are unused and take no effect. -->
<!--
<query>(&amp;(mail=%u@%r)(objectClass=inetOrgPerson))</query>
-->
<!-- 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>
<!-- if you want to configure more than one LDAP server
create ldap1, ldap2 etc. sections
<ldap1>
</ldap1>
-->
<!-- Pipe module configuration -->
<pipe>
<!-- Program to execute -->
<exec>/usr/bin/pipe-auth.pl</exec>
</pipe>
</authreg>
</c2s>
<!--
vim: syntax=xml
-->

705
jabber/._cfg0000_c2s.xml.dist Normal file
View File

@ -0,0 +1,705 @@
<!-- 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
the process ID from outside the process (eg for control scripts) -->
<pidfile>/var/run/jabber/${id}.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 an SSL certificate and private key to use when
setting up an encrypted channel with the router. From
SSL_CTX_use_certificate_chain_file(3): "The certificates must be
in PEM format and must be sorted starting with the subject's
certificate (actual client or server certificate), followed
by intermediate CA certificates if applicable, and ending
at the highest level (root) CA" (the latter one being optional).
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/jabber/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/log/jabber/c2s.log</file>
-->
<!-- Filename of the debug logfile -->
<!--
<debug>/var/log/jabber/debug-${id}.log</debug>
-->
</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.
You may leave the content of the <id/> empty to setup default
virtual host setup, that will be used for all present but not
configured otherwise SM domains.
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.
If empty "" realm is specified, the PAM backend wil authenticate
using plain usernames, not JIDs.
pemfile
attribute specifies the file containing a SSL certificate and
private key for client connections. If this is non existant,
clients will not be offered the STARTTLS stream extension
From SSL_CTX_use_certificate_chain_file(3):
"The certificates must be in PEM format and must be sorted
starting with the subject's certificate (actual client or server
certificate), followed by intermediate CA certificates if
applicable, and ending at the highest level (root) CA"
(the latter one being optional).
verify-mode
SSL verify mode - see SSL_CTX_set_verify(3), mode parameter.
Sum of the following options:
SSL_VERIFY_NONE 0x00
SSL_VERIFY_PEER 0x01
SSL_VERIFY_FAIL_IF_NO_PEER_CERT 0x02
SSL_VERIFY_CLIENT_ONCE 0x04
Use 7 to require all clients to present _valid_ certificates.
cachain
SSL CA chain. Used to verify client certificates.
CA names published to client upon connection.
require-starttls
If this attribute is set to any value, clients must do STARTTLS
before they can authenticate. Until the stream is encrypted,
all packets will be dropped.
register-enable
Remove this attribute to disable account registrations.
instructions
Human-readable instructions to be returned to client when
registration is requested.
register-oob
URL to be attached as an alternative, out-of-band registration
method. Usually web-based http:// URL.
password-change
Password change only. When registration is disabled, it may
still be useful to allow clients to change their password. If
you want this, add this attribute with any value, when you need
registration disabled.
-->
<id register-enable='mu'>localhost.localdomain</id>
<!-- or
<id realm='company.int'
pemfile='/etc/jabber/server.pem'
verify-mode='7'
cachain='/etc/jabber/client_ca_certs.pem'
require-starttls='mu'
register-enable='mu'
instructions='Enter a username and password to register with this server.'
register-oob='http://example.org/register'
password-change='mu'
>example.net</id> -->
<!-- or the default host
<id password-change='mu' /> -->
<!-- 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>
<!-- 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>
-->
<!-- File containing an SSL certificate and private key for client
connections. From SSL_CTX_use_certificate_chain_file(3):
"The certificates must be in PEM format and must be sorted
starting with the subject's certificate (actual client or server
certificate), followed by intermediate CA certificates if
applicable, and ending at the highest level (root) CA"
(the latter one being optional).
Note: This certificate is ONLY used for old style SSL
connections on port 5223 (pre-STARTTLS). If you want to
use STARTTLS over the standard XMPP port 5222 then you
MUST specify the pemfile in the 'id' tag above. -->
<!--
<pemfile>/etc/jabber/server.pem</pemfile>
-->
<!-- SSL verify mode - see SSL_CTX_set_verify(3), mode parameter -->
<!--
<verify-mode>7</verify-mode>
-->
<!-- SSL CA chain. Used to verify client certificates. CA names published to client upon connection -->
<!--
<cachain>/etc/jabber/client_ca_certs.pem</cachain>
-->
<!-- Forward incoming HTTP clients to a real HTTP server -->
<!--
<httpforward>http://www.jabber.org/</httpforward>
-->
</local>
<!-- Input/output settings -->
<io>
<!-- Maximum number of file descriptors. This value sets an upper
limit on the number of users who may be logged in to this
server at a given time. Each user consumers one file
descriptor.
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.
Also note that this value only affects how many file descriptors
jabberd is able to handle internally. You may also need to
tell your operating system to allow jabberd to use more file
descriptors. On Linux this can be done using ulimit -n or by
changing the value of /proc/sys/fd/file-max.
(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 number of stanzas per second - if more than X stanzas
are sent in Y seconds, connection is throttled for Z seconds.
The format is:
<stanzas seconds='Y' throttle='Z'>X</stanzas>
Default Y 1, default Z is 5. Set X to 0 to disable -->
<stanzas>1000</stanzas>
<!-- 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>
<!-- Maximum stanza size - if more than given number of bytes
are read in one incoming stanza, the stream is closed
with policy-violation error.
Set to 0 to disable.
Values less than 16384 might not work. -->
<stanzasize>65535</stanzasize>
</limits>
<!-- Enable XEP-0138: Stream Compression -->
<!--
<compression/>
-->
<!-- 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>
<!-- Statistics -->
<stats>
<!-- file containing count of packets that went through -->
<!--
<packet>/var/spool/jabber/stats/c2s.packets</packet>
-->
</stats>
<!-- PBX integration -->
<pbx>
<!-- Commands named pipe path. Allows creating "fake" sessions
with given resource and status -->
<!--
<pipe>/var/run/jabber/pbx</pipe>
-->
<!-- Available commands:
START jid/resource [[priority ]status] [description]
STOP jid/resource [description]
where priority is integer between -128 and +127
and status is one of: CHAT, ONLINE, DND, AWAY, XA
-->
</pbx>
<!-- see-other-host error stream redirection support
This will redirect connections to specified domains to other host:port
Usefull when migrating service and DNS change did not propagate yet.
Note that to_address should be RFC 3986 compliant. -->
<stream_redirect>
<!--
<redirect requested_domain="some.domain" to_address="other.hostname" to_port="5269" />
<redirect requested_domain="other.domain" to_address="other.host" to_port="1234" />
-->
</stream_redirect>
<!-- Authentication/registration database configuration -->
<authreg>
<!-- Dynamic authreg modules path -->
<path>/usr/lib64/jabberd</path>
<!-- Backend module to use -->
<module>db</module>
<!-- 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. -->
<traditional>
<plain/>
<digest/>
</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/>
<gssapi/>
-->
</sasl>
</mechanisms>
<!-- Additional mechanisms that are also available when the
connection is encrypted. Ie. when START-TLS had been
negotiated, or user connected on SSL-wrapped port. -->
<ssl-mechanisms>
<!-- it's advisable that you disable plain in the above
<mechanisms/> section -->
<traditional>
<plain/>
</traditional>
<sasl>
<plain/>
<external/>
</sasl>
</ssl-mechanisms>
<!-- SQLite driver configuration -->
<sqlite>
<!-- Database name -->
<dbname>/var/spool/jabber/db/sqlite.db</dbname>
<!-- 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/>
<!-- SQLite busy-timeout in milliseconds. -->
<busy-timeout>2000</busy-timeout>
<!-- Passwords in DB may be stored in plain or hashed format -->
<!-- NOTE: If you are using hashed passwords, the only auth
method that will work is PLAIN.
Make sure that you disabled others in 'mechanisms'
sections of the config file. -->
<password_type>
<!-- only one may be enabled here -->
<plaintext/>
<!-- use crypt(3)ed passwords
<crypt/>
-->
<!-- use A1HASH passwords
This stores the MD5 digest of user:realm:password in the database
<a1hash/>
-->
</password_type>
</sqlite>
<!-- 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>
<!-- Passwords in DB may be stored in plain or hashed format -->
<!-- NOTE: If you are using hashed passwords, the only auth
method that will work is PLAIN.
Make sure that you disabled others in 'mechanisms'
sections of the config file. -->
<password_type>
<!-- only one may be enabled here -->
<plaintext/>
<!-- use crypt(3)ed passwords
<crypt/>
-->
<!-- use A1HASH passwords
This stores the MD5 digest of user:realm:password in the database
<a1hash/>
-->
<!-- use bcrypt passwords
NOTE: cost has to be higher than 3 and lower than 32
<bcrypt cost='10'/>
-->
</password_type>
</mysql>
<!-- PostgreSQL module configuration -->
<pgsql>
<!-- PostgreSQL connection info.
For the rest of the options see
http://www.postgresql.org/docs/8.0/interactive/libpq.html -->
<conninfo>dbname=jabberd2 user=jabberd2 password=secret</conninfo>
<!-- Alternatively you may set connection settings separately.
These are used only in absence of 'conninfo' -->
<!-- Database server host and port -->
<host>localhost</host>
<port>5432</port>
<!-- Database name -->
<dbname>jabberd2</dbname>
<!-- Database schema -->
<schema>public</schema>
<!-- Database username and password -->
<user>jabberd2</user>
<pass>secret</pass>
<!-- Passwords in DB may be stored in plain or hashed format -->
<!-- NOTE: If you are using hashed passwords, the only auth
method that will work is PLAIN.
Make sure that you disabled others in 'mechanisms'
sections of the config file. -->
<password_type>
<!-- only one may be enabled here -->
<plaintext/>
<!-- use crypt(3)ed passwords
<crypt/>
-->
<!-- use A1HASH passwords
This stores the MD5 digest of user:realm:password in the database
<a1hash/>
-->
</password_type>
</pgsql>
<!-- 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>
<!-- Berkeley DB module configuration -->
<db>
<!-- Directory to store database files under -->
<path>/var/spool/jabber/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>
<!-- LDAPFULL module configuration -->
<ldapfull>
<!-- LDAP server host and port (default: 389) -->
<uri>ldap://localhost/ ldaps://ldap.example.com/</uri>
<!-- DN to bind as for searches. If unspecified, the searches
will be done anonymously. -->
<!--
<binddn>cn=Directory Manager</binddn>
<bindpw>secret</bindpw>
-->
<!-- Type of LDAP server. Currently "ad" for active directory and "ldap"
for other ldap servers. If not specified, then it is ldap. -->
<!--
<type>ad</type>
-->
<!-- LDAP attribute that holds the user ID (default: uid) -->
<uidattr>uid</uidattr>
<objectclass>posixAccount</objectclass>
<!-- LDAP attribute that holds the cleartext or hashed password
(not needed when pwscheme is set to 'bind') -->
<pwattr>userPassword</pwattr>
<!-- if you use included jabberd.schema use this:
<uidattr>jid</uidattr>
<objectclass>jabberUser</objectclass>
<pwattr>jabberPassword</pwattr>
-->
<!-- Attribute that holds jabber account status. Must be TRUE for AD,
and 1 for other LDAP server.
If not specified, then it will not be used. -->
<!--
<validattr>valid</validattr>
-->
<!-- Group that users must be members of
If this is set, only user that are members of the specified LDAP
group can log in. The group must be specified with its full
distinguished name -->
<!--
<group_dn>cn=jabberdusers,ou=servicegroups,dc=example,dc=com</group_dn>
-->
<fulluid/>
<!-- If pwscheme is not defined, then passwords are stored in clear
text and digest authentication may be done.
If passwords are hashed, then you cannot use digest authentication
and should use plain text authentication.
Any of sha, ssha, crypt, bind and clear may be specified.
'sha' specifies that the attribute in pwattr holds a base-64
encoded SHA-1 hashed password beginning with the string {SHA}.
'ssha' specifies that the attribute in pwattr holds a base-64
SHA-1 hashed password appended with 32 bits of salt and beginning
with the string {SSHA}.
'crypt' specifies that the attribute in pwattr holds a UNIX-style
crypt(3) hashed password.
'bind' specifies that the password is not stored in an attribute
but is authenticated directly by the LDAP server by binding
using the user's DN. This should be compatible with the
widest variety of LDAP servers.
-->
<!-- <pwscheme>bind</pwscheme> -->
<!-- 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>
</ldapfull>
<!-- LDAP module configuration -->
<!-- Remember that you need to use PLAIN auth with LDAP backend -->
<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>
<!-- Enable the append-realm element if you want to append
realm value (usernam@realm) to the uidattr value
<append-realm/>
-->
<!-- Alternatively to <uidattr/> and <append-realm/> you may
specify full LDAP search <query/> that will be used to
get user objects from directory.
The following replacements take place:
%u is replaced by user login name
%r is replaced by user login realm
When <query/> is specified, <uidattr/> and <append-realm/>
are unused and take no effect. -->
<!--
<query>(&amp;(mail=%u@%r)(objectClass=inetOrgPerson))</query>
-->
<!-- 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>
<!-- if you want to configure more than one LDAP server
create ldap1, ldap2 etc. sections
<ldap1>
</ldap1>
-->
<!-- Pipe module configuration -->
<pipe>
<!-- Program to execute -->
<exec>/usr/bin/pipe-auth.pl</exec>
</pipe>
</authreg>
</c2s>
<!--
vim: syntax=xml
-->

215
jabber/._cfg0000_router.xml Normal file
View File

@ -0,0 +1,215 @@
<!-- 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
the process ID from outside the process (eg for control scripts) -->
<pidfile>/var/run/jabber/${id}.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/log/jabber/router.log</file>
-->
<!-- Filename of the debug logfile -->
<!--
<debug>/var/log/jabber/debug-${id}.log</debug>
-->
</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>/etc/jabber/router-users.xml</users>
<!-- Shared secret used to identify XEP-0114 components (that is,
"jabber:component:accept" components that authenticate using
the Jabber Component Protocol's "handshake", for example
mu-conference). If this is commented out, support for XEP-0114
components will be disabled. -->
<secret>secret</secret>
<!-- File containing an SSL certificate and private key for client
connections. From SSL_CTX_use_certificate_chain_file(3):
"The certificates must be in PEM format and must be sorted
starting with the subject's certificate (actual client or
server certificate), followed by intermediate CA certificates
if applicable, and ending at the highest level (root) CA"
(the latter one being optional).
If this is commented out, connecting components will not be able
to request an SSL-encrypted channel. -->
<!--
<pemfile>/etc/jabber/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.
These file descriptors are really only used when a component
connects to the router. So unless you have a lot of components
for some reason then you probably don't need to change this
value.
(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.domain.com' 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>
-->
<!-- File containing packet filter rules.
May be used for fine grained packet routing control. -->
<filter>/etc/jabber/router-filter.xml</filter>
</aci>
<!-- Simple message logging to flat file
Remove <enabled/> tag to disable logging -->
<!--
<message_logging>
<enabled/>
<file>filename</file>
</message_logging>
-->
</router>
<!--
vim: syntax=xml
-->

215
jabber/._cfg0000_router.xml.dist Normal file
View File

@ -0,0 +1,215 @@
<!-- 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
the process ID from outside the process (eg for control scripts) -->
<pidfile>/var/run/jabber/${id}.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/log/jabber/router.log</file>
-->
<!-- Filename of the debug logfile -->
<!--
<debug>/var/log/jabber/debug-${id}.log</debug>
-->
</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>/etc/jabber/router-users.xml</users>
<!-- Shared secret used to identify XEP-0114 components (that is,
"jabber:component:accept" components that authenticate using
the Jabber Component Protocol's "handshake", for example
mu-conference). If this is commented out, support for XEP-0114
components will be disabled. -->
<secret>secret</secret>
<!-- File containing an SSL certificate and private key for client
connections. From SSL_CTX_use_certificate_chain_file(3):
"The certificates must be in PEM format and must be sorted
starting with the subject's certificate (actual client or
server certificate), followed by intermediate CA certificates
if applicable, and ending at the highest level (root) CA"
(the latter one being optional).
If this is commented out, connecting components will not be able
to request an SSL-encrypted channel. -->
<!--
<pemfile>/etc/jabber/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.
These file descriptors are really only used when a component
connects to the router. So unless you have a lot of components
for some reason then you probably don't need to change this
value.
(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.domain.com' 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>
-->
<!-- File containing packet filter rules.
May be used for fine grained packet routing control. -->
<filter>/etc/jabber/router-filter.xml</filter>
</aci>
<!-- Simple message logging to flat file
Remove <enabled/> tag to disable logging -->
<!--
<message_logging>
<enabled/>
<file>filename</file>
</message_logging>
-->
</router>
<!--
vim: syntax=xml
-->

323
jabber/._cfg0000_s2s.xml Normal file
View File

@ -0,0 +1,323 @@
<!-- 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
the process ID from outside the process (eg for control scripts) -->
<pidfile>/var/run/jabber/${id}.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 an SSL certificate and private key to use when
setting up an encrypted channel with the router. From
SSL_CTX_use_certificate_chain_file(3): "The certificates must be
in PEM format and must be sorted starting with the subject's
certificate (actual client or server certificate), followed
by intermediate CA certificates if applicable, and ending
at the highest level (root) CA" (the latter one being optional).
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/jabber/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/log/jabber/s2s.log</file>
-->
<!-- Filename of the debug logfile -->
<!--
<debug>/var/log/jabber/debug-${id}.log</debug>
-->
</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>
<!-- Multihomed machines (with more than one interface and IP address)
need to specify outgoing S2S connections interface/address.
If not set, the <ip> section address above is used. -->
<!--
<origins>
<ip>1.2.3.4</ip>
<ip>fe80::202:b3ff:fe1e:8329</ip>
</origins>
-->
<!-- 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 an SSL certificate and private key to use when setting
up encrypted s2s connections with other servers (STARTTLS + Dialback).
From SSL_CTX_use_certificate_chain_file(3): "The certificates must be
in PEM format and must be sorted starting with the subject's
certificate (actual client or server certificate), followed
by intermediate CA certificates if applicable, and ending
at the highest level (root) CA" (the latter one being optional).
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>/etc/jabber/server.pem</pemfile>
-->
<!-- SSL verify mode - see SSL_CTX_set_verify(3), mode parameter -->
<!--
<verify-mode>7</verify-mode>
-->
<!-- File containing an optional SSL certificate chain file for SSL
connections. -->
<!--
<cachain>/etc/jabber/cachain.pem</cachain>
-->
</local>
<!-- input/output settings -->
<io>
<!-- Maximum number of file descriptors. Note that the number of
possible connections will be slightly less than this, because
s2s itself can use some on its own. If the supply of file
descriptors is exhausted, new incoming connections will be
denied.
These connections are mainly consumed when we make a
connection to an external jabber server, or an external jabber
server connects to us. If you don't have a lot of users then
there's probably no need for s2s to establish connections to
external jabber servers and the default value here is probably
fine. On the other hand, if you have lots of users with lots
of remote buddies in their buddylist then s2s will need to have
lots of open connections with other jabber servers and you may
need to increase this value.
Note that this value only affects how many file descriptors
jabberd is able to handle internally. You may also need to
tell your operating system to allow jabberd to use more file
descriptors. On Linux this can be done using ulimit -n or by
changing the value of /proc/sys/fd/file-max.
(default: 1024) -->
<max_fds>1024</max_fds>
<!-- Rate limiting -->
<limits>
<!-- Maximum stanza size - if more than given number of bytes
are read in one incoming stanza, the stream is closed
with policy-violation error.
Set to 0 to disable.
Values less than 16384 might not work. -->
<stanzasize>65535</stanzasize>
</limits>
<!-- Enable XEP-0138: Stream Compression -->
<!--
<compression/>
-->
</io>
<!-- Timed checks -->
<check>
<!-- Interval between checks.
Checks will be run every n seconds.
0 disables all checks except DNS expiry. (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)
If stage 1 connection establishment fails and there are
alternative hosts for this route that have not failed
recently, they will be tried too before finally giving up.
0 disables queue expiry. (default: 60) -->
<queue>60</queue>
<!-- Queue retry timeout.
If the queue is older than this timeout, the connection
will not be retried even if there are alternative hosts
that have not failed recently.
0 disables retry expiry. (default: 300) -->
<retry>300</retry>
<!-- 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>
<!-- Interval between DNS result/bad host expiry.
0 disables expiry checks. (default: 300) -->
<dnscache>300</dnscache>
</check>
<!-- Statistics -->
<stats>
<!-- file containing count of packets that went through -->
<!--
<packet>/var/spool/jabber/stats/s2s.packets</packet>
-->
</stats>
<lookup>
<!-- SRV TCP services 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. -->
<!-- xmpp-server is mandated by the XMPP spec -->
<srv>xmpp-server</srv>
<!-- traditionally, jabber has been used -->
<srv>jabber</srv>
<!-- 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.
Connection attempts will be made to all IPv6 hosts before trying
IPv4 (see bad host timeout below). -->
<!--
<resolve-ipv6/>
-->
<!-- Minimum time that DNS lookup results are cached (overrides max below). -->
<min-ttl>30</min-ttl>
<!-- Maximum time that DNS lookup results are cached. -->
<max-ttl>86400</max-ttl>
<!-- Time /etc/hosts lookup results are cached for (default: 86400). -->
<etc-hosts-ttl>86400</etc-hosts-ttl>
<!-- Minimum time to wait before using hosts that we have failed to
establish a connection to (unless there are no alternatives).
Do not set this too low - it is required to detect permanent
problems like broken IPv6 connectivity in order to attempt IPv4.
0 disables bad host caching. (default: 3600) -->
<bad-host-timeout>3600</bad-host-timeout>
<!-- Disable the DNS cache (negative caching will still be done).
This is likely to negatively impact performance while saving
a small amount of memory since multiple DNS requests must
then be made for every re-connection. -->
<!--
<no-cache/>
-->
</lookup>
<!-- If this is enabled, domains which share the same host will re-use
existing outgoing connections. This is a potential security risk
as the SSL connection from the first domain will be re-used too. -->
<out-conn-reuse/>
<security>
<!-- Require TLS secured S2S connections -->
<!--
<require_tls/>
-->
<!--
Domain whitelisting
-->
<!--
<enable_whitelist/>
-->
<!-- Domain whitelisting
When defined, only whitelisted domains are allowed to connect -->
<!--
<whitelist_domain>domain1.tld</whitelist_domain>
<whitelist_domain>domain2.tld</whitelist_domain>
<whitelist_domain>other.tld</whitelist_domain>
-->
</security>
</s2s>
<!--
vim: syntax=xml
-->

323
jabber/._cfg0000_s2s.xml.dist Normal file
View File

@ -0,0 +1,323 @@
<!-- 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
the process ID from outside the process (eg for control scripts) -->
<pidfile>/var/run/jabber/${id}.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 an SSL certificate and private key to use when
setting up an encrypted channel with the router. From
SSL_CTX_use_certificate_chain_file(3): "The certificates must be
in PEM format and must be sorted starting with the subject's
certificate (actual client or server certificate), followed
by intermediate CA certificates if applicable, and ending
at the highest level (root) CA" (the latter one being optional).
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/jabber/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/log/jabber/s2s.log</file>
-->
<!-- Filename of the debug logfile -->
<!--
<debug>/var/log/jabber/debug-${id}.log</debug>
-->
</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>
<!-- Multihomed machines (with more than one interface and IP address)
need to specify outgoing S2S connections interface/address.
If not set, the <ip> section address above is used. -->
<!--
<origins>
<ip>1.2.3.4</ip>
<ip>fe80::202:b3ff:fe1e:8329</ip>
</origins>
-->
<!-- 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 an SSL certificate and private key to use when setting
up encrypted s2s connections with other servers (STARTTLS + Dialback).
From SSL_CTX_use_certificate_chain_file(3): "The certificates must be
in PEM format and must be sorted starting with the subject's
certificate (actual client or server certificate), followed
by intermediate CA certificates if applicable, and ending
at the highest level (root) CA" (the latter one being optional).
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>/etc/jabber/server.pem</pemfile>
-->
<!-- SSL verify mode - see SSL_CTX_set_verify(3), mode parameter -->
<!--
<verify-mode>7</verify-mode>
-->
<!-- File containing an optional SSL certificate chain file for SSL
connections. -->
<!--
<cachain>/etc/jabber/cachain.pem</cachain>
-->
</local>
<!-- input/output settings -->
<io>
<!-- Maximum number of file descriptors. Note that the number of
possible connections will be slightly less than this, because
s2s itself can use some on its own. If the supply of file
descriptors is exhausted, new incoming connections will be
denied.
These connections are mainly consumed when we make a
connection to an external jabber server, or an external jabber
server connects to us. If you don't have a lot of users then
there's probably no need for s2s to establish connections to
external jabber servers and the default value here is probably
fine. On the other hand, if you have lots of users with lots
of remote buddies in their buddylist then s2s will need to have
lots of open connections with other jabber servers and you may
need to increase this value.
Note that this value only affects how many file descriptors
jabberd is able to handle internally. You may also need to
tell your operating system to allow jabberd to use more file
descriptors. On Linux this can be done using ulimit -n or by
changing the value of /proc/sys/fd/file-max.
(default: 1024) -->
<max_fds>1024</max_fds>
<!-- Rate limiting -->
<limits>
<!-- Maximum stanza size - if more than given number of bytes
are read in one incoming stanza, the stream is closed
with policy-violation error.
Set to 0 to disable.
Values less than 16384 might not work. -->
<stanzasize>65535</stanzasize>
</limits>
<!-- Enable XEP-0138: Stream Compression -->
<!--
<compression/>
-->
</io>
<!-- Timed checks -->
<check>
<!-- Interval between checks.
Checks will be run every n seconds.
0 disables all checks except DNS expiry. (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)
If stage 1 connection establishment fails and there are
alternative hosts for this route that have not failed
recently, they will be tried too before finally giving up.
0 disables queue expiry. (default: 60) -->
<queue>60</queue>
<!-- Queue retry timeout.
If the queue is older than this timeout, the connection
will not be retried even if there are alternative hosts
that have not failed recently.
0 disables retry expiry. (default: 300) -->
<retry>300</retry>
<!-- 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>
<!-- Interval between DNS result/bad host expiry.
0 disables expiry checks. (default: 300) -->
<dnscache>300</dnscache>
</check>
<!-- Statistics -->
<stats>
<!-- file containing count of packets that went through -->
<!--
<packet>/var/spool/jabber/stats/s2s.packets</packet>
-->
</stats>
<lookup>
<!-- SRV TCP services 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. -->
<!-- xmpp-server is mandated by the XMPP spec -->
<srv>xmpp-server</srv>
<!-- traditionally, jabber has been used -->
<srv>jabber</srv>
<!-- 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.
Connection attempts will be made to all IPv6 hosts before trying
IPv4 (see bad host timeout below). -->
<!--
<resolve-ipv6/>
-->
<!-- Minimum time that DNS lookup results are cached (overrides max below). -->
<min-ttl>30</min-ttl>
<!-- Maximum time that DNS lookup results are cached. -->
<max-ttl>86400</max-ttl>
<!-- Time /etc/hosts lookup results are cached for (default: 86400). -->
<etc-hosts-ttl>86400</etc-hosts-ttl>
<!-- Minimum time to wait before using hosts that we have failed to
establish a connection to (unless there are no alternatives).
Do not set this too low - it is required to detect permanent
problems like broken IPv6 connectivity in order to attempt IPv4.
0 disables bad host caching. (default: 3600) -->
<bad-host-timeout>3600</bad-host-timeout>
<!-- Disable the DNS cache (negative caching will still be done).
This is likely to negatively impact performance while saving
a small amount of memory since multiple DNS requests must
then be made for every re-connection. -->
<!--
<no-cache/>
-->
</lookup>
<!-- If this is enabled, domains which share the same host will re-use
existing outgoing connections. This is a potential security risk
as the SSL connection from the first domain will be re-used too. -->
<out-conn-reuse/>
<security>
<!-- Require TLS secured S2S connections -->
<!--
<require_tls/>
-->
<!--
Domain whitelisting
-->
<!--
<enable_whitelist/>
-->
<!-- Domain whitelisting
When defined, only whitelisted domains are allowed to connect -->
<!--
<whitelist_domain>domain1.tld</whitelist_domain>
<whitelist_domain>domain2.tld</whitelist_domain>
<whitelist_domain>other.tld</whitelist_domain>
-->
</security>
</s2s>
<!--
vim: syntax=xml
-->

811
jabber/._cfg0000_sm.xml Normal file
View File

@ -0,0 +1,811 @@
<!-- Session manager configuration -->
<sm>
<!-- Our ID on the network (default: sm) -->
<id>sm</id>
<!-- The process ID file. Comment this out if you don't need to know
the process ID from outside the process (eg for control scripts) -->
<pidfile>/var/run/jabber/${id}.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 an SSL certificate and private key to use when
setting up an encrypted channel with the router. From
SSL_CTX_use_certificate_chain_file(3): "The certificates must be
in PEM format and must be sorted starting with the subject's
certificate (actual client or server certificate), followed
by intermediate CA certificates if applicable, and ending
at the highest level (root) CA" (the latter one being optional).
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/jabber/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/log/jabber/sm.log</file>
-->
<!-- Filename of the debug logfile -->
<!--
<debug>/var/log/jabber/debug-${id}.log</debug>
-->
</log>
<!-- Local network configuration -->
<local>
<!-- Who we identify ourselves as.
Users will have this as the domain part of their JID.
If you want your server to be accessible from other
Jabber servers, this IDs must be FQDN resolvable by DNSes.
If not set, the SM id is used. -->
<id>localhost.localdomain</id>
<!--
<id>vhost1.localdomain</id>
<id>vhost2.localdomain</id>
-->
</local>
<!-- Storage database configuration -->
<storage>
<!-- Dynamic storage modules path -->
<path>/usr/lib64/jabberd</path>
<!-- By default, we use the SQLite driver for all storage -->
<driver>db</driver>
<!-- Its also possible to explicitly list alternate drivers for
specific data types. -->
<!-- Store vcards in a ldapvcard database instead -->
<!--
<driver type='vcard'>ldapvcard</driver>
-->
<!-- Only ldapvcard driver implements published-roster: -->
<!--
<driver type='published-roster'>ldapvcard</driver>
-->
<!-- Use ldapvcard driver for published-roster-groups.
See description in section sm/user/template/mapped-groups.
Used by mod_published_roster.
See ldapvcard section for options.
When resolving group id to group name, it searches for
groupsobjectclass objects at groupsdn base using group id
(in groupsidattr) as key and returns the first value of
groupattr of first found entry.
E.g.. in general case, if group id is "some-dep", and groupsdn
is o=org, and class is jabberGroup, it searches for
(&(objectClass=jabberGroup)(cn=some-dep)) and returns value of
jabberPublishedItem attribute, which may contain textual description.
-->
<!--
<driver type='published-roster-groups'>ldapvcard</driver>
-->
<!-- Rate limiting -->
<limits>
<!-- Maximum queries per second - if more than X queries are sent in Y
seconds, connection is throttled for Z seconds. The format
is:
<queries seconds='Y' throttle='Z'>X</bytes>
Default Y is 5, default Z is 60. set X to 0 to disable. -->
<!--
<queries>3</queries>
-->
</limits>
<!-- SQLite driver configuration -->
<sqlite>
<!-- Database name -->
<dbname>/var/spool/jabber/db/sqlite.db</dbname>
<!-- Transaction 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/>
<!-- SQLite busy-timeout in milliseconds. -->
<busy-timeout>2000</busy-timeout>
</sqlite>
<!-- 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>
<!-- Transaction 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>
<!-- PostgreSQL connection info.
For the rest of the options see
http://www.postgresql.org/docs/8.0/interactive/libpq.html -->
<conninfo>dbname=jabberd2 user=jabberd2 password=secret</conninfo>
<!-- Alternatively you may set connection settings separately.
These are used only in absence of 'conninfo' -->
<!-- Database server host and port -->
<host>localhost</host>
<port>5432</port>
<!-- Database name -->
<dbname>jabberd2</dbname>
<!-- Database schema -->
<schema>public</schema>
<!-- Database username and password -->
<user>jabberd2</user>
<pass>secret</pass>
<!-- Transaction 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. This does not support roster
maxitems or offline userquota (because the mod_roster
implementation does not implement the 'count' callback). -->
<db>
<!-- Directory to store database files under -->
<path>/var/spool/jabber/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>
<!-- Filesystem driver configuration -->
<fs>
<!-- Directory to store database files under. -->
<path>/var/spool/jabber/fs</path>
</fs>
<!-- LDAPVCARD driver configuration -->
<ldapvcard>
<!-- LDAP server host and port (default: 389) -->
<uri>ldap://localhost/ ldaps://ldap.example.com/</uri>
<!-- DN to bind as for searches. If unspecified, the searches
will be done anonymously. -->
<!--
<binddn>cn=Directory Manager</binddn>
<bindpw>secret</bindpw>
-->
<!-- see authreg.ldapfull in c2s.xml for description. -->
<!--
<type>ad</type>
-->
<!-- LDAP attribute that holds the user ID (default: uid) -->
<uidattr>uid</uidattr>
<objectclass>posixAccount</objectclass>
<pwattr>userPassword</pwattr>
<!-- if you use included jabberd.schema use this:
<uidattr>jid</uidattr>
<objectclass>jabberUser</objectclass>
<pwattr>jabberPassword</pwattr>
-->
<!-- Realm to append to uidattr. -->
<!--
<realm>example.org</realm>
-->
<!-- see authreg.ldapfull in c2s.xml for description. -->
<!--
<validattr>valid</validattr>
-->
<!-- 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>o=Example Corp.</basedn>
<!-- attribute that holds published group name or id,
jabberPublishedGroup if not set -->
<!--
<groupattr>jabberPublishedGroup</groupattr>
-->
<!-- this option is helpful if your schema does not have designated
attribute that holds jabber group name
you can use any attribute in <groupattr> i.e. 'distinguishedName'
and then extract a part of it using Regular Expression;
first matching () group will be used -->
<!--
<groupattr_regex>OU=([^,]*),</groupattr_regex>
-->
<!-- boolean attribute that tells whether or not to publish this user
jabberPublishedItem by default -->
<!--
<publishedattr>jabberPublishedItem</publishedattr>
-->
<!-- If value specified, then keep cache of "published-roster"
database, which is used for all users. Cache is renewed when kept more seconds than value
specified. Setting this value increases perfomance of publishing
roster. If not specified, then we don't keep cache. -->
<publishedcachettl>60</publishedcachettl>
<mapped-groups>
<!-- If turned on, then mapping of group ids to names with
LDAP will works. -->
<!--
<map-groups/>
-->
<!-- base for searches for group id to group name mappings -->
<basedn>ou=jabbergroups, o=Example Corp.</basedn>
<!-- what objectclass to search, jabberGroup by default -->
<!--
<objectclass>jabberGroup</objectclass>
-->
<!-- what attribute to search, cn by default -->
<!--
<idattr>cn</idattr>
-->
<!-- attribute with text group name, description by default -->
<!--
<nameattr>description</nameattr>
-->
</mapped-groups>
</ldapvcard>
</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.localdomain</jid>
</acl>
<!-- These JIDs can send broadcast messages (announce, motd) -->
<!--
<acl type='broadcast'>
<jid>nocstaff1@localhost.localdomain</jid>
<jid>nocstaff2@localhost.localdomain</jid>
</acl>
-->
<!-- These JIDs will receive messages addressed to the sm itself
(help requestes and such) -->
<!--
<acl type='messages'>
<jid>support@localhost.localdomain</jid>
</acl>
-->
<!-- These JIDs can discover active user/session information -->
<!--
<acl type='disco'>
<jid>webstatus@localhost.localdomain</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 it's 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>
<!-- Dynamic sm modules path -->
<path>/usr/lib64/jabberd</path>
<!-- 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'>
<module>status</module> <!-- record status information -->
</chain>
<!-- 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>status</module> <!-- update status information -->
<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>status</module> <!-- update status information -->
<module>privacy</module> <!-- manage privacy lists -->
<module>roster</module> <!-- handle roster get/sets and s10ns -->
<module>vacation</module> <!-- manage vacation settings -->
<!-- <module>pep</module> <!- - personal eventing -->
<module>iq-vcard</module> <!-- store and retrieve the user's vcard -->
<module>iq-ping</module> <!-- return the server ping -->
<module>iq-private</module> <!-- manage the user's private data store -->
<module>disco</module> <!-- respond to agents requests from sessions -->
<module>amp</module> <!-- advanced message processing -->
<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'>
<!-- <module>pep</module> <!- - personal eventing -->
</chain>
<!-- 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-ping</module> <!-- return the server ping -->
<module>iq-time</module> <!-- return the current server time -->
<module>iq-version</module> <!-- return the server name and version -->
<module>amp</module> <!-- advanced message processing -->
<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 -->
<module>status</module> <!-- track status information -->
<module>presence</module> <!-- proces server presence subscriptions -->
</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>amp</module> <!-- advanced message processing -->
<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>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 if 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>roster-publish</module> <!-- load the published roster -->
<module>privacy</module> <!-- load privacy lists -->
<module>vacation</module> <!-- load vacation settings -->
</chain>
<!-- user-unload. The modules in this chain are called right
after last per-user session is destroyed. -->
<chain id='user-unload'>
</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>offline</module> <!-- bounce queued messages -->
<module>privacy</module> <!-- delete privacy lists -->
<module>roster</module> <!-- delete roster -->
<module>vacation</module> <!-- delete vacation settings -->
<module>status</module> <!-- delete status information -->
<module>iq-last</module> <!-- delete last logout time -->
<module>iq-private</module> <!-- delete private data -->
<module>iq-vcard</module> <!-- delete vcard -->
</chain>
<!-- disco-extend. The modules in this chain are called when a disco
info request is send to session manager. It implements XEP-0128
Service Discovery Extensions mechanizm to add additional
information to disco#info reply. -->
<chain id='disco-extend'>
<module>iq-version</module> <!-- add XEP-xxxx Software Information -->
<module>help</module> <!-- add XEP-0157 Contact Addresses -->
</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 XEP-0114 components,
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>
<!-- Server information added to server discovery information
in http://jabber.org/network/serverinfo jabber:x:data form. (XEP-0157)
May contain many values per item -->
<!--
<serverinfo>
<admin-addresses>
<value>mailto:xmpp@localhost.localdomain</value>
<value>xmpp:admins@localhost.localdomain</value>
</admin-addresses>
<abuse-addresses>
<value>mailto:abuse@localhost.localdomain</value>
<value>xmpp:abuse@localhost.localdomain</value>
</abuse-addresses>
<feedback-addresses>
<value>http://example.org/feedback.php</value>
</feedback-addresses>
<sales-addresses/>
<security-addresses/>
<support-addresses/>
</serverinfo>
-->
</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 user creation 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/>
-->
<!-- Define maximum size in bytes of fields of vcards.
There is a recommendation that the avatar picture SHOULD NOT
be larger than 16 KiB. -->
<!--
<vcard>
<max-field-size>
<default>16384</default>
<avatar>16384</avatar>
</max-field-size>
</vcard>
-->
<!-- Templates. If defined, the contents of these files will be
stored in the users data store when they are created. -->
<template>
<!-- Uncomment <publish> if you wish to forcibly publish
roster template from ldap on each user login -->
<!--
<publish>
-->
<!-- Key used for fetching published roster items.
Only one might be set at a time.
If not set, all items are fetched. -->
<!--
<fetch-key>
<domain/>
<user/>
<fixed>grouping-key</fixed>
</fetch-key>
-->
<!-- If <check-remove-domain> given, then published contact is checked
against sm user database and if user is unknown to sm, contact
will be deleted from user's roster (if it is in roster).
If no domain set (tag empty) all contacts are checked. -->
<!--
<check-remove-domain>jabber.example.com</check-remove-domain>
-->
<!-- Alternatively if <force-create-contacts/> is not commented,
published contact is added to sm user database
and user set known to sm, so it won't auto-unsubscribe
on connection established -->
<!--
<force-create-contacts/>
-->
<!-- Keep cache of "active" database specified number of seconds.
This will significantly speed up publishing of roster.
If unspecified or 0, no cache is used. -->
<active-cache-ttl>60</active-cache-ttl>
<!-- If <fix-subscriptions/> is not commented, set "to" and "from" subscriptions of
user's contacts to subscriptions of corresponding published
contacts. -->
<!--
<fix-subscriptions/>
-->
<!-- If <override-names/> is uncommented, then displayed names of
contacts in user's roster will be updated accordingly to
published roster (if they differ). If commented, then user can
rename contacts in roster -->
<!--
<override-names/>
-->
<!-- when mapped-groups is on (<map-groups/> is uncommented), the actual
group names for published contacts are read from
published-roster-groups storage type, which may be set
to ldapvcard driver. The key for searching is published user's
group, and returned value is used as group name. So you can assign
textual group IDs to users rather then group names.
group-cache-ttl keeps cache of mapping from group id to name for
specified number of seconds. If unspecified or 0, no cache is used.
-->
<!--
<mapped-groups>
<map-groups/>
<group-cache-ttl>120</group-cache-ttl>
</mapped-groups>
-->
<!-- If <force-groups> is commented out, published roster's contact
added to user's roster only when user does not have this contact.
If <force-groups> is uncommented, then these checks are performed
against each roster item already in user's roster:
If roster item already present in user's roster in
group of same name, no changes are made with this group (note
that contact may be in more than one group).
If <prefix> or <suffix> are given, then contact removed
from any matching groups.
After that, contact is added to group from published roster.
In other words, all groups of updated contact, that match prefix
or suffix, are replaced with group of published contact.
This is done because there is no way to determine that group was
published or greated by user. -->
<!--
<force-groups>
<prefix>MyOrg.</prefix>
<suffix>(MyOrg)</suffix>
</force-groups>
-->
<!--
</publish>
-->
<!-- If defined, the contents of these files will be
stored in the users data store when they are created. -->
<!-- If you defined publish, you should comment-out <roster> -->
<!--
<roster>/etc/jabber/templates/roster.xml</roster>
-->
</template>
</user>
<!-- Advanced Message Processing module configuration -->
<amp>
<!-- You can disable some actions -->
<!--
<disableactions>
<drop/>
<error/>
<alert/>
<notify/>
</disableactions>
-->
<!-- You can disable some conditions -->
<!--
<disableconditions>
<expireat/>
<matchresource/>
<deliver/>
</disableconditions>
-->
<!-- You need to enable this if your server has offline storage disabled -->
<!--
<offlinestoragedisabled/>
-->
</amp>
<!-- Offline module configuration -->
<offline>
<!-- Do not store messages in offline store -->
<!--
<dropmessages/>
-->
<!-- Store headline messages in offline store -->
<!--
<storeheadlines/>
-->
<!-- Do not store subscription requests in offline store -->
<!--
<dropsubscriptions/>
-->
<!-- Offline storage message quota.
Specifies how many messages will be stored in user offline store -->
<!--
<userquota>500</userquota>
-->
</offline>
<!-- roster module configuration -->
<roster>
<!-- maximum items per user roster -->
<!--
<maxitems>100</maxitems>
-->
</roster>
<!-- status module configuration -->
<status>
<!-- presence service resource
disabled when commented out -->
<!--
<resource>webstatus</resource>
-->
</status>
</sm>
<!--
vim: syntax=xml
-->

811
jabber/._cfg0000_sm.xml.dist Normal file
View File

@ -0,0 +1,811 @@
<!-- Session manager configuration -->
<sm>
<!-- Our ID on the network (default: sm) -->
<id>sm</id>
<!-- The process ID file. Comment this out if you don't need to know
the process ID from outside the process (eg for control scripts) -->
<pidfile>/var/run/jabber/${id}.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 an SSL certificate and private key to use when
setting up an encrypted channel with the router. From
SSL_CTX_use_certificate_chain_file(3): "The certificates must be
in PEM format and must be sorted starting with the subject's
certificate (actual client or server certificate), followed
by intermediate CA certificates if applicable, and ending
at the highest level (root) CA" (the latter one being optional).
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/jabber/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/log/jabber/sm.log</file>
-->
<!-- Filename of the debug logfile -->
<!--
<debug>/var/log/jabber/debug-${id}.log</debug>
-->
</log>
<!-- Local network configuration -->
<local>
<!-- Who we identify ourselves as.
Users will have this as the domain part of their JID.
If you want your server to be accessible from other
Jabber servers, this IDs must be FQDN resolvable by DNSes.
If not set, the SM id is used. -->
<id>localhost.localdomain</id>
<!--
<id>vhost1.localdomain</id>
<id>vhost2.localdomain</id>
-->
</local>
<!-- Storage database configuration -->
<storage>
<!-- Dynamic storage modules path -->
<path>/usr/lib64/jabberd</path>
<!-- By default, we use the SQLite driver for all storage -->
<driver>db</driver>
<!-- Its also possible to explicitly list alternate drivers for
specific data types. -->
<!-- Store vcards in a ldapvcard database instead -->
<!--
<driver type='vcard'>ldapvcard</driver>
-->
<!-- Only ldapvcard driver implements published-roster: -->
<!--
<driver type='published-roster'>ldapvcard</driver>
-->
<!-- Use ldapvcard driver for published-roster-groups.
See description in section sm/user/template/mapped-groups.
Used by mod_published_roster.
See ldapvcard section for options.
When resolving group id to group name, it searches for
groupsobjectclass objects at groupsdn base using group id
(in groupsidattr) as key and returns the first value of
groupattr of first found entry.
E.g.. in general case, if group id is "some-dep", and groupsdn
is o=org, and class is jabberGroup, it searches for
(&(objectClass=jabberGroup)(cn=some-dep)) and returns value of
jabberPublishedItem attribute, which may contain textual description.
-->
<!--
<driver type='published-roster-groups'>ldapvcard</driver>
-->
<!-- Rate limiting -->
<limits>
<!-- Maximum queries per second - if more than X queries are sent in Y
seconds, connection is throttled for Z seconds. The format
is:
<queries seconds='Y' throttle='Z'>X</bytes>
Default Y is 5, default Z is 60. set X to 0 to disable. -->
<!--
<queries>3</queries>
-->
</limits>
<!-- SQLite driver configuration -->
<sqlite>
<!-- Database name -->
<dbname>/var/spool/jabber/db/sqlite.db</dbname>
<!-- Transaction 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/>
<!-- SQLite busy-timeout in milliseconds. -->
<busy-timeout>2000</busy-timeout>
</sqlite>
<!-- 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>
<!-- Transaction 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>
<!-- PostgreSQL connection info.
For the rest of the options see
http://www.postgresql.org/docs/8.0/interactive/libpq.html -->
<conninfo>dbname=jabberd2 user=jabberd2 password=secret</conninfo>
<!-- Alternatively you may set connection settings separately.
These are used only in absence of 'conninfo' -->
<!-- Database server host and port -->
<host>localhost</host>
<port>5432</port>
<!-- Database name -->
<dbname>jabberd2</dbname>
<!-- Database schema -->
<schema>public</schema>
<!-- Database username and password -->
<user>jabberd2</user>
<pass>secret</pass>
<!-- Transaction 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. This does not support roster
maxitems or offline userquota (because the mod_roster
implementation does not implement the 'count' callback). -->
<db>
<!-- Directory to store database files under -->
<path>/var/spool/jabber/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>
<!-- Filesystem driver configuration -->
<fs>
<!-- Directory to store database files under. -->
<path>/var/spool/jabber/fs</path>
</fs>
<!-- LDAPVCARD driver configuration -->
<ldapvcard>
<!-- LDAP server host and port (default: 389) -->
<uri>ldap://localhost/ ldaps://ldap.example.com/</uri>
<!-- DN to bind as for searches. If unspecified, the searches
will be done anonymously. -->
<!--
<binddn>cn=Directory Manager</binddn>
<bindpw>secret</bindpw>
-->
<!-- see authreg.ldapfull in c2s.xml for description. -->
<!--
<type>ad</type>
-->
<!-- LDAP attribute that holds the user ID (default: uid) -->
<uidattr>uid</uidattr>
<objectclass>posixAccount</objectclass>
<pwattr>userPassword</pwattr>
<!-- if you use included jabberd.schema use this:
<uidattr>jid</uidattr>
<objectclass>jabberUser</objectclass>
<pwattr>jabberPassword</pwattr>
-->
<!-- Realm to append to uidattr. -->
<!--
<realm>example.org</realm>
-->
<!-- see authreg.ldapfull in c2s.xml for description. -->
<!--
<validattr>valid</validattr>
-->
<!-- 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>o=Example Corp.</basedn>
<!-- attribute that holds published group name or id,
jabberPublishedGroup if not set -->
<!--
<groupattr>jabberPublishedGroup</groupattr>
-->
<!-- this option is helpful if your schema does not have designated
attribute that holds jabber group name
you can use any attribute in <groupattr> i.e. 'distinguishedName'
and then extract a part of it using Regular Expression;
first matching () group will be used -->
<!--
<groupattr_regex>OU=([^,]*),</groupattr_regex>
-->
<!-- boolean attribute that tells whether or not to publish this user
jabberPublishedItem by default -->
<!--
<publishedattr>jabberPublishedItem</publishedattr>
-->
<!-- If value specified, then keep cache of "published-roster"
database, which is used for all users. Cache is renewed when kept more seconds than value
specified. Setting this value increases perfomance of publishing
roster. If not specified, then we don't keep cache. -->
<publishedcachettl>60</publishedcachettl>
<mapped-groups>
<!-- If turned on, then mapping of group ids to names with
LDAP will works. -->
<!--
<map-groups/>
-->
<!-- base for searches for group id to group name mappings -->
<basedn>ou=jabbergroups, o=Example Corp.</basedn>
<!-- what objectclass to search, jabberGroup by default -->
<!--
<objectclass>jabberGroup</objectclass>
-->
<!-- what attribute to search, cn by default -->
<!--
<idattr>cn</idattr>
-->
<!-- attribute with text group name, description by default -->
<!--
<nameattr>description</nameattr>
-->
</mapped-groups>
</ldapvcard>
</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.localdomain</jid>
</acl>
<!-- These JIDs can send broadcast messages (announce, motd) -->
<!--
<acl type='broadcast'>
<jid>nocstaff1@localhost.localdomain</jid>
<jid>nocstaff2@localhost.localdomain</jid>
</acl>
-->
<!-- These JIDs will receive messages addressed to the sm itself
(help requestes and such) -->
<!--
<acl type='messages'>
<jid>support@localhost.localdomain</jid>
</acl>
-->
<!-- These JIDs can discover active user/session information -->
<!--
<acl type='disco'>
<jid>webstatus@localhost.localdomain</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 it's 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>
<!-- Dynamic sm modules path -->
<path>/usr/lib64/jabberd</path>
<!-- 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'>
<module>status</module> <!-- record status information -->
</chain>
<!-- 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>status</module> <!-- update status information -->
<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>status</module> <!-- update status information -->
<module>privacy</module> <!-- manage privacy lists -->
<module>roster</module> <!-- handle roster get/sets and s10ns -->
<module>vacation</module> <!-- manage vacation settings -->
<!-- <module>pep</module> <!- - personal eventing -->
<module>iq-vcard</module> <!-- store and retrieve the user's vcard -->
<module>iq-ping</module> <!-- return the server ping -->
<module>iq-private</module> <!-- manage the user's private data store -->
<module>disco</module> <!-- respond to agents requests from sessions -->
<module>amp</module> <!-- advanced message processing -->
<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'>
<!-- <module>pep</module> <!- - personal eventing -->
</chain>
<!-- 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-ping</module> <!-- return the server ping -->
<module>iq-time</module> <!-- return the current server time -->
<module>iq-version</module> <!-- return the server name and version -->
<module>amp</module> <!-- advanced message processing -->
<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 -->
<module>status</module> <!-- track status information -->
<module>presence</module> <!-- proces server presence subscriptions -->
</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>amp</module> <!-- advanced message processing -->
<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>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 if 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>roster-publish</module> <!-- load the published roster -->
<module>privacy</module> <!-- load privacy lists -->
<module>vacation</module> <!-- load vacation settings -->
</chain>
<!-- user-unload. The modules in this chain are called right
after last per-user session is destroyed. -->
<chain id='user-unload'>
</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>offline</module> <!-- bounce queued messages -->
<module>privacy</module> <!-- delete privacy lists -->
<module>roster</module> <!-- delete roster -->
<module>vacation</module> <!-- delete vacation settings -->
<module>status</module> <!-- delete status information -->
<module>iq-last</module> <!-- delete last logout time -->
<module>iq-private</module> <!-- delete private data -->
<module>iq-vcard</module> <!-- delete vcard -->
</chain>
<!-- disco-extend. The modules in this chain are called when a disco
info request is send to session manager. It implements XEP-0128
Service Discovery Extensions mechanizm to add additional
information to disco#info reply. -->
<chain id='disco-extend'>
<module>iq-version</module> <!-- add XEP-xxxx Software Information -->
<module>help</module> <!-- add XEP-0157 Contact Addresses -->
</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 XEP-0114 components,
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>
<!-- Server information added to server discovery information
in http://jabber.org/network/serverinfo jabber:x:data form. (XEP-0157)
May contain many values per item -->
<!--
<serverinfo>
<admin-addresses>
<value>mailto:xmpp@localhost.localdomain</value>
<value>xmpp:admins@localhost.localdomain</value>
</admin-addresses>
<abuse-addresses>
<value>mailto:abuse@localhost.localdomain</value>
<value>xmpp:abuse@localhost.localdomain</value>
</abuse-addresses>
<feedback-addresses>
<value>http://example.org/feedback.php</value>
</feedback-addresses>
<sales-addresses/>
<security-addresses/>
<support-addresses/>
</serverinfo>
-->
</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 user creation 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/>
-->
<!-- Define maximum size in bytes of fields of vcards.
There is a recommendation that the avatar picture SHOULD NOT
be larger than 16 KiB. -->
<!--
<vcard>
<max-field-size>
<default>16384</default>
<avatar>16384</avatar>
</max-field-size>
</vcard>
-->
<!-- Templates. If defined, the contents of these files will be
stored in the users data store when they are created. -->
<template>
<!-- Uncomment <publish> if you wish to forcibly publish
roster template from ldap on each user login -->
<!--
<publish>
-->
<!-- Key used for fetching published roster items.
Only one might be set at a time.
If not set, all items are fetched. -->
<!--
<fetch-key>
<domain/>
<user/>
<fixed>grouping-key</fixed>
</fetch-key>
-->
<!-- If <check-remove-domain> given, then published contact is checked
against sm user database and if user is unknown to sm, contact
will be deleted from user's roster (if it is in roster).
If no domain set (tag empty) all contacts are checked. -->
<!--
<check-remove-domain>jabber.example.com</check-remove-domain>
-->
<!-- Alternatively if <force-create-contacts/> is not commented,
published contact is added to sm user database
and user set known to sm, so it won't auto-unsubscribe
on connection established -->
<!--
<force-create-contacts/>
-->
<!-- Keep cache of "active" database specified number of seconds.
This will significantly speed up publishing of roster.
If unspecified or 0, no cache is used. -->
<active-cache-ttl>60</active-cache-ttl>
<!-- If <fix-subscriptions/> is not commented, set "to" and "from" subscriptions of
user's contacts to subscriptions of corresponding published
contacts. -->
<!--
<fix-subscriptions/>
-->
<!-- If <override-names/> is uncommented, then displayed names of
contacts in user's roster will be updated accordingly to
published roster (if they differ). If commented, then user can
rename contacts in roster -->
<!--
<override-names/>
-->
<!-- when mapped-groups is on (<map-groups/> is uncommented), the actual
group names for published contacts are read from
published-roster-groups storage type, which may be set
to ldapvcard driver. The key for searching is published user's
group, and returned value is used as group name. So you can assign
textual group IDs to users rather then group names.
group-cache-ttl keeps cache of mapping from group id to name for
specified number of seconds. If unspecified or 0, no cache is used.
-->
<!--
<mapped-groups>
<map-groups/>
<group-cache-ttl>120</group-cache-ttl>
</mapped-groups>
-->
<!-- If <force-groups> is commented out, published roster's contact
added to user's roster only when user does not have this contact.
If <force-groups> is uncommented, then these checks are performed
against each roster item already in user's roster:
If roster item already present in user's roster in
group of same name, no changes are made with this group (note
that contact may be in more than one group).
If <prefix> or <suffix> are given, then contact removed
from any matching groups.
After that, contact is added to group from published roster.
In other words, all groups of updated contact, that match prefix
or suffix, are replaced with group of published contact.
This is done because there is no way to determine that group was
published or greated by user. -->
<!--
<force-groups>
<prefix>MyOrg.</prefix>
<suffix>(MyOrg)</suffix>
</force-groups>
-->
<!--
</publish>
-->
<!-- If defined, the contents of these files will be
stored in the users data store when they are created. -->
<!-- If you defined publish, you should comment-out <roster> -->
<!--
<roster>/etc/jabber/templates/roster.xml</roster>
-->
</template>
</user>
<!-- Advanced Message Processing module configuration -->
<amp>
<!-- You can disable some actions -->
<!--
<disableactions>
<drop/>
<error/>
<alert/>
<notify/>
</disableactions>
-->
<!-- You can disable some conditions -->
<!--
<disableconditions>
<expireat/>
<matchresource/>
<deliver/>
</disableconditions>
-->
<!-- You need to enable this if your server has offline storage disabled -->
<!--
<offlinestoragedisabled/>
-->
</amp>
<!-- Offline module configuration -->
<offline>
<!-- Do not store messages in offline store -->
<!--
<dropmessages/>
-->
<!-- Store headline messages in offline store -->
<!--
<storeheadlines/>
-->
<!-- Do not store subscription requests in offline store -->
<!--
<dropsubscriptions/>
-->
<!-- Offline storage message quota.
Specifies how many messages will be stored in user offline store -->
<!--
<userquota>500</userquota>
-->
</offline>
<!-- roster module configuration -->
<roster>
<!-- maximum items per user roster -->
<!--
<maxitems>100</maxitems>
-->
</roster>
<!-- status module configuration -->
<status>
<!-- presence service resource
disabled when commented out -->
<!--
<resource>webstatus</resource>
-->
</status>
</sm>
<!--
vim: syntax=xml
-->