diff --git a/doc/Pacemaker_Explained/en-US/Book_Info.xml b/doc/Pacemaker_Explained/en-US/Book_Info.xml
index 3da61de4f7..aae3d06b4d 100644
--- a/doc/Pacemaker_Explained/en-US/Book_Info.xml
+++ b/doc/Pacemaker_Explained/en-US/Book_Info.xml
@@ -1,35 +1,35 @@
Configuration Explained
An A-Z guide to Pacemaker's Configuration Options
Pacemaker
2.0
12
- 0
+ 2
The purpose of this document is to definitively explain the concepts used to configure Pacemaker.
To achieve this, it will focus exclusively on the XML syntax used to configure Pacemaker's
Cluster Information Base (CIB).
diff --git a/doc/Pacemaker_Explained/en-US/Ch-ACLs.txt b/doc/Pacemaker_Explained/en-US/Ch-ACLs.txt
new file mode 100644
index 0000000000..64a100323f
--- /dev/null
+++ b/doc/Pacemaker_Explained/en-US/Ch-ACLs.txt
@@ -0,0 +1,327 @@
+:compat-mode: legacy
+= Access Control Lists (ACLs) =
+
+////
+We prefer [[ch-acls]], but older versions of asciidoc don't deal well
+with that construct for chapter headings
+////
+anchor:ch-acls[Chapter 13, ACLs]
+indexterm:[access control list]
+indexterm:[ACL]
+
+By default, the +root+ user or any user in the +haclient+ group can modify
+Pacemaker's CIB without restriction. Pacemaker offers 'access control lists
+(ACLs)' to provide more fine-grained authorization.
+
+== ACL Prerequisites ==
+
+In order to use ACLs:
+
+* The Pacemaker software must have been compiled with ACL support. If the
+ output of the command `pacemakerd --features` contains `acls`, your
+ installation supports ACLs.
+
+* Desired users must have user accounts in the +haclient+ group on all nodes in
+ the cluster.
+
+* If your CIB was created before Pacemaker 1.1.12, it may need to be updated to
+ the current schema using `cibadmin --upgrade` in order to use the syntax
+ documented here.
+
+* The +enable-acl+ <> must be set to true.
+
+== ACL Configuration ==
+
+ACLs are specified within an +acls+ element of the CIB. The +acls+ element may
+contain any number of +acl_role+, +acl_target+, and +acl_group+ elements.
+
+== ACL Roles ==
+
+An ACL role is a collection of permissions allowing or denying access to
+particular portions of the CIB.
+
+.Properties of an ACL Role
+[width="95%",cols="1m,<3",options="header",align="center"]
+|====
+
+|Attribute
+|Description
+
+|id
+|A unique name for the role (required)
+ indexterm:[id,acl_role]
+ indexterm:[access control list,acl_role,id]
+
+|description
+|Arbitrary text (not used by Pacemaker)
+ indexterm:[description,acl_role]
+ indexterm:[access control list,acl_role,description]
+
+|====
+
+An +acl_role+ element may contain any number of +acl_permission+ elements.
+
+.Properties of an ACL Permission
+[width="95%",cols="1m,<3",options="header",align="center"]
+|====
+
+|Attribute
+|Description
+
+|id
+|A unique name for the permission (required)
+ indexterm:[id,acl_permission]
+ indexterm:[access control list,acl_permission,id]
+
+|description
+|Arbitrary text (not used by Pacemaker)
+ indexterm:[description,acl_permission]
+ indexterm:[access control list,acl_permission,description]
+
+|kind
+|The access being granted. Allowed values are +read+, +write+, and +deny+.
+ A value of +write+ grants both read and write access.
+ indexterm:[kind,acl_permission]
+ indexterm:[access control list,acl_permission,kind]
+
+|object-type
+|The name of an XML element in the CIB to which the permission applies.
+ (Exactly one of +object-type+, +xpath+, and +reference+ must be specified for
+ a permission.)
+ indexterm:[object-type,acl_permission]
+ indexterm:[access control list,acl_permission,object-type]
+
+|attribute
+|If specified, the permission applies only to +object-type+ elements that have
+ this attribute set (to any value). If not specified, the permission applies to
+ all +object-type+ elements. May only be used with +object-type+.
+ indexterm:[attribute,acl_permission]
+ indexterm:[access control list,acl_permission,attribute]
+
+|reference
+|The ID of an XML element in the CIB to which the permission applies.
+ (Exactly one of +object-type+, +xpath+, and +reference+ must be specified for
+ a permission.)
+ indexterm:[reference,acl_permission]
+ indexterm:[access control list,acl_permission,reference]
+
+|xpath
+|An https://www.w3.org/TR/xpath-10/[XPath] specification selecting an XML
+ element in the CIB to which the permission applies. Attributes may be
+ specified in the XPath to select particular elements, but the permissions
+ apply to the entire element.
+ (Exactly one of +object-type+, +xpath+, and +reference+ must be specified for
+ a permission.)
+ indexterm:[xpath,acl_permission]
+ indexterm:[access control list,acl_permission,xpath]
+
+|====
+
+[IMPORTANT]
+====
+Permissions are applied to the selected XML element's entire XML subtree
+(all elements enclosed within it). Permissions for more specific matches (more
+deeply nested elements) take precedence over more general ones. If multiple
+permissions are configured for the same match (for example, in different roles
+applied to the same user), any +deny+ permission takes precedence, then
++write+, then lastly +read+.
+====
+
+== ACL Targets and Groups ==
+
+ACL targets correspond to user accounts on the system.
+
+.Properties of an ACL Target
+[width="95%",cols="1m,<3",options="header",align="center"]
+|====
+
+|Attribute
+|Description
+
+|id
+|The name of a user on the system (required)
+ indexterm:[id,acl_target]
+ indexterm:[access control list,acl_target,id]
+
+|====
+
+ACL groups may be specified, but are not currently used by Pacemaker. This is
+expected to change in a future version.
+
+.Properties of an ACL Group
+[width="95%",cols="1m,<3",options="header",align="center"]
+|====
+
+|Attribute
+|Description
+
+|id
+|The name of a group on the system (required)
+ indexterm:[id,acl_group]
+ indexterm:[access control list,acl_group,id]
+
+|====
+
+Each +acl_target+ and +acl_group+ element may contain any number of +role+
+elements.
+
+.Properties of an ACL Role Reference
+[width="95%",cols="1m,<3",options="header",align="center"]
+|====
+
+|Attribute
+|Description
+
+|id
+|The +id+ of an +acl_role+ element that specifies permissions granted to the
+ enclosing target or group
+ indexterm:[id,role]
+ indexterm:[access control list,role,id]
+
+|====
+
+[IMPORTANT]
+====
+The +root+ and +hacluster+ user accounts always have full access to the CIB,
+regardless of ACLs. For other user accounts, when +enable-acl+ is true,
+permission to all parts of the CIB is denied by default (permissions must be
+explicitly granted).
+====
+
+== ACL Examples ==
+
+[source,XML]
+----
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+----
+
+In the above example, the user +alice+ has the minimal permissions necessary to
+run basic Pacemaker CLI tools, including using `crm_mon` to view the cluster
+status, without being able to modify anything. The user +bob+ can view the
+entire configuration and status of the cluster, but not make any changes. The
+user +carol+ can read everything, and change selected cluster properties as
+well as resource roles and location constraints. Finally, +dave+ has full read
+and write access to the entire CIB.
+
+Looking at the +minimal+ role in more depth, it is designed to allow read
+access to the +cib+ tag itself, while denying access to particular portions of
+its subtree (which is the entire CIB).
+
+This is because the DC node is indicated in the +cib+ tag, so `crm_mon` will
+not be able to report the DC otherwise. However, this does change the security
+model to allow by default, since any portions of the CIB not explicitly denied
+will be readable. The +cib+ read access could be removed and replaced with read
+access to just the +crm_config+ and +status+ sections, for a safer approach at
+the cost of not seeing the DC in status output.
+
+For a simpler configuration, the +minimal+ role allows read access to the
+entire +crm_config+ section, which contains cluster properties. It would be
+possible to allow read access to specific properties instead (such as
++stonith-enabled+, +dc-uuid+, +have-quorum+, and +cluster-name+) to restrict
+access further while still allowing status output, but cluster properties are
+unlikely to be considered sensitive.
diff --git a/doc/Pacemaker_Explained/en-US/Ch-Options.txt b/doc/Pacemaker_Explained/en-US/Ch-Options.txt
index 3fb06a96e3..15001b1265 100644
--- a/doc/Pacemaker_Explained/en-US/Ch-Options.txt
+++ b/doc/Pacemaker_Explained/en-US/Ch-Options.txt
@@ -1,422 +1,428 @@
:compat-mode: legacy
= Cluster-Wide Configuration =
== Configuration Layout ==
The cluster is defined by the Cluster Information Base (CIB),
which uses XML notation. The simplest CIB, an empty one, looks like this:
.An empty configuration
======
[source,XML]
-------
-------
======
The empty configuration above contains the major sections that make up a CIB:
* +cib+: The entire CIB is enclosed with a +cib+ tag. Certain fundamental settings
are defined as attributes of this tag.
** +configuration+: This section -- the primary focus of this document --
contains traditional configuration information such as what resources the
cluster serves and the relationships among them.
*** +crm_config+: cluster-wide configuration options
*** +nodes+: the machines that host the cluster
*** +resources+: the services run by the cluster
*** +constraints+: indications of how resources should be placed
** +status+: This section contains the history of each resource on each node.
Based on this data, the cluster can construct the complete current
state of the cluster. The authoritative source for this section
is the local executor (pacemaker-execd process) on each cluster node, and
the cluster will occasionally repopulate the entire section. For this
reason, it is never written to disk, and administrators are advised
against modifying it in any way.
In this document, configuration settings will be described as 'properties' or 'options'
based on how they are defined in the CIB:
* Properties are XML attributes of an XML element.
* Options are name-value pairs expressed as +nvpair+ child elements of an XML element.
Normally, you will use command-line tools that abstract the XML, so the
distinction will be unimportant; both properties and options are
cluster settings you can tweak.
== CIB Properties ==
Certain settings are defined by CIB properties (that is, attributes of the
+cib+ tag) rather than with the rest of the cluster configuration in the
+configuration+ section.
The reason is simply a matter of parsing. These options are used by the
configuration database which is, by design, mostly ignorant of the content it
holds. So the decision was made to place them in an easy-to-find location.
.CIB Properties
[width="95%",cols="2m,<5",options="header",align="center"]
|=========================================================
|Field |Description
| admin_epoch |
indexterm:[Configuration Version,Cluster]
indexterm:[Cluster,Option,Configuration Version]
indexterm:[admin_epoch,Cluster Option]
indexterm:[Cluster,Option,admin_epoch]
When a node joins the cluster, the cluster performs a check to see
which node has the best configuration. It asks the node with the highest
(+admin_epoch+, +epoch+, +num_updates+) tuple to replace the configuration on
all the nodes -- which makes setting them, and setting them correctly, very
important. +admin_epoch+ is never modified by the cluster; you can use this
to make the configurations on any inactive nodes obsolete. _Never set this
value to zero_. In such cases, the cluster cannot tell the difference between
your configuration and the "empty" one used when nothing is found on disk.
| epoch |
indexterm:[epoch,Cluster Option]
indexterm:[Cluster,Option,epoch]
The cluster increments this every time the configuration is updated (usually by
the administrator).
| num_updates |
indexterm:[num_updates,Cluster Option]
indexterm:[Cluster,Option,num_updates]
The cluster increments this every time the configuration or status is updated
(usually by the cluster) and resets it to 0 when epoch changes.
| validate-with |
indexterm:[validate-with,Cluster Option]
indexterm:[Cluster,Option,validate-with]
Determines the type of XML validation that will be done on the configuration.
If set to +none+, the cluster will not verify that updates conform to the
DTD (nor reject ones that don't). This option can be useful when
operating a mixed-version cluster during an upgrade.
|cib-last-written |
indexterm:[cib-last-written,Cluster Property]
indexterm:[Cluster,Property,cib-last-written]
Indicates when the configuration was last written to disk. Maintained by the
cluster; for informational purposes only.
|have-quorum |
indexterm:[have-quorum,Cluster Property]
indexterm:[Cluster,Property,have-quorum]
Indicates if the cluster has quorum. If false, this may mean that the
cluster cannot start resources or fence other nodes (see
+no-quorum-policy+ below). Maintained by the cluster.
|dc-uuid |
indexterm:[dc-uuid,Cluster Property]
indexterm:[Cluster,Property,dc-uuid]
Indicates which cluster node is the current leader. Used by the
cluster when placing resources and determining the order of some
events. Maintained by the cluster.
|=========================================================
[[s-cluster-options]]
== Cluster Options ==
Cluster options, as you might expect, control how the cluster behaves
when confronted with certain situations.
They are grouped into sets within the +crm_config+ section, and, in advanced
configurations, there may be more than one set. (This will be described later
in the section on <> where we will show how to have the cluster use
different sets of options during working hours than during weekends.) For now,
we will describe the simple case where each option is present at most once.
You can obtain an up-to-date list of cluster options, including
their default values, by running the `man pacemaker-schedulerd` and
`man pacemaker-controld` commands.
.Cluster Options
[width="95%",cols="5m,2,<11",options="header",align="center"]
|=========================================================
|Option |Default |Description
| cluster-name | |
indexterm:[cluster-name,Cluster Property]
indexterm:[Cluster,Property,cluster-name]
An (optional) name for the cluster as a whole. This is mostly for users'
convenience for use as desired in administration, but this can be used
in the Pacemaker configuration in <> (as the
+#cluster-name+ <>). It may
also be used by higher-level tools when displaying cluster information, and by
certain resource agents (for example, the +ocf:heartbeat:GFS2+ agent stores the
cluster name in filesystem meta-data).
| dc-version | |
indexterm:[dc-version,Cluster Property]
indexterm:[Cluster,Property,dc-version]
Version of Pacemaker on the cluster's DC.
Determined automatically by the cluster.
Often includes the hash which identifies the exact Git changeset it was built
from. Used for diagnostic purposes.
| cluster-infrastructure | |
indexterm:[cluster-infrastructure,Cluster Property]
indexterm:[Cluster,Property,cluster-infrastructure]
The messaging stack on which Pacemaker is currently running.
Determined automatically by the cluster.
Used for informational and diagnostic purposes.
| no-quorum-policy | stop
a|
indexterm:[no-quorum-policy,Cluster Option]
indexterm:[Cluster,Option,no-quorum-policy]
What to do when the cluster does not have quorum. Allowed values:
* +ignore:+ continue all resource management
* +freeze:+ continue resource management, but don't recover resources from nodes not in the affected partition
* +stop:+ stop all resources in the affected cluster partition
* +suicide:+ fence all nodes in the affected cluster partition
| batch-limit | 0 |
indexterm:[batch-limit,Cluster Option]
indexterm:[Cluster,Option,batch-limit]
The maximum number of actions that the cluster may execute in parallel across
all nodes. The "correct" value will depend on the speed and load of your
network and cluster nodes. If zero, the cluster will impose a dynamically
calculated limit only when any node has high load.
| migration-limit | -1 |
indexterm:[migration-limit,Cluster Option]
indexterm:[Cluster,Option,migration-limit]
The number of <> actions that the cluster
is allowed to execute in parallel on a node. A value of -1 means unlimited.
| symmetric-cluster | TRUE |
indexterm:[symmetric-cluster,Cluster Option]
indexterm:[Cluster,Option,symmetric-cluster]
Can all resources run on any node by default?
| stop-all-resources | FALSE |
indexterm:[stop-all-resources,Cluster Option]
indexterm:[Cluster,Option,stop-all-resources]
Should the cluster stop all resources?
| stop-orphan-resources | TRUE |
indexterm:[stop-orphan-resources,Cluster Option]
indexterm:[Cluster,Option,stop-orphan-resources]
Should deleted resources be stopped? This value takes precedence over
+is-managed+ (i.e. even unmanaged resources will be stopped if deleted from
the configuration when this value is TRUE).
| stop-orphan-actions | TRUE |
indexterm:[stop-orphan-actions,Cluster Option]
indexterm:[Cluster,Option,stop-orphan-actions]
Should deleted actions be cancelled?
| start-failure-is-fatal | TRUE |
indexterm:[start-failure-is-fatal,Cluster Option]
indexterm:[Cluster,Option,start-failure-is-fatal]
Should a failure to start a resource on a particular node prevent further start
attempts on that node? If FALSE, the cluster will decide whether the same
node is still eligible based on the resource's current failure count
and +migration-threshold+ (see <>).
| enable-startup-probes | TRUE |
indexterm:[enable-startup-probes,Cluster Option]
indexterm:[Cluster,Option,enable-startup-probes]
Should the cluster check for active resources during startup?
| maintenance-mode | FALSE |
indexterm:[maintenance-mode,Cluster Option]
indexterm:[Cluster,Option,maintenance-mode]
Should the cluster refrain from monitoring, starting and stopping resources?
| stonith-enabled | TRUE |
indexterm:[stonith-enabled,Cluster Option]
indexterm:[Cluster,Option,stonith-enabled]
Should failed nodes and nodes with resources that can't be stopped be
shot? If you value your data, set up a STONITH device and enable this.
If true, or unset, the cluster will refuse to start resources unless
one or more STONITH resources have been configured.
If false, unresponsive nodes are immediately assumed to be running no
resources, and resource takeover to online nodes starts without any
further protection (which means _data loss_ if the unresponsive node
still accesses shared storage, for example). See also the +requires+
meta-attribute in <>.
| stonith-action | reboot |
indexterm:[stonith-action,Cluster Option]
indexterm:[Cluster,Option,stonith-action]
Action to send to STONITH device. Allowed values are +reboot+ and +off+.
The value +poweroff+ is also allowed, but is only used for
legacy devices.
| stonith-timeout | 60s |
indexterm:[stonith-timeout,Cluster Option]
indexterm:[Cluster,Option,stonith-timeout]
How long to wait for STONITH actions (reboot, on, off) to complete
| stonith-max-attempts | 10 |
indexterm:[stonith-max-attempts,Cluster Option]
indexterm:[Cluster,Option,stonith-max-attempts]
How many times fencing can fail for a target before the cluster will no longer
immediately re-attempt it.
| stonith-watchdog-timeout | 0 |
indexterm:[stonith-watchdog-timeout,Cluster Option]
indexterm:[Cluster,Option,stonith-watchdog-timeout]
If nonzero, rely on hardware watchdog self-fencing. If positive, assume unseen
nodes self-fence within this much time. If negative, and the
SBD_WATCHDOG_TIMEOUT environment variable is set, use twice that value.
| concurrent-fencing | FALSE |
indexterm:[concurrent-fencing,Cluster Option]
indexterm:[Cluster,Option,concurrent-fencing]
Is the cluster allowed to initiate multiple fence actions concurrently?
| cluster-delay | 60s |
indexterm:[cluster-delay,Cluster Option]
indexterm:[Cluster,Option,cluster-delay]
Estimated maximum round-trip delay over the network (excluding action
execution). If the DC requires an action to be executed on another
node, it will consider the action failed if it does not get a response
from the other node in this time (after considering the action's
own timeout). The "correct" value will depend on the speed and load of your
network and cluster nodes.
| dc-deadtime | 20s |
indexterm:[dc-deadtime,Cluster Option]
indexterm:[Cluster,Option,dc-deadtime]
How long to wait for a response from other nodes during startup.
The "correct" value will depend on the speed/load of your network and the type of switches used.
| cluster-recheck-interval | 15min |
indexterm:[cluster-recheck-interval,Cluster Option]
indexterm:[Cluster,Option,cluster-recheck-interval]
Polling interval for time-based changes to options, resource parameters and constraints.
The Cluster is primarily event-driven, but your configuration can have
elements that take effect based on the time of day. To ensure these changes
take effect, we can optionally poll the cluster's status for changes. A value
of 0 disables polling. Positive values are an interval (in seconds unless other
SI units are specified, e.g. 5min).
| cluster-ipc-limit | 500 |
indexterm:[cluster-ipc-limit,Cluster Option]
indexterm:[Cluster,Option,cluster-ipc-limit]
The maximum IPC message backlog before one cluster daemon will disconnect
another. This is of use in large clusters, for which a good value is the number
of resources in the cluster multiplied by the number of nodes. The default of
500 is also the minimum. Raise this if you see "Evicting client" messages for
cluster daemon PIDs in the logs.
| pe-error-series-max | -1 |
indexterm:[pe-error-series-max,Cluster Option]
indexterm:[Cluster,Option,pe-error-series-max]
The number of PE inputs resulting in ERRORs to save. Used when reporting problems.
A value of -1 means unlimited (report all).
| pe-warn-series-max | -1 |
indexterm:[pe-warn-series-max,Cluster Option]
indexterm:[Cluster,Option,pe-warn-series-max]
The number of PE inputs resulting in WARNINGs to save. Used when reporting problems.
A value of -1 means unlimited (report all).
| pe-input-series-max | -1 |
indexterm:[pe-input-series-max,Cluster Option]
indexterm:[Cluster,Option,pe-input-series-max]
The number of "normal" PE inputs to save. Used when reporting problems.
A value of -1 means unlimited (report all).
| placement-strategy | default |
indexterm:[placement-strategy,Cluster Option]
indexterm:[Cluster,Option,placement-strategy]
How the cluster should allocate resources to nodes (see <>).
Allowed values are +default+, +utilization+, +balanced+, and +minimal+.
| node-health-strategy | none |
indexterm:[node-health-strategy,Cluster Option]
indexterm:[Cluster,Option,node-health-strategy]
How the cluster should react to node health attributes (see <>).
Allowed values are +none+, +migrate-on-red+, +only-green+, +progressive+, and
+custom+.
+| enable-acl | FALSE |
+indexterm:[enable-acl,Cluster Option]
+indexterm:[Cluster,Option,enable-acl]
+ Whether access control lists (ACLs) (see <>) can be used to authorize
+ modifications to the CIB.
+
| node-health-base | 0 |
indexterm:[node-health-base,Cluster Option]
indexterm:[Cluster,Option,node-health-base]
The base health score assigned to a node. Only used when
+node-health-strategy+ is +progressive+.
| node-health-green | 0 |
indexterm:[node-health-green,Cluster Option]
indexterm:[Cluster,Option,node-health-green]
The score to use for a node health attribute whose value is +green+.
Only used when +node-health-strategy+ is +progressive+ or +custom+.
| node-health-yellow | 0 |
indexterm:[node-health-yellow,Cluster Option]
indexterm:[Cluster,Option,node-health-yellow]
The score to use for a node health attribute whose value is +yellow+.
Only used when +node-health-strategy+ is +progressive+ or +custom+.
| node-health-red | 0 |
indexterm:[node-health-red,Cluster Option]
indexterm:[Cluster,Option,node-health-red]
The score to use for a node health attribute whose value is +red+.
Only used when +node-health-strategy+ is +progressive+ or +custom+.
| remove-after-stop | FALSE |
indexterm:[remove-after-stop,Cluster Option]
indexterm:[Cluster,Option,remove-after-stop]
_Advanced Use Only:_ Should the cluster remove resources from the LRM after
they are stopped? Values other than the default are, at best, poorly tested and
potentially dangerous.
| startup-fencing | TRUE |
indexterm:[startup-fencing,Cluster Option]
indexterm:[Cluster,Option,startup-fencing]
_Advanced Use Only:_ Should the cluster shoot unseen nodes?
Not using the default is very unsafe!
| election-timeout | 2min |
indexterm:[election-timeout,Cluster Option]
indexterm:[Cluster,Option,election-timeout]
_Advanced Use Only:_ If you need to adjust this value, it probably indicates
the presence of a bug.
| shutdown-escalation | 20min |
indexterm:[shutdown-escalation,Cluster Option]
indexterm:[Cluster,Option,shutdown-escalation]
_Advanced Use Only:_ If you need to adjust this value, it probably indicates
the presence of a bug.
| join-integration-timeout | 3min |
indexterm:[join-integration-timeout,Cluster Option]
indexterm:[Cluster,Option,join-integration-timeout]
_Advanced Use Only:_ If you need to adjust this value, it probably indicates
the presence of a bug.
| join-finalization-timeout | 30min |
indexterm:[join-finalization-timeout,Cluster Option]
indexterm:[Cluster,Option,join-finalization-timeout]
_Advanced Use Only:_ If you need to adjust this value, it probably indicates
the presence of a bug.
| transition-delay | 0s |
indexterm:[transition-delay,Cluster Option]
indexterm:[Cluster,Option,transition-delay]
_Advanced Use Only:_ Delay cluster recovery for the configured interval to
allow for additional/related events to occur. Useful if your configuration is
sensitive to the order in which ping updates arrive.
Enabling this option will slow down cluster recovery under
all conditions.
|=========================================================
diff --git a/doc/Pacemaker_Explained/en-US/Pacemaker_Explained.xml b/doc/Pacemaker_Explained/en-US/Pacemaker_Explained.xml
index 31bb67675d..5c3c84b7a4 100644
--- a/doc/Pacemaker_Explained/en-US/Pacemaker_Explained.xml
+++ b/doc/Pacemaker_Explained/en-US/Pacemaker_Explained.xml
@@ -1,26 +1,27 @@
+
diff --git a/doc/Pacemaker_Explained/en-US/Revision_History.xml b/doc/Pacemaker_Explained/en-US/Revision_History.xml
index 270734f3ea..531b3760f5 100644
--- a/doc/Pacemaker_Explained/en-US/Revision_History.xml
+++ b/doc/Pacemaker_Explained/en-US/Revision_History.xml
@@ -1,174 +1,186 @@
Revision History
1-0
19 Oct 2009
AndrewBeekhofandrew@beekhof.net
Import from Pages.app
2-0
26 Oct 2009
AndrewBeekhofandrew@beekhof.net
Cleanup and reformatting of docbook xml complete
3-0
Tue Nov 12 2009
AndrewBeekhofandrew@beekhof.net
Split book into chapters and pass validation
Re-organize book for use with Publican
4-0
Mon Oct 8 2012
AndrewBeekhofandrew@beekhof.net
Converted to asciidoc
(which is converted to docbook for use with
Publican)
5-0
Mon Feb 23 2015
KenGaillotkgaillot@redhat.com
Update for clarity, stylistic consistency and current command-line syntax
6-0
Tue Dec 8 2015
KenGaillotkgaillot@redhat.com
Update for Pacemaker 1.1.14
7-0
Tue May 3 2016
KenGaillotkgaillot@redhat.com
Update for Pacemaker 1.1.15
7-1
Fri Oct 28 2016
KenGaillotkgaillot@redhat.com
Overhaul upgrade documentation, and document node health strategies
8-0
Tue Oct 25 2016
KenGaillotkgaillot@redhat.com
Update for Pacemaker 1.1.16
9-0
Tue Jul 11 2017
KenGaillotkgaillot@redhat.com
Update for Pacemaker 1.1.17
10-0
Fri Oct 6 2017
KenGaillotkgaillot@redhat.com
Update for Pacemaker 1.1.18
11-0
Fri Jan 12 2018
KenGaillotkgaillot@redhat.com
Update for Pacemaker 2.0.0
12-0
Mon Jan 28 2019
KenGaillotkgaillot@redhat.com
ReidWahlnwahl@redhat.com
JanPokornýjpokorny@redhat.com
Update for Pacemaker 2.0.1, remove "Further Reading" and "FAQ" sections,
and add minor clarifications and reformatting
12-1
Mon May 13 2019
KenGaillotkgaillot@redhat.com
MaciejSobkowiakmsobkowiak@egnyte.com
Document podman support, cluster-name cluster option, and new
HealthIOWait agent, with other minor clarifications and
corrections
+
+ 12-2
+ Wed Jun 19 2019
+ KenGaillotkgaillot@redhat.com
+
+
+
+ Add chapter for ACLs
+
+
+
+
diff --git a/doc/acls.txt b/doc/acls.txt
index ce3d44f381..2028856aeb 100644
--- a/doc/acls.txt
+++ b/doc/acls.txt
@@ -1,200 +1,4 @@
Pacemaker Access Control Lists
==============================
-Tim Serong
-
-== Introduction
-
-The various tools for administering Pacemaker clusters (crm_mon,
-crm shell, cibadmin and friends, Python GUI, Hawk) can be used by
-the +root+ user, or any user in the +haclient+ group. By default,
-these users have full read/write access. Starting with Pacemaker
-version 1.1.5, flexible access control lists are introduced to
-provide different levels of administration to different users.
-
-== Prerequisites
-
-* Users are regular UNIX users, so the same user accounts must
- be present on all nodes in the cluster.
-* All user accounts must be in the +haclient+ group.
-* Pacemaker 1.1.5 or newer must be installed on all cluster nodes.
-* The CIB must be configured to use the pacemaker-1.1 or 1.2 schema.
- This can be set by running:
-
- cibadmin --modify --xml-text ''
-
-* The +enable-acl+ option must be set. If ACLs are not explicitly
- enabled, the previous behaviour will be used (i.e. all users in
- the +haclient+ group have full access):
-
- crm configure property enable-acl=true
-
-* Once this is done, ACLs can be configured as described below.
-* Note that the +root+ and +hacluster+ users will always have full
- access.
-* If nonprivileged users will be using the crm shell and CLI tools
- (as opposed to only using Hawk or the Python GUI) they will need
- to have +/usr/sbin+ added to their path.
-
-== Configuring ACLs
-
-Access control lists consist of an ordered set of access rules.
-Each rule allows read or write access or denies access completely
-to a part of the CIB. Rules are typically combined to produce a
-specific role, then users may be assigned to that role. It is
-also possible to configure ACLs directly for individual users.
-
-ACLs may be configured using the crm shell or the Python GUI.
-The shell syntax is documented here. Using the Python GUI should
-be reasonably straightforward once the concepts are understood.
-
-Note that rules are applied from first to last with the first
-matching rule being used. This means specific +write+ rules
-usually need to be listed before general +read+ rules. Any
-permission not explicitly granted is denied by default, but note
-that +write+ implies +read+, so there is no need to specify both
-to allow full read/write access.
-
-=== Minimum Required ACLs
-
-In order for the various tools to work correctly, a certain minimum
-amount of data must be readable by the user invoking the tool. In
-general, the safest thing to do is simply allow all users and roles
-read access to the entire CIB.
-
-=== Role Syntax
-
-An ACL role is a set of rules which describe access rights to
-CIB. Rules consist of an access right +read+, +write+, or +deny+
-and a specification denoting part of the configuration to which
-the access right applies. The specification can be an XPath or a
-combination of tag and id references. If an attribute is appended,
-then the specification applies only to that attribute of the matching
-element.
-
-==== Usage
-
-...............
- role rule [rule ...]
-
- rule :: acl-right cib-spec [attribute:]
-
- acl-right :: read | write | deny
-
- cib-spec :: xpath-spec | tag-ref-spec
- xpath-spec :: xpath:
- tag-ref-spec :: tag: | ref: | tag: ref:
-...............
-
-==== Example Role: Read-only Access
-
-...............
- role monitor \
- read xpath:"/cib"
-...............
-
-This is a single rule which allows read-only access to the entire
-CIB. Users with this role will be able to view the status of
-the cluster, but not make any changes.
-
-==== Example Role: ``Operator'' Access
-
-...............
- role operator \
- write xpath:"//crm_config//nvpair[@name='maintenance-mode']" \
- write xpath:"//op_defaults//nvpair[@name='record-pending']" \
- write xpath:"//nodes/node//nvpair[@name='standby']" \
- write xpath:"//resources//nvpair[@name='target-role']" \
- write xpath:"//resources//nvpair[@name='is-managed']" \
- write xpath:"//constraints/rsc_location" \
- read xpath:"/cib"
-...............
-
-These rules specify that users with this role will be able to:
-
-. Turn maintenance mode on or off
-. Change whether pending operations are recorded
-. Put any node on standby, and bring any node back online
-. Start, stop, promote or demote any resource
-. Tell the cluster to manage, or not manage any resource
-. Migrate/move resources from node to note
-. View the status of the cluster
-
-Users with this role will not be able to reconfigure resources
-(change parameters, operations, etc.) or colocation or ordering
-constraints.
-
-==== Example Role: Full Access
-
-...............
- role administrator \
- write xpath:"/cib"
-...............
-
-This is a single rule which allows full read-write access to the
-entire CIB. Users with this role will have equivalent access to
-the +root+ and +hacluster+ users.
-
-=== User Syntax
-
-ACLs can be defined for individual users using the same syntax
-as for roles. Alternately, users can simply be assigned a given
-role. The latter is considered best practice.
-
-==== Usage
-
-...............
- user {role:|rule [rule ...]}
-
- rule :: acl-right cib-spec [attribute:]
-
- acl-right :: read | write | deny
-
- cib-spec :: xpath-spec | tag-ref-spec
- xpath-spec :: xpath:
- tag-ref-spec :: tag: | ref: | tag: ref:
-...............
-
-==== Example
-
-...............
- user alice role:monitor
- user bob role:operator
-...............
-
-The above example assigns +alice+ the +monitor+ role and +bob+ the
-+operator+ role.
-
-== Advanced Usage
-
-Because ACLs can refer to elements and attributes in the CIB in a
-very granular way, it is possible to configure very specific rules.
-A refinement of the ``operator'' role above would be to allow
-manipulation of only a specific resource, for example:
-
-...............
- role bigdb_admin \
- write xpath:"//primitive[@id='bigdb']/meta_attributes/nvpair[@name='target-role']" \
- write xpath:"//primitive[@id='bigdb']/meta_attributes/nvpair[@name='is-managed']" \
- write xpath:"//constraints/rsc_location[@rsc='bigdb']" \
- read ref:"bigdb" \
- read xpath:"//nodes/node" uname \
- read xpath:"//nodes/node" type \
- read xpath:"//crm_config/cluster_property_set" \
- read xpath:"/cib/status"
-...............
-
-The first four rules are specific for the +bigdb+ resource. They
-allow modifying the +target-role+ and +is-managed+ meta
-attributes which effectively enables users in this role to
-stop/start and manage/unmanage the resource. The constraints
-write access rule allows moving the resource around. Finally, the
-user is granted read access to the resource definition.
-
-The bottom four rules are the absolute minimum read permissions
-necessary for proper operation of various Pacemaker tools,
-including `crm_mon` and the shell. This is fine for viewing
-cluster status, but there are some tools for which this will
-not be sufficient access (notably `crm_simulate`), which is why it is
-generally recommended that read access be allowed to the entire
-CIB.
-
+This document has been retired. See the Access Control Lists chapter of the
+Pacemaker Explained documentation instead.