Henry den Hengst's picture

I suggest that every Turnkey appliance should mention which version Core it was build on.

Jeremy Davis's picture

The TKL version number means that it was built on the same version Core. E.g. TKL LAMP v12.0 appliance is built on TKL Core v12.0. TKL Joomla v11.1 built on TKL Core v11.1...

Or did I misunderstand your suggestion?

Henry den Hengst's picture

To me they all just say... "This appliance includes all the standard features in TurnKey Core, and on top of that:" which always points to TKL Core v12.0 (at this point in time). If that is correct than everything is alright, but not clearly communicated in terms of software version management.

What I would like to know is rightaway, what version core is used for the appliance? I do not want to make an extra click to find out, especially not if they are all build on the latest Core anyway.

Jeremy Davis's picture

For example the (very dated) TKL Zimbra image (which is stuck at v2009.10-2 until TKL supports 64 bit) has the same generic link to TKL Core as a current v12.0 appliance. I can see how that may be a little misleading, especially for someone new to TKL.

So (to continue using the Zimbra appliance as an example) you are suggesting that instead of:

This appliance includes all the standard features in TurnKey Core, and on top of that:


It should perhaps read something like:

This appliance includes all the standard features in TurnKey Core (same version as the appliance - check the Core changelog) and on top of that:


Or better yet (pointing to the specific changlog entry):


This appliance includes all the standard features in TurnKey Core (specifically this version) and on top of that:


What do you think?

Henry den Hengst's picture

Usually Open Source Software is very good at software version management, therefor I was surprised to notice this rather casual approach.

You suggestions would be an improvement, although the following is very simple and would do the trick perfect:

<name appliance> version <x.x> build on Core version <x.x>

eg. Joomla 2.5 build on TKL Core 12.0

Carl Kiendl's picture

While the immediate attempt to find a better solution is commendable, I would like to point out (in a purely informational, non-confrontational way) that Henry does not speak for all of us...personally, I always found the versioning scheme rather intuitive: The appliances are released in series. Every appliance is built on a core plus a payload. So it makes perfect sense that Turnkey Joomla 13 is the Joomla appliance of the 13th series, and thus built on TKL Core 13 - the core of the 13th series...

What's -imo- a whole lot more confusing about the versioning is that an upgrade of the Core version does not necessarily imply an upgrade of the playload, or that the payload is current in any way: To me, it is obvious that TurnKey DokuWiki 12.0 is built upon TKL Core 12...it is not obvious that, despite the fact that the Core was upgraded on 2012-08-30, the payload is from 2009. (We've had this topic before, so I understand how it comes to that, the fact is just not very clearly communicated.)

I do think Henry's suggestion is a bit verbose and kind of takes the "branding" out of it - it stops being "TurnKey Linux Something" and is turned into "Something installed on TKL". While it is subtle, it moves the name away from communicating "this is a turnkey-ready Something appliance of the TKL brand" to saying "this is Something installed on the following Linux distro: TKL". iow, there is a communicative difference between "TurnKey Joomla 13" and "Joomla version 2.5 built on Core version 13.0". The latter is no different from "Joomla version 2.5 built on Ubuntu Server version 13.04", "Joomla version 2.5 built on CentOS version 6.4" or "Joomla version 2.5 built on Debian version 6.0.7".

The focus is no longer on it being an appliance, and is instead put on the payload software being installed on a random Linux flavor. And TKL appliances are more than that. They deserve better, and the creators have earned the right to brand them.

I believe the easiest way to consolidate all three points of view in this thread would be to move the most important information of the tucked away version information page onto the main appliance page: Instead of just having the almost-pointless "Stable version: 12.0 (changelog)" line, place a table on the page which says

Core version: 12.0
Software version: 0.0.20091225c-10+squeeze2
Software source: upstream repository
Additional software: apache2, mysql-server

Click here for more information

With "here" linking to the changelog, where the detailed information can be found.

