v14.1 Release - Bugfixes, Maintenance and More

About seven months after the release of v14.0 we are proud to announce the updated v14.1 release.

turnkey 14.0 banner

All of the v14.1 appliances are available for immediate launch in the cloud via the Hub. Amazon MarketPlace builds are on the way too although no ETA at present. All the other builds (e.g. ISO, OVA, Xen, etc.) can be downloaded from their respective appliance pages (eg. LAMP, WordPress Node.js etc). Alternatively the entire library can be downloaded via one of our mirrors.

Another Great Community Turnout

Once again this release has been a community affair! We've had lots of great contributions from many motivated and helpful people. Most of the usual suspects get a mention. :)

The lion's share of the work was completed by team members John Carver (@Dude4Linux), Anton Pyrogovskyi (@qrntz) and Stefan Davis (@OnGle). Valuable contributions have also come from Jonathan Struebel (@jstruebel), Dashamir Hoxha (@dashohoxha) and @janglapuk. Drupal ninja Michalis Stivaktakis (aka Mike Stiv) gave us some invaluable suggestions on improving the Drupal appliances from both an end-user and developer perspective.

Worth a special mention is the increased engagement with a number of upstream developers for v14.1 (with guidance and/or commits). These include Vincent Barrier (@vbarrier) from iceScrum; Stephan Großberndt (@sgrossberndt) & Helmut Hummel (@helhum) from TYPO3; Carsten Brandt (@cebe) from YiiFramework and Jamie Cameron from Webmin.

As per always there are a ton of others that have contributed via the forums including bug reports, workarounds and feature requests. Big thanks to all for your effort, engagement and for generally spreading the TurnKey love.

Bugfixes and Maintenance

The v14.1 release sees a massive amount of bugs squashed and features added (43 and 20 respectively; plus some other more generic "issues"). It's fantastic to squash so many bugs this release. One of the bugs we've finally fixed was reported all the way back in 2012! It's a bit embarrassing to have a bug hang around that long; but it's a massive relief to finally close it!

All v14.1 appliances are built on Debian 8.4 and include all the latest Debian security fixes and package updates, as well as the latest TurnKey software updates. TurnKey updates include TKLBAM, confconsole, inithooks (including significant improvements to the fence - relevant to headless builds only) and deck (TKLDev only). All appliances have more strict password complexity requirements now too. They require minimum 8 characters with at least one of each: uppercase, lowercase and number(s).

Webmin update

v14.1 also includes an updated Webmin release (v1.780 - installed from the TurnKey repository). We had hoped to include the latest (v1.791) but felt that it wasn't worth holding back the TurnKey release any further as we are already way behind our planned release schedule. The significant Webmin changes worth noting are:

  • Addition of Filemin - a new HTML5/CSS3/JavaScript File Manager:
    • Package name is "webmin-filemin"
    • The old (Java based) File Manager ("webmin-file") is still available - find it under "Java File Manager" in the menu.
    • The Java based file manager has been deprecated and will probably not be included in the next TurnKey release.
  • Support for Let's Encrypt SSL certificates:
    • An SSL certificate can now be requested from Let's Encrypt using a new tab on the SSL Encryption page.
    • Note: Requires installation of the Let's Encrypt commandline tool.

v14.0 users can also upgrade to Webmin v1.780 if they wish. I detailed instructions in this comment (on GitHub). Please note that you will need to manually start Webmin after install (or alternatively reboot your server).

Selected Software Updates

Long term TurnKey users would recall that for most of TurnKey's history point releases (e.g. 11.1, 11.2, etc) have solely focussed on bugfixes and security updates. That precedent was broken when v12.1 was released. Besides bugfixes and security updates, v12.1 included updates to all upstream software.

It would have been nice to do that for v14.1 too but we decided to make this something of a hybrid maintenance release. All updated appliances are great but they increase the labour overhead significantly and also increase the risk of inadvertently introducing regressions. So we prioritised updating appliances that the community and/or upstream were helping us maintain. We also rebuilt many of more popular appliances that include upstream software. A significant amount of them have build code which will automatically install the latest version. This makes for a lower overhead as generally just testing is required.

Rebuilt Appliances:

Most of the following have updated upstream software installed. Although some have just been rebuilt as a more reliable and easier way to include bugfixes. In alphabetical order:

