On Sat, Jun 21, 2003 at 12:21:17PM +0200, Michael van Elst wrote: >On Fri, Jun 20, 2003, Martin Andrews wrote: > >> I'll add my vote to Bill's side. I use cfengine to roll out my configuration files >> and then install software and (re)start services. I found it really annoying that >> installing postfix overwrote my configuration files. If it does that during an >> update too it is very bad. > >rpm does a "best effort". > >When the default configuration doesn't change, the user configuration >is kept as is, because it is unlikely that it will conflict with the >new version of the software. > >When the default configuration does change, it is installed and the >user configuration is saved as .rpmsave. When the default changes >one can assume that the user config needs change as well and simply >keeping it might cause problems as well. Just think about an unsafe >default that the user had simply copied into his configuration.
Well designed programs (e.g. postfix) generally change their configuration files so they don't break existing systems, adding new features rather than changing old ones. I'm a firm believer in the ``principle of least surprise'', and replacing configuration files can cause some nasty surprised. Changing configuration files in the middle of a ``openpkg buill -Ua'' sorta negates the utility of the automation process. >If you want always to keep the user configuration _as is_ you assume >that the user configuration is "perfect" and always the right thing. >I have strong doubts that this is a safe assumption. > >You are right that the default configuration often isn't usuable >for a production system and installing a default configuration is >likeley to interrupt services. But I believe you already have the >right answer to this problem: use a configuration management system >like cfengine. When upgrading a system, cfengine could stop and >disable the affected services, do the upgrade and verify configurations >(it should not simply override what is there). When all is well it >can enable and start the services again. I'm not familiar with cfengine. We use a somewhat more primitive method of checking all configuration directories in under CVS (using a hack I made to cvs to allow root checkins if the CVS_BADROOT environment variable is set). >What I'd like to add to the OpenPKG system is some internal safety. >Like my suggestion to auto-disable services that have .rpmsave'd >configurations. There needs to be some special handling For those few programs where the new configuration files are mandatory, preferably one that permits the admin to prepare the new configuration files in advance of doing the update, then putting them in place during ``%post'' processing. Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC UUCP: camco!bill PO Box 820; 6641 E. Mercer Way FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 URL: http://www.celestial.com/ When I hear a man applauded by the mob I always feel a pang of pity for him. All he has to do to be hissed is to live long enough. -- H.L. Mencken, ``Minority Report'' ______________________________________________________________________ The OpenPKG Project www.openpkg.org Developer Communication List [EMAIL PROTECTED]