That way, the current "grand" scheme of versioning in series or waves can be maintained, TKL retains its branding, but everybody can quickly and easily get an idea of what exactly they're getting with the appliance.

Henry den Hengst's picture

Thank you Carl in explaining the current way of versioning, that will help me (and probably others) in figuring out what the appliance is all about.


Joomla 2.5 build on TKL Core 12.0

Joomla 2.5 build on TKL Core 11.0

Joomla 1.5 build on TKL Core 12.0

Joomla 1.5 build on TKL Core 11.0

implies the version of TKL Core and the version of what is build on top. In no way was that ment to put down TKL in any way, but the clearify the exact content of the appliance.

I just learnt how it is being done now, and I hope my suggestion of how it can also be done will be held in account.

Jeremy Davis's picture

Instead of your suggestion:

Joomla 2.5 build on TKL Core 12.0
Joomla 2.5 build on TKL Core 11.0
Joomla 1.5 build on TKL Core 12.0
Joomla 1.5 build on TKL Core 11.0

Why not just keep it the same as it is:

TKL Joomla 2.5 v12.0
TKL Joomla 2.5 v11.0
TKL Joomla 1.5 v12.0
TKL Joomla 1.5 v11.0

Then like I said in my original post - the TKL version relates to the Core version it is built on...

The only reason the version is mentioned in the name of the Joomla appliance (and the Drupal one too) is that there are 2 appliances using different versions of the same software. It is impossible (or at least impractical) to maintain a simple consistent naming convention and also include version numbers of software in the appliances unless there is a need to differentiate them from one another (like with the Joomla and Drupal appliances). 

To use a naming convention consistent with your suggestion Henry, what would we call the TKL LAMP v12.0 appliance?

Apache 2.2 MySQL 5.1 PHP 5.3 Perl 5.10 Python 2.6 on TKL Core v12.0?

I know what I prefer! :)

Perhaps Henry, the issue is like Carl suggests and the "Stable version: 12.0" and is too small (just above the "Turnkey Core" link) or not obvious enough?

I must admit that I quite like your suggestion Carl although it potentially also suffers from some of the same issues as Henry's. While it would work great for many (most?) of the appliances, it is desirable to have consistency and so what details do you include for the LAMP appliance? If you start including Apache and MySQL versions then perhaps that should also appear in other appliances that use Apache and MySQL? So whilst i like it, I'm still not convinced that any significant change is needed (perhaps making the version number more obvious?)

Carl Kiendl's picture

I would list what's significant. If you're offering a LAMP-appliance, advertising it to contain Linux, Apache, MySQL and (PHP|Python|Perl), then the inclined user is going to ask one simple question: Which versions of Linux, Apache, MySQL and (PHP|Python|Perl) does this appliance contain?

Because it does make a difference whether it's Apache 2.2 or 2.4, MySQL 4 or 5, PHP 5.0 or 5.2. These are not marginal details provided for beancounters and nerds: These are important decision-making criteria for or against an appliance. In the case of Dokuwiki, for example, we ultimately decided that running the appliance with the ancient version and painfully updating the package-installation through third party repos was just not worth it. We took the LAMP appliance and installed Dokuwiki traditionally instead. (Your suggestion, btw - thank you!)

With Joomla, obviously, the 1.x or 2.x information is important. For the typical Ruby-based appliance, I'd include the payload's version and the versions of direct dependencies, e.g. Ruby's itself.

It's a simple question of "if I were trying to gauge how current the application I'm trying to run is as provided by this appliance, what version numbers would I look at?".

And the truth is: The matter is more complex than "it's based on TKL Core 12!". When I decided whether to install the LAMP appliance or not, I didn't go "oh, it's based on Core 12, alright!", I clicked through and checked the actual versions of the LAMP stack, because that's what's interesting to me when I'm about to install a LAMP server.

Abstracting the versions away works as long as the package is current and there's no big issue. As soon as there are feature differences between versions or security holes only fixed in up-to-date packages, the payload versions become critically important - and keeping them out of sight isn't helping anyone.

Jeremy Davis's picture

And personally I agree with your point about Core version (although knowng that the appliances are Debian based might be important to some...)

But I am a little torn on your ultimate point. Whilst I think that it may be a value to state the version of the 'important' software included I somewhat disagree with your last paragraph...

Security holes are rarely an issue with Debian packages from the 'stable' repos (regardless of whether they are an 'old' version or not). Generally the most stable and secure environment is when using the Debian stable packages (with security updates). I have even seen an 'old' version Debian repo package receive a security patch before inclusion in the stable release of the upstream software!

A significant factor behind the devs choice to move from an Ubuntu base to a Debian one is the fact that Debian includes security backported patches for ALL of it's packages (Ubuntu only backports security patches to 'important' packages i.e. those included in the 'main' repo). Once you install software to TKL from upstream, unless the software has some sort of internal updating mechanism, using the 'up-to-date' software reduces security and increases maintenance overhead! (You lose daily auto security patches of that software). Beyond features (and compatability with newer plugins) the most secure and stable version is the ('old') version from the repos!

This point is often lost on newbs (particularly Windows users...) as many have been trained to believe that old versions are 'bad' (have security issues) and the new version is always best... Sure on my laptop I want the latest software with all the new whizbang features (and bugs - although I don't actually want those!:D) so I run Debian testing with the unstable and experimental repos enabled (but pinned obviously). But on my servers I want security, stability and low maintenance overheads (although sometimes I want the new features too - but it's always a trade-off that requires significant consideration IMO). Perhaps if you want to use the software internally (offline e.g. intranet) then the tradeoff is not so bad, but generally there has to be a significant argument for the features in the 'new' version before I'd include the upstream software in a server I am administering.

So whilst I don't think the version should be hidden, having it 'in your face' may be counter productive for new comers (i.e. turn them off TKL before they understand this point)?

But where my counter argument breaks down is when the software in TKL appliances comes from upstream... We then have a situation that end users may not be aware of the implications that they have a responsibility to keep the software up to date to maintain security. This is a point that the Core devs have recognised and are working on some way of making it easier to keep upstream software updated (I'm yet to see what this will be...)

So maybe something like this would work?:

TKL Core version: 12.0
Software version: 0.0.20091225c-10+squeeze2
Why this version?
[link to explanation]
Software source: upstream repository 
What this means? {link to explanation]
Additional software: apache2, mysql-server

(the bits in square brackets are explanation, not intended to be included...)

Carl Kiendl's picture

I understand where you're coming from, but I believe you are assuming a situation where you are still close to the "sweet spot" - the feature differences between debian stable custom package version and actual software stable version are minor, and the codebase is close enough to backport security issues.

Reality, however, isn't as pretty as that. Look at the Debian changelog of the stable dokuwiki package. The last change was on June 29, 2011. It's still using the Lemming branch. Since then, the project released the Anteater, Rincewind, Angua and Adora Belle branches, with Weatherwax in RC. Can you imagine that backporting security fixes to Lemming isn't a priority to them anymore?

The truth about backporting is that it has an expiration date: At a certain point, your ancient codebase is so out of sync and outdated that you'd have to maintain it as a completely separate software project. That's not feasible, so the backports just stop. As they did with Dokuwiki.

So while I appreciate the Debian projects' efforts to maintain the security of their distribution, the basic assumption that "it's from Debian stable" equals "it's secure" is a dangerous one.
I've mentioned the old Linux joke before: Debian comes in three editions: Stale, rusty and ancient. Personally, my association with the phrase "Debian packages" is not "secure" but "outdated". And that's problematic not just on the security front, but also on the feature side of things.

Not only are features a big part of end user satisfaction and efficiency, there are also feature upgrades for administrators and developers. Having an outdated API makes development pointless - why develop if you know it's not going to run on the current version and will break with the next update?
More important, however, are the administrative features and changes. Great example right now is the GitLab appliance: I'm trying to establish git as the company's source control of choice here. I'd like to install a GitLab instance to make adjustment easier for everyone. Naturally, my first choice would've been TKL, but TKL's GitLab-version is at 2.5. Even if you update the hell out of it, the latest versions you're going to get are 4.x; 5.0 is current by now, and has significantly changed the underlying architecture of the software, meaning different and easier administration for the sysadmin. If I know the current version has fewer dependencies and is easier to administrate, why on Earth would I want to install an outdated version?

Mind that the linked repository is the one linked to in GitLab documentation; it's an unsupported third party repo, so the whole "it's from Debian stable, so it's secure" mantra doesn't apply in the first place. The official installation guide propagates a whole shitload of manual work on Debian, including self-compilation of Ruby.

I understand where you're coming from, with the focus on server stability and coherence. In theory, it's a good approach to server administration. It works if you're testing your software yourself, and then compile and install your own binaries. But reality looks different. As long as you're relying on outdated, unmaintained packages, backported or not, you're no safer than somebody installing the latest versions. And the latest versions at least include fixes for all known security issues. (At least with a good project.)


Conclusively, while do I see your point, personally, I can't agree with it, and don't consider the Debian project's ancient backports and repo versions valuable enough to be stuck with them.
Therefore, knowing what I'm stuck with in advance is a big part of deciding for or against an appliance for me.

Since your suggestion for the block includes all information I included (as far as I can see), I see no issue with it. :)

