Forum archive
Can't Launch Appliance - Trying to upgrade Debian 6
My brain is down to 1 working cell. Please help.
I've been running Debian 6 for a couple of years, and want to upgrade to 7 so the baddies don't get me. I've seen posts that I can "backup with tklbam and restore on the new lamp" (well, slightly paraphrased).
So, I did a full backup with tklbam-backup, which worked fine. And I launced a new server from that backup from the hub, but of course, it launches the Turnkey Linux 12 (which is Debian 6, right?)
So I figured I would need to launch a brand new server from TKL that would be Debian 7 (I assume?) and then restore from the command line which would then restore the backup and be deemed a "migrated" server. Correct?
But of course, when I tried to launch a fresh LAMP appliance on a server, I get the message that my "amazon ec2 account is not enabled for turnkey linux" (or something close to that)... And I have no idea how to tell aws to accept the hub launch. (Which is strange, because I can 'launch from backup' just fine)... I have been paying for TKL for about 3 years now but have not actually used the hub for about 2 years, I have only been using the aws console and relying heavily on snapshots. I had no idea my TKL was somehow banished from AWS.
Can anyone help with this and/or point out errors in my thinking about how to migrate from Debian 6 to Debian 7? And if needed, how to get AWS to somehow respond to a new LAMP launch via some sort of API setup?
My poor, tattered, shredded brain thanks you.
Replies (5)
Are you using IAM?
Reply 1Follow up...
Reply 2In theory that should work, but obviously in practice something is not right.
I'd like to try and reproduce the issue, could you tell me:
- What region you are trying to deploy to?
- What architecture did you select?
- Just to confirm, this is for LAMP 13.0 micro, correct?
- Have you tried any other images?
If I cannot reproduce the issue on one of our test accounts, I'll need your explicit permission to manually debug your account (security group creation, instance launch, assets querying), preferably via the feedback tab in the Hub when you're logged in.
Solved
Reply 3I am 99.9% sure I've found the issue, which seems to be a permissions issue in all non-Virginia images.
I'm running a script to update the permissions on all non-Virginia images (about 1,400). Once the script completes and Amazon pick up on the changes, you should be able to launch no problem.
In case you're interested as to what happened:
- We recently ran a routine batch job to update all the images to include security updates.
- The build process builds the image for Virginia, then copies them to all the other regions.
- The permissions on the copied images appear to be correct, but for some reason (bug) Amazon are ignoring them.
- I tested this by removing the permissions and re-adding them, a few minutes later Amazon picked up on the changes and all is well...
What we'll be doing so this doesn't happen again:
- Contact Amazon and report the bug
- Work around the bug (until fixed) in our build process.
Yup - IAM
Reply 4I just created a new IAM key pair and used them for the tkl hub. I set the permissions (policy) to full administrator access (The very first option under the PERMISSIONS tab) to test. The key pair added okay to the hub account, but I still get that error when creating a new LAMP stack on a micro server. Any ideas? Do permissions propogate to the very next use of the key pair by the hub? (I'm assuming that new policies are immediately in place for the next use of the key pair)...
??
WORKS!
Reply 5When I saw your 99.9% sure-ness, I thought "Hey, I like those odds!".
So I tried exactly what I tried before and now it works!! Thanks so much for this! (Yes, it was a non-Virginia region.)
Hi Rick,
I just checked the Hub logs and I see that there was an "Auth Failure" when you attempted to launch the server. I also see that your keys were marked as invalid, and that you updated your keys, which should have worked in theory, but...
Amazon have recently changed how keys are managed so that may be part of the issue. Did you create a new root keypair, or did you go with IAM based? Guessing here, but maybe you went with IAM based, and didn't give permissions to the keys to launch new instances / create security groups?