[GitHub] nifi pull request #3155: NIFI-5784 Edit Admin Guide to remove duplicate cont...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi/pull/3155 NIFI-5784 Edit Admin Guide to remove duplicate content that is in new⦠⦠Toolkit Guide Edited Toolkit Guide as needed for links. You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi NIFI-5784 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/3155.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3155 commit 77ef84a01eb198482fb01bd4c6a4937bddd10136 Author: Andrew Lim Date: 2018-11-07T16:20:59Z NIFI-5784 Edit Admin Guide to remove duplicate content that is in new Toolkit Guide ---
[GitHub] nifi issue #3124: NIFI-5767 Added NiFi Toolkit Guide to docs
Github user andrewmlim commented on the issue: https://github.com/apache/nifi/pull/3124 @pvillard31 I think with my latest changes, ready to merge unless you see any other issues. Thanks! ---
[GitHub] nifi pull request #3124: NIFI-5767 Added NiFi Toolkit Guide to docs
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3124#discussion_r230881754 --- Diff: nifi-docs/src/main/asciidoc/toolkit-guide.adoc --- @@ -0,0 +1,1257 @@ +// +// Licensed to the Apache Software Foundation (ASF) under one or more +// contributor license agreements. See the NOTICE file distributed with +// this work for additional information regarding copyright ownership. +// The ASF licenses this file to You under the Apache License, Version 2.0 +// (the "License"); you may not use this file except in compliance with +// the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, software +// distributed under the License is distributed on an "AS IS" BASIS, +// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +// See the License for the specific language governing permissions and +// limitations under the License. +// += Apache NiFi Toolkit Guide +Apache NiFi Team +:homepage: http://nifi.apache.org +:linkattrs: + +== Overview +The NiFi Toolkit contains several command line utilities to setup and support NiFi in standalone and clustered environments. The utilities include: + +* CLI -- The `cli` tool enables administrators to interact with NiFi and NiFi Registry instances to automate tasks such as deploying versioned flows and managing process groups and cluster nodes. +* Encrypt Config -- The `encrypt-config` tool encrypts the sensitive keys in the _nifi.properties_ file to facilitate the setup of a secure NiFi instance. +* File Manager -- The `file-manager` tool enables administrators to backup, install or restore a NiFi installation from backup. +* Flow Analyzer -- The `flow-analyzer` tool produces a report that helps administrators understand the max amount of data which can be stored in backpressure for a given flow. +* Node Manager -- The `node-manager` tool enables administrators to perform status checks on nodes as well as the ability to connect, disconnect, or remove nodes from the cluster. +* Notify -- The `notify` tool enables administrators to send bulletins to the NiFi UI. +* S2S -- The `s2s` tool enables administrators to send data into or out of NiFi flows over site-to-site. +* TLS Toolkit -- The `tls-toolkit` utility generates the required keystores, truststore, and relevant configuration files to facilitate the setup of a secure NiFi instance. +* ZooKeeper Migrator -- The `zk-migrator` tool enables administrators to: +** move ZooKeeper information from one ZooKeeper cluster to another +** migrate ZooKeeper node ownership + +The utilities are executed with scripts found in the `bin` folder of your NiFi Toolkit installation. + +NOTE: The NiFi Toolkit is downloaded separately from NiFi (see the link:https://nifi.apache.org/download.html[Apache NiFi downloads page^]). + +=== Prerequisites for Running in a Secure Environment +For secured nodes and clusters, two policies should be configured in advance: + +* Access the controller â A user that will have access to these utilities should be authorized in NiFi by creating an âaccess the controllerâ policy (`/controller`) with both view and modify rights +* Proxy user request â If not previously set, nodeâs identity (the DN value of the nodeâs certificate) should be authorized to proxy requests on behalf of a user + +When executing either the Notify or Node Manager tools in a secured environment the `proxyDN` flag option should be used in order to properly identify the user that was authorized to execute these commands. In non-secure environments, or if running the status operation on the Node Manager tool, the flag is ignored. + +== NiFi CLI +This tool offers a CLI focused on interacting with NiFi and NiFi Registry in order to automate tasks, such as deploying flows from a NIFi Registy to a NiFi instance or managing process groups and cluster nodes. + +=== Usage +The CLI toolkit can be executed in standalone mode to execute a single command, or interactive mode to enter an interactive shell. + +To execute a single command: + + ./bin/cli.sh + +To launch the interactive shell: + + ./bin/cli.sh + +To show help: + + cli.sh -h + +The following are available options: + + demo quick-import + nifi current-user + nifi cluster-summary + nifi connect-node + nifi delete-node + nifi disconnect-node + nifi get-root-id + nifi get-node + nifi get-nodes + nifi offload-node + nifi list-reg-clients + nifi create-reg-client + nifi update-reg-client + nifi get-reg-client-id
[GitHub] nifi pull request #3124: NIFI-5767 Added NiFi Toolkit Guide to docs
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3124#discussion_r230881702 --- Diff: nifi-docs/src/main/asciidoc/toolkit-guide.adoc --- @@ -0,0 +1,1257 @@ +// +// Licensed to the Apache Software Foundation (ASF) under one or more +// contributor license agreements. See the NOTICE file distributed with +// this work for additional information regarding copyright ownership. +// The ASF licenses this file to You under the Apache License, Version 2.0 +// (the "License"); you may not use this file except in compliance with +// the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, software +// distributed under the License is distributed on an "AS IS" BASIS, +// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +// See the License for the specific language governing permissions and +// limitations under the License. +// += Apache NiFi Toolkit Guide +Apache NiFi Team +:homepage: http://nifi.apache.org +:linkattrs: + +== Overview +The NiFi Toolkit contains several command line utilities to setup and support NiFi in standalone and clustered environments. The utilities include: + +* CLI -- The `cli` tool enables administrators to interact with NiFi and NiFi Registry instances to automate tasks such as deploying versioned flows and managing process groups and cluster nodes. +* Encrypt Config -- The `encrypt-config` tool encrypts the sensitive keys in the _nifi.properties_ file to facilitate the setup of a secure NiFi instance. +* File Manager -- The `file-manager` tool enables administrators to backup, install or restore a NiFi installation from backup. +* Flow Analyzer -- The `flow-analyzer` tool produces a report that helps administrators understand the max amount of data which can be stored in backpressure for a given flow. +* Node Manager -- The `node-manager` tool enables administrators to perform status checks on nodes as well as the ability to connect, disconnect, or remove nodes from the cluster. +* Notify -- The `notify` tool enables administrators to send bulletins to the NiFi UI. +* S2S -- The `s2s` tool enables administrators to send data into or out of NiFi flows over site-to-site. +* TLS Toolkit -- The `tls-toolkit` utility generates the required keystores, truststore, and relevant configuration files to facilitate the setup of a secure NiFi instance. +* ZooKeeper Migrator -- The `zk-migrator` tool enables administrators to: +** move ZooKeeper information from one ZooKeeper cluster to another +** migrate ZooKeeper node ownership + +The utilities are executed with scripts found in the `bin` folder of your NiFi Toolkit installation. + +NOTE: The NiFi Toolkit is downloaded separately from NiFi (see the link:https://nifi.apache.org/download.html[Apache NiFi downloads page^]). + +=== Prerequisites for Running in a Secure Environment +For secured nodes and clusters, two policies should be configured in advance: + +* Access the controller â A user that will have access to these utilities should be authorized in NiFi by creating an âaccess the controllerâ policy (`/controller`) with both view and modify rights +* Proxy user request â If not previously set, nodeâs identity (the DN value of the nodeâs certificate) should be authorized to proxy requests on behalf of a user + +When executing either the Notify or Node Manager tools in a secured environment the `proxyDN` flag option should be used in order to properly identify the user that was authorized to execute these commands. In non-secure environments, or if running the status operation on the Node Manager tool, the flag is ignored. + +== NiFi CLI +This tool offers a CLI focused on interacting with NiFi and NiFi Registry in order to automate tasks, such as deploying flows from a NIFi Registy to a NiFi instance or managing process groups and cluster nodes. + +=== Usage +The CLI toolkit can be executed in standalone mode to execute a single command, or interactive mode to enter an interactive shell. + +To execute a single command: + + ./bin/cli.sh + +To launch the interactive shell: + + ./bin/cli.sh + +To show help: + + cli.sh -h --- End diff -- Updated all help examples accordingly. ---
[GitHub] nifi pull request #3125: NIFI-5677 Added note to clarify why modifying/creat...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3125#discussion_r230824217 --- Diff: nifi-docs/src/main/asciidoc/user-guide.adoc --- @@ -1928,7 +1928,9 @@ The following actions are not considered local changes: * modifying sensitive property values * modifying remote process group URLs * updating a processor that was referencing a non-existent controller service to reference an externally available controller service -* modifying variables +* creating or modifying variables --- End diff -- Added "deleting variables" scenario. PR read for review/merge if no other issues raised. Thanks @ijokarumawak ! ---
[GitHub] nifi pull request #3125: NIFI-5677 Added note to clarify why modifying/creat...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3125#discussion_r230820448 --- Diff: nifi-docs/src/main/asciidoc/user-guide.adoc --- @@ -1928,7 +1928,9 @@ The following actions are not considered local changes: * modifying sensitive property values * modifying remote process group URLs * updating a processor that was referencing a non-existent controller service to reference an externally available controller service -* modifying variables +* creating or modifying variables --- End diff -- That's a good point. Will add that scenario. ---
[GitHub] nifi issue #3124: NIFI-5767 Added NiFi Toolkit Guide to docs
Github user andrewmlim commented on the issue: https://github.com/apache/nifi/pull/3124 I will file a Jira to edit the other docs that have duplicate content. The other docs can refer to the Toolkit Guide as needed. ---
[GitHub] nifi pull request #3124: NIFI-5767 Added NiFi Toolkit Guide to docs
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3124#discussion_r230381765 --- Diff: nifi-docs/src/main/asciidoc/toolkit-guide.adoc --- @@ -0,0 +1,1257 @@ +// +// Licensed to the Apache Software Foundation (ASF) under one or more +// contributor license agreements. See the NOTICE file distributed with +// this work for additional information regarding copyright ownership. +// The ASF licenses this file to You under the Apache License, Version 2.0 +// (the "License"); you may not use this file except in compliance with +// the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, software +// distributed under the License is distributed on an "AS IS" BASIS, +// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +// See the License for the specific language governing permissions and +// limitations under the License. +// += Apache NiFi Toolkit Guide +Apache NiFi Team +:homepage: http://nifi.apache.org +:linkattrs: + +== Overview +The NiFi Toolkit contains several command line utilities to setup and support NiFi in standalone and clustered environments. The utilities include: + +* CLI -- The `cli` tool enables administrators to interact with NiFi and NiFi Registry instances to automate tasks such as deploying versioned flows and managing process groups and cluster nodes. +* Encrypt Config -- The `encrypt-config` tool encrypts the sensitive keys in the _nifi.properties_ file to facilitate the setup of a secure NiFi instance. +* File Manager -- The `file-manager` tool enables administrators to backup, install or restore a NiFi installation from backup. +* Flow Analyzer -- The `flow-analyzer` tool produces a report that helps administrators understand the max amount of data which can be stored in backpressure for a given flow. +* Node Manager -- The `node-manager` tool enables administrators to perform status checks on nodes as well as the ability to connect, disconnect, or remove nodes from the cluster. +* Notify -- The `notify` tool enables administrators to send bulletins to the NiFi UI. +* S2S -- The `s2s` tool enables administrators to send data into or out of NiFi flows over site-to-site. +* TLS Toolkit -- The `tls-toolkit` utility generates the required keystores, truststore, and relevant configuration files to facilitate the setup of a secure NiFi instance. +* ZooKeeper Migrator -- The `zk-migrator` tool enables administrators to: +** move ZooKeeper information from one ZooKeeper cluster to another +** migrate ZooKeeper node ownership + +The utilities are executed with scripts found in the `bin` folder of your NiFi Toolkit installation. + +NOTE: The NiFi Toolkit is downloaded separately from NiFi (see the link:https://nifi.apache.org/download.html[Apache NiFi downloads page^]). + +=== Prerequisites for Running in a Secure Environment +For secured nodes and clusters, two policies should be configured in advance: + +* Access the controller â A user that will have access to these utilities should be authorized in NiFi by creating an âaccess the controllerâ policy (`/controller`) with both view and modify rights +* Proxy user request â If not previously set, nodeâs identity (the DN value of the nodeâs certificate) should be authorized to proxy requests on behalf of a user + +When executing either the Notify or Node Manager tools in a secured environment the `proxyDN` flag option should be used in order to properly identify the user that was authorized to execute these commands. In non-secure environments, or if running the status operation on the Node Manager tool, the flag is ignored. + +== NiFi CLI +This tool offers a CLI focused on interacting with NiFi and NiFi Registry in order to automate tasks, such as deploying flows from a NIFi Registy to a NiFi instance or managing process groups and cluster nodes. + +=== Usage +The CLI toolkit can be executed in standalone mode to execute a single command, or interactive mode to enter an interactive shell. + +To execute a single command: + + ./bin/cli.sh + +To launch the interactive shell: + + ./bin/cli.sh + +To show help: + + cli.sh -h + +The following are available options: + + demo quick-import + nifi current-user + nifi cluster-summary + nifi connect-node + nifi delete-node + nifi disconnect-node + nifi get-root-id + nifi get-node + nifi get-nodes + nifi offload-node + nifi list-reg-clients + nifi create-reg-client + nifi update-reg-client + nifi get-reg-client-id
[GitHub] nifi pull request #3124: NIFI-5767 Added NiFi Toolkit Guide to docs
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3124#discussion_r230381451 --- Diff: nifi-docs/src/main/asciidoc/toolkit-guide.adoc --- @@ -0,0 +1,1257 @@ +// +// Licensed to the Apache Software Foundation (ASF) under one or more +// contributor license agreements. See the NOTICE file distributed with +// this work for additional information regarding copyright ownership. +// The ASF licenses this file to You under the Apache License, Version 2.0 +// (the "License"); you may not use this file except in compliance with +// the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, software +// distributed under the License is distributed on an "AS IS" BASIS, +// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +// See the License for the specific language governing permissions and +// limitations under the License. +// += Apache NiFi Toolkit Guide +Apache NiFi Team +:homepage: http://nifi.apache.org +:linkattrs: + +== Overview +The NiFi Toolkit contains several command line utilities to setup and support NiFi in standalone and clustered environments. The utilities include: + +* CLI -- The `cli` tool enables administrators to interact with NiFi and NiFi Registry instances to automate tasks such as deploying versioned flows and managing process groups and cluster nodes. +* Encrypt Config -- The `encrypt-config` tool encrypts the sensitive keys in the _nifi.properties_ file to facilitate the setup of a secure NiFi instance. +* File Manager -- The `file-manager` tool enables administrators to backup, install or restore a NiFi installation from backup. +* Flow Analyzer -- The `flow-analyzer` tool produces a report that helps administrators understand the max amount of data which can be stored in backpressure for a given flow. +* Node Manager -- The `node-manager` tool enables administrators to perform status checks on nodes as well as the ability to connect, disconnect, or remove nodes from the cluster. +* Notify -- The `notify` tool enables administrators to send bulletins to the NiFi UI. +* S2S -- The `s2s` tool enables administrators to send data into or out of NiFi flows over site-to-site. +* TLS Toolkit -- The `tls-toolkit` utility generates the required keystores, truststore, and relevant configuration files to facilitate the setup of a secure NiFi instance. +* ZooKeeper Migrator -- The `zk-migrator` tool enables administrators to: +** move ZooKeeper information from one ZooKeeper cluster to another +** migrate ZooKeeper node ownership + +The utilities are executed with scripts found in the `bin` folder of your NiFi Toolkit installation. + +NOTE: The NiFi Toolkit is downloaded separately from NiFi (see the link:https://nifi.apache.org/download.html[Apache NiFi downloads page^]). + +=== Prerequisites for Running in a Secure Environment +For secured nodes and clusters, two policies should be configured in advance: + +* Access the controller â A user that will have access to these utilities should be authorized in NiFi by creating an âaccess the controllerâ policy (`/controller`) with both view and modify rights +* Proxy user request â If not previously set, nodeâs identity (the DN value of the nodeâs certificate) should be authorized to proxy requests on behalf of a user + +When executing either the Notify or Node Manager tools in a secured environment the `proxyDN` flag option should be used in order to properly identify the user that was authorized to execute these commands. In non-secure environments, or if running the status operation on the Node Manager tool, the flag is ignored. + +== NiFi CLI +This tool offers a CLI focused on interacting with NiFi and NiFi Registry in order to automate tasks, such as deploying flows from a NIFi Registy to a NiFi instance or managing process groups and cluster nodes. + +=== Usage +The CLI toolkit can be executed in standalone mode to execute a single command, or interactive mode to enter an interactive shell. + +To execute a single command: + + ./bin/cli.sh + +To launch the interactive shell: + + ./bin/cli.sh + +To show help: + + cli.sh -h --- End diff -- Do you think we should preface every help command example in the doc with "./bin/"? I can make those changes. ---
[GitHub] nifi-registry pull request #145: NIFIREG-210 Corrected incorrect document-li...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi-registry/pull/145 NIFIREG-210 Corrected incorrect document-links You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi-registry NIFIREG-210 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi-registry/pull/145.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #145 commit 3013d5f6fe498a42f0f3d943f3ca3d0695be3d50 Author: Andrew Lim Date: 2018-11-01T20:23:11Z NIFIREG-210 Corrected incorrect document-links ---
[GitHub] nifi pull request #3124: NIFI-5767 Added NiFi Toolkit Guide to docs
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi/pull/3124 NIFI-5767 Added NiFi Toolkit Guide to docs You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi NIFI-5767 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/3124.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3124 commit 060a4c5ccaf1b30f01dc3374edb2b69bb0f8833a Author: Andrew Lim Date: 2018-11-01T18:36:38Z NIFI-5767 Added NiFi Toolkit Guide to docs ---
[GitHub] nifi pull request #3115: NIFI-5766 Make formatting in User Guide consistent ...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi/pull/3115 NIFI-5766 Make formatting in User Guide consistent with Admin Guide Also added a new image for the Export a Template section. Improved iconDetails.png. You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi NIFI-5766 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/3115.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3115 commit 13a879725c301e35d9ad6fcc3f73569cf728197b Author: Andrew Lim Date: 2018-10-30T15:46:32Z NIFI-5766 Make formatting in User Guide consistent with Admin Guide ---
[GitHub] nifi-minifi pull request #140: MINIFI-473 Formatted Admin Guide and Java Qui...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi-minifi/pull/140 MINIFI-473 Formatted Admin Guide and Java Quick Start Guide to be con⦠â¦sistent with NiFi docs Also made some edits for readability and minor errors You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi-minifi MINIFI-473 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi-minifi/pull/140.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #140 commit ee99654ddaf6cea4aba78992f86107606c0dfc74 Author: Andrew Lim Date: 2018-10-29T15:51:54Z MINIFI-473 Formatted Admin Guide and Java Quick Start Guide to be consistent with NiFi docs ---
[GitHub] nifi pull request #3089: NIFI-5653 Added default NiFi and Embedded Zookeeper...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3089#discussion_r226055225 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -73,9 +73,38 @@ When NiFi first starts up, the following files and directories are created: See the <> section of this guide for more information about configuring NiFi repositories and configuration files. +== Port Configuration + +=== NiFi +The following table lists the default ports used by NiFi and the corresponding property in the _nifi.properties_ file. + +[options="header,footer"] +|== +| Function| Property | Default Value +|HTTP Port| `nifi.web.http.port` | `8080` +|HTTPS Port* | `nifi.web.https.port` | `9443` +|Remote Input Socket Port*| `nifi.remote.input.socket.port` | `10443` +|Cluster Node Protocol Port* | `nifi.cluster.node.protocol.port` | `11443` +|Cluster Node Load Balancing Port | `nifi.cluster.node.load.balance.port` | `6342` +|Web HTTP Forwarding Port | `nifi.web.http.port.forwarding` | blank +|== + +NOTE: The ports marked with an asterisk (*) have property values that are blank by default in _nifi.properties_. The values shown in the table are the default values for these ports when <> is used to generate _nifi.properties_ for a secured NiFi instance. The default Certificate Authority Port used by TLS Toolkit is `8443`. --- End diff -- Yup, will make _none_ in the tables. ---
[GitHub] nifi pull request #3089: NIFI-5653 Added default NiFi and Embedded Zookeeper...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3089#discussion_r226053244 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -73,9 +73,38 @@ When NiFi first starts up, the following files and directories are created: See the <> section of this guide for more information about configuring NiFi repositories and configuration files. +== Port Configuration + +=== NiFi +The following table lists the default ports used by NiFi and the corresponding property in the _nifi.properties_ file. + +[options="header,footer"] +|== +| Function| Property | Default Value +|HTTP Port| `nifi.web.http.port` | `8080` +|HTTPS Port* | `nifi.web.https.port` | `9443` +|Remote Input Socket Port*| `nifi.remote.input.socket.port` | `10443` +|Cluster Node Protocol Port* | `nifi.cluster.node.protocol.port` | `11443` +|Cluster Node Load Balancing Port | `nifi.cluster.node.load.balance.port` | `6342` +|Web HTTP Forwarding Port | `nifi.web.http.port.forwarding` | blank --- End diff -- As discussed in other comment threads, changing blank to _none_. ---
[GitHub] nifi pull request #3089: NIFI-5653 Added default NiFi and Embedded Zookeeper...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3089#discussion_r226053061 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -73,9 +73,38 @@ When NiFi first starts up, the following files and directories are created: See the <> section of this guide for more information about configuring NiFi repositories and configuration files. +== Port Configuration + +=== NiFi +The following table lists the default ports used by NiFi and the corresponding property in the _nifi.properties_ file. + +[options="header,footer"] +|== +| Function| Property | Default Value +|HTTP Port| `nifi.web.http.port` | `8080` +|HTTPS Port* | `nifi.web.https.port` | `9443` +|Remote Input Socket Port*| `nifi.remote.input.socket.port` | `10443` +|Cluster Node Protocol Port* | `nifi.cluster.node.protocol.port` | `11443` +|Cluster Node Load Balancing Port | `nifi.cluster.node.load.balance.port` | `6342` +|Web HTTP Forwarding Port | `nifi.web.http.port.forwarding` | blank +|== + +NOTE: The ports marked with an asterisk (*) have property values that are blank by default in _nifi.properties_. The values shown in the table are the default values for these ports when <> is used to generate _nifi.properties_ for a secured NiFi instance. The default Certificate Authority Port used by TLS Toolkit is `8443`. + +=== Embedded Zookeeper +The following table lists the default ports used by an <> and the corresponding property in the _zookeeper.properties_ file. + +[options="header,footer"] +|== +| Function | Property | Default Value +|Zookeeper Client Port | `clientPort` | `2181` +|Zookeeper Server Quorum and Leader Election Ports | `server.1` | `localhost:2888:3888` --- End diff -- Thanks, will make this change also. ---
[GitHub] nifi pull request #3089: NIFI-5653 Added default NiFi and Embedded Zookeeper...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3089#discussion_r226045546 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -73,9 +73,38 @@ When NiFi first starts up, the following files and directories are created: See the <> section of this guide for more information about configuring NiFi repositories and configuration files. +== Port Configuration + +=== NiFi +The following table lists the default ports used by NiFi and the corresponding property in the _nifi.properties_ file. + +[options="header,footer"] +|== +| Function| Property | Default Value +|HTTP Port| `nifi.web.http.port` | `8080` +|HTTPS Port* | `nifi.web.https.port` | `9443` +|Remote Input Socket Port*| `nifi.remote.input.socket.port` | `10443` +|Cluster Node Protocol Port* | `nifi.cluster.node.protocol.port` | `11443` +|Cluster Node Load Balancing Port | `nifi.cluster.node.load.balance.port` | `6342` +|Web HTTP Forwarding Port | `nifi.web.http.port.forwarding` | blank +|== + +NOTE: The ports marked with an asterisk (*) have property values that are blank by default in _nifi.properties_. The values shown in the table are the default values for these ports when <> is used to generate _nifi.properties_ for a secured NiFi instance. The default Certificate Authority Port used by TLS Toolkit is `8443`. + +=== Embedded Zookeeper +The following table lists the default ports used by an <> and the corresponding property in the _zookeeper.properties_ file. + +[options="header,footer"] +|== +| Function | Property | Default Value +|Zookeeper Client Port | `clientPort` | `2181` +|Zookeeper Server Quorum and Leader Election Ports | `server.1` | `localhost:2888:3888` --- End diff -- I see your point. We could change the table and following note to this: | Function | Property | Default Value |Zookeeper Client Port | `clientPort` | `2181` |Zookeeper Server Quorum and Leader Election Ports | `server.1` | blank NOTE: Commented examples for the Zookeeper server ports are included in the _zookeeper.properties_ file in the form server.N=nifi-nodeN-hostname:2888:3888. ---
[GitHub] nifi pull request #3089: NIFI-5653 Added default NiFi and Embedded Zookeeper...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3089#discussion_r226042799 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -73,9 +73,38 @@ When NiFi first starts up, the following files and directories are created: See the <> section of this guide for more information about configuring NiFi repositories and configuration files. +== Port Configuration + +=== NiFi +The following table lists the default ports used by NiFi and the corresponding property in the _nifi.properties_ file. + +[options="header,footer"] +|== +| Function| Property | Default Value +|HTTP Port| `nifi.web.http.port` | `8080` +|HTTPS Port* | `nifi.web.https.port` | `9443` +|Remote Input Socket Port*| `nifi.remote.input.socket.port` | `10443` +|Cluster Node Protocol Port* | `nifi.cluster.node.protocol.port` | `11443` +|Cluster Node Load Balancing Port | `nifi.cluster.node.load.balance.port` | `6342` +|Web HTTP Forwarding Port | `nifi.web.http.port.forwarding` | blank +|== + +NOTE: The ports marked with an asterisk (*) have property values that are blank by default in _nifi.properties_. The values shown in the table are the default values for these ports when <> is used to generate _nifi.properties_ for a secured NiFi instance. The default Certificate Authority Port used by TLS Toolkit is `8443`. --- End diff -- Similar to comment above about "blank", but happy to make this change since it reads better. ---
[GitHub] nifi pull request #3089: NIFI-5653 Added default NiFi and Embedded Zookeeper...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3089#discussion_r226042448 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -73,9 +73,38 @@ When NiFi first starts up, the following files and directories are created: See the <> section of this guide for more information about configuring NiFi repositories and configuration files. +== Port Configuration + +=== NiFi +The following table lists the default ports used by NiFi and the corresponding property in the _nifi.properties_ file. + +[options="header,footer"] +|== +| Function| Property | Default Value +|HTTP Port| `nifi.web.http.port` | `8080` +|HTTPS Port* | `nifi.web.https.port` | `9443` +|Remote Input Socket Port*| `nifi.remote.input.socket.port` | `10443` +|Cluster Node Protocol Port* | `nifi.cluster.node.protocol.port` | `11443` +|Cluster Node Load Balancing Port | `nifi.cluster.node.load.balance.port` | `6342` +|Web HTTP Forwarding Port | `nifi.web.http.port.forwarding` | blank --- End diff -- I was thinking about that also, but figured "blank" would be OK since we reference this throughout the Admin Guide (e.g. "The default value is blank"). ---
[GitHub] nifi pull request #3089: NIFI-5653 Added default NiFi and Embedded Zookeeper...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi/pull/3089 NIFI-5653 Added default NiFi and Embedded Zookeeper port tables to Ad⦠â¦min Guide Also added a new referenced tag/anchor for TLS Generation Toolkit section and removed an unnecessary NOTE. You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi NIFI-5653 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/3089.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3089 commit 56281924149503e84117dc377d94490f953c99f2 Author: Andrew Lim Date: 2018-10-17T17:43:39Z NIFI-5653 Added default NiFi and Embedded Zookeeper port tables to Admin Guide ---
[GitHub] nifi pull request #3080: NIFI-5701 Add documentation for Load Balancing conn...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3080#discussion_r225687626 --- Diff: nifi-docs/src/main/asciidoc/user-guide.adoc --- @@ -986,13 +991,11 @@ automatically be 'cloned', and a copy will be sent to each of those Connections. Settings -The Settings Tab provides the ability to configure the Connection's name, FlowFile expiration, Back Pressure thresholds, and -Prioritization: +The Settings Tab provides the ability to configure the Connection's Name, FlowFile Expiration, Back Pressure Thresholds, Load Balance Strategy and Prioritization: --- End diff -- Sounds good ---
[GitHub] nifi pull request #3080: NIFI-5701 Add documentation for Load Balancing conn...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3080#discussion_r225685340 --- Diff: nifi-docs/src/main/asciidoc/user-guide.adoc --- @@ -986,13 +991,11 @@ automatically be 'cloned', and a copy will be sent to each of those Connections. Settings -The Settings Tab provides the ability to configure the Connection's name, FlowFile expiration, Back Pressure thresholds, and -Prioritization: +The Settings Tab provides the ability to configure the Connection's Name, FlowFile Expiration, Back Pressure Thresholds, Load Balance Strategy and Prioritization: --- End diff -- There are other instances in the doc where tab is capitalized similarly: -Line 641 "Scheduling Tab" -Line 680 "Properties Tab" -Line 681 "Properties Tab" -Line 981 "Details Tab" But other instances where it is not capitalized: -Lines 716 & 717 "Comments tab" I'm OK with either style, but we should be consistent. So if you like the non-capitalized versions, we need to edit the 4 other instances I noted above. ---
[GitHub] nifi pull request #3080: NIFI-5701 Add documentation for Load Balancing conn...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi/pull/3080 NIFI-5701 Add documentation for Load Balancing connections to User Gu⦠â¦ide and add additional properties to Admin Guide Also updated some existing screenshots and did some reformatting of some titles. You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi NIFI-5701 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/3080.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3080 commit 652146287bd7c6ea8fc73fef8755d3b91fa87413 Author: Andrew Lim Date: 2018-10-16T16:06:31Z NIFI-5701 Add documentation for Load Balancing connections to User Guide and add additional properties to Admin Guide ---
[GitHub] nifi pull request #3056: NIFI-5659 Add documentation for Offloading Nodes fu...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3056#discussion_r225181107 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -3939,8 +3976,7 @@ to the cluster. It provides an additional layer of security. This value is blank |`nifi.cluster.flow.election.max.candidates`|Specifies the number of Nodes required in the cluster to cause early election of Flows. This allows the Nodes in the cluster to avoid having to wait a long time before starting processing if we reach at least this number of nodes in the cluster. |`nifi.cluster.load.balance.port`|Specifies the port to listen on for incoming connections for load balancing data across the cluster. The default value is `6342`. --- End diff -- Just noting that the default value is 6342 not 6432. ---
[GitHub] nifi pull request #3056: NIFI-5659 Add documentation for Offloading Nodes fu...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3056#discussion_r224161590 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2393,19 +2395,53 @@ When the DFM makes changes to the dataflow, the node that receives the request t nodes and waits for each node to respond, indicating that it has made the change on its local flow. -*Dealing with Disconnected Nodes* + +=== Managing Nodes + + Disconnect Nodes + +A DFM may manually disconnect a node from the cluster. A node may also become disconnected for other reasons, such as due to a lack of heartbeat. The Cluster Coordinator will show a bulletin on the User Interface when a node is disconnected. The DFM will not be able to make any changes to the dataflow until the issue of the disconnected node is resolved. The DFM or the Administrator will need to troubleshoot the issue with the node and resolve it before any new changes can be made to the dataflow. However, it is worth noting that just because a node is disconnected does not mean that it is not working. This may happen for a few reasons, for example when the node is unable to communicate with the Cluster Coordinator due to network problems. + +To manually disconnect a node, select the "Disconnect" icon (image:iconDisconnect.png["Disconnect Icon"]) from the node's row. + +image::disconnected-node-cluster-mgt.png["Disconnected Node in Cluster Management UI"] + +A disconnected node can be connected (image:iconConnect.png["Connect Icon"]), offloaded (image:iconOffload.png["Offload Icon"]) or deleted (image:iconDelete.png["Delete Icon"]). --- End diff -- I like your version. Let's run with that. ---
[GitHub] nifi pull request #3056: NIFI-5659 Add documentation for Offloading Nodes fu...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3056#discussion_r224156171 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2393,19 +2395,53 @@ When the DFM makes changes to the dataflow, the node that receives the request t nodes and waits for each node to respond, indicating that it has made the change on its local flow. -*Dealing with Disconnected Nodes* + +=== Managing Nodes + + Disconnect Nodes + +A DFM may manually disconnect a node from the cluster. A node may also become disconnected for other reasons, such as due to a lack of heartbeat. The Cluster Coordinator will show a bulletin on the User Interface when a node is disconnected. The DFM will not be able to make any changes to the dataflow until the issue of the disconnected node is resolved. The DFM or the Administrator will need to troubleshoot the issue with the node and resolve it before any new changes can be made to the dataflow. However, it is worth noting that just because a node is disconnected does not mean that it is not working. This may happen for a few reasons, for example when the node is unable to communicate with the Cluster Coordinator due to network problems. + +To manually disconnect a node, select the "Disconnect" icon (image:iconDisconnect.png["Disconnect Icon"]) from the node's row. + +image::disconnected-node-cluster-mgt.png["Disconnected Node in Cluster Management UI"] + +A disconnected node can be connected (image:iconConnect.png["Connect Icon"]), offloaded (image:iconOffload.png["Offload Icon"]) or deleted (image:iconDelete.png["Delete Icon"]). --- End diff -- OK. How about this then for the note: NOTE: Not all nodes in a "Disconnected" state can be offloaded. If the node is disconnected because the node died/lack of heartbeat, the offload operation will be unable to reach the node to start the offloading. Additionally, offloading may also be interrupted or prevented due to firewall issues. ---
[GitHub] nifi pull request #3056: NIFI-5659 Add documentation for Offloading Nodes fu...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3056#discussion_r224134708 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2393,19 +2395,53 @@ When the DFM makes changes to the dataflow, the node that receives the request t nodes and waits for each node to respond, indicating that it has made the change on its local flow. -*Dealing with Disconnected Nodes* + +=== Managing Nodes + + Disconnect Nodes + +A DFM may manually disconnect a node from the cluster. A node may also become disconnected for other reasons, such as due to a lack of heartbeat. The Cluster Coordinator will show a bulletin on the User Interface when a node is disconnected. The DFM will not be able to make any changes to the dataflow until the issue of the disconnected node is resolved. The DFM or the Administrator will need to troubleshoot the issue with the node and resolve it before any new changes can be made to the dataflow. However, it is worth noting that just because a node is disconnected does not mean that it is not working. This may happen for a few reasons, for example when the node is unable to communicate with the Cluster Coordinator due to network problems. + +To manually disconnect a node, select the "Disconnect" icon (image:iconDisconnect.png["Disconnect Icon"]) from the node's row. + +image::disconnected-node-cluster-mgt.png["Disconnected Node in Cluster Management UI"] + +A disconnected node can be connected (image:iconConnect.png["Connect Icon"]), offloaded (image:iconOffload.png["Offload Icon"]) or deleted (image:iconDelete.png["Delete Icon"]). --- End diff -- Good points. My intent was to present the available choices provided by the UI for a disconnected node. Perhaps we can add a note to the end of this section that provides more of this error handling/troubleshooting information. NOTE: Not all nodes in a "Disconnected" state can be offloaded. If the node is disconnected because the node died/lack of heartbeat, the offload operation will be unable to reach the node to start the offloading. Additionally, offloading may also be interrupted or prevented due to firewall issues (e.g., if the load balancing port is blocked). ---
[GitHub] nifi pull request #3056: NIFI-5659 Add documentation for Offloading Nodes fu...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3056#discussion_r224099820 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2393,19 +2395,53 @@ When the DFM makes changes to the dataflow, the node that receives the request t nodes and waits for each node to respond, indicating that it has made the change on its local flow. -*Dealing with Disconnected Nodes* + +=== Managing Nodes + + Disconnect Nodes + +A DFM may manually disconnect a node from the cluster. A node may also become disconnected for other reasons, such as due to a lack of heartbeat. The Cluster Coordinator will show a bulletin on the User Interface when a node is disconnected. The DFM will not be able to make any changes to the dataflow until the issue of the disconnected node is resolved. The DFM or the Administrator will need to troubleshoot the issue with the node and resolve it before any new changes can be made to the dataflow. However, it is worth noting that just because a node is disconnected does not mean that it is not working. This may happen for a few reasons, for example when the node is unable to communicate with the Cluster Coordinator due to network problems. + +To manually disconnect a node, select the "Disconnect" icon (image:iconDisconnect.png["Disconnect Icon"]) from the node's row. + +image::disconnected-node-cluster-mgt.png["Disconnected Node in Cluster Management UI"] + +A disconnected node can be connected (image:iconConnect.png["Connect Icon"]), offloaded (image:iconOffload.png["Offload Icon"]) or deleted (image:iconDelete.png["Delete Icon"]). + + Offload Nodes + +Flowfiles that remain on a disconnected node can be rebalanced to other active nodes in the cluster via offloading. In the Cluster Management dialog, select the "Offload" icon (image:iconOffload.png["Offload Icon"]) for a Disconnected node. This will stop all processors, terminate all processors, stop transmitting on all remote process groups and rebalance flowfiles to the other connected nodes in the cluster. + +image::offloading-node-cluster-mgt.png["Offloading Node in Cluster Management UI"] + +Nodes that remain in "Offloading" state due to errors encountered (out of memory, no network connection, etc.) can be reconnected to the cluster by restarting NiFi on the node. Offloaded nodes can be either reconnected to the cluster (by selecting Connect or restarting NiFi on the node) or deleted from the cluster. + +image::offloaded-node-cluster-mgt.png["Offloaded Node in Cluster Management UI"] + + Delete Nodes + +There are cases where a DFM may wish to continue making changes to the flow, even though a node is not connected to the cluster. In this case, the DFM may elect to delete the node from the cluster entirely. In the Cluster Management dialog, select the "Delete" icon (image:iconDelete.png["Delete Icon"]) for a Disconnected or Offloaded node. Once deleted, the node cannot be rejoined to the cluster until it has been restarted. + + Decommission Nodes + +The steps to decommission a node and remove it from a cluster are as follows: + +1. Disconnect the node. +2. Once disconnect completes, offload the node. +3. Once offload completes, delete the node. +4. Once the delete request has finished, stop/remove the NiFi service on the host. + + NiFi Toolkit Node Commands -A DFM may manually disconnect a node from the cluster. But if a node becomes disconnected for any other reason (such as due to lack of heartbeat), -the Cluster Coordinator will show a bulletin on the User Interface. The DFM will not be able to make any changes to the dataflow until the issue -of the disconnected node is resolved. The DFM or the Administrator will need to troubleshoot the issue with the node and resolve it before any -new changes may be made to the dataflow. However, it is worth noting that just because a node is disconnected does not mean that it is not working; -this may happen for a few reasons, including that the node is unable to communicate with the Cluster Coordinator due to network problems. +As an alternative to the UI, the following NiFi Toolkit CLI commands can be used for retrieving a single node, retrieving a list of nodes, and connecting/disconnecting/offloading/deleting nodes: -There are cases where a DFM may wish to continue making changes to the flow, even though a node is not connected to the cluster. -In this case, they DFM may elect to remove the node from the cluster entirely through the Cluster Management dialog. Once removed, -the node cannot be rejoined to the cluster un
[GitHub] nifi pull request #3056: NIFI-5659 Add documentation for Offloading Nodes fu...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3056#discussion_r223917872 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2393,19 +2395,53 @@ When the DFM makes changes to the dataflow, the node that receives the request t nodes and waits for each node to respond, indicating that it has made the change on its local flow. -*Dealing with Disconnected Nodes* + +=== Managing Nodes + + Disconnect Nodes + +A DFM may manually disconnect a node from the cluster. A node may also become disconnected for other reasons, such as due to a lack of heartbeat. The Cluster Coordinator will show a bulletin on the User Interface when a node is disconnected. The DFM will not be able to make any changes to the dataflow until the issue of the disconnected node is resolved. The DFM or the Administrator will need to troubleshoot the issue with the node and resolve it before any new changes can be made to the dataflow. However, it is worth noting that just because a node is disconnected does not mean that it is not working. This may happen for a few reasons, for example when the node is unable to communicate with the Cluster Coordinator due to network problems. + +To manually disconnect a node, select the "Disconnect" icon (image:iconDisconnect.png["Disconnect Icon"]) from the node's row. + +image::disconnected-node-cluster-mgt.png["Disconnected Node in Cluster Management UI"] + +A disconnected node can be connected (image:iconConnect.png["Connect Icon"]), offloaded (image:iconOffload.png["Offload Icon"]) or deleted (image:iconDelete.png["Delete Icon"]). + + Offload Nodes + +Flowfiles that remain on a disconnected node can be rebalanced to other active nodes in the cluster via offloading. In the Cluster Management dialog, select the "Offload" icon (image:iconOffload.png["Offload Icon"]) for a Disconnected node. This will stop all processors, terminate all processors, stop transmitting on all remote process groups and rebalance flowfiles to the other connected nodes in the cluster. + +image::offloading-node-cluster-mgt.png["Offloading Node in Cluster Management UI"] + +Nodes that remain in "Offloading" state due to errors encountered (out of memory, no network connection, etc.) can be reconnected to the cluster by restarting NiFi on the node. Offloaded nodes can be either reconnected to the cluster (by selecting Connect or restarting NiFi on the node) or deleted from the cluster. + +image::offloaded-node-cluster-mgt.png["Offloaded Node in Cluster Management UI"] + + Delete Nodes + +There are cases where a DFM may wish to continue making changes to the flow, even though a node is not connected to the cluster. In this case, the DFM may elect to delete the node from the cluster entirely. In the Cluster Management dialog, select the "Delete" icon (image:iconDelete.png["Delete Icon"]) for a Disconnected or Offloaded node. Once deleted, the node cannot be rejoined to the cluster until it has been restarted. + + Decommission Nodes + +The steps to decommission a node and remove it from a cluster are as follows: + +1. Disconnect the node. +2. Once disconnect completes, offload the node. +3. Once offload completes, delete the node. +4. Once the delete request has finished, stop/remove the NiFi service on the host. + + NiFi Toolkit Node Commands -A DFM may manually disconnect a node from the cluster. But if a node becomes disconnected for any other reason (such as due to lack of heartbeat), -the Cluster Coordinator will show a bulletin on the User Interface. The DFM will not be able to make any changes to the dataflow until the issue -of the disconnected node is resolved. The DFM or the Administrator will need to troubleshoot the issue with the node and resolve it before any -new changes may be made to the dataflow. However, it is worth noting that just because a node is disconnected does not mean that it is not working; -this may happen for a few reasons, including that the node is unable to communicate with the Cluster Coordinator due to network problems. +As an alternative to the UI, the following NiFi Toolkit CLI commands can be used for retrieving a single node, retrieving a list of nodes, and connecting/disconnecting/offloading/deleting nodes: -There are cases where a DFM may wish to continue making changes to the flow, even though a node is not connected to the cluster. -In this case, they DFM may elect to remove the node from the cluster entirely through the Cluster Management dialog. Once removed, -the node cannot be rejoined to the clu
[GitHub] nifi pull request #3056: NIFI-5659 Add documentation for Offloading Nodes fu...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi/pull/3056 NIFI-5659 Add documentation for Offloading Nodes functionality and ne⦠â¦w Node related CLI commands You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi NIFI-5659 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/3056.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3056 commit 80d49e2f15b84fd59ae83229bc05af5c9d8d1f5d Author: Andrew Lim Date: 2018-10-09T20:31:56Z NIFI-5659 Add documentation for Offloading Nodes functionality and new Node related CLI commands ---
[GitHub] nifi pull request #2947: [WIP] NIFI-5516: Implement Load-Balanced Connection...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2947#discussion_r222402579 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -3929,6 +3929,13 @@ from the remote node before considering the communication with the node a failur to the cluster. It provides an additional layer of security. This value is blank by default, meaning that no firewall file is to be used. |`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 the number specified by the `nifi.cluster.flow.election.max.candidates` property, the cluster will not wait this long. The default value is `5 mins`. Note that the time starts as soon as the first vote is cast. |`nifi.cluster.flow.election.max.candidates`|Specifies the number of Nodes required in the cluster to cause early election of Flows. This allows the Nodes in the cluster to avoid having to wait a long time before starting processing if we reach at least this number of nodes in the cluster. +|`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 the number specified + by the `nifi.cluster.flow.election.max.candidates` property, the cluster will not wait this long. The default value is `5 mins`. Note that the time starts as soon as the first vote is cast. +|`nifi.cluster.flow.election.max.candidates`|Specifies the number of Nodes required in the cluster to cause early election of Flows. This allows the Nodes in the cluster to avoid having to wait a +long time before starting processing if we reach at least this number of nodes in the cluster. +|`nifi.cluster.load.balance.port`|Specifies the port to listen on for incoming connections for load balancing data across the cluster. The default value is `6342`.| --- End diff -- Should remove the "|" at the end of line 3936. Causes incorrect formatting of the property following it. ---
[GitHub] nifi pull request #3010: [WIP] NIFI-5585
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/3010#discussion_r222397907 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -3929,6 +3929,13 @@ from the remote node before considering the communication with the node a failur to the cluster. It provides an additional layer of security. This value is blank by default, meaning that no firewall file is to be used. |`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 the number specified by the `nifi.cluster.flow.election.max.candidates` property, the cluster will not wait this long. The default value is `5 mins`. Note that the time starts as soon as the first vote is cast. |`nifi.cluster.flow.election.max.candidates`|Specifies the number of Nodes required in the cluster to cause early election of Flows. This allows the Nodes in the cluster to avoid having to wait a long time before starting processing if we reach at least this number of nodes in the cluster. +|`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 the number specified + by the `nifi.cluster.flow.election.max.candidates` property, the cluster will not wait this long. The default value is `5 mins`. Note that the time starts as soon as the first vote is cast. +|`nifi.cluster.flow.election.max.candidates`|Specifies the number of Nodes required in the cluster to cause early election of Flows. This allows the Nodes in the cluster to avoid having to wait a +long time before starting processing if we reach at least this number of nodes in the cluster. +|`nifi.cluster.load.balance.port`|Specifies the port to listen on for incoming connections for load balancing data across the cluster. The default value is `6342`.| +|`nifi.cluster.load.balance.host`|Specifies the hostname to listen on for incoming connections for load balancing data across the cluster. If not specified, will default to the value used by the `nifi --- End diff -- The formatting in the table is off because the "|" at the end of line 3936 is not needed. ---
[GitHub] nifi pull request #3017: NIFI-5578 Correct errors in EL Guide including Date...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi/pull/3017 NIFI-5578 Correct errors in EL Guide including Date Manipulation and ⦠â¦Escaping EL examples Also fixed some formatting typos You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi NIFI-5578 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/3017.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3017 commit efe3d1928c0b3c25754789dc6683606051e5aa2e Author: Andrew Lim Date: 2018-09-20T14:40:49Z NIFI-5578 Correct errors in EL Guide including Date Manipulation and Escaping EL examples ---
[GitHub] nifi pull request #2975: NIFI-5526 Improve PutS3Object processor documentati...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi/pull/2975 NIFI-5526 Improve PutS3Object processor documentation You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi NIFI-5526 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2975.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2975 commit 4e0d9e6f3826f68cfc33082079475e86f1640f63 Author: Andrew Lim Date: 2018-08-29T17:24:22Z NIFI-5526 Improve PutS3Object processor documentation ---
[GitHub] nifi-site pull request #29: NIFIREG-195 Add GitFlowPersistenceProvider video...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi-site/pull/29 NIFIREG-195 Add GitFlowPersistenceProvider video to Registry home page You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi-site NIFIREG-195 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi-site/pull/29.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #29 commit d39b57602c5545a4dee2c7094c9bd6dc83316816 Author: Andrew Lim Date: 2018-03-13T15:04:51Z NIFIREG-151 Add tutorial videos to Registry home page commit a11dd344ff09ed1cb9589ca8d025d45f3e5a392b Author: Andrew Lim Date: 2018-08-15T18:34:06Z Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/nifi-site commit 10b5572228ea476c5bbe6849a1fe41487ebc8407 Author: Andrew Lim Date: 2018-08-15T18:50:14Z NIFIREG-195 Add GitFlowPersistenceProvider video to Registry home page ---
[GitHub] nifi-registry pull request #137: NIFIREG-191 Make formatting consistent in R...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi-registry/pull/137 NIFIREG-191 Make formatting consistent in Registry docs and minor fixes You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi-registry NIFIREG-191 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi-registry/pull/137.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #137 commit ba83adf06a1f4920fda7143e2e6791dd23b04790 Author: Andrew Lim Date: 2018-08-15T18:17:51Z NIFIREG-191 Make formatting consistent in Registry docs and minor fixes ---
[GitHub] nifi pull request #2925: NIFI-5469 Additional italics and code formatting co...
Github user andrewmlim commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2925#discussion_r209305557
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -3256,9 +3361,9 @@ stream {
image:s2s-rproxy-portnumber.svg["Port number to Node mapping"]
--- End diff --
Thanks @zenfenan . Added a commit with that fix.
---
[GitHub] nifi pull request #2925: NIFI-5469 Additional italics and code formatting co...
Github user andrewmlim commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2925#discussion_r208248950
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -3256,9 +3361,9 @@ stream {
image:s2s-rproxy-portnumber.svg["Port number to Node mapping"]
--- End diff --
While editing a doc (administration-guide.adoc, overview.adoc, etc.), the
screenshots won't load unless the image files are in the same directory as the
doc. But, once the docs are build the screenshots will be referenced properly:
---
[GitHub] nifi issue #2925: NIFI-5469 Additional italics and code formatting correctio...
Github user andrewmlim commented on the issue: https://github.com/apache/nifi/pull/2925 Thanks for reviewing @zenfenan ! ---
[GitHub] nifi pull request #2925: NIFI-5469 Additional italics and code formatting co...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2925#discussion_r208012356 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -1486,35 +1588,35 @@ 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. --- End diff -- Good catch. Will update. ---
[GitHub] nifi pull request #2925: NIFI-5469 Additional italics and code formatting co...
Github user andrewmlim commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2925#discussion_r208012302
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -3256,9 +3361,9 @@ stream {
image:s2s-rproxy-portnumber.svg["Port number to Node mapping"]
--- End diff --
Hi @zenfenan,
Can you clarify what you mean by "aren't loading properly"? I'm trying to
understand what is broken since the screenshots are properly displayed in the
generated docs.
---
[GitHub] nifi pull request #2927: NIFI-5473 Added section on using external signed CA...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2927#discussion_r206707072 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -281,6 +281,272 @@ After running the client you will have the CAâs certificate, a keystore, a tru For a client certificate that can be easily imported into the browser, specify: `-T PKCS12` + Using An Existing Intermediate Certificate Authority (CA) + +In some enterprise scenarios, a security/IT team may provide a signing certificate that has already been signed by the organization's certificate authority (CA). This *intermediate CA* can be used to sign the *node* (sometimes referred to as *leaf*) certificates that will be installed on each NiFi node. In order to inject the existing signing certificate into the toolkit process, follow these steps: + +. Generate or obtain the signed intermediate CA keys in the following format (see additional commands below): + * Public certificate in PEM format: `nifi-cert.pem` + * Private key in PEM format: `nifi-key.key` +. Place the files in the *toolkit directory*. This is the directory where the tool binary (usually called via the invoking script `tls-toolkit.sh` or `tls-toolkit.bat`) is configured to output the signed certificates. *This is not necessarily the directory where the binary is located or invoked*. + * For example, given the following scenario, the toolkit command can be run from its location as long as the output directory `-o` is `../hardcoded/`, and the existing `nifi-cert.pem` and `nifi-key.key` will be used. + ** e.g. `$ ./toolkit/bin/tls-toolkit.sh standalone -o ./hardcoded/ -n 'node4.nifi.apache.org' -P thisIsABadPassword -S thisIsABadPassword -O` will result in a new directory at `./hardcoded/node4.nifi.apache.org` with a keystore and truststore containing a certificate signed by `./hardcoded/nifi-key.key` + * If the `-o` argument is not provided, the default working directory (`.`) must contain `nifi-cert.pem` and `nifi-key.key` + ** e.g. `$ cd ./hardcoded/ && ../toolkit/bin/tls-toolkit.sh standalone -n 'node5.nifi.apache.org' -P thisIsABadPassword -S thisIsABadPassword -O` + +``` +ð 0s @ 18:07:58 $ tree -L 2 +. +âââ hardcoded +â  âââ CN=myusername.hardcoded_OU=NiFi.p12 +â  âââ CN=myusername.hardcoded_OU=NiFi.password +â  âââ nifi-cert.pem +â  âââ nifi-key.key +â  âââ node1.nifi.apache.org +â  âââ node2.nifi.apache.org +â  âââ node3.nifi.apache.org +âââ toolkit +   âââ LICENSE +   âââ NOTICE +   âââ README +   âââ bin +   âââ conf +   âââ docs +   âââ lib +``` + += Additional Commands + +The `nifi-cert.pem` and `nifi-key.key` files should be ASCII-armored (Base64-encoded ASCII) files containing the CA public certificate and private key respectively. Examples: --- End diff -- No, I just meant elaborate so "Examples" is a quick sentence summarizing what they show. Not critical. ---
[GitHub] nifi issue #2927: NIFI-5473 Added section on using external signed CA for TL...
Github user andrewmlim commented on the issue: https://github.com/apache/nifi/pull/2927 Reviewed and added my comments. Looks good overall. +1 to changing the TOC level to 3. ---
[GitHub] nifi pull request #2927: NIFI-5473 Added section on using external signed CA...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2927#discussion_r206591826 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -166,7 +166,7 @@ In order to facilitate the secure setup of NiFi, you can use the `tls-toolkit` c 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: + Potential issues with wildcard certificates: --- End diff -- With the TOC Level Set to 3, should change this to: Potential Issues with Wildcard Certificates ---
[GitHub] nifi pull request #2927: NIFI-5473 Added section on using external signed CA...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2927#discussion_r206584091 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -281,6 +281,272 @@ After running the client you will have the CAâs certificate, a keystore, a tru For a client certificate that can be easily imported into the browser, specify: `-T PKCS12` + Using An Existing Intermediate Certificate Authority (CA) + +In some enterprise scenarios, a security/IT team may provide a signing certificate that has already been signed by the organization's certificate authority (CA). This *intermediate CA* can be used to sign the *node* (sometimes referred to as *leaf*) certificates that will be installed on each NiFi node. In order to inject the existing signing certificate into the toolkit process, follow these steps: + +. Generate or obtain the signed intermediate CA keys in the following format (see additional commands below): + * Public certificate in PEM format: `nifi-cert.pem` + * Private key in PEM format: `nifi-key.key` +. Place the files in the *toolkit directory*. This is the directory where the tool binary (usually called via the invoking script `tls-toolkit.sh` or `tls-toolkit.bat`) is configured to output the signed certificates. *This is not necessarily the directory where the binary is located or invoked*. + * For example, given the following scenario, the toolkit command can be run from its location as long as the output directory `-o` is `../hardcoded/`, and the existing `nifi-cert.pem` and `nifi-key.key` will be used. + ** e.g. `$ ./toolkit/bin/tls-toolkit.sh standalone -o ./hardcoded/ -n 'node4.nifi.apache.org' -P thisIsABadPassword -S thisIsABadPassword -O` will result in a new directory at `./hardcoded/node4.nifi.apache.org` with a keystore and truststore containing a certificate signed by `./hardcoded/nifi-key.key` + * If the `-o` argument is not provided, the default working directory (`.`) must contain `nifi-cert.pem` and `nifi-key.key` + ** e.g. `$ cd ./hardcoded/ && ../toolkit/bin/tls-toolkit.sh standalone -n 'node5.nifi.apache.org' -P thisIsABadPassword -S thisIsABadPassword -O` + +``` +ð 0s @ 18:07:58 $ tree -L 2 +. +âââ hardcoded +â  âââ CN=myusername.hardcoded_OU=NiFi.p12 +â  âââ CN=myusername.hardcoded_OU=NiFi.password +â  âââ nifi-cert.pem +â  âââ nifi-key.key +â  âââ node1.nifi.apache.org +â  âââ node2.nifi.apache.org +â  âââ node3.nifi.apache.org +âââ toolkit +   âââ LICENSE +   âââ NOTICE +   âââ README +   âââ bin +   âââ conf +   âââ docs +   âââ lib +``` + += Additional Commands + +The `nifi-cert.pem` and `nifi-key.key` files should be ASCII-armored (Base64-encoded ASCII) files containing the CA public certificate and private key respectively. Examples: + +``` +# The first command shows the actual content of the encoded file, and the second parses it and shows the internal values + +.../certs $ more nifi-cert.pem +-BEGIN CERTIFICATE- +MIIDZTCCAk2gAwIBAgIKAWTeM3kDADANBgkqhkiG9w0BAQsFADAxMQ0wCwYD +VQQLDAROSUZJMSAwHgYDVQQDDBduaWZpLWNhLm5pZmkuYXBhY2hlLm9yZzAeFw0x +ODA3MjgwMDA0MzJaFw0yMTA3MjcwMDA0MzJaMDExDTALBgNVBAsMBE5JRkkxIDAe +BgNVBAMMF25pZmktY2EubmlmaS5hcGFjaGUub3JnMIIBIjANBgkqhkiG9w0BAQEF +AAOCAQ8AMIIBCgKCAQEAqkVrrC+AkFbjnCpupSy84tTFDsRVUIWYj/k2pVwC145M +3bpr0pRCzLuzovAjFCmT5L+isTvNjhionsqif07Ebd/M2psYE/Rih2MULsX6KgRe +1nRUiBeKF08hlmSBMGDFPj39yDzE/V9edxV/KGjRqVgw/Qy0vwaS5uWdXnLDhzoV +4/Mz7lGmYoMasZ1uexlH93jjBl1+EFL2Xoa06oLbEojJ9TKaWhpG8ietEedf7WM0 +zqBEz2kHo9ddFk9yxiCkT4SUKnDWkhwc/o6us1vEXoSw+tmufHY/A3gVihjWPIGz +qyLFl9JuN7CyJepkVVqTdskBG7S85G/kBlizUj5jOwIDAQABo38wfTAOBgNVHQ8B +Af8EBAMCAf4wDAYDVR0TBAUwAwEB/zAdBgNVHQ4EFgQUKiWBKbMMQ1zUabD4gI7L +VOWOcy0wHwYDVR0jBBgwFoAUKiWBKbMMQ1zUabD4gI7LVOWOcy0wHQYDVR0lBBYw +FAYIKwYBBQUHAwIGCCsGAQUFBwMBMA0GCSqGSIb3DQEBCwUAA4IBAQAxfHFIZLOw +mwIqnSI/ir8f/uzDMq06APHGdhdeIKV0HR74BtK95KFg42zeXxAEFeic98PC/FPV +tKpm2WUa1slMB+oP27cRx5Znr2+pktaqnM7f2JgMeJ8bduNH3RUkr9jwgkcJRwyC +I4fwHC9k18aizNdOf2q2UgQXxNXaLYPe17deuNVwwrflMgeFfVrwbT2uPJTMRi1D +FQyc6haF4vsOSSRzE6OyDoc+/1PpyPW75OeSXeVCbc3AEAvRuTZMBQvBQUqVM51e +MDG+K3rCeieSBPOnGNrEC/PiA/CvaMXBEog+xPAw1SgYfuCz4rlM3BdRa54z3+oO +lc8xbzd7w8Q3 +-END CERTIFICATE- +.../certs $ openssl x509 -in nifi-cert.pem -text -noout +Certificate: +Data: +Version: 3 (0x2) +Serial Number: +01:64:de:33:79:03:00:00:00:00 +Signature Algorithm: sha256WithRSAEncryption +Issuer: OU=NIFI, CN=nifi-ca.nifi.ap
[GitHub] nifi pull request #2927: NIFI-5473 Added section on using external signed CA...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2927#discussion_r206583792 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -281,6 +281,272 @@ After running the client you will have the CAâs certificate, a keystore, a tru For a client certificate that can be easily imported into the browser, specify: `-T PKCS12` + Using An Existing Intermediate Certificate Authority (CA) + +In some enterprise scenarios, a security/IT team may provide a signing certificate that has already been signed by the organization's certificate authority (CA). This *intermediate CA* can be used to sign the *node* (sometimes referred to as *leaf*) certificates that will be installed on each NiFi node. In order to inject the existing signing certificate into the toolkit process, follow these steps: + +. Generate or obtain the signed intermediate CA keys in the following format (see additional commands below): + * Public certificate in PEM format: `nifi-cert.pem` + * Private key in PEM format: `nifi-key.key` +. Place the files in the *toolkit directory*. This is the directory where the tool binary (usually called via the invoking script `tls-toolkit.sh` or `tls-toolkit.bat`) is configured to output the signed certificates. *This is not necessarily the directory where the binary is located or invoked*. + * For example, given the following scenario, the toolkit command can be run from its location as long as the output directory `-o` is `../hardcoded/`, and the existing `nifi-cert.pem` and `nifi-key.key` will be used. + ** e.g. `$ ./toolkit/bin/tls-toolkit.sh standalone -o ./hardcoded/ -n 'node4.nifi.apache.org' -P thisIsABadPassword -S thisIsABadPassword -O` will result in a new directory at `./hardcoded/node4.nifi.apache.org` with a keystore and truststore containing a certificate signed by `./hardcoded/nifi-key.key` + * If the `-o` argument is not provided, the default working directory (`.`) must contain `nifi-cert.pem` and `nifi-key.key` + ** e.g. `$ cd ./hardcoded/ && ../toolkit/bin/tls-toolkit.sh standalone -n 'node5.nifi.apache.org' -P thisIsABadPassword -S thisIsABadPassword -O` + +``` +ð 0s @ 18:07:58 $ tree -L 2 +. +âââ hardcoded +â  âââ CN=myusername.hardcoded_OU=NiFi.p12 +â  âââ CN=myusername.hardcoded_OU=NiFi.password +â  âââ nifi-cert.pem +â  âââ nifi-key.key +â  âââ node1.nifi.apache.org +â  âââ node2.nifi.apache.org +â  âââ node3.nifi.apache.org +âââ toolkit +   âââ LICENSE +   âââ NOTICE +   âââ README +   âââ bin +   âââ conf +   âââ docs +   âââ lib +``` + += Additional Commands + +The `nifi-cert.pem` and `nifi-key.key` files should be ASCII-armored (Base64-encoded ASCII) files containing the CA public certificate and private key respectively. Examples: + --- End diff -- Add a section title? == nifi-cert.pem ---
[GitHub] nifi pull request #2927: NIFI-5473 Added section on using external signed CA...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2927#discussion_r206582621 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -281,6 +281,272 @@ After running the client you will have the CAâs certificate, a keystore, a tru For a client certificate that can be easily imported into the browser, specify: `-T PKCS12` + Using An Existing Intermediate Certificate Authority (CA) + +In some enterprise scenarios, a security/IT team may provide a signing certificate that has already been signed by the organization's certificate authority (CA). This *intermediate CA* can be used to sign the *node* (sometimes referred to as *leaf*) certificates that will be installed on each NiFi node. In order to inject the existing signing certificate into the toolkit process, follow these steps: + +. Generate or obtain the signed intermediate CA keys in the following format (see additional commands below): + * Public certificate in PEM format: `nifi-cert.pem` + * Private key in PEM format: `nifi-key.key` +. Place the files in the *toolkit directory*. This is the directory where the tool binary (usually called via the invoking script `tls-toolkit.sh` or `tls-toolkit.bat`) is configured to output the signed certificates. *This is not necessarily the directory where the binary is located or invoked*. + * For example, given the following scenario, the toolkit command can be run from its location as long as the output directory `-o` is `../hardcoded/`, and the existing `nifi-cert.pem` and `nifi-key.key` will be used. + ** e.g. `$ ./toolkit/bin/tls-toolkit.sh standalone -o ./hardcoded/ -n 'node4.nifi.apache.org' -P thisIsABadPassword -S thisIsABadPassword -O` will result in a new directory at `./hardcoded/node4.nifi.apache.org` with a keystore and truststore containing a certificate signed by `./hardcoded/nifi-key.key` + * If the `-o` argument is not provided, the default working directory (`.`) must contain `nifi-cert.pem` and `nifi-key.key` + ** e.g. `$ cd ./hardcoded/ && ../toolkit/bin/tls-toolkit.sh standalone -n 'node5.nifi.apache.org' -P thisIsABadPassword -S thisIsABadPassword -O` + +``` +ð 0s @ 18:07:58 $ tree -L 2 +. +âââ hardcoded +â  âââ CN=myusername.hardcoded_OU=NiFi.p12 +â  âââ CN=myusername.hardcoded_OU=NiFi.password +â  âââ nifi-cert.pem +â  âââ nifi-key.key +â  âââ node1.nifi.apache.org +â  âââ node2.nifi.apache.org +â  âââ node3.nifi.apache.org +âââ toolkit +   âââ LICENSE +   âââ NOTICE +   âââ README +   âââ bin +   âââ conf +   âââ docs +   âââ lib +``` + += Additional Commands + +The `nifi-cert.pem` and `nifi-key.key` files should be ASCII-armored (Base64-encoded ASCII) files containing the CA public certificate and private key respectively. Examples: --- End diff -- Perhaps elaborate on what the "Examples" demonstrate. ---
[GitHub] nifi issue #2922: NIFI-5469 Update Kerberos and LDAP login identity provider...
Github user andrewmlim commented on the issue: https://github.com/apache/nifi/pull/2922 Closing this PR as https://github.com/apache/nifi/pull/2925 is the complete PR. ---
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim closed the pull request at: https://github.com/apache/nifi/pull/2922 ---
[GitHub] nifi issue #2927: NIFI-5473 Added section on using external signed CA for TL...
Github user andrewmlim commented on the issue: https://github.com/apache/nifi/pull/2927 Will review and provide feedback. ---
[GitHub] nifi pull request #2925: NIFI-5469 Additional italics and code formatting co...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi/pull/2925 NIFI-5469 Additional italics and code formatting corrections for cons⦠â¦istency You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi NIFI-5469-2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2925.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2925 commit ac62417eaede596d4f33c37aa12a048d197d08d1 Author: Andrew Lim Date: 2018-07-30T20:17:19Z NIFI-5469 Additional italics and code formatting corrections for consistency ---
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2922#discussion_r206166816 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2434,82 +2538,82 @@ Before you begin, confirm that: + | |*Required Information*|*Description* -|Source ZooKeeper hostname (*sourceHostname*)|The hostname must be one of the hosts running in the ZooKeeper ensemble, which can be found in /conf/zookeeper.properties. Any of the hostnames declared in the *server.N* properties can be used. -|Destination ZooKeeper hostname (*destinationHostname*)|The hostname must be one of the hosts running in the ZooKeeper ensemble, which can be found in /conf/zookeeper.properties. Any of the hostnames declared in the *server.N* properties can be used. -|Source ZooKeeper port (*sourceClientPort*)|This can be found in *zookeeper.properties* of the /conf/zookeeper.properties. The port is specified in the *clientPort* property. -|Destination ZooKeeper port (*destinationClientPort*)|This can be found in *zookeeper.properties* of the /conf/zookeeper.properties. The port is specified in the *clientPort* property. +|Source ZooKeeper hostname (*sourceHostname*)|The hostname must be one of the hosts running in the ZooKeeper ensemble, which can be found in _/conf/zookeeper.properties_. Any of the hostnames declared in the *server.N* properties can be used. --- End diff -- Going to also remove the double reference to zookeeper.properties: This can be found in zookeeper.properties of the /conf/zookeeper.properties. ---
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2922#discussion_r205892652 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2944,95 +3048,95 @@ at this time. | |*Property*|*Description* -|nifi.provenance.repository.directory.default*|The location of the Provenance Repository. The default value is `./provenance_repository`. + +|`nifi.provenance.repository.directory.default`*|The location of the Provenance Repository. The default value is `./provenance_repository`. + + *NOTE*: Multiple provenance repositories can be specified by using the *_nifi.provenance.repository.directory._* prefix with unique suffixes and separate paths as values. + + For example, to provide two additional locations to act as part of the provenance repository, a user could also specify additional properties with keys of: + + -nifi.provenance.repository.directory.provenance1=/repos/provenance1 + -nifi.provenance.repository.directory.provenance2=/repos/provenance2 + +`nifi.provenance.repository.directory.provenance1=/repos/provenance1` + +`nifi.provenance.repository.directory.provenance2=/repos/provenance2` + + Providing three total locations, including `nifi.provenance.repository.directory.default`. -|nifi.provenance.repository.max.storage.time|The maximum amount of time to keep data provenance information. The default value is `24 hours`. -|nifi.provenance.repository.max.storage.size|The maximum amount of data provenance information to store at a time. The default value is `1 GB`. -|nifi.provenance.repository.rollover.time|The amount of time to wait before rolling over the latest data provenance information so that it is available in the User Interface. The default value is `30 secs`. -|nifi.provenance.repository.rollover.size|The amount of information to roll over at a time. The default value is `100 MB`. -|nifi.provenance.repository.query.threads|The number of threads to use for Provenance Repository queries. The default value is `2`. -|nifi.provenance.repository.index.threads|The number of threads to use for indexing Provenance events so that they are searchable. The default value is `2`. +|`nifi.provenance.repository.max.storage.time`|The maximum amount of time to keep data provenance information. The default value is `24 hours`. +|`nifi.provenance.repository.max.storage.size`|The maximum amount of data provenance information to store at a time. The default value is `1 GB`. +|`nifi.provenance.repository.rollover.time`|The amount of time to wait before rolling over the latest data provenance information so that it is available in the User Interface. The default value is `30 secs`. +|`nifi.provenance.repository.rollover.size`|The amount of information to roll over at a time. The default value is `100 MB`. +|`nifi.provenance.repository.query.threads`|The number of threads to use for Provenance Repository queries. The default value is `2`. +|`nifi.provenance.repository.index.threads`|The number of threads to use for indexing Provenance events so that they are searchable. The default value is `2`. For flows that operate on a very high number of FlowFiles, the indexing of Provenance events could become a bottleneck. If this is the case, a bulletin will appear, indicating that "The rate of the dataflow is exceeding the provenance recording rate. Slowing down flow to accommodate." If this happens, increasing the value of this property may increase the rate at which the Provenance Repository is able to process these records, resulting in better overall throughput. -|nifi.provenance.repository.compress.on.rollover|Indicates whether to compress the provenance information when rolling it over. The default value is `true`. -|nifi.provenance.repository.always.sync|If set to `true`, any change to the repository will be synchronized to the disk, meaning that NiFi will ask the operating system not to cache the information. This is very expensive and can significantly reduce NiFi performance. However, if it is `false`, there could be the potential for data loss if either there is a sudden power loss or the operating system crashes. The default value is `false`. -|nifi.provenance.repository.journal.count|The number of journal files that should be used to serialize Provenance Event data. Increasing this value will allow more tasks to simultaneously update the repository but will result in more expensive merging of the journal files later. This value should ideally be equal to the number of threads that are expected to update the repository simultaneously, but 16 tends to work well in must environments. The default value is `16`. -|nifi.provenance.repository.indexed.fields|This is a comma-separated list of the fields that should be indexe
[GitHub] nifi issue #2922: NIFI-5469 Update Kerberos and LDAP login identity provider...
Github user andrewmlim commented on the issue: https://github.com/apache/nifi/pull/2922 Thanks @alopresto for the detailed review. Definitely needed your extra sets of eyes. Will make the suggested changes. ---
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2922#discussion_r205890860 --- 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. --- End diff -- Will make these changes. There are other trailing asterisks as noted in the comments below that should NOT be formatted as they are meant to designate properties that require upgrade considerations. ---
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2922#discussion_r205890227 --- 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. --- End diff -- Agreed. ---
[GitHub] nifi issue #2922: NIFI-5469 Update Kerberos and LDAP login identity provider...
Github user andrewmlim commented on the issue: https://github.com/apache/nifi/pull/2922 Those trailing asterisks refer to the following sections. From the System Properties section (line 2860-2861): Consider configuring items below marked with an asterisk (*) in such a way that upgrading will be easier. From the Warning at the end of the Guide (line 3687): Take care when configuring the properties above that are marked with an asterisk (*). ---
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2922#discussion_r205887314 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2944,95 +3048,95 @@ at this time. | |*Property*|*Description* -|nifi.provenance.repository.directory.default*|The location of the Provenance Repository. The default value is `./provenance_repository`. + +|`nifi.provenance.repository.directory.default`*|The location of the Provenance Repository. The default value is `./provenance_repository`. + + *NOTE*: Multiple provenance repositories can be specified by using the *_nifi.provenance.repository.directory._* prefix with unique suffixes and separate paths as values. + + For example, to provide two additional locations to act as part of the provenance repository, a user could also specify additional properties with keys of: + + -nifi.provenance.repository.directory.provenance1=/repos/provenance1 + -nifi.provenance.repository.directory.provenance2=/repos/provenance2 + +`nifi.provenance.repository.directory.provenance1=/repos/provenance1` + +`nifi.provenance.repository.directory.provenance2=/repos/provenance2` + + Providing three total locations, including `nifi.provenance.repository.directory.default`. -|nifi.provenance.repository.max.storage.time|The maximum amount of time to keep data provenance information. The default value is `24 hours`. -|nifi.provenance.repository.max.storage.size|The maximum amount of data provenance information to store at a time. The default value is `1 GB`. -|nifi.provenance.repository.rollover.time|The amount of time to wait before rolling over the latest data provenance information so that it is available in the User Interface. The default value is `30 secs`. -|nifi.provenance.repository.rollover.size|The amount of information to roll over at a time. The default value is `100 MB`. -|nifi.provenance.repository.query.threads|The number of threads to use for Provenance Repository queries. The default value is `2`. -|nifi.provenance.repository.index.threads|The number of threads to use for indexing Provenance events so that they are searchable. The default value is `2`. +|`nifi.provenance.repository.max.storage.time`|The maximum amount of time to keep data provenance information. The default value is `24 hours`. +|`nifi.provenance.repository.max.storage.size`|The maximum amount of data provenance information to store at a time. The default value is `1 GB`. +|`nifi.provenance.repository.rollover.time`|The amount of time to wait before rolling over the latest data provenance information so that it is available in the User Interface. The default value is `30 secs`. +|`nifi.provenance.repository.rollover.size`|The amount of information to roll over at a time. The default value is `100 MB`. +|`nifi.provenance.repository.query.threads`|The number of threads to use for Provenance Repository queries. The default value is `2`. +|`nifi.provenance.repository.index.threads`|The number of threads to use for indexing Provenance events so that they are searchable. The default value is `2`. For flows that operate on a very high number of FlowFiles, the indexing of Provenance events could become a bottleneck. If this is the case, a bulletin will appear, indicating that "The rate of the dataflow is exceeding the provenance recording rate. Slowing down flow to accommodate." If this happens, increasing the value of this property may increase the rate at which the Provenance Repository is able to process these records, resulting in better overall throughput. -|nifi.provenance.repository.compress.on.rollover|Indicates whether to compress the provenance information when rolling it over. The default value is `true`. -|nifi.provenance.repository.always.sync|If set to `true`, any change to the repository will be synchronized to the disk, meaning that NiFi will ask the operating system not to cache the information. This is very expensive and can significantly reduce NiFi performance. However, if it is `false`, there could be the potential for data loss if either there is a sudden power loss or the operating system crashes. The default value is `false`. -|nifi.provenance.repository.journal.count|The number of journal files that should be used to serialize Provenance Event data. Increasing this value will allow more tasks to simultaneously update the repository but will result in more expensive merging of the journal files later. This value should ideally be equal to the number of threads that are expected to update the repository simultaneously, but 16 tends to work well in must environments. The default value is `16`. -|nifi.provenance.repository.indexed.fields|This is a comma-separated list of the fields that should be indexe
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2922#discussion_r205885953 --- 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.htt
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
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.htt
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2922#discussion_r205885566 --- 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. --- End diff -- Good idea. ---
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2922#discussion_r205884822 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2944,95 +3048,95 @@ at this time. | |*Property*|*Description* -|nifi.provenance.repository.directory.default*|The location of the Provenance Repository. The default value is `./provenance_repository`. + +|`nifi.provenance.repository.directory.default`*|The location of the Provenance Repository. The default value is `./provenance_repository`. + + *NOTE*: Multiple provenance repositories can be specified by using the *_nifi.provenance.repository.directory._* prefix with unique suffixes and separate paths as values. + + For example, to provide two additional locations to act as part of the provenance repository, a user could also specify additional properties with keys of: + + -nifi.provenance.repository.directory.provenance1=/repos/provenance1 + -nifi.provenance.repository.directory.provenance2=/repos/provenance2 + +`nifi.provenance.repository.directory.provenance1=/repos/provenance1` + +`nifi.provenance.repository.directory.provenance2=/repos/provenance2` + + Providing three total locations, including `nifi.provenance.repository.directory.default`. -|nifi.provenance.repository.max.storage.time|The maximum amount of time to keep data provenance information. The default value is `24 hours`. -|nifi.provenance.repository.max.storage.size|The maximum amount of data provenance information to store at a time. The default value is `1 GB`. -|nifi.provenance.repository.rollover.time|The amount of time to wait before rolling over the latest data provenance information so that it is available in the User Interface. The default value is `30 secs`. -|nifi.provenance.repository.rollover.size|The amount of information to roll over at a time. The default value is `100 MB`. -|nifi.provenance.repository.query.threads|The number of threads to use for Provenance Repository queries. The default value is `2`. -|nifi.provenance.repository.index.threads|The number of threads to use for indexing Provenance events so that they are searchable. The default value is `2`. +|`nifi.provenance.repository.max.storage.time`|The maximum amount of time to keep data provenance information. The default value is `24 hours`. +|`nifi.provenance.repository.max.storage.size`|The maximum amount of data provenance information to store at a time. The default value is `1 GB`. +|`nifi.provenance.repository.rollover.time`|The amount of time to wait before rolling over the latest data provenance information so that it is available in the User Interface. The default value is `30 secs`. +|`nifi.provenance.repository.rollover.size`|The amount of information to roll over at a time. The default value is `100 MB`. +|`nifi.provenance.repository.query.threads`|The number of threads to use for Provenance Repository queries. The default value is `2`. +|`nifi.provenance.repository.index.threads`|The number of threads to use for indexing Provenance events so that they are searchable. The default value is `2`. For flows that operate on a very high number of FlowFiles, the indexing of Provenance events could become a bottleneck. If this is the case, a bulletin will appear, indicating that "The rate of the dataflow is exceeding the provenance recording rate. Slowing down flow to accommodate." If this happens, increasing the value of this property may increase the rate at which the Provenance Repository is able to process these records, resulting in better overall throughput. -|nifi.provenance.repository.compress.on.rollover|Indicates whether to compress the provenance information when rolling it over. The default value is `true`. -|nifi.provenance.repository.always.sync|If set to `true`, any change to the repository will be synchronized to the disk, meaning that NiFi will ask the operating system not to cache the information. This is very expensive and can significantly reduce NiFi performance. However, if it is `false`, there could be the potential for data loss if either there is a sudden power loss or the operating system crashes. The default value is `false`. -|nifi.provenance.repository.journal.count|The number of journal files that should be used to serialize Provenance Event data. Increasing this value will allow more tasks to simultaneously update the repository but will result in more expensive merging of the journal files later. This value should ideally be equal to the number of threads that are expected to update the repository simultaneously, but 16 tends to work well in must environments. The default value is `16`. -|nifi.provenance.repository.indexed.fields|This is a comma-separated list of the fields that should be indexe
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2922#discussion_r205884528 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2944,95 +3048,95 @@ at this time. | |*Property*|*Description* -|nifi.provenance.repository.directory.default*|The location of the Provenance Repository. The default value is `./provenance_repository`. + +|`nifi.provenance.repository.directory.default`*|The location of the Provenance Repository. The default value is `./provenance_repository`. + + *NOTE*: Multiple provenance repositories can be specified by using the *_nifi.provenance.repository.directory._* prefix with unique suffixes and separate paths as values. + + For example, to provide two additional locations to act as part of the provenance repository, a user could also specify additional properties with keys of: + + -nifi.provenance.repository.directory.provenance1=/repos/provenance1 + -nifi.provenance.repository.directory.provenance2=/repos/provenance2 + +`nifi.provenance.repository.directory.provenance1=/repos/provenance1` + +`nifi.provenance.repository.directory.provenance2=/repos/provenance2` + + Providing three total locations, including `nifi.provenance.repository.directory.default`. -|nifi.provenance.repository.max.storage.time|The maximum amount of time to keep data provenance information. The default value is `24 hours`. -|nifi.provenance.repository.max.storage.size|The maximum amount of data provenance information to store at a time. The default value is `1 GB`. -|nifi.provenance.repository.rollover.time|The amount of time to wait before rolling over the latest data provenance information so that it is available in the User Interface. The default value is `30 secs`. -|nifi.provenance.repository.rollover.size|The amount of information to roll over at a time. The default value is `100 MB`. -|nifi.provenance.repository.query.threads|The number of threads to use for Provenance Repository queries. The default value is `2`. -|nifi.provenance.repository.index.threads|The number of threads to use for indexing Provenance events so that they are searchable. The default value is `2`. +|`nifi.provenance.repository.max.storage.time`|The maximum amount of time to keep data provenance information. The default value is `24 hours`. +|`nifi.provenance.repository.max.storage.size`|The maximum amount of data provenance information to store at a time. The default value is `1 GB`. +|`nifi.provenance.repository.rollover.time`|The amount of time to wait before rolling over the latest data provenance information so that it is available in the User Interface. The default value is `30 secs`. +|`nifi.provenance.repository.rollover.size`|The amount of information to roll over at a time. The default value is `100 MB`. +|`nifi.provenance.repository.query.threads`|The number of threads to use for Provenance Repository queries. The default value is `2`. +|`nifi.provenance.repository.index.threads`|The number of threads to use for indexing Provenance events so that they are searchable. The default value is `2`. For flows that operate on a very high number of FlowFiles, the indexing of Provenance events could become a bottleneck. If this is the case, a bulletin will appear, indicating that "The rate of the dataflow is exceeding the provenance recording rate. Slowing down flow to accommodate." If this happens, increasing the value of this property may increase the rate at which the Provenance Repository is able to process these records, resulting in better overall throughput. -|nifi.provenance.repository.compress.on.rollover|Indicates whether to compress the provenance information when rolling it over. The default value is `true`. -|nifi.provenance.repository.always.sync|If set to `true`, any change to the repository will be synchronized to the disk, meaning that NiFi will ask the operating system not to cache the information. This is very expensive and can significantly reduce NiFi performance. However, if it is `false`, there could be the potential for data loss if either there is a sudden power loss or the operating system crashes. The default value is `false`. -|nifi.provenance.repository.journal.count|The number of journal files that should be used to serialize Provenance Event data. Increasing this value will allow more tasks to simultaneously update the repository but will result in more expensive merging of the journal files later. This value should ideally be equal to the number of threads that are expected to update the repository simultaneously, but 16 tends to work well in must environments. The default value is `16`. -|nifi.provenance.repository.indexed.fields|This is a comma-separated list of the fields that should be indexe
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2922#discussion_r205884200 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2944,95 +3048,95 @@ at this time. --- End diff -- I saw that and didn't want to change it, not knowing the author's intent. But, if you agree that this is worthy to change for consistency, then I am in agreement also. ---
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2922#discussion_r205883727 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2876,40 +2980,40 @@ FlowFile Repository, if also on that disk, could become corrupt. To avoid this s | |*Property*|*Description* -|nifi.content.repository.implementation|The Content Repository implementation. The default value is `org.apache.nifi.controller.repository.FileSystemRepository` and should only be changed with caution. To store flowfile content in memory instead of on disk (at the risk of data loss in the event of power/machine failure), set this property to `org.apache.nifi.controller.repository.VolatileContentRepository`. +|`nifi.content.repository.implementation`|The Content Repository implementation. The default value is `org.apache.nifi.controller.repository.FileSystemRepository` and should only be changed with caution. To store flowfile content in memory instead of on disk (at the risk of data loss in the event of power/machine failure), set this property to `org.apache.nifi.controller.repository.VolatileContentRepository`. | === File System Content Repository Properties | |*Property*|*Description* -|nifi.content.repository.implementation|The Content Repository implementation. The default value is `org.apache.nifi.controller.repository.FileSystemRepository` and should only be changed with caution. To store flowfile content in memory instead of on disk (at the risk of data loss in the event of power/machine failure), set this property to `org.apache.nifi.controller.repository.VolatileContentRepository`. -|nifi.content.claim.max.appendable.size|The maximum size for a content claim. The default value is `1 MB`. -|nifi.content.claim.max.flow.files|The maximum number of FlowFiles to assign to one content claim. The default value is `100`. -|nifi.content.repository.directory.default*|The location of the Content Repository. The default value is `./content_repository`. + +|`nifi.content.repository.implementation`|The Content Repository implementation. The default value is `org.apache.nifi.controller.repository.FileSystemRepository` and should only be changed with caution. To store flowfile content in memory instead of on disk (at the risk of data loss in the event of power/machine failure), set this property to `org.apache.nifi.controller.repository.VolatileContentRepository`. +|`nifi.content.claim.max.appendable.size`|The maximum size for a content claim. The default value is `1 MB`. +|`nifi.content.claim.max.flow.files`|The maximum number of FlowFiles to assign to one content claim. The default value is `100`. +|`nifi.content.repository.directory.default`*|The location of the Content Repository. The default value is `./content_repository`. + + *NOTE*: Multiple content repositories can be specified by using the *_nifi.content.repository.directory._* prefix with unique suffixes and separate paths as values. + + For example, to provide two additional locations to act as part of the content repository, a user could also specify additional properties with keys of: + + -nifi.content.repository.directory.content1=/repos/content1 + -nifi.content.repository.directory.content2=/repos/content2 + +`nifi.content.repository.directory.content1=/repos/content1` + +`nifi.content.repository.directory.content2=/repos/content2` + + Providing three total locations, including `nifi.content.repository.directory.default`. -|nifi.content.repository.archive.max.retention.period|If archiving is enabled (see nifi.content.repository.archive.enabled below), then +|`nifi.content.repository.archive.max.retention.period`|If archiving is enabled (see `nifi.content.repository.archive.enabled` below), then this property specifies the maximum amount of time to keep the archived data. The default value is `12 hours`. -|nifi.content.repository.archive.max.usage.percentage|If archiving is enabled (see nifi.content.repository.archive.enabled below), then this property must have a value that indicates the content repository disk usage percentage at which archived data begins to be removed. If the archive is empty and content repository disk usage is above this percentage, then archiving is temporarily disabled. Archiving will resume when disk usage is below this percentage. The default value is `50%`. -|nifi.content.repository.archive.enabled|To enable content archiving, set this to _true_ and specify a value for the `nifi.content.repository.archive.max.usage.percentage` property above. Content archiving enables the provenance UI to view or replay content that is no longer in a dataflow queue. By default, archiving is enabled. -|nifi.content.repository.always.sync|If set to `true`, any change
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2922#discussion_r205883620 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2876,40 +2980,40 @@ FlowFile Repository, if also on that disk, could become corrupt. To avoid this s | |*Property*|*Description* -|nifi.content.repository.implementation|The Content Repository implementation. The default value is `org.apache.nifi.controller.repository.FileSystemRepository` and should only be changed with caution. To store flowfile content in memory instead of on disk (at the risk of data loss in the event of power/machine failure), set this property to `org.apache.nifi.controller.repository.VolatileContentRepository`. +|`nifi.content.repository.implementation`|The Content Repository implementation. The default value is `org.apache.nifi.controller.repository.FileSystemRepository` and should only be changed with caution. To store flowfile content in memory instead of on disk (at the risk of data loss in the event of power/machine failure), set this property to `org.apache.nifi.controller.repository.VolatileContentRepository`. | === File System Content Repository Properties | |*Property*|*Description* -|nifi.content.repository.implementation|The Content Repository implementation. The default value is `org.apache.nifi.controller.repository.FileSystemRepository` and should only be changed with caution. To store flowfile content in memory instead of on disk (at the risk of data loss in the event of power/machine failure), set this property to `org.apache.nifi.controller.repository.VolatileContentRepository`. -|nifi.content.claim.max.appendable.size|The maximum size for a content claim. The default value is `1 MB`. -|nifi.content.claim.max.flow.files|The maximum number of FlowFiles to assign to one content claim. The default value is `100`. -|nifi.content.repository.directory.default*|The location of the Content Repository. The default value is `./content_repository`. + +|`nifi.content.repository.implementation`|The Content Repository implementation. The default value is `org.apache.nifi.controller.repository.FileSystemRepository` and should only be changed with caution. To store flowfile content in memory instead of on disk (at the risk of data loss in the event of power/machine failure), set this property to `org.apache.nifi.controller.repository.VolatileContentRepository`. +|`nifi.content.claim.max.appendable.size`|The maximum size for a content claim. The default value is `1 MB`. +|`nifi.content.claim.max.flow.files`|The maximum number of FlowFiles to assign to one content claim. The default value is `100`. +|`nifi.content.repository.directory.default`*|The location of the Content Repository. The default value is `./content_repository`. + + *NOTE*: Multiple content repositories can be specified by using the *_nifi.content.repository.directory._* prefix with unique suffixes and separate paths as values. + + For example, to provide two additional locations to act as part of the content repository, a user could also specify additional properties with keys of: + + -nifi.content.repository.directory.content1=/repos/content1 + -nifi.content.repository.directory.content2=/repos/content2 + +`nifi.content.repository.directory.content1=/repos/content1` + +`nifi.content.repository.directory.content2=/repos/content2` + + Providing three total locations, including `nifi.content.repository.directory.default`. -|nifi.content.repository.archive.max.retention.period|If archiving is enabled (see nifi.content.repository.archive.enabled below), then +|`nifi.content.repository.archive.max.retention.period`|If archiving is enabled (see `nifi.content.repository.archive.enabled` below), then this property specifies the maximum amount of time to keep the archived data. The default value is `12 hours`. -|nifi.content.repository.archive.max.usage.percentage|If archiving is enabled (see nifi.content.repository.archive.enabled below), then this property must have a value that indicates the content repository disk usage percentage at which archived data begins to be removed. If the archive is empty and content repository disk usage is above this percentage, then archiving is temporarily disabled. Archiving will resume when disk usage is below this percentage. The default value is `50%`. -|nifi.content.repository.archive.enabled|To enable content archiving, set this to _true_ and specify a value for the `nifi.content.repository.archive.max.usage.percentage` property above. Content archiving enables the provenance UI to view or replay content that is no longer in a dataflow queue. By default, archiving is enabled. -|nifi.content.repository.always.sync|If set to `true`, any change
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2922#discussion_r205883526 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2749,7 +2853,7 @@ root@kdc:~# [[system_properties]] == System Properties -The _nifi.properties_ file in the _conf_ directory is the main configuration file for controlling how NiFi runs. This section provides an overview of the properties in this file and includes some notes on how to configure it in a way that will make upgrading easier. *After making changes to this file, restart NiFi in order +The _nifi.properties_ file in the `conf` directory is the main configuration file for controlling how NiFi runs. This section provides an overview of the properties in this file and includes some notes on how to configure it in a way that will make upgrading easier. *After making changes to this file, restart NiFi in order --- End diff -- I saw a mixture of both throughout the doc. I went with code formatted for the new standard. ---
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2922#discussion_r205883351 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2434,82 +2538,82 @@ Before you begin, confirm that: + | |*Required Information*|*Description* -|Source ZooKeeper hostname (*sourceHostname*)|The hostname must be one of the hosts running in the ZooKeeper ensemble, which can be found in /conf/zookeeper.properties. Any of the hostnames declared in the *server.N* properties can be used. -|Destination ZooKeeper hostname (*destinationHostname*)|The hostname must be one of the hosts running in the ZooKeeper ensemble, which can be found in /conf/zookeeper.properties. Any of the hostnames declared in the *server.N* properties can be used. -|Source ZooKeeper port (*sourceClientPort*)|This can be found in *zookeeper.properties* of the /conf/zookeeper.properties. The port is specified in the *clientPort* property. -|Destination ZooKeeper port (*destinationClientPort*)|This can be found in *zookeeper.properties* of the /conf/zookeeper.properties. The port is specified in the *clientPort* property. +|Source ZooKeeper hostname (*sourceHostname*)|The hostname must be one of the hosts running in the ZooKeeper ensemble, which can be found in _/conf/zookeeper.properties_. Any of the hostnames declared in the *server.N* properties can be used. +|Destination ZooKeeper hostname (*destinationHostname*)|The hostname must be one of the hosts running in the ZooKeeper ensemble, which can be found in _/conf/zookeeper.properties_. Any of the hostnames declared in the *server.N* properties can be used. +|Source ZooKeeper port (*sourceClientPort*)|This can be found in *zookeeper.properties* of the _/conf/zookeeper.properties_. The port is specified in the *clientPort* property. +|Destination ZooKeeper port (*destinationClientPort*)|This can be found in *zookeeper.properties* of the _/conf/zookeeper.properties_. The port is specified in the *clientPort* property. |Export data path|Determine the path that will store a json file containing the export of data from ZooKeeper. It must be readable and writable by the user running the zk-migrator tool. -|Source ZooKeeper Authentication Information|This information is in /conf/state-management.xml. For NiFi 0.x, if Creator Only is specified in state-management.xml, you need to supply authentication information using the `-a,--auth` argument with the values from the Username and Password properties in state-management.xml. For NiFi 1.x, supply authentication information using the `-k,--krb-conf` argument. -+ -If the state-management.xml specifies Open, no authentication is required. -|Destination ZooKeeper Authentication Information|This information is in /conf/state-management.xml. For NiFi 0.x, if Creator Only is specified in state-management.xml, you need to supply authentication information using the `-a,--auth` argument with the values from the Username and Password properties in state-management.xml. For NiFi 1.x, supply authentication information using the `-k,--krb-conf` argument. -+ -If the state-management.xml specifies Open, no authentication is required. -|Root path to which NiFi writes data in Source ZooKeeper (*sourceRootPath*)|This information can be found in /conf/state-management.xml under the Root Node property in the cluster-provider element. (default: /nifi) -|Root path to which NiFi writes data in Destination ZooKeeper (*destinationRootPath*)|This information can be found in /conf/state-management.xml under the Root Node property in the cluster-provider element. +|Source ZooKeeper Authentication Information|This information is in _/conf/state-management.xml_. For NiFi 0.x, if Creator Only is specified in _state-management.xml_, you need to supply authentication information using the `-a,--auth` argument with the values from the Username and Password properties in _state-management.xml_. For NiFi 1.x, supply authentication information using the `-k,--krb-conf` argument. + +If the _state-management.xml_ specifies Open, no authentication is required. +|Destination ZooKeeper Authentication Information|This information is in _/conf/state-management.xml_. For NiFi 0.x, if Creator Only is specified in _state-management.xml_, you need to supply authentication information using the `-a,--auth` argument with the values from the Username and Password properties in state-management.xml. For NiFi 1.x, supply authentication information using the `-k,--krb-conf` argument. + +If the _state-management.xml_ specifies Open, no authentication is required. +|Root path to which NiFi writes data in Source ZooKeeper (*sourceRootPath*)|This information can be found in `/conf/state-management.xml` under the Root Node property in the cluster-provider element. (default
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2922#discussion_r205883302 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2434,82 +2538,82 @@ Before you begin, confirm that: + | |*Required Information*|*Description* -|Source ZooKeeper hostname (*sourceHostname*)|The hostname must be one of the hosts running in the ZooKeeper ensemble, which can be found in /conf/zookeeper.properties. Any of the hostnames declared in the *server.N* properties can be used. -|Destination ZooKeeper hostname (*destinationHostname*)|The hostname must be one of the hosts running in the ZooKeeper ensemble, which can be found in /conf/zookeeper.properties. Any of the hostnames declared in the *server.N* properties can be used. -|Source ZooKeeper port (*sourceClientPort*)|This can be found in *zookeeper.properties* of the /conf/zookeeper.properties. The port is specified in the *clientPort* property. -|Destination ZooKeeper port (*destinationClientPort*)|This can be found in *zookeeper.properties* of the /conf/zookeeper.properties. The port is specified in the *clientPort* property. +|Source ZooKeeper hostname (*sourceHostname*)|The hostname must be one of the hosts running in the ZooKeeper ensemble, which can be found in _/conf/zookeeper.properties_. Any of the hostnames declared in the *server.N* properties can be used. --- End diff -- I wasn't sure about the intent for the bold. But, I could see them being code formatted as you suggested. ---
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2922#discussion_r205882931 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2338,15 +2442,15 @@ We add the following line anywhere in this file in order to tell the NiFi JVM to [source] java.arg.15=-Djava.security.auth.login.config=./conf/zookeeper-jaas.conf -Finally we need to update `nifi.properties` to ensure that NiFi knows to apply SASL specific ACLs for the Znodes it will create in Zookeeper for cluster management. +Finally we need to update _nifi.properties_ to ensure that NiFi knows to apply SASL specific ACLs for the Znodes it will create in Zookeeper for cluster management. To enable this, in the `$NIFI_HOME/conf/nifi.properties` file and edit the following properties as shown below: --- End diff -- yes ---
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2922#discussion_r205883004 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2364,7 +2468,7 @@ in the following locations: - _conf/zookeeper.properties_ file should use FQDN for `server.1`, `server.2`, ..., `server.N` values. - The `Connect String` property of the ZooKeeperStateProvider - - The /etc/hosts file should also resolve the FQDN to an IP address that is *not* _127.0.0.1_. + - The /etc/hosts file should also resolve the FQDN to an IP address that is *not* `127.0.0.1`. --- End diff -- yes ---
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2922#discussion_r205882868 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2315,7 +2419,7 @@ kadmin: xst -k nifi.keytab n...@example.com This keytab file can be copied to the other NiFi nodes with embedded zookeeper servers. -This will create a file in the current directory named `nifi.keytab`. We can now copy that file into the _$NIFI_HOME/conf/_ directory. We should ensure +This will create a file in the current directory named `nifi.keytab`. We can now copy that file into the `$NIFI_HOME/conf/` directory. We should ensure --- End diff -- I've been going with this convention: filenames in italics, directory paths/directories in code formatting. ---
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2922#discussion_r205881424 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2434,82 +2538,82 @@ Before you begin, confirm that: + | |*Required Information*|*Description* -|Source ZooKeeper hostname (*sourceHostname*)|The hostname must be one of the hosts running in the ZooKeeper ensemble, which can be found in /conf/zookeeper.properties. Any of the hostnames declared in the *server.N* properties can be used. -|Destination ZooKeeper hostname (*destinationHostname*)|The hostname must be one of the hosts running in the ZooKeeper ensemble, which can be found in /conf/zookeeper.properties. Any of the hostnames declared in the *server.N* properties can be used. -|Source ZooKeeper port (*sourceClientPort*)|This can be found in *zookeeper.properties* of the /conf/zookeeper.properties. The port is specified in the *clientPort* property. -|Destination ZooKeeper port (*destinationClientPort*)|This can be found in *zookeeper.properties* of the /conf/zookeeper.properties. The port is specified in the *clientPort* property. +|Source ZooKeeper hostname (*sourceHostname*)|The hostname must be one of the hosts running in the ZooKeeper ensemble, which can be found in _/conf/zookeeper.properties_. Any of the hostnames declared in the *server.N* properties can be used. +|Destination ZooKeeper hostname (*destinationHostname*)|The hostname must be one of the hosts running in the ZooKeeper ensemble, which can be found in _/conf/zookeeper.properties_. Any of the hostnames declared in the *server.N* properties can be used. +|Source ZooKeeper port (*sourceClientPort*)|This can be found in *zookeeper.properties* of the _/conf/zookeeper.properties_. The port is specified in the *clientPort* property. +|Destination ZooKeeper port (*destinationClientPort*)|This can be found in *zookeeper.properties* of the _/conf/zookeeper.properties_. The port is specified in the *clientPort* property. |Export data path|Determine the path that will store a json file containing the export of data from ZooKeeper. It must be readable and writable by the user running the zk-migrator tool. -|Source ZooKeeper Authentication Information|This information is in /conf/state-management.xml. For NiFi 0.x, if Creator Only is specified in state-management.xml, you need to supply authentication information using the `-a,--auth` argument with the values from the Username and Password properties in state-management.xml. For NiFi 1.x, supply authentication information using the `-k,--krb-conf` argument. -+ -If the state-management.xml specifies Open, no authentication is required. -|Destination ZooKeeper Authentication Information|This information is in /conf/state-management.xml. For NiFi 0.x, if Creator Only is specified in state-management.xml, you need to supply authentication information using the `-a,--auth` argument with the values from the Username and Password properties in state-management.xml. For NiFi 1.x, supply authentication information using the `-k,--krb-conf` argument. -+ -If the state-management.xml specifies Open, no authentication is required. -|Root path to which NiFi writes data in Source ZooKeeper (*sourceRootPath*)|This information can be found in /conf/state-management.xml under the Root Node property in the cluster-provider element. (default: /nifi) -|Root path to which NiFi writes data in Destination ZooKeeper (*destinationRootPath*)|This information can be found in /conf/state-management.xml under the Root Node property in the cluster-provider element. +|Source ZooKeeper Authentication Information|This information is in _/conf/state-management.xml_. For NiFi 0.x, if Creator Only is specified in _state-management.xml_, you need to supply authentication information using the `-a,--auth` argument with the values from the Username and Password properties in _state-management.xml_. For NiFi 1.x, supply authentication information using the `-k,--krb-conf` argument. + +If the _state-management.xml_ specifies Open, no authentication is required. +|Destination ZooKeeper Authentication Information|This information is in _/conf/state-management.xml_. For NiFi 0.x, if Creator Only is specified in _state-management.xml_, you need to supply authentication information using the `-a,--auth` argument with the values from the Username and Password properties in state-management.xml. For NiFi 1.x, supply authentication information using the `-k,--krb-conf` argument. + +If the _state-management.xml_ specifies Open, no authentication is required. +|Root path to which NiFi writes data in Source ZooKeeper (*sourceRootPath*)|This information can be found in `/conf/state-management.xml` under the Root Node property in the cluster-provider element. (default
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi/pull/2922#discussion_r205880453 --- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc --- @@ -2083,11 +2187,11 @@ Once these State Providers have been configured in the _state-management.xml_ fi referenced by their identifiers. By default, the Local State Provider is configured to be a `WriteAheadLocalStateProvider` that persists the data to the -_$NIFI_HOME/state/local_ directory. The default Cluster State Provider is configured to be a `ZooKeeperStateProvider`. The default +`$NIFI_HOME/state/local` directory. The default Cluster State Provider is configured to be a `ZooKeeperStateProvider`. The default ZooKeeper-based provider must have its `Connect String` property populated before it can be used. It is also advisable, if multiple NiFi instances will use the same ZooKeeper instance, that the value of the `Root Node` property be changed. For instance, one might set the value to `/nifi//production`. A `Connect String` takes the form of comma separated : tuples, such as -my-zk-server1:2181,my-zk-server2:2181,my-zk-server3:2181. In the event a port is not specified for any of the hosts, the ZooKeeper default of +my-zk-server1:2181,`my-zk-server2:2181,my-zk-server3:2181`. In the event a port is not specified for any of the hosts, the ZooKeeper default of --- End diff -- Good catch. ---
[GitHub] nifi pull request #2922: NIFI-5469 Update Kerberos and LDAP login identity p...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi/pull/2922 NIFI-5469 Update Kerberos and LDAP login identity provider sections ⦠â¦and correct formatting inconsistencies You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi NIFI-5469 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2922.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2922 commit 1055d3b0626a55f5f8d6bcfe5ba56fdaed9907ee Author: Andrew Lim Date: 2018-07-27T18:34:00Z NIFI-5469 Update Kerberors and LDAP login identity provider sections and correct formatting inconsistencies ---
[GitHub] nifi-registry pull request #130: NIFIREG-185 Added element id's to facilitat...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi-registry/pull/130 NIFIREG-185 Added element id's to facilitate User testing use cases You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi-registry NIFIREG-185 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi-registry/pull/130.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #130 commit e6a765f4a80530787b0391708197ca820136cf06 Author: Andrew Lim Date: 2018-07-12T20:03:29Z NIFIREG-185 Added elment id's to facilitate User testing use cases ---
[GitHub] nifi-site pull request #27: Added GPG Guide
Github user andrewmlim commented on a diff in the pull request:
https://github.com/apache/nifi-site/pull/27#discussion_r201812727
--- Diff: src/pages/markdown/gpg.md ---
@@ -0,0 +1,524 @@
+---
+title: GPG (Gnu Privacy Guard / Open PGP) Signatures
+---
+
+# Apache NiFi Release Signatures and Code Signing
+
+The purpose of this document is to capture and describe the steps involved
in generating and verifying cryptographic signatures of official releases of
Apache NiFi, as well as configuring cryptographic signatures of individual code
commits. It is written for contributors, committers, and users of Apache NiFi
(and related applications).
+
+## Table of Contents
+ * [The Objective](#the-objective)
+ * [Background Material](#background-material)
+ * [Terms](#terms)
+ * [Variable Reference Substitutions](#variable-reference-substitutions)
+ * [Download GPG](#download-gpg)
+ * [Set up a GPG key](#set-up-a-gpg-key)
+ * [Sign your GPG key](#sign-your-gpg-key)
+ * [Publish your key](#publish-your-key)
+ * [Import another GPG key](#import-another-gpg-key)
+ * [Verify a key](#verify-a-key)
+ * [Sign an external key](#sign-an-external-key)
+ * [Web of trust](#web-of-trust)
+ * [Set up git with your key](#set-up-git-with-your-key)
+ * [Signing code](#signing-code)
+ * [Verifying a signature](#verifying-a-signature)
+ * [Set up GitHub with your key](#set-up-github-with-your-key)
+ * [Signing a release artifact](#signing-a-release-artifact)
+ * [Verifying a release signature](#verifying-a-release-signature)
+
+## The Objective
+
+Our aim is to instruct users on how to sign their commits, verify other's
signatures, and do the same for official releases of Apache NiFi.
+
+## Background Material
+
+ - These documents are helpful for general environmental setup to perform
GPG signing and signature verification
+- [Apache PGP Info][apache-pgp]
+- [Apache Release Signing][apache-release-signing]
+- [Git Ready: Signing Releases with GPG][git-sign-tag-instructs]
+- [RFC 4880: IETF Standard Spec for OpenPGP][rfc-4880]
+- [GitHub Blog: GPG Signature Verification][github-gpg-signing]
+- [Git Ready: gpg-sign releases][git-sign-tag-instructs]
+- [GitHub Help: Signing Commits Using GPG][github-help-gpg]
+- [GitHub Help: Telling Git About Your GPG Key][git-config-gpg]
+- [Git Docs: Git Tools Signing Your Work][git-gpg]
+- [PGP Web of Trust][web-of-trust]
+
+## Terms
+
+ * **Asymmetric Cryptography** - a type of cryptography which relies on
*key pairs* -- a *public* and *private* key which are mathematically-related
such that no other component key matches. This cryptography offers the
following actions: **encrypt**, **decrypt**, **sign**, and **verify**
+ * **Cryptographic Signature** - a series of bytes which are the result of
a signing operation such that only the possessor of a specific private key
could have generated this signature. A valid signature indicates that the
possessor of said key performed the operation (non-repudiable)
+
+## Variable Reference
Substitutions
+
+Throughout this guide, references must be made to names and values that
will vary from release to release. For clarity
+those variable values have been written like Bash variable references.
When a term like
+"```/tmp/src/nifi-${NIFI_VERSION}```" is seen in an instruction or email
template it should be replaced with
+"```/tmp/src/nifi-1.7.0```" when working the release of "Apache NiFi
1.7.0".
+
+ * Substitutions used in tasks and email templates
+
+ReferenceExample value Description
+=== ===
+${BRANCH}master the development branch on
which the release is based.
+${NIFI_VERSION} 1.7.0 the version currently in
development on the release branch.
+${NEXT_VERSION} 1.8.0-SNAPSHOT the future version for
development on the release branch.
+${JIRA_TICKET} NIFI-2112 the JIRA ticket created by
the release manager for the release tasks.
+${RC}2 the Release Candidate index
start at 1 for the first release candidate.
+${RC_TAG_COMMIT_ID} the 40 byte commit ID of the
RC tag created during the Maven release process.
+${STAGING_REPO_ID} orgapachenifi-1088 the temporary repository ID
where staged artifacts have been placed.
+${RM_USERID} johndoe the Apache account ID of
Release Manager.
+${RELEASE_TAG} rel/nifi-1.7.0 the Git repository tag for
the source code as released.
+${VOTE_THREAD_
[GitHub] nifi-site pull request #27: Added GPG Guide
Github user andrewmlim commented on a diff in the pull request:
https://github.com/apache/nifi-site/pull/27#discussion_r201812213
--- Diff: src/pages/markdown/gpg.md ---
@@ -0,0 +1,524 @@
+---
+title: GPG (Gnu Privacy Guard / Open PGP) Signatures
+---
+
+# Apache NiFi Release Signatures and Code Signing
+
+The purpose of this document is to capture and describe the steps involved
in generating and verifying cryptographic signatures of official releases of
Apache NiFi, as well as configuring cryptographic signatures of individual code
commits. It is written for contributors, committers, and users of Apache NiFi
(and related applications).
+
+## Table of Contents
+ * [The Objective](#the-objective)
+ * [Background Material](#background-material)
+ * [Terms](#terms)
+ * [Variable Reference Substitutions](#variable-reference-substitutions)
+ * [Download GPG](#download-gpg)
+ * [Set up a GPG key](#set-up-a-gpg-key)
+ * [Sign your GPG key](#sign-your-gpg-key)
+ * [Publish your key](#publish-your-key)
+ * [Import another GPG key](#import-another-gpg-key)
+ * [Verify a key](#verify-a-key)
+ * [Sign an external key](#sign-an-external-key)
+ * [Web of trust](#web-of-trust)
+ * [Set up git with your key](#set-up-git-with-your-key)
+ * [Signing code](#signing-code)
+ * [Verifying a signature](#verifying-a-signature)
+ * [Set up GitHub with your key](#set-up-github-with-your-key)
+ * [Signing a release artifact](#signing-a-release-artifact)
+ * [Verifying a release signature](#verifying-a-release-signature)
+
+## The Objective
+
+Our aim is to instruct users on how to sign their commits, verify other's
signatures, and do the same for official releases of Apache NiFi.
+
+## Background Material
+
+ - These documents are helpful for general environmental setup to perform
GPG signing and signature verification
+- [Apache PGP Info][apache-pgp]
+- [Apache Release Signing][apache-release-signing]
+- [Git Ready: Signing Releases with GPG][git-sign-tag-instructs]
+- [RFC 4880: IETF Standard Spec for OpenPGP][rfc-4880]
+- [GitHub Blog: GPG Signature Verification][github-gpg-signing]
+- [Git Ready: gpg-sign releases][git-sign-tag-instructs]
+- [GitHub Help: Signing Commits Using GPG][github-help-gpg]
+- [GitHub Help: Telling Git About Your GPG Key][git-config-gpg]
+- [Git Docs: Git Tools Signing Your Work][git-gpg]
+- [PGP Web of Trust][web-of-trust]
+
+## Terms
+
+ * **Asymmetric Cryptography** - a type of cryptography which relies on
*key pairs* -- a *public* and *private* key which are mathematically-related
such that no other component key matches. This cryptography offers the
following actions: **encrypt**, **decrypt**, **sign**, and **verify**
+ * **Cryptographic Signature** - a series of bytes which are the result of
a signing operation such that only the possessor of a specific private key
could have generated this signature. A valid signature indicates that the
possessor of said key performed the operation (non-repudiable)
+
+## Variable Reference
Substitutions
+
+Throughout this guide, references must be made to names and values that
will vary from release to release. For clarity
+those variable values have been written like Bash variable references.
When a term like
+"```/tmp/src/nifi-${NIFI_VERSION}```" is seen in an instruction or email
template it should be replaced with
+"```/tmp/src/nifi-1.7.0```" when working the release of "Apache NiFi
1.7.0".
+
+ * Substitutions used in tasks and email templates
+
+ReferenceExample value Description
+=== ===
+${BRANCH}master the development branch on
which the release is based.
+${NIFI_VERSION} 1.7.0 the version currently in
development on the release branch.
+${NEXT_VERSION} 1.8.0-SNAPSHOT the future version for
development on the release branch.
+${JIRA_TICKET} NIFI-2112 the JIRA ticket created by
the release manager for the release tasks.
+${RC}2 the Release Candidate index
start at 1 for the first release candidate.
+${RC_TAG_COMMIT_ID} the 40 byte commit ID of the
RC tag created during the Maven release process.
+${STAGING_REPO_ID} orgapachenifi-1088 the temporary repository ID
where staged artifacts have been placed.
+${RM_USERID} johndoe the Apache account ID of
Release Manager.
+${RELEASE_TAG} rel/nifi-1.7.0 the Git repository tag for
the source code as released.
+${VOTE_THREAD_
[GitHub] nifi-site pull request #27: Added GPG Guide
Github user andrewmlim commented on a diff in the pull request:
https://github.com/apache/nifi-site/pull/27#discussion_r201810673
--- Diff: src/pages/markdown/gpg.md ---
@@ -0,0 +1,524 @@
+---
+title: GPG (Gnu Privacy Guard / Open PGP) Signatures
+---
+
+# Apache NiFi Release Signatures and Code Signing
+
+The purpose of this document is to capture and describe the steps involved
in generating and verifying cryptographic signatures of official releases of
Apache NiFi, as well as configuring cryptographic signatures of individual code
commits. It is written for contributors, committers, and users of Apache NiFi
(and related applications).
+
+## Table of Contents
+ * [The Objective](#the-objective)
+ * [Background Material](#background-material)
+ * [Terms](#terms)
+ * [Variable Reference Substitutions](#variable-reference-substitutions)
+ * [Download GPG](#download-gpg)
+ * [Set up a GPG key](#set-up-a-gpg-key)
+ * [Sign your GPG key](#sign-your-gpg-key)
+ * [Publish your key](#publish-your-key)
+ * [Import another GPG key](#import-another-gpg-key)
+ * [Verify a key](#verify-a-key)
+ * [Sign an external key](#sign-an-external-key)
+ * [Web of trust](#web-of-trust)
+ * [Set up git with your key](#set-up-git-with-your-key)
+ * [Signing code](#signing-code)
+ * [Verifying a signature](#verifying-a-signature)
+ * [Set up GitHub with your key](#set-up-github-with-your-key)
+ * [Signing a release artifact](#signing-a-release-artifact)
+ * [Verifying a release signature](#verifying-a-release-signature)
+
+## The Objective
+
+Our aim is to instruct users on how to sign their commits, verify other's
signatures, and do the same for official releases of Apache NiFi.
+
+## Background Material
+
+ - These documents are helpful for general environmental setup to perform
GPG signing and signature verification
+- [Apache PGP Info][apache-pgp]
+- [Apache Release Signing][apache-release-signing]
+- [Git Ready: Signing Releases with GPG][git-sign-tag-instructs]
+- [RFC 4880: IETF Standard Spec for OpenPGP][rfc-4880]
+- [GitHub Blog: GPG Signature Verification][github-gpg-signing]
+- [Git Ready: gpg-sign releases][git-sign-tag-instructs]
+- [GitHub Help: Signing Commits Using GPG][github-help-gpg]
+- [GitHub Help: Telling Git About Your GPG Key][git-config-gpg]
+- [Git Docs: Git Tools Signing Your Work][git-gpg]
+- [PGP Web of Trust][web-of-trust]
+
+## Terms
+
+ * **Asymmetric Cryptography** - a type of cryptography which relies on
*key pairs* -- a *public* and *private* key which are mathematically-related
such that no other component key matches. This cryptography offers the
following actions: **encrypt**, **decrypt**, **sign**, and **verify**
+ * **Cryptographic Signature** - a series of bytes which are the result of
a signing operation such that only the possessor of a specific private key
could have generated this signature. A valid signature indicates that the
possessor of said key performed the operation (non-repudiable)
+
+## Variable Reference
Substitutions
+
+Throughout this guide, references must be made to names and values that
will vary from release to release. For clarity
+those variable values have been written like Bash variable references.
When a term like
+"```/tmp/src/nifi-${NIFI_VERSION}```" is seen in an instruction or email
template it should be replaced with
+"```/tmp/src/nifi-1.7.0```" when working the release of "Apache NiFi
1.7.0".
+
+ * Substitutions used in tasks and email templates
+
+ReferenceExample value Description
+=== ===
+${BRANCH}master the development branch on
which the release is based.
+${NIFI_VERSION} 1.7.0 the version currently in
development on the release branch.
+${NEXT_VERSION} 1.8.0-SNAPSHOT the future version for
development on the release branch.
+${JIRA_TICKET} NIFI-2112 the JIRA ticket created by
the release manager for the release tasks.
+${RC}2 the Release Candidate index
start at 1 for the first release candidate.
+${RC_TAG_COMMIT_ID} the 40 byte commit ID of the
RC tag created during the Maven release process.
+${STAGING_REPO_ID} orgapachenifi-1088 the temporary repository ID
where staged artifacts have been placed.
+${RM_USERID} johndoe the Apache account ID of
Release Manager.
+${RELEASE_TAG} rel/nifi-1.7.0 the Git repository tag for
the source code as released.
+${VOTE_THREAD_
[GitHub] nifi-site pull request #27: Added GPG Guide
Github user andrewmlim commented on a diff in the pull request:
https://github.com/apache/nifi-site/pull/27#discussion_r201810221
--- Diff: src/pages/markdown/gpg.md ---
@@ -0,0 +1,524 @@
+---
+title: GPG (Gnu Privacy Guard / Open PGP) Signatures
+---
+
+# Apache NiFi Release Signatures and Code Signing
+
+The purpose of this document is to capture and describe the steps involved
in generating and verifying cryptographic signatures of official releases of
Apache NiFi, as well as configuring cryptographic signatures of individual code
commits. It is written for contributors, committers, and users of Apache NiFi
(and related applications).
+
+## Table of Contents
+ * [The Objective](#the-objective)
+ * [Background Material](#background-material)
+ * [Terms](#terms)
+ * [Variable Reference Substitutions](#variable-reference-substitutions)
+ * [Download GPG](#download-gpg)
+ * [Set up a GPG key](#set-up-a-gpg-key)
+ * [Sign your GPG key](#sign-your-gpg-key)
+ * [Publish your key](#publish-your-key)
+ * [Import another GPG key](#import-another-gpg-key)
+ * [Verify a key](#verify-a-key)
+ * [Sign an external key](#sign-an-external-key)
+ * [Web of trust](#web-of-trust)
+ * [Set up git with your key](#set-up-git-with-your-key)
+ * [Signing code](#signing-code)
+ * [Verifying a signature](#verifying-a-signature)
+ * [Set up GitHub with your key](#set-up-github-with-your-key)
+ * [Signing a release artifact](#signing-a-release-artifact)
+ * [Verifying a release signature](#verifying-a-release-signature)
+
+## The Objective
+
+Our aim is to instruct users on how to sign their commits, verify other's
signatures, and do the same for official releases of Apache NiFi.
+
+## Background Material
+
+ - These documents are helpful for general environmental setup to perform
GPG signing and signature verification
+- [Apache PGP Info][apache-pgp]
+- [Apache Release Signing][apache-release-signing]
+- [Git Ready: Signing Releases with GPG][git-sign-tag-instructs]
+- [RFC 4880: IETF Standard Spec for OpenPGP][rfc-4880]
+- [GitHub Blog: GPG Signature Verification][github-gpg-signing]
+- [Git Ready: gpg-sign releases][git-sign-tag-instructs]
+- [GitHub Help: Signing Commits Using GPG][github-help-gpg]
+- [GitHub Help: Telling Git About Your GPG Key][git-config-gpg]
+- [Git Docs: Git Tools Signing Your Work][git-gpg]
+- [PGP Web of Trust][web-of-trust]
+
+## Terms
+
+ * **Asymmetric Cryptography** - a type of cryptography which relies on
*key pairs* -- a *public* and *private* key which are mathematically-related
such that no other component key matches. This cryptography offers the
following actions: **encrypt**, **decrypt**, **sign**, and **verify**
+ * **Cryptographic Signature** - a series of bytes which are the result of
a signing operation such that only the possessor of a specific private key
could have generated this signature. A valid signature indicates that the
possessor of said key performed the operation (non-repudiable)
+
+## Variable Reference
Substitutions
+
+Throughout this guide, references must be made to names and values that
will vary from release to release. For clarity
+those variable values have been written like Bash variable references.
When a term like
+"```/tmp/src/nifi-${NIFI_VERSION}```" is seen in an instruction or email
template it should be replaced with
+"```/tmp/src/nifi-1.7.0```" when working the release of "Apache NiFi
1.7.0".
+
+ * Substitutions used in tasks and email templates
+
+ReferenceExample value Description
+=== ===
+${BRANCH}master the development branch on
which the release is based.
+${NIFI_VERSION} 1.7.0 the version currently in
development on the release branch.
+${NEXT_VERSION} 1.8.0-SNAPSHOT the future version for
development on the release branch.
+${JIRA_TICKET} NIFI-2112 the JIRA ticket created by
the release manager for the release tasks.
+${RC}2 the Release Candidate index
start at 1 for the first release candidate.
+${RC_TAG_COMMIT_ID} the 40 byte commit ID of the
RC tag created during the Maven release process.
+${STAGING_REPO_ID} orgapachenifi-1088 the temporary repository ID
where staged artifacts have been placed.
+${RM_USERID} johndoe the Apache account ID of
Release Manager.
+${RELEASE_TAG} rel/nifi-1.7.0 the Git repository tag for
the source code as released.
+${VOTE_THREAD_
[GitHub] nifi-site pull request #27: Added GPG Guide
Github user andrewmlim commented on a diff in the pull request:
https://github.com/apache/nifi-site/pull/27#discussion_r201807293
--- Diff: src/pages/markdown/gpg.md ---
@@ -0,0 +1,524 @@
+---
+title: GPG (Gnu Privacy Guard / Open PGP) Signatures
+---
+
+# Apache NiFi Release Signatures and Code Signing
+
+The purpose of this document is to capture and describe the steps involved
in generating and verifying cryptographic signatures of official releases of
Apache NiFi, as well as configuring cryptographic signatures of individual code
commits. It is written for contributors, committers, and users of Apache NiFi
(and related applications).
+
+## Table of Contents
+ * [The Objective](#the-objective)
+ * [Background Material](#background-material)
+ * [Terms](#terms)
+ * [Variable Reference Substitutions](#variable-reference-substitutions)
+ * [Download GPG](#download-gpg)
+ * [Set up a GPG key](#set-up-a-gpg-key)
+ * [Sign your GPG key](#sign-your-gpg-key)
+ * [Publish your key](#publish-your-key)
+ * [Import another GPG key](#import-another-gpg-key)
+ * [Verify a key](#verify-a-key)
+ * [Sign an external key](#sign-an-external-key)
+ * [Web of trust](#web-of-trust)
+ * [Set up git with your key](#set-up-git-with-your-key)
+ * [Signing code](#signing-code)
+ * [Verifying a signature](#verifying-a-signature)
+ * [Set up GitHub with your key](#set-up-github-with-your-key)
+ * [Signing a release artifact](#signing-a-release-artifact)
+ * [Verifying a release signature](#verifying-a-release-signature)
+
+## The Objective
+
+Our aim is to instruct users on how to sign their commits, verify other's
signatures, and do the same for official releases of Apache NiFi.
+
+## Background Material
+
+ - These documents are helpful for general environmental setup to perform
GPG signing and signature verification
+- [Apache PGP Info][apache-pgp]
+- [Apache Release Signing][apache-release-signing]
+- [Git Ready: Signing Releases with GPG][git-sign-tag-instructs]
+- [RFC 4880: IETF Standard Spec for OpenPGP][rfc-4880]
+- [GitHub Blog: GPG Signature Verification][github-gpg-signing]
+- [Git Ready: gpg-sign releases][git-sign-tag-instructs]
+- [GitHub Help: Signing Commits Using GPG][github-help-gpg]
+- [GitHub Help: Telling Git About Your GPG Key][git-config-gpg]
+- [Git Docs: Git Tools Signing Your Work][git-gpg]
+- [PGP Web of Trust][web-of-trust]
+
+## Terms
+
+ * **Asymmetric Cryptography** - a type of cryptography which relies on
*key pairs* -- a *public* and *private* key which are mathematically-related
such that no other component key matches. This cryptography offers the
following actions: **encrypt**, **decrypt**, **sign**, and **verify**
+ * **Cryptographic Signature** - a series of bytes which are the result of
a signing operation such that only the possessor of a specific private key
could have generated this signature. A valid signature indicates that the
possessor of said key performed the operation (non-repudiable)
+
+## Variable Reference
Substitutions
+
+Throughout this guide, references must be made to names and values that
will vary from release to release. For clarity
+those variable values have been written like Bash variable references.
When a term like
+"```/tmp/src/nifi-${NIFI_VERSION}```" is seen in an instruction or email
template it should be replaced with
+"```/tmp/src/nifi-1.7.0```" when working the release of "Apache NiFi
1.7.0".
+
+ * Substitutions used in tasks and email templates
+
+ReferenceExample value Description
+=== ===
+${BRANCH}master the development branch on
which the release is based.
+${NIFI_VERSION} 1.7.0 the version currently in
development on the release branch.
+${NEXT_VERSION} 1.8.0-SNAPSHOT the future version for
development on the release branch.
+${JIRA_TICKET} NIFI-2112 the JIRA ticket created by
the release manager for the release tasks.
+${RC}2 the Release Candidate index
start at 1 for the first release candidate.
+${RC_TAG_COMMIT_ID} the 40 byte commit ID of the
RC tag created during the Maven release process.
+${STAGING_REPO_ID} orgapachenifi-1088 the temporary repository ID
where staged artifacts have been placed.
+${RM_USERID} johndoe the Apache account ID of
Release Manager.
+${RELEASE_TAG} rel/nifi-1.7.0 the Git repository tag for
the source code as released.
+${VOTE_THREAD_
[GitHub] nifi-site pull request #27: Added GPG Guide
Github user andrewmlim commented on a diff in the pull request:
https://github.com/apache/nifi-site/pull/27#discussion_r201806357
--- Diff: src/pages/markdown/gpg.md ---
@@ -0,0 +1,524 @@
+---
+title: GPG (Gnu Privacy Guard / Open PGP) Signatures
+---
+
+# Apache NiFi Release Signatures and Code Signing
+
+The purpose of this document is to capture and describe the steps involved
in generating and verifying cryptographic signatures of official releases of
Apache NiFi, as well as configuring cryptographic signatures of individual code
commits. It is written for contributors, committers, and users of Apache NiFi
(and related applications).
+
+## Table of Contents
+ * [The Objective](#the-objective)
+ * [Background Material](#background-material)
+ * [Terms](#terms)
+ * [Variable Reference Substitutions](#variable-reference-substitutions)
+ * [Download GPG](#download-gpg)
+ * [Set up a GPG key](#set-up-a-gpg-key)
+ * [Sign your GPG key](#sign-your-gpg-key)
+ * [Publish your key](#publish-your-key)
+ * [Import another GPG key](#import-another-gpg-key)
+ * [Verify a key](#verify-a-key)
+ * [Sign an external key](#sign-an-external-key)
+ * [Web of trust](#web-of-trust)
+ * [Set up git with your key](#set-up-git-with-your-key)
+ * [Signing code](#signing-code)
+ * [Verifying a signature](#verifying-a-signature)
+ * [Set up GitHub with your key](#set-up-github-with-your-key)
+ * [Signing a release artifact](#signing-a-release-artifact)
+ * [Verifying a release signature](#verifying-a-release-signature)
+
+## The Objective
+
+Our aim is to instruct users on how to sign their commits, verify other's
signatures, and do the same for official releases of Apache NiFi.
+
+## Background Material
+
+ - These documents are helpful for general environmental setup to perform
GPG signing and signature verification
+- [Apache PGP Info][apache-pgp]
+- [Apache Release Signing][apache-release-signing]
+- [Git Ready: Signing Releases with GPG][git-sign-tag-instructs]
+- [RFC 4880: IETF Standard Spec for OpenPGP][rfc-4880]
+- [GitHub Blog: GPG Signature Verification][github-gpg-signing]
+- [Git Ready: gpg-sign releases][git-sign-tag-instructs]
+- [GitHub Help: Signing Commits Using GPG][github-help-gpg]
+- [GitHub Help: Telling Git About Your GPG Key][git-config-gpg]
+- [Git Docs: Git Tools Signing Your Work][git-gpg]
+- [PGP Web of Trust][web-of-trust]
+
+## Terms
+
+ * **Asymmetric Cryptography** - a type of cryptography which relies on
*key pairs* -- a *public* and *private* key which are mathematically-related
such that no other component key matches. This cryptography offers the
following actions: **encrypt**, **decrypt**, **sign**, and **verify**
+ * **Cryptographic Signature** - a series of bytes which are the result of
a signing operation such that only the possessor of a specific private key
could have generated this signature. A valid signature indicates that the
possessor of said key performed the operation (non-repudiable)
+
+## Variable Reference
Substitutions
+
+Throughout this guide, references must be made to names and values that
will vary from release to release. For clarity
+those variable values have been written like Bash variable references.
When a term like
+"```/tmp/src/nifi-${NIFI_VERSION}```" is seen in an instruction or email
template it should be replaced with
+"```/tmp/src/nifi-1.7.0```" when working the release of "Apache NiFi
1.7.0".
+
+ * Substitutions used in tasks and email templates
+
+ReferenceExample value Description
+=== ===
+${BRANCH}master the development branch on
which the release is based.
+${NIFI_VERSION} 1.7.0 the version currently in
development on the release branch.
+${NEXT_VERSION} 1.8.0-SNAPSHOT the future version for
development on the release branch.
+${JIRA_TICKET} NIFI-2112 the JIRA ticket created by
the release manager for the release tasks.
+${RC}2 the Release Candidate index
start at 1 for the first release candidate.
+${RC_TAG_COMMIT_ID} the 40 byte commit ID of the
RC tag created during the Maven release process.
+${STAGING_REPO_ID} orgapachenifi-1088 the temporary repository ID
where staged artifacts have been placed.
+${RM_USERID} johndoe the Apache account ID of
Release Manager.
+${RELEASE_TAG} rel/nifi-1.7.0 the Git repository tag for
the source code as released.
+${VOTE_THREAD_
[GitHub] nifi-site pull request #27: Added GPG Guide
Github user andrewmlim commented on a diff in the pull request:
https://github.com/apache/nifi-site/pull/27#discussion_r20170
--- Diff: src/pages/markdown/gpg.md ---
@@ -0,0 +1,524 @@
+---
+title: GPG (Gnu Privacy Guard / Open PGP) Signatures
+---
+
+# Apache NiFi Release Signatures and Code Signing
+
+The purpose of this document is to capture and describe the steps involved
in generating and verifying cryptographic signatures of official releases of
Apache NiFi, as well as configuring cryptographic signatures of individual code
commits. It is written for contributors, committers, and users of Apache NiFi
(and related applications).
+
+## Table of Contents
+ * [The Objective](#the-objective)
+ * [Background Material](#background-material)
+ * [Terms](#terms)
+ * [Variable Reference Substitutions](#variable-reference-substitutions)
+ * [Download GPG](#download-gpg)
+ * [Set up a GPG key](#set-up-a-gpg-key)
+ * [Sign your GPG key](#sign-your-gpg-key)
+ * [Publish your key](#publish-your-key)
+ * [Import another GPG key](#import-another-gpg-key)
+ * [Verify a key](#verify-a-key)
+ * [Sign an external key](#sign-an-external-key)
+ * [Web of trust](#web-of-trust)
+ * [Set up git with your key](#set-up-git-with-your-key)
+ * [Signing code](#signing-code)
+ * [Verifying a signature](#verifying-a-signature)
+ * [Set up GitHub with your key](#set-up-github-with-your-key)
+ * [Signing a release artifact](#signing-a-release-artifact)
+ * [Verifying a release signature](#verifying-a-release-signature)
+
+## The Objective
+
+Our aim is to instruct users on how to sign their commits, verify other's
signatures, and do the same for official releases of Apache NiFi.
+
+## Background Material
+
+ - These documents are helpful for general environmental setup to perform
GPG signing and signature verification
+- [Apache PGP Info][apache-pgp]
+- [Apache Release Signing][apache-release-signing]
+- [Git Ready: Signing Releases with GPG][git-sign-tag-instructs]
+- [RFC 4880: IETF Standard Spec for OpenPGP][rfc-4880]
+- [GitHub Blog: GPG Signature Verification][github-gpg-signing]
+- [Git Ready: gpg-sign releases][git-sign-tag-instructs]
+- [GitHub Help: Signing Commits Using GPG][github-help-gpg]
+- [GitHub Help: Telling Git About Your GPG Key][git-config-gpg]
+- [Git Docs: Git Tools Signing Your Work][git-gpg]
+- [PGP Web of Trust][web-of-trust]
+
+## Terms
+
+ * **Asymmetric Cryptography** - a type of cryptography which relies on
*key pairs* -- a *public* and *private* key which are mathematically-related
such that no other component key matches. This cryptography offers the
following actions: **encrypt**, **decrypt**, **sign**, and **verify**
+ * **Cryptographic Signature** - a series of bytes which are the result of
a signing operation such that only the possessor of a specific private key
could have generated this signature. A valid signature indicates that the
possessor of said key performed the operation (non-repudiable)
+
+## Variable Reference
Substitutions
+
+Throughout this guide, references must be made to names and values that
will vary from release to release. For clarity
+those variable values have been written like Bash variable references.
When a term like
+"```/tmp/src/nifi-${NIFI_VERSION}```" is seen in an instruction or email
template it should be replaced with
+"```/tmp/src/nifi-1.7.0```" when working the release of "Apache NiFi
1.7.0".
+
+ * Substitutions used in tasks and email templates
+
+ReferenceExample value Description
+=== ===
+${BRANCH}master the development branch on
which the release is based.
+${NIFI_VERSION} 1.7.0 the version currently in
development on the release branch.
+${NEXT_VERSION} 1.8.0-SNAPSHOT the future version for
development on the release branch.
+${JIRA_TICKET} NIFI-2112 the JIRA ticket created by
the release manager for the release tasks.
+${RC}2 the Release Candidate index
start at 1 for the first release candidate.
+${RC_TAG_COMMIT_ID} the 40 byte commit ID of the
RC tag created during the Maven release process.
+${STAGING_REPO_ID} orgapachenifi-1088 the temporary repository ID
where staged artifacts have been placed.
+${RM_USERID} johndoe the Apache account ID of
Release Manager.
+${RELEASE_TAG} rel/nifi-1.7.0 the Git repository tag for
the source code as released.
+${VOTE_THREAD_
[GitHub] nifi-site pull request #27: Added GPG Guide
Github user andrewmlim commented on a diff in the pull request:
https://github.com/apache/nifi-site/pull/27#discussion_r201777645
--- Diff: src/pages/markdown/gpg.md ---
@@ -0,0 +1,524 @@
+---
+title: GPG (Gnu Privacy Guard / Open PGP) Signatures
+---
+
+# Apache NiFi Release Signatures and Code Signing
+
+The purpose of this document is to capture and describe the steps involved
in generating and verifying cryptographic signatures of official releases of
Apache NiFi, as well as configuring cryptographic signatures of individual code
commits. It is written for contributors, committers, and users of Apache NiFi
(and related applications).
+
+## Table of Contents
+ * [The Objective](#the-objective)
+ * [Background Material](#background-material)
+ * [Terms](#terms)
+ * [Variable Reference Substitutions](#variable-reference-substitutions)
+ * [Download GPG](#download-gpg)
+ * [Set up a GPG key](#set-up-a-gpg-key)
+ * [Sign your GPG key](#sign-your-gpg-key)
+ * [Publish your key](#publish-your-key)
+ * [Import another GPG key](#import-another-gpg-key)
+ * [Verify a key](#verify-a-key)
+ * [Sign an external key](#sign-an-external-key)
+ * [Web of trust](#web-of-trust)
+ * [Set up git with your key](#set-up-git-with-your-key)
+ * [Signing code](#signing-code)
+ * [Verifying a signature](#verifying-a-signature)
+ * [Set up GitHub with your key](#set-up-github-with-your-key)
+ * [Signing a release artifact](#signing-a-release-artifact)
+ * [Verifying a release signature](#verifying-a-release-signature)
+
+## The Objective
+
+Our aim is to instruct users on how to sign their commits, verify other's
signatures, and do the same for official releases of Apache NiFi.
+
+## Background Material
+
+ - These documents are helpful for general environmental setup to perform
GPG signing and signature verification
+- [Apache PGP Info][apache-pgp]
+- [Apache Release Signing][apache-release-signing]
+- [Git Ready: Signing Releases with GPG][git-sign-tag-instructs]
+- [RFC 4880: IETF Standard Spec for OpenPGP][rfc-4880]
+- [GitHub Blog: GPG Signature Verification][github-gpg-signing]
+- [Git Ready: gpg-sign releases][git-sign-tag-instructs]
+- [GitHub Help: Signing Commits Using GPG][github-help-gpg]
+- [GitHub Help: Telling Git About Your GPG Key][git-config-gpg]
+- [Git Docs: Git Tools Signing Your Work][git-gpg]
+- [PGP Web of Trust][web-of-trust]
+
+## Terms
+
+ * **Asymmetric Cryptography** - a type of cryptography which relies on
*key pairs* -- a *public* and *private* key which are mathematically-related
such that no other component key matches. This cryptography offers the
following actions: **encrypt**, **decrypt**, **sign**, and **verify**
+ * **Cryptographic Signature** - a series of bytes which are the result of
a signing operation such that only the possessor of a specific private key
could have generated this signature. A valid signature indicates that the
possessor of said key performed the operation (non-repudiable)
+
+## Variable Reference
Substitutions
+
+Throughout this guide, references must be made to names and values that
will vary from release to release. For clarity
+those variable values have been written like Bash variable references.
When a term like
+"```/tmp/src/nifi-${NIFI_VERSION}```" is seen in an instruction or email
template it should be replaced with
+"```/tmp/src/nifi-1.7.0```" when working the release of "Apache NiFi
1.7.0".
+
+ * Substitutions used in tasks and email templates
+
+ReferenceExample value Description
+=== ===
+${BRANCH}master the development branch on
which the release is based.
+${NIFI_VERSION} 1.7.0 the version currently in
development on the release branch.
+${NEXT_VERSION} 1.8.0-SNAPSHOT the future version for
development on the release branch.
+${JIRA_TICKET} NIFI-2112 the JIRA ticket created by
the release manager for the release tasks.
+${RC}2 the Release Candidate index
start at 1 for the first release candidate.
+${RC_TAG_COMMIT_ID} the 40 byte commit ID of the
RC tag created during the Maven release process.
+${STAGING_REPO_ID} orgapachenifi-1088 the temporary repository ID
where staged artifacts have been placed.
+${RM_USERID} johndoe the Apache account ID of
Release Manager.
+${RELEASE_TAG} rel/nifi-1.7.0 the Git repository tag for
the source code as released.
+${VOTE_THREAD_
[GitHub] nifi-site pull request #27: Added GPG Guide
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi-site/pull/27#discussion_r201772672 --- Diff: src/pages/markdown/gpg.md --- @@ -0,0 +1,524 @@ +--- +title: GPG (Gnu Privacy Guard / Open PGP) Signatures +--- + +# Apache NiFi Release Signatures and Code Signing + +The purpose of this document is to capture and describe the steps involved in generating and verifying cryptographic signatures of official releases of Apache NiFi, as well as configuring cryptographic signatures of individual code commits. It is written for contributors, committers, and users of Apache NiFi (and related applications). + +## Table of Contents + * [The Objective](#the-objective) + * [Background Material](#background-material) + * [Terms](#terms) + * [Variable Reference Substitutions](#variable-reference-substitutions) + * [Download GPG](#download-gpg) + * [Set up a GPG key](#set-up-a-gpg-key) + * [Sign your GPG key](#sign-your-gpg-key) + * [Publish your key](#publish-your-key) + * [Import another GPG key](#import-another-gpg-key) + * [Verify a key](#verify-a-key) + * [Sign an external key](#sign-an-external-key) + * [Web of trust](#web-of-trust) + * [Set up git with your key](#set-up-git-with-your-key) + * [Signing code](#signing-code) + * [Verifying a signature](#verifying-a-signature) + * [Set up GitHub with your key](#set-up-github-with-your-key) + * [Signing a release artifact](#signing-a-release-artifact) + * [Verifying a release signature](#verifying-a-release-signature) + +## The Objective + +Our aim is to instruct users on how to sign their commits, verify other's signatures, and do the same for official releases of Apache NiFi. + +## Background Material + + - These documents are helpful for general environmental setup to perform GPG signing and signature verification --- End diff -- Consider adding a colon at the end or adding more space before the bulleted list. ---
[GitHub] nifi-site pull request #27: Added GPG Guide
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi-site/pull/27#discussion_r201770983 --- Diff: src/pages/markdown/gpg.md --- @@ -0,0 +1,524 @@ +--- +title: GPG (Gnu Privacy Guard / Open PGP) Signatures +--- + +# Apache NiFi Release Signatures and Code Signing + +The purpose of this document is to capture and describe the steps involved in generating and verifying cryptographic signatures of official releases of Apache NiFi, as well as configuring cryptographic signatures of individual code commits. It is written for contributors, committers, and users of Apache NiFi (and related applications). + +## Table of Contents + * [The Objective](#the-objective) + * [Background Material](#background-material) + * [Terms](#terms) + * [Variable Reference Substitutions](#variable-reference-substitutions) + * [Download GPG](#download-gpg) + * [Set up a GPG key](#set-up-a-gpg-key) + * [Sign your GPG key](#sign-your-gpg-key) + * [Publish your key](#publish-your-key) + * [Import another GPG key](#import-another-gpg-key) + * [Verify a key](#verify-a-key) + * [Sign an external key](#sign-an-external-key) + * [Web of trust](#web-of-trust) + * [Set up git with your key](#set-up-git-with-your-key) --- End diff -- Capitalize "Git" for consistency ---
[GitHub] nifi-site pull request #27: Added GPG Guide
Github user andrewmlim commented on a diff in the pull request: https://github.com/apache/nifi-site/pull/27#discussion_r201770601 --- Diff: src/pages/markdown/gpg.md --- @@ -0,0 +1,524 @@ +--- +title: GPG (Gnu Privacy Guard / Open PGP) Signatures +--- + +# Apache NiFi Release Signatures and Code Signing + +The purpose of this document is to capture and describe the steps involved in generating and verifying cryptographic signatures of official releases of Apache NiFi, as well as configuring cryptographic signatures of individual code commits. It is written for contributors, committers, and users of Apache NiFi (and related applications). + +## Table of Contents --- End diff -- The following links are broken: Set up a GPG key Sign your GPG key Sign an external key Signing code ---
[GitHub] nifi pull request #2810: NIFI-5330 Fixed broken image in Variables in Versio...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi/pull/2810 NIFI-5330 Fixed broken image in Variables in Versioned Flows section ⦠â¦of User Guide You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi NIFI-5330 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2810.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2810 commit 57c2bc47251c69f58665cd76e905db6cfe30938c Author: Andrew Lim Date: 2018-06-25T14:56:27Z NIFI-5330 Fixed broken image in Variables in Versioned Flows section of User Guide ---
[GitHub] nifi-registry pull request #120: NIFIREG-56: Added element ids to facilitate...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi-registry/pull/120 NIFIREG-56: Added element ids to facilitate bucket testing use cases These are the ids I needed to do some automated UI testing around Bucket test cases (Bucket creation/deletion/duplicates etc.). If more ids are needed for other test cases, will file separate more specific Jiras. You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi-registry NIFIREG-56 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi-registry/pull/120.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #120 commit cdb2cb81650b0f04e3390397725e92b57ef0579e Author: Andrew Lim Date: 2018-05-31T17:55:48Z NIFIREG-56: Added element ids to facilitate bucket testing use cases ---
[GitHub] nifi pull request #2719: NIFI-4585 Add nifi.cluster.node.max.concurrent.requ...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi/pull/2719 NIFI-4585 Add nifi.cluster.node.max.concurrent.requests to Cluster No⦠â¦de Properties section of Admin Guide You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi NIFI-4585 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2719.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2719 commit d4f63af1b2b0243d65f30043a0d52dbd38d35b14 Author: Andrew Lim <andrewlim.apache@...> Date: 2018-05-18T16:40:23Z NIFI-4585 Add nifi.cluster.node.max.concurrent.requests to Cluster Node Properties section of Admin Guide ---
[GitHub] nifi pull request #2716: NIFI-5205 Updated default value for nifi.content.cl...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi/pull/2716 NIFI-5205 Updated default value for nifi.content.claim.max.appendable⦠â¦.size in Admin Guide Also fixed the formatting of some default values while I was in there. You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi NIFI-5205 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2716.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2716 commit 5fafedc07742af5cd71afca073b0062d3202c4cf Author: Andrew Lim <andrewlim.apache@...> Date: 2018-05-17T19:00:04Z NIFI-5205 Updated default value for nifi.content.claim.max.appendable.size in Admin Guide ---
[GitHub] nifi pull request #2710: NIFI-2966 Add policy resources to Access Policies t...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi/pull/2710 NIFI-2966 Add policy resources to Access Policies tables in Admin Guide You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi NIFI-2966 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2710.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2710 commit 7e68b74e92d1d63c27663c38236b299ebaba0975 Author: Andrew Lim <andrewlim.apache@...> Date: 2018-05-16T18:13:45Z NIFI-2966 Add policy resources to Access Policies tables in Admin Guide ---
[GitHub] nifi-registry pull request #113: NIFIREG-163 Added JDK information to System...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi-registry/pull/113 NIFIREG-163 Added JDK information to System Requirements section of A⦠â¦dmin Guide Also added formatting to a default system property to be consistent with others. You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi-registry NIFIREG-163 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi-registry/pull/113.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #113 commit 64e72cd494d70d07c8ea9a63b7248fa16017dbc0 Author: Andrew Lim <andrewlim.apache@...> Date: 2018-04-17T17:44:48Z NIFIREG-163 Added JDK information to System Requirements section of Admin Guide ---
[GitHub] nifi issue #2633: NIFI-5066: Allow global enable/disable component requests
Github user andrewmlim commented on the issue: https://github.com/apache/nifi/pull/2633 Changes look good. Enable/disable and start/stop buttons behave consistently. This is minor, but it would be nice if all of these buttons were greyed out (or unavailable in the context menu) when there were no components available i.e. when the process group is empty. ---
[GitHub] nifi pull request #2627: NIFI-5074 Added section Variables in Versioned Flow...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi/pull/2627 NIFI-5074 Added section Variables in Versioned Flows to User Guide You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi NIFI-5074 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2627.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2627 commit a75876f3b353caa56bd83f4198ac1be0dd32 Author: Andrew Lim <andrewlim.apache@...> Date: 2018-04-11T16:24:16Z NIFI-5074 Added section Variables in Versioned Flows to User Guide ---
[GitHub] nifi pull request #2624: NIFI-5063 Added screenshots and supporting text for...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi/pull/2624 NIFI-5063 Added screenshots and supporting text for Primary Node proc⦠â¦essors Also, fixed some single quote formatting inconsistencies throughout the User Guide. You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi NIFI-5063 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2624.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2624 commit b320d142ab09ac00a64b26cabc8a9bb158d7fd05 Author: Andrew Lim <andrewlim.apache@...> Date: 2018-04-10T17:30:19Z NIFI-5063 Added screenshots and supporting text for Primary Node processors ---
[GitHub] nifi pull request #2620: NIFI-4941 Updated nifi.sensitive.props.additional.k...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi/pull/2620 NIFI-4941 Updated nifi.sensitive.props.additional.keys description to⦠⦠refer to nifi.properties Also corrected formatting for a reference to bootstrap.conf file You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi NIFI-4941 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2620.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2620 commit a4c5bc5cd58cf39f715732750a813d227d261da7 Author: Andrew Lim <andrewlim.apache@...> Date: 2018-04-09T20:12:37Z NIFI-4941 Updated nifi.sensitive.props.additional.keys description to refer to nifi.properties ---
[GitHub] nifi pull request #2612: NIFI-5048 Corrected typo in KeytabCredentialsServic...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi/pull/2612 NIFI-5048 Corrected typo in KeytabCredentialsService controller servi⦠â¦ce description You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi NIFI-5048 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2612.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2612 commit 28fcfa6fc8e28b145ed899b5bd55c25ed632cab5 Author: Andrew Lim <andrewlim.apache@...> Date: 2018-04-06T18:20:20Z NIFI-5048 Corrected typo in KeytabCredentialsService controller service description ---
[GitHub] nifi pull request #2610: NIFI-5042 Added section Restricted Components in Ve...
GitHub user andrewmlim opened a pull request: https://github.com/apache/nifi/pull/2610 NIFI-5042 Added section Restricted Components in Versioned Flows and ⦠â¦edited related section in Adding Components to the Canvas You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrewmlim/nifi NIFI-5042 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2610.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2610 commit 10321b9dd09b6b70036b4be58b6514465e0dc250 Author: Andrew Lim <andrewlim.apache@...> Date: 2018-04-06T15:05:46Z NIFI-5042 Added section Restricted Components in Versioned Flows and edited related section in Adding Components to the Canvas ---
[GitHub] nifi issue #2515: NIFI-4885: Granular component restrictions
Github user andrewmlim commented on the issue: https://github.com/apache/nifi/pull/2515 @mcgilman Looks good! Thanks for including a fix for MoveHDFS. ---
