Re: Bundling .debs with their debconf data
See http://www.infrastructures.org/papers/turing/turing.html. A
particular piece of debconf data is specific to the version of that
package on that machine at that time -- it is not sitewide, or even
host-class-wide. Debconf data changes really ought to be advanced in
step with the versions of packages to which they pertain. This means
that sitewide distribution of most debconf data (via LDAP or anything
else) doesn't appear to be a good idea. The only things that seem to
make sense to put in LDAP are transient, environment-specific
information, like server locations.
To give you a practical idea of what I mean, I'd be curious to see the
results of this from each of your machines:
(dpkg -l; cat /var/cache/debconf/config.dat) | md5sum
I'm wondering if you'll find that you have close to 120 different
machines, as unique as snowflakes, rather than 3-4 different software
configurations. Some of this difference would be due to debconf
management issues, and some might be due to FAI's default behavior of
downloading the latest version of whatever it finds on the archive
servers during initial install -- the same FAI configuration will
produce different machines on different days.
It's *possible* that in your case you have totally identical machines
within classes -- one way to get that would be to re-install them all
since you took that most recent woody snapshot, while never changing
the content of your snapshot. A frequent 'apt-get update && apt-get
dist-upgrade' would help avoid the latter requirement, but that brings
up all sorts of production test and change control issues. And it
still doesn't solve many of the debconf data management problems.
The debconf data really needs to be encapsulated with the packages in
order to get provably repeatable rebuilds across a whole set of hosts.
Provable repeatability is important for production management, for
test vs. production syncing, and gets really important for DR ability
-- you want the hosts at your recovery site to rebuild in *exactly*
the same way; in case of a major disaster you'll have more important
things to worry about.
Steve
On Tue, Jan 14, 2003 at 09:49:33AM +0100, Matthieu Delahaye wrote:
> We are managing around 120 computers under Debian, first with an
> unstable snapshot made between potato and woody, and now woody.
> They are not all of the same type (let say 4 different models),
> with 3-4 different software configurations.
> All the installation process is managed by FAI [1] (available on Woody) and
> is good enough for our needs. And perhaps for yours.
> The main problem we had and that is not solved by the solution proposed
> above is about packages which are not using debconf. Exim is an example.
> About distributing debconf data, you may use an LDAP backend.
> We didn't test it but IMHO instead of copying the whole data, just configure
> debconf seems better.
>
> Matthieu Delahaye
>
> [1]: http://www.informatik.uni-koeln.de/fai/
> > I think what I'd do if I were to maintain a cluster:
> >
> > create a local debian repository, with a local 'beta' and 'final'
> > distribution (like testing and stable, but I think it's better not to
> > use those names).
> >
> > The test machine(s) obviously point to beta, the cluster to final. So,
> > every new package would be put into beta, where it could be tested and
> > then it would be propagated into final (totally manual process. Could be
> > semi-automated by syncing beta to (for instance) Debian stable+security
> > on a regular basis).
> >
> > The only remaining problem would then be distributing debconf data. I'm
> > not familiar enough with that to have a proposal here, but I'm sure you
> > can come up with something.
> >
> > A cron job on all production machines would then look like:
> > - sync debconf db with master
> > - apt-get update && apt-get dist-upgrade
> >
> > (Hmmm. this does only cover installed pkgs. So a way to make sure new
> > packages are installed is required, too. But, since I would only expect
> > to-be-installed packages in the local 'final' repository, this is easy.
> > grep the Packages file and install everything available).
> >
> > cheers
> > -- vbi
> >
> > --
> > this email is protected by a digital signature: http://fortytwo.ch/gpg
>
>
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
Stephen G. Traugott
UNIX/Linux Infrastructure Architect, TerraLuna LLC
stevegt@TerraLuna.Org
http://www.stevegt.com
Reply to: