You are here
v14.2 Core Release - Improvements to Confconsole, including easy Let's Encrypt SSL certs
It's been a while in the making, but v14.2 Core is now available for immediate launch in the cloud via the Hub. Amazon MarketPlace builds are on the way too, although no ETA at present. (Almost) all of the other builds (e.g. ISO, OVA, Xen, Proxmox etc.) can also be downloaded from the Core appliance page. Alternatively, all the currently appliance builds are available for direct download from one of our mirrors.
The highlights for this release include, a significant confconsole update, as well as new versions of TKLBAM and Webmin. It will also include a new OpenStack build courtesy of Tomas (from 'Home at Cloud').
Why just Core?
Unlike our last release, this one will be staged. We are releasing v14.2 Core independently, with others coming soon. The other appliances will be released in batches, as they are ready. I am hoping to release the first batch within weeks. I can't promise anything, but if you have a specific appliance that you'd really love to see a new version of, please comment below and I'll do my best to prioritise it's update and release. The more specific you can be about what you want/need, the better.
Confconsole - new and improved v1.0.0
Beyond, the staged nature of this release, the other most significant change in v14.2 is a major revamp of Confconsole (including some reasonable docs too). You can read all about Confconsole and the new v1.0.0 features in the docs here, but I have noted some highlights below.
The latest development has primarily been done by Anton Pyrogovsky and Stefan Davis. I had a fair bit of involvement in the Let's Encrypt component. But it wouldn't have been the same without community powerhouse; Ken Robinson. Ken kindly devoted a ton of time and effort to testing and feedback. Thanks to all of you, but especially you Ken! You rock man! :)
Confconsole v1.0.0 highlights
Let's Encrypt integration: You've been asking for it for ages, now here it is! We've finally integrated an easy way to get free Let's Encrypt SSL certificates and bundled it with TurnKey OOTB. Just fire up Confconsole from the commandline and look for it in the "Advanced" menu. Full docs are here.
Mail relay configuration: Another feature that has been asked for, is easy email SMTP relay configuration. Actually we've done one better. We have researched the available third party options and have concluded that SendinBlue are currently providing the best mix of features and value for money. So we've made SendinBlue config super simple! Just sign up for a free SendinBlue account and after a few keystrokes in Confconsole, and you're away! On the other hand, we don't like to lock anyone in, so alternate custom SMTP relay configuration is also straight forward. Again, look for it in the Confconsole "Advanced" menu. Full docs are here.
Other highlights: There's quite a bit of other added functionality, but particular highlights for me are the TKLBAM hasn't had any major new features added, but it has had some love. The new release resolves a few edge case bugs and ensures it's functionality is more robust. Existing v14.x users can update with a simple 'apt-get update && apt-get install tklbam'.
As per usual, a new TurnKey release means a new Webmin update. So v14.2 comes with Webmin v1.831 pre-installed (from the TurnKey repository). There are a ton of bugfixes included since our last version (v1.780) but no fundamental changes beyond the addition of a new IPv6 Firewall module (not installed by default, but easily added via 'apt-get update && apt-get install webmin-firewall6'. For full details,
please view the full Webmin changelog. Similar to previous TurnKey releases, v14.0/v14.1 users can also upgrade to Webmin v1.831 if they wish. The detailed instructions in this comment (on GitHub) contain some redundancy for v14.1 users, but should still work. Please note that you will need to manually start Webmin after install: 'service webmin start'. Alternatively you may just reboot your server.
Those of you paying attention, may notice that I noted that it "will" include a new improved OpenStack build. Also I didn't mention the OpenNode build at all. The story behind OpenNode is pretty straight forward. OpenNode has been a legacy product for some time now (superseded by NodeFabric). As it's now a legacy product, we have decided not to build v14.2 OpenNode images. We hope to support NodeFabric in the future, but unfortunately, we'll need to leave that for another day as it relies on our future TKLX incarnation. The story behind the currently missing OpenStack build is quite different. Obviously OpenStack is still in active development. But for our last 2 releases, our OpenStack build has been sub-optimal, to say the least! Due to the fact that none of us have OpenStack installed, the testing and maintenance has been a bit flaky. I have done some very basic testing from an OpenStack install nested within Proxmox. But OpenStack wasn't very stable for me, so it was far from ideal. I have put the call out a number of times and personally contacted past OpenStack users and developers and had little feedback, so until now, we've made do with what we had. But then along came Tomas Vondra, sponsored by his employer; Home at Cloud! His employer liked the look of TurnKey and wanted to leverage our appliances on their hosting platform. However Tomas soon discovered that our existing OpenStack build (as noted above) was sadly lacking.
But not to be deterred; in the community spirit of open source, Tomas rolled up his sleeves and did some major reworking of our OpenStack build. He has managed to bring it more-or-less inline with the vanilla Debian OpenStack release. So in the very near future (after we do some last minute minor tweaks), we will have a shiny new OpenStack build. As per the Debian OpenStack release, it is in .qcow2 format. Qcow2 is a native KVM disk image format. As such, our new OpenStack build is primarily aimed at OpenStack implementations with a KVM virtualization backend.
Even though it's been primarily designed for (and tested on) KVM backed OpenStack, it should also work on Xen backed systems. Xen has supported the .qcow2 image format for quite some time now. Whilst I don't have a Xen system to double-check, as we use the default Debian kernel, so it should "just work"! Note that the Debian kernel includes relevant drivers so you should find it works best in "HVM" mode (technically "PV-on-HVM"). Failing that, you may be able to bend our Xen tarball release (designed for PV support) to fit. If you are running a Xen backed OpenStack cloud, please drop us a line and let us know how it works for you.
As hinted above, the OpenStack build should be just around the corner. I had hoped to release it at the same time as all the other builds. However, it needs a couple more tweaks and some last minute testing. I'll update this post when it's live. As for the other appliances, please watch this space. I will announce batches of new appliances via the blog as we publish them. As per always, we love feedback; the good, the bad; and even the ugly (but please keep it constructive)! :) So please take the new release for a test drive and tell us what you think below in the comments. If you have any issues, please feel free to post in our forums. As per usual, please report bugs and feature requests on our Issue Tracker. Bonus brownie points if you can provide a workaround to a bug; or better still a pull request with the fixed code! :)TKLBAM update
Webmin update
Missing buildtypes?!
OpenStack build needed some love
Meet an TurnKey OpenStack hero - Tomas from 'Home at Cloud'!
More updates coming soon
Comments
Core's page 14.1 vs 14.2
Jeremy,
Is it just me or do the Core page build links still point to 14.1?
14.2 on AWS looks great -- thanks!
Mark
Not sure what happened, but it's fixed.
Hi Erick
LAMP will be in the next (first) batch of appliances to be released. At this point I still need to do a ton of testing, but I am hoping to be posting a blog post announcement for the first batch (early?) next week. So stay tuned! :)
Regarding PHP 7.0; TurnKey v14.x is based on Debian Jessie (aka 8.x). Because we use native Debian packages whenever possible (security and stability come first), we are stuck with PHP v5.6 until we rebase on Debian Stretch (aka 9.x).
Although perhaps we will consider at least documenting how to update to PHP 7.0 for those interested? Or now we have the confconsole plugin system, perhaps we (or a motivated community member?) can go a step further and develop a confconsole plugin to install PHP 7.0!?
Regardless, the next release of Debian; codename Stretch, includes PHP 7.0 and is currently in "release candidate" stage (i.e. very close to stable release). As soon as I've finished the v14.2 release, I'll be switching focus to v15.0. V15.0 will be a rebase on Debian Stretch so will include PHP 7.0 by default.
I don't want to give any specific timelines (as they always blowout and cause frustration and disappointment) but you can be assured that we'll release v15.0 ASAP (as soon as it's ready or Stretch is stable; whichever comes last; most likely the former).
GPG signatures
Hi Jeremy, Is there a reason the signature files for version 14.2 have changed extension from .sig to .hash? They appear to function the same way, i.e.
The change may screwup people who have written scripts to verify downloads.
Bringing up the subject makes me think of a another question that I've meant to ask about.
Is there a reason that the Turnkey release key doesn't have a trusted signature?
Information is free, knowledge is acquired, but wisdom is earned.
Hi John; great to hear from you! :)
I hope your travels (did? / are?) treated/treating you well!? :)
We just changed the name as a tidy up. Originally the .sig files actually contained a signature (as convention suggests they would). But that functionality changed quite some time ago. Since then they have actually only contained hashes and instructions on how to verify the files. So the name change was purely to bring our filenames back in line with convention.
And yes you are right, it may mess with some people's existing scripts. Deep apologies to anybody who's scripts break. I still think that the update is a good idea though, as it brings the file name closer to what users would expect. Users (especially Windows users in my experience) tend to look for hash files to verify downloads (if they do it at all), so now they can easily find it, and perhaps they'll go the extra step to check the signature too?!
Re your question on why TurnKey's key isn't "trusted": AFAIK it's because you haven't told your system to trust TurnKey's key! Essentially GPG/PGP relies on a "web of trust". By default, if you download a key from a server, there is no way to be 100% sure that the key belongs to who it says it does, unless you have verified it via some other means. That's why many open source groups have "crypto signing parties"; so people can meet IRL and check physical ID against their GPG fingerprint (many tech types tend to have business cards which also have their GPG fingerprint). Then they can trust (as much as possible) that that particular key really does belong to that particular person. It's not quite as secure, but I tend to check GPG fingerprints over the phone or (secure) instant message channels which I have used to communicate with the person before.
In the case of TurnKey, we state the release key fingerprint on the website (PS those docs need a serious update as they still refer to the old way we used to do it...) and/or you can also download it direct from GitHub. If/when you are assured that the key (or at least the key's fingerprint) really does belong to TurnKey, you can then choose to trust it. Once you have done that, you will no longer get the warning (so long as you do the checks on the same system)! :)
Yes, I'm Back
Hi Jeremy, Yes I'm back from my travels and trying to catch up on work I left behind. Will try to finalize the work I started on the Ansible appliance for 14.2. They've recently released a new version and it would be nice to include if it doesn't introduce new problems.
Thanks for the explanation of GPG/PGP. I did some reading and now understand that I must first create a user key pair, then sign the Turnkey Linux Release Key and mark it trusted. In the past, I've always resorted to checking the key fingerprint manually or by script. When I tried to create a user key pair, I received a message that my host didn't have enough entropy and several attempts failed. Guess I'll stick with the old method. :)
Information is free, knowledge is acquired, but wisdom is earned.
Glad to have you back! :)
No worries, so long as I'm aware of what's going on, that's fine. Actually it'd be great to have you update the Ansible appliance! AFAIK none of us have really done much with Ansible (I have been planning to have a play but still haven't gotten around to it).
Yes, generating keys on servers is a bit of a pain... And on virtualised servers, it's even harder (because they have so little entropy to start with, and develop so little as they run). Installing haveged (in Debian repos) can help. I've used it and found it helps, but I have also read mixed reviews on it's effectiveness. Apparently in some virtualisation scenarios it can actually be a bad thing as it can generate "fake" entropy (i.e. the system thinks it's generating genuine randomness, but really it's not). I forget the scenarios where it can be bad, sorry...
FWIW if you have a graphical environment with physically connected mouse and keyboard, it's much easier to generate entropy; and therefore keys... I generated my key pair on my laptop. I then generate subkeys as required (to put on my servers and other PCs). That way, even if one of my keys get compromised, it's not the end of the world (I just revoke that particular key).
Pages
Add new comment