@PradNiFi1236    There are numerous steps in this process.  So lets start with some basics on Site-To-Site (S2S).  The S2SBulletinReportingTask works much like the NiFi Remote Process Group (RPG).  When configured with a Destination URL and enabled a background thread will run independently on an interval to fetch S2S details from the destination URL.  If the destination url is a node in a NiFi cluster, the returned S2S details will include the hostnames of all the nodes in the cluster, whether cluster nodes are configured to support RAW and/or HTTP transport protocols, the configured RAW port for each node, node load average, etc... Configuring just one destination URL from the target cluster does not change this behavior.  Configuring a comma separate list of nodes from the same destination cluster affords you HA.  If S2S details can't be retrieved from node URL 1, it then tries second URL, and so forth. Also keep in mind it does not matter what node URL of a NiFi cluster you are accessing, any component (processor, reporting task, controller service, etc) added to the canvas is replicated to all nodes in the NiFi cluster.   So when you enable this S2SBulletinReporting task, all nodes are going to try to fetch S2S details.  Each node in a NIFi cluster has all the same components and executes all the same components (with exception of processors that can be scheduled to execute on primary node only). This means that all node will be trying to send generated bulletins to your cluster nodes. So by what you shared, it looks like the background thread that fetches those S2S details is failing due to timeout.  This could be for any number of reasons.  Your configured keystore in the sslContextService does not contain a single PrivateKeyEntry that can be trusted by the truststore configured in the nifi.properties file on all 3 of your destination nodes.  The PrivateKeyEntry presented by the 3 NiFi nodes to the controller service is not trusted by what exists in the truststore configured in your SSLConTextService.  keystore used in sslContextService does not have a clientAuth PrivtaeKeyEntry in it. nifi.remote.input.secure is not set to true. nifi.remote.input.http.enabled not set to true.   There are several authorization policies in play here as well, but I don't think you have even gotten that far yet. Retrieve site-to-site details  <-- The privateKeyEntry from the keystore configured in the sslContextService will need to be authorized to retrieve these S2S details.  The keystore used in each of your 3 NiFi node's sslContext service may have unique DNs for their PrivateKeyEntry.  So all three of those unique keys would need to be authorized Receive data via site-to-site  <-- The privateKeyEntry from the keystore configured in the sslContextService will need to be authorized to retrieve these S2S details.  The keystore used in each of your 3 NiFi node's sslContext service may have unique DNs for their PrivateKeyEntry.  So all three of those unique keys would need to be authorized.  This allows the S2SBulletinReporting task to see this bulletinmonitoring remote input port as an option to send bulletins to. But if you were getting past authentication and failing on authorization, your exception would be different.  Instead of timeouts, you would be seeing not authorized exceptions. If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt ... View more

@Alevc  Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target The above exception you are encountering with TLS is caused by a lack of a complete trust chain in the mutual TLS handshake. On each side (server and client) of your TLS connection, you will have a keystore containing a PrivateKey entry (Will support and extended key usage (EKU) of clientAuth, serverAuth, or both) that either your client or server will use to identify itself.   That PrivateKey entry will have an owner and issuer DN associated with it.   The issuer is the signer for the owner.  Each side will also have a truststore (just another keystore by a different name containing a bunch of TrustedCertEntry(s)) that would need to contain the trustedCertEntry for the issuer/signer of your PrivateKeyEntry.  It is also very common that the issuer/signer trustedCertEntry has an owner DN and Issuer DN that do not match. This means that that issuer was just an intermediate Certificate Authority (CA) and was issued/signed by another CA.  As such the truststore would need to also contain the TrustedCertEntry for that next level issuer CA.  This continues until you reach the root CA trustedCertEntry where the owner and issuer have the same DN.  This is known as the rootCA for your PriavteKeyEntry.   Having all the intermediate CA(s) and the root CA, means you have the complete trust chain in your truststore.  This process applies in both directions in the mutual TSL handshake.  Meaning your clientAuth certificate presented by your Kafka Consumer must have its complete trust chain in the Kafka servers truststore.  And the ServerAuth certificate presented by your server must have its complete trust chain present in the truststore used by your client Kafka consumer.   Note: I am over simplifying this mutual TLS handshake (private keys themselves are never shared and there is more in the server and client hello exchanges in the TLS handshake), but intent is to focus at a high level on what your issue is caused by specifically. So to get past your issue, you need to make sure the truststore used by your client and server side contain all the CAs trust chain trustedCertEntries. If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt ... View more

