I have an old v11 appliance as an archive for old websites no longer in use. Can this be backed up to the hub so I can migrate to V14. Can see where to enter the hub api key ?




If use command line tklbam-init api key I get error already initalized. then back up gives error

I had backups for this server but they have been deleted from hub. I think that is issue ?



If I run the list command on the V 11 LAMP APPLIANCE I can see that the backup profile is present. But if I log into the hub the backups are not present in the list.

Jeremy Davis's picture

TKLBAM backups from v11.x (or earlier) haven't been supported by the Hub since circa late 2017 and even then, you would have needed a legacy DevPay backed account to run the backup.

When the Hub moved from DevPay billing to Stripe billing, we have to re-engineer how TKLBAM authenticated against AWS. AWS DevPay provided special S3 buckets which we leveraged and the authentication mechanism was quite different. Post DevPay (i.e. with Stripe billing) TKLBAM now uses "normal" AWS S3 buckets and IAMs role token authentication. So this old version of TKLBAM doesn't know what to do with the usertoken, hence the KeyError.

IIRC we started the migration to Stripe billing during the lifetime of v14.x. We did backport the TKLBAM changes back to v12.x, but not v11.x or earlier (I wasn't intimately involved in the technicalities of TurnKey back then and I don't recall the rationale, but I'm pretty sure that there were technical reasons).

There is a hacked together work around. But it only allows backup upload (not download), plus it also has the limitation of only allowing up to one hour of uploads; so you'd either need a fast internet connection and/or it will only support a small backup. I've taken the liberty of pulling your email from your TurnKey website user account and I'll send you a copy of that via email with instructions. I don't really want to share it publicly as it was never intended for anything other than "one off" usage.

Regarding the old backup showing via HubCLI, but not within the Hub UI, I'm assuming that's because they actually show slightly different things. The Hub CLI client shows the raw backend info that the Hub has (including broken and inaccessible backups). Whereas the Hub UI only shows backups that it believes to be valid (on a few criteria). I suspect that the backup you're referring to is #3 right?

So unless you migrated that particular backup to "normal" AWS S3, any associated data would be gone. Because v11.x (and earlier) backups weren't supported, we encouraged users to ensure that they migrated to newer TurnKey versions prior to doing the billing migration (from DevPay to Stripe).

I also took the liberty of using your email to dig through the logs to try to get a clearer understanding of how it explicitly played out at the time, but I wasn't able to find anything?! Have you perhaps updated the email address for your account since the move from DevPay?

ny tips on best way to migrate the LAMP files ie apache and mysql configs files database etc. I managed to update  webmin to 1.9.41 on the old v11 appliance and this has options to backup the webmin configuration, however I don't seem to have the same option on the 14.2 appliance. I'm not relishing having to recreate all of the users and passwords.

Is it possible to update webmin tried apt-get install webmin but stays on version.



Thanks for script. It was backing up but the etc/.git files took a long time and ran up against the 1 hour time limit. Then I found this post


so ran git gc tried again. Looks like it will work if I can get under the 1 hour.



Is there any way to extend the 1 hour limit ?



I made a backup of var/www then deleted the contents. I could then create the backup of the version 11 appliance successfully in under an hour.

Tried to restore unto a version 14 appliance. Restore was completed okay erro = 0

then copied the contents of www back

however webmin not loading and apace not starting

root@lamp ~# /etc/init.d/webmin restart
[....] Restarting webmin (via systemctl): webmin.serviceJob for webmin.service failed. See 'systemctl status webmin.service' and 'journalctl -xn' for
in var/webmin/miniserv.error
Error: Access denied : User root is not allowed to use the MySQL Database Server module
Error: The Apache Webserver module is not available on your system
[14/Feb/2020:17:55:27 +0000] [] /stripped : File not found
Use of uninitialized value in pattern match (m//) at /usr/share/webmin/acl/acl-lib.pl line 1296.
Use of uninitialized value $system_status::config{"collect_interval"} in string eq at /usr/share/webmin/system-status/system-status-lib.pl line 98.
Use of uninitialized value $system_status::gconfig{"os_version"} in string eq at /usr/share/webmin/system-status/system_info.pl line 41.
Use of uninitialized value $system_status::gconfig{"real_os_type"} in concatenation (.) or string at /usr/share/webmin/system-status/system_info.pl line 41.
Use of uninitialized value in concatenation (.) or string at /usr/share/webmin/system-status/system_info.pl line 41.
Error: Module system-status does not exist





If this is ourside of scope of turnkey I shoul dbe able to sor tit out.

Is it correct that when you do a restore the root password changes to the one from the restored backup ?




Is there a URL to download legacy versions of the appliances v12 or v13 to see if the restore works on those versions ?

Jeremy Davis's picture

Unfortunately, we don't have any old images prior to v14.x ones. Plus I'm not sure how much that will really help. E.g. Apache config from prior to v14 will still need to be manually updated to be compliant with Apache 2.4 config requirements to run on v13. So if you want it up and running, on a supported OS, then you'll still need to do that.

IMO, the way to go is to try to diagnose the problems and work through them one-by-one. I'm happy to assist if you want to share the log outputs.

Regarding the Apache config, that's pretty easy. If you check out the relevant Apache doc page that should get the Apache side of things up and running.

You also mention MySQL. What are the logs reporting as an issue there? IIRC MySQL logs should be /var/logs/mysql and/or just check the syslog. Grep is often a useful tool for filtering log output. E.g. to search the syslog (/var/log/syslog) for all lines that contain "mysql":

grep mysql /var/log/syslog

It might also be worth just trying to start it manually from the commandline?

Please feel free to post logs if you need a hand interpreting things. Although if they're big, it may be better to attach them (you'll need to attach to your first post).

Add new comment