812 lines
30 KiB
XML
812 lines
30 KiB
XML
<!-- 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
|
|
-->
|