M2.1 - config.xml

M2.1 Broker config.xml details

Qpid Upgrade steps from M2

Here are the manual changes required to config.xml for M2.1:

1. Remove use of old password format

Replace line '<class>org.apache.qpid.server.security.auth.database.PlainPasswordVHostFilePrincipalDatabase</class>'
With '<class>org.apache.qpid.server.security.auth.database.PlainPasswordFilePrincipalDatabase</class>'
Change format of the password file '${conf}/passwdVhost' to be username:password
Rename file on disk '${conf}/passwdVhost' to '${conf}/passwd'
Replace config line '<value>${conf}/passwdVhost</value>' with '<value>${conf}/passwd</value>'
For details on how to configure the new ACLs to restore the per VirtualHost Access rights see Configure ACLs

2. Update package of AllowAll

Replace line '<class>org.apache.qpid.server.security.access.AllowAll</class>'
With '<class>org.apache.qpid.server.security.access.plugins.AllowAll</class>'

3. Remove all Security sections from virtualhosts

Changes from M2 configuration

There are a four sections with changes that have occurred since M2. Taking them in order as they appear in the file the first change is in the connector section. The protectio feature is new its purpose is to limit the underlying send and receive buffers so that they do not grow unbounded. Testing has shown this feature to affect performance so further work is required to fully understand the impact.

The advanced section now includes a boolean enableJMSXUserID which causes the broker to stamp every message with the UserID of the producing connection. This has an impact on performance so will be improved in a later release with client side setting of JMSXUserID and broker side verification, which is a low overhead.

The security section has had a couple of changes. The PlainPasswordVHostFilePrincipalDatabase was an early attempt to show how ACLs could be performed. The introduction of a more comprehensive ACL package now removes the need for that class and so the use of PlainPasswordFilePrincipalDatabase would be recommended instead. The change to ACLs also included the repackaging of the AllowAll ACL class to be in a pluings package.

The virtualhost sections now have new security sections based on the type of ACL being used. The documentation of which will occur on the a different page.

File Format

This is an overview of the top level of the config file. Description of each section is embedded below. Each section is then described in detail in their own section. Each section that has changes from M2 is highlighted.

<broker>
    <connector>
<!-- Type of connections and properties -->                      <!-- Additional features in M2.1 -->
    <management>
<!-- Enablement of management functionality -->
    <advanced>
<!-- Various advanced flags -->                                  <!-- Additional features in M2.1 -->  
    <security>
<!-- Definition of available security options -->                <!-- M2 Incompatible changes in M2.1 -->
    <virtualhosts>
<!-- Definition of available virtual hosts -->                   <!-- M2 Incompatible changes in M2.1 -->
    <heartbeat>
<!-- Heartbeat configuration -->
    <queue>
<!-- General queue configuration options-->
    <virtualhosts>
<!-- Configuration of various virtual hosts. -->
</broker>

Configuration Sections - Detailed Information

The following sections provide an element by element overview of the config.xml.

Broker

The setting of the prefixes for QPID_HOME and QPID_WORK allows environment variables to be used throughout the config.xml and removes the need for hard coding of paths in this file.

See the Environment Variables section of the Getting Started Guide for more information on these variables.

<broker>
    <prefix>${QPID_HOME}</prefix>
    <work>${QPID_WORK}</work>
    <conf>${prefix}/etc</conf>

Connector

The connector section allows configuration of SSL and related keystore settings. By default this section is commented out and thus SSL is not enabled.

<connector>
    <!-- Uncomment out this block and edit the keystorePath and keystorePassword
         to enable SSL support
    <ssl>
        <enabled>true</enabled>
        <sslOnly>true</sslOnly>
        <keystorePath>/path/to/keystore.ks</keystorePath>
        <keystorePassword>keystorepass</keystorePassword>
    </ssl>-->
    <qpidnio>false</qpidnio>
    <protectio>                                          <!-- New Feature in M2.1 -->
       <enabled>false</enabled>
       <readBufferLimitSize>262144</readBufferLimitSize>
       <writeBufferLimitSize>262144</writeBufferLimitSize>
    </protectio>
    <transport>nio</transport>
    <port>5672</port>
    <sslport>8672</sslport>
    <socketReceiveBuffer>32768</socketReceiveBuffer>
    <socketSendBuffer>32768</socketSendBuffer>
</connector>

Management

This element allows the user to switch the connectivity of the management console on/off i.e. if the enabled tag is set to false you will not be able to connect a management console to this broker instance. The JMX Management port is set to 8999 by default but it can be changed here in the XML or on the command line. The management console has the ability to utilise some additional Sun Binary Code License code to improve the security of JMX Connections. Full details of this can be found here.

