sm.xml.dist.in

这是一个完全开放的

<!-- Session manager configuration -->
<sm>
  <!-- Our ID on the network. Users will have this as the domain part of
       their JID. If you want your server to be accessible from other
       Jabber servers, this ID must be resolvable by DNS.s
       (default: localhost) -->
  <id>localhost</id>

  <!-- The process ID file. comment this out if you don't need to know
       to know the process ID from outside the process (eg for control
       scripts) -->
  <pidfile>@localstatedir@/jabberd/pid/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 a SSL certificate and private key to use when
         setting up an encrypted channel with the router. If this is
         commented out, or the file can't be read, no attempt will be
         made to establish an encrypted channel with the router. -->
    <!--
    <pemfile>@sysconfdir@/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>@localstatedir@/jabberd/log/sm.log</file>
    -->
  </log>

  <!-- Storage database configuration -->
  <storage>
    <!-- By default, we use the MySQL driver for all storage -->
    <driver>mysql</driver>

    <!-- Its also possible to explicitly list alternate drivers for
         specific data types. -->
    <!-- Store vcards in a PostgreSQL database instead -->
    <!--
    <driver type='vcard'>pgsql</driver>
    -->

    <!-- 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>
      <!-- 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 -->
    <db>
      <!-- Directory to store database files under -->
      <path>@localstatedir@/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>
  </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</jid>
    </acl>

    <!-- These JIDs can send broadcast messages (announce, motd) -->
    <!--
    <acl type='broadcast'>
      <jid>nocstaff1@localhost</jid>
      <jid>nocstaff2@localhost</jid>
    </acl>
    -->

    <!-- These JIDs will receive messages addressed to the sm itself
         (help requestes and such) -->
    <!--
    <acl type='messages'>
      <jid>support@localhost</jid>
    </acl>
    -->

    <!-- These JIDs can discover active user/session information -->
    <!--
    <acl type='disco'>
      <jid>webstatus@localhost</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>

    <!-- 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'/>

    <!-- 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>iq-last</module>          <!-- update logout time -->
    </chain>

    <!-- in-sess. The modules in this chain are called when a packet