Thank you for writing EC2Box, it seems to be exactly the tool I can use to ssh into our EC2 instances. I created a new EC2 ubuntu instance to host EC2box. However I cannot get any of the Composite SSH Terminals to connect. I believe I have entered the account settings and keys correctly, and I can see the list of instances in the instances table. However, when I select any instance and click on the Create SSH Terminals button, I get an "Auth fail" error, and I see the following error on the EC2Box term:
org.h2.jdbc.JdbcSQLException: NULL not allowed for column "HOST"; SQL statement:
insert into system (display_nm, user, host, port, instance_id, key_id, region, state, instance_status, system_status) values (?,?,?,?,?,?,?,?,?,?) [23502-175]
Do you know what could cause that?
thank you,
-John
Thanks John! When you have an instance that is shutdown the AWS services won't return a DNS for it and that was causing it to fail when inserting. I never noticed that before. I actually just committed a fix and some other features. I haven't done a release yet, but will get to it sometime today.
Related
I am new to AWS EC2 instance. I use ssh to connect to the instance and just want to know how to leave the instance properly. Sometimes I just close the terminal but I couldn't connect to it next time. Then I use
shutdown -h now
It works, but this way I need to restart the instance next time. Is any proper way to leave the instance?
Type
exit
if you just want to leave it and keep it running
The EC2 instance runs independently of you connecting to it. Each time you SSH in to the instance you start a new interactive shell. exit or Control-D will close the shell that you have logged in to, and leave the instance running.
If your instance is on-demand, you can shut it down to save costs, but that is an entirely separate operation from logging in and out.
I have an ec2 micro instance. I can start it from the console, ssh into it (using a .pem file) and visit the website it hosts.
Using the old ec2 CLI, I can start the instance and perform other actions including ssh and website access.
I am having trouble with the new ec2 CLI. When I do "aws ec2 start-instances --instance-ids i-xxx" I get the message "A client error (InvalidInstanceID.NotFound) occurred when calling the StartInstances operation: The instance ID 'i-xxx' does not exist".
Clearly the instance exists, so I don't what the message is really indicating.
Here is some of my thinking:
One difference between the old and new CLI is that the the later used .pem files whereas the new interface uses access key pairs. The instance has an access key pair associated with is, but have tried all the credentials I can find, and none of them change anything).
I tried created an IAM user and a new access key pair for it. The behavior in all cases is unchanged (start from console or old CLI, web access, ssh) but not using the new CLI.
I realize that there is a means for updating the access key pairs by detaching the volume (as described here), but the process looks a little scary to me.
I realize that I can clone another instance from the image, but the image is a little out of date, and I don't want to lose my changes.
Can anyone suggest what the message really means and what I can do to get around the problem?
The problem had to do with credentials. I had the correct environment
variables (AWS_ACCESS_KEY and AWS_SECRET_KEY) set. But they didn't match what was in my .aws/credentials file. That is, despite what it says here, the new CLI worked only when I had the environment variables and
the credentials file correct and in sync.
Configure your aws cli with "aws configure" in new cli instance with region in which your ec2 instance reside. and then try to give the same command. The instance should start.
I am windows user and wanted to use a spot instance using my own EBS windows AMI. For this I have followed these steps:
I had my own on-demand instance with specific settings
Using AWS console I used option "Create Image EBS" to create EBS based windows AMI. IT worked and AMI created successfully
Then using this new AMI I launched a spot medium instance that was created well and now running with status checks passed.
After waiting an hour or more I am trying to connect it using windows 7 RDC client but is not reachable with client tool's standard error that either computer is not reachable or not powered on.
I have tried to achieve this goal and created/ deleted many volums, instances, snapshots everything but still unsuccessful. Doesn't anybody else have any solution to this problem?
Thanks
Basically what's happening is that the existing administrator password (and other user authentication information) for Windows is only valid in the original instance, and can't be used on the new "hardware" that you're launching the AMI on (even though it's all virtualized).
This is why RDP connections will fail to newly launched instances, as will any attempts to retrieve the administrator password. Unfortunately you have no choice but to shut down the new instances you've been trying to connect to because you won't be able to do anything with them.
For various reasons the Windows administrator password cannot be preserved when running a snapshot of the operating system on different hardware (even virtualized hardware) - this is a big part of the reason why technologies like Active Directory exist, so that user authentication information is portable between machines and networks.
It sounds like you did all the steps necessary to get this working except for one - you never took any steps to cause a new password to be assigned to your newly-launched instances based on the original AMI you created.
To fix this, BEFORE turning your instance into a custom AMI that can be used to launch new instances, you need to (in the original instance) run the Ec2ConfigService Settings tool (found in the start menu when remoted into the original instance using RDP), and enable the option to generate a new password on next reboot. Save this setting change.
Then when you do create an AMI from the original instance, and use that AMI to launch new instances, they will each boot up to your custom Windows image but will choose their own random administrator password.
At this point you can go to your ec2 dashboard and retrieve the newly-generated password for the new instance based on the old AMI, and you'll also be able to download the RDP file used to connect to it.
One additional note is that Amazon warns that it can take upwards of 30 minutes for the retrieval of an administrator password after launching a new instance, however in my previous experience I've never had to wait more than a few minutes to be able to get it.
Your problem is most likely that the security group you used to launch the AMI does not have RDP (TCP port #3389) enabled.
When you launch the windows AMI for the first time, AWS will populate the quicklaunch with this port enabled. However, when you launch the subsequent AMI, you will have to ensure that this port is open for your security group.
I do the following using AWS web console:
Attach EBS volume-A to instance-A. Make some changes to data on volume-A and detach it
Launch new instance-B (in the same zone as instance-A)
Try attach volume-A to the new instance-B. But the new instance does not appear in the instances list during attach volume process (dialog box).
If I try the same attach using command line EC2 API (volume-A and instance-B), it works fine!
Do you know if this is a bug in AWS web console or am I doing something wrong in the console? Tried page refresh in Step #3 but it still would not list the new instance.
In order to attach, both volumes has to be in the same zone. So if you are going to attach a volume into a instance check the zone of the instance's attached volume. If those are not matching create a new instance with the same zone as the zone of the volume that you need to attached.
The volume and the instance have to be in the same region AND the same zone.
If you have a volume in us-east-1a and the instance in us-east-1b, you would need to move the volume to us-east-1b to make it work.
Even I had faced this problem yesterday and a day before. It looks like Amazon problem with their cache. Not sure WHY.
To bring back the stuff as is, I had to sign-out and make sure things are good. But it's always good to work with CLI, works better.
Although the user interface may not list the instance ID, you can attempt to add the volume anyway. If it's genuinely impossible (rather than a cache issue) you will get an error message.
Paste in the instance ID (i-xxxxxxx) manually then type your mount point (e.g. /dev/sdf) and click Attach.
For the benefit of others: some instance types do not support encrypted volumes, which may be why the instance doesn't appear in the list. I get the following error:
Error attaching volume: 'vol-12341234' is encrypted and 't2.medium' does not support encrypted volumes.
I realise there are some similar questions on here already but I couldn't see one that matched my problem so I'm afraid I had to ask a new question.
I have a webservice running on a server, which is throwing a ORA-12154: TNS:could not resolve the connect identifier specified" error. However when I log onto the said server i am able to tnsping the entry successfully, and connect to it via sqlplus, but not through the webservice.
If anyone has any suggestions as to things to look for then I would greatly appreciate it.
Cheers
Some other things to look at include:
If you're using a service name instead of SID, are you specifying the entire service name?
If you're using the ORACLE_SID environmental variable, check the case (mydb vs MYDB)
Check for a sqlnet.log file
If you're using a username/password#SID connect string, you may need to quote your password if it contains special characters (like an # symbol).
The webservice can't find tnsnames.ora which usually means that you didn't set up Oracle's environment properly when starting the process. This usually means you didn't source oraenv.sh in the shell script which starts it.
So your interactive login works - what is different between your interactive login and the user that runs your web service?
Are they the same user? If not then you will need to update some of your configs in order to make the Oracle client files available to the webservice.
Details like Operating System, Oracle Version, etc are always a help.