Member since
07-30-2019
3406
Posts
1623
Kudos Received
1008
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 338 | 12-17-2025 05:55 AM | |
| 399 | 12-15-2025 01:29 PM | |
| 418 | 12-15-2025 06:50 AM | |
| 371 | 12-05-2025 08:25 AM | |
| 605 | 12-03-2025 10:21 AM |
10-17-2024
09:54 AM
@vg27 A few issues I see with what has been shared: Issue 1: IPV4 addresses like 0.0.0.0 and 127.0.0.1 are special reserved network addresses. 0.0.0.0 is not going to be resolvable to any network host. 0.0.0.0 is typically used by server applications running on multi-homed networks. Meaning the the server has multiple NIC cards that are connected. For example: one NIC connected to a companies internal private network and another NIC on same server connected to a public network. BY configuring the server with 0.0.0.0, the special addresses tells the server to listen and accept connection from all NICs. From the browser you would still need to use a resolvable IP address for accessing that server via one of the NICs. NiFi offers a specific configuration property if you want to define multiple network interfaces you want NiFi to listen for connections on. 127.0.0.1 is the loopback address (localhost), which if used in NiFi, means NiFi is only listening on that loopback address. So you should be configuring your "nifi.web.https.host" property for the hostname of the server on which it is running. This hostname would need to be resolvable and reachable by your browser. -------------------------- Issue 2: You are setting up. NiFi cluster, but are still using the single-user providers for authentication and authorization: nifi.security.user.authorizer=single-user-authorizer
nifi.security.user.login.identity.provider=single-user-provider These providers were created so that users could launch NiFi standalone instances out-of-the-box for ease of product evaluation. These providers are not suitable for clustered NiFi setups or multi-users environments. The authorizers.xml you shared is incomplete and only shows a "file-user-group-provider". The authorizers.xml is easiest to read from bottom of the file upward. At the very bottom you will find the authorizer (for example: "single-user-authorizer" or "managed-authorizer"). Depending on type of authorizer, the authorizer may utilize one or more additional providers ("file-access-policy-provider", composite-user-group-provider, ldap-user-group-provider", "file-user-group-provider", etc...) already loaded further up in the authorizers.xml. So while you may have configured the "file-user-group-provider" and the that provider executes on NiFi creating a users.xml file, the configured single-user-authorizer would never use it. --------------------------- Issue 3: Did you generate your own NiFi keystores and truststore for your 2 NiFi nodes or are you using the NiFi auto-generated keystore and truststore? I encourage you to manage your own certificates, keystores, and truststores in a production setup. The certificates generated automatically are self-signed and only contain very specific Subject Alternative names. In a cluster setup, NiFi nodes act as both clients and servers since they communicate with one another. And the owner of those self-signed certifcates is going to be "localhost". This means that all nodes will report as same identity "localhost", which is not good for security. ------------------------------- Issue 4: I see you are using the embedded zookeeper (ZK). ZK requires quorum in order to be useable. With only 2 nodes, you only have 2 ZK nodes which is not a quorum. IF either one of the nodes becomes unreachable or goes down, you will not be able to access the one remaining node either since ZK has lost quorum. Quorum consists of an odd number of ZK nodes (typically 3 or 5) depending on how much loss tolerance you want to have. While embedded ZK makes things easy with setup, you'll want to have at least 3 NiFi nodes (this allows you to lose up to one node and still retain access to the NiFi UI of the other 2 nodes. Of course using an external ZK is even better and the best production option as stopping/starting or loss of NiFi nodes has no impact on quorum. --------------------------------- These are the areas to address first. Please help our community thrive. 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
10-17-2024
06:28 AM
@Suayb I see no ERROR logging in anything you have shared. The snippet of the nifi-app.log you shared only shows that NiFi is still starting up. NiFi is not fully up and the UI is not accessible until you see the following lines output in the nifi-app.log: 2024-10-17 09:24:32,817 INFO [main] org.apache.nifi.web.server.JettyServer Started Server on https://<hostname>:8443/nifi
2024-10-17 09:24:32,818 INFO [main] org.apache.nifi.BootstrapListener Successfully initiated communication with Bootstrap
2024-10-17 09:24:32,819 INFO [main] org.apache.nifi.NiFi Started Application Controller in 11.878 seconds (11878131211 ns) Are you seeing above in your nifi-app.log? Are you seeing any ERROR lines in any of you logs? are you seeing any disk space issues? Thanks, Matt
... View more
10-16-2024
05:46 AM
@Suayb NiFi- 2.x requires Java 21 The make sure your NiFi is starting with Java 21 and not another version of Java. You configure a specific java in the NiFi.bootstrap.conf file. By default in that file java is set to "java=java" which uses system default java. You could could change this to "java=<path to java 21 bin dir>/java" If above does not solve issue start reviewing the nifi-bootstrap.log, nifi-app.log, and nifi-request.log for any relevant details. Please help our community thrive. 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
10-15-2024
05:10 AM
1 Kudo
@livsey Can you share what Java and Java version you are using and how you have configured your Apache NiFi conf/nifi.properties file? I am most interested in the Web Properties section. Thank you, Matt
... View more
10-11-2024
09:35 AM
1 Kudo
@vg27 From your shared nifi.properties file, I can see you are using SSO based user authentication and Mutual TLS (always enabled) based authentication. For user authorization, you using the managed-authorizer. So when you access the NiFi UI you are being redirected to your SSO login, correct? After successful authentication, you are able to access the NiFi UI; however, when you click on the global menu in upper right corner, the menu has the users and policies greyed out and not clickable? If it is greyed out, it means the currently authenticated user is not authorized to access those items. What is the user identity string displayed in upper right corner above logout? This case sensitive user identity string is what needs to be properly authorized. Can you share your authorizers.xml file? This file sets up your authorizer and various sub provider it depends on for establish necessary access policies for your initial admin user and nodes. That initial admin user's identity string would get the minimum needed admin policies granted against it. That admin user could then access the NiFi UI and be able to add additional user identity strings and apply policies to those new user identity strings or groups strings. A very basic authorizers.xml would have in it: File-user-group-provider --> Responsible for creating initial user identity strings for your initial admin and your NiFi nodes. This provider generates a users.xml file only if one does not already exists. It will not edit and existing users.xml. Your user identity must match exactly (case sensitive) with what you see in the NiFi UI. From within the NiFi UI additional users and groups can be added later which will be also added to the users.xml file. File-access-policy-provider --> This provider is responsible for creating the authorizations.xml file that contains the policies that have been assigned to user or group identity strings. It will only generate an authorizations.xml file if one does not exist. It will not edit an existing authorizations.xml. When seeding initial policies for nodes and initial admin it expects to find those user and node identity strings from the file-user-group-provider. Any newly setup policies via the NiFi UI will get added to the authorizations.xml. managed-authorizer ---> This authorizer points at the file-access-policy-provider to load the current authorizations. Please help our community thrive. 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
10-10-2024
09:54 AM
2 Kudos
@Krish98 Most NiFi Heap memory issues are directly related to dataflow design. The Apache NiFi documentation for the individual components generally does a good job with reporting "System Resource Considerations". So the first step would be to review the documentation for the components you are using to see which list "MEMORY" as system resource consideration. Example: SplitContent 1.27.0 Then sharing your configuration of those components might help with providing suggestions that may help you. - Split and Merge processor depending on how they are configured can utilize a lot of heap. - Distributed Map cache also resides in HEAP and can contribute to to significant heap usage depending on configuration and the size of what is being written to it. Beyond components: - NiFi loads the entire flow.json.gz (uncompressed it to heap memory). This includes any NiFi Templates (Deprecated in Apache NiFi 1.x and removed in newer Apache NiFi 2.x version). Templates should no longer be used. Any templates created which are listed in the NiFi templates UI should be downloaded so they are stored outside of NiFi and then deleted from NiFi to reduce heap usage. - NiFi FlowFiles - NiFi FlowFlowFiles are what transition between components via connections in your dataflow(s). A FlowFile consists of two parts. FlowFile content stored in content claims in the content_repository and FlowFile metadata/attributes held in heap memory and persisted to flowfile_repository. So if you are creating a lot of FlowFile attributes on your FlowFiles or creating very large FlowFile attributes (like extract content to an attribute), that can result in high heap usage. A connection does have a default threshold at which time a swap file is created to reduce heap usage. Swap files are created with 10,000 FlowFiles in each swap file. The first swap file would not be created until a connection on a specific node reached 20,000 at which point 10,000 would be moved to a swap file and the 10,000 highest priority would remain in heap. The default "back pressure object threshold" on a connection is 10,000 meaning that with defaults no connection would ever create a swap file. Please help our community thrive. 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
10-10-2024
06:04 AM
@Leo3103 What are you seeing in the minifi-app.log? You could also try set DEBUG logging in the minifi logback.xml to capture more details. Please help our community thrive. 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
10-09-2024
05:55 AM
@Leo3103 I am confused by what you are showing me. While not building the same flow as you, i have gone through the steps outlined using my minifi-2.0.0-M4 and minifi-toolkit-2.0.0-M4 downloads. Taking my downloaded <flow-definition-download.json> from my NiFi, I ran it through the toolkit using: ./minifi2/minifi-toolkit-2.0.0-M4/bin/config.sh transform-nifi NiFi_Template_XML_to_Flow_Definition_JSON.json flow.json.raw The toolkit output file begins with: {"maxTimerDrivenThreadCount":0,"parameterContexts":[],"rootGroup":{"identifier":"e2e44df7-dbd9-3890-aeee-67a6f48fe538","instanceIdentifier":"006c844b-0192-1000-1158-841acd760276","name":"NiFi_Template_XML_to_Flow_Definition_JSON","comments":"","position":{"x":-1032.0,"y":-456.0},"processGroups":[],"remoteProcessGroups":[],"processors":[{"identifier":"e5d........ If you were to start MiNiFi with this flow.json.raw with out editing it first, a flow.json.gz will be created and you will encounter the exception about number of threads can not be "0". If you did start it, delete the generated flow.json.gz file. Then edit the flow.json.raw file: {"maxTimerDrivenThreadCount":5,"parameterContexts":[],"rootGroup":{"identifier":"e2e44df7-dbd9-3890-aeee-67a6f48fe538","instanceIdentifier":"006c844b-0192-1000-1158-841acd760276","name":"NiFi_Template_XML_to_Flow_Definition_JSON","comments":"","position":{"x":-1032.0,"y":-456.0},"processGroups":[],"remoteProcessGroups":[],"processors":[{"identifier":"e5d You'll see here that I set my thread pool size to 5. I then started MiNiFi again and once again the flow.json.gz was created during startup from my flow.json.raw file. MiNiFi started successfully. DEBUG logging shows here it persisting the loaded flow.json.raw to a flow.json.gz file: 2024-10-09 08:47:17,537 DEBUG [main] o.a.n.m.commons.util.FlowUpdateUtils Persisting flow to path /opt/minifi2/minifi-2.0.0-M4/./conf/flow.json.gz with content You could edit the logback.xml to produce DEBUG output so you can see more detail about the flow being loaded. Is your MiNiFi running on the same host as your NiFi? I see you have your Remote Process Group (RPG) configured for localhost. Please help our community thrive. 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
10-07-2024
06:12 AM
1 Kudo
@newbeede The only Authentication provider provided with NiFi that supports a single managed user with password is the Single User provider. Apache NiFi create this authentication provider so that NiFi out-of-the-box could run securely over HTTPS. It is intended for non clustered use to make it easy to evaluate the product. The users.xml is created by the file-user-group-provider inside the authorizers.xml. It's is for authorization use only and has nothing to do with user/client authentication. In order to setup various authorization policies through the file-access-policy provider (also found in the authorizers,.xml and generates an authorizations.xml file), the authorizer must be aware of the user/client identities for which policies will be granted. The file-user-group-provider is just one of the available providers that creates these user identities within NiFi for the sole purpose of policy assignment. The file-user-group-provider is used to generate the Initial Admin Identity and the Identities for each of your cluster nodes. The users.xml file it creates will only initially contain those identities. The file-user-group-provider will ONLY generate the users.xml on NiFi startup if it does NOT already exist. Once the NiFi UI is accessed by the initial admin identity, additional user identities and policies are setup from within the UI. Additional user identities and group identities added through the NiFi UI will be added to the users.xml. If you are using the Single-User authentication provider and single-user authorizer, then users and polices will not present in the UI when accessed. The File-access-policy provider sets up admin polices for the defined initial admin identity and sets up initial node required policies. The policies are needed for that initial admin to be authorized to create additional user identities and configure additional policy authorizations from with the NiFi UI. The file-access-policy provider will ONLY generate the authorizations.xml file on NiFi startup if it does NOT already exist. Additional policies setup from with the NiFi UI are added to the authorizations.xml file. So to be clear, NiFi does allow you to dynamically add/remove additional user identities and dynamically add/modify/remove authorizations from the NiFi UI without needing a restart. When it comes to handling user authentication, a secured NiFi will always support client Authentication as first authentication method attempted. This is the only method used for the NiFi nodes to communicate with one another. When additional authentication method are configured, NiFi will still WANT a client auth certificate in the TLS exchange; however if one is not provided, NiFi will try the next authentication method configured. The most commonly used additional authentication method used are the LDAP-provider and Kerberos-provider. The LDAP-provider allows you to authenticate via your own LDAP/AD. Sample: <provider>
<identifier>ldap-provider</identifier>
<class>org.apache.nifi.ldap.LdapProvider</class>
<property name="Authentication Strategy">SIMPLE</property>
<property name="Manager DN"></property> <-- MUST be configured
<property name="Manager Password"></property> <-- MUST be configured
<property name="TLS - Keystore"></property>
<property name="TLS - Keystore Password"></property>
<property name="TLS - Keystore Type"></property>
<property name="TLS - Truststore"></property>
<property name="TLS - Truststore Password"></property>
<property name="TLS - Truststore Type"></property>
<property name="TLS - Client Auth"></property>
<property name="TLS - Protocol"></property>
<property name="TLS - Shutdown Gracefully"></property>
<property name="Referral Strategy">FOLLOW</property>
<property name="Connect Timeout">10 secs</property>
<property name="Read Timeout">10 secs</property>
<property name="Url">ldap://<hostname>:<port></property> <-- MUST be configured
<property name="User Search Base">CN=Users,DC=example,DC=com)</property> <-- MUST be configured
<property name="User Search Filter">cn={0}</property> <-- MUST be configured
<property name="Identity Strategy">USE_USERNAME</property> <-- MUST be configured
<property name="Authentication Expiration">12 hours</property>
</provider> USE_USERNAME: Upon successful LDAP/AD authentication, the user identity string as typed (case sensitive) in the username login window will be passed to the authorizer to look up policies assigned to the user identity. USE_DN: Will pass the DN returned from LDAP/AD after successful authentication to the authorizer as the user identity for policy assignment lookup. Kerberos-provider allows you to authentication using your kerberos principal and password. Sample: <provider>
<identifier>kerberos-provider</identifier>
<class>org.apache.nifi.kerberos.KerberosProvider</class>
<property name="Default Realm">NIFI.APACHE.ORG</property>
<property name="Authentication Expiration">12 hours</property>
</provider> Bottom line is Apache NiFi does not support managing multiple local accounts. In fact the single-user provider is actually fairly new to Apache NiFi. Prior to its existence, NiFi out-of-the-box started up un-secure over http. Since most browser now force http to https, Apache NiFi added this provider to make it easy for first time user to evaluate the service. Please help our community thrive. 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
10-04-2024
12:20 PM
1 Kudo
@Abibee04 Please start a new Community question with the details of your query. I am not clear what you mean by "recover the registry", so the more detail you can provide the better in that new community question by sharing what step you performed and what you are looking to accomplish. Thank you, Matt
... View more