bhruska's picture

I am planning on migrating a wordpress-13.0-wheezy-amd64 off of Amazon to my own server.

Is there a way to "upgrade" this to the latest (version 14) appliance at the same time?  If so, how would I do that?

I'm planning to run a restore with TKLBM.

Also, when I restore it suggestst he same appliance.  But since its a restore, won't it overwrite whatever is there?  So would this matter?  Just trying to figure out exactly how to do this migration.



bhruska's picture

Okay, so I've done a restore to a local machine.  Having done this, and noticing that it doesn't start up normally, and reading further about TKLBM, it seems that any modifications I've made to the server don't seem to get included in the backup automagically.  

So do I have to add any new packages I've installed to the configuration for the backup?  How do I know what to add?

Here's the message that I get rebooting my local machine.  At first, it did reboot, now its trashed.  Ugh!



bhruska's picture

I have tried using TKLBM to restore a zurmo machine locally with similar results.  After restoring, I cannot access the machine via SSH, or the web server interface.  I suspect the network settings get restored, and thus are invalid in some way.  What do I need to adjust after restore?  Any help appreciated.



bhruska's picture

Obviously I'm missing something.  I've created a new server appliance on my local EXSi server.  It runs fine.  Then I put the API key in.  That works.  I execute the restore from the cloud backup.  That says it finishes fine.

Now I try rebooting the machine and accessing it.  I can't get to it.  The IP address obviously is different than what it would be out on Amazon's cloud.  So are the domains assigned to it.  I get that.  But after reboot I can't even get to it with SSH.

Are there steps I'm not taking properly after the restore?  Is this spelled out anywhere?

Any help would be appreciated.  Backups aren't any good if you can't access them!




Jeremy Davis's picture

It should just work. You may need to tweak some settings but ssh should definitely still work.

TBH I don't understand the errors that appear to be occurring. It seems like something is seriously wrong somewhere! But it sounds like you've already figured that much out!

