Pinging directly will not work as it is behind the firewall.  We need to use curl pointing to the proxy to connect to cloudera.com at the OS level (could be any internet hostname) My previous responses tested using curl calling our proxy server at the OS level where NiFi is running and it is working. Only NiFi using Configuration service (Proxy server: HTTP) seems to broken with 2.7.2.  Before the upgrade from 1.26 to 2.7.2, NiFi worked connecting to cloudera using our own proxy server. ... View more

@Runa27  Before being able to properly help we need you to share your exact Apache NiFi version details.  This allows us to see if your are experiencing a known issue in your specific version.    Also you'll want to tail the nifi-user.log and nifi-app.log when you make the request to view the content.  Then share the output from both those files covering the time of that request (please include time when you performed request via NiFi UI). Also share a bit more about your NiFi setup.  What method of user authentication and user authorization are you using? 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

@pnac03  Based on your nifi-registry.properties file, there is no user identity manipulation happening.  This means that the full DistinquishedName (DN) presented by NiFi in the MutualTLS exchange with NiFi-Registry will be the user identity for the registry client connecting to your NiFi-Registry.  That means that the full DN needs to be authorized in NiFi-Registry properly.  That DN needs to be authorized for the following Special Privileges: "Can manage buckets" - Read "Can proxy user requests" - Read, Write, and Delete From the keystore you shared fro your SSL Context Service, we can see it properly contains only one PrivateKeyEntry and the DN for that clientAuth privateKey is: O=3SCDemo, CN=nifi-registry So the above (case sensitive) MUST exist as a user in your NiFi-Registry and have granted to it the above special Privileges mentioned. Also, the user identity of the user logged into NiFi (as displayed in upper right corner - case sensitive) when attempting start version control on a process group in NiFi will need to exist as a user in your NiFi-Registry and be authorized properly directly on the bucket in which you want to version control the process group (this is different then the Special Privileges section in NiFi-Registry).  Read Bucket - Allows user to see version controlled flows in the bucket. Write Bucket - Allows user to commit new version controlled flows to the bucket Delete Bucket - allows user to delete a bucket.  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

@MattWho  Wow! I think this pattern would work best for my usecase. I hadn't even considered the first challenge you brought up of production flows having their Parameter Context unassigned if I were to update their version. That would've been painful to find out after deploying many instances.   Back in NiFi 1 I used to handle situations such as this with variables, since they could just be directly attached to Process Groups and so I never had to worry about creating separate objects (parameters) and ensuring they get attached, or that every new instance of a versioned flow had to have its own unique context created. It's been a couple years but I believe I even questioned Pierre about this in one of his appearances in the Israeli NiFi meet-ups.   In regards to product work, I've ran into this case of trying to use NiFi as the underlying tool for different SaaS platforms multiple times already. There could definitely be some QoL changes made to make such a use-case easier to implement with NiFi's flow registry, I guess the responsibility lies in people like me opening issues to bring them though 🙂   Thank you very much for the suggestions Matt! Green ... View more

Hello @MattWho thanks for the information.  I'm already running the process only on the Primary node.  I will monitor and take a thread dump if it occurs again.  ... View more

I regenterate the keystore with the common server name.  Nifi UI works but I thought I can find the username/password in the nifi-bootstrap.log  I found the username and password encrypted in login-identity-providers.xml how can I decrypt them, or should I generate a new username/password and how? thank you. BN           ... View more

@Pashazadeh  Apache NiFI 2.0.x was a technical milestone/preview releases that underwent many changes before the first GA release with NiFi 2.1.x.  I would not expect a change in behavior going forward, unless some bug is introduced or the community agrees on a change in functionality/behavior.   While I don't have a specific answer to what bug resulted in the difference in behavior you encountered, here are some changes that affected the JsonRecordSetWriter. NIFI-14331 NIFI-13963 / NIFI-13843 NIFI-12670 If you still have your NiFi 2.0.0 running, you could run your flow using a convertRecord with same record readers and writers and then compare the output content with what you see with 2.7.1 output.  Maybe that can help figure out what is happening and if either of those bugs affecting earlier NiFi 2.x versions is related. Thanks, Matt ... View more

@MuruganFinastra  Since you are getting a 403 response, the first thing you should do is see what user identity this 403 is being returned for.  For this you'll want to be tailing the nifi-user.log while you attempt to make this rest-api call. You will see the denied related log lines in the nifi-user.log.  That logging will provide the user identity string and which NiFi authorization policy required for which that user identity did not have the required permissions.   Using this output, we can determine the next steps required here.  Is the expected user identity being logged? What is the logged authorization policy resulting in the 403 response? Also which user authentication and authorization configuration options are you using in your setup? 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

Hello @PepeVo! As this is an older post, you would have a better chance of receiving a resolution by starting a new thread. This will also be an opportunity to provide details specific to your environment that could aid others in assisting you with a more accurate answer to your question. You can link this thread as a reference in your new post. Thanks. ... View more

@MattWho Apologies for the delay here. I could finally try using certificates with the EKU Extensions and I do not see a similar authentication issue anymore.  Thank you for the kind assistance!  ... View more