Jeremy Davis's picture

Just thinking out loud really... sorry for the essay...

Personally I like the idea of having a 'master server' with all the individual appliances installed as VMs (modules) that interact with one another and fulfill all the functions/roles I want from my server, but each still be (somewhat) independant of the others. That's why I love Proxmox so much. Not to mention OpenVZ performance being nothing short of incredible! (No noticable difference from bare metal, other than from full system reboot).

Anyway, I digress... it just occured to me that maybe you could consider some way of using downloadable install scripts and/or TKL installation/upgrade (.deb) packages for the different appliances. Perhaps this could mean that users could have an easy path to 'roll their own' all-in-one servers. I guess from a production/Dev perspective this could be a nightmare. But for some users (especially those running VMs under Windows and the performance hit they suffer) it could reduce the overall system footprint (ie having one VM rather than 3 or 4).I guess I'm thinking somewhat along the lines of eBox, but without all the bloat and slugginess.

I still consider myself a Linux noob but your recent releases got me thinking about upgrading my own servers (all of which are based on OpenVZ templates that I made from TKL, many of them Core) and how painful it will be to upgrade them all. Not that I need to, they all work fine! I just want to play with your new offerings and be a part of the action!

Whilst I think that major releases (that require a fresh .iso, etc) are a good thing, the ability to 'upgrade' my TKL 2009.02 based VMs to TKL 2009.10 would be very nice (rather than having to start again from scratch)

.... Anyway just a thought. Keep up the good work guys and I can't wait to have some time to get my hands dirty with all these new appliances I just downloaded. Its like Christmas come early! I'll let you know how I go.

Liraz Siri's picture

I love the idea of a master VM ala Proxmox with modules. That could be extremely powerful and I would very much like to work on that when we get a bit of breathing space.

Regarding upgrading appliances via script / package, we've given that some thought and while it would be possible to hack something together it's technically problematic to try to do that.

The reason is that a TurnKey Linux appliance is pretty much a standard Ubuntu system under the hood. We give users a better starting point by doing all of the preconfiguration but we don't prevent them from modifying / customizing an appliance to fit their needs. Since it's impossible to anticipate all the possible ways in which an appliance has changed since installation it's dangerous to try and change the configuration automatically in place.

Rather than trying to upgrade in-place, a technically safer solution is to try and separate the system from the data it works on and then provide a migration mechanism so users that are interested could move their data from one appliance version to another and re-apply any tweaks they made to the old system, if necessary.

Of course, as always, the devil is in the details.

PS: Your "essays" provide us some of the best feedback we've received from the community. Keep it coming!

tom12010's picture

I think this is a definite necessity. I even made a poll about it. :)

Jeremy Davis's picture

I have just posted my vision of a TKL VE on the Dev wiki. I can't remember by LaunchPad login so I can't put up a blueprint at the moment but I will endeavour to do it sometime soon. I may put up a poll at some point too to guage what level of interest there is in this idea. I am tempted to start work on this but as I am not much of a programer I'll have to rob a lot of stuff from Proxmox VE (lucky its open source!) and play with that. There is an (unsupported) installer for Debian Lenny, not sure how'd that'd go installed on TKL as I know Ubuntu and Debian repos aren't really compatible (although many individual packages are).

Liraz Siri's picture

I've had good experience getting individual Debian packages to install just fine on Ubuntu. When that fails, rebuilding the package on Ubuntu from the deb package's source (e.g., with dpkg-buildpackage) often works. When it doesn't, the required tweak to the source package is usually minor, except when long chains of dependencies come into play such as when a package depends on a specific version of a development framework (e.g., KDE, JDK, Gnome).

Worst case scenario you just install the tools from a source tarball into /usr/local and later when everything is working you can look into creating a new Debian package.

Add new comment