I had two always free instances running Ubuntu 18.04 LTS on ca-toronto-1. I logged in to the console today to see that both of them have been terminated. I didn't upgrade to a paid account after my trial expired but my understanding was that I could continue using the always free eligible instances. How can I find out why they were terminated?
I have 2FA enabled on my account with a strong passphrase so I don't think my account was compromised. There's nothing showing in work requests for either instance.
This is a known issue and I believe Oracle's working on resolving the issue and hopefully, restore these "terminated" instances. Word is, emails have gone out to affected users. Meanwhile, if you're in a hurry to restore services, follow these steps:
Check that the boot volumes associated with the the terminated compute instances still exist.
If so, you can create a new instance from that boot volume.
If you were using ephemeral public IP addresses, then those would have been reassigned. I'd encourage you to create an assign a reserved IP address and then update your DNS records if they were previously associated to this instance.
Related
its second time when after reboot instance cannot connect to them via SSH. Before reboot all is working well. Can I use serial console, but not know the user and password.
In addition to the guide provided by #Kolban. When using serial console keep in mind that:
The interactive serial console does not support IP-based access
restrictions such as IP whitelists. If you enable the interactive
serial console on an instance, clients can attempt to connect to that
instance from any IP address. Anybody can connect to that instance if
they know the correct SSH key, username, project ID, zone, and
instance name.
More information you can find in the documentation Interacting with the Serial Console.
There're more ways to troubleshoot SSH connectivity then serial console. Have a look at the Troubleshooting SSH guide and Known issues for SSH in browser. In addition, Google provides a troubleshooting script for Compute Engine to identify issues with SSH login/accessibility of your Linux based instance.
In some cases, the cause of the connectivity problem could be running out of free space of you disk system. In this case update your question and I'll provide you extra instructions.
I am being billed for an unused IP address. I can't find the item that's
charging me.
I've gone through the project using console.cloud.google.com looking in Compute Engine and Networking settings, but I can't find any IP addresses.
I'm only using the project for Cloud Storage of 1 text file, and a git
repository. I run these commands on the terminal, and I am getting 0 items.
$ gcloud --project=PROJECTNAME compute addresses list
The above command listed 0 items.
$ gcloud --project=PROJECTNAME compute forwarding-rules list
The above command listed 0 items.
Is there a way of telling where this static IP address is, or how I
can disable it? I can't find it anywhere. I'd rather not delete the entire
project because some of the services are being used by my production app.
I know that it's a global IP address because I can see it listed in my
Compute Engine quota. For me to be able to use a command line option to delete the address, I think that I need the name of the address, but I can't find that listed anywhere.
I'm thinking this could be related to me having one of these two
things enabled for the project in the past:
I was running an AppEngine project, but have since terminated it.
For the AppEngine project, I registered a custom domain to point
to it.
I had used AppEngine Flexible (aef). The unused IP was from my stopped version. This blocks the releasing of the static IP and so it was advised to first delete this version before trying to release the IP address again.
You cannot delete your previous version if that's the only one you have as you need to have at least one version for the default module.
To fix you could deploy a new version, say a Flexible VM (deployed to another region), or a Standard VM. Then as a workaround, if you do not have any app to replace it right now, you can deploy an empty app instead. You would need to create an app.yaml that uses only static files that does not have any script to execute so you would not be charged for any instance.
For a more detailed guide in doing this workaround, you may check this documentation [1].
[1] http://stackoverflow.com/questions/37679552/cannot-delete-version
I'm trying to access my Google Compute Engine VM at 104.197.83.224. I tried to allow HTTP and HTTPS traffic but it errors out both times. It gives the error Invalid Fingerprint.
Could use some help. Thanks!
Also, although I haven't used my VM at all, I've gotten a bunch of requests on it. And its starting to charge me even though I'm not using it. How can I prevent that?
It sounds like you've stored a previous SSH key for that IP address in your ~/.ssh/known_hosts file. Check that file for entries that have the same IP address as your current instance and remove them.
Unfortunately, SSH assumes that IP addresses and SSH keys are assigned fairly statically (rather than using signatures from some central trust authority like SSL), which is a problem when you start to have cloud services which may assign the same IP address to different VMs several times during one day (if the VMs are started and shut down quickly, for example). I think that the gcloud ssh comm
I'm new to GCE and want to migrate my web site there. I created a VM instance group hoping. I installed all the packages and set it up a couple days ago. But today I noticed my VM instance group has a different name (postfix, to be exact), and the disk is flushed empty. Is it possible to restore its status, or at least make sure it won't get wiped out again? I'm so surprised that GCE wiped out everything and I wonder if I'm missing something during setup.
A few details in case they are related:
I'm using a trusty image for the VM.
The cloud storage is chosen to be a regular persistent disk.
It was working with emphemeral IP, and yesterday I started to use Cloud DNS to host my domain. I should have used a static IP, but that mistake shouldn't cause the VM instance group to be flushed...
I'm using cloud sql as the database service.
Maybe I should just use VM instance, given I don't have much traffic now?
Any help will be greatly appreciated~
I've setup our heroku app with an amazon RDS instance.
I followed the guide here:
https://devcenter.heroku.com/articles/amazon_rds
This guide basically says to require SSL with the connection and then to input your RDS credentials.
This doesn't seem very secure to me. If someone has my db url, user and password then they can login from anywhere, correct? The SSL is nice to prevent sniffing of this info, but I'd like to lock it down further, to a machine, IP address or SSH.
I previously setup RDS DB instances where access was locked down to only specific IPs, but heroku no longer recommends this for whatever reason.
So the questions are:
Are my assumptions correct here?
How can I lock this down further?
Why doesn't heroku recommend locking it down to IP (or at least IP range)
I'll run this by heroku support as well and post an update, but wanted to get thoughts from the community.
Previously, Heroku recommended locking down access by referencing the Heroku AWS account ID. That approach is no longer recommended. The Heroku changelog entry lists the reasons, reproducing here for completeness:
Cross-security grants don't work with AWS VPC (which is now the default on AWS)
It's not safe because it grants access to all apps running on Heroku, not just yours
Doesn't work across AWS regions
Heroku may in the future run apps in a VPC or in a different region or use a different AWS account
We know that not all customers are happy with this level of access granularity, and we're continuously evaluating whether this is the optimal setup.