Member since
07-30-2019
3470
Posts
1642
Kudos Received
1018
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 270 | 05-06-2026 09:16 AM | |
| 451 | 05-04-2026 05:20 AM | |
| 331 | 05-01-2026 10:15 AM | |
| 513 | 03-23-2026 05:44 AM | |
| 388 | 02-18-2026 09:59 AM |
09-18-2023
12:16 PM
@LKB I'd expect a full stack trace in the nifi-app.log following that ERROR. The ldap-provider is configured inside the login-identity-providers.xml file. Does your LDAP Manager password happen to contain any XML special characters? If so, you should escape them. https://xml.silmaril.ie/specials.html Have you tried using ldapsearch to manually make a connection to your LDAPS from the server where you have NiFi installed using same manager DN, Manager password, and keystore and trustsore? Was it successful? If you found any of the suggestions/solutions provided helped you with your issue, 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-18-2023
12:02 PM
@pacman Seems odd to me that in the shared Ranger configuration you have configured a truststore where Ranger is expecting a keystore. Then you have your truststore configured with the keystore instead of truststore. The Ranger service is attempting to connect to NiFi's /resource NiFi resource Identifier endpoint in order to obtain an up-to-date list of NIFi Resource Identifiers in order to simplify creating new policies in Ranger for NiFi. The endpoint requires authorization and NiFi gets its authorization from the policies it downloads from Ranger. So we have a which comes first, chicken or the egg, scenario here. You will need to authorize the clientAuth certificate configure in the keystore for READ on the "/resources" NiFi Resource Identifier before Ranger will be able to fetch all the rest of the NiFi resource Identifiers. Before that is possible, Ranger will need to be able to successfully negiotate a mutualTLS handshake with NiFi. This does not require that Ranger server is SSL enabled, just that the NiFi service within Ranger is configured with a keystore and truststore capable of facilitating that mutualTLS handshake with the secured NiFi. Also keep in mind that Ranger service user is executing this client connection to NiFi and thus the keystore and truststore configured must be accessible by the Ranger service user. The Truststore used in Ranger NiFi service must contain the complete trust chain for all the NiFi cluster node's certificates. The ClientAuth certificate in the keystore used in the Ranger NiFi service must be trusted by all the NiFi cluster nodes (meanings its complete trust chain must exist in NiFi's truststore configured in the nifi.properties file). If you found any of the suggestions/solutions provided helped you with your issue, 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-18-2023
11:44 AM
@manishg The ListFile does not pickup any files. It simply generates a zero content NiFI FlowFile for each file found in the target directory. That FlowFile only has metadata about the target content. The FetchFile processor utilizes that metadata to fetch that actual content and add it to the FlowFile. The value added here happens when you have a lot target files to ingest. To avoid having all the disk I/o related to that content on one node, you can redistribute the zero byte FlowFiles across all nodes so that each node now in a distributed way fetches the content (This works assuming that same target directory is mounted on all NiFi cluster nodes). As @SAMSAL shared you could use Process Group (PG) FlowFile concurrency to accomplish the processing of one FlowFile at a time. The ListFile will still continue to list all FlowFiles in target directory (writes state and continues to list new files as they get added to input directory). You can then feed the outbound connection of your ListFile to a PG configured with "Single FlowFile Per Node" FlowFile concurrency. This will prevent any other FlowFile queued between ListFile and the PG to enter the PG until the first FlowFile has processed through that PG. So your first processor inside the PG would be your FetchFile processor. Now if you were to configure Load Balanced Connection on that connection between ListFile and the PG, You would end up with each node in your NiFi cluster processing a single File at a time. This gives you some concurrency if you want it. However, if you have a strict one file at a time, you would not configure load balanced connection. Hope this helps, Matt
... View more
09-15-2023
11:12 AM
@LKB I am not clear what you mean by "NiFi rejects" it. What is the exact exception you are seeing. NiFi does not reject anything, the ldap endpoint would be what would be responding to the query. The "{0}" is replaced with the username string you enter in the "user" field presented by NiFi. So let's assume you login with "user_admin". Your configured LDAP endpoint would be queried for user with "sAMAccountName=user_admin" as an attribute. I would get the ldap listing for your user_admin user from ldap server and verify that "sAMAccountName=user_admin" exists. sAMAccountName is an attribute more commonly associated with Active Directory (AD), but can be added to LDAP as a useable attribute with some custom ldifs. Two authentication happen here: First is the Manager DN along with Manager password is used to facilitate a connection to your ldap. Then the supplied username via login UI is used to lookup the specific user record for password verification. Additionally, since you are using LDAPS instead of LDAP, you are enabling a TLS encrypted connection to your LDAPS. So something else you'll want to verify is that the keystore and truststore you configured in your ldap-provider contains the necessary entries to facilitate that successful TLS connection. Something other configs that strikes me as incorrect: 1. Your user DN is "uid=user_admin,OU=USERS,DC=abc,DC=com"; however, your configured user search base is "DC=abc,DC=net". That means your user you are trying to authenticate would not be found under that search base. 2. Your LDAPS url is missing the port number "ldaps://test.com:<port>" (commonly 636 and 3269 are defaults for ldaps). If your LDAP support unencrypted connections you could change your "Authentication Strategy" from "START_TLS" to "SIMPLE" and then set your LDAP URL to ldap://test.com:389 (389 is default unencrypted port). Make sure you are checking your nifi-app.log and nifi-user.log for any exceptions that may be thrown as you try to login to help you troubleshoot further. If you found any of the suggestions/solutions provided helped you with your issue, 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-15-2023
07:56 AM
@LKB Does the user "uid=user_admin,OU=USERS,DC=abc,DC=com" exist in your LDAP server? Also I have never seen a LDAP user entry that used a full DistinquishedName (DN) in the sAMAccountName attribute. sAMAccountName is typically a short name for the user. NiFi does not install a LDAP/AD server or create/add users and groups to an existing LDAP/AD . NiFi can be configured to authenticate user that already exists in some external existing LDAP/AD server. So if the login username and password would be whatever was setup in your externally installed and managed LDAP server. If you found any of the suggestions/solutions provided helped you with your issue, 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-15-2023
05:33 AM
@manishg The Record Reader and record Writer controller services are not responsible for tracking counts. This is handled within your custom processors code. I am not sure what your custom processor does and whether it makes sense to track "record processed" or some other record based stat, but you can look at the github code for other processors like PartitionRecord to see how RecordCount is handled. If you found any of the suggestions/solutions provided helped you with your issue, 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-14-2023
11:32 AM
@RRG I have never used bitbucket before. Version control of Process Groups in NiFi is handled by the NiFi-Registry service that integrates with NiFi. The NiFi-Registry service offers a GitHub integration option https://nifi.apache.org/docs/nifi-registry-docs/html/administration-guide.html#flow-persistence-providers I am not sure how interchangeable git hub is with bitbucket. But you may want to have a look at the following on how NiFi-registry can be integrated with Github: https://community.cloudera.com/t5/Community-Articles/Storing-Apache-NiFi-Versioned-Flows-in-a-Git-Repository/ta-p/248713 If you found any of the suggestions/solutions provided helped you with your issue, 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-14-2023
11:24 AM
@davehkd Of your NiFi cluster is secured you'll need to make sure that the load balancer is configured with sticky sessions (also known as session persistence). This is needed because NiFi authentication (except certificate based mutual TLS authentication) issues a client and server side token. The issued client token gets passed by the client (browser) with every subsequent request made to NiFi. The corresponding server side token only exists on the specific NiFi node that handled the authentication. So if your LB routes subsequent requests to a different node, authentication will fail for that request. Many users setup LBs in front of NiFi so there is one URL that can direct to any number of nodes in the NiFi cluster that are all capable fo handling authentication and authorization. This ensures ease of access for example when a node in the cluster is down. If you found any of the suggestions/solutions provided helped you with your issue, 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-14-2023
10:55 AM
@manishg I am not clear, can you share the processor type where the expected data is not present? The View Status History "Record Processed" will only appear on some component "Record" type processors (example: PartitionRecord processor). It would not exist as on processors that don't process "records". If you found any of the suggestions/solutions provided helped you with your issue, 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-14-2023
10:10 AM
2 Kudos
@Soli There is likelihood that once you upgrade that you will have ghosted processors (happens when you are using a processor that no longer exists in the newer release) or invalid components (happens when new version of same component class introduces new required properties that need to be configured). Something you may want to try is standing up a different NiFi on 1.23 with autoresume.state set to false in the nifi.properties. drop your flow.xml.gz in to that NiFi and start it. Everything will load up in stopped state. At least then you can validate al your processors are valid and none are ghosted. If this standalone can reach yoru redis, make sure you don't start processors that use it as it can mess up state recorded in your prod NiFi. You also did not mention if you have a standalone NiFi or a NiFi cluster setup. In a NiFi cluster, Zookeeper is also used by some components to store cluster wide state. So would not utilize same ZK in your test cluster setup used to check for component issues. At least you will be able to rule out flow design issues and be able to make note of what needs to be fixed in your production upgrade prior to doing the upgrade. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt
... View more