Member since
07-29-2019
640
Posts
114
Kudos Received
48
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
10952 | 12-01-2022 05:40 PM | |
2744 | 11-24-2022 08:44 AM | |
3948 | 11-12-2022 12:38 PM | |
1435 | 10-10-2022 06:58 AM | |
2077 | 09-11-2022 05:43 PM |
01-17-2022
08:19 AM
I suggest you try to set your path with "\" instead of "/" for example: C:\Users\kiran\Downloads\mysql\mysql-connector-java-8.0.17.jar it worked out for me!
... View more
01-14-2022
09:37 AM
Hello @jludac Thanks for letting us know. Yes. To access the archive repos, you will need to access it through the shared wall credentials
... View more
01-10-2022
03:16 PM
Hi @tableau
Please read the relevant Support Announcement here: Cloudera response to CVE-2021-4104 which also has information on what steps to take if the support announcement isn't sufficient to answer your questions.
... View more
01-10-2022
07:36 AM
Hello, I'd like to understand what does having a valid subscription entails for a small cluster hosted on company servers. PS: I'm trying to get in touch with sales to get more informations but so far no luck
... View more
01-03-2022
08:22 AM
Thanks @ask_bill_brooks for the reply, I'll check.
... 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
01-02-2022
02:01 PM
Hi @sagarbot ,
First and foremost, you should understand that CDH 5.16 reached it's end of support date in December 2020 (open that link and then expand the section labeled "Cloudera Enterprise products" underneath Current End of Support (EoS) Dates). The current Enterprise Data Platform offered by Cloudera is Cloudera Data Platform (CDP), which in it's on-premises "form factor" is offered as CDP Private Cloud. CDP supersedes CDH as it is fairly up to date on all the included components, which is not the case with CDH 5.16. For these reasons, it's going to be increasingly difficult to get answers to your questions about CDH 5.16 going forward, as fewer and fewer members of the community use that version and therefore your organization should be actively looking into upgrading.
That being said, there is a lot going on in the screen shot you provided. I'll focus my response on this bit, based on your Subject line for this post:
[centos@ip-i72-31-2-199 -1$ systemctl status cloudera-scm-server.service
. cloudera-scm-server.service - LSB: Cloudera SCM Server
Loaded: loaded (/etc/rc.d/init.d/cloudera-scm-server: bad; vendor preset: disabled)
Active: active (exited) since Fri 2021-12-31 20:03:52 UTC; 10min ago
DOCS: man: systemd-sysv-generator (8)
Process: 7268 ExecStop=/etc/rc.d/init.d/cloudera-scm-server stop (code exited, status=1/FAILURE)
If I am interpreting your question correctly, your issue is that the /etc/rc.d/init.d/cloudera-scm-server script is not responding in the desired manner when you supply the stop argument on the command line. If that's the case, you need to consult the logs for that script and deduce what is going on from what is being logged there. It could be any number of things, but I think it will turn out to be a problem addressable with regular Linux (Centos) System Administration skills.
I believe that by default, the logs for that script can be found on the Server host at the location /var/log/cloudera-scm-server/cloudera-scm-server.log so that is the first place you should go and look (but it's been a long time since I've seen a CDH-5 based system). You might want to post what you find there in this thread if the problem isn't obvious and perhaps other members of the community who are still running CDH-5 will post something helpful. If the logs aren't present in that directory, you may have to find someone in your organization who knows how the system was installed and configured and ask them.
... View more
12-23-2021
12:50 PM
@brconejeros
You didn't provide any detail about which repository you were attempting to download from or the hostname you were using.
If you're attempting to download the binaries for Ambari from Cloudera's repositories you should closely read this announcement: Transition to private repositories for CDH, HDP and HDF
One alternative would be to download and/or install Ambari 2.7.0.x from Apache's site.
... View more
12-16-2021
11:57 AM
@Saraali 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
12-12-2021
04:42 PM
Hi @Army
It appears that you are attempting to run a version of the Cloudera Quickstart VM that is based on CDH 5.4.2. Hopefully you are aware that the 5.4.2 version of CDH was released way back in May 2015 (that was quite a while ago, especially in terms of "internet time") and is probably severely out of date when compared to the hardware, host OS and virtualization platform you are attempting to run it on. In addition, Cloudera is no longer making that version of the Cloudera Quickstart VM available for download because the version of CDH it was based on went out of support last year. For both these reasons, obtaining a quick resolution to your specific issue from the Cloudera Community will be challenging.
Unless you have some very compelling reason to run the Quickstart VM, you'd be much better off installing and running a much more up-to-date data platform. The current Enterprise Data Platform available from Cloudera is Cloudera Data Platform (CDP), which in it's on-premises "form factor" is offered as CDP Private Cloud. CDP supersedes CDH as it is fairly up to date on all the included components, which is not the case with CDH 5.4.2. You can download and install the Trial Version of CDP Private Cloud Base Edition of Cloudera Data Platform without an existing valid Cloudera subscription.
All that being said, if you must troubleshoot your particular installation of the Cloudera Quickstart VM, your logical first step would be to examine the log file located on your file system at the location
C:\Users\User\VirtualBox VMs\cloudera-quickstart-vm-5.4.2-0-virtualbox\Logs\VBoxHardening.log
…and take steps based on what it says. You stand a better chance of obtaining assistance if you cut-and-paste the text present in that file in a reply to this thread; that might jog the memory of some other community member with specific expertise on virtual box.
... View more