Member since
07-30-2019
3368
Posts
1615
Kudos Received
996
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
42 | 10-08-2025 10:52 AM | |
30 | 10-08-2025 10:36 AM | |
99 | 10-03-2025 06:04 AM | |
100 | 10-02-2025 07:44 AM | |
265 | 09-23-2025 10:09 AM |
10-01-2025
07:02 AM
@gunlomboy NiFi Site-To-Site (S2S) protocol was not designed for the use case you are trying to achieve. The ability to provide a comma separated list of hostnames in the Remote Process Group (RPG) exists simply to provide fault tolerance. The RPG will attempt to use the first hostname provided to fetch the S2S detail about the NiFi cluster from that host. These S2S details will include all the detail about the target NiFi cluster (This is why the RPG still distributed across all nodes in target cluster when only one hostname is provided). The extra hostnames provide fault tolerance for example lets say the hostname you configured is down, the RPG will attempt the second host to fetch S2S details. The S2S details fetched from the contacted host will include things like hostnames of all nodes connected to cluster, RAW enabled status, Raw Port for each host, Secure enabled, individual target node workload, etc. site-to-site-protocol-sequence By setting up firewall rules, you are not changing the S2S details being refreshed regularly and the RPG will continue to build a distribution algorithm that includes all the target host nodes. This means very inefficient transfer of FlowFiles. You might consider redesigning your dataflows to utilize PostHTTP processor (one for each host in target NiFi cluster with failure routed to other PostHTTP). Then setup a ListenHTTP on your receiving NIFi cluster. The postHTTP processor can be configured to "Send as FlowFile" so the NiFi Cluster will still receive the FlowFile content and associated FlowFile attributes/metadata just like how RPG sends FlowFiles. In Front of your ListenHTTP processor you could put a DistributeLoad processor to distribute FlowFiles being sent to your different target nodes. The downside to a setup like this is if you add additional nodes in your zone1 or zone2 of the target NiFi Cluster, You'll need to update your dataflows to add more PostHTTP processors for those new target hosts. You also lose the benefit of the workload based FlowFile distribution build into the S2S protocol. That being said, there is no other options since you can't change the functionality of the S2S protocol. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt
... View more
09-26-2025
06:24 AM
@ragshetty I shared the Apache Jira which documented the removal of the encrypt-config toolkit in Apache NiFi 2.x releases. There is no alternative solution offered directly in the Apache NiFi product. NIFI-13414 Thank you, Matt
... View more
09-26-2025
06:14 AM
@IgorSpryzhkov You have asked a new unrelated question in an older post which already has an accepted answer. You would get better traction/visibility in the community of you were to start a new community question instead. Thank you, Matt
... View more
09-26-2025
06:09 AM
1 Kudo
@AlokKumar Did the assistance/information provided in the response(s) to your community question in this thread assist you? Please take a moment to accept the answer that provided the assisting information. Thank you, Matt
... View more
09-26-2025
06:09 AM
@AlokKumar Did the assistance/information provided in the response(s) to your community question in this thread assist you? Please take a moment to accept the answer that provided the assisting information. Thank you, Matt
... View more
09-26-2025
06:08 AM
@AlokKumar Did the assistance/information provided in the response(s) to your community question in this thread assist you? Please take a moment to accept the answer that provided the assisting information. Thank you, Matt
... View more
09-26-2025
06:08 AM
@AlokKumar Did the assistance/information provided in the response(s) to your community question in this thread assist you? Please take a moment to accept the answer that provided the assisting information. Thank you, Matt
... View more
09-25-2025
05:51 AM
@jame1997 Not enough information to say what is going on on your environment yet. Can you provide more details? What method of authentication are you using in your NiFi (single-user, ldap-provider, kerberos-provder, SAML, etc...) Assuming you are using a login based provider, are you seeing the NiFi login page and then successfully logging in? Do you ever see the NiFi UI canvas or immediately encounter this exception as soon as you login? Have you inspect the nifi-user.log and nifi-app.log on every node at time of attempted login to see which node is reporting the authentication success and which node is reporting the shared exception? If you do successfully access the NiFi canvas, how long is your access lasting before you encounter the exception? Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt
... View more
09-25-2025
05:38 AM
@AlokKumar When you authorize a user to "View Provenance", you are authorizing that user to be able to view provenance events created by that component (and any components that may be inheriting this authorization). So this authorizations controls what the user can see, but does not give that user the ability to execute a provenance query. For that the admin user will need to go into the NiFi Global menu --> Policies and authorize the user for "query provenance" access policy. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt
... View more
09-24-2025
05:55 AM
@AlokKumar NiFi authorization policies are very granular. A user will not have access to flow development icon across top of the UI unless that user is authorized within the currently access process group to "modify the component", but you would also want those same users to also be authorized for "view the component". Now depending on what additional access you want each user to have, you'll probably be authorizing them for even more NiFi policies. Keep in mind that by adding a user to the "modify the component" authorization policy in the "Copy of ProcessGroupAdminTest" process group will only give that user the ability to add and modify components within that process group and any child/sub process group of "Copy of ProcessGroupAdminTest" Process group (if a child/sub process group is not inheriting authorizations from the parent Process group, then user you add to parent would not have same access to chid/sub Process group). NiFi has "Global Access Policies" and "Component Access Policies" The Global Access Policies are set by accessing the NiFi Global menu (three horizontal lines in upper right corner of the NiFi UI) and then "Policies". If you hover your cursor over the access policy, it will pop-up a description of what the policy grants access for: The levels of access you want to provide your individual users/teams is completely up to you. ALL users must be authorized for the "View the User Interface" global access policy in order to access the NiFi UI, but that does not give the user much access beyond that. So you need to decide which user will be building dataflows, NiFi refers to them as DataFlow Managers (DFM)s. Then you may also have operators which you only grant ability to "view the component" and "operate the component" certain dataflows with no authorization to modify or view the data. The component level access policies are set by clicking on the "key" icon for a selected component. For example: Below I have clicked on the "GenerateFlowFile" processor as we can see it in the "operation" panel to its left. Inside that Operate panel, your admin user (or other users you have authorized) will have access to the policies for that component. Granting a user "view the component" and "modify the component" on a process group will give that user the ability to build and operate dataflows. But that user will still not be authorized to view the content of the FlowFiles traversing that dataflow, empty a connection queue, or view the provenance data produced by those components unless you set that additional authorizations. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt
... View more