@rafy  Once you have created the certificates for your other two users as @DigitalPlumber suggested, you would need to connect to your NiFi as the admin user you setup during initial securing of your NiFi and these two new users via the NiFi global menu (upper right corner) --> Users.   Then you would need to authorize those new user identities against any policies needed for them to perform the actions you want them to be allowed.  https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#config-users-access-policies   Hope this helps, Matt ... View more

@Hashem1980  Neither the ConsumeIMAP or ConsumePOP3 NiFi processors support Oauth2 for authentication. NiFi does have an StandardOauth2AccessTokenProvider controller service.  I would recommend opening an Apache NiFi Jira asking to have Oauth2 via this existing controller service integrated in to these processors.  As an open source project contribution are always welcome. If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt ... View more

@shashikumar  NiFi only requires the the Java Runtime Environment (JRE).  Latest versions of NiFi support both Java 8 or Java 11: system_requirements    The JDK contains, in addition to the JRE, additional development tools like compilers, debuggers, etc.  These may be useful to you depending on whether or not you intend to compile java code within your dataflow (not a requirement of any components like processors, controller services, reporting tasks, etc included with NiFi) or create your own custom NiFi components. If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt ... View more

@Chakkara  Updating a parameter context is a multi command process. 1. Fist you must GET the current parameter context configuration: curl -k -X GET https://<hostname>:<port>/nifi-api/parameter-contexts/<parameter context UUID> --compressed       - This will return a potentially large json which will include the current revision, all the parameter contexts from that parameter context and all the referencing components.  Assuming your NIFi is secured, your'll also need to include a method of authentication (client certificate, bearer token) in the above request. 2. Next you will POST your update-request using detail from above json response in step 1. curl -k 'https://<hostname>:<port>/nifi-api/parameter-contexts/<PARAMETR Context UUID>/update-requests' --data-raw $'{"revision":{"version":<num from step 1>},"id":"<PARAMETR Context UUID>","uri":"https://<hostname>:<port>/nifi-api/parameter-contexts/<PARAMETR Context UUID>","permissions":{"canRead":true,"canWrite":true},"component":{"name":"param-test","description":"","parameters":[{"parameter":{"name":"<Parameter name>","sensitive":false,"value":"<new parameter value>","description":""}}],"boundProcessGroups":[{"revision":{"clientId":"edcad62f-0181-1000-2fc6-de0c25282a3b","version":<num from step 1>},"id":"70b33f0a-e362-1c0b-8147-8fada18d56bd","position":{"x":136,"y":-2456},"permissions":{"canRead":true,"canWrite":true},"component":{"id":"70b33f0a-e362-1c0b-8147-8fada18d56bd","parentGroupId":"7930f131-017b-1000-0000-00007ece6b9d","position":{"x":136,"y":-2456},"name":"Param2","comments":"","variables":{},"parameterContext":{"id":"<PARAMETR Context UUID>","permissions":{"canRead":true,"canWrite":true},"component":{"id":"<PARAMETR Context UUID>","name":"param-test"}},"flowfileConcurrency":"UNBOUNDED","flowfileOutboundPolicy":"STREAM_WHEN_AVAILABLE","runningCount":2,"stoppedCount":0,"invalidCount":0,"disabledCount":0,"activeRemotePortCount":0,"inactiveRemotePortCount":0,"upToDateCount":0,"locallyModifiedCount":0,"staleCount":0,"locallyModifiedAndStaleCount":0,"syncFailureCount":0,"localInputPortCount":0,"localOutputPortCount":0,"publicInputPortCount":0,"publicOutputPortCount":0,"inputPortCount":0,"outputPortCount":0},"runningCount":2,"stoppedCount":0,"invalidCount":0,"disabledCount":0,"activeRemotePortCount":0,"inactiveRemotePortCount":0,"upToDateCount":0,"locallyModifiedCount":0,"staleCount":0,"locallyModifiedAndStaleCount":0,"syncFailureCount":0,"localInputPortCount":0,"localOutputPortCount":0,"publicInputPortCount":0,"publicOutputPortCount":0,"parameterContext":{"id":"994938a5-0180-1000-0000-00007cbba46b","permissions":{"canRead":true,"canWrite":true},"component":{"id":"<PARAMETR Context UUID>","name":"param-test"}},"inputPortCount":0,"outputPortCount":0},{"revision":{"clientId":"edcad62f-0181-1000-2fc6-de0c25282a3b","version":2},"id":"edcb3ff7-0181-1000-0000-00004abfd1ed","position":{"x":-323.1760214048029,"y":-2454.121877860687},"permissions":{"canRead":true,"canWrite":true},"component":{"id":"edcb3ff7-0181-1000-0000-00004abfd1ed","parentGroupId":"7930f131-017b-1000-0000-00007ece6b9d","position":{"x":-323.1760214048029,"y":-2454.121877860687},"name":"param1","comments":"","variables":{},"parameterContext":{"id":"994938a5-0180-1000-0000-00007cbba46b","permissions":{"canRead":true,"canWrite":true},"component":{"id":"<PARAMETR Context UUID>","name":"param-test"}},"flowfileConcurrency":"UNBOUNDED","flowfileOutboundPolicy":"STREAM_WHEN_AVAILABLE","runningCount":2,"stoppedCount":0,"invalidCount":0,"disabledCount":0,"activeRemotePortCount":0,"inactiveRemotePortCount":0,"upToDateCount":0,"locallyModifiedCount":0,"staleCount":0,"locallyModifiedAndStaleCount":0,"syncFailureCount":0,"localInputPortCount":0,"localOutputPortCount":0,"publicInputPortCount":0,"publicOutputPortCount":0,"inputPortCount":0,"outputPortCount":0},"runningCount":2,"stoppedCount":0,"invalidCount":0,"disabledCount":0,"activeRemotePortCount":0,"inactiveRemotePortCount":0,"upToDateCount":0,"locallyModifiedCount":0,"staleCount":0,"locallyModifiedAndStaleCount":0,"syncFailureCount":0,"localInputPortCount":0,"localOutputPortCount":0,"publicInputPortCount":0,"publicOutputPortCount":0,"parameterContext":{"id":"994938a5-0180-1000-0000-00007cbba46b","permissions":{"canRead":true,"canWrite":true},"component":{"id":"<PARAMETR Context UUID>","name":"param-test"}},"inputPortCount":0,"outputPortCount":0},{"revision":{"version":0},"id":"7930f131-017b-1000-0000-00007ece6b9d","position":{"x":328,"y":400},"permissions":{"canRead":true,"canWrite":true},"component":{"id":"7930f131-017b-1000-0000-00007ece6b9d","versionedComponentId":"136b68f9-1621-366e-8e8a-1db651ad8808","parentGroupId":"e377355c-017a-1000-2658-01d1a778332f","position":{"x":328,"y":400},"name":"Matt\'s PG","comments":"","variables":{},"versionControlInformation":{"groupId":"7930f131-017b-1000-0000-00007ece6b9d","registryId":"e97b2503-017a-1000-0000-00000c0a8abc","registryName":"nifi-sme-75.novalocal","bucketId":"19f7633f-5c1d-4d80-9d0d-d95c7e4885f8","bucketName":"new-bucket","flowId":"6add76b8-e56b-4d36-99e2-8aba4f5a9c33","flowName":"Matts-PG","flowDescription":"","version":2,"state":"LOCALLY_MODIFIED","stateExplanation":"Local changes have been made"},"parameterContext":{"id":"<PARAMETR Context UUID>","permissions":{"canRead":true,"canWrite":true},"component":{"id":"994938a5-0180-1000-0000-00007cbba46b","name":"param-test"}},"flowfileConcurrency":"UNBOUNDED","flowfileOutboundPolicy":"STREAM_WHEN_AVAILABLE","runningCount":39,"stoppedCount":109,"invalidCount":74,"disabledCount":7,"activeRemotePortCount":0,"inactiveRemotePortCount":2,"upToDateCount":0,"locallyModifiedCount":0,"staleCount":0,"locallyModifiedAndStaleCount":0,"syncFailureCount":0,"localInputPortCount":0,"localOutputPortCount":0,"publicInputPortCount":0,"publicOutputPortCount":0,"inputPortCount":0,"outputPortCount":0},"runningCount":39,"stoppedCount":109,"invalidCount":74,"disabledCount":7,"activeRemotePortCount":0,"inactiveRemotePortCount":2,"versionedFlowState":"LOCALLY_MODIFIED","upToDateCount":0,"locallyModifiedCount":0,"staleCount":0,"locallyModifiedAndStaleCount":0,"syncFailureCount":0,"localInputPortCount":0,"localOutputPortCount":0,"publicInputPortCount":0,"publicOutputPortCount":0,"parameterContext":{"id":"<PARAMETR Context UUID>","permissions":{"canRead":true,"canWrite":true},"component":{"id":"994938a5-0180-1000-0000-00007cbba46b","name":"param-test"}},"inputPortCount":0,"outputPortCount":0},{"revision":{"clientId":"edcad62f-0181-1000-2fc6-de0c25282a3b","version":2},"id":"373a39ad-0443-10ec-9e85-69445fefe75e","position":{"x":-320,"y":-2216},"permissions":{"canRead":true,"canWrite":true},"component":{"id":"373a39ad-0443-10ec-9e85-69445fefe75e","parentGroupId":"7930f131-017b-1000-0000-00007ece6b9d","position":{"x":-320,"y":-2216},"name":"param3","comments":"","variables":{},"parameterContext":{"id":"994938a5-0180-1000-0000-00007cbba46b","permissions":{"canRead":true,"canWrite":true},"component":{"id":"<PARAMETR Context UUID>","name":"param-test"}},"flowfileConcurrency":"UNBOUNDED","flowfileOutboundPolicy":"STREAM_WHEN_AVAILABLE","runningCount":2,"stoppedCount":0,"invalidCount":0,"disabledCount":0,"activeRemotePortCount":0,"inactiveRemotePortCount":0,"upToDateCount":0,"locallyModifiedCount":0,"staleCount":0,"locallyModifiedAndStaleCount":0,"syncFailureCount":0,"localInputPortCount":0,"localOutputPortCount":0,"publicInputPortCount":0,"publicOutputPortCount":0,"inputPortCount":0,"outputPortCount":0},"runningCount":2,"stoppedCount":0,"invalidCount":0,"disabledCount":0,"activeRemotePortCount":0,"inactiveRemotePortCount":0,"upToDateCount":0,"locallyModifiedCount":0,"staleCount":0,"locallyModifiedAndStaleCount":0,"syncFailureCount":0,"localInputPortCount":0,"localOutputPortCount":0,"publicInputPortCount":0,"publicOutputPortCount":0,"parameterContext":{"id":"994938a5-0180-1000-0000-00007cbba46b","permissions":{"canRead":true,"canWrite":true},"component":{"id":"<PARAMETR Context UUID>","name":"param-test"}},"inputPortCount":0,"outputPortCount":0}],"id":"<PARAMETR Context UUID>"}}' --compressed       - This will return the uri for this new update request.  A background process will take care of stopping changing, validating and starting all referenced components for the update parameter context. Assuming your NIFi is secured, your'll also need to include a method of authentication (client certificate, bearer token) in the above request. 3. Third you can execute a GET using the uri returned in step 2 to check progress of the request.   curl 'https://<hostname>:<port>/nifi-api/parameter-contexts/<PARAMETER CONTEXT UUID>/update-requests/<UPDATE REQUEST UUID form step 2 response>' -k --compressed      - This will return a json that will include within it the "percentCompleted".  You'll need to check this endpoint until it reports 100% complete. Assuming your NIFi is secured, your'll also need to include a method of authentication (client certificate, bearer token) in the above request. 4. Final step is a DELETE to remove the update request that is now completed.  Failing to do this leaves this request in NiFi Heap memory until a NiFi restart. curl -X DELETE 'https://<hostname>:<port>/nifi-api/parameter-contexts/<PARAMETER CONTEXT UUID>/update-requests/<UPDATE_REQUEST UUID from step 2 response>' -k --compressed      -    Assuming your NIFi is secured, your'll also need to include a method of authentication (client certificate, bearer token) in the above request. An easy way to help understand the --data-raw input needed for your specific update-request is to use the developer tolls found in most browsers to inspect/capture that actual rest-api calls made when you execute the actual action via the NiFi UI.   The browser developer tools will also allow you to right click on the triggering action and copy as curl.  You can then paste that action as a curl command in a terminal window and execute it yourself. Reference: https://nifi.apache.org/docs/nifi-docs/rest-api/index.html - specifically looking at the section for "Parameter Contexts" If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt ... View more