Hi @Vijay11  You didn't say which release of Ambari server you're interested in, so I strongly recommend that you first consult the Cloudera Support Matrix on Cloudera's website, to confirm that your desired version of Ambari server is actually available for the release of RHEL you are targeting. The Ambari project at Apache might have different OS support levels available, although you should be aware that the Ambari project was retired in January of this year.   As far as access to the repository you mentioned, last year Cloudera changed their download policy and now to download Ambari binaries from Cloudera's private repository, you need a valid subscription. Please see and carefully read the announcement here: Transition to private repositories for CDH, HDP and HDF. Toward the end of that announcement, you will see a section subtitled Ambari 2.7.x.x and HDP 3.x.x.x. You should follow the appropriate hyperlink underneath that and then carefully read the documentation. Note that the credentials to access the private repository where Cloudera is now distributing releases of Ambari are not generally the same ones to access Cloudera's website or the Cloudera community.     ... View more

Hi @BugFixer  I think it's unlikely. That's because, if I recall correctly, the price of a CDH 6 subscription depends on a number of factors, some of which are specific to your target deployment that other members of the Cloudera Community are not going to be familiar with. Your single best approach would be to contact the Cloudera Sales Team to find out more about subscription options.   That being said, you should know that Cloudera Enterprise 6 is reaching its EoS Date this year. 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 only 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 deploying CDH 6 will essentially become obsolete later this year. For that reason, I would not recommend spending time on that stack. I also think — for the same reason — it will be difficult for you to get someone in sales to contact you in response to your inquiry unless you already have a Cloudera subscription and want to extend an expiring CDH 6 subscription.   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 6. If you're interested in acquiring a subscription for an up-to-date data platform, you can contact sales at the same page linked above.      ... View more

@MikedMike  asked: I've updated my hosts file as follows at the following location: C:\Windows\System32\drivers\etc, I believe this is correct? Yes, you should be able to locate and edit a file named "hosts" in that location on Windows.   Why don't you post a screen grab of the confirmation screen presented when you completed the installation? It'll look like this: You might be going to the wrong URL or using the wrong port number when you attempt to load the welcome page.     ... View more

Hi @yougham  The first thing you should try is simply to use a browser that is not Google Chrome. By default, Chrome uses the HTTPS protocol when a user navigates to a websites by manually typing a URL. You are probably not going to be able to connect to the HDP Sandbox welcome page using the HTTPS protocol, because in order to do so, you would need to enable HTTPS on the web server embedded with the HDP Sandbox installation. As it is delivered via the Cloudera website, the HDP Sandbox is not set up for this (although a sophisticated UNIX/Linux system administrator could get it to work with sufficient effort). That is why, when the browser attempts to use HTTPS, you get an error message in response that indicates the server "can't provide a secure connection". By using a different browser which does not use this default behavior, you should be able to access the HDP Sandbox Welcome page using the HTTP protocol.   The second thing you should try is to type out the full URL in the browser location bar. You can do this by not relying on the browser to supply the protocol and manually specify HTTP by intentionally typing, for example, http://localhost:4200/ (beginning with the http://) in the browser location bar. Indeed, if you closely examine the screen shots in the Sandbox Deployment and Install Guide, you'll see that nowhere do they indicate that you should use the https:// protocol prefix to initiate your Hortonworks Sandbox session. It's easy to get confused on this point because the URLs for the documentation and the HDP Sandbox download website do specify the https:// protocol prefix.     ... View more

Hi @rahi  Just reading the download URL you're using, it appears that you are aware that last year, Cloudera modified its download policies and the binaries you are seeking to access are now only available in a private repository. If not, please see the announcement here: Transition to private repositories for CDH, HDP and HDF   if you are aware of this, then you are probably getting the HTTP 401 Authentication Required error because you are not using the correct credentials to access the private repository. The credentials to access this private repository are not generally the same ones to access Cloudera's website or the Cloudera community. Instead, individuals working at companies with a valid Cloudera subscription can generate repository credentials from a CDH license key, and there is a full description of how to do this in the Cloudera Enterprise 6.x Release Notes here: Version, Packaging, and Download Information …under the subheading Obtain Credentials, among other places.   What you should also be aware of, however, is that Altus Director has already reached its EoS date of July 2020. Cloudera's lifecycle support policies are documented here: Support lifecycle policy (open that link and then expand the section labeled "Cloudera Altus (Platform as a service)" underneath Current End of Support (EoS) Dates). At that last link (as of this writing) you can read that Cloudera 6.3 is only supported until the end of March 2022 (The last version of Director was 6.3.1). 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 deploying CDH using Altus Director will essentially become obsolete later this year. For that reason alone, I would not recommend spending time on that stack.   Cloudera's current Enterprise Data Platform, since the Fall of 2019, is Cloudera Data Platform (CDP), which in its cloud-based "form factor" is now called CDP Public Cloud. CDP supersedes CDH as Cloudera's Enterprise Data Platform offering. If you are looking to evaluate a current data platform for use within your company utilizing AWS, then you can follow the instructions for using the latest CDP stack with the public cloud option by consulting the AWS quick start documentation.     ... View more

