Hi @nivanecu  You didn't say what set of instructions you were following in order to do the installation, so this is going to be somewhat difficult to troubleshoot…but from what I've gathered from the output you've provided, you're attempting to install the HDP Sandbox. It seems like the problem here is not any issue with the HDP Sandbox, but with your use of Docker. Just picking up on the error message you've emphasized here:   docker: Error response from daemon: Conflict. The container name "/sandbox-hdp" is already in use by container "b1c48478c7d48e681a706f86de84fd23978be91001aef9efc6da18a24f99c21f".   It appears that you have a pre-existing container that is causing a conflict. As a first stab at a solution, you could try removing that other container.   First, you're going to want to get a listing of all the containers you have. Issue the command docker ps -a at the command line. The output will give you a list of all the containers you have in use and their status. Confirm for yourself that the container identified by the error message is not in the 'running' status.   Then you can remove the container by issuing a command something like:   MBP15:~ ask_bill_brooks $ docker container rm -v \ b1c48478c7d48e681a706f86de84fd23978be91001aef9efc6da18a24f99c21f   Which will allow you to reuse the name that is causing the conflict you're encountering.     ... View more

@MikedMike  I take it from your response (the screen shot you uploaded was not legible) that you were ultimately able to access Ambari via the URL and port number available on your machine.   The behavior you are now describing could be due to lack of memory available to the virtual machine. Note that the Sandbox Deployment and Install Guide calls for at least 10 GB RAM dedicated to the virtual machine, but that doesn't mean it will perform acceptably at that level, more RAM is better. Those instructions were written against Virtual Box version 5.1. If you have it available, you might want to try shutting everything down gracefully, allocating more memory to the virtual machine and then starting everything up again and seeing if responsiveness improves.   Another approach would be to give up on using the HDP 3-based Sandbox because it is no longer current (for example data analytics studio is on it's way out and Ambari is already dead). If you're just looking to evaluate a data platform, you can currently do so without a Cloudera subscription by downloading and installing the Trial Version of CDP Private Cloud Base Edition of Cloudera Data Platform. Cloudera has an extensive tutorial on installing CDP Private Cloud Base in an Infrastructure as a service (IaaS) fashion using AWS on its website.     ... 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

Thanks @ask_bill_brooks a lot for the detailed explanation and it answered my question. ... 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 @ask_bill_brooks , Thanks for the suggestion. I have obtained the username and password. and while I use the link over browser I am able to view parcels, However I am unable to download it using script. Can you suggest over this that why am I getting the invalid URL error? Attaching the screenshots for reference. the same URL on browser URL used to launch 5 EC2 nodes and download reporitories Error as Invalid URL ... 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