Bottom line is that TKLBAM should track most changes that you make, although not necessarily all. It should track packages that you install with apt (so long as they come from the Debian or TurnKey repos). It will also track all of your WordPress changes (including if you've updated the version etc). It won't track software that you've installed in another way (e.g. using pip for python or installing from source).

One thing you could do, is on your original server run a backup, but with the `--simulate`. It will leave a directory called /TKLBAM (which includes everything that is backed up). Install tree and then post an output of the tree structure of that directory:

apt-get update && apt-get install tree
tree /TKLBAM > tklbam-files.txt
Then edit your top post and attach the file (only the first post in a thread can have attachments).
bhruska's picture

I did the simulation, and uploaded the tklbam-files.txt file.

It looks like apache has been updated for the new appliance, and there are errors starting it.

/var/www$ service apache2 restart
Job for apache2.service failed. See 'systemctl status apache2.service' and 'journalctl -xn' for details.
/var/www$ systemctl status apache2.service
* apache2.service - LSB: Apache2 web server
   Loaded: loaded (/etc/init.d/apache2)
   Active: failed (Result: exit-code) since Tue 2016-05-31 17:02:15 UTC; 9s ago
  Process: 2039 ExecStart=/etc/init.d/apache2 start (code=exited, status=1/FAILURE)

May 31 17:02:15 zurmo apache2[2039]: Starting web server: apache2 failed!
May 31 17:02:15 zurmo apache2[2039]: The apache2 configtest failed. ... (warning).
May 31 17:02:15 zurmo apache2[2039]: Output of config test was:
May 31 17:02:15 zurmo apache2[2039]: AH00526: Syntax error on line 49 of /etc/apache2/mods-enabled/ssl.conf:
May 31 17:02:15 zurmo apache2[2039]: Invalid command 'SSLMutex', perhaps misspelled or defined by a module not included in the server configuration
May 31 17:02:15 zurmo apache2[2039]: Action 'configtest' failed.
May 31 17:02:15 zurmo apache2[2039]: The Apache error log may have more information.
May 31 17:02:15 zurmo systemd[1]: apache2.service: control process exited, code=exited status=1
May 31 17:02:15 zurmo systemd[1]: Failed to start LSB: Apache2 web server.
May 31 17:02:15 zurmo systemd[1]: Unit apache2.service entered failed state.



Jeremy Davis's picture

Apache in v13.x was 2.2 and in v14.x it's 2.4 and there were a lot of changes between the versions.

The update should be fairly straight forward. First thing to do is update the ssl.conf to our (new) standard one.

mv /$CONF /${CONF}.backup
wget $URL/$CONF -O /$CONF
sed -i "s|^\(\s*SSLCipherSuite\s\+\).*$|\1${CIPHERS}|g" $CONF

You may also need to update the location of your keys. Edit the line that says:

SSLCertificateFile /etc/ssl/private/cert.pem
And make sure that it points to your cert.

You'll also need to rename the Zurmo Apache conf file.

mv /etc/apache2/sites-avaialble/zurmo /etc/apache2/sites-avaialble/zurmo.conf
a2ensite zurmo
You may also need to tweak that config file a little, although if you haven't updated it yourself, you just need to make it look like this:

Note that you can remove the SSLCertificateFile directive that your default file contains (as it's now in the ssl.conf).

Rob B's picture

The link for the ssl.conf is no longer valid, I am upgrading using tklbam from 13 to 14.1



Jeremy Davis's picture

Regardless, it's probably best to start your own thread, rather than hijacking someone else's.

So in a new thread, please detail the appliance you are working with and the steps you have taken already. If there is info from other forum threads or posts that's relevant, please feel free to link to it etc.

FWIW there is a doc page that gives a suggested workflow and note a couple of specific details that will need tweaking.

Rob B's picture



Thanks for the link and the warm welcome!

Regardless I have manage to work through this issue.


Jeremy Davis's picture

I didn't mean to come across as rude or unhelpful, that wasn't my conscious intention at all.

Having said that it does get a little tiring to answer posts where there is so little info to work with. When people don't share the context of their issue it makes people trying to help have to work that much harder.

If you are new to Linux and/or "tech" type forum posting then you may well not realise that on face value. So apologies that you copped my frustration, that wasn't fair.

For future reference, if you have an issue and want help with it, best practice is to start your own new thread (unless of course the thread is very recent and EXACTLY matches your issue). If in doubt (i.e. you aren't sure whether it's the same issue or not - or it's similar but not exactly the same) start a new thread. Provide links to other threads that you think may be similar and/or you used info from. Also feel free to cross post links to your thread in similar threads.

So for example in this case, ideally you would have opened a new thread and written something like this:

I am trying to use TKLBAM to migrate a v13.0 XYZ TurnKey appliance to the current version (v14.1). However on my v14.1 server ABC isn't working as I think it should.

I used the information from link to some other thread but the instructions didn't work for me and I am now getting this error message:

some error message

Yes it does require a little more effort on your part to do that, but it also means that the person trying to help you doesn't have to work so hard. If you can lower the bar for those who want to help, then the chances of getting a useful, helpful reply in a timely manner are improved! It also provides a much more useful reference for future users.

If you have resolved the issue, perhaps you could share your info and save someone else in the future?! At this point, please feel free to just post here. Starting a new thread at this late stage probably doesn't make so much sense.

Rob B's picture

I decided to upgrade using a backup of the wordpresss enviroment and manually making configuration changes to apache that I required. (from my documents)


I felt due to the changes in apache version it was better to not introduce some unknown issues.


The site is now upgraded to the new TKL 14.1 platform and gets the A rating from Qualys SSL labs site checker which was my reason for the upgrade.


Happy New Year.

Jeremy Davis's picture

Great to hear that you successfully managed to migrate your data to the current version! Great work. :)

Add new comment