I'm facing an issue with my ec2 instance. Until now, I had an ec2 instance working with an IP like this: ec2-xx-xxx-xxx-xxx.compute-1.amazonaws.com.
Now I configured an elastic IP to make that instead of use the default domain uses one of my own.
Something goes wrong because now a receive a 403 if I make a request pointing to my new domain.
I'm check that I'm still able to connect to my Ubuntu server 20.04 LTS through SSH. Only have to change the host name to my new domain.(I'm using PuTTy)
Searching on internet if found that the problem can be that my machine still have the old domain in some config files. I don't have experience with Ubuntu servers. I try to find the http.conf file or the apache2 directory in etc., but no one is present.....
I don't know what to do next.
I have to change some configuration file? In that case, which one?
I leave you some images from my machine:
Root
etc folder
For further information, the security group of my ec2 instance have these rules:
Any help will be appreciated. Thanks
-EDIT
I'm trying to access the server, making a request, with Postman like this.
And that is the error:
For more information. I implemented my ec2 using this video:ec2 video
And I changed the domain with that video:link ec2 with namecheap domain
I'm afraid it is a propagation issue, that takes more time than the 48 hours, because now it starts to works without changing absolutely nothing. Sorry
It appears that your requirement is to point bochogame.com to an Elastic IP address.
You can do this by using a DNS Service, such as Amazon Route 53. You would create a A-Record record that points that domain name to the IP address.
If you are unfamiliar with these concepts, I recommend watching some YouTube videos such as DNS with AWS Route 53 - YouTube.
My AWS web servers are not showing a request for example '42.26.32.120'
Is there a way to see if our ALB has received a request from that?
We are unable to identify the cause of the issue, as the IPs is not in any of the access logs
Therefore, I am trying to find out where the request was lost.
I found some output against there queries
SELECT * FROM alb_logs
WHERE client_ip= '42.26.32.120'
but from the results This seems to indicate that after the new app launch ip haven't been able to connect ?
would that be behavior if clients had written our ALB location statically ?
and If the request just hung in ALB would it log
e.g. if it couldnt find target machine, or if ALB was no longer around
would we have logs in those cases ?
Any Short of help would be apricated.
I am unable to access AWS Elasticsearch Kibana with a browser.
I have set up an Elasticsearch instance within my VPC exactly as described here;
https://aws.amazon.com/blogs/aws/amazon-elasticsearch-service-now-supports-vpc/
I used the default IAM access policy template which is basicaly all current IAM profiles (*)
My EC2 webapp (xenforo forum) is happily connected and chugging away.
I would like to access my elasticsearch domain kibana endpoint via browser from my home PC.
The security group I attached to the cluster configuration includes a rule to allow ALL TCP inbound from my home broadband fixed IP address.
I log into the AWS console, click the Kibana link from the elasticsearch domain overview and... nothing, times out.
I have read everything I can find on the matter. No joy - except perhaps I should be signing my https requests as well which seems crazy complicated and my understanding is that IP access should be configurable with security groups?
Can anyone clarify?
to access Kibana, it seems the only way is pass proper header with your requests to.
We solved it by using https://github.com/abutaha/aws-es-proxy - its not niciest, but works for us.
requires to have aws-cli installed
requires to do bit of setup, but works well afterwards
hope it helps
Hi There are many ways to access Kibana here are some of them that I found:-
Use an SSH tunnel. For information on how to do this :- https://aws.amazon.com/premiumsupport/knowledge-center/kibana-outside-vpc-ssh-elasticsearch
Advantages: Provides a secure connection over the SSH protocol. All connections use the SSH port.
Disadvantages: Requires client-side configuration and a proxy server.
Use an NGINX Proxy. For information on how to do this, please visit reference :- https://aws.amazon.com/premiumsupport/knowledge-center/kibana-outside-vpc-nginx-elasticsearch
Advantages: Setup is easier, because only server-side configuration is required. Uses standard HTTP (port 80) and HTTPS (port 443).
Disadvantages: Requires a proxy server. The security level of the connection depends on how the proxy server is configured.
I am following this video tutorial on youtube https://www.youtube.com/watch?v=JbQbwum196g to install a Custom SSL Certificate with Cloud Front on my AWS Server, I followed all steps correctly and everything seems fine even created certificate on zone "us-east-1" (Virginia) as recommended on others posts I read but, I still get same problem, the problem I get is that server refuses Https connection, so every time I try to access https I get this error on browser "ERR_CONNECTION_REFUSED" for this error I can imagine is a permissions problem but, I don't seem to figure out what I am missing, can someone please give me a hand, thanks!
I am trying to set up Elastic Load Balancing (ELB) in AWS to split the requests between multiple instances. I have created several images of my webserver based on the same AMI, and I am able to ssh into each individually and access the site via each distinct public DNS.
I have added each of my instances to the load balancer, but they all come back with the Status: Out of Service because they failed the health check. I'm mostly confused because I can access each instance from its public DNS, but I get a timeout whenever I visit the load balancer DNS name.
I've been trying to read through all the docs and googling it, but I'm stuck. Any pointers or links in the right direction would be greatly appreciated.
I contacted AWS support about this same issue. Apparently their system doesn't know how to handle cases were all of the instances behind the ELB are stopped for an extended amount of time. AWS support can manually refresh the statuses, if you need them up immediately.
The suggested fix it to de-register the ec2 instances from the ELB instead of just stopping them and re-register them when you start again.
Health check is (by default) made by accessing index.html on each instance incorporated in load balancer. If you don't have index.html in document root of instance - default health check will fail. You can set custom protocol, port and path for health check when creating elastic load balancer.
Finally I got this working. The issue was with the Amazon Security Groups, because I've restricted the access to port 80 to few machines on my development area and the load balancer could not access the apache server on the instance. Once the load balancer gained access to my instance, it gets In Service.
I checked it with tail -f /var/log/apache2/access.log in my instance, to verify if the load balancer was trying to access my server, and to see the answer the server is giving to the load balancer.
Hope this helps.
If your web server is running fine, then it means the health check goes on a url that doesn't return 200.
A trick that works for me : go on the instance, type curl localhost:80/pathofyourhealthcheckurl
After you can adapt your health check url to always have a 200 response.
In my case, the rules on security groups assigned to the instance and the load balancer were not allowing traffic to pass between the two. This caused the health check to fail.
I to faced same issue , i changed Ping Protocol from https to ssl .. it worked !
Go to Health Check --> click on Edit Health Check -- > change Ping protocol from HTTPS to SSL
Ping Target SSL:443
Timeout 5 seconds
Interval 30 seconds
Unhealthy Threshold 5
Healthy Threshold 10
For anyone else that sees this thread as this isn't listed:
Check that the health check is checking the port that the responding server is listening on.
E.g. node.js running on port 3000 -> Point healthcheck to port 3000;
Not port 80 or 443. Those are what your ALB will be using.
I spent a morning on this. Yes.
I would like to provide you a general way to solve this problem. When you have set up you web server like apache or nginx, try to read the access log file to see what happened. In my occasion, it report 401 error because I have add the basic auth in nginx. Of course, just like #ivankoni remind, it may because of the document you check is not exist.
I was working on the AWS Tutorial on hosting a web app and ran into this problem. Step 7b states the following:
"Set Ping Path to /. This sends queries to your default page, whether
it is named index.html or something else."
They could have put the forward slash in quotations like this "/". Make sure you have that in your health checks and not this "/." .
Adding this because I've spent hours trying to figure it out...
If you configured your health check endpoint but it still says Out of Service, it might be because your server is redirecting the request (i.e. returning a 301 or 302 response).
For example, if your endpoint is supposed to be /app/health/ but you only enter /app/health (no trailing slash) into the health check endpoint field on your ELB, you will not get a 200 response, so the health check will fail.
I had a similar issue. The problem appears to have been caused due to my using a HTTP health check and also using .htaccess to password protect the site.
I got the same error, in my case had to copy the particular html file from s3 bucket to "/var/www/html" location. The same html referenced in load balancer path.
The issue resolved after copying html file.
I had this issue too, and it was due to both my inbound and outbound rule for the Load Balancer's Security Group only allowing HTTP traffic on port 80. I needed to add another rule for HTTPS traffic on port 443.
I was also facing that same issue,
where ELB (Classic-Load-Balancer) try to request /index.html not / (root) while health check.
If it unable to find /index.html resource it says 'OutOfService'. Be Sure index.html should be available.