quick q's on TKLBAM migrating 11.2 to 12.0, and suggestions on security practices

neildaemond's picture

I've fiddel with TKL 12 a tiny bit using a VM, and now I jsut provisioned a VPS over at Host VIrtual(vr.org) running the Turnkey linux LAMP stack v11.2

They said they will have v12 in a few weeks, but I can't really wait that long. Will I be able to easily migrate from 11.2 to 12.0 using TKLBAM and the backup on amazon?

Also, I noticed that the logs visible on the web gui can show the changes made through that web gui, but it won't show any changes I make via the command line. Does the TKLBAM track ALL** changes made to the system? or just those done via the web interface?

** -> Changes such as adding software in via apt in the command line or from source, and other various configuration file changes?


Also, I was wondering what people do to secure their system when they first get a fresh Turnkey linux going. Are the default settings secure enough? or are their a few things you do. For starters, I would probably:

- add another account and disable the root account
- setup ssh keys
- install fail2ban
- implement a boilerplate iptables setup
- check that unused processes are turned off

I know the creators of TKL are security minded, so perhaps you guys have a routine you go through when starting up a fresh turnkey machine? or even better some scripts?

Lamp stacks are pretty easy to setup without turnkey, but it's nice how the outgoing email is setup already and I really want to take advantage of TKLBAM system.


Sorry for the mashup of questions, but they cover all my concerns I have right now as a new TKL user. Your replies are much appreciated, Thanks.

neildaemond's picture

i signed up s3 and got an activation key, but when I ran the tklbam-init and entered the key, I got:

Traceback (most recent call last):
  File "/usr/bin/tklbam-init", line 127, in <module>
  File "/usr/bin/tklbam-init", line 99, in main
    if not is_valid_apikey(apikey):
  File "/usr/bin/tklbam-init", line 41, in is_valid_apikey
    struct.unpack("!L8s", base64.b32decode(padded + "=" * 4))
struct.error: unpack requires a string argument of length 12


EDIT: OK, nvm.. I was using using the wrong key,  some key that was being generated (it was even called the api key), but it wasn't staying set in the settings. I found another page which showed the current key.

Eric (tssgery)'s picture

in regards to how to secure the image, your list looks really good.

I follow those processes with both my linode instances as well as my turnkey appliances. I keep meaning to build a script to do this for my turnkey instances but haven't gotten around to it yet... maybe this weekend as I have a few other TKL-ish tasks to do....

Anyway, I follow a handy guide in the linode library: http://library.linode.com/securing-your-server

The next thing I do is to CLOSELY monitor any security issues related to the applications themselves. For example, if you have a TKL Joomla appliance, you must want the Joomle pages/threads/chatter for security issues that need to be patched. TKL does not monitor those for you and supply the necessary patches.


Jeremy Davis's picture

Firstly migration from v11.x to v12.x using TKLBAM should be  relatively straight forward although I haven't used it recently (for migration purposes) so can't be too sure whether my experience is still relevant. With some of the other appliances \ (particularly ones that include upstream software) there can be unaccounted differences eg DB schema changes that require extra tweaks, but you should be fairly safe with LAMP.

As for what changes TKLBAM 'tracks', actually it doesn't 'track' any changes. What it does is makes comparisons against the stock standard appliance. For example:

  • Installed packages - On restore it will install apps that were installed by apt-get BUT only if they come from the default TKL appliance repos - any from third party repos will need to be installed manually afterwards.
  • Configuration - It does copy across many config settings, but it ignores most hardware relevant config (such as network settings). This is pretty important as it allows you to migrate from VM to bare metal, bare metal to AWS, AWS to alternative VPS, etc.
  • Databases - DBs are simply 'dumped' complete and restored to the new appliance.
  • Files stored in 'user editable' places eg /var/www are automatically included.

So generally it should suit your purposes, as long as you don't put things in 'naughty places' - ie places that are meant to be handled by package management under the Debian FHS. My suggestion would be to read up in the docs about TKLBAM and give it a test run. I have had pretty good experience with it and some users swear by it. OTOH others have reported problems. So have a look and see what you think... If nothing else it should be enough to get you started on your new v12.x appliance as soon as your host supports it...

neildaemond's picture

Thanks guys!

Yes, closely monitoring the application is a good idea! I want to utilize IRC with logging so that I can scan the logs to notice security alert related talks.

Jemery, You gave me a much better idea about what is going on behind the scenes with TKLBAM. I'm new to these forums and already have to thank you for all the work you put into helping people out around here. I will be sure to confirm with the docs before I make any assumptions in the future as well.

I know the security upgrades are automatic, but should I bother to run a "apt-get upgrade" ? i did and it froze midway... i forgot the step. I ended up just reprovisioning the VM, and not doing the upgrade. Perhaps I will leave it closer to default untill the v12 is available.

Post new comment