[Debconf-devel] Distribution of debconf configuration

[mnaumann at gmx.de]

Hi,

I originally sent this email to Joey Hess last week but have not since 
received a response - which is not a problem other than I still have not 
been able to solve the problem I'm running into. So I'm extending the 
audience to your mailing list, hoping you may be able to hit me with the 
clue stick.

I have several questions regarding debconf which I have been unable to
find answers to. I'm now sending email to you directly hoping you may
provide some further insight. If you do not wish to respond to
commercial 'support requests' then please just state so. I will not
consider this impolite or inadequate and will not bug you further.

I work for a company developing email encryption solutions. One of the 
products is an appliance, a set of hardware and preconfigured software
(running on Debian GNU/Linux (currently 4.0)) which allows you to use
the software without having to deal with the linux console.

Right now, I'm working on a project which is supposed to preconfigure,
in a central location, all Debian packages and distribute their
(debconf) configurations to the clients' appliances where they should be
used to non-interactively configure packages which are being updated.
Basically, we plan to have one central system here and make all the
appliances use the same debconf configuration (they also have the same
packages installed as our 'master' system).

We have already created a web frontend and some BASH script backend to
that which allows for installing updates from our APT repositories.
However, we have not yet found a way to make the appliances actually use
the configuration we provide in a way that they actually use the
configuration we ship to them when they install package upgrades.

Our attempt to achieve this consisted of the fllowing steps:

* on the central 'template' server, do a dist-upgrade, answering all
debconf questions manually.

* Package the debconf config database of the 'template' server

* On the appliances ('clients'), first install this config database as
the main debconf config database, then run a dist-upgrade (with a
non-interactive frontend) to install any updates

* updated packages should now use the values found in the debconf config
database we provide to them to non-interactively respond to any
debconf-questions, meaning we will have the same package configuration
(as far as debconf configures those packages) we have on the template
server, once the upgrade is complete.


Aside from the last step, this works pretty well. However, unfortunately
it seems like debconf uses the default answers (which I think are stored
in the packages' configuration or the template database - I'm not
entirely sure about this) instead of those we have stored in the debconf
config databse that is installed (replacing the previous debconf config
databse) before the dist-upgrade takes place. As a result, once the
dist-upgrade is complete, we have differently (debconf) configured
package installations on the template server on the one hand, and the
appliances on the other hand.

Since this did not work, we tried several other approaches, which
included setting and removing the 'Seen' flag for packages, using a
primary and secondary debconf database etc. But nothing really worked
out so far.

By now I assume our approach is incorrect and instead of the replacing
the debconf config database, we should 'debconf-get > somefile' the
configuration on the template server and 'debconf-set < somefile' on the
 appliances. But at this point I don't really expect that this will
sufficiently fix the problem of those pre-configurations being ignored
on package upgrades.

Can you provide some hints on how we could best achieve this deployment
of centrally preconfigured package configurations?

Thank you very much in advance.

Moritz
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger