AndrewH's picture

I'm using the LXC appliance on AWS and I'm trying to create a Wordpress container. I follow the instructions but when I issue the command

lxc-create -n wp1 -t turnkey -- wordpress -i /root/inithooks.conf

I get an error.

root@lxc ~#  lxc-create -n wp1 -t turnkey -- wordpress -i /root/inithooks.conf
debootstrap is /usr/sbin/debootstrap
FATAL [lxc-turnkey]: turnkey version 14.2-jessie-amd64 is not recognized:
lxc_container: container creation template for wp1 failed
lxc_container: Error creating container wp1

Any help will be appreciated.

Jeremy Davis's picture

Thanks tons for reporting.

That should definitely work, but clearly it doesn't. I just fired up an instance and can definitely reproduce this, so have added it as a bug to our tracker.

As noted there on the issue, it turns out that it was actually my fault (oops), via this commit. I obviously didn't test that properly and it's not quite right. To add insult to injury, it turns out that the reason why I updated that code wasn't even completely legitimate either... :(

Anyway, as noted on the issue, the "proper" workaround is to return that script to it's previous condition via the sed line in the bug report (the line of code starting with "sed", right at the bottom, in the "Workaround" section).

An alternate workaround would be to explicitly state the version as "14.2-jessie" at launch (and forever after), i.e. add "-v 14.2-jessie" to the end of the launch line. Something like this:

lxc-create -n wp1 -t turnkey -- wordpress -i /root/inithooks.conf 
FWIW, I just used this and it worked fine (I created wp1.conf first):
lxc-create -n wp1 -f /etc/lxc/natbridge.conf -t turnkey -- wordpress -i /root/wp1.conf -v 14.2-jessie
AndrewH's picture

Thanks for looking at this.

I tried

lxc-create -n wp1 -f /etc/lxc/natbridge.conf -t turnkey -- wordpress -i /root/inithooks.conf -v 14.2-jessie

and I get the following

root@lxc ~# lxc-create -n wp1 -f /etc/lxc/natbridge.conf -t turnkey -- wordpress -i /root/inithooks.conf -v 14.2-jessie
debootstrap is /usr/sbin/debootstrap
INFO [lxc-turnkey]: checking cache download in /var/cache/lxc/turnkey/debian-8-turnkey-wordpress_14.2-1_amd64.tar.gz ...
INFO [lxc-turnkey]: verifying gpg signature...
gpg: verify signatures failed: eof
FATAL [lxc-turnkey]: debian-8-turnkey-wordpress_14.2-1_amd64.tar.gz.sig gpg verification failed
FATAL [lxc-turnkey]: failed to install turnkey wordpress
lxc_container: container creation template for wp1 failed
lxc_container: Error creating container wp1

I suspect it's because this is a version 14.1 LXC VM.

In any case the following worked for me.

lxc-create -n wp1 -f /etc/lxc/natbridge.conf -t turnkey -- wordpress -i /root/inithooks.conf -v 14.1-jessie

Thanks again.


Jeremy Davis's picture

For v14.2 we changed the authentication mechanism a little. We moved from a .sig file to a .hash file. We did that to better reflect what the file actually is. A .sig file should be a plain text signature, whereas our file contains hashes. The file itself is signed, but the contents are hashes, so renaming that brings us into line with convention.

Looking at the error message that you have posted, it seems clear that it is expecting a .sig file, but can't find one for v14.2 (because there isn't one! v14.2 only has a .hash file). If you're happy to continue with v14.1, that's fine, although I would argue that generally v14.2 is going to be a better starting point for any appliance.

If you wanted to fix this on your server (without downloading and installing the v14.2 LXC appliance from scratch - and you'd still have the bug I noted earlier), you could do that by replacing the TurnKey LXC template file (/usr/share/lxc/templates/lxc-turnkey) with an updated copy. FWIW, I've just reverted that earlier commit (that I added which introduced this regression in v14.2), so the easiest way to get the current (and hopefully fully working) template would be like this:

cd /usr/share/lxc/templates/
mv lxc-turnkey lxc-turnkey.bak
chmod +x lxc-turnkey
That should eliminate your immediate issue, and should also resolve the issue that I noted earlier. Worst case scenario and it doesn't work as expected, you can roll back by deleting the new file and renaming the backup file (.bak) to it's original name. Hopefully that shouldn't be required.

Obviously, if v14.1 works well enough for you, you can continue on as you are.

Add new comment