You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nifi.apache.org by ze...@apache.org on 2018/08/13 09:34:11 UTC
[1/2] nifi git commit: NIFI-5469 Additional italics and code
formatting corrections for consistency
Repository: nifi
Updated Branches:
refs/heads/master 17ea29244 -> 86beca0c5
http://git-wip-us.apache.org/repos/asf/nifi/blob/86beca0c/nifi-docs/src/main/asciidoc/administration-guide.adoc
----------------------------------------------------------------------
diff --git a/nifi-docs/src/main/asciidoc/administration-guide.adoc b/nifi-docs/src/main/asciidoc/administration-guide.adoc
index 769b7bc..f62b68c 100644
--- a/nifi-docs/src/main/asciidoc/administration-guide.adoc
+++ b/nifi-docs/src/main/asciidoc/administration-guide.adoc
@@ -40,66 +40,66 @@ Apache NiFi can run on something as simple as a laptop, but it can also be clust
* Linux/Unix/OS X
** Decompress and untar into desired installation directory
-** Make any desired edits in files found under <installdir>/conf
-*** At a minimum, we recommend editing the _nifi.properties_ file and entering a password for the nifi.sensitive.props.key (see <<system_properties>> below)
-** From the <installdir>/bin directory, execute the following commands by typing ./nifi.sh <command>:
+** Make any desired edits in files found under `<installdir>/conf`
+*** At a minimum, we recommend editing the _nifi.properties_ file and entering a password for the `nifi.sensitive.props.key` (see <<system_properties>> below)
+** From the `<installdir>/bin` directory, execute the following commands by typing `./nifi.sh <command>`:
*** start: starts NiFi in the background
*** stop: stops NiFi that is running in the background
*** status: provides the current status of NiFi
*** run: runs NiFi in the foreground and waits for a Ctrl-C to initiate shutdown of NiFi
*** install: installs NiFi as a service that can then be controlled via
-**** service nifi start
-**** service nifi stop
-**** service nifi status
+**** `service nifi start`
+**** `service nifi stop`
+**** `service nifi status`
* Windows
** Decompress into the desired installation directory
-** Make any desired edits in the files found under <installdir>/conf
-*** At a minimum, we recommend editing the _nifi.properties_ file and entering a password for the nifi.sensitive.props.key (see <<system_properties>> below)
-** Navigate to the <installdir>/bin directory
-** Double-click run-nifi.bat. This runs NiFi in the foreground and waits for a Ctrl-C to initiate shutdown of NiFi
-** To see the current status of NiFi, double-click status-nifi.bat
+** Make any desired edits in the files found under `<installdir>/conf`
+*** At a minimum, we recommend editing the _nifi.properties_ file and entering a password for the `nifi.sensitive.props.key` (see <<system_properties>> below)
+** Navigate to the `<installdir>/bin` directory
+** Double-click `run-nifi.bat`. This runs NiFi in the foreground and waits for a Ctrl-C to initiate shutdown of NiFi
+** To see the current status of NiFi, double-click `status-nifi.bat`
When NiFi first starts up, the following files and directories are created:
-* content_repository
-* database_repository
-* flowfile_repository
-* provenance_repository
-* work directory
-* logs directory
-* Within the conf directory, the _flow.xml.gz_ file and the templates directory are created
+* `content_repository`
+* `database_repository`
+* `flowfile_repository`
+* `provenance_repository`
+* `work` directory
+* `logs` directory
+* Within the `conf` directory, the _flow.xml.gz_ file is created
See the <<system_properties>> section of this guide for more information about configuring NiFi repositories and configuration files.
== Configuration Best Practices
-NOTE: If you are running on Linux, consider these best practices. Typical Linux defaults are not necessarily well tuned for the needs of an IO intensive application like NiFi. For all of these areas, your distribution's requirements may vary. Use these sections as advice, but
+NOTE: If you are running on Linux, consider these best practices. Typical Linux defaults are not necessarily well-tuned for the needs of an IO intensive application like NiFi. For all of these areas, your distribution's requirements may vary. Use these sections as advice, but
consult your distribution-specific documentation for how best to achieve these recommendations.
Maximum File Handles::
NiFi will at any one time potentially have a very large number of file handles open. Increase the limits by
-editing '/etc/security/limits.conf' to add
+editing _/etc/security/limits.conf_ to add
something like
----
* hard nofile 50000
* soft nofile 50000
----
Maximum Forked Processes::
-NiFi may be configured to generate a significant number of threads. To increase the allowable number edit '/etc/security/limits.conf'
+NiFi may be configured to generate a significant number of threads. To increase the allowable number, edit _/etc/security/limits.conf_
----
* hard nproc 10000
* soft nproc 10000
----
-And your distribution may require an edit to /etc/security/limits.d/90-nproc.conf by adding
+And your distribution may require an edit to _/etc/security/limits.d/90-nproc.conf_ by adding
----
* soft nproc 10000
----
Increase the number of TCP socket ports available::
This is particularly important if your flow will be setting up and tearing
-down a large number of sockets in small period of time.
+down a large number of sockets in a small period of time.
----
sudo sysctl -w net.ipv4.ip_local_port_range="10000 65000"
----
@@ -107,23 +107,23 @@ sudo sysctl -w net.ipv4.ip_local_port_range="10000 65000"
Set how long sockets stay in a TIMED_WAIT state when closed::
You don't want your sockets to sit and linger too long given that you want to be
able to quickly setup and teardown new sockets. It is a good idea to read more about
-it but to adjust do something like
+it and adjust to something like
----
sudo sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait="1"
----
Tell Linux you never want NiFi to swap::
Swapping is fantastic for some applications. It isn't good for something like
-NiFi that always wants to be running. To tell Linux you'd like swapping off you
-can edit '/etc/sysctl.conf' to add the following line
+NiFi that always wants to be running. To tell Linux you'd like swapping off, you
+can edit _/etc/sysctl.conf_ to add the following line
----
vm.swappiness = 0
----
-For the partitions handling the various NiFi repos turn off things like 'atime'.
-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.
-
+For the partitions handling the various NiFi repos, turn off things like `atime`.
+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]]
== Security Configuration
NiFi provides several different configuration options for security purposes. The most important properties are those under the
@@ -164,12 +164,12 @@ accomplished by setting the `nifi.remote.input.secure` and `nifi.cluster.protoco
In order to facilitate the secure setup of NiFi, you can use the `tls-toolkit` command line utility to automatically generate the required keystores, truststore, and relevant configuration files. This is especially useful for securing multiple NiFi nodes, which can be a tedious and error-prone process.
-Wildcard certificates (i.e. two nodes `node1.nifi.apache.org` and `node2.nifi.apache.org` being assigned the same certificate with a CN or SAN entry of +*.nifi.apache.org+) are *not officially supported* and *not recommended*. There are numerous disadvantages to using wildcard certificates, and a cluster working with wildcard certificates has occurred in previous versions out of lucky accidents, not intentional support. Wildcard SAN entries are acceptable *if* each cert maintains an additional unique SAN entry and CN entry.
+Wildcard certificates (i.e. two nodes `node1.nifi.apache.org` and `node2.nifi.apache.org` being assigned the same certificate with a CN or SAN entry of `+*.nifi.apache.org+`) are *not officially supported* and *not recommended*. There are numerous disadvantages to using wildcard certificates, and a cluster working with wildcard certificates has occurred in previous versions out of lucky accidents, not intentional support. Wildcard SAN entries are acceptable *if* each cert maintains an additional unique SAN entry and CN entry.
==== Potential issues with wildcard certificates
* In many places throughout the codebase, cluster communications use certificate identities many times to identify a node, and if the certificate simply presents a wildcard DN, that doesn’t resolve to a specific node
-* Admins may need to provide a custom node identity in `authorizers.xml` for `*.nifi.apache.org` because all proxy actions only resolve to the cert DN (see <<user_authentication>>)
+* Admins may need to provide a custom node identity in _authorizers.xml_ for `*.nifi.apache.org` because all proxy actions only resolve to the cert DN (see <<user_authentication>>)
* Admins have no traceability into which node performed an action because they all resolve to the same DN
* Admins running multiple instances on the same machine using different ports to identify them can accidentally put `node1` hostname with `node2` port, and the address will resolve fine because it’s using the same certificate, but the host header handler will block it because the `node1` hostname is (correctly) not listed as an acceptable host for `node2` instance
* If the wildcard certificate is compromised, all nodes are compromised
@@ -178,7 +178,7 @@ NOTE: JKS keystores and truststores are recommended for NiFi. This tool allows
The `tls-toolkit` command line tool has two primary modes of operation:
-1. Standalone -- generates the certificate authority, keystores, truststores, and nifi.properties files in one command.
+1. Standalone -- generates the certificate authority, keystores, truststores, and _nifi.properties_ files in one command.
2. Client/Server mode -- uses a Certificate Authority Server that accepts Certificate Signing Requests from clients, signs them, and sends the resulting certificates back. Both client and server validate the other’s identity through a shared secret.
==== Standalone
@@ -192,7 +192,7 @@ You can use the following command line options with the `tls-toolkit` in standal
* `-c`,`--certificateAuthorityHostname <arg>` Hostname of NiFi Certificate Authority (default: `localhost`)
* `-C`,`--clientCertDn <arg>` Generate client certificate suitable for use in browser with specified DN (Can be specified multiple times)
* `-d`,`--days <arg>` Number of days issued certificate should be valid for (default: `1095`)
-* `-f`,`--nifiPropertiesFile <arg>` Base `nifi.properties` file to update (Embedded file identical to the one in a default NiFi install will be used if not specified)
+* `-f`,`--nifiPropertiesFile <arg>` Base _nifi.properties_ file to update (Embedded file identical to the one in a default NiFi install will be used if not specified)
* `-g`,`--differentKeyAndKeystorePasswords` Use different generated password for the key and the keystore
* `-G`,`--globalPortSequence <arg>` Use sequential ports that are calculated for all hosts according to the provided hostname expressions (Can be specified multiple times, MUST BE SAME FROM RUN TO RUN)
* `-h`,`--help` Print help and exit
@@ -217,17 +217,17 @@ Hostname Patterns:
Examples:
-Create 4 sets of keystore, truststore, nifi.properties for localhost along with a client certificate with the given DN:
+Create 4 sets of keystore, truststore, _nifi.properties_ for localhost along with a client certificate with the given DN:
----
bin/tls-toolkit.sh standalone -n 'localhost(4)' -C 'CN=username,OU=NIFI'
----
-Create keystore, truststore, nifi.properties for 10 NiFi hostnames in each of 4 subdomains:
+Create keystore, truststore, _nifi.properties_ for 10 NiFi hostnames in each of 4 subdomains:
----
bin/tls-toolkit.sh standalone -n 'nifi[01-10].subdomain[1-4].domain'
----
-Create 2 sets of keystore, truststore, nifi.properties for 10 NiFi hostnames in each of 4 subdomains along with a client certificate with the given DN:
+Create 2 sets of keystore, truststore, _nifi.properties_ for 10 NiFi hostnames in each of 4 subdomains along with a client certificate with the given DN:
----
bin/tls-toolkit.sh standalone -n 'nifi[01-10].subdomain[1-4].domain(2)' -C 'CN=username,OU=NIFI'
----
@@ -612,9 +612,10 @@ NiFi supports user authentication via client certificates, via username/password
Username/password authentication is performed by a 'Login Identity Provider'. The Login Identity Provider is a pluggable mechanism for
authenticating users via their username/password. Which Login Identity Provider to use is configured in the _nifi.properties_ file.
-Currently NiFi offers username/password with Login Identity Providers options for LDAP and Kerberos.
+Currently NiFi offers username/password with Login Identity Providers options for <<ldap_login_identity_provider>> and <<kerberos_login_identity_provider>>.
+
+The `nifi.login.identity.provider.configuration.file` property specifies the configuration file for Login Identity Providers. By default, this property is set to `./conf/login-identity-providers.xml`.
-The `nifi.login.identity.provider.configuration.file` property specifies the configuration file for Login Identity Providers.
The `nifi.security.user.login.identity.provider` property indicates which of the configured Login Identity Provider should be
used. By default, this property is not configured meaning that username/password must be explicitly enabled.
@@ -627,7 +628,7 @@ token during authentication.
NOTE: NiFi can only be configured for username/password, OpenId Connect, or Apache Knox at a given time. It does not support running each of
these concurrently. NiFi will require client certificates for authenticating users over HTTPS if none of these are configured.
-A secured instance of NiFi cannot be accessed anonymously unless configured to use an LDAP or Kerberos Login Identity Provider, which in turn must be configured to explicitly allow anonymous access. Anonymous access is not currently possible by the default FileAuthorizer (see <<authorizer-configuration>>), but is a future effort (link:https://issues.apache.org/jira/browse/NIFI-2730[NIFI-2730^]).
+A secured instance of NiFi cannot be accessed anonymously unless configured to use an <<ldap_login_identity_provider>> or <<kerberos_login_identity_provider>> Login Identity Provider, which in turn must be configured to explicitly allow anonymous access. Anonymous access is not currently possible by the default FileAuthorizer (see <<authorizer-configuration>>), but is a future effort (link:https://issues.apache.org/jira/browse/NIFI-2730[NIFI-2730^]).
NOTE: NiFi does not perform user authentication over HTTP. Using HTTP, all users will be granted all roles.
@@ -636,6 +637,14 @@ NOTE: NiFi does not perform user authentication over HTTP. Using HTTP, all users
Below is an example and description of configuring a Login Identity Provider that integrates with a Directory Server to authenticate users.
+Set the following in _nifi.properties_ to enable LDAP username/password authentication:
+
+----
+nifi.security.user.login.identity.provider=ldap-provider
+----
+
+Modify _login-identity-providers.xml_ to enable the `ldap-provider`. Here is the sample provided in the file:
+
----
<provider>
<identifier>ldap-provider</identifier>
@@ -668,73 +677,75 @@ Below is an example and description of configuring a Login Identity Provider tha
</provider>
----
-With this configuration, username/password authentication can be enabled by referencing this provider in _nifi.properties_.
-
-----
-nifi.security.user.login.identity.provider=ldap-provider
-----
+The `ldap-provider` has the following properties:
[options="header,footer"]
|==================================================================================================================================================
| Property Name | Description
-|`Authentication Strategy` | How the connection to the LDAP server is authenticated. Possible values are ANONYMOUS, SIMPLE, LDAPS, or START_TLS.
+|`Authentication Strategy` | How the connection to the LDAP server is authenticated. Possible values are `ANONYMOUS`, `SIMPLE`, `LDAPS`, or `START_TLS`.
|`Manager DN` | The DN of the manager that is used to bind to the LDAP server to search for users.
|`Manager Password` | The password of the manager that is used to bind to the LDAP server to search for users.
|`TLS - Keystore` | Path to the Keystore that is used when connecting to LDAP using LDAPS or START_TLS.
|`TLS - Keystore Password` | Password for the Keystore that is used when connecting to LDAP using LDAPS or START_TLS.
-|`TLS - Keystore Type` | Type of the Keystore that is used when connecting to LDAP using LDAPS or START_TLS (i.e. JKS or PKCS12).
+|`TLS - Keystore Type` | Type of the Keystore that is used when connecting to LDAP using LDAPS or START_TLS (i.e. `JKS` or `PKCS12`).
|`TLS - Truststore` | Path to the Truststore that is used when connecting to LDAP using LDAPS or START_TLS.
|`TLS - Truststore Password` | Password for the Truststore that is used when connecting to LDAP using LDAPS or START_TLS.
-|`TLS - Truststore Type` | Type of the Truststore that is used when connecting to LDAP using LDAPS or START_TLS (i.e. JKS or PKCS12).
-|`TLS - Client Auth` | Client authentication policy when connecting to LDAP using LDAPS or START_TLS. Possible values are REQUIRED, WANT, NONE.
-|`TLS - Protocol` | Protocol to use when connecting to LDAP using LDAPS or START_TLS. (i.e. TLS, TLSv1.1, TLSv1.2, etc).
+|`TLS - Truststore Type` | Type of the Truststore that is used when connecting to LDAP using LDAPS or START_TLS (i.e. `JKS` or `PKCS12`).
+|`TLS - Client Auth` | Client authentication policy when connecting to LDAP using LDAPS or START_TLS. Possible values are `REQUIRED`, `WANT`, `NONE`.
+|`TLS - Protocol` | Protocol to use when connecting to LDAP using LDAPS or START_TLS. (i.e. `TLS`, `TLSv1.1`, `TLSv1.2`, etc).
|`TLS - Shutdown Gracefully` | Specifies whether the TLS should be shut down gracefully before the target context is closed. Defaults to false.
-|`Referral Strategy` | Strategy for handling referrals. Possible values are FOLLOW, IGNORE, THROW.
-|`Connect Timeout` | Duration of connect timeout. (i.e. 10 secs).
-|`Read Timeout` | Duration of read timeout. (i.e. 10 secs).
-|`Url` | Space-separated list of URLs of the LDAP servers (i.e. ldap://<hostname>:<port>).
-|`User Search Base` | Base DN for searching for users (i.e. CN=Users,DC=example,DC=com).
-|`User Search Filter` | Filter for searching for users against the 'User Search Base'. (i.e. sAMAccountName={0}). The user specified name is inserted into '{0}'.
-|`Identity Strategy` | Strategy to identify users. Possible values are USE_DN and USE_USERNAME. The default functionality if this property is missing is USE_DN in order to retain backward
-compatibility. USE_DN will use the full DN of the user entry if possible. USE_USERNAME will use the username the user logged in with.
+|`Referral Strategy` | Strategy for handling referrals. Possible values are `FOLLOW`, `IGNORE`, `THROW`.
+|`Connect Timeout` | Duration of connect timeout. (i.e. `10 secs`).
+|`Read Timeout` | Duration of read timeout. (i.e. `10 secs`).
+|`Url` | Space-separated list of URLs of the LDAP servers (i.e. `ldap://<hostname>:<port>`).
+|`User Search Base` | Base DN for searching for users (i.e. `CN=Users,DC=example,DC=com`).
+|`User Search Filter` | Filter for searching for users against the `User Search Base`. (i.e. `sAMAccountName={0}`). The user specified name is inserted into '{0}'.
+|`Identity Strategy` | Strategy to identify users. Possible values are `USE_DN` and `USE_USERNAME`. The default functionality if this property is missing is USE_DN in order to retain backward
+compatibility. `USE_DN` will use the full DN of the user entry if possible. `USE_USERNAME` will use the username the user logged in with.
|`Authentication Expiration` | The duration of how long the user authentication is valid for. If the user never logs out, they will be required to log back in following this duration.
|==================================================================================================================================================
+NOTE: For changes to _nifi.properties_ and _login-identity-providers.xml_ to take effect, NiFi needs to be restarted. If NiFi is clustered, configuration files must be the same on all nodes.
+
[[kerberos_login_identity_provider]]
=== Kerberos
Below is an example and description of configuring a Login Identity Provider that integrates with a Kerberos Key Distribution Center (KDC) to authenticate users.
+Set the following in _nifi.properties_ to enable Kerberos username/password authentication:
+
+----
+nifi.security.user.login.identity.provider=kerberos-provider
+----
+
+Modify _login-identity-providers.xml_ to enable the `kerberos-provider`. Here is the sample provided in the file:
+
----
<provider>
<identifier>kerberos-provider</identifier>
<class>org.apache.nifi.kerberos.KerberosProvider</class>
<property name="Default Realm">NIFI.APACHE.ORG</property>
- <property name="Kerberos Config File">/etc/krb5.conf</property>
<property name="Authentication Expiration">12 hours</property>
</provider>
----
-With this configuration, username/password authentication can be enabled by referencing this provider in _nifi.properties_.
-
-----
-nifi.security.user.login.identity.provider=kerberos-provider
-----
+The `kerberos-provider` has the following properties:
[options="header,footer"]
|==================================================================================================================================================
| Property Name | Description
-|`Default Realm` | Default realm to provide when user enters incomplete user principal (i.e. NIFI.APACHE.ORG).
-|`Kerberos Config File` | Absolute path to Kerberos client configuration file.
+|`Default Realm` | Default realm to provide when user enters incomplete user principal (i.e. `NIFI.APACHE.ORG`).
|`Authentication Expiration`| The duration of how long the user authentication is valid for. If the user never logs out, they will be required to log back in following this duration.
|==================================================================================================================================================
See also <<kerberos_service>> to allow single sign-on access via client Kerberos tickets.
+NOTE: For changes to _nifi.properties_ and _login-identity-providers.xml_ to take effect, NiFi needs to be restarted. If NiFi is clustered, configuration files must be the same on all nodes.
+
[[openid_connect]]
=== OpenId Connect
-To enable authentication via OpenId Connect the following properties must be configured in nifi.properties.
+To enable authentication via OpenId Connect the following properties must be configured in _nifi.properties_.
[options="header,footer"]
|==================================================================================================================================================
@@ -744,23 +755,23 @@ To enable authentication via OpenId Connect the following properties must be con
|`nifi.security.user.oidc.read.timeout` | Read timeout when communicating with the OpenId Connect Provider.
|`nifi.security.user.oidc.client.id` | The client id for NiFi after registration with the OpenId Connect Provider.
|`nifi.security.user.oidc.client.secret` | The client secret for NiFi after registration with the OpenId Connect Provider.
-|`nifi.security.user.oidc.preferred.jwsalgorithm` | The preferred algorithm for for validating identity tokens. If this value is blank, it will default to 'RS256' which is required to be supported
-by the OpenId Connect Provider according to the specification. If this value is 'HS256', 'HS384', or 'HS512', NiFi will attempt to validate HMAC protected tokens using the specified client secret.
-If this value is 'none', NiFi will attempt to validate unsecured/plain tokens. Other values for this algorithm will attempt to parse as an RSA or EC algorithm to be used in conjunction with the
+|`nifi.security.user.oidc.preferred.jwsalgorithm` | The preferred algorithm for for validating identity tokens. If this value is blank, it will default to `RS256` which is required to be supported
+by the OpenId Connect Provider according to the specification. If this value is `HS256`, `HS384`, or `HS512`, NiFi will attempt to validate HMAC protected tokens using the specified client secret.
+If this value is `none`, NiFi will attempt to validate unsecured/plain tokens. Other values for this algorithm will attempt to parse as an RSA or EC algorithm to be used in conjunction with the
JSON Web Key (JWK) provided through the jwks_uri in the metadata found at the discovery URL.
|==================================================================================================================================================
[[apache_knox]]
=== Apache Knox
-To enable authentication via Apache Knox the following properties must be configured in nifi.properties.
+To enable authentication via Apache Knox the following properties must be configured in _nifi.properties_.
[options="header,footer"]
|==================================================================================================================================================
| Property Name | Description
-|`nifi.security.user.knox.url` | The URL for the Apache Knox log in page.
+|`nifi.security.user.knox.url` | The URL for the Apache Knox login page.
|`nifi.security.user.knox.publicKey` | The path to the Apache Knox public key that will be used to verify the signatures of the authentication tokens in the HTTP Cookie.
-|`nifi.security.user.knox.cookieName` | The name of the HTTP Cookie that Apache Knox will generate after successful log in.
+|`nifi.security.user.knox.cookieName` | The name of the HTTP Cookie that Apache Knox will generate after successful login.
|`nifi.security.user.knox.audiences` | Optional. A comma separate listed of allowed audiences. If set, the audience in the token must be present in
this listing. The audience that is populated in the token can be configured in Knox.
|==================================================================================================================================================
@@ -778,99 +789,161 @@ user has privileges to perform that action. These privileges are defined by poli
An 'authorizer' grants users the privileges to manage users and policies by creating preliminary authorizations at startup.
-Authorizers are configured using two properties in the 'nifi.properties' file:
+Authorizers are configured using two properties in the _nifi.properties_ file:
-* The `nifi.authorizer.configuration.file` property specifies the configuration file where authorizers are defined. By default, the 'authorizers.xml' file located in the root installation conf directory is selected.
-* The `nifi.security.user.authorizer` property indicates which of the configured authorizers in the 'authorizers.xml' file to use.
+* The `nifi.authorizer.configuration.file` property specifies the configuration file where authorizers are defined. By default, the _authorizers.xml_ file located in the root installation conf directory is selected.
+* The `nifi.security.user.authorizer` property indicates which of the configured authorizers in the _authorizers.xml_ file to use.
[[authorizers-setup]]
=== Authorizers.xml Setup
-The 'authorizers.xml' file is used to define and configure available authorizers. The default authorizer is the StandardManagedAuthorizer. The managed authorizer is comprised of a UserGroupProvider
+The _authorizers.xml_ file is used to define and configure available authorizers. The default authorizer is the StandardManagedAuthorizer. The managed authorizer is comprised of a UserGroupProvider
and a AccessPolicyProvider. The users, group, and access policies will be loaded and optionally configured through these providers. The managed authorizer will make all access decisions based on
these provided users, groups, and access policies.
During startup there is a check to ensure that there are no two users/groups with the same identity/name. This check is executed regardless of the configured implementation. This is necessary because this is how users/groups are identified and authorized during access decisions.
+
+==== FileUserGroupProvider
+
The default UserGroupProvider is the FileUserGroupProvider, however, you can develop additional UserGroupProviders as extensions. The FileUserGroupProvider has the following properties:
-* Users File - The file where the FileUserGroupProvider stores users and groups. By default, the 'users.xml' in the 'conf' directory is chosen.
-* Legacy Authorized Users File - The full path to an existing authorized-users.xml that will be automatically be used to load the users and groups into the Users File.
+* Users File - The file where the FileUserGroupProvider stores users and groups. By default, the _users.xml_ in the `conf` directory is chosen.
+* Legacy Authorized Users File - The full path to an existing _authorized-users.xml_ that will be automatically be used to load the users and groups into the Users File.
* Initial User Identity - The identity of a users and systems to seed the Users File. The name of each property must be unique, for example: "Initial User Identity A", "Initial User Identity B", "Initial User Identity C" or "Initial User Identity 1", "Initial User Identity 2", "Initial User Identity 3"
-Another option for the UserGroupProvider is the LdapUserGroupProvider. By default, this option is commented out but can be configured in lieu of the FileUserGroupProvider. This will sync users and groups from a directory server and will present them in NiFi UI in read only form. The LdapUserGroupProvider has the following properties:
-
-* Authentication Strategy - How the connection to the LDAP server is authenticated. Possible values are ANONYMOUS, SIMPLE, LDAPS, or START_TLS
-* Manager DN - The DN of the manager that is used to bind to the LDAP server to search for users.
-* Manager Password - The password of the manager that is used to bind to the LDAP server to search for users.
-* TLS - Keystore - Path to the Keystore that is used when connecting to LDAP using LDAPS or START_TLS.
-* TLS - Keystore Password - Password for the Keystore that is used when connecting to LDAP using LDAPS or START_TLS.
-* TLS - Keystore Type - Type of the Keystore that is used when connecting to LDAP using LDAPS or START_TLS (i.e. JKS or PKCS12).
-* TLS - Truststore - Path to the Truststore that is used when connecting to LDAP using LDAPS or START_TLS.
-* TLS - Truststore Password - Password for the Truststore that is used when connecting to LDAP using LDAPS or START_TLS.
-* TLS - Truststore Type - Type of the Truststore that is used when connecting to LDAP using LDAPS or START_TLS (i.e. JKS or PKCS12).
-* TLS - Client Auth - Client authentication policy when connecting to LDAP using LDAPS or START_TLS. Possible values are REQUIRED, WANT, NONE.
-* TLS - Protocol - Protocol to use when connecting to LDAP using LDAPS or START_TLS. (i.e. TLS, TLSv1.1, TLSv1.2, etc).
-* TLS - Shutdown Gracefully - Specifies whether the TLS should be shut down gracefully before the target context is closed. Defaults to false.
-* Referral Strategy - Strategy for handling referrals. Possible values are FOLLOW, IGNORE, THROW.
-* Connect Timeout - Duration of connect timeout. (i.e. 10 secs).
-* Read Timeout - Duration of read timeout. (i.e. 10 secs).
-* Url - Space-separated list of URLs of the LDAP servers (i.e. ldap://<hostname>:<port>).
-* Page Size - Sets the page size when retrieving users and groups. If not specified, no paging is performed.
-* Sync Interval - Duration of time between syncing users and groups. (i.e. 30 mins). Minimum allowable value is 10 secs.
-* User Search Base - Base DN for searching for users (i.e. ou=users,o=nifi). Required to search users.
-* User Object Class - Object class for identifying users (i.e. person). Required if searching users.
-* User Search Scope - Search scope for searching users (ONE_LEVEL, OBJECT, or SUBTREE). Required if searching users.
-* User Search Filter - Filter for searching for users against the 'User Search Base' (i.e. (memberof=cn=team1,ou=groups,o=nifi) ). Optional.
-* User Identity Attribute - Attribute to use to extract user identity (i.e. cn). Optional. If not set, the entire DN is used.
-* User Group Name Attribute - Attribute to use to define group membership (i.e. memberof). Optional. If not set group membership will not be calculated through the users. Will rely on group membership being defined through 'Group Member Attribute' if set. The value of this property is the name of the attribute in the user ldap entry that associates them with a group. The value of that user attribute could be a dn or group name for instance. What value is expected is configured in the 'User Group Name Attribute - Referenced Group Attribute'.
-* User Group Name Attribute - Referenced Group Attribute - If blank, the value of the attribute defined in 'User Group Name Attribute' is expected to be the full dn of the group. If not blank, this property will define the attribute of the group ldap entry that the value of the attribute defined in 'User Group Name Attribute' is referencing (i.e. name). Use of this property requires that 'Group Search Base' is also configured.
-* Group Search Base - Base DN for searching for groups (i.e. ou=groups,o=nifi). Required to search groups.
-* Group Object Class - Object class for identifying groups (i.e. groupOfNames). Required if searching groups.
-* Group Search Scope - Search scope for searching groups (ONE_LEVEL, OBJECT, or SUBTREE). Required if searching groups.
-* Group Search Filter - Filter for searching for groups against the 'Group Search Base'. Optional.
-* Group Name Attribute - Attribute to use to extract group name (i.e. cn). Optional. If not set, the entire DN is used.
-* Group Member Attribute - Attribute to use to define group membership (i.e. member). Optional. If not set group membership will not be calculated through the groups. Will rely on group membership being defined through 'User Group Name Attribute' if set. The value of this property is the name of the attribute in the group ldap entry that associates them with a user. The value of that group attribute could be a dn or memberUid for instance. What value is expected is configured in the 'Group Member Attribute - Referenced User Attribute'. (i.e. member: cn=User 1,ou=users,o=nifi vs. memberUid: user1)
-* Group Member Attribute - Referenced User Attribute - If blank, the value of the attribute defined in 'Group Member Attribute' is expected to be the full dn of the user. If not blank, this property will define the attribute of the user ldap entry that the value of the attribute defined in 'Group Member Attribute' is referencing (i.e. uid). Use of this property requires that 'User Search Base' is also configured. (i.e. member: cn=User 1,ou=users,o=nifi vs. memberUid: user1)
+==== LdapUserGroupProvider
+
+Another option for the UserGroupProvider is the LdapUserGroupProvider. By default, this option is commented out but can be configured in lieu of the FileUserGroupProvider. This will sync users and groups from a directory server and will present them in the NiFi UI in read only form.
+
+The LdapUserGroupProvider has the following properties:
+
+[options="header,footer"]
+|==================================================================================================================================================
+| Property Name | Description
+|`Authentication Strategy` | How the connection to the LDAP server is authenticated. Possible values are `ANONYMOUS`, `SIMPLE`, `LDAPS`, or `START_TLS`.
+|`Manager DN` | The DN of the manager that is used to bind to the LDAP server to search for users.
+|`Manager Password` | The password of the manager that is used to bind to the LDAP server to search for users.
+|`TLS - Keystore` | Path to the Keystore that is used when connecting to LDAP using LDAPS or START_TLS.
+|`TLS - Keystore Password` | Password for the Keystore that is used when connecting to LDAP using LDAPS or START_TLS.
+|`TLS - Keystore Type` | Type of the Keystore that is used when connecting to LDAP using LDAPS or START_TLS (i.e. `JKS` or `PKCS12`).
+|`TLS - Truststore` | Path to the Truststore that is used when connecting to LDAP using LDAPS or START_TLS.
+|`TLS - Truststore Password` | Password for the Truststore that is used when connecting to LDAP using LDAPS or START_TLS.
+|`TLS - Truststore Type` | Type of the Truststore that is used when connecting to LDAP using LDAPS or START_TLS (i.e. `JKS` or `PKCS12`).
+|`TLS - Client Auth` | Client authentication policy when connecting to LDAP using LDAPS or START_TLS. Possible values are `REQUIRED`, `WANT`, `NONE`.
+|`TLS - Protocol` | Protocol to use when connecting to LDAP using LDAPS or START_TLS. (i.e. `TLS`, `TLSv1.1`, `TLSv1.2`, etc).
+|`TLS - Shutdown Gracefully` | Specifies whether the TLS should be shut down gracefully before the target context is closed. Defaults to false.
+|`Referral Strategy` | Strategy for handling referrals. Possible values are `FOLLOW`, `IGNORE`, `THROW`.
+|`Connect Timeout` | Duration of connect timeout. (i.e. `10 secs`).
+|`Read Timeout` | Duration of read timeout. (i.e. `10 secs`).
+|`Url` | Space-separated list of URLs of the LDAP servers (i.e. `ldap://<hostname>:<port>`).
+|`Page Size` | Sets the page size when retrieving users and groups. If not specified, no paging is performed.
+|`Sync Interval` | Duration of time between syncing users and groups. (i.e. `30 mins`). Minimum allowable value is `10 secs`.
+|`User Search Base` | Base DN for searching for users (i.e. `ou=users,o=nifi`). Required to search users.
+|`User Object Class` | Object class for identifying users (i.e. `person`). Required if searching users.
+|`User Search Scope` | Search scope for searching users (`ONE_LEVEL`, `OBJECT`, or `SUBTREE`). Required if searching users.
+|`User Search Filter` | Filter for searching for users against the `User Search Base` (i.e. `(memberof=cn=team1,ou=groups,o=nifi)`). Optional.
+|`User Identity Attribute` | Attribute to use to extract user identity (i.e. `cn`). Optional. If not set, the entire DN is used.
+|`User Group Name Attribute` | Attribute to use to define group membership (i.e. `memberof`). Optional. If not set group membership will not be calculated through the users. Will rely on group membership being defined through `Group Member Attribute` if set. The value of this property is the name of the attribute in the user ldap entry that associates them with a group. The value of that user attribute could be a dn or group name for instance. What value is expected is configured in the `User Group Name Attribute - Referenced Group Attribute`.
+|`User Group Name Attribute - Referenced Group Attribute` | If blank, the value of the attribute defined in `User Group Name Attribute` is expected to be the full dn of the group. If not blank, this property will define the attribute of the group ldap entry that the value of the attribute defined in `User Group Name Attribute` is referencing (i.e. `name`). Use of this property requires that `Group Search Base` is also configured.
+|`Group Search Base` | Base DN for searching for groups (i.e. `ou=groups,o=nifi`). Required to search groups.
+|`Group Object Class` | Object class for identifying groups (i.e. `groupOfNames`). Required if searching groups.
+|`Group Search Scope` | Search scope for searching groups (`ONE_LEVEL`, `OBJECT`, or `SUBTREE`). Required if searching groups.
+|`Group Search Filter` | Filter for searching for groups against the `Group Search Base`. Optional.
+|`Group Name Attribute` | Attribute to use to extract group name (i.e. `cn`). Optional. If not set, the entire DN is used.
+|`Group Member Attribute` | Attribute to use to define group membership (i.e. `member`). Optional. If not set group membership will not be calculated through the groups. Will rely on group membership being defined through `User Group Name Attribute` if set. The value of this property is the name of the attribute in the group ldap entry that associates them with a user. The value of that group attribute could be a dn or memberUid for instance. What value is expected is configured in the `Group Member Attribute - Referenced User Attribute`. (i.e. `member: cn=User 1,ou=users,o=nifi` vs. `memberUid: user1`)
+|`Group Member Attribute - Referenced User Attribute` | If blank, the value of the attribute defined in `Group Member Attribute` is expected to be the full dn of the user. If not blank, this property will define the attribute of the user ldap entry that the value of the attribute defined in `Group Member Attribute` is referencing (i.e. `uid`). Use of this property requires that `User Search Base` is also configured. (i.e. `member: cn=User 1,ou=users,o=nifi` vs. `memberUid: user1`)
+|==================================================================================================================================================
+
+NOTE: Any identity mapping rules specified in _nifi.properties_ will also be applied to the user identities. Group names are not mapped.
+
+==== Composite Implementations
Another option for the UserGroupProvider are composite implementations. This means that multiple sources/implementations can be configured and composed. For instance, an admin can configure users/groups to be loaded from a file and a directory server. There are two composite implementations, one that supports multiple UserGroupProviders and one that supports multiple UserGroupProviders and a single configurable UserGroupProvider.
-The CompositeUserGroupProvider will provide support for retrieving users and groups from multiple sources. The CompositeUserGroupProvider has the following properties:
+The CompositeUserGroupProvider will provide support for retrieving users and groups from multiple sources. The CompositeUserGroupProvider has the following property:
-* User Group Provider - The identifier of user group providers to load from. The name of each property must be unique, for example: "User Group Provider A", "User Group Provider B", "User Group Provider C" or "User Group Provider 1", "User Group Provider 2", "User Group Provider 3"
+[options="header,footer"]
+|==================================================================================================================================================
+| Property Name | Description
+|`User Group Provider [unique key]` | The identifier of user group providers to load from. The name of each property must be unique, for example: "User Group Provider A", "User Group Provider B", "User Group Provider C" or "User Group Provider 1", "User Group Provider 2", "User Group Provider 3"
+|==================================================================================================================================================
+
+NOTE: Any identity mapping rules specified in _nifi.properties_ are not applied in this implementation. This behavior would need to be applied by the base implementation.
The CompositeConfigurableUserGroupProvider will provide support for retrieving users and groups from multiple sources. Additionally, a single configurable user group provider is required. Users from the configurable user group provider are configurable, however users loaded from one of the User Group Provider [unique key] will not be. The CompositeConfigurableUserGroupProvider has the following properties:
-* Configurable User Group Provider - A configurable user group provider.
-* User Group Provider - The identifier of user group providers to load from. The name of each property must be unique, for example: "User Group Provider A", "User Group Provider B", "User Group Provider C" or "User Group Provider 1", "User Group Provider 2", "User Group Provider 3"
+[options="header,footer"]
+|==================================================================================================================================================
+| Property Name | Description
+|`Configurable User Group Provider` | A configurable user group provider.
+|`User Group Provider [unique key]` | The identifier of user group providers to load from. The name of each property must be unique, for example: "User Group Provider A", "User Group Provider B", "User Group Provider C" or "User Group Provider 1", "User Group Provider 2", "User Group Provider 3"
+|==================================================================================================================================================
+
+==== FileAccessPolicyProvider
The default AccessPolicyProvider is the FileAccessPolicyProvider, however, you can develop additional AccessPolicyProvider as extensions. The FileAccessPolicyProvider has the following properties:
-* User Group Provider - The identifier for an User Group Provider defined above that will be used to access users and groups for use in the managed access policies.
-* Authorizations File - The file where the FileAccessPolicyProvider will store policies.
-* Initial Admin Identity - The identity of an initial admin user that will be granted access to the UI and given the ability to create additional users, groups, and policies. The value of this property could be a DN when using certificates or LDAP, or a Kerberos principal. This property will only be used when there are no other policies defined. If this property is specified then a Legacy Authorized Users File can not be specified.
-* Legacy Authorized Users File - The full path to an existing authorized-users.xml that will be automatically converted to the new authorizations model. If this property is specified then an Initial Admin Identity can not be specified, and this property will only be used when there are no other users, groups, and policies defined.
-* Node Identity - The identity of a NiFi cluster node. When clustered, a property for each node should be defined, so that every node knows about every other node. If not clustered these properties can be ignored. The name of each property must be unique, for example for a three node cluster: "Node Identity A", "Node Identity B", "Node Identity C" or "Node Identity 1", "Node Identity 2", "Node Identity 3"
+[options="header,footer"]
+|==================================================================================================================================================
+| Property Name | Description
+|`User Group Provider` | The identifier for an User Group Provider defined above that will be used to access users and groups for use in the managed access policies.
+|`Authorizations File` | The file where the FileAccessPolicyProvider will store policies.
+|`Initial Admin Identity` | The identity of an initial admin user that will be granted access to the UI and given the ability to create additional users, groups, and policies. The value of this property could be a DN when using certificates or LDAP, or a Kerberos principal. This property will only be used when there are no other policies defined. If this property is specified then a Legacy Authorized Users File can not be specified.
+|`Legacy Authorized Users File` | The full path to an existing _authorized-users.xml_ that will be automatically converted to the new authorizations model. If this property is specified then an Initial Admin Identity can not be specified, and this property will only be used when there are no other users, groups, and policies defined.
+|`Node Identity` | The identity of a NiFi cluster node. When clustered, a property for each node should be defined, so that every node knows about every other node. If not clustered these properties can be ignored. The name of each property must be unique, for example for a three node cluster: "Node Identity A", "Node Identity B", "Node Identity C" or "Node Identity 1", "Node Identity 2", "Node Identity 3"
-The identities configured in the Initial Admin Identity, the Node Identity properties, or discovered in a Legacy Authorized Users File must be available in the configured User Group Provider.
+|==================================================================================================================================================
-The default authorizer is the StandardManagedAuthorizer, however, you can develop additional authorizers as extensions. The StandardManagedAuthorizer has the following properties:
+NOTE: The identities configured in the Initial Admin Identity, the Node Identity properties, or discovered in a Legacy Authorized Users File must be available in the configured User Group Provider.
-* Access Policy Provider - The identifier for an Access Policy Provider defined above.
+NOTE: Any users in the legacy users file must be found in the configured User Group Provider.
-The FileAuthorizer has been replaced with the more granular StandardManagedAuthorizer approach described above. However, it is still available for backwards compatibility reasons. The
-FileAuthorizer has the following properties.
+NOTE: Any identity mapping rules specified in _nifi.properties_ will also be applied to the node identities,
+ so the values should be the unmapped identities (i.e. full DN from a certificate). This identity must be found
+ in the configured User Group Provider.
-* Authorizations File - The file where the FileAuthorizer stores policies. By default, the 'authorizations.xml' in the 'conf' directory is chosen.
-* Users File - The file where the FileAuthorizer stores users and groups. By default, the 'users.xml' in the 'conf' directory is chosen.
-* Initial Admin Identity - The identity of an initial admin user that is granted access to the UI and given the ability to create additional users, groups, and policies. This property is only used when there are no other users, groups, and policies defined.
-* Legacy Authorized Users File - The full path to an existing authorized-users.xml that is automatically converted to the multi-tenant authorization model. This property is only used when there are no other users, groups, and policies defined.
-* Node Identity - The identity of a NiFi cluster node. When clustered, a property for each node should be defined, so that every node knows about every other node. If not clustered, these properties can be ignored.
+==== StandardManagedAuthorizer
+
+The default authorizer is the StandardManagedAuthorizer, however, you can develop additional authorizers as extensions. The StandardManagedAuthorizer has the following property:
+
+[options="header,footer"]
+|==================================================================================================================================================
+| Property Name | Description
+|`Access Policy Provider` | The identifier for an Access Policy Provider defined above.
+|==================================================================================================================================================
+
+
+==== FileAuthorizer
+
+The FileAuthorizer has been replaced with the more granular StandardManagedAuthorizer approach described above. However, it is still available for backwards compatibility reasons. The FileAuthorizer has the following properties:
+
+[options="header,footer"]
+|==================================================================================================================================================
+| Property Name | Description
+|`Authorizations File` | The file where the FileAuthorizer stores policies. By default, the _authorizations.xml_ in the `conf` directory is chosen.
+|`Users File` | The file where the FileAuthorizer stores users and groups. By default, the _users.xml_ in the `conf` directory is chosen.
+|`Initial Admin Identity` | The identity of an initial admin user that is granted access to the UI and given the ability to create additional users, groups, and policies. This property is only used when there are no other users, groups, and policies defined.
+|`Legacy Authorized Users File` | The full path to an existing _authorized-users.xml_ that is automatically converted to the multi-tenant authorization model. This property is only used when there are no other users, groups, and policies defined.
+|`Node Identity` | The identity of a NiFi cluster node. When clustered, a property for each node should be defined, so that every node knows about every other node. If not clustered, these properties can be ignored.
+|==================================================================================================================================================
+
+NOTE: Any identity mapping rules specified in _nifi.properties_ will also be applied to the initial admin identity, so the value should be the unmapped identity.
+
+NOTE: Any identity mapping rules specified in _nifi.properties_ will also be applied to the node identities, so the values should be the unmapped identities (i.e. full DN from a certificate).
[[initial-admin-identity]]
==== Initial Admin Identity (New NiFi Instance)
-If you are setting up a secured NiFi instance for the first time, you must manually designate an “Initial Admin Identity” in the 'authorizers.xml' file. This initial admin user is granted access to the UI and given the ability to create additional users, groups, and policies. The value of this property could be a DN (when using certificates or LDAP) or a Kerberos principal. If you are the NiFi administrator, add yourself as the “Initial Admin Identity”.
+If you are setting up a secured NiFi instance for the first time, you must manually designate an “Initial Admin Identity” in the _authorizers.xml_ file. This initial admin user is granted access to the UI and given the ability to create additional users, groups, and policies. The value of this property could be a DN (when using certificates or LDAP) or a Kerberos principal. If you are the NiFi administrator, add yourself as the “Initial Admin Identity”.
+
+After you have edited and saved the _authorizers.xml_ file, restart NiFi. The “Initial Admin Identity” user and administrative policies are added to the _users.xml_ and _authorizations.xml_ files during restart. Once NiFi starts, the “Initial Admin Identity” user is able to access the UI and begin managing users, groups, and policies.
+
+NOTE: For a brand new secure flow, providing the "Initial Admin Identity" gives that user access to get into the UI and to manage users, groups and policies. But if that user wants to start modifying the flow, they need to grant themselves policies for the root process group. The system is unable to do this automatically because in a new flow the UUID of the root process group is not permanent until the _flow.xml.gz_ is generated. If the NiFi instance is an upgrade from an existing _flow.xml.gz_ or a 1.x instance going from unsecure to secure, then the "Initial Admin Identity" user is automatically given the privileges to modify the flow.
+
+Some common use cases are described below.
+
+===== File-based (LDAP Authentication)
Here is an example LDAP entry using the name John Smith:
@@ -902,6 +975,8 @@ Here is an example LDAP entry using the name John Smith:
</authorizers>
----
+===== File-based (Kerberos Authentication)
+
Here is an example Kerberos entry using the name John Smith and realm `NIFI.APACHE.ORG`:
----
@@ -932,11 +1007,9 @@ Here is an example Kerberos entry using the name John Smith and realm `NIFI.APAC
</authorizers>
----
-After you have edited and saved the 'authorizers.xml' file, restart NiFi. The “Initial Admin Identity” user and administrative policies are added to the 'users.xml' and 'authorizations.xml' files during restart. Once NiFi starts, the “Initial Admin Identity” user is able to access the UI and begin managing users, groups, and policies.
+===== LDAP-based Users/Groups Referencing User DN
-NOTE: For a brand new secure flow, providing the "Initial Admin Identity" gives that user access to get into the UI and to manage users, groups and policies. But if that user wants to start modifying the flow, they need to grant themselves policies for the root process group. The system is unable to do this automatically because in a new flow the UUID of the root process group is not permanent until the flow.xml.gz is generated. If the NiFi instance is an upgrade from an existing flow.xml.gz or a 1.x instance going from unsecure to secure, then the "Initial Admin Identity" user is automatically given the privileges to modify the flow.
-
-Here is an example loading users and groups from LDAP. Group membership will be driven through the member attribute of each group. Authorization will still use file based access policies:
+Here is an example loading users and groups from LDAP. Group membership will be driven through the member attribute of each group. Authorization will still use file-based access policies:
----
dn: cn=User 1,ou=users,o=nifi
@@ -1025,9 +1098,11 @@ member: cn=User 2,ou=users,o=nifi
</authorizers>
----
-The 'Initial Admin Identity' value would have loaded from the cn from John Smith's entry based on the 'User Identity Attribute' value.
+The `Initial Admin Identity` value would have loaded from the cn from John Smith's entry based on the `User Identity Attribute` value.
+
+===== LDAP-based Users/Groups Referencing User Attribute
-Here is an example loading users and groups from LDAP. Group membership will be driven through the member attribute of each group. Authorization will still use file based access policies:
+Here is an example loading users and groups from LDAP. Group membership will be driven through the member uid attribute of each group. Authorization will still use file-based access policies:
----
dn: uid=User 1,ou=Users,dc=local
@@ -1077,7 +1152,7 @@ memberUid: user2
<property name="Page Size"></property>
<property name="Sync Interval">30 mins</property>
- <property name="User Search Base">ou=Groups,dc=local</property>
+ <property name="User Search Base">ou=Users,dc=local</property>
<property name="User Object Class">posixAccount</property>
<property name="User Search Scope">ONE_LEVEL</property>
<property name="User Search Filter"></property>
@@ -1111,9 +1186,36 @@ memberUid: user2
</authorizers>
----
+===== Composite - File and LDAP-based Users/Groups
+
Here is an example composite implementation loading users and groups from LDAP and a local file. Group membership will be driven through the member attribute of each group. The users from LDAP will be read only while the users loaded from the file will be configurable in UI.
----
+dn: cn=User 1,ou=users,o=nifi
+objectClass: organizationalPerson
+objectClass: person
+objectClass: inetOrgPerson
+objectClass: top
+cn: User 1
+sn: User1
+uid: user1
+
+dn: cn=User 2,ou=users,o=nifi
+objectClass: organizationalPerson
+objectClass: person
+objectClass: inetOrgPerson
+objectClass: top
+cn: User 2
+sn: User2
+uid: user2
+
+dn: cn=admins,ou=groups,o=nifi
+objectClass: groupOfNames
+objectClass: top
+cn: admins
+member: cn=User 1,ou=users,o=nifi
+member: cn=User 2,ou=users,o=nifi
+
<authorizers>
<userGroupProvider>
<identifier>file-user-group-provider</identifier>
@@ -1191,12 +1293,12 @@ Here is an example composite implementation loading users and groups from LDAP a
</authorizers>
----
-In this example, the users and groups are loaded from LDAP but the servers are managed in a local file. The 'Initial Admin Identity' value came from an attribute in a LDAP entry based on the 'User Identity Attribute'. The 'Node Identity' values are established in the local file using the 'Initial User Identity' properties.
+In this example, the users and groups are loaded from LDAP but the servers are managed in a local file. The `Initial Admin Identity` value came from an attribute in a LDAP entry based on the `User Identity Attribute`. The `Node Identity` values are established in the local file using the `Initial User Identity` properties.
[[legacy-authorized-users]]
==== Legacy Authorized Users (NiFi Instance Upgrade)
-If you are upgrading from a 0.x NiFi instance, you can convert your previously configured users and roles to the multi-tenant authorization model. In the 'authorizers.xml' file, specify the location of your existing 'authorized-users.xml' file in the “Legacy Authorized Users File” property.
+If you are upgrading from a 0.x NiFi instance, you can convert your previously configured users and roles to the multi-tenant authorization model. In the _authorizers.xml_ file, specify the location of your existing _authorized-users.xml_ file in the `Legacy Authorized Users File` property.
Here is an example entry:
@@ -1228,9 +1330,9 @@ Here is an example entry:
</authorizers>
----
-After you have edited and saved the 'authorizers.xml' file, restart NiFi. Users and roles from the 'authorized-users.xml' file are converted and added as identities and policies in the 'users.xml' and 'authorizations.xml' files. Once the application starts, users who previously had a legacy Administrator role can access the UI and begin managing users, groups, and policies.
+After you have edited and saved the _authorizers.xml_ file, restart NiFi. Users and roles from the _authorized-users.xml_ file are converted and added as identities and policies in the _users.xml_ and _authorizations.xml_ files. Once the application starts, users who previously had a legacy Administrator role can access the UI and begin managing users, groups, and policies.
-The following tables summarize the global and component policies assigned to each legacy role if the NiFi instance has an existing 'flow.xml.gz':
+The following tables summarize the global and component policies assigned to each legacy role if the NiFi instance has an existing _flow.xml.gz_:
===== Global Access Policies
[cols=">s,^s,^s,^s,^s,^s,^s", options="header"]
@@ -1265,9 +1367,9 @@ The following tables summarize the global and component policies assigned to eac
For details on the individual policies in the table, see <<access-policies>>.
-NOTE: NiFi fails to restart if values exist for both the “Initial Admin Identity” and “Legacy Authorized Users File” properties. You can specify only one of these values to initialize authorizations.
+NOTE: NiFi fails to restart if values exist for both the `Initial Admin Identity` and `Legacy Authorized Users File` properties. You can specify only one of these values to initialize authorizations.
-NOTE: Do not manually edit the 'authorizations.xml' file. Create authorizations only during initial setup and afterwards using the NiFi UI.
+NOTE: Do not manually edit the _authorizations.xml_ file. Create authorizations only during initial setup and afterwards using the NiFi UI.
[[cluster-node-identities]]
==== Cluster Node Identities
@@ -1312,7 +1414,7 @@ cn=nifi-2,ou=people,dc=example,dc=com
</authorizers>
----
-NOTE: In a cluster, all nodes must have the same 'authorizations.xml' and 'users.xml'. The only exception is if a node has empty 'authorizations.xml' and 'user.xml' files prior to joining the cluster. In this scenario, the node inherits them from the cluster during startup.
+NOTE: In a cluster, all nodes must have the same _authorizations.xml_ and _users.xml_. The only exception is if a node has empty _authorizations.xml_ and _user.xml_ files prior to joining the cluster. In this scenario, the node inherits them from the cluster during startup.
Now that initial authorizations have been created, additional users, groups and authorizations can be created and managed in the NiFi UI.
@@ -1620,7 +1722,7 @@ image:user2-edit-connection.png["User2 Edit Connection"]
This section provides an overview of the capabilities of NiFi to encrypt and decrypt data.
-The `EncryptContent` processor allows for the encryption and decryption of data, both internal to NiFi and integrated with external systems, such as `openssl` and other data sources and consumers.
+The EncryptContent processor allows for the encryption and decryption of data, both internal to NiFi and integrated with external systems, such as `openssl` and other data sources and consumers.
[[key-derivation-functions]]
=== Key Derivation Functions
@@ -1673,7 +1775,7 @@ Here are the KDFs currently supported by NiFi (primarily in the `EncryptContent`
* link:http://security.stackexchange.com/a/26253/16485[Scrypt vs. Bcrypt (as of 2010)^]
* link:http://security.stackexchange.com/a/6415/16485[Bcrypt vs PBKDF2^]
* link:http://wildlyinaccurate.com/bcrypt-choosing-a-work-factor/[Choosing a work factor for Bcrypt^]
-* link:https://docs.spring.io/spring-security/site/docs/current/apidocs/org/springframework/security/crypto/bcrypt/BCrypt.html[Spring Security Bcrypt^]
+* link:https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/crypto/bcrypt/BCrypt.html[Spring Security Bcrypt^]
* link:https://www.openssl.org/docs/man1.1.0/crypto/EVP_BytesToKey.html[OpenSSL EVP BytesToKey PKCS#1v1.5^]
* link:https://wiki.openssl.org/index.php/Manual:PKCS5_PBKDF2_HMAC(3)[OpenSSL PBKDF2 KDF^]
* link:http://security.stackexchange.com/a/29139/16485[OpenSSL KDF flaws description^]
@@ -1810,7 +1912,7 @@ If no administrator action is taken, the configuration values remain unencrypted
[[encrypt-config_tool]]
=== Encrypt-Config Tool
-The `encrypt-config` command line tool (invoked as `./bin/encrypt-config.sh` or `bin\encrypt-config.bat`) reads from a 'nifi.properties' file with plaintext sensitive configuration values, prompts for a master password or raw hexadecimal key, and encrypts each value. It replaces the plain values with the protected value in the same file, or writes to a new 'nifi.properties' file if specified.
+The `encrypt-config` command line tool (invoked as `./bin/encrypt-config.sh` or `bin\encrypt-config.bat`) reads from a _nifi.properties_ file with plaintext sensitive configuration values, prompts for a master password or raw hexadecimal key, and encrypts each value. It replaces the plain values with the protected value in the same file, or writes to a new _nifi.properties_ file if specified.
The default encryption algorithm utilized is AES/GCM 128/256-bit. 128-bit is used if the JCE Unlimited Strength Cryptographic Jurisdiction Policy files are not installed, and 256-bit is used if they are installed.
@@ -1818,27 +1920,27 @@ You can use the following command line options with the `encrypt-config` tool:
* `-h`,`--help` Prints this usage message
* `-v`,`--verbose` Sets verbose mode (default false)
- * `-n`,`--niFiProperties <arg>` The nifi.properties file containing unprotected config values (will be overwritten)
- * `-l`,`--loginIdentityProviders <arg>` The login-identity-providers.xml file containing unprotected config values (will be overwritten)
- * `-a`,`--authorizers <arg>` The authorizers.xml file containing unprotected config values (will be overwritten)
- * `-f`,`--flowXml <arg>` The flow.xml.gz file currently protected with old password (will be overwritten)
- * `-b`,`--bootstrapConf <arg>` The bootstrap.conf file to persist master key
- * `-o`,`--outputNiFiProperties <arg>` The destination nifi.properties file containing protected config values (will not modify input nifi.properties)
- * `-i`,`--outputLoginIdentityProviders <arg>` The destination login-identity-providers.xml file containing protected config values (will not modify input login-identity-providers.xml)
- * `-u`,`--outputAuthorizers <arg>` The destination authorizers.xml file containing protected config values (will not modify input authorizers.xml)
- * `-g`,`--outputFlowXml <arg>` The destination flow.xml.gz file containing protected config values (will not modify input flow.xml.gz)
+ * `-n`,`--niFiProperties <arg>` The _nifi.properties_ file containing unprotected config values (will be overwritten)
+ * `-l`,`--loginIdentityProviders <arg>` The _login-identity-providers.xml_ file containing unprotected config values (will be overwritten)
+ * `-a`,`--authorizers <arg>` The _authorizers.xml_ file containing unprotected config values (will be overwritten)
+ * `-f`,`--flowXml <arg>` The _flow.xml.gz_ file currently protected with old password (will be overwritten)
+ * `-b`,`--bootstrapConf <arg>` The _bootstrap.conf_ file to persist master key
+ * `-o`,`--outputNiFiProperties <arg>` The destination _nifi.properties_ file containing protected config values (will not modify input _nifi.properties_)
+ * `-i`,`--outputLoginIdentityProviders <arg>` The destination _login-identity-providers.xml_ file containing protected config values (will not modify input _login-identity-providers.xml_)
+ * `-u`,`--outputAuthorizers <arg>` The destination _authorizers.xml_ file containing protected config values (will not modify input _authorizers.xml_)
+ * `-g`,`--outputFlowXml <arg>` The destination _flow.xml.gz_ file containing protected config values (will not modify input _flow.xml.gz_)
* `-k`,`--key <arg>` The raw hexadecimal key to use to encrypt the sensitive properties
* `-e`,`--oldKey <arg>` The old raw hexadecimal key to use during key migration
* `-p`,`--password <arg>` The password from which to derive the key to use to encrypt the sensitive properties
* `-w`,`--oldPassword <arg>` The old password from which to derive the key during migration
* `-r`,`--useRawKey` If provided, the secure console will prompt for the raw key value in hexadecimal form
- * `-m`,`--migrate` If provided, the nifi.properties and/or login-identity-providers.xml sensitive properties will be re-encrypted with a new key
- * `-x`,`--encryptFlowXmlOnly` If provided, the properties in flow.xml.gz will be re-encrypted with a new key but the nifi.properties and/or login-identity-providers.xml files will not be modified
- * `-s`,`--propsKey <arg>` The password or key to use to encrypt the sensitive processor properties in flow.xml.gz
- * `-A`,`--newFlowAlgorithm <arg>` The algorithm to use to encrypt the sensitive processor properties in flow.xml.gz
- * `-P`,`--newFlowProvider <arg>` The security provider to use to encrypt the sensitive processor properties in flow.xml.gz
+ * `-m`,`--migrate` If provided, the _nifi.properties_ and/or _login-identity-providers.xml_ sensitive properties will be re-encrypted with a new key
+ * `-x`,`--encryptFlowXmlOnly` If provided, the properties in _flow.xml.gz_ will be re-encrypted with a new key but the _nifi.properties_ and/or _login-identity-providers.xml_ files will not be modified
+ * `-s`,`--propsKey <arg>` The password or key to use to encrypt the sensitive processor properties in _flow.xml.gz_
+ * `-A`,`--newFlowAlgorithm <arg>` The algorithm to use to encrypt the sensitive processor properties in _flow.xml.gz_
+ * `-P`,`--newFlowProvider <arg>` The security provider to use to encrypt the sensitive processor properties in _flow.xml.gz_
-As an example of how the tool works, assume that you have installed the tool on a machine supporting 256-bit encryption and with the following existing values in the 'nifi.properties' file:
+As an example of how the tool works, assume that you have installed the tool on a machine supporting 256-bit encryption and with the following existing values in the _nifi.properties_ file:
----
# security properties #
@@ -1865,7 +1967,7 @@ encrypt-config.sh
-n nifi.properties
----
-As a result, the 'nifi.properties' file is overwritten with protected properties and sibling encryption identifiers (`aes/gcm/256`, the currently supported algorithm):
+As a result, the _nifi.properties_ file is overwritten with protected properties and sibling encryption identifiers (`aes/gcm/256`, the currently supported algorithm):
----
# security properties #
@@ -1886,7 +1988,7 @@ nifi.security.truststoreType=
nifi.security.truststorePasswd=
----
-Additionally, the 'bootstrap.conf' file is updated with the encryption key as follows:
+Additionally, the _bootstrap.conf_ file is updated with the encryption key as follows:
----
# Master key in hexadecimal format for encrypted sensitive configuration values
@@ -1895,11 +1997,11 @@ nifi.bootstrap.sensitive.key=0123456789ABCDEFFEDCBA98765432100123456789ABCDEFFED
Sensitive configuration values are encrypted by the tool by default, however you can encrypt any additional properties, if desired. To encrypt additional properties, specify them as comma-separated values in the `nifi.sensitive.props.additional.keys` property.
-If the 'nifi.properties' file already has valid protected values, those property values are not modified by the tool.
+If the _nifi.properties_ file already has valid protected values, those property values are not modified by the tool.
-When applied to 'login-identity-providers.xml' and 'authorizers.xml', the property elements are updated with an `encryption` attribute:
+When applied to _login-identity-providers.xml_ and _authorizers.xml_, the property elements are updated with an `encryption` attribute:
-Example of protected login-identity-providers.xml:
+Example of protected _login-identity-providers.xml_:
----
<!-- LDAP Provider -->
@@ -1916,7 +2018,7 @@ Example of protected login-identity-providers.xml:
</provider>
----
-Example of protected authorizers.xml:
+Example of protected _authorizers.xml_:
---
<!-- LDAP User Group Provider -->
@@ -1936,7 +2038,7 @@ Example of protected authorizers.xml:
[encrypt_config_property_migration]
=== Sensitive Property Key Migration
-In order to change the key used to encrypt the sensitive values, indicate *migration mode* using the `-m` or `--migrate` flag, provide the new key or password using the `-k` or `-p` flags as usual, and provide the existing key or password using `-e` or `-w` respectively. This will allow the toolkit to decrypt the existing values and re-encrypt them, and update `bootstrap.conf` with the new key. Only one of the key or password needs to be specified for each phase (old vs. new), and any combination is sufficient:
+In order to change the key used to encrypt the sensitive values, indicate *migration mode* using the `-m` or `--migrate` flag, provide the new key or password using the `-k` or `-p` flags as usual, and provide the existing key or password using `-e` or `-w` respectively. This will allow the toolkit to decrypt the existing values and re-encrypt them, and update _bootstrap.conf_ with the new key. Only one of the key or password needs to be specified for each phase (old vs. new), and any combination is sufficient:
* old key -> new key
* old key -> new password
@@ -1946,17 +2048,17 @@ In order to change the key used to encrypt the sensitive values, indicate *migra
[encrypt_config_flow_migration]
=== Existing Flow Migration
-This tool can also be used to change the value of `nifi.sensitive.props.key` for an existing flow. The tool will read the existing `flow.xml.gz` and decrypt any sensitive component properties using the original key,
-then re-encrypt the sensitive properties with the new key, and write out a new version of the `flow.xml.gz`, or overwrite the existing one.
+This tool can also be used to change the value of `nifi.sensitive.props.key` for an existing flow. The tool will read the existing _flow.xml.gz_ and decrypt any sensitive component properties using the original key,
+then re-encrypt the sensitive properties with the new key, and write out a new version of the _flow.xml.gz_, or overwrite the existing one.
-The current sensitive properties key is not provided as a command-line argument, as it is read directly from `nifi.properties`. As this file is a required parameter, the `-x`/`--encryptFlowXmlOnly` flags tell the tool *not* to attempt to encrypt the properties in `nifi.properties`, but rather to *only* update the `nifi.sensitive.props.key` value with the new key. The exception to this is if the `nifi.properties` is *already* encrypted, the new sensitive property key will also be encrypted before being written to `nifi.properties`.
+The current sensitive properties key is not provided as a command-line argument, as it is read directly from _nifi.properties_. As this file is a required parameter, the `-x`/`--encryptFlowXmlOnly` flags tell the tool *not* to attempt to encrypt the properties in _nifi.properties_, but rather to *only* update the `nifi.sensitive.props.key` value with the new key. The exception to this is if the _nifi.properties_ is *already* encrypted, the new sensitive property key will also be encrypted before being written to _nifi.properties_.
-The following command would migrate the sensitive properties key in place, meaning it would overwrite the existing `flow.xml.gz` and `nifi.properties`:
+The following command would migrate the sensitive properties key in place, meaning it would overwrite the existing _flow.xml.gz_ and _nifi.properties_:
----
./encrypt-config.sh -f /path/to/flow.xml.gz -n ./path/to/nifi.properties -s newpassword -x
----
-The following command would migrate the sensitive properties key and write out a separate `flow.xml.gz` and `nifi.properties`:
+The following command would migrate the sensitive properties key and write out a separate _flow.xml.gz_ and _nifi.properties_:
----
./encrypt-config.sh -f ./path/to/src/flow.xml.gz -g /path/to/dest/flow.xml.gz -n /path/to/src/nifi.properties -o /path/to/dest/nifi.properties -s newpassword -x
----
@@ -1991,7 +2093,7 @@ and clustered environments. These utilities include:
* Node Manager -- The node manager tool allows administrators to perform a status check on a node as well as to connect, disconnect, or remove nodes that are part of a cluster.
* File Manager -- The file manager tool allows administrators to backup, install or restore a NiFi installation from backup.
-The admin toolkit is bundled with the nifi-toolkit and can be executed with scripts found in the _bin_ folder.
+The admin toolkit is bundled with the nifi-toolkit and can be executed with scripts found in the `bin` folder.
=== Prerequisites for Running Admin Toolkit in a Secure Environment
For secured nodes and clusters, two policies should be configured in advance:
@@ -2021,7 +2123,7 @@ The following are available options:
* `-b`,`--bootstrapConf <arg>` Existing Bootstrap Configuration file (required)
* `-d`,`--nifiInstallDir <arg>` NiFi Root Folder (required)
* `-h`,`--help` Help Text (optional)
-* `-l`,`--level <arg>` Status level of bulletin – INFO, WARN, ERROR
+* `-l`,`--level <arg>` Status level of bulletin – `INFO`, `WARN`, `ERROR`
* `-m`,`--message <arg>` Bulletin message (required)
* `-p`,`--proxyDN <arg>` Proxy or User DN (required for secured nodes)
* `-v`,`--verbose` Verbose messaging (optional)
@@ -2046,7 +2148,7 @@ displays if the node is not part of a cluster) as well as obtaining the status o
from a cluster and need to be
connected or removed, a list of urls of connected nodes should be provided to send the required command to
the active cluster. Node Manager supports NiFi version 1.0.0 and higher. Node Manager is also available in
-'node-manager.bat' file for use on Windows machines.
+_node-manager.bat_ file for use on Windows machines.
To connect, disconnect, or remove a node from a cluster:
@@ -2105,7 +2207,7 @@ Disconnect:
When a node is disconnected from the cluster, the node itself should appear as disconnected and the cluster
should have a bulletin indicating the disconnect request was received. The cluster should also show _n-1/n_
-nodes available in the cluster. For example, if 1 node is disconnected from a 3-node cluster, then 2 of 3 nodes
+nodes available in the cluster. For example, if 1 node is disconnected from a 3-node cluster, then "2 of 3" nodes
should show on the remaining nodes in the cluster. Changes to the flow should not be allowed on the cluster
with a disconnected node.
@@ -2120,7 +2222,7 @@ Remove:
When the remove command is executed the node should show as disconnected from a cluster. The nodes remaining
in the cluster should show _n-1/n-1_ nodes. For example, if 1 node is removed from a 3-node cluster, then the remaining 2 nodes
-should show 2 of 2 nodes). The cluster should allow a flow to be adjusted. The removed node can rejoin the
+should show "2 of 2" nodes. The cluster should allow a flow to be adjusted. The removed node can rejoin the
cluster if restarted and the flow for the cluster has not changed. If the flow was changed, the flow template of
the removed node should be deleted before restarting the node to allow it to obtain the cluster flow (otherwise
an uninheritable flow file exception may occur).
@@ -2129,7 +2231,7 @@ an uninheritable flow file exception may occur).
The File Manager utility allows system administrators to take a backup of an existing NiFi installation, install a new version of NiFi
in a designated location (while migrating any previous configuration settings) or restore an installation from a previous backup.
-File Manager supports NiFi version 1.0.0 and higher and is available in 'file-manager.bat' file for use on Windows machines.
+File Manager supports NiFi version 1.0.0 and higher and is available in _file-manager.bat_ file for use on Windows machines.
To show help:
@@ -2199,8 +2301,10 @@ folder of the current installation) to the new installation as well as migrate c
Restore:
The restore operation allows an existing installation to revert back to a previous installation. Using an existing backup directory (created from the backup operation)
-the FileManager utility will restore libraries, scripts and documents as well as revert to previous configurations. NOTE: If repositories were changed due to the installation
-of a newer version of NiFi these may no longer be compatible during restore. In that scenario exclude the -m option to ensure new repositories will be created or, if repositories
+the FileManager utility will restore libraries, scripts and documents as well as revert to previous configurations.
+
+NOTE: If repositories were changed due to the installation
+of a newer version of NiFi these may no longer be compatible during restore. In that scenario exclude the `-m` option to ensure new repositories will be created or, if repositories
live outside of the NiFi directory, remove them so they can be recreated on startup after restore.
@@ -2238,7 +2342,7 @@ NiFi Clustering is unique and has its own terminology. It's important to underst
[template="glossary", id="terminology"]
*Terminology* +
-*NiFi Cluster Coordinator*: A NiFi Cluster Cluster Coordinator is the node in a NiFi cluster that is responsible for carrying out
+*NiFi Cluster Coordinator*: A NiFi Cluster Coordinator is the node in a NiFi cluster that is responsible for carrying out
tasks to manage which nodes are allowed in the cluster and providing the most up-to-date flow to newly joining nodes. When a
DataFlow Manager manages a dataflow in a cluster, they are able to do so through the User Interface of any node in the cluster. Any
change made is then replicated to all nodes in the cluster.
@@ -2308,7 +2412,7 @@ some number of Nodes have cast votes (configured by setting the `nifi.cluster.fl
a flow is elected to be the "correct" copy of the flow. All nodes that have incompatible flows are then disconnected
from the cluster while those with compatible flows inherit the cluster's flow. Election is performed according to
the "popular vote" with the caveat that the winner will never be an "empty flow" unless all flows are empty. This
-allows an administrator to remove a node's `flow.xml.gz` file and restart the node, knowing that the node's flow will
+allows an administrator to remove a node's _flow.xml.gz_ file and restart the node, knowing that the node's flow will
not be voted to be the "correct" flow unless no other flow is found.
*Basic Cluster Setup* +
@@ -2329,31 +2433,31 @@ For each Node, the minimum properties to configure are as follows:
* Under the _State Management section_, set the `nifi.state.management.provider.cluster` property
to the identifier of the Cluster State Provider. Ensure that the Cluster State Provider has been
configured in the _state-management.xml_ file. See <<state_providers>> for more information.
-* Under _Cluster Node_ Properties, set the following:
-** nifi.cluster.is.node - Set this to _true_.
-** nifi.cluster.node.address - Set this to the fully qualified hostname of the node. If left blank, it defaults to "localhost".
-** nifi.cluster.node.protocol.port - Set this to an open port that is higher than 1024 (anything lower requires root).
-** nifi.cluster.node.protocol.threads - The number of threads that should be used to communicate with other nodes in the cluster. This property
- defaults to 10. A thread pool is used for replicating requests to all nodes, and the
+* Under _Cluster Node Properties_, set the following:
+** `nifi.cluster.is.node` - Set this to _true_.
+** `nifi.cluster.node.address` - Set this to the fully qualified hostname of the node. If left blank, it defaults to `localhost`.
+** `nifi.cluster.node.protocol.port` - Set this to an open port that is higher than 1024 (anything lower requires root).
+** `nifi.cluster.node.protocol.threads` - The number of threads that should be used to communicate with other nodes in the cluster. This property
+ defaults to `10`. A thread pool is used for replicating requests to all nodes, and the
thread pool will never have fewer than this number of threads. It will grow as needed up to the maximum value set by the `nifi.cluster.node.protocol.max.threads`
property.
-** nifi.cluster.node.protocol.max.threads - The maximum number of threads that should be used to communicate with other nodes in the cluster. This property
- defaults to 50. A thread pool is used for replication requests to all nodes, and the thread pool will have a "core" size that is configured by the
+** `nifi.cluster.node.protocol.max.threads` - The maximum number of threads that should be used to communicate with other nodes in the cluster. This property
+ defaults to `50`. A thread pool is used for replication requests to all nodes, and the thread pool will have a "core" size that is configured by the
`nifi.cluster.node.protocol.threads` property. However, if necessary, the thread pool will increase the number of active threads to the limit
set by this property.
-** nifi.zookeeper.connect.string - The Connect String that is needed to connect to Apache ZooKeeper. This is a comma-separted list
- of hostname:port pairs. For example, localhost:2181,localhost:2182,localhost:2183. This should contain a list of all ZooKeeper
+** `nifi.zookeeper.connect.string` - The Connect String that is needed to connect to Apache ZooKeeper. This is a comma-separated list
+ of hostname:port pairs. For example, `localhost:2181,localhost:2182,localhost:2183`. This should contain a list of all ZooKeeper
instances in the ZooKeeper quorum.
-** nifi.zookeeper.root.node - The root ZNode that should be used in ZooKeeper. ZooKeeper provides a directory-like structure
+** `nifi.zookeeper.root.node` - The root ZNode that should be used in ZooKeeper. ZooKeeper provides a directory-like structure
for storing data. Each 'directory' in this structure is referred to as a ZNode. This denotes the root ZNode, or 'directory',
- that should be used for storing data. The default value is _/root_. This is important to set correctly, as which cluster
+ that should be used for storing data. The default value is `/root`. This is important to set correctly, as which cluster
the NiFi instance attempts to join is determined by which ZooKeeper instance it connects to and the ZooKeeper Root Node
that is specified.
-** nifi.cluster.flow.election.max.wait.time - Specifies the amount of time to wait before electing a Flow as the "correct" Flow.
+** `nifi.cluster.flow.election.max.wait.time` - Specifies the amount of time to wait before electing a Flow as the "correct" Flow.
If the number of Nodes that have voted is equal to
<TRUNCATED>
[2/2] nifi git commit: NIFI-5469 Additional italics and code
formatting corrections for consistency
Posted by ze...@apache.org.
NIFI-5469 Additional italics and code formatting corrections for consistency
This closes #2925
Signed-off-by: zenfenan <ze...@apache.org>
Project: http://git-wip-us.apache.org/repos/asf/nifi/repo
Commit: http://git-wip-us.apache.org/repos/asf/nifi/commit/86beca0c
Tree: http://git-wip-us.apache.org/repos/asf/nifi/tree/86beca0c
Diff: http://git-wip-us.apache.org/repos/asf/nifi/diff/86beca0c
Branch: refs/heads/master
Commit: 86beca0c58231174c33a532daed085b1752c3304
Parents: 17ea292
Author: Andrew Lim <an...@gmail.com>
Authored: Mon Jul 30 16:17:19 2018 -0400
Committer: zenfenan <si...@gmail.com>
Committed: Mon Aug 13 15:03:41 2018 +0530
----------------------------------------------------------------------
.../src/main/asciidoc/administration-guide.adoc | 1138 ++++++++++--------
1 file changed, 622 insertions(+), 516 deletions(-)
----------------------------------------------------------------------