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

Re: debconf and cluster management

I'm not on this list, but I wouldn't mind if the rest of this thread was
cc'd to me. I've been reading it in the archives.

A few comments..

Marcelo E. Magallon:
> The basic idea is that you configure a machine using the interactive
> front-end, store the configuration on a remote location and then
> configure the rest of the machines using the non-interactive front-end.
> Then you get spammed with tons of mails telling you how hundreds of
> machines where configured the same way :-)

Of course you can turn those mails off. More to the point, if you have a
distributed db set up and multiple machines are using it, debconf will
send each note a maximum of *one* time for the whole set.

Matthew Palmer:
> I think you misunderstood what I was after.  I know the non-interactive
> front-end, and it's what gets used at present.  What I wanted was some way
> to say 'OK, ask me the questions from these packages and then give me the
> debconf data (stored in some remote database, preferably) to use on other
> machines - but without screwing with the config the local machine.'

This is very very difficult, and unlikely. Curently you'll need one spare
machine to do the initial install/upgrade on.

You can preconfigure everything w/o touching the machine you run the
preconfigure on, but that's only like 90% of the questions. The other
10% are harder to deal with.

Marcelo E. Magallon:
> nice trick: store the configuration with an id an have a
> "snapshot" table, in other words, all the configurations with a given
> id are time-coherent.  Then you could *theoretically* roll back the
> configuration.  It's just an idea and I made it up on the spot, but
> sounds neat if it could be implemented.

Neat idea, I dunno if the various packages that use debconf would
support it. Maybe you'd have to reconfigure them all or something.

Martin Quinson:
> And how about cluster-wide dpkg-reconfigure?  :)

Well, dpkg-reconfigure currently refuses to let you use it in
noninteractive mode because that tended to confuse people that had
noninteractive set as their default frontend. But I see no reason why I
couldn't make dpkg-reconfigure --frontend=noninteractive work agaim.
Then you just need a wrapper that runs it once with a real frontend, and
remotely execs it on every node in noninteractive mode.

Martin Quinson:
>   At the Debian miniconference in Brisbane it was reported that most
> packages *are* using debconf.  I don't think I believe that, but I might buy
> that most packages with interactive configuration are using debconf now.  At
> the moment, of 3023 packages in my available file, the string debconf
> appears only 179 times.  Shortly before debconf was first released I scanned
> all my *.postinst for "read", and found that only about 10% had interactive
> scripts, and many (most?) of those were wrapped in conditionals and not
> normally executed.  At the moment, "read " appears in only 66 of the
> postinsts of the 2359 packages installed on this machine.  Interactive
> postinsts seem to be an even smaller minority today,

You should note that it's easy to use debconf w/o "debconf" appearing in
the binary package. It's better to look for packages that have a
templates file. I count 431 packages using debconf today, via a complete
grep of the archive. Graph at: http://auric.debian.org/~joeyh/debconf-stats/

>  and in many cases
> probably really should stop and ask the sysadmin ("should I reinitialize
> your postgresql database, or would you like to dump it out first?").

That's not an excuse for not using debconf.

> Most of the interaction I get these days is just deciding whether to
> overwrite modified config files.  Solve just that and Debian would be quite
> cluster friendly in even fully managed node layouts.

The best tool to deal with that so far is --force-confnew and

see shy jo

Reply to: