[
https://issues.apache.org/jira/browse/NIFI-5469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560261#comment-16560261
]
ASF GitHub Bot commented on NIFI-5469:
--------------------------------------
Github user andrewmlim commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2922#discussion_r205885877
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -3074,69 +3178,69 @@
nifi.provenance.repository.encryption.key=0123456789ABCDEFFEDCBA9876543210012345
The Component Status Repository contains the information for the Component
Status History tool in the User Interface. These
properties govern how that tool works.
-The buffer.size and snapshot.frequency work together to determine the
amount of historical data to retain. As an example to
+The `buffer.size` and `snapshot.frequency` work together to determine the
amount of historical data to retain. As an example to
configure two days worth of historical data with a data point snapshot
occurring every 5 minutes you would configure
snapshot.frequency to be "5 mins" and the buffer.size to be "576". To
further explain this example for every 60 minutes there
are 12 (60 / 5) snapshot windows for that time period. To keep that data
for 48 hours (12 * 48) you end up with a buffer size
of 576.
|====
|*Property*|*Description*
-|nifi.components.status.repository.implementation|The Component Status
Repository implementation. The default value is
`org.apache.nifi.controller.status.history.VolatileComponentStatusRepository`
and should not be changed.
-|nifi.components.status.repository.buffer.size|Specifies the buffer size
for the Component Status Repository. The default value is `1440`.
-|nifi.components.status.snapshot.frequency|This value indicates how often
to present a snapshot of the components' status history. The default value is
`1 min`.
+|`nifi.components.status.repository.implementation`|The Component Status
Repository implementation. The default value is
`org.apache.nifi.controller.status.history.VolatileComponentStatusRepository`
and should not be changed.
+|`nifi.components.status.repository.buffer.size`|Specifies the buffer size
for the Component Status Repository. The default value is `1440`.
+|`nifi.components.status.snapshot.frequency`|This value indicates how
often to present a snapshot of the components' status history. The default
value is `1 min`.
|====
[[site_to_site_properties]]
=== Site to Site Properties
These properties govern how this instance of NiFi communicates with remote
instances of NiFi when Remote Process Groups are configured in the dataflow.
-Remote Process Groups can choose transport protocol from RAW and HTTP.
Properties named with _nifi.remote.input.socket.*_ are RAW transport protocol
specific. Similarly, _nifi.remote.input.http.*_ are HTTP transport protocol
specific properties.
+Remote Process Groups can choose transport protocol from RAW and HTTP.
Properties named with `nifi.remote.input.socket.`* are RAW transport protocol
specific. Similarly, `nifi.remote.input.http.`* are HTTP transport protocol
specific properties.
|====
|*Property*|*Description*
-|nifi.remote.input.host|The host name that will be given out to clients to
connect to this NiFi instance for Site-to-Site communication. By default, it is
the value from InetAddress.getLocalHost().getHostName(). On UNIX-like operating
systems, this is typically the output from the `hostname` command.
-|nifi.remote.input.secure|This indicates whether communication between
this instance of NiFi and remote NiFi instances should be secure. By default,
it is set to `false`. In order for secure site-to-site to work, set the
property to `true`. Many other Security Properties (below) must also be
configured.
-|nifi.remote.input.socket.port|The remote input socket port for
Site-to-Site communication. By default, it is blank, but it must have a value
in order to use RAW socket as transport protocol for Site-to-Site.
-|nifi.remote.input.http.enabled|Specifies whether HTTP Site-to-Site should
be enabled on this host. By default, it is set to `true`. +
+|`nifi.remote.input.host`|The host name that will be given out to clients
to connect to this NiFi instance for Site-to-Site communication. By default, it
is the value from InetAddress.getLocalHost().getHostName(). On UNIX-like
operating systems, this is typically the output from the `hostname` command.
+|`nifi.remote.input.secure`|This indicates whether communication between
this instance of NiFi and remote NiFi instances should be secure. By default,
it is set to `false`. In order for secure site-to-site to work, set the
property to `true`. Many other Security Properties (below) must also be
configured.
+|`nifi.remote.input.socket.port`|The remote input socket port for
Site-to-Site communication. By default, it is blank, but it must have a value
in order to use RAW socket as transport protocol for Site-to-Site.
+|`nifi.remote.input.http.enabled`|Specifies whether HTTP Site-to-Site
should be enabled on this host. By default, it is set to `true`. +
Whether a Site-to-Site client uses HTTP or HTTPS is determined by
`nifi.remote.input.secure`. If it is set to `true`, then requests are sent as
HTTPS to `nifi.web.https.port`. If set to `false`, HTTP requests are sent to
`nifi.web.http.port`.
-|nifi.remote.input.http.transaction.ttl|Specifies how long a transaction
can stay alive on the server. By default, it is set to `30 secs`. +
+|`nifi.remote.input.http.transaction.ttl`|Specifies how long a transaction
can stay alive on the server. By default, it is set to `30 secs`. +
If a Site-to-Site client hasn’t proceeded to the next action after this
period of time, the transaction is discarded from the remote NiFi instance. For
example, when a client creates a transaction but doesn’t send or receive flow
files, or when a client sends or receives flow files but doesn’t confirm that
transaction.
-|nifi.remote.contents.cache.expiration|Specifies how long NiFi should
cache information about a remote NiFi instance when communicating via
Site-to-Site. By default, NiFi will cache the +
+|`nifi.remote.contents.cache.expiration`|Specifies how long NiFi should
cache information about a remote NiFi instance when communicating via
Site-to-Site. By default, NiFi will cache the +
responses from the remote system for `30 secs`. This allows NiFi to avoid
constantly making HTTP requests to the remote system, which is particularly
important when this instance of NiFi +
has many instances of Remote Process Groups.
|====
[[site_to_site_reverse_proxy_properties]]
=== Site to Site Routing Properties for Reverse Proxies
-Site-to-Site requires peer-to-peer communication between a client and a
remote NiFi node. E.g. if a remote NiFi cluster has 3 nodes, nifi0, nifi1 and
nifi2, then a client requests have to be reachable to each of those remote node.
+Site-to-Site requires peer-to-peer communication between a client and a
remote NiFi node. E.g. if a remote NiFi cluster has 3 nodes (nifi0, nifi1 and
nifi2) then a client requests have to be reachable to each of those remote node.
If a NiFi cluster is planned to receive/transfer data from/to Site-to-Site
clients over the internet or a company firewall, a reverse proxy server can be
deployed in front of the NiFi cluster nodes as a gateway to route client
requests to upstream NiFi nodes, to reduce number of servers and ports those
have to be exposed.
In such environment, the same NiFi cluster would also be expected to be
accessed by Site-to-Site clients within the same network. Sending FlowFiles to
itself for load distribution among NiFi cluster nodes can be a typical example.
In this case, client requests should be routed directly to a node without going
through the reverse proxy.
-In order to support such deployments, remote NiFi clusters need to expose
its Site-to-Site endpoints dynamically based on client request contexts.
Following properties configure how peers should be exposed to clients. A
routing definition consists of 4 properties, 'when', 'hostname', 'port', and
'secure', grouped by 'protocol' and 'name'. Multiple routing definitions can be
configured. 'protocol' represents Site-to-Site transport protocol, i.e. raw or
http.
+In order to support such deployments, remote NiFi clusters need to expose
its Site-to-Site endpoints dynamically based on client request contexts.
Following properties configure how peers should be exposed to clients. A
routing definition consists of 4 properties, `when`, `hostname`, `port`, and
`secure`, grouped by `protocol` and `name`. Multiple routing definitions can be
configured. `protocol` represents Site-to-Site transport protocol, i.e. raw or
http.
|====
|*Property*|*Description*
-|nifi.remote.route.{protocol}.{name}.when|Boolean value, 'true' or
'false'. Controls whether the routing definition for this name should be used.
-|nifi.remote.route.{protocol}.{name}.hostname|Specify hostname that will
be introduced to Site-to-Site clients for further communications.
-|nifi.remote.route.{protocol}.{name}.port|Specify port number that will be
introduced to Site-to-Site clients for further communications.
-|nifi.remote.route.{protocol}.{name}.secure|Boolean value, 'true' or
'false'. Specify whether the remote peer should be accessed via secure
protocol. Defaults to 'false'.
+|`nifi.remote.route.{protocol}.{name}.when`|Boolean value, `true` or
`false`. Controls whether the routing definition for this name should be used.
+|`nifi.remote.route.{protocol}.{name}.hostname`|Specify hostname that will
be introduced to Site-to-Site clients for further communications.
+|`nifi.remote.route.{protocol}.{name}.port`|Specify port number that will
be introduced to Site-to-Site clients for further communications.
+|`nifi.remote.route.{protocol}.{name}.secure`|Boolean value, `true` or
`false`. Specify whether the remote peer should be accessed via secure
protocol. Defaults to `false`.
|====
All of above routing properties can use NiFi Expression Language to
compute target peer description from request context. Available variables are:
|===
|*Variable name*|*Description*
-|s2s.{source\|target}.hostname|Hostname of the source where the request
came from, and the original target.
-|s2s.{source\|target}.port|Same as above, for ports. Source port may not
be useful as it is just a client side TCP port.
-|s2s.{source\|target}.secure|Same as above, for secure or not.
-|s2s.protocol|The name of Site-to-Site protocol being used, RAW or HTTP.
-|s2s.request|The name of current request type, SiteToSiteDetail or Peers.
See Site-to-Site protocol sequence below for detail.
-|HTTP request headers|HTTP request header values can be referred by its
name.
+|`s2s.{source\|target}.hostname`|Hostname of the source where the request
came from, and the original target.
+|`s2s.{source\|target}.port`|Same as above, for ports. Source port may not
be useful as it is just a client side TCP port.
+|`s2s.{source\|target}.secure`|Same as above, for secure or not.
+|`s2s.protocol`|The name of Site-to-Site protocol being used, RAW or HTTP.
+|`s2s.request`|The name of current request type, SiteToSiteDetail or
Peers. See Site-to-Site protocol sequence below for detail.
--- End diff --
Raw or HTTP also in the line above.
> Edits needed for LDAP and Kerberos login identity provider sections in Admin
> Guide
> ----------------------------------------------------------------------------------
>
> Key: NIFI-5469
> URL: https://issues.apache.org/jira/browse/NIFI-5469
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Documentation & Website
> Reporter: Andrew Lim
> Assignee: Andrew Lim
> Priority: Minor
>
> Going through the Authentication and Authorization sections of the Admin
> Guide, I noticed the following improvements could be made:
> * Removed “Kerberos Config File” property from kerberos-provider login
> identity provider (this was done because the same property exists in
> nifi.properties)
> * Corrected the "LDAP-based Users/Groups Referencing User Attribute” login
> identity provider example to refer to “member uid"
> * Added titles to login identity provider examples for improved
> readability/search
> * Changed UserGroupProvider property examples from bulleted lists to tables
> Also, text formatting for references to config files, directories, etc. need
> to be made consistent. For example, config files like _nifi.properties_,
> _authorizers.xml_ should be italicized. Directories, properties and default
> values for properties should be monospaced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
