On Mon, Dec 05, 2005 at 11:44:22AM +1300, Steve Wray wrote: > Matthew Palmer wrote: > >On Mon, Dec 05, 2005 at 09:07:42AM +1300, Steve Wray wrote: > > > >>Matthew Palmer wrote: > [snip] > >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. > > Actually I often find that packages will have debconf entries that none > of their maintainer scripts use. > > Alternatively, there may be config things you want to do that arn't > covered by the maintainer script. > > Or even cases where the maintainer scripts will totally ignore debconf > if there is existing configuration file content.
These are all arguments in favour of "ignore debconf and do all the config in cfengine". > In these cases, its well worth producing a 'wrapper' package which > depends on the base debian package and which does its own thing with > debconf. This, in general, seems like a hell of a lot more effort than just managing the config files using copy. It also is very, very Debian-specific -- the moment you have to start managing a couple of RHEL servers (don't laugh, it happens) this technique doesn't work at all. (I think it's far more likely that you'll need to manage disparate systems instead of using disparate management systems on the same infrastructure). > For example, the cfengine bootstrapping problem; I have a cfengine-local > package which contains my base cfengine starter pack. That's one package that I've got in my infrastructures; nothing more than a localised base update.conf and friends, and a dependency on cfengine2 (>= 2.1.15)). That's fairly easy to build an RPM for (modulo a sensible dependency resolution); building your entire debconf-based wrapper package system to manage some RHEL boxes is going to be pain (and something that other people in your team are likely to have a *lot* more trouble keeping on top of). > apt-get install cfengine-local gets it ready for its first cfengine update. > > Its actually relatively easy to do this sort of thing, though you > wouldn't think so from reading Debians own documentation... ??? Building debian packages isn't hard, and there's no shortage of documentation on how to do so. > http://cfwiki.org/cfwiki/index.php/Editfiles_Considered_Harmful Nice page. Definitely worth reading. It does ignore a part of cfengine's intended use case, though -- the idea of "immunilogical computing", where the system brings itself into line with some described baseline. That is where I think editfiles can be useful. However, editfiles doesn't do nearly well enough to make this use case practical in the general case. It's also not what most users want from their management tool. - Matt _______________________________________________ Help-cfengine mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-cfengine
