Context Navigation

4. Basic Configuration

This section provides a quick road map for the most basic configuration and testing of your Jabberd 2 installation. Basic setup for Jabberd 2 consists of these three steps:

Jabberd 2 is configured via its six XML files. For default installations, these configuration files can be found in /usr/local/etc/jabberd/, and they are accessible from /etc/jabberd if you created the symlink for this directory. Note that this section is easier to complete if you gather the required information in Section 2 beforehand.

4.1. Set Host Name in sm.xml and c2s.xml

The first step in basic configuration consists of setting the hostname in sm.xml and c2s.xml.

P Parameter: Hostname

Your server hostname (network ID) must be set in both c2s.xml and sm.xml so that the ID provides a network resolvable reference for your server. In c2s.xml this ID is found under the heading labeled Local network configuration (approx. line 63), and in sm.xml this ID is found under Session manager configuration (line 1). Edit sm.xml and c2s.xml so that this ID references your server.

In sm.xml :

 <sm>  <id>somemachine.somedomain.com</id>

In c2s.xml :

 <local>  <id>somemachine.somedomain.com</id>

As the c2s.xml file notes, this is the hostname that will be appended to your user names to create Jabber ID's, and it must be resolvable via DNS for Jabberd to be accessible via the Internet.

N Note

You may use just a domain name (somedomain.com) for your Jabberd 2 network ID if your DNS is configured properly to resolve that ID to your server. See Section 5.7. for information about setting up DNS SRV records for Jabberd 2.

4.2. Provision and Configure for Storage and Authentication Package(s)

Getting Jabberd 2 to work with your choice of external storage and authentication packages involves these steps:

Provision external package(s) to work with Jabberd 2
Configure sm.xml for your choice of storage package
Configure c2s.xml for your choice of authentication package

Most Jabberd 2 installations rely on a single package, such as MySQL, to provide both storage and authentication services. If your installation relies on a single package, you will need to configure this package for Jabberd 2 and then enter similar connection details in both sm.xml and c2s.xml.

P Parameters: Data Storage and Authentication Packages

Follow the guide to complete relevant subsections for your choice(s) of storage and authentication packages. (Berkeley DB, MySQL or PostgreSQL for storage. Berkeley DB, MySQL, PostgreSQL, PAM or OpenLDAP for authentication.)

Start by jumping to your selection of external storage package:

You will then need to provision (if necessary) and configure your authentication package. Once your external packages are prepared, and Jabberd is configured to use them, you will need to test your server installation.

4.3. Provision and Configure for Berkeley Berkeley DB

Berkeley DB provides the easiest means to getting your Jabberd 2 server up and running quickly. Jabberd 2 requires a minimum version of 4.1.24 or higher.

4.3.1. Provisioning Berkeley DB

Complete this section if you are using Berkeley DB for storage and/or authorization. Provisioning your system to use Berkeley DB is quite simple. Berkeley DB only needs a directory in which to store data files, and this directory should be owned by the jabber user and group.

P Parameter: Data Directory

Create a directory and set permissions (using the user and group created above) for Berkeley DB. (as superuser):

           mkdir -p /usr/local/var/jabberd/db
           chown -R jabber:jabber /usr/local/var/jabberd

Berkeley DB is now ready to be used with Jabberd.

4.3.2. Configure for Storage using Berkeley DB (sm.xml)

Complete this section if you are using Berkeley DB for storage. Jabberd 2 requires minimal configuration to use Berkeley DB for backend storage. Simply set the driver to use and specify the location for the database.

In sm.xml under the section labeled Storage database configuration, edit the driver to use db (Berkeley DB):

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

P Parameter: Data Directory

In sm.xml under the section labeled Berkeley DB driver configuration, set the path (created in section 4.3.1. above) for your database:

          <!-- Berkeley DB driver configuration -->
          <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>

Jabberd 2 is now configured to use Berkeley DB for storage.

If you wish to use an authentication package other than Berkeley DB, jump to your selection of authentication package:

Otherwise, continue on to 4.3.3. directly below to finish your Jabberd 2 configuration.

4.3.3. Configure for Authentication using Berkeley DB (c2s.xml)

Complete this section if you are using Berkeley DB for authentication. Jabberd 2 authentication configuration for Berkeley DB is the same as above, except that the information is contained in c2s.xml.

In c2s.xml under the section labeled Authentication/registration database configuration, edit the module to use db (Berkeley DB):

      <!-- Authentication/registration database configuration -->
      <authreg>
        <!-- Backend module to use -->
        <module>db</module>

P Parameter: Data Directory

In c2s.xml under the section labeled Berkeley DB module configuration, set the path (created in section 4.3.1. above) for your database:

          <!-- Berkeley DB module configuration -->
          <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>

Your Jabberd 2 configuration for storage and authentication is now complete. Jump to Test Server to begin testing your server before moving on other configuration tasks, such as configuring SSL, in Section 5.

4.4. Provision and Configure for MySQL

MySQL is the default Jabberd 2 package for storage and authentication.

4.4.1. Provision for MySQL

Complete this section if you are using MySQL for storage and/or authorization. In order to set up MySQL for Jabberd, you must run the setup script included in the Jabberd 2 distribution. After the script is run, you should create a user and then grant that user access to the database.

First, run the MySQL setup script. This script is located in '[Jabberd Source Files]/tools'. Switch to the tools directory and start the MySQL console (the MySQL server should already be running). Then, run the db-setup.mysql script from the MySQL console:

      mysql -u root -p
      mysql>\. db-setup.mysql

Now that a database for Jabberd exists in the MySQL data directory, create a MySQL user that Jabberd can use to connect to the MySQL server.

P Parameter: MySQL User and Password

From the MySQL console, run the SQL statement below, replacing secret with the password you have chosen for your Jabberd MySQL user:
          GRANT select,insert,delete,update ON jabberd2.* 
          to jabberd2@localhost IDENTIFIED by 'secret';

Note that the password secret is the default password used in the Jabberd configuration files for MySQL.

MySQL is now ready to be used with Jabberd.

N Note: Default MySQL Socket

Jabberd 2 stable 3 connects to the MySQL server socket at /tmp/mysql.sock. The default socket when installing MySQL from source is /var/lib/mysql/mysql.sock. You will need to create a symlink to /tmp/mysql.sock if it does not exist:
          ln -s /var/lib/mysql/mysql.sock /tmp/mysql.sock   

If you are unsure as to where your MySQL server socket is, consult your MySQL configuration file (usually located in /etc/my.cnf or /etc/mysql/my.cnf).

4.4.2. Configure for Storage using MySQL (sm.xml)

Complete this section if you are using MySQL for storage. Most installations using MySQL for storage will require only the setting of the driver, user and password.

In sm.xml under the section labeled Storage database configuration, make sure that the driver is to use mysql. (The driver should be set to mysql by default.):

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

P Parameter: MySQL User and Password

In sm.xml under the section labeled MySQL driver configuration, replace secret with your MySQL password. Change the user if you are not using the default user (jabberd2):

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

Note that you should change the host setting only if your MySQL server is running on a different host. You should change the port setting only if your MySQL server is running on a non-standard port (port 3306 is the default for MySQL installations). The transaction support section is self-explanatory.

Jabberd 2 is now configured to use MySQL for storage.

If you wish to use an authentication package other than MySQL, jump to your selection of authentication package:

Otherwise, continue on to 4.4.3. directly below to finish your Jabberd 2 configuration.

4.4.3. Configure for Authentication using MySQL (c2s.xml)

Complete this section if you are using MySQL for authentication. Jabberd 2 authentication configuration for MySQL is the same as above, except that the information is contained in c2s.xml.

P Parameter: Authentication Data Package

In c2s.xml under the section labeled Authentication/registration database configuration, make sure that the driver is to use mysql. (The driver should be set to mysql by default.):
          
          <authreg>
            
            <module>mysql</module>

