Educational v Production appliances

Iván Carrasco's picture

Hi all

I was wondering how are you guys developing the appliances. I'm not asking about tech details, but about how are you installing the sensible packages of the appliance. apt-get or manual installation?

The question is not just curiosity, but to know how are we focusing the appliances. Each approach has its own benefits and drawbacks imho:

- Apt-get: BENEFITS: Easy installation, configuration & upgrade. DRAWBACKS: Due the easy upgradable facility, it might get upgrades when we don't want to upgrade at all.

- Manual: BENEFITS: The packages will be always in the same state, unless we really mean to change them. DRAWBACKS: Not as straigthforward installation and configuration, as we more likely will have to compile the packages. Also manual tunning is involved.

IMO each approach has its own target: Apt-get installations are quite good for testing, playing around, and get used to and X appliance, but OOTB production appliances, should be installed manually.

When i mean Manual installed i don't mean the whole appliance, but just the special packages of an appliance

Eg: A LAMP production appliance should involve manual installation of Apache, MySQL and PHP, as some upgrades to those packages might mean some future errors in the code when upgrading (features no longer available, API's changes, etc). But for a testing or "educational" appliance, apt-get installation would be fine, and eases the support at all.

What are your views on this one guys? I was wondering this, as in my system i always emerge (gentoo) everything, except the specific packages (JDK, Apache, Tomcat, JBoss, Mysql, etc etc) that i manually install for the reasons above, and i was about to start developing an appliance (apache + geronimo or glassfish + mysql) and i wanted to know the project's standards.


Alon Swartz's picture

If I understand correctly, the issue at hand is not package installation, but rather package upgrades.

From the auto-security updates documentation:
TurnKey software appliance are configured to auto-update
daily with the latest security patches.

Usually automatically updating software is considered to be
a risky practice since updates may occasionally break
existing functionality (e.g., changes to file formats,
software interfaces, or expected behavior).

Ubuntu and Debian mitigate this risk by carefully backporting 
security fixes so that security updates change as little as
possible, minimizing the likelyhood that things will break.

In practice we've found it is very rare for an Ubuntu 
security update to break something, so we believe it is 
beneficial to configure software appliances to auto-update 
security fixes by default. Advanced users can always disable
this mechanism and apply security fixes manually if they want.
In Debian based systems there are 2 main methods for influencing package policy:

The first is to hold packages back from not being upgraded, for example:
add hold:    echo PACKAGE_NAME hold | dpkg --set-selections
remove hold: echo PACKAGE_NAME install | dpkg --set-selections

The second is pinning, which we use, for example to prioritize our package repository for the packages we have customized over those available in Ubuntu.
See /etc/apt/preferences and man apt_preferences for more details.

I hope this answers your question.
Iván Carrasco's picture


In that case is the user himself who has to set the packages he wants as 'hold' in order to avoid upgrades. It adds flexibility to the user letting them to pick an 'stable' (meaning not upgradable) appliance, or an auto-updatable one. I'll take a look on this issue




Liraz Siri's picture

Ivan, TurnKey appliances are configured such that only security updates are applied automatically. You don't have to worry about your appliance pulling the rug from under you by updating to new package versions that include functional changes or new features.

Allowing production servers to auto-upgrade security fixes from trusted repositories is something you generally want, which is why we've set it as the default behavior.

There are a few expert scenarios where you really do want to turn off automatic security upgrades and do it manually (e.g., compiling and installing a kernel module that relies on a specific binary kernel), but that can add a tremendous amount of overhead to your administration duties, so you usually want to avoid it.

Post new comment