Jeremy Davis's picture

Sorry for slow reply. Been getting to this for ages...

All security updates are handled by the Debian Security team (not the Debian package maintainer). Debian Security team commit to maintaining security backports for the life of the distro (i.e. from stable release until 12mths after the next stable release). And generally they are pretty quick. The other thing Debian do, is they have a Security Audit team which actually spend their days trying to find security bugs (that aren't yet known). So sometimes it is actually the Debian team that find the secutiy bug in the first place! Sometimes they even devise the fix (or at least a fix) and on occasion packages with the fixed security bug appear in Debian before the upstream software has even released a security bugfix version! Read more about Debian's take on security here

Anyway, security updates don't generally go in the 'normal' main repo, but into a separate 'security' repo. I assume that's why the package changelog doesn't reflect all the security updates (I'm guessing that it only shows updates to the package in the 'main' repo, not the security one), because they aren't applied to that package, a new package is uploaded to security (with a minor increment so as it overrules the package in main). TBH I'm not sure why there have been some updated DokuWiki packages uploaded to the main repo post stable release, but no doubt there is some reason and/or rule that allows it to a point (perhaps prior to the Debian point release?).

If you look on the security tracker for DokuWiki and compare it to the security bugs listed against DokuWiki (and here - not sure why DokuWiki is split into 2 pages? Perhaps it has been forked? Or change of dev team?)... Anyway, if you compare them you can see that pretty much all the security bugs have been patched (with exception of a couple - IMO reltively minor as they only allow display of info about the server and as long as you aren't relying on security by obscurity are not biggies). Unfortunately the Debian security page for each app isn't laid out all that well IMO) and you can't at a glance see when they were applied, but the info is there if you want to go digging. There is also the package patch tracker which contains info about the patches applied to the package.

Also if you are particulrly interested in Security then you can sign up to the Security Team mailing list and see the conversations in real time. Also if there is a bug that you are aware of that isn't fixed and you want to know when or if or why it isn't then you can ask there!

I won't argue your point about additional features, but like all things in life any choice we make is always a trade off. Debian have decided to trade rock solid stability, with security into an OS that requires little maintenance - against having the latest features and versions. Is it a reasonable trade? For me and my servers I'd say most times, with most software, without a doubt! Is it always good enough? Mostly but sometimes not... Especially with newer released software that is under heavy development - often it isn't even close to good enough... And that's where your point about the GitLab appliance is really relevant. As there is no official Debian package (and if there was it would almost not be unrecognisable in comparision anyway) as you suggest the whole thing somewhat falls down. But what is the answer? TBH I don't think that there is an easy one that  