P Parameter: MySQL User and Password

In c2s.xml under the section labeled MySQL module configuration, replace secret with your MySQL password. Change the user if you are not using the default user (jabberd2):

          <!-- MySQL module configuration -->
          <mysql>
            <!-- Database server host and port -->
            <host>localhost</host>
            <port>3306</port>

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

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

4.5. Provision and Configure for PostgreSQL

PostgreSQL, like MySQL provides a very manageable backend for storage and authentication. Unlike MySQL, PostgreSQL provides better unicode support.

4.5.1. Provision PostgreSQL

Complete this section if you are using PostgreSQL for storage and/or authorization. In order to set up PostgreSQL for Jabberd, you must create a database, create a PostgreSQL user and then run the PostgreSQL script included in the Jabberd 2 distribution.

Create the database for Jabberd. (The PostgreSQL server should already be running):

      createdb -U postgres jabberd2

The command above will create a database from which you will be able to run the script for setting up the Jabberd PostgreSQL database.

N Note: Unicode Support

If you want to enable Unicode support for your PostgreSQL database, change the command above to the following:
          createdb -U postgres -E UNICODE jabberd2

Now that your database is created, create a PostgreSQL user for the database.

P Parameter: PostgreSQL User and Password

To create your Jabberd database user, enter the command below:
          createuser -P -U postgres jabberd2

This command will initiate an interactive user creation script. When prompted, enter the password that Jabberd will use to connect to your PostgreSQL database:

      Enter password for user "jabberd2":
      Enter it again:
      Shall the new user be allowed to create databases? (y/n) n
      Shall the new user be allowed to create more new users? (y/n) n
      CREATE USER

The CREATE USER statement indicates that the command was successful.

After your jabberd user is created, you are ready to run the the PostgreSQL setup script. This script is located in '[Jabberd Source Files]/tools'. Switch to the tools directory and start the PostgreSQL console as the jabberd2 user:

      psql -U jabberd2 jabberd2

Then, run the db-setup.pgsql script from the PostgreSQL console:

      jabberd2=>\i db-setup.pgsql

PostgreSQL is now ready to be used with Jabberd 2.

4.5.2. Configure for Storage using PostgreSQL (sm.xml)

Complete this section if you are using PostgreSQL for storage. Most installations using PostgreSQL for storage will require only the setting of the driver, user and password.

In sm.xml under the section labeled Storage database configuration, edit the driver to use pgsql (PostgreSQL):

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

P Parameter: PostgreSQL User and Password

In sm.xml under the section labeled PostgreSQL driver configuration, replace secret with your PostgreSQL password. Change the user if you are not using the default user (jabberd2):

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

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

Note that you should change the host setting only if your PostgreSQL server is running on a different host. You should change the port setting only if your PostgreSQL server is running on a non-standard port (port 5432 is the default for PostgreSQL installations). The transaction support section is self-explanatory.

Jabberd 2 is now configured to use PostgreSQL for storage.

If you wish to use an authentication package other than PostgreSQL, jump to your selection of authentication package:

Otherwise, continue on to 4.5.3. directly below to finish your Jabberd 2 configuration.

4.5.3. Configure for Authentication using PostgreSQL (`c2s.xml`)

Complete this section if you are using PostgreSQL for authentication. Jabberd 2 authentication configuration for PostgreSQL is the same as above, except that the information is contained in c2s.xml.

In c2s.xml under the section labeled Authentication/registration database configuration, edit the module to use pgsql (PostgreSQL):

      <!-- Authentication/registration database configuration -->
      <authreg>
        <!-- Backend module to use -->
        <module>pgsql</module>

P Parameter: PostgreSQL User and Password

In c2s.xml under the section labeled PostgreSQL module configuration, replace secret with your PostgreSQL password. Change the user if you are not using the default user (jabberd2):

          <!-- PostgreSQL module configuration -->
          <pgsql>
            <!-- Database server host and port -->
            <host>localhost</host>
            <port>5432</port>

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

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