Ansible
icon
Bugzilla
icon
Drupal7
icon
Drupal8
icon
Etherpad
icon
GitLab
icon
iceScrum
icon
Jenkins
icon
Joomla3
icon
Moodle
icon
Nodejs
icon
Observium
icon
Odoo
icon
ownCloud
icon
Piwik
icon
ProjectPier
icon
Redmine
icon
SugarCRM
icon
SuiteCRM
icon
Torrentserver
icon
Trac
icon
Typo3
icon
Web2py
icon
WordPress
icon
YiiFramework
icon

New appliance:

mediaserver iconWe are happy to introduce the newest addition to the TurnKey library. It's called Mediaserver and was developed by Jonathan Struebel (@jstruebel). It is based on the Fileserver appliance so includes all of the connection options provided by that (SMB, SFTP, NFS, WebDAV and rsync). The primary Media Center functionality is powered by Emby. Emby provides media streaming via a Web UI (sort of similar to Youtube) as well as via DLNA. DLNA is supported by literally thousands of devices such as games consoles, smart TVs and mobile devices, as well as popular HTPC software such as Kodi (formerly XBMC). Check for DLNA compatible devices in the product database. Emby also provides support for some DVB TV cards, allowing it to operate as a DVR.

Known Issues

Currently there is only one known issue in v14.1 and that is related to the Canvas appliance. Currently when launched from the Hub, initially the Canvas webUI fails to start. A reboot should resolve that but we are working on improving it so that is not required. Beyond Canvas, at the time of writing there are no other known significant issues! :) We set out to squash all the appliance related bugs for v14.1 and we have mostly succeeded. There are still a few minor bugs that have been rolled over to the v14.2 milestone with a ton of feature requests (see on the tracker). We plan to put a dent in them for v14.2 and some cool new features! Perhaps you can help out too?!

Please take the new release for a test drive and tell us what you think below in the comments. If you are having issues you can also post in our forums and 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! :)

You can get future posts delivered by email or good old-fashioned RSS.
TurnKey also has a presence on Google+, Twitter and Facebook.

Comments

dominique120's picture

Fantastic news!

 

Thank you for all the effort you put into this.

Jeremy Davis's picture

And thanks too for your patience Dominique! :)
Ernest's picture

The redmine appliance consumes hard drive read/write. After the first reboot after installing from ISO, the harddrive like on virtualbox stays green and the appliance will not move/moves extremely slow behind initial setup/updates.

Virtualbox 5.0.15 r 105871

tkl redmine 14.1

Jeremy Davis's picture

Thanks for the report, we'll need to have a look...
Jeremy Davis's picture

I just tested turnkey-redmine-14.1-jessie-amd64.ova in VirtualBox v5.0.14 r105127 (on Debian Wheezy using kernel 3.16.0-0.bpo.4-amd64 from backports). I left the OVA VM defaults untouched: 512MB RAM; 1 vCPU with VT-x/AMD-V & PAE/NX both enabled; 20 GB vHDD (sparse). I skipped the initial security updates.

During initialisation the HDD indicator was very busy. But once the firstboot scripts completed it settled down. I logged into Redmine within my web browser and it all seemed to be running fine to me. It wasn't super fast but considering that Redmine is written on Ruby on Rails and the low resources allocated, it ran as good as I would expect. With no activity (other than the web page still open in my browser) the vHDD indicator was occasionally "blipping" but otherwise was mostly off. Actually the network indicator was "blipping" as much, if not more than the vHDD indicator.

Although for my test to be conclusive I probably should update VirtualBox and install from ISO as you did (and install initial sec-updates too by the sounds).

Assuming that it is given the same virtual hardware, theoretically once the ISO is installed the VM should be identical. Essentially that's how we build the OVA - by (scripted) install of the ISO to a vHDD and then packaging it. Out of interest is there a reason why you used the ISO and not the OVA (pre-built VM)?

Did you use a sparse or a pre-allocated vHDD? Do you have plenty of free (real) harddrive space? Do you have a lot of other i/o operations going on? Do you have plenty of free RAM (i.e. you system isn't paging/swapping too much)?

The only thing I can imagine is that if you used a sparse disk and you don't have a lot of free space and/or there are a lot of other i/o operations going on (including paging/swapping) then the VM may have cached a lot of it's writes (to RAM - which may in turn have then been paged/swapped) and a whole vicious cycle is going on. Then add on top of that extending the sparse disk on the fly; that will often cause a flood of i/o.

FWIW my system is i7 laptop; 4GB RAM; 256GB SSD with 4GB swap allocated. I'm running Debian (as mentioned above) with Gnome3, Thunderbird running and about 20 Chrome tabs open. With the 14.1 Redmine VM running my system has 170MB RAM free & 2GB swap free and everything is running pretty sweet...

I suggest that you leave it running for a little while and see what happens. And/or try rebooting it. And/or try to free some other system resources and see if that helps it settle down...

Another excellent TKLX team effort. The Let's Encrypt and Java-less Webmin are certainly timely and much appreciated enhancemenets.

Congrats on corralling all the moving parts Jeremy :-)

 

Cheers,

Tim (Managing Director - OnePressTech)

Jeremy Davis's picture

Thanks for your kind words and ongoing support and feedback.

Have you had a go of the Webmin "Let's Encrypt" functionality? TBH I'd be really interested to hear about the use of it. I didn't actually get a chance to test it out but read about it in the Webmin changelog.

FWIW we have big plans for integrating Let's Encrypt into v14.2. The plan at this stage is to include the option of pre-seeding Let's Encrypt cert generation (so it will be automated within the Hub at launch or can be pre-seeded for all the other builds). We are not quite sure exactly how users will configure it post-install/post-firstboot (if not pre-seeded) but we don't really want to add extra interactive firstboot scripts. Actually we'd like to reduce them - there already too many questions at firstboot IMO. So it is likely that we will extend the confconsole to include additional configuration options, but we'll have to see how that goes...

As per always, your input and feedback are warmly welcome! :)

sidboy55555's picture

Can I upgrade my v14.0 to v14.1 with the command line or something? or must I reinstall my dedicated server?

Jeremy Davis's picture

The v14.1 release is mostly the same as v14.0 but built on top of an updated OS with some updated components. The primary value of a TurnKey "point release" is for new servers; not existing ones. All the components; with the exception of the upstream software are essentially what you'd have if you started with v14.0 and ran:
apt-get update
apt-get upgrade
apt-get dist-upgrade
If you do that though; please ensure that you have a current backup; just in case something goes wrong! Actually I'd go as far as to suggest that you should regularly be testing your backups on a clean TurnKey server anyway so this may be a great opportunity to do that. I.e. test doing a TKLBAM (or whatever alternate backup solution you use) restore to a clean fresh version of TurnKey. Personally I'd be testing the restore on v14.1 so you are aware of any potential "gotchas" moving forward (and you can tell us so we know).

With regard to the updated upstream software; unfortunately there is no easy way to update that without risking data loss. So really you'll want to do that manually anyway. FWIW with most of the appliances; even if you migrate your data with TKLBAM (from v14.0 to v14.1) then your backup will still include the old version of the upstream software; so you will still need to update that yourself...

sidboy55555's picture

Hi, thnx it really helped, because I don´t like bugs haha (nobady does :P) keep up the good work!

 

p.s maybe the turnkey needs a mobile version like m.turnkey.org :P

Jeremy Davis's picture

Thanks for your kind words! :)

Actually something that I've thought of is that there may be some appliance specific config changes that you may like to make on your appliances (which are a part of v14.1). To check out whether that may be the case, you'll want to have a look at the bugs we resolved for v14.1. Go to GitHub and looking at the v14.1 "milestone" issues. Then select your appliance name from the "Label" drop down (see image for details).

As much as possible I try to add all the appliances that a particular bug affects, however sometimes I will only add "core" if it affects all appliances, or "lamp" if it affects all lamp based appliances. So I suggest that you also check both "core" and probably "lamp" too. Unfortunately thought GitHub doesn't support OR operations on tags/labels, so you'll need to do the searches individually. Hopefully I haven't confused you too much... If you need any clarification (either on what you should check for your specific appliances, or how to implement a specific change/bug fix on your appliance) please do not hesitate to ask...

TBH I think that the TurnKey website needs a whole lot more than just a m.turnkey.org! It's in some serious need of some love I reckon! We are hoping to do a whole website refresh at some point in the not-too-distant future. I think it has been nearly 6 years since the last one...!

Wick Net's picture

 

First off, thank you SO much for all your hard work in bringing us a wonderful product lineup - it is of immense help to us sysadmins running open source software that "just works" on your appliances.

Last month, I had deployed TKL Canvas 14 on a locally hosted ESXi v6.1 vm, that worked with absolutely zero issues. Tempted by the new 14.1 update, I deleted the old and deployed the new version, which again came up without any issues. However, users apparantly no longer have any option/button to upload their profile pictures, which seems strange as the version of canvas on TKL 14.1 appears identical to that on v14.

Might this be another usability issue, besides the one you reported of the UI not coming up on the hub for the new canvas appliance?

Many thanks for any assitance. If a huge problem to resolve, I'm happy to go back to v14.

 

Wick Net's picture

 

