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