4.6. Provision and Configure for PAM

PAM (Pluggable Authentication Modules for Linux) provides built in authentication support for Jabberd 2.

4.6.1. Provision for PAM

Complete this section if you are using PAM for authorization. Authentication via PAM requires a valid PAM configuration file named jabberd. For many systems, this configuration file should be located under /etc/pam.d. Creation of Jabberd PAM configuration file is beyond the scope of this guide; however, a shortcut may be used to create this configuration file. Copy the system-auth configuration file to jabberd (as root):

      cp /etc/pam.d/system-auth /etc/pam.d/jabberd

This will create a PAM configuration file that can be used by Jabberd2.

I Important: PAM Authentication Requires PAM Database Access

Jabberd authentication via PAM requires that Jabberd2 has access to the PAM database. For many systems, this database is the /etc/shadow file. Thus, Jabberd2 must be run as root, or the jabberd user must be granted read permissions for this file. Running the Jabberd2 server as root is not recommended.

N Note: Winbind Can Be Used to Integrate NT Authentication with PAM

The Winbind package from the Samba project can be used to support Jabber authentication via Windows NT. With Winbind successfully installed and configured, configure Jabberd to use PAM for authentication. Then create the jabberd PAM configuration file as below:
          auth       required     pam_winbind.so
          password   required     pam_winbind.so
          account    required     pam_winbind.so
          session    required     pam_winbind.so      

PAM is now ready to be used with Jabberd 2. Continue on to begin configuring Jabberd 2 to authenticate against PAM.

4.6.2. Configure for Authentication using PAM (c2s.xml)

Complete this section if you are using PAM for authentication. Jabberd requires little configuration to use PAM.

In c2s.xml under the section labeled Authentication/registration database configuration, edit the module to use pam:

      <!-- Authentication/registration database configuration -->
      <authreg>
        <!-- Backend module to use -->
        <module>pam</module>

Users cannot create their own accounts when using PAM for authentication. Therefore, public account registration should be disabled, while auto-create should be enabled so that the session manager can create accounts the first time users log on.

In c2s.xml, look for the Registration configuration subsection under the Authentication/registration database configuration section. Commenting the enable tag as below will disable public registration:

      <!-- Registration configuration -->
      <register>
        <!-- Account registration is enabled by default (provided the
             auth/reg module in use supports it). Comment this out to
             disable. -->
        <!-- <enable/> -->

In sm.xml under the section labeled User options (near the bottom of the file), uncomment the auto-create tag as below so that the session manager will create a new Jabberd2 account the first time a user logs on:

      <!-- 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.

             Enableing this option will make it so that a user create 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/>

Your Jabberd 2 configuration for storage and authentication is now complete (provided that you have provisioned and configured for a storage package). Jump to Test Server to begin testing your server before moving on other configuration tasks, such as configuring SSL, in Section 5.

TODO: note that PAM should use SSL/TLS

4.7. Provision and Configure for OpenLDAP

OpenLDAP provides authentication support that is distributable across platforms and geography. Jabberd 2 requires a minimum version of OpenLDAP 2.1.0.

4.7.1. Provision for OpenLDAP

Complete this section if you are using OpenLDAP authorization. Your OpenLDAP installation should not require special configuration for Jabberd 2; however, at the time of writing (Jabberd 2 stable release 3), there is an important issue regarding Jabberd connection with OpenLDAP v3 servers. Jabberd 2 currently uses v2 syntax. By default, OpenLDAP v3 servers require v3 syntax.

There is a workaround for this issue. Add the following statement to your slapd.conf file, and restart your slapd daemon:

      allow bind_v2

This statement will allow your Jabberd 2 server to connect to your OpenLDAP v3 server.

4.7.2. Configure for Authentication using OpenLDAP (c2s.xml)

Complete this section if you are using OpenLDAP for authentication. OpenLDAP configuration is more detailed because configuration requires host and connection settings in addition to query settings.

