Tim Collins's picture

OK so I've got a configured Turnkey machine image I used to demo to a customer. Now the customer wants to go live with it but move it or copy it rather under their own AWS account login.

How should I do this or what's the best way?


Liraz Siri's picture

You can use TKLBAM to do this.

  1. Backup the customized appliance on your account.
  2. Launch a new appliance on your customer's account.
  3. Reinitialize tklbam with your Hub account's API KEY, restore the backup and then reinitialize tklbam again with your customer's Hub API KEY. Like this:
    tklbam-init --force YOUR_APIKEY
    tklbam-init --force YOUR_CUSTOMERS_APIKEY
Tim Collins's picture

Sounds like a breeze but I'm just not clear on what you're referring to as the customised appliance id?

Jeremy Davis's picture

As displayed in your backups section on the Hub - here.

Tim Collins's picture

Excuse me for asking more questions so I've got this clear. Do I register a new Turnkey account on behalf of the customer and then launch the new appliance? I actually want to end up keeping the existing appliance on my account and having a copy running under the customer account. Ultimately after further config further regional instances will be deployed.


Jeremy Davis's picture

Yes, to run the appliance under the customers own account, you will need to sign them up to the Hub (if they have an existing account, it can just be linked to a new Hub account for them, no need to make a new AWS account).

This process won't affect the instance running under your account. But be aware that if you do further work on your instance and repeat this process, you will need to tweak TKLBAM so as not to overwrite their data.

I would run (and test) a TKLBAM backup of your customer's instance first. That way you can revert to their instance as it was if something goes wrong when overwriting their instance with your new development TKLBAM backup.

By default the TKLBAM migration will overwrite (at least some of) their data. You should be able to tweak TKLBAM to not overwrite specific data though (but I'd do a backup of their data anyway, just in case). Have a look at the TKLBAM docs for how to tweak it for your usage scenario.

Tim Collins's picture

OK did all that and er something did go wrong because the new customer instance won't mount now. In hindsight I should have done a S3 backup in AWS too. How do I now reinitialise the original LAMP image so I can try again. Console log pasted below... any idea what went wrong? Does it make a difference coming  from a micro to a medium instance?

Begin: Running /scripts/init-bottom ...


mount: special device /mnt/tmp does not exist

mountall: mount /tmp [272] terminated with status 32

mountall: Filesystem could not be mounted: /tmp

Thanks again for the help.

Jeremy Davis's picture

If there's no data in the customer instance then easiest way would be just destroy the customer instance and repeat steps 2 & 3 in Liraz's post above.

I'm not sure but the issue may be a regression introduced by a recent update to TKLBAM. Try making the directory that it complains about ie mkdir /mnt/tmp prior to restoring your backup.

Micro instances are EBS backed only, Small & Med ones are S3 backed by default. It shouldn't make any difference AFAIK.

Alon Swartz's picture

As Jeremy mentioned, it seems there is an issue with a tweak made a couple of days ago which automatically mounts /tmp to /mnt/tmp to take advantage of the ephemeral storage.

Do you get this issue when launching the medium instance directly (not via the "restore this backup in the cloud")? What appliance are you using? I'd like to try and replicate the issue so we can either provide you with a workaround or fix it if it is a regression.

Tim Collins's picture

Ahh I see a 'tweak' so maybe it's not me doing something wrong then. I'm worried now that the work I've done this morning will be lost again if I stop the machine. So hope you can resolve the problem soon.

I launched a new Medium LAMP instance last night only had it running for about half hour last night and it wouldn't mount this morning. Please try it yourself just launch it stop it and see if it will reboot or stop/start.


Tim Collins's picture

Everything went so smoothly and I've had zero problems with my previous micro instance. I did as you suggested and destroyed and recreated the new instance through the hub. All was fine I did a couple of installs, all fine, stopped it went home for the evening came in this morning started it - same problem won't mount fs can't get into it. I'm going to try one last time from scratch and this time snapshot it and make an AMI before I stop it (belt and braces).

I'll get back to you with progress...

Jeremy Davis's picture

The blue button on the left hand side when you are logged in. It's like a hotline to the core TKL devs and also supplies them with your account info so they can have a look from their end.

Alon Swartz's picture

Quick update: we released an update that fixes this issue, so other users won't hit the same bug. If anyone does have an issue, please let us know (via Hub feedback).

Tim, your instance has also been fixed (see your email for more info).

Tim Collins's picture

Many thanks to all for help and advice and thanks Alon for sorting problem, my machine is all fine now reboots and come back up no problem.

One other thing I would like to ask though, would you expect to be able to restore the contents of a medium instance to a micro and have it boot sucessfully? Because I tried the original post from Liraz yesterday with this backup into a micro instance, I could see no errors in the log but it would not connect the Shell to it.

Very many thanks.

Alon Swartz's picture

Micro instances are, well, micro (ie. not nearly as powerful as a medium instance). They also don't have ephemeral storage, so large backups might not be able to restore - if this is the case you will get the appropriate error message.

That being said, if the micro instance can handle the backup and processing overhead the restore should work. I'd recommend performing the restore manually (tklbam-restore BACKUP_ID), and follow the output to see if any errors are displayed. Also make sure that all services are running while your connected via SSH, and if not, restart them.

I hope the above helps.

Add new comment