anchor.diff:  
   This section provides a quick overview of NiFi Clustering and instructions on how to set up a basic cluster. In the future, we hope to provide supplemental documentation that covers the NiFi Cluster Architecture in depth. 
   
  -The design of NiFi clustering is a simple master/slave model where there is a master and one or more slaves. While the model is that of master and slave, if the master dies, the slaves are all instructed to continue operating as they were to ensure the dataflow remains live. The absence of the master simply means new slaves cannot join the cluster and cluster flow changes cannot occur until the master is restored. In NiFi clustering, we call the master the NiFi Cluster Manager (NCM), and the slaves are called Nodes. See a full description of each in the Terminology section below.
  +The design of NiFi clustering is a simple master/slave model where there is a master and one or more slaves. 
  +While the model is that of master and slave, if the master dies, the slaves are all instructed to continue operating 
  +as they were to ensure the dataflow remains live. The absence of the master simply means new slaves cannot join the 
  +cluster and cluster flow changes cannot occur until the master is restored. In NiFi clustering, we call the master 
  +the NiFi Cluster Manager (NCM), and the slaves are called Nodes. See a full description of each in the Terminology section below.
   
   *Why Cluster?* +
   
  
positive.code: The ADMIN user should be listed. Click on the pencil icon to see this user's role(s). You may edit the
  roles by selecting the appropriate checkboxes.
  
  When other users want access to the NiFi UI, they navigate to the configured URL and are
  prompted to request access. When someone has requested access, the ADMIN user sees a star
  on the Users icon in the Management Toolbar, alerting the ADMIN to the fact that a request is
  pending. Upon opening the User Management Page, the pending request is visible, and the ADMIN
  
negative.code: Doing so can cause a surprising bump in throughput.  Edit the '/etc/fstab' file
  and for the partition(s) of interest add the 'noatime' option.
  
  
  Security Configuration
  ----------------------
  
  NiFi provides several different configuration options for security purposes. The most important properties are those under the
  "security properties" heading in the _nifi.properties_ file. In order to run securely, the following properties must be set:
  
  [options="header,footer"]
  |==================================================================================================================================================
  | Property Name | Description
  |`nifi.security.keystore` | Filename of the Keystore that contains the server's private key.
  |`nifi.security.keystoreType` | The type of Keystore. Must be either `PKCS12` or `JKS`.
  |`nifi.security.keystorePasswd` | The password for the Keystore.
  |`nifi.security.keyPasswd` | The password for the certificate in the Keystore. If not set, the value of `nifi.security.keystorePasswd` will be used.
  |`nifi.security.truststore` | Filename of the Truststore that will be used to authorize those connecting to NiFi. If not set, all who 
                              attempt to connect will be provided access as the 'Anonymous' user.
  |`nifi.security.truststoreType` | The type of the Truststore. Must be either `PKCS12` or `JKS`.
  |`nifi.security.truststorePasswd` | The password for the Truststore.
  |`nifi.security.needClientAuth` | Specifies whether or not connecting clients must authenticate themselves. If the Truststore properties are not set, 
                                  this must be `false`. Otherwise, a value of `true` indicates that users will be authenticated and must have 
                                  certificates that are trusted by the Truststore loaded into their web browsers. A value of `false` indicates
                                  that all users should be given access as the 'Anonymous' user.  
  |==================================================================================================================================================
  
  Once the above properties have been configured, we can enable the User Interface to be accessed over HTTPS instead of HTTP. This is accomplished
  by setting the `nifi.web.https.host` and `nifi.web.https.port` properties. The `nifi.web.https.host` property indicates which hostname the server
  should run on. This allows admins to configure the application to run only on specific network interfaces. If it is desired that the HTTPS interface
  be accessible from all network interfaces, a value of `0.0.0.0` should be used.
  
  It is important when enabling HTTPS that the `nifi.web.http.port` property be unset. If both properties are configured, users will be able to
  connect over either HTTPS or HTTP. This can be useful in order to connect over HTTP when accessing the system over a local network and require
  HTTPS for all other network interfaces. However, it is usually desirable to secure all network interfaces, so this property is most often unset.
  
  Now that the User Interface has been secured, we can easily secure Site-to-Site connections and inner-cluster communications, as well. This is
  accomplished by setting the `nifi.remote.input.secure` and `nifi.cluster.protocol.is.secure` properties, respectively, to `true`.
  
  
  Controlling Levels of Access
  ----------------------------
  
  Once NiFi is configured to run securely as discussed in the previous section, it is necessary
  to configure who will have access to the system and what types of access those people will have.
  NiFi controls this through the user of an 'Authority Provider.' The Authority Provider is a pluggable
  mechanism for providing authorizations to different users. Which Authority Provider to use is configured
  using two properties in the _nifi.properties_ file. 
  
  The `nifi.authority.provider.configuration.file` property specifies the configuration file for Authority Providers. 
  The `nifi.security.user.authority.provider` property indicates which of the configured Authority Providers should be
  used.
  
  By default, the `file-provider` Authority Provider is selected and is configured to use the permissions granted in 
  the _authorized-users.xml_ file. This is typically sufficient for instances of NiFi that are run in "standalone" mode.
  If the NiFi instance is configured to run in a cluster, the node will typically use the `cluster-node-provider`
  Provider and the Cluster Manager will typically use the `cluster-ncm-provider` Provider. Both of these Providers
  have a default configuration in the _authority-providers.xml_ file but are commented out.
  
  When using the `cluster-node-provider` Provider, all of the authorization is provided by the Cluster Manager. In this
  way, the configuration only has to be maintained in one place and will be consistent across the entire cluster.
   
  When configuring the Cluster Manager or a standalone node, it is necessary to manually designate an ADMIN user 
  in the _authorized-users.xml_ file, which is located in the root installation's conf directory.
  After this ADMIN user has been added, s/he may grant access
  to other users, systems, and other instances of NiFi, through the User Interface (UI) without having to manually edit the _authorized-users.xml_
  file. If you are the administrator, you would add yourself as the ADMIN user in this file.
  
  Open the _authorized-users.xml_ file in a text editor. You will notice that it includes a template
  to guide you, with example entries that are commented out.
  
  It is only necessary to manually add one user, the ADMIN user, to this file.
  So, at a minimum, the following example entry should be included and contain the user Distinguished Name (DN)
  in place of "user dn - read only and admin":
  
  ----
  