In c2s.xml under the section labeled Authentication/registration database configuration, edit the driver to use ldap (OpenLDAP):

      <!-- Authentication/registration database configuration -->
      <authreg>
        <!-- Backend module to use -->
        <module>ldap<module>

P Parameter: LDAP Connection Settings

The first part of the LDAP module configuration in c2s.xml deals with the settings required to connect to your OpenLDAP server. The host must either be a hostname resolvable by the server or the IP address of the OpenLDAP server. Port 389 is the default port for OpenLDAP servers, so in most cases, port should be left as is. The v3 tag specifies whether your OpenLDAP server is v3. Uncomment this tag if it is. Leave the v3 tag commented for OpenLDAP v2 servers. Lastly, uncomment either the starttls or ssl tag if your server supports encryption (see notes below):
          
          <ldap>
            
            <host>ldap.example.com</host>
            <port>389</port>

I Important: Passwords are Transmitted in Clear Text

The current release of Jabberd 2 (stable 3) requires that plain text passwords be used when authenticating via OpenLDAP. Therefore, it is extremely important that you enable encryption. As noted above, encryption options are available only for connection with OpenLDAP v3 servers.

TODO: note that PAM should use SSL/TLS

N Note: Encryption Options

The author has had success using Jabberd 2 and STARTTLS with a recent version of the OpenLDAP server. STARTTLS runs over the standard port (389), so all that needs to be done to enable STARTTLS is to uncomment the v3 and starttls tags. On the other hand, the author has not had success using SSL encryption between Jabberd 2 and OpenLDAP. To set up SSL, you should specify the OpenLDAP SSL hostname (if different from the non-SSL hostname). This is often something like ldaps.example.com. More importantly, you should specify the SSL port. The standard SSL port (LDAPS) for OpenLDAP is 636. Lastly, you should uncomment the ssl tag.

P Parameter: OpenLDAP User and Password

The next part of the OpenLDAP configuration handles the user and password for queries on the OpenLDAP server. A user and password are required only if your OpenLDAP server does not permit anonymous binding (authentication) for the required searches. Uncomment this section if your OpenLDAP server requires authentication for connection. Note that the binddn is the full RDN (relative distinguished name) for the user. This may be something like cn=admin,ou=people,dc=example,dc=com :

P Parameter: LDAP Query Settings

Lastly, the user ID and base DN must be set for OpenLDAP queries. User ID is specified by the uidattr tags. This ID should be the attribute by which your users are uniquely identified under the specified base DN (distinguished name). In other words, when querying against the specified base DN, the specified uidattr should uniquely identify each user. The basedn attribute specifies the base against which queries are run. This can be the topmost DN of the OpenLDAP server, such as dc=example,dc=com or it can be an RDN below which the user entries are found, such as ou=people,ou=sales,dc=example,dc=com. Using a lower level RDN is likely to speed OpenLDAP queries. Lastly, if your configuration requires multiple realms, you can specify a base DN for each by using the realm attribute of the basedn tag. Note that if you are not using multiple realms, you need only to specify a single basedn without the realm attribute:
          
          <uidattr>uid</uidattr>

          
          <basedn realm='company'>o=Company.com</basedn>
          <basedn>o=Example Corp.</basedn>
        </ldap>

Below is an obfuscated view of the author's working OpenLDAP configuration:

      <!-- LDAP module configuration -->
      <ldap>
        <!-- LDAP server host and port (default: 389) -->
        <host>ldap.mydomain.org</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=admin,dc=mydomain,dc=org</binddn>
        <bindpw>snip</bindpw>
        -->          

        <!-- LDAP attribute that holds the user ID (default: uid) -->
        <uidattr>uid</uidattr>

        <!-- base DN of the tree. You should specify a DN for each
             authentication realm declared in the <local/> section above,
             by using the realm attribute. -->

        <basedn>ou=people,ou=design,dc=mydomain,dc=org</basedn>
      </ldap>

