TurnKey Linux's take on Ubuntu appliance development: KISS

[Alon Swartz]

Soren Hansen wrote:
> On Tue, Nov 17, 2009 at 06:33:22PM +0200, Alon Swartz wrote:
>> TurnKey Linux has created 40 Ubuntu-based appliances so far and has
>> many more in the works. 
> 
> The list certainly looks very impressive. Good job!
> 
>> Our approach to appliance development is a bit different then those
>> that have been discussed in the mailing list so far. We are strong
>> believers in keeping everything as simple as possible. KISS and all
>> that. Debian packages were never really designed for this sort of
>> thing and trying to force them into that role raises the bar by making
>> things overly complicated.
> 
> Could you elaborate on this a little bit? Lots of different ideas have
> been tossed back and forth on various mailing lists, IRC and other fora,
> so I'm not completely sure what you mean Debian packages were not
> designed for.

What this means is that Debian packages were never designed for
system-level integration. They're meant to be building blocks for a
system administrator who then glues them together to integrate a
production solution. An appliance is all about removing that last step.
We're not competing with or displacing packages. We're just gluing them
together to give the user a better starting point. The means selecting
the components, configuring / integrating them to work together to
provide the desired solution, and last but not least, testing the final
result as a single unit.

There's no elegant way to do that with packages / meta-packages
precisely because they're not designed for this sort of thing. For
example, according to the Debian Policy Manual a package is not allowed
to edit configuration files of other packages.

>> Incidentally, we've given some thought to getting the community more
>> involved with appliance development and recently released TKLPatch, a
>> simple way to customize and extend any appliance in the TurnKey Linux
>> virtual appliance library. However the mechanism is really extremely
>> simple and the approach (or something like it) should work for
>> non-TurnKey appliances.
>>
>> Documentation: http://www.turnkeylinux.org/docs/tklpatch
>> Source code: http://github.com/turnkeylinux/tklpatch
> 
> This is an interesting approach. However, we've traditionally been very
> careful about keeping any logic about and customisations for packages
> inside the packages themselves, rather than allowing external programs
> go in and make changes to the contents and behaviour of packages.

Just to clear up any potential confusion, tklpatch isn't intended to
patch packages or package contents. It's intended to patch the appliance
by for example installing additional packages, changing the
configuration of an existing package, installing adhoc scripts to
/usr/local, etc.

We love packages, but an appliance is a higher-level concept and it's
important to understand that.

> Can you give a few examples of things you've patched this way and why
> those changes were needed?  That way, it's easier to discuss how it
> perhaps could be done using different mechanics.

Note that every appliance has a list of its configuration and its
documentation on the web site. The most amount of detail is available in
the changelog, also on the web site.

For example, let's compare the LAMP stack with the MySQL appliance. The
MySQL appliance is intended to be used as a standalone database so you
have lighttpd instead of Apache. Accessing http://your.appliance.ip/
redirects you to https://your.appliance.ip/ where brings you directly to
the phpmyadmin interface. MySQL listens on a network-reachable port and
is configured by default to accept connections from any host (though we
do recommend users limit incoming connections to specific hosts).

OTOH, the LAMP stack appliance has a different usage scenario, so the
database is bound to localhost for enhanced security. We're using Apache
instead of lighttpd because it has better webmin support and is more
familiar to developers. PhpMyAdmin is configured to listen on
https://your.appliance.ip:12322/ which makes it easy to block that port
on your firewall (local iptables firewall or a network firewall). For
convenience, if you point your browser to http://your.appliance.ip/ a
temporary startup page gives you links to the appliance's web interfaces
(e.g., AJAX web shell, webmin and PhpMyAdmin), and gives you access to
Apache PHP information (phpinfo), Apache server status page and a link
to the TurnKey LAMP release notes.

LAMP stack and the MySQL appliance have very similar components, but
different usage scenarios and hence - different configurations.

If you try to do this sort of thing with packages you are going to
either fail or be forced to add a tremendous amount of unnecessary
complexity at the package level.

The TKLPatch approach is much simpler and more elegant.

>> BTW, we're building out TurnKey Linux as a specialized extension of
>> the Ubuntu community that focuses on appliance development. Some
>> people confuse the project for a fork, but if you take a look at an
>> appliance under the hood you'll see it is pretty much a standard
>> installation of Ubuntu that has been customized for a particular usage
>> scenario. We just give users a better starting point. Like Ubuntu,
>> TurnKey Linux is 100% open source.
> 
> I would love to see more convergence of the two projects, both in terms
> of development efforts, branding, release cycle, release processes, etc.

Amen. So would we. If we could better leverage Ubuntu's community and
marketing clout we could make better appliances and reach and help so
many more users! Tighter cooperation and official recognition from
Ubuntu would give TurnKey a big push I think. The project has been
growing by leaps and bounds on its own, but I'm pretty sure we could
take that to the next level.

>> Anyhow, we've invested a ton of effort into figuring out all of the
>> issues and we'd like to invite any one interested in appliance
>> development to collaborate with us. Reinventing the wheel is such a
>> poor use of the community's resources.
> 
> I agree, you guys clearly have thought a lot of these things through
> already, and it would be silly not to leverage your expertise. If we, in
> return, could help you guys utilise some of the more traditional methods
> for customising applications and applying patches of various sort, that
> would be a big win for both sides, I think.

Definitely. Improved collaboration would be a huge win for both sides.
For example, we depend on Ubuntu and Debian for security updates to all
of the components in the appliances. Whenever a package is not supported
in Ubuntu or worse, doesn't even exist as a Debian package, that makes
it much more difficult to create and maintain appliances.

Originally we only made appliances out of supported components, but
eventually we hit a wall because there is quite a bit of excellent
software that is either not supported by Ubuntu or not packaged by
Debian and that has forced us to settle for creating appliances with
components which users will need to maintain themselves (as opposed to
being able to support automatic security updates and such).

We don't have the resources to package all of this software ourselves in
our own repositories, so we've done that only for very popular software
packages such as Joomla. This sort of thing can add a huge amount of
overhead to our work and prevents us from focusing on what we do best:
identifying usage scenarios we can solve with open source software,
selecting the best components, gluing them together and testing the hell
out of it both internally and with the help of the community make a
truly turn-key solution that will live up to the "TurnKey" name.