Re: cfengine, debconf and ldap

[Matthew Palmer]

[No need to Cc me, I'm subscribed]

On Mon, Dec 05, 2005 at 09:07:42AM +1300, Steve Wray wrote:
> Matthew Palmer wrote:
> >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 :)
> [snip]
> >>
> >>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.
> 
> Setting the environment variable on the commandline seems to work 
> reasonably well for dpkg operations, but I have found that in apt-get 
> operations it sometimes doesn't seem to be passed 'down the chain'.
> 
> In other words in:
> DEBIAN_FRONTEND=noninteractive apt-get install foo bar baz
> 
> the install of package foo will get the environment variable but not bar 
> or baz. I'm not sure but it could be a problem with the maintainer scripts.

Try installing the failing packages directly using dpkg..  If the package
doesn't fail then, there's some sort of really nasty bug in APT, since that
environment variable is *really* supposed to pass-through.  Perhaps try
" export DEBIAN_FRONTEND=...; apt-get ..." instead, but I'd consider it
apt's "duty" to make sure that environment var goes through.

> Still, this is *kind* of getting off topic for the cfengine list :)

Quite likely.  I'll continue this discussion off-list or on a more
appropriate list if anyone wants to continue.

> >>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,
> 
> it sure helps to shut the installer up

Some degree of debconf preseeding is necessary to make the installer quiet,
but practically speaking that's no different to Kickstart config files.

> and help to get the initial install of a package to be sane.

Define "sane".  Unless you can get the config exactly as you need using the
Debconf questions (not a common experience) you need to copy/editfiles your
way to where you want to be anyway.

> >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 disagree... copy is fine but editfiles, for anything non-trivial is 
> not so good.

So only use editfiles for the trivial things then... <grin>

> With editfiles, you are left gesticulating at the editfile stanza and 
> saying something like 'if the sshd_config was like it was supposed to 
> have been then when this editfiles ran it should have changed it in 
> *this* way'
> 
> I'd rather keep version-controlled copies of the config file under, say, 
> svn on a central server and distribute the changes with copy. Thats what 
> I am doing with the package selection states. This way I can tell 
> exactly what package selection list was in force a month ago.

Ayup, keeping everything under revision control is great.  I'm a bit up in
the air about when to editfiles and when to copy.  I can espouse at length
about my varying opinions, if you need to get to sleep sometime, and I'm
sure that anyone who's maintaining a cfengine infrastructure will know all
of the ideas already.

- Matt

-- 
Sure, it's possible to write C in an object-oriented way.  But, in practice,
getting an entire team to do that is like telling them to walk along a
straight line painted on the floor, with the lights off.
                -- Tess Snider, slug-chat@slug.org.au