Hi @ryu  Just from reading the absolute file path you've called out, evidently you are running log4j version 1.   To back up a bit for the sake of other community members who might be reading this: the chief reason we're even talking about this is because Log4j 1 reached its end of life (EOL) and is no longer officially supported by the Apache™ Logging Services™ Project as of 5 August 2015, over six years ago now. But largely due to the increased scrutiny of Log4j in general in the wake of the CVE-2021-44228 vulnerability (which impacted Log4j 2), a new vulnerability that was rated lower in severity has come to light, CVE-2021-4104, which does affect Log4j 1. But again, Log4j 1 has reached EOL, and Apache's Logging Services™ Project isn't providing any more releases for Log4j 1, even to remediate serious security vulnerabilities. For both of these and for other reasons, the best practical approach is to upgrade to a more up-to-date data platform that is being actively supported.   Cloudera's current Enterprise Data Platform, since the Fall of 2019, is Cloudera Data Platform (CDP), which in it's on-premises "form factor" is now called CDP Private Cloud. CDP supersedes HDP as Cloudera's Enterprise Data Platform, and as an aside, HDP 2.6.1 reached it's end of support date in December 2020 (open that link and then expand the section labeled "Hortonworks Data Platform (HDP)" underneath Current End of Support (EoS) Dates). As a core part of its business, Cloudera addresses customer needs for vulnerability remediation as part of the benefits of a subscription agreement even when Apache no longer supports an impacted component.   You can read Cloudera's judgement about how concerned you should be about that Log4j 1 vulnerability here: Cloudera response to CVE-2021-4104   The reason upgrading is the best practical approach is because arguably the proper way to upgrade log4j is to go through the source code for all the affected components that use the Log4j version you are trying to avoid, become intimate with the details of how they use the various Logging APIs and then update or even totally rewrite the code that uses those existing, risk-exposed APIs to use the APIs in the new, replacement version of log4j 2 that is not exposed to known vulnerabilities (presumably 2.15.x or later). Then recompile against log4j 2 exclusively, unit test and release each changed component, and then test the entire system as a whole for regressions. And then finally migrate the completed product with only log4j 2 to production. As you probably understand, that takes a lot of engineering effort and it's not something a data platform administrator or even a data platform team at an enterprise that is using HDP for it's internal data management needs, for example, should be expected to complete on their own.   Upgrading the platform to a new, more up-to-date release that is actively being maintained is the next best thing, and as a practical matter, its better. It allows data platform users to take advantage of the fact that the data platform provider/vendor is going to have those substantial engineering resources and be able to bring them to bear on the necessary API updates on an ongoing basis and in a timely fashion.   If for whatever reason you aren't able to or are unwilling to upgrade and don't have a subscription agreement…well, just engaging in a bit of logical deduction from first principles (because I don't have access to an HDP 2.6.1-based cluster at the moment to actually try it) I think the short answer to this portion of your question: Can we just replace the log4j jar file with an upgraded version? …is a qualified "No". Some of the critical APIs for Log4j 2 are simply not backwardly-compatible with Log4j 1, so you should assume that just dropping in the Log4j 2 .jar files into an existing HDP installation is not going to work without issues. Other members of the Cloudera Community have reported that even dropping the Log4j 2 .jar file(s) into an installation of CDH 6.3.x, which was built with Log4j 2 specifically, produced less than desirable results.   However, there does exist a Log4j 1.x bridge which reportedly will "forward" all requests for Log4j 1 to Log4j 2, assuming that you have a valid Log4j 2 installation, so you might want to explore that option if you can test it out on a non-production cluster first. It also requires that you do a thorough job of removing any Log4j 1 jars in the application's CLASSPATH for any Hadoop component. It goes without saying that Cloudera doesn't support this however and again, I haven't tried it so you should only proceed down this path if you are desperate to remove a Log4j 1 installation, don't have or can't obtain a subscription agreement and have a solid plan to roll back the change if it doesn't work out.     ... View more

@kevmac you and @Eric_B can find out about the actual target Log4j library version for Cloudera's suggested remediation by consulting the blog post Cloudera Response to CVE-2021-44228. The version of the Log4j library that the aforementioned remediation script is intended for is specified in the very first paragraph, sub-headed Summary.     ... View more