Member since
07-30-2019
3387
Posts
1617
Kudos Received
999
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 188 | 11-05-2025 11:01 AM | |
| 396 | 10-20-2025 06:29 AM | |
| 536 | 10-10-2025 08:03 AM | |
| 371 | 10-08-2025 10:52 AM | |
| 407 | 10-08-2025 10:36 AM |
03-09-2017
03:11 PM
@Christophe Vico This appears to be an issue between Ranger and Solr and have nothing to do with NiFi at all. I suggest updating your tags on this post to include Solr.
... View more
03-09-2017
03:07 PM
@Christophe Vico Based on the DN pattern you provided in your question (CN=nodename, OU=some OU, DC=dc1, DC=dc2). None of the mapping you shared should have matched. Are you sure there isn't a third OU in there?
The closest mapping is nifi.security.identity.mapping.pattern.dn2=^CN=(.*?), OU=(.*?), OU=(.*?), OU=(.*?), DC=(.*?), DC=(.*?)$
nifi.security.identity.mapping.value.dn2=$1 The mapping pattern above takes the DN that starts with CN=<capture group 1>, OU=<capture group 2>, OU=<capture group 3>, OU=<capture group 4>, DC=<capture group 5>, DC=<capture group 6> each "(.*?)" creates a java capture group of everything between "=" and ",". It then returns the value of <capture group 1> only as dictated by the "$1". It is this resulting value that is passed to teh authorizer. assuming there is a third , OU= in your servers DN, this would explain exactly what you are seeing. Thanks, Matt
... View more
03-09-2017
02:58 PM
@Harshith Venkatesh Where the certificates created to secure each of these NiFi instances signed by the same CA? The authentication that is going to occur between these NiFi instances is 2-way SSL. Both servers must be able to trust the certificate being presented by the other NiFi instance. Thanks, Matt
... View more
03-09-2017
02:55 PM
@Harshith Venkatesh And what do you see in the nifi-user.log on the other NiFi instance?
... View more
03-09-2017
01:05 PM
@Harshith Venkatesh What do you see in the nifi-user.log on the target NiFi server of the RPG?
What is the full error seen in the nifi-app.log of the source NiFi server?
... View more
03-09-2017
12:50 PM
@Christophe Vico In order for users or servers to access any secured NiFi end-point a series of steps occur: 1. User/server authentication: For users this sounds like it is being done via AD which you have configured via Ambari (this sets up the login-identity-providers.xml file in NiFi). For servers this is done via server certificates that are configured for each of your NiFi nodes. If and only if user/server authentication is successful, then the process moves on to step two. Do a verbose listing of the keystore on your newly added node to verify DN structure. 2. User/server Pattern mapping: NiFi can be configured to use pattern mappings to extract a portion of the return DN or principal before passing the resulting mapped value to the configured authorizer (in your case the authorizer is Ranger). These mappings can be setup in Ambari which will update the nifi.properties file. by default, pattern mapping is not enabled. All Authenticated entities no matter how the authentication was completed are passed through every configured mapping looking for a match. If no matches are found, the full return is sent to the authorizer. Check to see if any mappings have been setup that are matching on your new server's DN. 3. User/Server Authorization: User/server authorization is check to see what NiFi resources a particular authenticated entity has been granted access to. Note: You can follow the authentication and authorization process by looking in the nifi-user.log. Thanks, Matt
... View more
03-09-2017
02:36 AM
3 Kudos
@Saikrishna Tarapareddy Using the ExecuteScript processor here should work for you. The "Command" property should only contain "kinit" The "Command Arguments" property is where you would add "-k -t /etc/security/keytabs/nifi.keytab nifi/695660.x.com@X.X.COM" Two things to keep in mind: 1. Make sure the user that runs/owns your NiFi process can also resolve and execute the kinit command 2. Make sure the user that runs/owns your NiFI process has the necessary permissions to navigate down the path to your nifi.keytab and read that file. (The error seems to indicate that your NiFi user can get down that path.) Thanks, Matt
... View more
03-08-2017
03:52 PM
@Harshith Venkatesh When performing Site-to-Site (S2S) between two Secured NiFi installs, server authentication and authorization will need to be successful. In your case it sounds like authentication was likely successful (You can confirm this by looking in the nifi-user.log of the target NiFi). What appears to be missing is source server(s) authorization. To resolve the "forbidden" you are seeing on your RPG, you will need to go to the target NiFi and add a new user for the source NiFi server(s) running the RPG. Click on "Users" to add new The user you are adding will need to be the full DN from the source NiFI's server certificate. (Case sensitive and white spaces count as valid characters). You can pull he DN out of the nifi-user.log or by doing a verbose listing source NiFi's keystore. After you have added the server as a user, you will need to authorize that server by clicking on "Policies" and granting the server "retrieve site-to-site details" access policy.
After doing the above the "forbidden" response on the RPG should go away on next sync. What you still will not see is a list of available input and output ports on the target NiFi to which your source NiFi can connect with over S2S. Remote input and output ports can only be added to the root canvas level. After they have been added you will need to allow your source NiFi server user to access them as well before they will show up in the RPG. This is done via the "Operate panel": Selecting an input or output port on the canvas will show that component as the selected component in the operate panel. Select the key icon and grant your NiFi source Server the following policy: For input ports --> "receive data via site-to-site" access policy For output ports --> "send data via site-to-site" access policy On next sync RPG should now show these ports as available to your source Nifi for connecting to over S2S. Thanks, Matt
... View more
03-08-2017
02:43 PM
@mel mendoza There appears to be some issue with your FTP server. The SYST command is a standard command that is passed when establishing a connection to the FTP server. The expected response would be the OS information of the target FTP server. https://en.wikipedia.org/wiki/List_of_FTP_commands The FTP server running on your SUN OS 4.1 is responding that it does not understand that command. Thanks, Matt
... View more
03-07-2017
08:00 PM
You need to keep the NIFi copy of the data even after writing a copy of it out via the putSFTP? If you need to retain a local copy of the data, route success twice form your putSFTP processor. So you should be able to do this with..... The UpdateAttribute processor can be used to update the filename by adding the following new property to its configuration: The Local copy of your Files remain unchanged down the success relationship to the left. The copy sent down the path to the right will have its content cleared, filename changed, and then sent via another PutSFTP. Thanks, Matt
... View more