Belay the earlier request. Found I have to enable the Avatar function for profile picture editing. Phew!

Wick Net's picture


Great, great work with your appliances, as always, but attempting to replace SSL certs on just v14.1 LAMP appliance is killing me. Not a novice but after hours and hours of  googling, experimenting and then restoring snapshots, I've thrown up my hands and resorted to appealing for help.

I have a wildcard server.crt and intermediate ca.crt downloaded from RapidSSL along with my private.key generated with the .CSR file - all are in .pem ASCII format with ---BEGIN--- and ----END---- lines. Simply replacing your certs in /etc/ssl/private directory with my files using the same names does not work, as the first apt-get update && apt-get upgrade rewrites them. Pointing the stunnel.conf file to my own .pem file hosted in /etc/ssl/mydomain/cert.pem does not work as restarting stunnel4 services crashes immediately. I'm unable to make sense of the it's log. Uploading the cert, key and ca.cert using webmin's SSL module does not work (it says wrong format), but  copying and pasting the actual contents of the files in webmin does work but ONLY for https://serverI:12321 access, not for the actual site (https://hostname.mydomain.com which still shown the self-signed LAMP cert.

I'm sure that I'm not alone in struggling with a basic functionality for a production server and many, many of your users would love to get simple, clear documentation specifying EXACTLY what to change in which conf files / directories for any v14.x appliance using Apache or NGINX web-servers, especially as you’ve built custom appliances with stunnel doing some SSL heavy-lifting. Solutions suggested on the internet for replacing SSL certs in apache or nginx are written for plain vanilla installs using Debian's ISO's and do NOT work on your appliances.

Please help!

THANK YOU!

Jeremy Davis's picture

We recognise that adding SSL certs is not as easy as it should be. We hope to address that in v14.2 (see these issues: #382 & #546) but obviously that's not much help to you right now...

As of v14.0 our config is slightly different WRT default Debian (Jessie) Apache (2.4), but not significantly different.

The default global Apache cert location is defined in the ssl_mod config (/etc/apache2/mods-available/ssl.conf). So you could add your new cert to /etc/ssl/private and adjust the default global Apache SSL conf to point to it. Alternatively you can define certs on a site by site basis by adding the 'SSLCertificateFile /path/to/cert.pem' directive within the 443 server declaration in your current site file (default in LAMP is /etc/apache2/sites-available/000-default.conf). Either will require an Apache restart (service apache2 restart).

To use the cert with Webmin and Webshell you'll need to also adjust the stunnel config (/etc/stunnel/stunnel.conf). If your cert is causing issues then double check that your pem looks something like this:

-----BEGIN CERTIFICATE-----

    ... cert here ...

-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----

    ... private key here ...

-----END PRIVATE KEY-----
-----BEGIN DH PARAMETERS-----

    ... Diffie Hellman parameters here ...

-----END DH PARAMETERS-----

If your doesn't look like that then you should be able to make it look like that using the current pem, crt & key files that you currently have. TBH I have limited experience with "proper" (i.e. not self-signed) SSL certs so am unable to double check any of my understandings.

Another thing to be wary of is that if you created (or edited) the pem file in Windows Notepad it may have mangled the line endings? I recommend that you use something like NotePad++ for Windows editing of any text files that are intended for use by/in Linux.

Also one of our community members has provided a script (turnkey-make-ssl-cert) which is now in all TurnKey appliances by default. TBH I have only used it with it's default configuration (to create self-signed certs) but by my understanding it can be used to generate other certs.

I hope at least some of that helps...

Wick Net's picture

Thank you SO much for your response. I'm beat now but wil try your suggestions tomorrow am and report back.

Ralph Sanders's picture

./upgradeWizard.log could not be created/written to. Please fix permissions on your SuiteCRM directory.

 

I keep getting this error can anyone help

Jeremy Davis's picture

Apologies that I missed your post.

FWIW as a general rule, posting on our forums is the best way to ensure a (more) timely response. I monitor those regularly and there is a nice list of unanswered forum posts that I use when responding on the forums. I usually closely monitor blog posts for the few weeks after they're published. I also get notifications about comments on blog posts too, but they can often get buried in my inbox. As there isn't a nice list anywhere of unanswered blog post comments, the only time I usually see "late comments" is when I clean up spam or otherwise find myself on a blog post.

Anyway, it sounds like the permissions are too locked down to allow upgrade of SuiteCRM in our appliance?! Changing the ownership of ./ (probably /var/www/suitecrm) to www-data should resolve that.

Pages

Post new comment