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
--force-confold.
--
see shy jo
Reply to: