help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cfengine, debconf and ldap


From: Matthew Palmer
Subject: Re: cfengine, debconf and ldap
Date: Sat, 3 Dec 2005 11:26:54 +1100
User-agent: Mutt/1.5.9i

On Fri, Dec 02, 2005 at 12:03:03PM -0600, Brendan Strejcek wrote:
> Steve Wray wrote:
> 
> > debconf is set up to query these databases and to *try* not to be
> > interactive (sometimes this seems a lot harder than it should be :)
> >
> > cfengine takes care of the package installation with a
> > dselect-upgrade. The package selection state list for each host is
> > maintained on the cfserver this list is (currently) manually updated
> > by the sysadmin and then a cfrun command issued; the client pulls down
> > its latest selection states, runs a dpkg --set-selections from it and
> > then performs an apt-get dselect-upgrade. Debconf gets its answers
> > directly from the central LDAP database.
> 
> I solved this problem using the sledgehammer method: get dpkg, apt-get,
> debconf, etc to just shut up and install the package with defaults (if
> you set enough --force-yes, DEBIAN_FRONTEND=noninteractive, etc, options
> it is possible to get it to actually be noninteractive).

Any package that asks questions or otherwise interrupts installation when
"DEBIAN_FRONTEND=noninteractive" is buggy.  Report a bug, and if you want to
send me the bug number and I'll try and help get the problem fixed.  I'm
quite keen on seeing Debian packages install cleanly in a non-interactive
manner.

> Then I use copy, editfiles, and other cfengine actions to do any
> configuration I need.

I'll second that, from an insiders point of view.  Debconf is *not* a
registry; it is not intended, designed, or supposed to record every possible
configuration value in a package.  It is merely there to provide a basic,
usable default configuration.  As a result, you're going to have to get very
comfy with copy and editfiles to customise your infrastructure anyway; the
amount of assistance that Debconf pre-seeding is going to give you is fairly
minimal in the grand scheme of things.

> I think the Debian package tools were really optimized for single-user
> use, not infrastructures.

It's not that the Debian tools aren't optimized for infrastructures, so much
as that it is impossible to get 1000 cats (Debian Developers) to write
complete config file parser/rewriters for over 10,000 source packages, in
such a way that all local modifications (including comments) are preserved,
that work flawlessly all the time, and which are consistent across the
entire distribution.

Personally, I think it's a problem that no distribution has solved
completely, at least without completely castrating the edit-the-config-file
style of systems administration with custom management tools (hello SuSE)
which then, of course, means that the moment a program provides a feature
you want to use that isn't covered in the automated config tool, you're dead
in the water.

- Matt




reply via email to

[Prev in Thread] Current Thread [Next in Thread]