[
https://issues.apache.org/jira/browse/NIFI-5469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560251#comment-16560251
]
ASF GitHub Bot commented on NIFI-5469:
--------------------------------------
Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2922#discussion_r205884976
--- 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.
--- End diff --
"Each of those remote node**s**."
> 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)