But that's where TKL community can come in (soon!). With the new build and release mechanism that the core devs are madly working on (but will hopefully release real soon), community members can upgrade appliance software and share with others to their hearts content. Will it be perfect? Probably not, but it's a huge step in the right direction IMO. So if you wish to have a DokuWiki appliance that has a much later version, then you'll be able to have that and share it with all other TKL users! The overall plan is to get people to adopt maintenance of appliances. Then the devs will be able to focus on infrastructure more and just release 'official' updated version occasionaly (drawing from what the community is doing as appropriate). 

As for my use of Debian on my laptop... No I don't run 'stable'. Currently I run a base of 'testing' (Wheezy - actually gone stable today!) mixed with packages from 'unstable' and 'experimental' too! Now Wheezy is 'stable' I'll probably stick with a Wheezy base for now but probably get more and more packages from 'testing' as time goes on...

Carl Kiendl's picture

While I will acknowledge that, from a security point of view, the debian version is not as bad as it could have been, I only find my opinion strengthened: Even in the "new" wheezy, the security page gives the current debian version of dokuwiki as 0.0.20120125b-2 - that's 2012-01-25b “Angua”, the most recent version of dokuwiki listed in the "old versions" section. Which starts off with the note "These releases are no longer recommended for usage and are listed for reference only."

In other words: The latest version of dokuwiki in the brand new release of debian is so old, that the project does not recommend using it anymore.

Yes, Angua was the last release marked as containing a security fix. So by applying the metric of "no unpatched published security issues", it is a safe version. But does that make it a reasonable version?
By applying the very same logic, 2012-10-13 “Adora Belle” is also a safe version: There are no unpatched published security issues.

If you use the number of known, unpatched security issues as a metric, the latest stable version of dokuwiki is 100% as secure as the 15-month-old version current with debian. But unlike Debian's ancient version, it contains several dozen additional bugfixes as well as new features and architectural improvements.

My point is: You are talking about secure software as if the fact that all known, glaring security issues have been fixed makes an ancient version of a software equal to the current version in security. For one, that is simply not the case - the latest stable of dokuwiki, for example, includes changes to the password reset mechanism, Active Directory integration and ACLs, all improving the authentication and authorization structure of the application. The current RC replaces the blowfish encryption library, because it creates inconsistent results across platforms.
Secondly and more importantly, however, the entire core argumentation of "this is more suitable for a server because it's a known stable version with all known security holes fixed" falls apart when one realizes that the latest stable version has the same patch level and is the one not deprecated by the project. Or, to phrase it differently: If, by the same metric, both versions are equally secure, but one of them is labeled "no longer recommended for usage" by the people who should know best, that is not the one one should put on his server for production use.

And all of this happens in the makebelief world of "all exploits are known" anyway. The reality is that the truly dangerous security issues are the ones not known to the project developers or the system administrators. And for protection against unknown issues, I prefer the security architecture that has seen 15 months of additional scrutiny, development and improvement, not the one the project has already deprecated.


As said before: I understand where you're coming from. I know the argumentation. I just think it's more legend than reality.
Earlier in the discussion, you said

Beyond features (and compatability with newer plugins) the most secure and stable version is the ('old') version from the repos!
This point is often lost on newbs (particularly Windows users...) as many have been trained to believe that old versions are 'bad' (have security issues) and the new version is always best...

to be frank, I think you're showing the reverse side of the indoctrination here. Just like the generic Windows user assumes the latest version of a software is always the best, without ever questioning that, you're automatically assuming the latest version will be less stable and less secure, and an old, "time-tested" version will be the better choice - without ever questioning that.

The Windows newb has faith in the application's developer.
You have faith in the debian security team.

It's the same approach, just a different deity.

You and/or the debian project are equalizing "new version" with "new bugs" and "new features", and thus not necessarily relevant to production use.
I equalize "new version" with "fixed bugs" and "improved architecture", and thus very relevant to production use.
The truth probably lies in the middle.
But no matter what the truth is, I do believe you, too, can agree that knowing what version one installs on a server is important: Be it to ensure the software is reliably ancient or to ascertain it was developed in this decade, one has to know what version it is.

