You are here
v14.0 stable release - Massive Community Effort!
Drum roll please... May I proudly introduce: The TurnKey Linux v14.0 release!
A long time coming...
Wow is it mid September already!? What has happened to the year?!
To be honest I had expected that the TurnKey v14.0 release would have been finished months ago. But after witnessing first hand how much effort a release takes; I really wonder how Alon managed past releases mostly solo?! It has been a steep learning curve but I have been lucky to have Alon and Liraz supporting, guiding and nudging me in the right direction all along the way. Thanks tons guys! :)
Biggest Community effort to date!
TurnKey has always aimed to be a community production. And we have certainly had some awesome community contributions over the years. But never has a TurnKey release been touched by the hands of so many contributors.
Not only has the community provided some new appliances; but also helped drive feature development and implementation. When we also factor in all the bug reports, feature requests and other community input there are more than a hundred contributors! So congratulations to all of you wonderful and generous TurnKey community people! Backslapping all round! :)
These people especially deserve a mention (if you think your name should be here and I missed it; please accept my deep apologies and email me so I can fix it!).
| @wvengen | @SiKing |
| Ken Robinson (@DocCyblade) | TKL) | John Carver (@Dude4Linux) | TKL) |
| Landis Arnold (@l-arnold) | TKL) | Tim Hibberd (@OnePressTech) |
| Anton Pyrogovskyi (@qrntz) | Stefan Davis (@OnGle) |
| Jonathan Struebel (@jstruebel) | Jeroen Peters (@jeroenpeters1986) |
| Alfonso Valdes (@ponchov) | Vinitha Cejo John (@vinithacejo) |
| Peter Liven (@plieven) | KAMP.de) | Oleksiy Avramenko (@AlexAv | EspoCRM) |
| Lloyd Ernst (CloudStaff CEO) | Adrian Del Rosario (CloudStaff) |
| Bryan Santos (CloudStaff Manager) | Rodolfo Lansangan (CloudStaff) |
| Justin Ashley (CloudStaff) | Mark Krueg (@markkrueg) |
| Richard van Dijk (@richard-vd) | Rob Fantini (TKL) |
| Kevin Destrem (@kefniark) | pee (TKL) |
New Features
Adminer (replaces PHPMyAdmin & PHPPgAdmin)
Troubles forcing the Debian Jessie version of PHPMyAdmin to stay bound to port 12322 (without hardcoding a full URL) lead me to consider Adminer (as suggested on the tracker). Following some testing we decided to go for it. No sooner had the decision been made; community superstar Ken Robinson (@DocCyblade | TKL) swung into action and took the project on!
Hardened default SSL/TLS settings
After the SSL troubles of the last year or so, default webserver settings have been slowly getting better. However nowhere near good enough for community powerhouse John Carver (@Dude4Linux | TKL). John took it upon himself to drive the hardening of default TurnKey webserver SSL settings (technically TLS settings as all versions of SSL are now disabled).
The result is that now TurnKey appliances have Webmin and Webshell hidden behind stunnel (TLS only) and the 3 webservers we use across appliances (Apache, LigHTTPd & Nginx) are all configured to use consistent hardened TLS cipher suite and settings. Tomcat too has hardened TLS settings for v14.0.
Security & System Alerts
For a long time TurnKey appliances have been auto installing security updates. But have you ever wondered what has been updated and when? Well wonder no more! TurnKey appliances will now alert you via email when updates have been installed. This should make questions of "am I vulnerable to such-and-such?" much easier to answer.
TurnKey v14.0 appliances also include a minimalist monitoring system (Monit) which also alerts via email when RAM, CPU and/or HDD limits are hit (75%, 90% & 90% respectively). The email address for all these features can be set at firstboot. As a bonus you will also be automatically subscribed to TurnKey's "Security and News Alerts" email list. This is a very low traffic e-newletter which will only email you with important security and/or news announcements. You can unsubscribe at any time if you'd rather not.
New Appliances
We have lost a few appliances since last release. Some upstream software has been abandoned, some is broken and others have changed their licence (so no longer open source). That's always a pity, but let's focus on the positives!
Ansible
So not only has John got a passion for security; he also has an interest in automation and orchestration. So he developed the Ansible appliance. According to the words on the box:
Ansible is an IT automation tool. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates.
EspoCRM
EspoCRM is light-weight CRM platform targeted at small to medium business. It provides plenty of features with a clean responsive design. Thanks to Alex (Oleksiy Avramenko | @AlexAv) from EspoCRM (upstream) for doing most of the work.
Foodsoft
The Foodsoft appliance has been a long time coming. Despite only just being officially released, the Foodsoft code has been avaialble for some time now. Development of the appliance build code (by @wvengen - also the upstream Foodsoft dev) motivated Liraz to rewrite the TKLDev docs! @wvengen has also contributed to the Rails appliance code (the base on which Foodsoft is built).
Laravel
Laravel is a PHP framework with the tagline of "The PHP Framework For Web Artisans". TBH I've never used it but I'v heard great things and I must say it looks pretty sexy! Arguably a product of the "php renaissance".
Some time ago Kevin Destrem (@kefniark) developed a Laravel appliance. Unfortunately it is only seeing the light of day now. We couldn't get in touch with Kevin so Anton (Pyrogovskyi - @qrntz) updated it to the current version of Laravel for a v14.0 release.
SuiteCRM
SuiteCRM is a CRM suite forked from SugarCRM provided with additional modules. A question from Bill Goodall prompted me to have a quick look at SuiteCRM, by the time I had worked out the build code would be almost identical to SugarCRM, TurnKey had a new appliance! :)
Drupal8 (beta) & Joomla3
Whilst generally TurnKey only includes stable (non-beta) software we decided to make an exception for Drupal8. Drupal 8 has been in development for some time now and is slated for a stable release later this year. The Drupal7 appliance (which utilises drush) has been very popular with developers and now that the Drupal8 API should be essentially stable; we thought perhaps our dev users may find a TurnKey Druapl8 appliance useful? Let's see! :)
The new Joomla appliance is a fork of the previous Joomla2.5 appliance. Whilst it is technically a new appliance it is more of an update. The only significant difference is that it will track the 3.x branch of Joomla. As previously, the Joomla appliance includes the latest stable release. Once Joomla 4.x is in beta, we may also consider releasing an additional Joomla beta appliance. But that will be some time away...
Limitations
There a few limitations of this release.
- Release build formats - currently there are only ISO downloads and Hub deployments available. The other builds are coming but we need to make some tweaks.
- 64 bit only - as mentioned in the v14.0 RC1 announcement
- Web browser considerations - due to SSL/TLS hardening, Windows XP users will need to use either Firefox or Chrome to visit HTTPS on TurnKey appliances. Other Windows users will need at least IE9 (or Firefox or Chrome).
- Hub: EBS deployments only - due to technical limitations v14.0 appliances are only available for EBS backed instances. So unfortunately Budget plan users won't yet be able to launch v14.0 (with the exception of micro servers). We will be looking into a workaround at some point in the future. If you are affected by this and need v14.0 appliances in larger sizes please contact us direct (try me on jeremy AT turnkeylinux.org) and we can investigate workaround options.
Still work to do...
As mentioned above there is still work to do before I can legitimately say that the release is finished. Even then, there will no doubt be bugs reported, features requested and support required. And by then I'll probably need to start thinking about v14.1... Oh well, onwards and upwards! :)
Remember that all contributions are warmly welcome. Bugs and feature requests go on our issue tracker. Questions and support go in our support forum. Other content (e.g. tutorials, ideas, general discussions) can go in our "general" forum. And last but definitely not least; devs and coders please have a look at TKLDev and/or the existing appliance build code and/or other TurnKey software. Hope to see you soon! :)
Comments
Great! Docker images coming?
Hello, this looks great and comes just in time for a new project.
Will the docker images be pushed to
https://hub.docker.com/search/?q=turnkeylinux
soon? That would be most welcome!
That's the plan!
Not sure how long it will take. Actually TBH I'm not even sure how much work they will need. I anticipate that we may need to make some adjustments for systemd but we'll see...
Thanks! :)
Thank You
Version 14 was just in time for two Debian Jessie systems I needed to install.... Turnkey makes install, backup and recovery easy , safe and reliable. For us backup and recovery are a very to have set up for any system. B&R has worked perfect for us. We run all our systems on a local network. With Turnkey backups I know that most of our systems are 5-10 minutes away from running on amazon using turnkey hub.
Thank you to all who produce Turnkey .
Thanks for the feedback.
No list sorry
I can tell you the specific appliances that have been depreciated for v14.0 (or more correctly since the release of v12.1):
Also there were a number of appliances that were not included and may or may not be released at a future date:
OTTOMH there was only one comeback (i.e. app that wasn't in v13.0 but is in both v12.x & v14.0):
Finally there were a couple of appliances which will be released later:
I know the library fairly intimately now though so if you have specific questions (like your torrentserver & fileserver ones) please feel free to ask. OTTMH beyond torrentserver, fileserver and domain-controller there aren't too many significant changes that I can think of.
Regarding those apps I mentioned:
fileserver - actually doesn't include Ajaxplorer (or Pydio) anymore. The initial reason was a technical limitation. We could not get the latest Pydio to install non-interactively. I got in touch with the lead Pydio dev but he was heading off on holidays so we left it for now. Also Pydio has grown beyond a simple fileserver UI so at this point we intend to release a standalone Pydio appliance in the future. So instead of Ajaxplorer/Pydio. So the new fileserver uses SambaDAV to provide a webUI to access files. It uses the WebDAV access (which is new for v14.0) and Samba authentication to provide access to your files (new users need to be added to Samba). It also includes NFS enabled by default too.
torrentserver - as per previous releases it includes the fileserver (so SambaDAV etc) but as you note rTorrent and ruTorrent as the torrent tools.
Domain Controller - This now uses Samba4's AD abilites to provide a modern AD DC (i.e. not an NT4 PDC anymore). Because of the significant changes it's been stripped to a minimlaist MVP for v14.0 but we're hoping to add some of the old features back in for v14.1
As per usual all the other apps that include upstream source installs are at latest versions (as of time of appliance code update - some may have newer releases since we updated the build code). Obviously all of the Debian packages are at the latest (Jessie) versions...
Also as may be of interest to you, I hope to reinclude the Zibra appliance in the library; hopefully for v14.1...
Help with LXC appliance
@Jeremy, could you use some help with the LXC appliance? I'd like to see some changes that would allow the new Ansible appliance to manage containers on the LXC appliance using Ansible's lxc_container module.
Ansible lxc_container requirements:
I'd also like to break the dependance on openvz images for the lxc-turnkey template. Are there plans to provide pre-built LXC images on the TurnKey mirrors?
Also for 14.1, I'd like to be able to build LXC images in the TKLdev appliance. The usecase I have in mind is for developing a custom appliance, i.e. one which is not in the official TurnKey Suite.
Information is free, knowledge is acquired, but wisdom is earned.
Sounds interesting John
I anticipate that the new templates we will provide for v14.0 will be labelled as LXC/OVZ templates but will essentially be the current v14.0 appliances built with the existing OpenVZ build code. Preliminary testing shows that only a bit of a tweak (remove systemd and replace with sysvinit) is required. The tweak is because the version of SystemD in Jessie does not play nice in a container. Apparently upstream SystemD has already resolved this so when we get to v15.0 (Debian Stretch - currently 'testing') we'll be all good...
Re your required versions; other than lxc-python2 (which you note we can get with pip) it appears that you're in luck:
# apt-cache policy lxc python lxc-python2 lxc: Installed: (none) Candidate: 1:1.0.6-6+deb8u1 Version table: 1:1.0.6-6+deb8u1 0 500 http://ftp.au.debian.org/debian/ jessie/main amd64 Packages 500 http://security.debian.org/ jessie/updates/main amd64 Packages python: Installed: 2.7.9-1 Candidate: 2.7.9-1 Version table: *** 2.7.9-1 0 500 http://ftp.au.debian.org/debian/ jessie/main amd64 Packages 100 /var/lib/dpkg/status N: Unable to locate package lxc-python2Both of the above would be included in the LXC appliance anyway; and it sounds like the python library for interacting with LXC would be useful to include OOTB too. So unless there is any other significant requirements it sounds like that would be a goer...
Re your comments about building LXC in TKLDev, I have a few comments to make:
Firstly we have intention to improve on TKLDev by moving from building in a chroot to building in a container. We may use LXC although we are not yet committed. Personally I think that systemd-nspawn may be a better alternative? I'm not sure whether that will happen in time for v14.1 or not though. Ideally IMO we would also include QEMU too so we can do non-native architecture builds (I'm thinking ARM).
So concurrently to that; we would also be aiming to allow the building of all appliance build types in TKLDev. You can already leverage buildatsks to build any of the appliances in any of the build types. But I think that it would be neater if it were baked into TKLDev and we could specify the desired buildtype at build time... In the short term that would probably be a case of including buildtasks pre-packaged into TKLDev; but longer term it would probably require more than that so it is an integral component...
Beyond some of the subtleties I think that your plan is a great one. Actually beyond some of your specifics it is very similar to discussions that Alon, Liraz and I have had...
A framework to provide for scripted automated testing of appliances is already in the works (currently using the TKLDev build chroot; but eventually the build container). However it is not a current priority so there is no ETA. I would hope that the basics would be in place for v14.1 though. I anticipate that once it is to a usable point it will be public and posted on GitHub...
Between a rock and a hard place
My testing so far confirms that the Jessie versions of LXC and Python meet the requirements for Ansible's lxc_container management. However when I try to install the lxc bindings for Python2 using pip, I get a failure because lxc-dev is missing. I can't install that package because it was withheld from Jessie due to some issues.
LXC has embraced Python3 and has built those bindings into LXC. Ansible on the other hand is holding back on adopting Python3 and it's scripts will fail if you try to use it, hence the need for the Python2 bindings. I can't figure out how to build and install them on Jessie without having the lxc-dev package. In Ubuntu, the desired bindings are packaged as 'python-lxc'. See https://launchpad.net/ubuntu/+source/python-lxc
I also discovered that lxc-create now uses xz compression for downloading images, but there appears to be a missing dependancy on the package 'xz-utils'. That will need to be added to plan/main.
Information is free, knowledge is acquired, but wisdom is earned.
Maybe try to install Ubunutu's "python-lxc" deb?
As for the note re lxc-create; that's awesome to know. And will help when we get that far...
FYI I'm currently battling with the headless builds. I'm having issues with the fencing under LXC. It worked great under OVZ and from what I can see the LXC appliance works around it by preseeding the inithooks (although TBH I never actually used LXC before)...
I have build "lxc-dev" for v14.x (Jessie)
Note, I have called the package "lxc-dev-tkl" because the Debian Jessie lxc package "conflicts" with "lxc-dev" (so if I called it "lxc-dev" then it would uninstall lxc!).
Congratulations!!
It was a nice surprise to see the release of 14.0 on the very day I returned from a month long trip to Europe. Tip of the hat to Norway and Austria.
Thanks, Jeremy, for your kind words. I know that the changes I suggested were cause of some of the delay and they added greatly to your workload. Thanks for having faith and being willing to take on such large changes so late in the release cycle. That's part of what makes it great to be a member of the TurnKey GNU/Linux community. I was pleased to see how smoothly the install of the 14.0 Ansible server proceeded. The entire TurnKey community owes you a round of applause for taking on a difficult task and seeing it to a successful conclusion.
Information is free, knowledge is acquired, but wisdom is earned.
Thanks back at you John
14.0/ownCloud
Huge thanks to everyone involved in bringing 14.0 and the appliances to release.
I have the ownCloud appliance up in a VM and it's all working very well (after I got my head around its "Trusted Domain" thing).
Phil
Thanks for the feedback Phil :)
Sounds like TKLPatch probably needs an update for Jessie/v14.x
You could try doing this:
Although ultimately perhaps it would be better to just convert your patch to TKLDev build code and build from scratch? We don't intend to put a lot of effort into maintaining TKLPatch in the longer term whereas TKLDev will get lots of loving! :)
A perspective on TKLPatch
I would like to see TKLPatch or something like it continue to be supported. I use it extensively as a way to setup defaults for the different packages from the base turnkey appliances which are unique to my environment. For instance, I have several patches that configure different settings for SAMBA for my own environment which I combine into one master patch to create my own flavor of the fileserver appliance. I then leverage most of those same patches to customize the torrentserver appliance since I want most of the same settings applied to the SAMBA installation on that appliance. Using the TKLPatch mechanism allows me to easily use one patch for multiple appliances, and the nesting capability allows me to ensure that a collection of patches gets applied in the correct order if there are any dependencies between patches.
Since these are customizations that I'm making to the official releases for my own environment, I don't think they belong in the official app repository, and if I try to simply maintain separate branches of the app repos, any updates to get a SAMBA patch working on the fileserver appliance would have to be manually copied over to the torrentserver appliance rather than just running the TKLPatch against the torrentserver appliance. This would reduce efficiency since I would essentially be duplicating work and makes it harder to maintain bug fixes.
Now, maybe there is a mechanism in the TKLDev to handle this scenario already which I haven't discovered. If so I would be willing to use it in place of the TKLPatch. If not and you don't want to support both TKLDev and TKLPatch, I would like to see some sort of patching capability added to TKLDev. Something like make-patch which would take an argument of the patch location (folder or archive) and apply it to the root.patched or root.sandbox.
BTW, I love what you all have done with Turnkey Linux and especially the TKLPatch/TKLDev products which greatly aid a part-time sysadmin like me in maintaining Linux servers.
Thanks for sharing Jonathan!
Currently you could use TKLDev and use git to maintain your own tweaked branch. When there are updates you pull them into your tweaked branch and then (re)build ISO (or whatever build you like with Buildtasks).
Having said that I understand that having a simple TKLPatch possibly makes more sense in some scenarios. Also some may prefer to work with modified "official" builds (rather than building their own)...
FWIW I finally got around to investigating this and have a fix
The fix hasn't yet been merged into the main TurnKey repo. But once that's done then hopefully very soon after Alon will rebuild TKLPatch and update the v14.x repo with the fixed copy.
If anyone wants to test this out then the changes that I made can be inspected on GitHub here. You can replicate those changes by manually editing your local
/usr/bin/tklpatch-prepare-cdrootto match the commit (i.e. remove the one line in red in the left pane; and add the 6 lines in green on the right).Also I probably should have opened an issue regarding this on the tracker ages ago. But better late than never... :)
We're swapping to OVA
For the record an OVA is essentially a VMDK and an OVF bundled together in a single (OVA) file which most application which can read an OVF will support (I have tested in VirtualBox and VMware Player and both work fine OOTB). The beauty of the OVA format is that you can use it as is and there is no need to unzip!
Are you using the Hub?
What I mean by that is that under the hood, TurnKey is Debian. So you can use the Debian upgrade path if you desire.
However TKLBAM is the recommended method. Please note that there are some significant changes between v13.0 and v14.0 so it is likely that some post migration tweaks will be required. Ideally I'd like to automate some of the common tweaks to make it easier but unfortunately I haven't got there.
The beauty of TKLBAM is that you can restore your backup to a new server and treat that as a test migration. If you document anything you need to do then once you have everything working as you want; destroy your test server; do a fresh backup (to get all the latest data); restore to a new server (following your documentation). Then (assuming it's an EBS baked server) you can stop your old server and do finals config to make your new server live. Once you are satisfied that everything is 100% good then you can destroy your old server and your old backups. Personally I'd wait a few days at least...
All images available as VPS one click installs on GigaTux
You might be interested in knowing that we made all of the appliances for 14.0 available on our VPS hosting platform, and each image can be installed with just one click. This sets up a base installation with sensible default.
We wrote a little about it at https://www.gigatux.com/news/index.php/2015/11/09/turnkey-linux-14-now-a... and we make these images available to all via our Debian repository.
Thanks Marc
Closing comments due to spammers
This is a fairly old blog post which relates to an old release. As such, it isn't super relevant anymore. As it seems to be attracting a lot of spam posts, I'm going to lock it. Please feel free to comment elsewhere or better still sign up and start a new thread.
Pages