I'm trying to build a t2.mirco Ubuntu 12.04 EC2 environment running Airtime from Sourcefabric, however despite the installation going through OK I cannot access the login page via the address that the installer provided. I have change my security settings several times but I feel that it might have something to do with it. I have ran system checks to see if airtime is working and it returns a perfectly operating copy every time. The address that i'm trying to access the installation on is http://ip-172-31-5-46.us-west-2.compute.internal does anyone know why Amazon AWS is reacting this way?
The URL you just provided is EC2's internal DNS address (note the ".internal" at the end), if you want it to be accessibly publicly you'll need to assign an Elastic IP to the EC2 instance, or auto assign a public DNS on creation of the instance
Amazon docs for reference
Related
I am trying to upgrade my hosting from the 1GB RAM to the 2GB RAM instance from an existing Plesk Lightsail snapshot to another Plesk instance. I was able to create a larger instance and load the snapshot successfully. I was able to access the files via FTP and the databases were all present as expected. However, when I logged into Plesk via {NewStaticIP}:8443/ (using the same credentials as I did with my old instance), I was able to login but the IP address shown was still the old one.
The mistake I made was that for my old instance, I had not assigned a static IP and was using the default public IP provided by Lightsail. If I had defined a static IP to the old one, it would have been easy. I would detach the static IP from the old and attach it to the new and there would be no need to make any change in the DNS records even.
However now, even if I change the A record to point to the new Static IP I've assigned to the new instance (I use Cloudflare), it propagates instantly but shows me a "Web server is down" (Cloudflare error 521). This is confusing me because the server has been set up and I can access it via FTP. Ports 80, 443, 8443, 8447, 21, 22 are all open as well.
When I try to access the website using the static IP, it shows an error that the server refused to connect.
In addition, via Plesk Tools, I was able to change the IP address shown for that server but I also read that it's not the best way to change the address of the server so not sure if this helps or not.
Any help regarding this would be much appreciated. Thank you...
Just need some help as I am new in this system and the previous guy did not provide much documentation.
Currently the jenkins server is hosted in Aws in an instance but this instance only have a private ip address thus the only way of routing to the internet would be through another instance of ours that is hosted in Aws too but in another private ip address. But as we are new to this system, we accidentally stop and start all our instances. Thus now our jenkins are unable to fetch from our github.
To Note the public ip has changed but private ip has not changed
TLDR
-how to allow our instance 1(jenkins) ssh to instance 2(public) that will route out to the internet so as to fetch the code back to instance 1?
Any solution to this? as currently we tried these few method
- create a new job with same configuration worried if file corrupted
- make sure the plugin version is align with the previous working one
- tried to git config --global but there is no config file in jenkins or not under .ssh/config
I've been tasked with getting a new SSL installed on a website, the site is hosted on AWS EC2.
I've discovered that I need the key pair in order to connect to the server instance, however the client doesn't have contact with the former web master.
I don't have much familiarity with AWS so I'm somewhat at a loss of how to proceed. I'm guessing I would need the old key pair to access the server instance and install the SSL?
I see there's also the Certificate Manager section in AWS, but don't currently see an SSL in there. Will installing it here attach it to the website or do I need to access the server instance and install it there?
There is a documented process for updating the SSH keys on an EC2 instance. However, this will require some downtime, and must not be run on an instance-store-backed instance. If you're new to AWS then you might not be able to determine whether this is the case, so would be risky.
Instead, I think your best option is to bring up an Elastic Load Balancer to be the new front-end for the application: clients will connect to it, and it will in turn connect to the application instance. You can attach an ACM cert to the ELB, and shifting traffic should be a matter of changing the DNS entry (but, of course, test it out first!).
Moving forward, you should redeploy the application to a new EC2 instance, and then point the ELB at this instance. This may be easier said than done, because the old instance is probably manually configured. With luck you have the site in source control, and can do deploys in a test environment.
If not, and you're running on Linux, you'll need to make a snapshot of the live instance and attach it to a different instance to learn how it's configured. Start with the EC2 EBS docs and try it out in a test environment before touching production.
I'm not sure if there's any good way to recover the content from a Windows EC2 instance. And if you're not comfortable with doing ops, you should find someone who is.
I'm running GitLab CE privately within an AWS VPC that I access via a VPN instance. I installed the latest AWS AMI of GitLab CE, then upgraded it to the latest version of GitLab. I've gotten everything working, except for one thing: Whenever I reboot the instance in EC2, my /etc/gitlab/gitlab.rb's external_url is reset to the IP address of my VPC's SNAT instance, almost as if GitLab is asking "what is my public IP?" and then changing the setting's value to that answer. I keep changing it back to the internal hostname provided by my VPC's Route 53 hosted zone, https://gitlab.corp.mydomain.com, but it's reset every time I reboot the instance. To be clear, this GitLab instance is not exposed to the internet, but it does have egress to the internet through the SNAT (e.g., to update OS packages).
How can I force my internal hostname to stick? I can still access GitLab through my browser at https://gitlab.corp.mydomain.com, so perhaps this doesn't matter?
After a quick search I have found this.
https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/2021
Summary of the content:
It seems like Gitlabs hostname detection is not working correctly if public IPs are deactivated in EC2. To enable usage in such cases Gitlab replaces the hostname with the assigned IP. Gitlab will return to the hostname if it can resolve it later, at least from version 10.1.3.
As it works for you, I would simply keep the configuration.
I created a VM using Hyper-V on my local machine which I can RDP onto fine. I exported the VHDX to VHD and then uploaded it to AWS via the API.
This created a new EC2 instance for me but I cannot connect to it as it has no security keypair associated.
Thus I created a private AMI from the instance and re-instantiated a new EC2 instance from this AMI, setting the keypair in the process to ensure HTTP, RDP etc are permitted. The EC2 instance is running, but when I download teh RDP shortcut if fails to connect. I've tried rebooting the instance several times (as this was one of the suggested solutions on here when I searched) but it hasn't helped.
I also cannot ping any of these instances via the public DNS or private DNS.
Any idea what I'm doing wrong? I'm not even getting as far as the password prompt, its the connectivity is the problem.
Thanks
I had a similar problem - this is the tip from the AWS documentation that helped me solve it:
Verify that the route table for the subnet has a route that sends all traffic
destined outside the VPC (0.0.0.0/0) to the Internet gateway for the VPC
Additional debugging tips for this problem can be found here: Remote Desktop can't connect to the remote computer
The problem is probably the security group configuration attached to the instance. Make sure you have inbound TCP port 3389 permitted to be able to connect via RDP.
in username type:
.\Administrator
....and your decrypted password
See, this is local user. but you dont know real local hostname, that different from public DNS name.
Was helpful for me, hope for you too.
My guess for the reason you aren't getting anywhere has to do with the host certificates.
Be mindful that each computer connecting to the server via RDP needs to have an IAM user in AWS with an X.509 certificate uploaded to their account.
When importing or creating a windows AMI it is best to install and configure the EC2Config service.
The EC2 Config service does the following when you launch the instance:
At initial setup:
Sets the hostname to the private DNS name
Generates and sets a random password on the Administrator account
Initializes and formats the ephemeral disks
Generates and installs the host certificate used for Terminal
Services
Syncs the instance clock with a time server
After initial setup:
Writes the last three entries in the System event log to the Amazon
EC2 console so you can debug startup problems.
Prepares instances for bundling
Also, by default, security groups do not allow you to ping the instances. You must enable ICMP in the security group.
Hope that helps.
EDIT: Here is the link to the 64bit version of the EC2Config Installer
I also had the same problem. This is what I got from EC2.
Public DNS ec2-23-22-109-251.compute-1.amazonaws.com
User name Administrator
Password MyPassword
On the remote desktop, enter the domain and user name as
ec2-23-22-109-251\Administrator
If you paste the password is may not work, try to paste it but reenter the last 1 or 2 characters. Once you get the security certificate prompt accept/install it and your connection should open soon.
This is what worked for me:
Use your cell phone as a "hot spot" - which gives you a static IP address. That worked. Now, I'll need to contact my Internet provider to assign a static IP to my wireless router. Currently, it is spitting out DHCP IP addresses.
UPDATE:
12.7.2016
You need to go to the Security Group, select the Instance, then EDIT the RDP. If you click "MyIP" that should work for those of us working from home. If you are onsite, you may need to put in a custom CIDR.
After rebooting an EC2 instance, I found that I needed to reassociate the Elastic IP address associated with the instance. You click the button below then select the instance and private instance IP address when prompted.
RDP access worked after this step.
After patching Windows 2019 on my server, I couldn't access the instance anymore despite all my working settings didn't change. I used EC2Rescue to fix my issue
Please refer to the link below for details on how to use it: https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/troubleshoot-connect-windows-instance.html#AWSSupport-ExecuteEC2Rescue