Member since
11-17-2021
1163
Posts
261
Kudos Received
30
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 388 | 04-23-2026 02:02 PM | |
| 944 | 03-17-2026 05:26 PM | |
| 6207 | 11-05-2025 10:13 AM | |
| 1134 | 10-16-2025 02:45 PM | |
| 1900 | 10-06-2025 01:01 PM |
07-01-2024
10:27 AM
@prfbessa Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. Thanks.
... View more
06-26-2024
01:52 AM
Thank you for response and apologies for delay reply. I have created a custom tmp directory as below under core-site.xml. I ran stop-all.sh and start-all.sh under sbin directory but still custom tmp directory is empty and not utilized. Is I need to do anything else, please suggest. Thanks in advance. <property> <name>hadoop.tmp.dir</name> <value>/opt/osa/hadoop-2.10.2/tmp_Hadoop</value> <description>A base for other temporary directories.</description> </property>
... View more
06-25-2024
12:58 PM
Despite extensive efforts, I was unable to directly resolve the issue, but I devised a workaround. Rather than directly accessing the Hadoop Job object for status updates, I extracted the job ID after submitting the job. Using this job ID, I created an ApplicationID object, which I then used to instantiate my YarnClient. This approach enabled me to effectively monitor the status and completion rate of the running job. Interestingly, both my distcp job and YarnClient are utilizing the same HadoopConf object (YarnClient is instantiated right after the DistCP Job is executed) and is within the same scope of the UserGroupInformation. The exact reason why the YarnClient can access the necessary information while the Job object cannot remains unclear. Nevertheless, this workaround has successfully unblocked me. Additional context: I am using Java 8 and running on an Ubuntu Xenial image.
... View more
06-25-2024
12:37 PM
1 Kudo
@aymenech Welcome to the Cloudera Community! To help you get the best possible solution, I have tagged our CDP experts @venkatsambath @abdulpasithali who may be able to assist you further. Please keep us updated on your post, and we hope you find a satisfactory solution to your query.
... View more
06-24-2024
11:27 AM
@Mike_CHU44 Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. Thanks.
... View more
06-20-2024
01:53 PM
1 Kudo
It works! Thanks!
... View more
06-19-2024
01:49 AM
Tried on 2.0.0-M1, no problem. It looks there is a problem with Jetty v12 introduced at M2. Until potential bug fix, additional conf or workaround, I consider downgrading to M1. Thanks
... View more
06-19-2024
01:37 AM
1 Kudo
We are experiencing the same issue on CDP 7.1.7 calling a spark job from Oozie.
... View more
06-14-2024
09:57 AM
1 Kudo
@thegreatdakness Welcome to the Cloudera Community! I have reached to you via DM with next steps, thanks!
... View more
06-14-2024
06:54 AM
2 Kudos
@helk You can use a single certificate to secure all your nodes, but i would not recommend doing so for security reasons. You risk compromising all your host if any one of them is compromised. Additionally NiFi nodes act as clients and not just servers. This means that all your hosts will identify themselves as the same client (based off DN). So tracking client initiated actions back to a specific node would be more challenging. And if auditing is needed, made very difficult. The SAN is meant to be used to differently. Let's assume you host an endpoint searchengine.com which is back by 100 servers to handle client requests. When a client tries to access searchengine.com that request may get routed to anyone of those 100 servers. The certificate issues to each of those 100 servers is unique to each server; however, every single one of them will have the searchengine.com as an additional SAN entry in addition to their unique hostname. This allows the host verification to still be successful since all 100 are also known as searchengine.com. Your specific issue based on shared output above is caused by the fact that your single certificate does not have "nifi01" in the list of Subject Alternative Names (SAN). It appears you only added nifi02 and nifi03 as SAN entries. The current hostname verification specs no longer use DN for hostname verification. Only the SAN entries are used for that. So all names(hostnames, common names, IPs) that may be used when connecting to a host must be included in the SAN list. NiFi cluster keystore requirements: 1. keystore can contain only ONE privateKeyEntry. 2. PrivateKey can not use wildcards in the DN. 3. PrivateKey must contain both clientAuth and serverAuth Extended Key Usage (EKU). 4. Privatekey must contain at least one SAN entry matching the hostname of server on which keystore will be used. The NiFi truststore must contain the complete trust chain for your cluster node's PrivateKeys. On truststore is typically copied to and used on all nodes. 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