<management>
        <enabled>true</enabled>
        <jmxport>8999</jmxport>
        <security-enabled>false</security-enabled>            
</management>

Advanced

The elements in this section are used under the covers in the broker. At present, we do not recommend any changes to these settings.

<advanced>
   <filterchain enableExecutorPool="true"/>
    <enablePooledAllocator>false</enablePooledAllocator>
    <enableDirectBuffers>false</enableDirectBuffers>
    <framesize>65535</framesize>
    <compressBufferOnQueue>false</compressBufferOnQueue>
    <enableJMSXUserID>false</enableJMSXUserID>           <!-- Additional features in M2.1 -->
</advanced>

Security

This section lists all the principal databases that are available for authentication and the default access control. The databases understand what SASL mechanisms can be used against their data and so are responsible for registering these SASL mechanisms. Currently we do not provide means of limiting these mechanisms.

<security>
    <principal-databases>
        <principal-database>
            <!-- A name for referencing this database-->
            <name>passwordfile</name>
            <!-- The type of principal database -->
            <class>org.apache.qpid.server.security.auth.database.PlainPasswordFilePrincipalDatabase</class>
            <!-- Any attributes associated with the database. Here it is a password file to load. -->
            <attributes>
                <attribute>
                    <name>passwordFile</name>
                    <value>${conf}/passwd</value>
                </attribute>
            </attributes>
        </principal-database>
    </principal-databases>
    <!-- This access value can be any access manager. The built in defaults are AllowAll and DenyAll -->
    <access>
        <class>org.apache.qpid.server.security.access.plugin.AllowAll</class>    <!-- NOTE class change in M2.1 -->
    </access>
    <!-- Properties required when running the JMX Management console. -->
    <jmx>
       <!-- Access file that allows users rights to access the management console. -->
       <access>${conf}/jmxremote.access</access>
       <!-- The principal database to use to authenticate users. -->
       <principal-database>passwordfile</principal-database>
    </jmx>        
</security>

Virtualhosts

This section allows you to define the set of virtual hosts which will be contained in your broker instance, and the message store & location for each. NB: The commented out section referencing BDBMessageStore should be used for all applications wishing to use persistence to disk.

If you are using transient messaging you can use the MemoryMessageStore, with the caveat that scalability for transient use is limited by heap size.

In our example config.xml, we define three virtual hosts which we commonly use for development (development), system testing (test) and integration testing (localhost). In the config.xml the per virtual host sections define both the Message Store in use (MemoryMessageStore for non-persistent applications or BDBMessageStore for persistent application usage) and the security for each virtual host. The security settings are under currently development so subject to changes.

The default virtual host for connections which do not specify a host on the url is 'test' in the example config.xml.

<virtualhost>
            <name>localhost</name>
            <localhost>
                <store>
                    <!-- <class>org.apache.qpid.server.store.berkeleydb.BDBMessageStore</class>
                    <environment-path>${work}/localhost-store</environment-path> -->

                    <class>org.apache.qpid.server.store.MemoryMessageStore</class>
                </store>                
            </localhost>
        </virtualhost>

Heartbeat

The Qpid broker sends an internal (only) heartbeat. This element allows configuration of the frequency of this heartbeat. At present, we recommend that you leave this section unchanged !

<heartbeat>
    <delay>0</delay>
    <timeoutFactor>2.0</timeoutFactor>
</heartbeat>

Queue

This should NOT be changed lightly as it sets the broker up to automatically bind queues to exchanges.

It could theoretically be used to prevent users creating new queues at runtime, assuming that you have created all queues/topics etc at broker startup. However, best advice is to leave unchanged for now.

<queue>
    <auto_register>true</auto_register>
</queue>

Virtualhosts

This element allows you to specify a location for the virtualhosts.xml file that you wish to use. If you are not using a subdirectory under $QPID_HOME you can provide a fully qualified path instead. For more information on the content of the virtualhosts.xml file please see Configure the Virtual Hosts via virtualhosts.xml

<virtualhosts>${conf}/virtualhosts.xml</virtualhosts>

Child pages

M2.1 - config.xml

M2.1 Broker config.xml details

Qpid Upgrade steps from M2

Changes from M2 configuration

File Format

Configuration Sections - Detailed Information

Broker

Connector

Management

Advanced

Security

Virtualhosts

Heartbeat

Queue

Virtualhosts