diff options
Diffstat (limited to 'doc/book/src/cpp-broker')
| -rw-r--r-- | doc/book/src/cpp-broker/AMQP-Messaging-Broker-CPP-Book.xml | 1 | ||||
| -rw-r--r-- | doc/book/src/cpp-broker/Active-Active-Cluster.xml | 561 | ||||
| -rw-r--r-- | doc/book/src/cpp-broker/Active-Passive-Cluster.xml | 236 | ||||
| -rw-r--r-- | doc/book/src/cpp-broker/Security.xml | 979 |
4 files changed, 895 insertions, 882 deletions
diff --git a/doc/book/src/cpp-broker/AMQP-Messaging-Broker-CPP-Book.xml b/doc/book/src/cpp-broker/AMQP-Messaging-Broker-CPP-Book.xml index 228c6a5e15..6122b12e18 100644 --- a/doc/book/src/cpp-broker/AMQP-Messaging-Broker-CPP-Book.xml +++ b/doc/book/src/cpp-broker/AMQP-Messaging-Broker-CPP-Book.xml @@ -53,7 +53,6 @@ <xi:include href="Security.xml"/> <xi:include href="LVQ.xml"/> <xi:include href="queue-state-replication.xml"/> - <xi:include href="Active-Active-Cluster.xml"/> <xi:include href="producer-flow-control.xml"/> <xi:include href="AMQP-Compatibility.xml"/> <xi:include href="Qpid-Interoperability-Documentation.xml"/> diff --git a/doc/book/src/cpp-broker/Active-Active-Cluster.xml b/doc/book/src/cpp-broker/Active-Active-Cluster.xml deleted file mode 100644 index 28db3876e2..0000000000 --- a/doc/book/src/cpp-broker/Active-Active-Cluster.xml +++ /dev/null @@ -1,561 +0,0 @@ -<?xml version="1.0" encoding="utf-8"?> -<!-- - -Licensed to the Apache Software Foundation (ASF) under one -or more contributor license agreements. See the NOTICE file -distributed with this work for additional information -regarding copyright ownership. The ASF licenses this file -to you under the Apache License, Version 2.0 (the -"License"); you may not use this file except in compliance -with the License. You may obtain a copy of the License at - -http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, -software distributed under the License is distributed on an -"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -KIND, either express or implied. See the License for the -specific language governing permissions and limitations -under the License. - ---> - -<section id="chap-Messaging_User_Guide-Active_Active_Cluster"> - <title>Active-active Messaging Clusters</title> - <para> - Active-active Messaging Clusters provide fault tolerance by ensuring that every broker in a <firstterm>cluster</firstterm> has the same queues, exchanges, messages, and bindings, and allowing a client to <firstterm>fail over</firstterm> to a new broker and continue without any loss of messages if the current broker fails or becomes unavailable. <firstterm>Active-active</firstterm> refers to the fact that all brokers in the cluster can actively serve clients. Because all brokers are automatically kept in a consistent state, clients can connect to and use any broker in a cluster. Any number of messaging brokers can be run as one <firstterm>cluster</firstterm>, and brokers can be added to or removed from a cluster while it is in use. - </para> - <para> - High Availability Messaging Clusters are implemented using using the <ulink url="http://www.openais.org/">OpenAIS Cluster Framework</ulink>. - </para> - <para> - An OpenAIS daemon runs on every machine in the cluster, and these daemons communicate using multicast on a particular address. Every qpidd process in a cluster joins a named group that is automatically synchronized using OpenAIS Closed Process Groups (CPG) — the qpidd processes multicast events to the named group, and CPG ensures that each qpidd process receives all the events in the same sequence. All members get an identical sequence of events, so they can all update their state consistently. - </para> - <para> - Two messaging brokers are in the same cluster if - <orderedlist> - <listitem> - <para> - They run on hosts in the same OpenAIS cluster; that is, OpenAIS is configured with the same mcastaddr, mcastport and bindnetaddr, and - </para> - - </listitem> - <listitem> - <para> - They use the same cluster name. - </para> - - </listitem> - - </orderedlist> - - </para> - <para> - High Availability Clustering has a cost: in order to allow each broker in a cluster to continue the work of any other broker, a cluster must replicate state for all brokers in the cluster. Because of this, the brokers in a cluster should normally be on a LAN; there should be fast and reliable connections between brokers. Even on a LAN, using multiple brokers in a cluster is somewhat slower than using a single broker without clustering. This may be counter-intuitive for people who are used to clustering in the context of High Performance Computing or High Throughput Computing, where clustering increases performance or throughput. - </para> - - <para> - High Availability Messaging Clusters should be used together with Red Hat Clustering Services (RHCS); without RHCS, clusters are vulnerable to the "split-brain" condition, in which a network failure splits the cluster into two sub-clusters that cannot communicate with each other. See the documentation on the <command>--cluster-cman</command> option for details on running using RHCS with High Availability Messaging Clusters. See the <ulink url="http://sources.redhat.com/cluster/wiki">CMAN Wiki</ulink> for more detail on CMAN and split-brain conditions. Use the <command>--cluster-cman</command> option to enable RHCS when starting the broker. - </para> - <section id="sect-Messaging_User_Guide-High_Availability_Messaging_Clusters-Starting_a_Broker_in_a_Cluster"> - <title>Starting a Broker in a Cluster</title> - <para> - Clustering is implemented using the <filename>cluster.so</filename> module, which is loaded by default when you start a broker. To run brokers in a cluster, make sure they all use the same OpenAIS mcastaddr, mcastport, and bindnetaddr. All brokers in a cluster must also have the same cluster name — specify the cluster name in <filename>qpidd.conf</filename>: - </para> - - <screen>cluster-name="local_test_cluster" - </screen> - <para> - On RHEL6, you must create the file <filename>/etc/corosync/uidgid.d/qpidd</filename> to tell Corosync the name of the user running the broker.By default, the user is qpidd: - </para> - - <programlisting> - uidgid { - uid: qpidd - gid: qpidd - } - </programlisting> - <para> - On RHEL5, the primary group for the process running qpidd must be the ais group. If you are running qpidd as a service, it is run as the <command>qpidd</command> user, which is already in the ais group. If you are running the broker from the command line, you must ensure that the primary group for the user running qpidd is ais. You can set the primary group using <command>newgrp</command>: - </para> - - <screen>$ newgrp ais - </screen> - <para> - You can then run the broker from the command line, specifying the cluster name as an option. - </para> - - <screen>[jonathan@localhost]$ qpidd --cluster-name="local_test_cluster" - </screen> - <para> - All brokers in a cluster must have identical configuration, with a few exceptions noted below. They must load the same set of plug-ins, and have matching configuration files and command line arguments. The should also have identical ACL files and SASL databases if these are used. If one broker uses persistence, all must use persistence — a mix of transient and persistent brokers is not allowed. Differences in configuration can cause brokers to exit the cluster. For instance, if different ACL settings allow a client to access a queue on broker A but not on broker B, then publishing to the queue will succeed on A and fail on B, so B will exit the cluster to prevent inconsistency. - </para> - <para> - The following settings can differ for brokers on a given cluster: - </para> - <itemizedlist> - <listitem> - <para> - logging options - </para> - - </listitem> - <listitem> - <para> - cluster-url — if set, it will be different for each broker. - </para> - - </listitem> - <listitem> - <para> - port — brokers can listen on different ports. - </para> - - </listitem> - - </itemizedlist> - <para> - The qpid log contains entries that record significant clustering events, e.g. when a broker becomes a member of a cluster, the membership of a cluster is changed, or an old journal is moved out of the way. For instance, the following message states that a broker has been added to a cluster as the first node: - </para> - - <screen> - 2009-07-09 18:13:41 info 127.0.0.1:1410(READY) member update: 127.0.0.1:1410(member) - 2009-07-09 18:13:41 notice 127.0.0.1:1410(READY) first in cluster - </screen> - <note> - <para> - If you are using SELinux, the qpidd process and OpenAIS must have the same SELinux context, or else SELinux must be set to permissive mode. If both qpidd and OpenAIS are run as services, they have the same SELinux context. If both OpenAIS and qpidd are run as user processes, they have the same SELinux context. If one is run as a service, and the other is run as a user process, they have different SELinux contexts. - </para> - - </note> - <para> - The following options are available for clustering: - </para> - <table frame="all" id="tabl-Messaging_User_Guide-Starting_a_Broker_in_a_Cluster-Options_for_High_Availability_Messaging_Cluster"> - <title>Options for High Availability Messaging Cluster</title> - <tgroup align="left" cols="2" colsep="1" rowsep="1"> - <colspec colname="c1" colwidth="1*"></colspec> - <colspec colname="c2" colwidth="4*"></colspec> - <thead> - <row> - <entry align="center" nameend="c2" namest="c1"> - Options for High Availability Messaging Cluster - </entry> - - </row> - - </thead> - <tbody> - <row> - <entry> - <command>--cluster-name <replaceable>NAME</replaceable></command> - </entry> - <entry> - Name of the Messaging Cluster to join. A Messaging Cluster consists of all brokers started with the same cluster-name and openais configuration. - </entry> - - </row> - <row> - <entry> - <command>--cluster-size <replaceable>N</replaceable></command> - </entry> - <entry> - Wait for at least N initial members before completing cluster initialization and serving clients. Use this option in a persistent cluster so all brokers in a persistent cluster can exchange the status of their persistent store and do consistency checks before serving clients. - </entry> - - </row> - <row> - <entry> - <command>--cluster-url <replaceable>URL</replaceable></command> - </entry> - <entry> - An AMQP URL containing the local address that the broker advertizes to clients for fail-over connections. This is different for each host. By default, all local addresses for the broker are advertized. You only need to set this if - <orderedlist> - <listitem> - <para> - Your host has more than one active network interface, and - </para> - - </listitem> - <listitem> - <para> - You want to restrict client fail-over to a specific interface or interfaces. - </para> - - </listitem> - - </orderedlist> - <para>Each broker in the cluster is specified using the following form:</para> - - <programlisting>url = ["amqp:"][ user ["/" password] "@" ] protocol_addr - ("," protocol_addr)* - protocol_addr = tcp_addr / rmda_addr / ssl_addr / ... - tcp_addr = ["tcp:"] host [":" port] - rdma_addr = "rdma:" host [":" port] - ssl_addr = "ssl:" host [":" port]</programlisting> - - <para>In most cases, only one address is advertized, but more than one address can be specified in if the machine running the broker has more than one network interface card, and you want to allow clients to connect using multiple network interfaces. Use a comma delimiter (",") to separate brokers in the URL. Examples:</para> - <itemizedlist> - <listitem> - <para> - <command>amqp:tcp:192.168.1.103:5672</command> advertizes a single address to the broker for failover. - </para> - - </listitem> - <listitem> - <para> - <command>amqp:tcp:192.168.1.103:5672,tcp:192.168.1.105:5672</command> advertizes two different addresses to the broker for failover, on two different network interfaces. - </para> - - </listitem> - - </itemizedlist> - - </entry> - - </row> - <row> - <entry> - <command>--cluster-cman</command> - </entry> - <entry> - <para> - CMAN protects against the "split-brain" condition, in which a network failure splits the cluster into two sub-clusters that cannot communicate with each other. When "split-brain" occurs, each of the sub-clusters can access shared resources without knowledge of the other sub-cluster, resulting in corrupted cluster integrity. - </para> - <para> - To avoid "split-brain", CMAN uses the notion of a "quorum". If more than half the cluster nodes are active, the cluster has quorum and can act. If half (or fewer) nodes are active, the cluster does not have quorum, and all cluster activity is stopped. There are other ways to define the quorum for particular use cases (e.g. a cluster of only 2 members), see the <ulink url="http://sources.redhat.com/cluster/wiki">CMAN Wiki</ulink> - for more detail. - </para> - <para> - When enabled, the broker will wait until it belongs to a quorate cluster before accepting client connections. It continually monitors the quorum status and shuts down immediately if the node it runs on loses touch with the quorum. - </para> - - </entry> - - </row> - <row> - <entry> - --cluster-username - </entry> - <entry> - SASL username for connections between brokers. - </entry> - - </row> - <row> - <entry> - --cluster-password - </entry> - <entry> - SASL password for connections between brokers. - </entry> - - </row> - <row> - <entry> - --cluster-mechanism - </entry> - <entry> - SASL authentication mechanism for connections between brokers - </entry> - - </row> - - </tbody> - - </tgroup> - - </table> - <para> - If a broker is unable to establish a connection to another broker in the cluster, the log will contain SASL errors, e.g: - </para> - - <screen>2009-aug-04 10:17:37 info SASL: Authentication failed: SASL(-13): user not found: Password verification failed - </screen> - <para> - You can set the SASL user name and password used to connect to other brokers using the <command>cluster-username</command> and <command>cluster-password</command> properties when you start the broker. In most environment, it is easiest to create an account with the same user name and password on each broker in the cluster, and use these as the <command>cluster-username</command> and <command>cluster-password</command>. You can also set the SASL mode using <command>cluster-mechanism</command>. Remember that any mechanism you enable for broker-to-broker communication can also be used by a client, so do not enable <command>cluster-mechanism=ANONYMOUS</command> in a secure environment. - </para> - <para> - Once the cluster is running, run <command>qpid-cluster</command> to make sure that the brokers are running as one cluster. See the following section for details. - </para> - <para> - If the cluster is correctly configured, queues and messages are replicated to all brokers in the cluster, so an easy way to test the cluster is to run a program that routes messages to a queue on one broker, then to a different broker in the same cluster and read the messages to make sure they have been replicated. The <command>drain</command> and <command>spout</command> programs can be used for this test. - </para> - - </section> - - <section id="sect-Messaging_User_Guide-High_Availability_Messaging_Clusters-qpid_cluster"> - <title>qpid-cluster</title> - <para> - <command>qpid-cluster</command> is a command-line utility that allows you to view information on a cluster and its brokers, disconnect a client connection, shut down a broker in a cluster, or shut down the entire cluster. You can see the options using the <command>--help</command> option: - </para> - - <screen>$ ./qpid-cluster --help - </screen> - - <screen>Usage: qpid-cluster [OPTIONS] [broker-addr] - - broker-addr is in the form: [username/password@] hostname | ip-address [:<port>] - ex: localhost, 10.1.1.7:10000, broker-host:10000, guest/guest@localhost - - Options: - -C [--all-connections] View client connections to all cluster members - -c [--connections] ID View client connections to specified member - -d [--del-connection] HOST:PORT - Disconnect a client connection - -s [--stop] ID Stop one member of the cluster by its ID - -k [--all-stop] Shut down the whole cluster - -f [--force] Suppress the 'are-you-sure?' prompt - -n [--numeric] Don't resolve names - </screen> - <para> - Let's connect to a cluster and display basic information about the cluser and its brokers. When you connect to the cluster using <command>qpid-tool</command>, you can use the host and port for any broker in the cluster. For instance, if a broker in the cluster is running on <filename>localhost</filename> on port 6664, you can start <command>qpid-tool</command> like this: - </para> - - <screen> - $ qpid-cluster localhost:6664 - </screen> - <para> - Here is the output: - </para> - - <screen> - Cluster Name: local_test_cluster - Cluster Status: ACTIVE - Cluster Size: 3 - Members: ID=127.0.0.1:13143 URL=amqp:tcp:192.168.1.101:6664,tcp:192.168.122.1:6664,tcp:10.16.10.62:6664 - : ID=127.0.0.1:13167 URL=amqp:tcp:192.168.1.101:6665,tcp:192.168.122.1:6665,tcp:10.16.10.62:6665 - : ID=127.0.0.1:13192 URL=amqp:tcp:192.168.1.101:6666,tcp:192.168.122.1:6666,tcp:10.16.10.62:6666 - </screen> - <para> - The ID for each broker in cluster is given on the left. For instance, the ID for the first broker in the cluster is <command>127.0.0.1:13143</command>. The URL in the output is the broker's advertized address. Let's use the ID to shut the broker down using the <command>--stop</command> command: - </para> - - <screen>$ ./qpid-cluster localhost:6664 --stop 127.0.0.1:13143 - </screen> - - </section> - - <section id="sect-Messaging_User_Guide-High_Availability_Messaging_Clusters-Failover_in_Clients"> - <title>Failover in Clients</title> - <para> - If a client is connected to a broker, the connection fails if the broker crashes or is killed. If heartbeat is enabled for the connection, a connection also fails if the broker hangs, the machine the broker is running on fails, or the network connection to the broker is lost — the connection fails no later than twice the heartbeat interval. - </para> - <para> - When a client's connection to a broker fails, any sent messages that have been acknowledged to the sender will have been replicated to all brokers in the cluster, any received messages that have not yet been acknowledged by the receiving client requeued to all brokers, and the client API notifies the application of the failure by throwing an exception. - </para> - <para> - Clients can be configured to automatically reconnect to another broker when it receives such an exception. Any messages that have been sent by the client, but not yet acknowledged as delivered, are resent. Any messages that have been read by the client, but not acknowledged, are delivered to the client. - </para> - <para> - TCP is slow to detect connection failures. A client can configure a connection to use a heartbeat to detect connection failure, and can specify a time interval for the heartbeat. If heartbeats are in use, failures will be detected no later than twice the heartbeat interval. The Java JMS client enables hearbeat by default. See the sections on Failover in Java JMS Clients and Failover in C++ Clients for the code to enable heartbeat. - </para> - <section id="sect-Messaging_User_Guide-Failover_in_Clients-Failover_in_Java_JMS_Clients"> - <title>Failover in Java JMS Clients</title> - <para> - In Java JMS clients, client failover is handled automatically if it is enabled in the connection. Any messages that have been sent by the client, but not yet acknowledged as delivered, are resent. Any messages that have been read by the client, but not acknowledged, are sent to the client. - </para> - <para> - You can configure a connection to use failover using the <command>failover</command> property: - </para> - - <screen> - connectionfactory.qpidConnectionfactory = amqp://guest:guest@clientid/test?brokerlist='tcp://localhost:5672'&failover='failover_exchange' - </screen> - <para> - This property can take three values: - </para> - <variablelist id="vari-Messaging_User_Guide-Failover_in_Java_JMS_Clients-Failover_Modes"> - <title>Failover Modes</title> - <varlistentry> - <term>failover_exchange</term> - <listitem> - <para> - If the connection fails, fail over to any other broker in the cluster. - </para> - - </listitem> - - </varlistentry> - <varlistentry> - <term>roundrobin</term> - <listitem> - <para> - If the connection fails, fail over to one of the brokers specified in the <command>brokerlist</command>. - </para> - - </listitem> - - </varlistentry> - <varlistentry> - <term>singlebroker</term> - <listitem> - <para> - Failover is not supported; the connection is to a single broker only. - </para> - - </listitem> - - </varlistentry> - - </variablelist> - <para> - In a Connection URL, heartbeat is set using the <command>idle_timeout</command> property, which is an integer corresponding to the heartbeat period in seconds. For instance, the following line from a JNDI properties file sets the heartbeat time out to 3 seconds: - </para> - - <screen> - connectionfactory.qpidConnectionfactory = amqp://guest:guest@clientid/test?brokerlist='tcp://localhost:5672',idle_timeout=3 - </screen> - - </section> - - <section id="sect-Messaging_User_Guide-Failover_in_Clients-Failover_and_the_Qpid_Messaging_API"> - <title>Failover and the Qpid Messaging API</title> - <para> - The Qpid Messaging API also supports automatic reconnection in the event a connection fails. . Senders can also be configured to replay any in-doubt messages (i.e. messages whice were sent but not acknowleged by the broker. See "Connection Options" and "Sender Capacity and Replay" in <citetitle>Programming in Apache Qpid</citetitle> for details. - </para> - <para> - In C++ and python clients, heartbeats are disabled by default. You can enable them by specifying a heartbeat interval (in seconds) for the connection via the 'heartbeat' option. - </para> - <para> - See "Cluster Failover" in <citetitle>Programming in Apache Qpid</citetitle> for details on how to keep the client aware of cluster membership. - </para> - - </section> - - - </section> - - <section id="sect-Messaging_User_Guide-High_Availability_Messaging_Clusters-Error_handling_in_Clusters"> - <title>Error handling in Clusters</title> - <para> - If a broker crashes or is killed, or a broker machine failure, broker connection failure, or a broker hang is detected, the other brokers in the cluster are notified that it is no longer a member of the cluster. If a new broker is joined to the cluster, it synchronizes with an active broker to obtain the current cluster state; if this synchronization fails, the new broker exit the cluster and aborts. - </para> - <para> - If a broker becomes extremely busy and stops responding, it stops accepting incoming work. All other brokers continue processing, and the non-responsive node caches all AIS traffic. When it resumes, the broker completes processes all cached AIS events, then accepts further incoming work. <!-- If a broker is non-responsive for too long, it is assumed to be hanging, and treated as described in the previous paragraph. --> - </para> - <para> - Broker hangs are only detected if the watchdog plugin is loaded and the <command>--watchdog-interval</command> option is set. The watchdog plug-in kills the qpidd broker process if it becomes stuck for longer than the watchdog interval. In some cases, e.g. certain phases of error resolution, it is possible for a stuck process to hang other cluster members that are waiting for it to send a message. Using the watchdog, the stuck process is terminated and removed from the cluster, allowing other members to continue and clients of the stuck process to fail over to other members. - </para> - <para> - Redundancy can also be achieved directly in the AIS network by specifying more than one network interface in the AIS configuration file. This causes Totem to use a redundant ring protocol, which makes failure of a single network transparent. - </para> - <para> - Redundancy can be achieved at the operating system level by using NIC bonding, which combines multiple network ports into a single group, effectively aggregating the bandwidth of multiple interfaces into a single connection. This provides both network load balancing and fault tolerance. - </para> - <para> - If any broker encounters an error, the brokers compare notes to see if they all received the same error. If not, the broker removes itself from the cluster and shuts itself down to ensure that all brokers in the cluster have consistent state. For instance, a broker may run out of disk space; if this happens, the broker shuts itself down. Examining the broker's log can help determine the error and suggest ways to prevent it from occuring in the future. - </para> - <!-- "Bad case" for cluster matrix - things we will fix, or things users may encounter long term? --> - </section> - - <section id="sect-Messaging_User_Guide-High_Availability_Messaging_Clusters-Persistence_in_High_Availability_Message_Clusters"> - <title>Persistence in High Availability Message Clusters</title> - <para> - Persistence and clustering are two different ways to provide reliability. Most systems that use a cluster do not enable persistence, but you can do so if you want to ensure that messages are not lost even if the last broker in a cluster fails. A cluster must have all transient or all persistent members, mixed clusters are not allowed. Each broker in a persistent cluster has it's own independent replica of the cluster's state it its store. - </para> - <section id="sect-Messaging_User_Guide-Persistence_in_High_Availability_Message_Clusters-Clean_and_Dirty_Stores"> - <title>Clean and Dirty Stores</title> - <para> - When a broker is an active member of a cluster, its store is marked "dirty" because it may be out of date compared to other brokers in the cluster. If a broker leaves a running cluster because it is stopped, it crashes or the host crashes, its store continues to be marked "dirty". - </para> - <para> - If the cluster is reduced to a single broker, its store is marked "clean" since it is the only broker making updates. If the cluster is shut down with the command <literal>qpid-cluster -k</literal> then all the stores are marked clean. - </para> - <para> - When a cluster is initially formed, brokers with clean stores read from their stores. Brokers with dirty stores, or brokers that join after the cluster is running, discard their old stores and initialize a new store with an update from one of the running brokers. The <command>--truncate</command> option can be used to force a broker to discard all existing stores even if they are clean. (A dirty store is discarded regardless.) - </para> - <para> - Discarded stores are copied to a back up directory. The active store is in <data-dir>/rhm. Back-up stores are in <data-dir>/_cluster.bak.<nnnn>/rhm, where <nnnn> is a 4 digit number. A higher number means a more recent backup. - </para> - - </section> - - <section id="sect-Messaging_User_Guide-Persistence_in_High_Availability_Message_Clusters-Starting_a_persistent_cluster"> - <title>Starting a persistent cluster</title> - <para> - When starting a persistent cluster broker, set the cluster-size option to the number of brokers in the cluster. This allows the brokers to wait until the entire cluster is running so that they can synchronize their stored state. - </para> - <para> - The cluster can start if: - </para> - <para> - <itemizedlist> - <listitem> - <para> - all members have empty stores, or - </para> - - </listitem> - <listitem> - <para> - at least one member has a clean store - </para> - - </listitem> - - </itemizedlist> - - </para> - <para> - All members of the new cluster will be initialized with the state from a clean store. - </para> - - </section> - - <section id="sect-Messaging_User_Guide-Persistence_in_High_Availability_Message_Clusters-Stopping_a_persistent_cluster"> - <title>Stopping a persistent cluster</title> - <para> - To cleanly shut down a persistent cluster use the command <command>qpid-cluster -k</command>. This causes all brokers to synchronize their state and mark their stores as "clean" so they can be used when the cluster restarts. - </para> - - </section> - - <section id="sect-Messaging_User_Guide-Persistence_in_High_Availability_Message_Clusters-Starting_a_persistent_cluster_with_no_clean_store"> - <title>Starting a persistent cluster with no clean store</title> - <para> - If the cluster has previously had a total failure and there are no clean stores then the brokers will fail to start with the log message <literal>Cannot recover, no clean store.</literal> If this happens you can start the cluster by marking one of the stores "clean" as follows: - </para> - <procedure> - <step> - <para> - Move the latest store backup into place in the brokers data-directory. The backups end in a 4 digit number, the latest backup is the highest number. - </para> - - <screen> - cd <data-dir> - mv rhm rhm.bak - cp -a _cluster.bak.<nnnn>/rhm . - </screen> - - </step> - <step> - <para> - Mark the store as clean: - <screen>qpid-cluster-store -c <data-dir></screen> - - </para> - - </step> - - </procedure> - - <para> - Now you can start the cluster, all members will be initialized from the store you marked as clean. - </para> - - </section> - - <section id="sect-Messaging_User_Guide-Persistence_in_High_Availability_Message_Clusters-Isolated_failures_in_a_persistent_cluster"> - <title>Isolated failures in a persistent cluster</title> - <para> - A broker in a persistent cluster may encounter errors that other brokers in the cluster do not; if this happens, the broker shuts itself down to avoid making the cluster state inconsistent. For example a disk failure on one node will result in that node shutting down. Running out of storage capacity can also cause a node to shut down because because the brokers may not run out of storage at exactly the same point, even if they have similar storage configuration. To avoid unnecessary broker shutdowns, make sure the queue policy size of each durable queue is less than the capacity of the journal for the queue. - </para> - - </section> - - - </section> - - -</section> diff --git a/doc/book/src/cpp-broker/Active-Passive-Cluster.xml b/doc/book/src/cpp-broker/Active-Passive-Cluster.xml index 805ceb06e0..8a6403c2b5 100644 --- a/doc/book/src/cpp-broker/Active-Passive-Cluster.xml +++ b/doc/book/src/cpp-broker/Active-Passive-Cluster.xml @@ -55,30 +55,45 @@ under the License. <title>Avoiding message loss</title> <para> In order to avoid message loss, the primary broker <emphasis>delays - acknowledgment</emphasis> of messages received from clients until the - message has been replicated to and acknowledged by all of the back-up + acknowledgment</emphasis> of messages received from clients until the message has + been replicated to and acknowledged by all of the back-up brokers. This means that + all <emphasis>acknowledged</emphasis> messages are safely stored on all the backup brokers. </para> <para> - Clients buffer unacknowledged messages and re-send them in the event of - a fail-over. + Clients keep <emphasis>unacknowledged</emphasis> messages in a buffer + <footnote> + <para> + You can control the maximum number of messages in the buffer by setting the + client's <literal>capacity</literal>. For details of how to set the capacity + in client code see "Using the Qpid Messaging API" in + <citetitle>Programming in Apache Qpid</citetitle>. + </para> + </footnote> + until they are acknowledged by the primary. If the primary fails, clients will + fail-over to the new primary and <emphasis>re-send</emphasis> all their + unacknowledged messages. <footnote> <para> Clients must use "at-least-once" reliability to enable re-send of unacknowledged messages. This is the default behavior, no options need be set to enable it. For details of client addressing options see "Using the Qpid Messaging API" - in <citetitle>Programming in Apache Qpid</citetitle> + in <citetitle>Programming in Apache Qpid</citetitle>. </para> </footnote> - If the primary crashes before a message is replicated to - all the backups, the client will re-send the message when it fails over - to the new primary. + </para> + <para> + So if the primary crashes, all the <emphasis>acknowledged</emphasis> + messages will be available on the backup that takes over as the new + primary. The <emphasis>unacknowledged</emphasis> messages will be + re-sent by the clients. Thus no messages are lost. </para> <para> Note that this means it is possible for messages to be - <emphasis>duplicated</emphasis>. In the event of a failure it is - possible for a message to be both received by the backup that becomes - the new primary <emphasis>and</emphasis> re-sent by the client. + <emphasis>duplicated</emphasis>. In the event of a failure it is possible for a + message to received by the backup that becomes the new primary + <emphasis>and</emphasis> re-sent by the client. The application must take steps + to identify and eliminate duplicates. </para> <para> When a new primary is promoted after a fail-over it is initially in @@ -87,6 +102,11 @@ under the License. primary. This protects those messages against a failure of the new primary until the backups have a chance to connect and catch up. </para> + <para> + Not all messages need to be replicated to the back-up brokers. If a + message is consumed and acknowledged by a regular client before it has + been replicated to a backup, then it doesn't need to be replicated. + </para> <variablelist> <title>Status of a HA broker</title> <varlistentry> @@ -134,67 +154,35 @@ under the License. </variablelist> </section> <section> - <title>Replacing the old cluster module</title> + <title>Limitations</title> <para> - The High Availability (HA) module replaces the previous - <firstterm>active-active</firstterm> cluster module. The new active-passive - approach has several advantages compared to the existing active-active cluster - module. - <itemizedlist> - <listitem> - It does not depend directly on openais or corosync. It does not use multicast - which simplifies deployment. - </listitem> - <listitem> - It is more portable: in environments that don't support corosync, it can be - integrated with a resource manager available in that environment. - </listitem> - <listitem> - Replication to a <firstterm>disaster recovery</firstterm> site can be handled as - simply another node in the cluster, it does not require a separate replication - mechanism. - </listitem> - <listitem> - It can take advantage of features provided by the resource manager, for example - virtual IP addresses. - </listitem> - <listitem> - Improved performance and scalability due to better use of multiple CPUs - </listitem> - </itemizedlist> + There are a some known limitations in the current implementation. These + will be fixed in furture versions. </para> - </section> - <section> - <title>Limitations</title> <itemizedlist> <listitem> - Transactional changes to queue state are not replicated atomically. If the - primary crashes during a transaction, it is possible that the backup could - contain only part of the changes introduced by a transaction. - </listitem> - <listitem> - Not yet integrated with the persistent store. A persistent broker must have its - store erased before joining an existing cluster. If the entire cluster fails, - there are no tools to help identify the most recent store. In the future a - persistent broker will be able to use its stored messages to avoid downloading - messages from the primary when joining a cluster. - </listitem> - <listitem> - Configuration changes (creating or deleting queues, exchanges and bindings) are - replicated asynchronously. Management tools used to make changes will consider - the change complete when it is complete on the primary, it may not yet be - replicated to all the backups. + <para> + Transactional changes to queue state are not replicated atomically. If + the primary crashes during a transaction, it is possible that the + backup could contain only part of the changes introduced by a + transaction. + </para> </listitem> <listitem> - Deletions made immediately after a failure (before all the backups are ready) - may be lost on a backup. Queues, exchange or bindings that were deleted on the - primary could re-appear if that backup is promoted to primary on a subsequent - failure. + <para> + Configuration changes (creating or deleting queues, exchanges and + bindings) are replicated asynchronously. Management tools used to + make changes will consider the change complete when it is complete + on the primary, it may not yet be replicated to all the backups. + </para> </listitem> <listitem> - Federated links <emphasis>from</emphasis> the primary will be lost in fail over, - they will not be re-connected to the new primary. Federation links - <emphasis>to</emphasis> the primary can fail over. + <para> + Federated links <emphasis>from</emphasis> the primary will be lost + in fail over, they will not be re-connected to the new + primary. Federation links <emphasis>to</emphasis> the primary will + fail over. + </para> </listitem> </itemizedlist> </section> @@ -247,12 +235,20 @@ under the License. </row> <row> <entry> + <literal>ha-queue-replication <replaceable>yes|no</replaceable></literal> + </entry> + <entry> + Enable replication of specific queues without joining a cluster, see <xref linkend="ha-queue-replication"/>. + </entry> + </row> + <row> + <entry> <literal>ha-brokers-url <replaceable>URL</replaceable></literal> </entry> <entry> <para> The URL - <footnote> + <footnote id="ha-url-grammar"> <para> The full format of the URL is given by this grammar: <programlisting> @@ -264,10 +260,9 @@ ssl_addr = "ssl:" host [":" port]' </programlisting> </para> </footnote> - used by cluster brokers to connect to each other. The URL can - contain a list of all the broker addresses or it can contain a single - virtual IP address. If a list is used it is comma separated, for example - <literal>amqp:node1.exaple.com,node2.exaple.com,node3.exaple.com</literal> + used by cluster brokers to connect to each other. The URL should + contain a comma separated list of the broker addresses, rather than a + virtual IP address. </para> </entry> </row> @@ -275,20 +270,23 @@ ssl_addr = "ssl:" host [":" port]' <entry><literal>ha-public-url <replaceable>URL</replaceable></literal> </entry> <entry> <para> - The URL that is advertised to clients. This defaults to the - <literal>ha-brokers-url</literal> URL above, and has the same format. A - virtual IP address is recommended for the public URL as it simplifies - deployment and hides changes to the cluster membership from clients. + The URL <footnoteref linkend="ha-url-grammar"/> is advertised to + clients as the "known-hosts" for fail-over. It can be a list or + a single virtual IP address. A virtual IP address is recommended. </para> <para> - This option allows you to put client traffic on a different network from - broker traffic, which is recommended. + Using this option you can put client and broker traffic on + separate networks, which is recommended. + </para> + <para> + Note: When HA clustering is enabled the broker option + <literal>known-hosts-url</literal> is ignored and over-ridden by + the <literal>ha-public-url</literal> setting. </para> </entry> </row> <row> <entry><literal>ha-replicate </literal><replaceable>VALUE</replaceable></entry> - <foo/> <entry> <para> Specifies whether queues and exchanges are replicated by default. @@ -330,6 +328,15 @@ ssl_addr = "ssl:" host [":" port]' </para> </entry> </row> + <row> + <entry><literal>link-heartbeat-interval <replaceable>SECONDS</replaceable></literal></entry> + <entry> + <para> + Heartbeat interval for replication links. The link will be assumed broken + if there is no heartbeat for twice the interval. + </para> + </entry> + </row> </tbody> </tgroup> </table> @@ -382,7 +389,7 @@ ssl_addr = "ssl:" host [":" port]' clustered services using <command>cman</command> and <command>rgmanager</command>. It will show you how to configure an active-passive, hot-standby <command>qpidd</command> HA cluster with <command>rgmanager</command>. - </para> + </para> <para> You must provide a <literal>cluster.conf</literal> file to configure <command>cman</command> and <command>rgmanager</command>. Here is @@ -532,22 +539,28 @@ NOTE: fencing is not shown, you must configure fencing appropriately for your cl </section> <section id="ha-creating-replicated"> - <title>Creating replicated queues and exchanges</title> + <title>Controlling replication of queues and exchanges</title> <para> By default, queues and exchanges are not replicated automatically. You can change the default behavior by setting the <literal>ha-replicate</literal> configuration option. It has one of the following values: <itemizedlist> <listitem> - <firstterm>all</firstterm>: Replicate everything automatically: queues, - exchanges, bindings and messages. + <para> + <firstterm>all</firstterm>: Replicate everything automatically: queues, + exchanges, bindings and messages. + </para> </listitem> <listitem> - <firstterm>configuration</firstterm>: Replicate the existence of queues, - exchange and bindings but don't replicate messages. + <para> + <firstterm>configuration</firstterm>: Replicate the existence of queues, + exchange and bindings but don't replicate messages. + </para> </listitem> <listitem> - <firstterm>none</firstterm>: Don't replicate anything, this is the default. + <para> + <firstterm>none</firstterm>: Don't replicate anything, this is the default. + </para> </listitem> </itemizedlist> </para> @@ -575,6 +588,18 @@ NOTE: fencing is not shown, you must configure fencing appropriately for your cl <programlisting> "myqueue;{create:always,node:{x-declare:{arguments:{'qpid.replicate':all}}}}" </programlisting> + <para> + There are some built-in exchanges created automatically by the broker, these + exchangs are never replicated. The built-in exchanges are the default (nameless) + exchange, the AMQP standard exchanges (<literal>amq.direct, amq.topic, amq.fanout</literal> and + <literal>amq.match</literal>) and the management exchanges (<literal>qpid.management, qmf.default.direct</literal> and + <literal>qmf.default.topic</literal>) + </para> + <para> + Note that if you bind a replicated queue to one of these exchanges, the + binding wil <emphasis>not</emphasis> be replicated, so the queue will not + have the binding after a fail-over. + </para> </section> <section> @@ -588,12 +613,17 @@ NOTE: fencing is not shown, you must configure fencing appropriately for your cl each type of client). There are two possibilities <itemizedlist> <listitem> - The URL contains multiple addresses, one for each broker in the cluster. + <para> + The URL contains multiple addresses, one for each broker in the cluster. + </para> </listitem> <listitem> - The URL contains a single <firstterm>virtual IP address</firstterm> - that is assigned to the primary broker by the resource manager. - <footnote><para>Only if the resource manager supports virtual IP addresses</para></footnote> + <para> + The URL contains a single <firstterm>virtual IP address</firstterm> + that is assigned to the primary broker by the resource manager. + <footnote><para>Only if the resource manager supports virtual IP + addresses</para></footnote> + </para> </listitem> </itemizedlist> In the first case, clients will repeatedly re-try each address in the URL @@ -790,10 +820,10 @@ NOTE: fencing is not shown, you must configure fencing appropriately for your cl <para> To integrate with a different resource manager you must configure it to: <itemizedlist> - <listitem>Start a qpidd process on each node of the cluster.</listitem> - <listitem>Restart qpidd if it crashes.</listitem> - <listitem>Promote exactly one of the brokers to primary.</listitem> - <listitem>Detect a failure and promote a new primary.</listitem> + <listitem><para>Start a qpidd process on each node of the cluster.</para></listitem> + <listitem><para>Restart qpidd if it crashes.</para></listitem> + <listitem><para>Promote exactly one of the brokers to primary.</para></listitem> + <listitem><para>Detect a failure and promote a new primary.</para></listitem> </itemizedlist> </para> <para> @@ -821,6 +851,30 @@ NOTE: fencing is not shown, you must configure fencing appropriately for your cl or to simulate a cluster on a single node. For deployment, a resource manager is required. </para> </section> + <section id="ha-queue-replication"> + <title>Replicating specific queues</title> + <para> + In addition to the automatic replication performed in a cluster, you can + set up replication for specific queues between arbitrary brokers, even if + the brokers are not members of a cluster. The command: + </para> + <programlisting> + qpid-ha replicate <replaceable>QUEUE</replaceable> <replaceable>REMOTE-BROKER</replaceable> + </programlisting> + <para> + sets up replication of <replaceable>QUEUE</replaceable> on <replaceable>REMOTE-BROKER</replaceable> to <replaceable>QUEUE</replaceable> on the current broker. + </para> + <para> + Set the configuration option + <literal>ha-queue-replication=yes</literal> on both brokers to enable this + feature on non-cluster brokers. It is automatically enabled for brokers + that are part of a cluster. + </para> + <para> + Note that this feature does not provide automatic fail-over, for that you + need to run a cluster. + </para> + </section> </section> <!-- LocalWords: scalability rgmanager multicast RGManager mailto LVQ qpidd IP dequeued Transactional username diff --git a/doc/book/src/cpp-broker/Security.xml b/doc/book/src/cpp-broker/Security.xml index f28b72c71d..67c9d3dab7 100644 --- a/doc/book/src/cpp-broker/Security.xml +++ b/doc/book/src/cpp-broker/Security.xml @@ -315,67 +315,102 @@ com.sun.security.jgss.initiate { <!-- ################################################### --> <section id="sect-Messaging_User_Guide-Security-Authorization"> <title>Authorization</title> <para> - In Qpid, Authorization specifies which actions can be performed by each authenticated user using an Access Control List (ACL). Use the <command>--acl-file</command> command to load the access control list. The filename should have a <filename>.acl</filename> extension: + In Qpid, Authorization specifies which actions can be performed by each authenticated user using an Access Control List (ACL). + </para> + <para> + Use the <command>--acl-file</command> command to load the access control list. The filename should have a <filename>.acl</filename> extension: </para> <screen> -$ qpidd --acl-file <replaceable>./aclfilename.acl</replaceable></screen> + $ qpidd --acl-file <replaceable>./aclfilename.acl</replaceable></screen> <para> Each line in an ACL file grants or denies specific rights to a user. If the last line in an ACL file is <literal>acl deny all all</literal>, the ACL uses <firstterm>deny mode</firstterm>, and only those rights that are explicitly allowed are granted: </para> <programlisting> -acl allow rajith@QPID all all -acl deny all all + acl allow rajith@QPID all all + acl deny all all </programlisting> <para> On this server, <literal>rajith@QPID</literal> can perform any action, but nobody else can. Deny mode is the default, so the previous example is equivalent to the following ACL file: </para> <programlisting> -acl allow rajith@QPID all all + acl allow rajith@QPID all all +</programlisting> + <para> + Alternatively the ACL file may use <firstterm>allow mode</firstterm> by placing: + </para> +<programlisting> + acl allow all all </programlisting> <para> + as the final line in the ACL file. In <emphasis>allow mode</emphasis> all actions by all users are allowed unless otherwise denied by specific ACL rules. + The ACL rule which selects <emphasis>deny mode</emphasis> or <emphasis>allow mode</emphasis> must be the last line in the ACL rule file. + </para> + <para> ACL syntax allows fine-grained access rights for specific actions: </para> <programlisting> -acl allow carlt@QPID create exchange name=carl.* -acl allow fred@QPID create all -acl allow all consume queue -acl allow all bind exchange -acl deny all all + acl allow carlt@QPID create exchange name=carl.* + acl allow fred@QPID create all + acl allow all consume queue + acl allow all bind exchange + acl deny all all </programlisting> <para> An ACL file can define user groups, and assign permissions to them: </para> <programlisting> -group admin ted@QPID martin@QPID -acl allow admin create all -acl deny all all + group admin ted@QPID martin@QPID + acl allow admin create all + acl deny all all </programlisting> + + <para> + Performance Note: Most ACL queries are performed infrequently. The overhead associated with + ACL passing an allow or deny decision on the creation of a queue is negligible + compared to actually creating and using the queue. One notable exception is the <command>publish exchange</command> + query. ACL files with no <emphasis>publish exchange</emphasis> rules are noted and the broker short circuits the logic + associated with the per-messsage <emphasis>publish exchange</emphasis> ACL query. + However, if an ACL file has any <emphasis>publish exchange</emphasis> rules + then the broker is required to perform a <emphasis>publish exchange</emphasis> query for each message published. + Users with performance critical applications are encouraged to structure exchanges, queues, and bindings so that + the <emphasis>publish exchange</emphasis> ACL rules are unnecessary. + </para> + <!-- ######## --> <section id="sect-Messaging_User_Guide-Authorization-ACL_Syntax"> <title>ACL Syntax</title> <para> ACL rules must be on a single line and follow this syntax: <programlisting><![CDATA[ -user = username[/domain[@realm]] -user-list = user1 user2 user3 ... -group-name-list = group1 group2 group3 ... - -group <group-name> = [user-list] [group-name-list] - -permission = [allow|allow-log|deny|deny-log] -action = [consume|publish|create|access|bind|unbind|delete|purge|update] -object = [virtualhost|queue|exchange|broker|link|route|method] -property = [name|durable|owner|routingkey|autodelete|exclusive| - type|alternate|queuename|schemapackage|schemaclass| - queuemaxsizelowerlimit|queuemaxsizeupperlimit| - queuemaxcountlowerlimit|queuemaxcountupperlimit] - -acl permission {<group-name>|<user-name>|"all"} {action|"all"} [object|"all" - [property=<property-value> ...]] + user = username[/domain[@realm]] + user-list = user1 user2 user3 ... + group-name-list = group1 group2 group3 ... + + group <group-name> = [user-list] [group-name-list] + + permission = [allow | allow-log | deny | deny-log] + action = [consume | publish | create | access | + bind | unbind | delete | purge | update] + object = [queue | exchange | broker | link | method] + property = [name | durable | owner | routingkey | + autodelete | exclusive |type | + alternate | queuename | + schemapackage | schemaclass | + queuemaxsizelowerlimit | + queuemaxsizeupperlimit | + queuemaxcountlowerlimit | + queuemaxcountupperlimit | + filemaxsizelowerlimit | + filemaxsizeupperlimit | + filemaxcountlowerlimit | + filemaxcountupperlimit ] + + acl permission {<group-name>|<user-name>|"all"} {action|"all"} [object|"all" + [property=<property-value> ...]] ]]></programlisting> ACL rules can also include a single object name (or the keyword <parameter>all</parameter>) and one or more property name value pairs in the form <command>property=value</command> @@ -463,7 +498,9 @@ acl permission {<group-name>|<user-name>|"all"} {action|"all"} [object|"all" </entry> <entry> <para> - Applied on a per message basis on publish message transfers, this rule consumes the most resources + Applied on a per message basis + to verify that the user has rights to publish to the given + exchange with the given routingkey. </para> </entry> @@ -647,49 +684,49 @@ acl permission {<group-name>|<user-name>|"all"} {action|"all"} [object|"all" <entry> <command>name</command> </entry> <entry>String</entry> <entry>Object name, such as a queue name or exchange name.</entry> - <entry>.</entry> + <entry></entry> </row> <row> <entry> <command>durable</command> </entry> <entry>Boolean</entry> <entry>Indicates the object is durable</entry> - <entry>CREATE QUEUE, CREATE EXCHANGE</entry> + <entry>CREATE QUEUE, CREATE EXCHANGE, ACCESS QUEUE, ACCESS EXCHANGE</entry> </row> <row> <entry> <command>routingkey</command> </entry> <entry>String</entry> <entry>Specifies routing key</entry> - <entry>BIND EXCHANGE, UNBIND EXCHANGE, ACCESS EXCHANGE</entry> + <entry>BIND EXCHANGE, UNBIND EXCHANGE, ACCESS EXCHANGE, PUBLISH EXCHANGE</entry> </row> <row> <entry> <command>autodelete</command> </entry> <entry>Boolean</entry> <entry>Indicates whether or not the object gets deleted when the connection is closed</entry> - <entry>CREATE QUEUE</entry> + <entry>CREATE QUEUE, ACCESS QUEUE</entry> </row> <row> <entry> <command>exclusive</command> </entry> <entry>Boolean</entry> <entry>Indicates the presence of an <parameter>exclusive</parameter> flag</entry> - <entry>CREATE QUEUE</entry> + <entry>CREATE QUEUE, ACCESS QUEUE</entry> </row> <row> <entry> <command>type</command> </entry> <entry>String</entry> <entry>Type of exchange, such as topic, fanout, or xml</entry> - <entry>CREATE EXCHANGE</entry> + <entry>CREATE EXCHANGE, ACCESS EXCHANGE</entry> </row> <row> <entry> <command>alternate</command> </entry> <entry>String</entry> <entry>Name of the alternate exchange</entry> - <entry>CREATE EXCHANGE, CREATE QUEUE</entry> + <entry>CREATE EXCHANGE, CREATE QUEUE, ACCESS EXCHANGE, ACCESS QUEUE</entry> </row> <row> <entry> <command>queuename</command> </entry> <entry>String</entry> <entry>Name of the queue</entry> - <entry>ACCESS EXCHANGE</entry> + <entry>ACCESS EXCHANGE, BIND EXCHANGE, UNBIND EXCHANGE</entry> </row> <row> <entry> <command>schemapackage</command> </entry> @@ -706,119 +743,571 @@ acl permission {<group-name>|<user-name>|"all"} {action|"all"} [object|"all" <row> <entry> <command>queuemaxsizelowerlimit</command> </entry> <entry>Integer</entry> - <entry>Minimum value for queue.max_size</entry> - <entry>CREATE QUEUE</entry> + <entry>Minimum value for queue.max_size (memory bytes)</entry> + <entry>CREATE QUEUE, ACCESS QUEUE</entry> </row> <row> <entry> <command>queuemaxsizeupperlimit</command> </entry> <entry>Integer</entry> - <entry>Maximum value for queue.max_size</entry> - <entry>CREATE QUEUE</entry> + <entry>Maximum value for queue.max_size (memory bytes)</entry> + <entry>CREATE QUEUE, ACCESS QUEUE</entry> </row> <row> <entry> <command>queuemaxcountlowerlimit</command> </entry> <entry>Integer</entry> - <entry>Minimum value for queue.max_count</entry> - <entry>CREATE QUEUE</entry> + <entry>Minimum value for queue.max_count (messages)</entry> + <entry>CREATE QUEUE, ACCESS QUEUE</entry> </row> <row> <entry> <command>queuemaxcountupperlimit</command> </entry> <entry>Integer</entry> - <entry>Maximum value for queue.max_count</entry> - <entry>CREATE QUEUE</entry> + <entry>Maximum value for queue.max_count (messages)</entry> + <entry>CREATE QUEUE, ACCESS QUEUE</entry> + </row> + <row> + <entry> <command>filemaxsizelowerlimit</command> </entry> + <entry>Integer</entry> + <entry>Minimum value for file.max_size (64kb pages)</entry> + <entry>CREATE QUEUE, ACCESS QUEUE</entry> + </row> + <row> + <entry> <command>filemaxsizeupperlimit</command> </entry> + <entry>Integer</entry> + <entry>Maximum value for file.max_size (64kb pages)</entry> + <entry>CREATE QUEUE, ACCESS QUEUE</entry> + </row> + <row> + <entry> <command>filemaxcountlowerlimit</command> </entry> + <entry>Integer</entry> + <entry>Minimum value for file.max_count (files)</entry> + <entry>CREATE QUEUE, ACCESS QUEUE</entry> + </row> + <row> + <entry> <command>filemaxcountupperlimit</command> </entry> + <entry>Integer</entry> + <entry>Maximum value for file.max_count (files)</entry> + <entry>CREATE QUEUE, ACCESS QUEUE</entry> </row> - </tbody> - </tgroup> - </table> - + + <section id="sect-Messaging_User_Guide-Authorization-ACL_ActionObjectPropertyTuples"> + <title>ACL Action-Object-Property Tuples</title> + <para> + Not every ACL action is applicable to every ACL object. Furthermore, not every property may be + specified for every action-object pair. + The following table enumerates which action and object pairs are allowed. + The table also lists which optional ACL properties are allowed to qualify + action-object pairs. + </para> + <para> + The <emphasis>access</emphasis> action is called with different argument + lists for the <emphasis>exchange</emphasis> and <emphasis>queue</emphasis> objects. + A separate column shows the AMQP 0.10 method that the Access ACL rule is satisfying. + Write separate rules with the additional arguments for the <emphasis>declare</emphasis> + and <emphasis>bind</emphasis> methods and include these rules in the ACL file + before the rules for the <emphasis>query</emphasis> method. + <!-- The exact sequence of calling these methods is a product of the client + library. The user might not know anything about a 'declare' or a 'query' or + a passive declaration. --> + </para> + <table id="tabl-Messaging_User_Guide-ACL_Syntax-ACL_ActionObject_properties"> + <title>ACL Properties Allowed for each Action and Object</title> + <tgroup cols="4"> + <thead> + <row> + <entry>Action</entry> + <entry>Object</entry> + <entry>Properties</entry> + <entry>Method</entry> + </row> + </thead> + <tbody> + <row> + <entry>access</entry> + <entry>broker</entry> + <entry></entry> + </row> + <row> + <entry>access</entry> + <entry>exchange</entry> + <entry>name type alternate durable</entry> + <entry>declare</entry> + </row> + <row> + <entry>access</entry> + <entry>exchange</entry> + <entry>name queuename routingkey</entry> + <entry>bound</entry> + </row> + <row> + <entry>access</entry> + <entry>exchange</entry> + <entry>name</entry> + <entry>query</entry> + </row> + <row> + <entry>access</entry> + <entry>method</entry> + <entry>name schemapackage schemaclass</entry> + <entry></entry> + </row> + <row> + <entry>access</entry> + <entry>queue</entry> + <entry>name alternate durable exclusive autodelete policy queuemaxsizelowerlimit queuemaxsizeupperlimit queuemaxcountlowerlimit queuemaxcountupperlimit filemaxsizelowerlimit filemaxsizeupperlimit filemaxcountlowerlimit filemaxcountupperlimit</entry> + <entry>declare</entry> + </row> + <row> + <entry>access</entry> + <entry>queue</entry> + <entry>name</entry> + <entry>query</entry> + </row> + <row> + <entry>bind</entry> + <entry>exchange</entry> + <entry>name queuename routingkey</entry> + <entry></entry> + </row> + <row> + <entry>consume</entry> + <entry>queue</entry> + <entry>name</entry> + <entry></entry> + </row> + <row> + <entry>create</entry> + <entry>exchange</entry> + <entry>name type alternate durable</entry> + <entry></entry> + </row> + <row> + <entry>create</entry> + <entry>link</entry> + <entry>name</entry> + <entry></entry> + </row> + <row> + <entry>create</entry> + <entry>queue</entry> + <entry>name alternate durable exclusive autodelete policy queuemaxsizelowerlimit queuemaxsizeupperlimit queuemaxcountlowerlimit queuemaxcountupperlimit filemaxsizelowerlimit filemaxsizeupperlimit filemaxcountlowerlimit filemaxcountupperlimit</entry> + <entry></entry> + </row> + <row> + <entry>delete</entry> + <entry>exchange</entry> + <entry>name</entry> + <entry></entry> + </row> + <row> + <entry>delete</entry> + <entry>queue</entry> + <entry>name</entry> + <entry></entry> + </row> + <row> + <entry>publish</entry> + <entry>exchange</entry> + <entry>name routingkey</entry> + <entry></entry> + </row> + <row> + <entry>purge</entry> + <entry>queue</entry> + <entry>name</entry> + <entry></entry> + </row> + <row> + <entry>unbind</entry> + <entry>exchange</entry> + <entry>name queuename routingkey</entry> + <entry></entry> + </row> + <row> + <entry>update</entry> + <entry>broker</entry> + <entry></entry> + <entry></entry> + </row> + </tbody> + </tgroup> + </table> + <para> + + </para> + </section> </section> <section id="sect-Messaging_User_Guide-Authorization-ACL_Syntactic_Conventions"> <title>ACL Syntactic Conventions</title> - <para> - In ACL files, the following syntactic conventions apply: + <section id="sect-Messaging_User_Guide-Authorization-ACL_Syntactic_Conventions-comments"> + <title>Comments</title> + <para> + <itemizedlist> + <listitem> + <para> + A line starting with the <command>#</command> character is considered a comment and is ignored. + </para> + </listitem> + <listitem> + <para> + Embedded comments and trailing comments are not allowed. The <command>#</command> is commonly found in routing keys and other AMQP literals which occur naturally in ACL rule specifications. + </para> + </listitem> + </itemizedlist> + </para> + </section> + <section id="sect-Messaging_User_Guide-Authorization-ACL_Syntactic_Conventions-whitespace"> + <title>White Space</title> + <itemizedlist> + <listitem> + <para> + Empty lines and lines that contain only whitespace (' ', '\f', '\n', '\r', '\t', '\v') are ignored. + </para> + </listitem> + <listitem> + <para> + Additional whitespace between and after tokens is allowed. + </para> + </listitem> + <listitem> + <para> + Group and Acl definitions must start with <command>group</command> and <command>acl</command> respectively and with no preceding whitespace. + </para> + </listitem> + </itemizedlist> + </section> + <section id="sect-Messaging_User_Guide-Authorization-ACL_Syntactic_Conventions-characterset"> + <title>Character Set</title> + <itemizedlist> + <listitem> + <para> + ACL files use 7-bit ASCII characters only + </para> + </listitem> + <listitem> + <para> + Group names may contain only <itemizedlist> - <listitem> - <para> - A line starting with the <command>#</command> character is considered a comment and is ignored. - </para> - - </listitem> - <listitem> - <para> - Empty lines and lines that contain only whitespace (' ', '\f', '\n', '\r', '\t', '\v') are ignored. - </para> - - </listitem> - <listitem> - <para> - All tokens are case sensitive. <parameter>name1</parameter> is not the same as <parameter>Name1</parameter> and <parameter>create</parameter> is not the same as <parameter>CREATE</parameter>. - </para> - - </listitem> - <listitem> - <para> - Group lists can be extended to the following line by terminating the line with the <command>\</command> character. - </para> - - </listitem> - <listitem> - <para> - Additional whitespace - that is, where there is more than one whitespace character - between and after tokens is ignored. Group and ACL definitions must start with either <command>group</command> or <command>acl</command> and with no preceding whitespace. - </para> - - </listitem> - <listitem> - <para> - All ACL rules are limited to a single line of at most 1024 characters. - </para> - - </listitem> - <listitem> - <para> - Rules are interpreted from the top of the file down until a matching rule is obtained. The matching rule then controls the allow or deny decision. - </para> - - </listitem> - <listitem> - <para> - The keyword <parameter>all</parameter> is reserved and may be used in ACL rules to match all individuals and groups, all actions, or all objects. - </para> - - </listitem> - <listitem> - <para> - By default ACL files are in 'Deny Mode' and deny all actions by all users. That is, there is an implicit <parameter>acl deny all all</parameter> rule appended to the ACL rule list. - </para> - - </listitem> - <listitem> - <para> - Group names may contain only <parameter>a-z</parameter>, <parameter>A-Z</parameter>, <parameter>0-9</parameter>, <parameter>- hyphen</parameter> and <parameter>_ underscore</parameter>. - </para> - - </listitem> - <listitem> - <para> - Individual user names may contain only <parameter>a-z</parameter>, <parameter>A-Z</parameter>, <parameter>0-9</parameter>, <parameter>- hyphen</parameter>, <parameter>_ underscore</parameter>, <parameter>. period</parameter>, <parameter>@ ampersand</parameter>, and <parameter>/ slash</parameter>. - </para> - - </listitem> - <listitem> - <para> - Rules must be preceded by any group definitions they can use. Any name not defined as a group will be assumed to be that of an individual. - </para> - - </listitem> - + <listitem><command>[a-z]</command></listitem> + <listitem><command>[A-Z]</command></listitem> + <listitem><command>[0-9]</command></listitem> + <listitem><command>'-'</command> hyphen</listitem> + <listitem><command>'_'</command> underscore</listitem> + </itemizedlist> + </para> + </listitem> + <listitem> + <para> + Individual user names may contain only + <itemizedlist> + <listitem><command>[a-z]</command></listitem> + <listitem><command>[A-Z]</command></listitem> + <listitem><command>[0-9]</command></listitem> + <listitem><command>'-'</command> hyphen</listitem> + <listitem><command>'_'</command> underscore</listitem> + <listitem><command>'.'</command> period</listitem> + <listitem><command>'@'</command> ampersand</listitem> + <listitem><command>'/'</command> slash</listitem> </itemizedlist> + </para> + </listitem> + </itemizedlist> + </section> + <section id="sect-Messaging_User_Guide-Authorization-ACL_Syntactic_Conventions-casesensitivity"> + <title>Case Sensitivity</title> + <itemizedlist> + <listitem> + <para> + All tokens are case sensitive. <parameter>name1</parameter> is not the same as <parameter>Name1</parameter> and <parameter>create</parameter> is not the same as <parameter>CREATE</parameter>. + </para> + </listitem> + </itemizedlist> + </section> + <section id="sect-Messaging_User_Guide-Authorization-ACL_Syntactic_Conventions-linecontinuation"> + <title>Line Continuation</title> + <itemizedlist> + <listitem> + <para> + Group lists can be extended to the following line by terminating the line with the <command>'\'</command> character. No other ACL file lines may be continued. + </para> + </listitem> + <listitem> + <para> + Group specification lines may be continued only after the group name or any of the user names included in the group. See example below. + </para> + </listitem> + <listitem> + <para> + Lines consisting solely of a <command>'\'</command> character are not permitted. + </para> + </listitem> + <listitem> + <para> + The <command>'\'</command> continuation character is recognized only if it is the last character in the line. Any characters after the <command>'\'</command> are not permitted. + </para> + </listitem> + </itemizedlist> +<programlisting><![CDATA[ + # + # Examples of extending group lists using a trailing '\' character + # + group group1 name1 name2 \ + name3 name4 \ + name5 + + group group2 \ + group1 \ + name6 + # + # The following are illegal: + # + # '\' must be after group name + # + group \ + group3 name7 name8 + # + # No empty extension line + # + group group4 name9 \ + \ + name10 +]]></programlisting> - </para> + </section> + <section id="sect-Messaging_User_Guide-Authorization-ACL_Syntactic_Conventions-linelength"> + <title>Line Length</title> + <itemizedlist> + <listitem> + <para> + ACL file lines are limited to 1024 characters. + </para> + </listitem> + </itemizedlist> + </section> + + + <section id="sect-Messaging_User_Guide-Authorization-ACL_Syntactic_Conventions-keywords"> + <title>ACL File Keywords</title> + ACL reserves several words for convenience and for context sensitive substitution. + + <section id="sect-Messaging_User_Guide-Authorization-ACL_Syntactic_Conventions-keywords-all"> + <title>The <command>all</command> Keyword</title> + The keyword <command>all</command> is reserved. It may be used in ACL rules to match all individuals and groups, all actions, or all objects. + <itemizedlist> + <listitem>acl allow all create queue</listitem> + <listitem>acl allow bob@QPID all queue</listitem> + <listitem>acl allow bob@QPID create all</listitem> + </itemizedlist> + </section> + + <section id="sect-Messaging_User_Guide-Authorization-ACL_Syntactic_Conventions-keywords-userdomain"> + <title>User Name and Domain Name Keywords</title> + <para> + In the C++ Broker 0.20 a simple set of user name and domain name substitution variable keyword tokens is defined. This provides administrators with an easy way to describe private or shared resources. + </para> + <para> + Symbol substitution is allowed in the ACL file anywhere that text is supplied for a property value. + </para> + <para> + In the following table an authenticated user named bob.user@QPID.COM has his substitution keywords expanded. + + <table id="tabl-Messaging_User_Guide-ACL_Syntax-ACL_UsernameSubstitution"> + <title>ACL User Name and Domain Name Substitution Keywords</title> + <tgroup cols="2"> + <thead> + <row> + <entry>Keyword</entry> + <entry>Expansion</entry> + </row> + </thead> + <tbody> + <row> + <entry> <command>${userdomain}</command> </entry> + <entry>bob_user_QPID_COM</entry> + </row> + <row> + <entry> <command>${user}</command> </entry> + <entry>bob_user</entry> + </row> + <row> + <entry> <command>${domain}</command> </entry> + <entry>QPID_COM</entry> + </row> + </tbody> + </tgroup> + </table> + </para> + + <para> + <itemizedlist> + <listitem> + The original user name has the period “.” and ampersand “@” characters translated into underscore “_”. This allows substitution to work when the substitution keyword is used in a routingkey in the Acl file. + </listitem> + <listitem> + The Acl processing matches ${userdomain} before matching either ${user} or ${domain}. Rules that specify the combination ${user}_${domain} will never match. + </listitem> + </itemizedlist> + </para> + +<programlisting><![CDATA[ + # Example: + # + # Administrators can set up Acl rule files that allow every user to create a + # private exchange, a private queue, and a private binding between them. + # In this example the users are also allowed to create private backup exchanges, + # queues and bindings. This effectively provides limits to user's exchange, + # queue, and binding creation and guarantees that each user gets exclusive + # access to these resources. + # + # + # Create primary queue and exchange: + # + acl allow all create queue name=$\{user}-work alternate=$\{user}-work2 + acl deny all create queue name=$\{user}-work alternate=* + acl allow all create queue name=$\{user}-work + acl allow all create exchange name=$\{user}-work alternate=$\{user}-work2 + acl deny all create exchange name=$\{user}-work alternate=* + acl allow all create exchange name=$\{user}-work + # + # Create backup queue and exchange + # + acl deny all create queue name=$\{user}-work2 alternate=* + acl allow all create queue name=$\{user}-work2 + acl deny all create exchange name=$\{user}-work2 alternate=* + acl allow all create exchange name=$\{user}-work2 + # + # Bind/unbind primary exchange + # + acl allow all bind exchange name=$\{user}-work routingkey=$\{user} queuename=$\{user}-work + acl allow all unbind exchange name=$\{user}-work routingkey=$\{user} queuename=$\{user}-work + # + # Bind/unbind backup exchange + # + acl allow all bind exchange name=$\{user}-work2 routingkey=$\{user} queuename=$\{user}-work2 + acl allow all unbind exchange name=$\{user}-work2 routingkey=$\{user} queuename=$\{user}-work2 + # + # Access primary exchange + # + acl allow all access exchange name=$\{user}-work routingkey=$\{user} queuename=$\{user}-work + # + # Access backup exchange + # + acl allow all access exchange name=$\{user}-work2 routingkey=$\{user} queuename=$\{user}-work2 + # + # Publish primary exchange + # + acl allow all publish exchange name=$\{user}-work routingkey=$\{user} + # + # Publish backup exchange + # + acl allow all publish exchange name=$\{user}-work2 routingkey=$\{user} + # + # deny mode + # + acl deny all all +]]></programlisting> + </section> + + </section> + + <section id="sect-Messaging_User_Guide-Authorization-ACL_Syntatic_Conventions-wildcards"> + <title>Wildcards</title> + ACL privides two types of wildcard matching to provide flexibility in writing rules. + + <section id="sect-Messaging_User_Guide-Authorization-ACL_Syntatic_Conventions-wildcards-asterisk"> + <title>Property Value Wildcard</title> + <para> + Text specifying a property value may end with a single trailing <command>*</command> character. + This is a simple wildcard match indicating that strings which match up to that point are matches for the ACL property rule. + An ACL rule such as + </para> + <para> + <programlisting> acl allow bob@QPID create queue name=bob*</programlisting> + </para> + <para> + allow user bob@QPID to create queues named bob1, bob2, bobQueue3, and so on. + </para> + </section> + + <section id="sect-Messaging_User_Guide-Authorization-ACL_Syntatic_Conventions-wildcards-topickey"> + <title>Topic Routing Key Wildcard</title> + <para> + In the C++ Broker 0.20 the logic governing the ACL Match has changed for each ACL rule that contains a routingkey property. + The routingkey property is matched according to Topic Exchange match logic the broker uses when it distributes messages published to a topic exchange. + </para> + <para> + Routing keys are hierarchical where each level is separated by a period: + <itemizedlist> + <listitem>weather.usa</listitem> + <listitem>weather.europe.germany</listitem> + <listitem>weather.europe.germany.berlin</listitem> + <listitem>company.engineering.repository</listitem> + </itemizedlist> + </para> + <para> + Within the routing key hierarchy two wildcard characters are defined. + <itemizedlist> + <listitem><command>*</command> matches one field</listitem> + <listitem><command>#</command> matches zero or more fields</listitem> + </itemizedlist> + </para> + <para> + Suppose an ACL rule file is: + </para> + <para> + <programlisting> + acl allow-log uHash1@COMPANY publish exchange name=X routingkey=a.#.b + acl deny all all + </programlisting> + </para> + <para> + When user uHash1@COMPANY attempts to publish to exchange X the ACL will return these results: + + <table id="tabl-Messaging_User_Guide-ACL_Syntax-ACL_TopicExchangeMatch"> + <title>Topic Exchange Wildcard Match Examples</title> + <tgroup cols="2"> + <thead> + <row> + <entry>routingkey in publish to exchange X</entry> + <entry>result</entry> + </row> + </thead> + <tbody> + <row> + <entry> <command>a.b</command> </entry> + <entry>allow-log</entry> + </row> + <row> + <entry> <command>a.x.b</command> </entry> + <entry>allow-log</entry> + </row> + <row> + <entry> <command>a.x.y.zz.b</command> </entry> + <entry>allow-log</entry> + </row> + <row> + <entry> <command>a.b.</command> </entry> + <entry>deny</entry> + </row> + <row> + <entry> <command>q.x.b</command> </entry> + <entry>deny</entry> + </row> + </tbody> + </tgroup> + </table> - </section> + </para> + </section> + + </section> + + + + </section> <section id="sect-Messaging_User_Guide-Authorization-ACL_Rule_Matching"> <title>ACL Rule Matching</title> @@ -839,51 +1328,51 @@ acl permission {<group-name>|<user-name>|"all"} {action|"all"} [object|"all" <para> The following illustration shows how ACL rules are processed to find matching rules. <programlisting><![CDATA[ -# Example of rule matching -# -# Using this ACL file content: - -(1) acl deny bob create exchange name=test durable=true passive=true -(2) acl deny bob create exchange name=myEx type=direct -(3) acl allow all all - -# -# Lookup 1. id:bob action:create objectType:exchange name=test -# {durable=false passive=false type=direct alternate=} -# -# ACL Match Processing: -# 1. Rule 1 passes minimum criteria with user bob, action create, -# and object exchange. -# 2. Rule 1 matches name=test. -# 3. Rule 1 does not match the rule's durable=true with the requested -# lookup of durable=false. -# 4. Rule 1 does not control the decision and processing continues -# to Rule 2. -# 5. Rule 2 passes minimum criteria with user bob, action create, -# and object exchange. -# 6. Rule 2 does not match the rule's name=myEx with the requested -# lookup of name=test. -# 7. Rule 2 does not control the decision and processing continues -# to Rule 3. -# 8. Rule 3 matches everything and the decision is 'allow'. -# -# Lookup 2. id:bob action:create objectType:exchange name=myEx -# {durable=true passive=true type=direct alternate=} -# -# ACL Match Processing: -# 1. Rule 1 passes minimum criteria with user bob, action create, -# and object exchange. -# 6. Rule 1 does not match the rule's name=test with the requested -# lookup of name=myEx. -# 4. Rule 1 does not control the decision and processing continues -# to Rule 2. -# 5. Rule 2 passes minimum criteria with user bob, action create, -# and object exchange. -# 2. Rule 2 matches name=myEx. -# 3. Rule 2 matches the rule's type=direct with the requested -# lookup of type=direct. -# 8. Rule 2 is the matching rule and the decision is 'deny'. -# + # Example of rule matching + # + # Using this ACL file content: + + (1) acl deny bob create exchange name=test durable=true passive=true + (2) acl deny bob create exchange name=myEx type=direct + (3) acl allow all all + + # + # Lookup 1. id:bob action:create objectType:exchange name=test + # {durable=false passive=false type=direct alternate=} + # + # ACL Match Processing: + # 1. Rule 1 passes minimum criteria with user bob, action create, + # and object exchange. + # 2. Rule 1 matches name=test. + # 3. Rule 1 does not match the rule's durable=true with the requested + # lookup of durable=false. + # 4. Rule 1 does not control the decision and processing continues + # to Rule 2. + # 5. Rule 2 passes minimum criteria with user bob, action create, + # and object exchange. + # 6. Rule 2 does not match the rule's name=myEx with the requested + # lookup of name=test. + # 7. Rule 2 does not control the decision and processing continues + # to Rule 3. + # 8. Rule 3 matches everything and the decision is 'allow'. + # + # Lookup 2. id:bob action:create objectType:exchange name=myEx + # {durable=true passive=true type=direct alternate=} + # + # ACL Match Processing: + # 1. Rule 1 passes minimum criteria with user bob, action create, + # and object exchange. + # 2. Rule 1 does not match the rule's name=test with the requested + # lookup of name=myEx. + # 3. Rule 1 does not control the decision and processing continues + # to Rule 2. + # 4. Rule 2 passes minimum criteria with user bob, action create, + # and object exchange. + # 5. Rule 2 matches name=myEx. + # 6. Rule 2 matches the rule's type=direct with the requested + # lookup of type=direct. + # 7. Rule 2 is the matching rule and the decision is 'deny'. + # ]]></programlisting> </para> @@ -892,38 +1381,38 @@ acl permission {<group-name>|<user-name>|"all"} {action|"all"} [object|"all" <section id="sect-Messaging_User_Guide-Authorization-Specifying_ACL_Permissions"> <title>Specifying ACL Permissions</title> <para> - Now that we have seen the ACL syntax, we will provide representative examples and guidelines for ACL files. + Now that we have seen the ACL syntax, we will provide representative examples and guidelines for ACL files. </para> <para> Most ACL files begin by defining groups: </para> <programlisting> -group admin ted@QPID martin@QPID -group user-consume martin@QPID ted@QPID -group group2 kim@QPID user-consume rob@QPID -group publisher group2 \ -tom@QPID andrew@QPID debbie@QPID + group admin ted@QPID martin@QPID + group user-consume martin@QPID ted@QPID + group group2 kim@QPID user-consume rob@QPID + group publisher group2 \ + tom@QPID andrew@QPID debbie@QPID </programlisting> <para> Rules in an ACL file grant or deny specific permissions to users or groups: </para> <programlisting> -acl allow carlt@QPID create exchange name=carl.* -acl allow rob@QPID create queue -acl allow guest@QPID bind exchange name=amq.topic routingkey=stocks.rht.# -acl allow user-consume create queue name=tmp.* - -acl allow publisher publish all durable=false -acl allow publisher create queue name=RequestQueue -acl allow consumer consume queue durable=true -acl allow fred@QPID create all -acl allow bob@QPID all queue -acl allow admin all -acl allow all consume queue -acl allow all bind exchange -acl deny all all + acl allow carlt@QPID create exchange name=carl.* + acl allow rob@QPID create queue + acl allow guest@QPID bind exchange name=amq.topic routingkey=stocks.rht.# + acl allow user-consume create queue name=tmp.* + + acl allow publisher publish all durable=false + acl allow publisher create queue name=RequestQueue + acl allow consumer consume queue durable=true + acl allow fred@QPID create all + acl allow bob@QPID all queue + acl allow admin all + acl allow all consume queue + acl allow all bind exchange + acl deny all all </programlisting> <para> In the previous example, the last line, <literal>acl deny all all</literal>, denies all authorizations that have not been specifically granted. This is the default, but it is useful to include it explicitly on the last line for the sake of clarity. If you want to grant all rights by default, you can specify <literal>acl allow all all</literal> in the last line. @@ -933,10 +1422,10 @@ acl deny all all </para> <para> <programlisting> -group users alice@QPID bob@QPID charlie@QPID -acl deny charlie@QPID create queue -acl allow users create queue -acl deny all all + group users alice@QPID bob@QPID charlie@QPID + acl deny charlie@QPID create queue + acl allow users create queue + acl deny all all </programlisting> </para> <para> @@ -947,42 +1436,74 @@ acl deny all all </para> <programlisting> -group allUsers guest@QPID -.... -acl deny-log allUsers create link -acl deny-log allUsers access method name=connect -acl deny-log allUsers access method name=echo -acl allow all all + group allUsers guest@QPID + ... + acl deny-log allUsers create link + acl deny-log allUsers access method name=connect + acl deny-log allUsers access method name=echo + acl allow all all </programlisting> </section> - - <section id="sect-Messaging_User_Guide-Authorization-Specifying_ACL_Connection_Limits"> - <title>Specifying ACL Connection Limits</title> - <para> - The ACL module creates two broker command line switches that set limits on the number of connections allowed per user or per client host address. These settings are not specified in the ACL file. - </para> - <para> -<programlisting> ---acl-max-connect-per-user N_USER ---acl-max-connect-per-ip N_IP -</programlisting> - </para> - <para> - If either of these switches is not specified or the value specified is zero then the corresponding connection limit is not enforced. - </para> - <para> - If a limit is set for user connections then all users are limited to that number of connections regardless of the client IP address the users are coming from. - </para> - <para> - If a limit is set for IP connections then connections for a given IP address are limited regardless of the user credentials presented with the connection. - </para> - <para> - Note that addresses using different transports are counted separately even though the host is actually the same physical machine. In the setting illustrated above a host would allow N_IP connections from [::1] IPv6 transport localhost and another N_IP connections from [127.0.0.1] IPv4 transport localhost. - </para> - </section> - - </section> + </section> + + <section id="sect-Messaging_User_Guide-Authorization-Specifying_ACL_Quotas"> + <title>User Connection and Queue Quotas</title> + The ACL module enforces various quotas and thereby limits user activity. + + <section id="sect-Messaging_User_Guide-Authorization-Specifying_ACL_Connection_Limits"> + <title>Connection Limits</title> + <para> + The ACL module creates broker command line switches that set limits on the number of concurrent connections allowed per user or per client host address. These settings are not specified in the ACL file. + </para> + <para> + <programlisting> + --max-connections N + --max-connections-per-user N + --max-connections-per-ip N + </programlisting> + </para> + <para> + If a switch is not specified or the value specified is zero then the corresponding connection limit is not enforced. + </para> + <para> + <command>max-connections</command> specifies an upper limit for all user connections. + </para> + <para> + <command>max-connections-per-user</command> specifies an upper limit for each user based on the authenticated user name. This limit is enforced regardless of the client IP address from which the connection originates. + </para> + <para> + <command>max-connections-per-ip</command> specifies an upper limit for connections for all users based on the originating client IP address. This limit is enforced regardless of the user credentials presented with the connection. + <itemizedlist> + <listitem> + Note that addresses using different transports are counted separately even though the originating host is actually the same physical machine. In the setting illustrated above a host would allow N_IP connections from [::1] IPv6 transport localhost and another N_IP connections from [127.0.0.1] IPv4 transport localhost. + </listitem> + <listitem> + The max-connections-per-ip and max-connections-per-user counts are active simultaneously. From a given client system users may be denied access to the broker by either connection limit. + </listitem> + </itemizedlist> + </para> + </section> + + <section id="sect-Messaging_User_Guide-Authorization-Specifying_ACL_Queue_Limits"> + <title>Queue Limits</title> + <para> + The ACL module creates a broker command line switch that set limits on the number of queues each user is allowed to create. This settings is not specified in the ACL file. + </para> + <para> + <programlisting> + --max-queues-per-user N + </programlisting> + </para> + <para> + If this switch is not specified or the value specified is zero then the queue limit is not enforced. + </para> + <para> + The queue limit is set for all users on the broker based on the authenticated user name. + </para> + </section> + + </section> <!-- ########################### --> <section id="sect-Messaging_User_Guide-Security-Encryption_using_SSL"> <title>Encryption using SSL</title> |