And that information, that full disclosure, is what we were originally discussing.

Even if you disagree with my reasons for wanting to know at a quick glance what versions are deployed with a TKL appliance, can you agree that making it easier and more intuitive for the potential administrator to see what versions the appliance includes would be a good thing?

Your argument against an "in your face" listing was that seeing the older versions might turn off new users who don't understand the "ancient == stable" paradigm. I understand that concern. But can you truly say that conning them into installing the appliance by keeping the versions quasi-hidden is a better approach?

How many possible scenarios for that are there?

  • The user sees no versions,  doesn't care, installs the appliance, and is happy.
  • The user sees no versions, assumes it'll be the latest, installs the appliance, and is pissed off.
  • The user sees no versions, wants to know them, doesn't find them, and is pissed off.
  • The user sees no versions, wants to know them, finds them, and is happy.
  • The user sees no versions, wants to know them, finds them, and is turned off.
  • The user sees the versions, doesn't care, installs the appliance, and is happy
  • The user sees the versions, does care, installs the appliance, and is happy.
  • The user sees the versions, does care, and is turned off by what he sees.

The latter is the case you're fearing. But what you'll notice is that that is the only case where the numbers are visible that ends in sadness. All people not caring or satisfied with the versions are fine with seeing them. On the flip side, when the versions are hidden, both the people who do and don't want the latest version in their appliance are pissed off by how it is artificially made harder to get the info they want - reasonable, important information for a server installation.

You are essentially trading the happiness of seasoned administrators for the blissful ignorance of the newbs. And for what? If they never see the version they're installing, and they have no issues in production, they will never learn the lecture you are hoping to teach - they never learn they're running an old version and that that's somehow better, because it just works.

When would those who did not see the version they were installing care about it later? Only when there are problems. When features are missing that the project's page promised, when bugs are occurring that the project's forums claim are fixed. And then the sudden realization: This POS came with an ancient version!! What do they learn? Check the versions, or you might get some ancient shit that ruins your day.

Once again, the sysadmin lesson is not taught.

Sure, you can try to convince them that the deployed version is better, but how likely is it they'll agree, after the reason they noticed is that the installed version made them unhappy?

You will not teach lessons by conning people into installing something they wouldn't have wanted to install or by pissing them off later on.

Yes, telling people up front "this is not the latest version" might turn a few of them off. But it also ensures that those who do install the appliance know what they're doing, have the correct expectations, and understand the situation when there are problems in production.


How about listing the versions and placing a "learn why this version is better than the latest version" link next to it?
A bit of a polemic phrasing, but it should catch the potentially-turned-off-user's attention long enough for you to have a chance to convince him installing a four-year-old version of dokuwiki might somehow be a smart idea. ;)





Edit: On an entirely different note, the partial/pseudo-threading of this software is really annoying. If there's a commenting interface under the latest comment, I expect to be replying to that, not open a thread inside a thread. -_-
Also, unless I'm blind, the WYSIWYG interface doesn't have buttons to change the font size. (Or color, for that matter.)

Jeremy Davis's picture

I haven't got time for a proper reply, but just wanted to say that I've read your post and whilst I still disagree with some of what you say, I think I get your perspective more clearly and you do put forward some good arguments. I appreciate you taking the time to put them down and some time soon I will try to respond more fully as I think it deserves.

Bottom line though is that I agree with your sentiments about perhaps the best way would be listing the versons of the 'important' software with a linking explanation as you suggest - interestingly the same idea occurred to me as I was reading (before I got to the bit where you made that point) so perhaps that's something we can agree on! :)

And yeah the default Drupal forum module (I'm pretty sure that's what this is) is a bit sucky isn't it... Yeah and you're right, it has the different styles, but not simple explicit font, size or colour...

Add new comment