I am attempting to install Cloudera Manager on an EC2 instance following these directions. They indicate that once I have installed Manager and navigated to the EC2 host page at port 7180, it will automatically detect that it is running on an EC2 instance and allow me to have it deploy and configure my hadoop cluster. The docs mention an EC2 related warning message on the welcome screen. Instead I get a different welcome screen that doesn't mention EC2:
When I click continue I get a second screen where I am required to enter the name or ip of existing hosts:
So it appears that the express wizard doesn't detect that it is running on EC2. Does anyone know why this might be occurring?
Related
My computer is OSX. I'm logged into an ssh connection (Ubuntu), and from there I'm ssh'ed into an OpenStack instance of Ubuntu 14.04. From this OpenStack instance I've been following a Docker-Compose tutorial from the Docker docs : https://docs.docker.com/compose/gettingstarted/
I'm on Step 4, and I'm successfully running a server that is running on http://0.0.0.0:5000/
However, I don't know how to view a GUI Google Chrome browser from my Macbook. Because whenever I go to http://0.0.0.0:5000/ it says server not found, which makes sense because it's not on my computer.
I read something about port forwarding, but I'm not sure that's right here. I'm fairly new, so please help!
Also, is this the right way to use an OpenStack machine? That you use your computer's web browser to view the web app?
I solved it myself. Turns out on OpenStack, you need to create a security group and then add it to your instance. When you create a security group, you can add a port that you want to provide public access to. And then you can view the web app on any computer by typing in your floating IP on OpenStack, colon separated by the public port address.
I am testing the free services from Amazon EC2. I followed the manual and was able to access the server. After one minute inside the server, it crashes and I have to close my console and reboot the instance.
By reading the guides from Amazon, I found that I should set the Route Table, which I was not able to find. Maybe the dashboard has changed.
I have Apache server running on Centos5.4 Ec2 instance. Unfortunately while removing Bash from Centos, it also removed basic shared libraries.
Now afterward I can't SSH to that EC2 instance but Apache server is still running (I can access my site through URL).
Any idea how can I get the SSH access back? or can repair Centos Ec2 instance?
Thanks!
You can always contact the AWS support directly. They are very accommodating. send a message to them and they will recover your access, if it is doable from their end.
You may call, or you may send a message from your AWS account.
I booted the DataStax AMI for Amazon EC2, logged in via SSH, but the terminal hangs on "Installation Started":
Cluster started with these options:
--clustername CassandraDev --totalnodes 1 --version enterprise --username **** --password ****
Installation started.
"Installation started" keeps going through suffixes consisting of one, two, and three dots. But nothing happens, I can't quit the installation process, and I can't access any log files to see what might be going on (or I don't know how).
Tried on two separate m3.large instances operating in a VPC subnet, at the us-east-1 region. The exact AMI is datastax_clustering_ami_2.5.1_hvm.manifest.xml (ami-ada2b6c4). On the first instance, I waited about an hour and a half. The second instance I just left online all night, with the same results.
Because this is a VPC, all outbound traffic goes through a NAT server. Security groups allow outbound traffic only on ports 80, 443, and 123. Might there be another outbound port that needs to be opened? Inbound ports do not matter, as the server is not public-facing, but within the subnet I have allowed all traffic on all ports.
Someone else has had a similar issue, but without answers so far: DataStax AMI hangs on
Any help would be appreciated!
Since there were a few tickets that came up recently around the same issue, it seems as though something recently changed within the AMI provisioning side in EC2, or this specific configuration of VPCs had never been used before, which seems a bit unlikely.
The current fix is to add an additional entry into /etc/hostname to get rid of the stderr output that occurs after each sudo command. This in turn doesn't get flagged as an error on the provisioning side.
This has been fixed and patched as documented on this ticket:
https://github.com/riptano/ComboAMI/issues/51.
If you spot any additional issues, feel free to create another ticket there.
Going forward, just launch another set of instances using the same user-data and you should be up and running.
I have an ec2 instance serving a webpage with apache. I created an autoscaling group using an AMI of this instance in the launch config. Once CPU went over 80% and the autoscale policy ran, a new instance was created. But the CPU of my original instance continued to rise and the CPU of my new instance remained at 0%.
The new instance was not serving the web page. I am guessing this is because apache was not started with the launch of the image. I tried to ssh into the new instance to run "service httpd start" but I got the following error:
ssh: Could not resolve hostname http://ec2-xxx-xx-xxx-xxx.compute-1.amazonaws.com:
nodename nor servname provided, or not known
Why could I not ssh in? How do I configure autoscaling to automatically start apache on launch?
It would appear that you are attempting to ssh to a host with http:// in the hostname. Remove that and ssh should work.
Assuming that you created an AMI to use in AutoScaling, you would need to ensure that you chkconfig httpd on in the source instance before creating a new AMI for AutoScaling.
In order for you to connect to an EC2 instance you need two things:
The Security Group associated with your instance has an inbound rule that allows SSH communication.
Make sure you have the private key generated for the instance. Note: This is only needed if you chose to use a key in the first place.
If those two things are correct, then you can connect to your instance like this:
ssh -i "PATH_TO_YOUR_KEY.pem" ec2-user#ec2-xxx-xx-xxx-xxx.compute-1.amazonaws.com
For the other point, that is, to make sure you can start apache on launch, you can do two things:
As #atbell mentioned on a previous answer, you can make sure that the chkconfig YOUR_SERVICE on is on the AMI used to start your instance.
You can add a command as user data to your LaunchConfiguration so it runs it as soon as the instance is started:
What this will do is run start YOUR_SERVICE start as soon as the instance can respond to commands. So, whenever your AutoScaling group creates another instance, your service will surely be started. Note that the commands added to the user data field of the LaunchConfiguration are, by default, going to be executed as sudo.