Users cannot create their own accounts when using OpenLDAP for authentication. Therefore, public account registration should be disabled, while auto-create should be enabled so that the session manager can create accounts the first time users log on.

      <!-- Registration configuration -->
      <register>
        <!-- Account registration is enabled by default (provided the
             auth/reg module in use supports it). Comment this out to
             disable. -->
        <!-- <enable/> -->

      <!-- 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.

             Enableing this option will make it so that a user create 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/>

Your Jabberd 2 configuration for storage and authentication is now complete (provided that you have provisioned and configured for a storage package). Jump to the next section, Test Server, to begin testing your server before moving on other configuration tasks, such as configuring SSL, in Section 5.

4.8. Test Server

After setting the hostname, provisioning external package(s), and configuring Jabberd to use your external package(s), your server is ready for testing.

C Checkpoint: Start Your Server

You should be able to start and test your Jabberd 2 server by using the Jabberd 2 startup script (as your jabber user):
        su
        su jabber
        cd /usr/local/bin
        ./jabberd  

N Note: Troubleshooting

If Jabberd does not start, make sure that any previous instances have stopped. These instances include all the Jabberd runtime components (jabberd, router, resolver, sm, s2s and c2s). Note that your jabber user (if created according to section 2.) may not have default PATH's; therefore, you should cd to the /usr/local/bin directory and run jabberd as above. Check that your chosen data package servers are running (except Berkeley DB, which does not require starting). Check your syslog for error messages. If your server fails to start, you can start Jabberd 2 with the debug option (note that this requires building Jabberd 2 with the debug option — see Section 3.3):
        /usr/local/bin/jabberd -D

I Important: Jabberd 2 Should Not Be Run as Superuser

As with all daemons, Jabberd 2 should not be run as superuser. Running Jabberd 2 as super-user not only risks damage to the system, but also running as super-user may create file permission problems.

N Note: Public Registration

Public registration for new users is enabled in Jabberd2 by default. Thus, when testing your server, you can create a new user by logging on as a new user.

C Checkpoint: Connect from a Machine on the Same Network

Once you have verified that your server is starting correctly, try connecting from a machine on the same network. In a Jabber client, enter a JID (Jabber ID) that uses the ID you set in sm.xml in Section 4.1, and try to connect to your server.

C Checkpoint: Connect from Client on Remote Network

If you are able to connect to your server on the same network, use a Jabber client to connect to it from a remote network. This will test that id is set properly and that the machine name is resolvable via DNS.

Your Jabberd 2 server is now ready to use. Continue to Common Configuration Tasks which details configuration options, such as enabling SSL connections.

This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/1.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

Download in other formats:

Plain Text

Context Navigation

4. Basic Configuration

4.1. Set Host Name in sm.xml and c2s.xml

4.2. Provision and Configure for Storage and Authentication Package(s)

4.3. Provision and Configure for Berkeley Berkeley DB

4.3.1. Provisioning Berkeley DB

4.3.2. Configure for Storage using Berkeley DB (sm.xml)

4.3.3. Configure for Authentication using Berkeley DB (c2s.xml)

4.4. Provision and Configure for MySQL

4.4.1. Provision for MySQL

4.4.2. Configure for Storage using MySQL (sm.xml)

4.4.3. Configure for Authentication using MySQL (c2s.xml)

4.5. Provision and Configure for PostgreSQL

4.5.1. Provision PostgreSQL

4.5.2. Configure for Storage using PostgreSQL (sm.xml)

4.5.3. Configure for Authentication using PostgreSQL (c2s.xml)

4.6. Provision and Configure for PAM

4.6.1. Provision for PAM

4.6.2. Configure for Authentication using PAM (c2s.xml)

4.7. Provision and Configure for OpenLDAP

4.7.1. Provision for OpenLDAP

4.7.2. Configure for Authentication using OpenLDAP (c2s.xml)

4.8. Test Server

Download in other formats:

4.5.3. Configure for Authentication using PostgreSQL (`c2s.xml`)