[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openpkg-dev
Subject:    Re: Suggestions for build standards
From:       Bill Campbell <bill () celestial ! com>
Date:       2003-06-21 17:59:31
[Download RAW message or body]

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:   bill@Celestial.COM  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                   openpkg-dev@openpkg.org


[prev in list] [next in list] [prev in thread] [next in thread]