Member since
07-29-2019
640
Posts
114
Kudos Received
48
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 14422 | 12-01-2022 05:40 PM | |
| 3293 | 11-24-2022 08:44 AM | |
| 4950 | 11-12-2022 12:38 PM | |
| 1789 | 10-10-2022 06:58 AM | |
| 2579 | 09-11-2022 05:43 PM |
01-12-2022
01:19 PM
Hi @jludac
You didn't say which release of CDH you're interested in, but assuming you're looking for information describing how to download CDH 6 from Cloudera's private repositories, the best place to start would be the official documentation located here:
CDH 6 Download Information
You should only follow those instructions, however, after carefully considering the fact that CDH 6 is well on it's way to reaching its EOS date. CDH 5.x releases have already reached their EoS date. Cloudera's lifecycle support policies are documented here:
Support lifecycle policy (open that link and then expand the section labeled "Cloudera Enterprise products" underneath Current End of Support (EoS) Dates).
At that last link (as of this writing) you can read that Cloudera 6.3 is supported until the end of March 2022. For eligible customers, Limited Support for CDH versions 6.2 and 6.3 will be provided during the six-month period beginning on April 1, 2022, and ending on September 30, 2022. So you should understand that in the best case circumstances, any testing you plan to do using CDH will essentially become obsolete later this year.
If you are looking to evaluate a current data platform for use within your company, you can currently do so by downloading and installing the Trial Version of CDP Private Cloud Base Edition of Cloudera Data Platform without a preexisting Cloudera subscription. CDP Private Cloud supersedes CDH as Cloudera's on-premises data platform product and has been generally available since November 2019. If your evaluation needs will extend past the 60-day free trial period governing that downloadable distribution, please reach out to your Cloudera Account Executive to find out how to proceed.
... View more
01-02-2022
10:43 PM
Hi @PT_L
I strongly recommend that you consult the section headed CDP Private Cloud Base Supported Operating Systems on the page titled Operating System Requirements in the section of Cloudera's documentation devoted to CDP Private Cloud.
If you click the hyperlink in that section labeled Cloudera Support Matrix, I think that you'll find that the release of CDP Private Cloud Base that the trial version is based on isn't supported on the release of RHEL you are targeting, and perhaps you have stumbled upon one of the reasons why that is the case.
... View more
01-02-2022
08:15 PM
1 Kudo
@noamsh_88, to recap:
You started out the thread saying that you are "using Cloudera V5.1.1 with log4j v1.2.17" and asked how you could upgrade to the latest version of log4j on CDH V5.1.1.
@GangWar replied that CDH 5.x is not and would not be tested with a later version of log4j, as CDH 5.x has reached End of Support (open that link and then expand the section labeled "Cloudera Enterprise products" underneath Current End of Support (EoS) Dates) and so if you tried it, you would be on your own.
He also wrote that CDH-5 was not impacted by the log4j vulnerability described in log4j2 CVE-2021-44228
You replied on 2 Jan that you ran the "patch for log4j provided at https://github.com/cloudera/cloudera-scripts-for-log4j" and asked:
how can we verify our env is out from log4j risk?
is there some java classes we should verify inside?
The very first sentence of the README.md file that renders in the browser automatically when one visits the URL you shared earlier for the cloudera-scripts-for-log4j reads:
This repo contains scripts and helper tools to mitigate the critical log4j vulnerability CVE-2021-44228 for Cloudera products affecting all versions of log4j between 2.0 and 2.14.1.
Emphasis added.
As @GangWar indicated, your environment, based on CDH 5.x, should not have had a version of log4j between 2.0 and 2.14.1 installed, and therefore should not have been vulnerable to the the log4j vulnerability described in log4j2 CVE-2021-44228. This is because, as you yourself pointed out in your original post on 23 Dec, you only had log4j v1.2.17 installed in your environment. log4j v1.2.17 is not a version of log4j between 2.0 and 2.14.1.
This also explains why, after you ran the script intended for systems using log4j versions between 2.0 and 2.14.1 on a system using log4j v1.2.17, the log4j V1 jars were not removed.
But since you ran the script for log4j provided at https://github.com/cloudera/cloudera-scripts-for-log4j anyway and presumably still have it handy, you could check manually for log4j .jar files in your environment in a similar manner that the script does and verify for yourself that none of those files still have the JndiLookup.class still present and thereby verify your environment is not at risk to the log4j vulnerability described in log4j2 CVE-2021-44228 (this information is also in the same README.md file on GitHub where the script you ran is being distributed from).
... View more
12-28-2021
10:07 AM
@Fawze that is why I asked @chr_heim what version he was talking about. It's a little imprecise to say "Cloudera is using the 1.x log4j", because different versions of Cloudera's distributions use different versions of the log4j library.
If you're interested in CDH 5.x, then sure, the version of the log4j library you most likely have deployed is log4j 1.x (you should confirm this for yourself) and you should confirm for yourself by consulting the appropriate documentation whether or not log4j 1.x is even affected by CVE-2021-44228 and therefore if applying Cloudera's short-term mitigation is necessary. My reading of the advisory that The Apache Security team released earlier this month addressing CVE-2021-44228 is that it affects Apache Log4j, versions 2.0 through 2.14.x. Other versions of CDH use a version of Log4j that is definitely within this affected group.
See Cloudera Response to CVE-2021-44228 for the details.
... View more
12-17-2021
10:33 AM
Christian,
You didn't indicate what version of CDH you're running the aforementioned script on, so other members of the community with the appropriate knowledge and inclination to offer assistance won't be able to offer an answer to your questions.
... View more
12-13-2021
01:55 PM
@Eric_B Yes. There is a link for non-customers of Cloudera in the blog article linked above. It's at the end of the paragraph beginning "What Cloudera products and versions are affected?"
... View more
11-30-2021
05:19 PM
@AWlodarczyk No, I can neither confirm nor deny that any or all of the three specific point releases of the Azul Zulu OpenJDK you've listed is officially compatible with CDP and supported by Cloudera. This thread will remain open and perhaps someone in Cloudera support will see it and reply here.
... View more
11-26-2021
08:14 AM
Hi @AWlodarczyk You can figure out the answer to your question by consulting the documentation for CDP Private Cloud, starting out at this page: Java Requirements …and scrolling downwards until you find the JDK you are interested in.
... View more
11-17-2021
10:49 PM
Hi @Aryan007 You didn't indicate what version of Cloudera Manager you are talking about or what distribution of Cloudera software you're using it with. But here is the relevant text from the documentation for Cloudera Enterprise 6.3.x: Cloudera Enterprise - All services will continue to run as-is. The Cloudera Manager Admin Console will be disabled, meaning that you will not be able to view or modify clusters. Key Trustee KMS and the Key Trustee server will continue to function on the cluster, but you cannot change any configurations or add any services. On license expiration, the only action you can take in the Cloudera Manager Admin Console is to upload a new, valid license. Emphasis added. I would recommend reaching out to your Cloudera Account representative to discuss your options prior to making assumptions about what you will be able to do with Cloudera Manager following letting your subscription lapse.
... View more
11-09-2021
10:19 AM
Welcome to the Cloudera Community, @SAYB ! I have been using both Oracle and PostgreSQL DBMS's heavily for quite some time, and it's not clear, to me at least, what you mean when you write you want to "extract the header of a table from oracle database". For the same reason, it's not clear what "execute a create statement to store the header into postgresql" means. Let's assume that by "the header of a table", you mean the output of Oracle's Describe command, which provides the user with a display indicating the structure of the specified table, including the column names and the data type for each column. If that assumption is correct, perhaps you mean that you'd like to use NiFi to obtain the structure of a table in Oracle, and have it CREATE a similar table in postgresql, by translating in some automated fashion between the datatypes available on that specific source Oracle database and the data types available in the target PostgreSQL database. That is typically something that you'd do only once per schema pair. Does your task involve many database tables, and are you going to have to do this task over and over again?
... View more