<!-- 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/jabberd2/sm.pid</pidfile>

  <!-- Router connection configuration -->
  <router>
    <!-- IP/port the router is waiting for connections on -->
    <ip>127.0.0.1</ip>            <!-- default: 127.0.0.1 -->
    <port>5347</port>             <!-- default: 5347 -->

    <!-- Username/password to authenticate as -->
    <user>jabberd</user>          <!-- default: jabberd -->
    <pass>secret</pass>           <!-- default: secret -->

    <!-- File containing 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/jabberd2/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/jabberd2/sm.log</file>
    -->

    <!-- Filename of the debug logfile -->
    <!--
    <debug>/var/log/jabberd2/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>45.79.188.247</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>
    -->

    <!-- Read mapping for group id <-> group name from ldap.
         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 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 5, default Z is 60. set X to 0 to disable. -->
      <!--
      <queries>3</queries>
      -->
    </limits>

    <!-- SQLite driver configuration -->
    <sqlite>
      <!-- Database name -->
      <dbname>/var/lib/jabberd2/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>
    </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>

      <!-- Transacation support. If this is commented out, transactions
           will be disabled. This might make database accesses faster,
           but data may be lost if jabberd crashes.

           This will need to be disabled if you are using a MySQL
           earlier than v3.23.xx, as transaction support did not appear
           until this version. -->
      <transactions/>
    </mysql>

    <!-- PostgreSQL driver configuration -->
    <pgsql>
      <!-- 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 username and password -->
      <user>jabberd2</user>
      <pass>secret</pass>

      <!-- Transacation support. If this is commented out, transactions
           will be disabled. This might make database accesses faster,
           but data may be lost if jabberd crashes. -->
      <transactions/>
    </pgsql>

    <!-- Berkeley DB driver configuration.  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>/usr/local/var/jabberd/db</path>

      <!-- Synchronize the database to disk after each write. If you
           disable this, database accesses may be faster, but data may
           be lost if jabberd crashes. -->
      <sync/>
    </db>

    <!-- Oracle driver configuration -->
    <oracle>
      <!-- Database server host and port. -->
      <host>localhost</host>
      <port>1521</port>

      <!-- Database name -->
      <dbname>jabberd2</dbname>

      <!-- Database username and password -->
      <user>jabberd2</user>
      <pass>secret</pass>
    </oracle>

    <!-- Filesystem driver configuration -->
    <fs>
      <!-- Directory to store database files under. -->
      <path>/var/lib/jabberd2/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 int 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>
      -->

      <!-- see authreg.ldapfull int 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, publish or not this user
           jabberPublishedItem by default -->
      <!--
      <publishedattr>jabberPublishedItem</publishedattr>
      -->

      <!-- If value specified, then keep cache of "published-roster"
           database. 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 reading 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 its compiled into the server.

       Serveral modules have a presence in more than one chain. It is
       possible to remove a module from one chain but not others, but
       this may cause strange behaviour. Make sure you know what you're
       doing. -->
  <modules>
    <!-- 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>