On Thu, Feb 12, 2009, Les Mikesell wrote:
>Bill Campbell wrote:
>>
>>>>
>>>>> locate rpmsave
>>>>> locate rpmnew
>>>> rpmsave is left from *un*installations, rpmnew is the *new* file, there is
>>>> no file overwritten. rpm usually doesn't overwrite files if they got
>>>> changed.
>>> AFAIK this is not correct, a package upgrade can create either of these
>>> (or both, or neither of them despite your having edited a file). And
>>> that's the way it should be, either choice can be justified.
>>> It depends on the package's SPEC file. rpm just does what it's told,
>>> everything is in the hands of the package maintainer.
>>
>> I think that the only time a .rpmnew file is created is if the
>> SPEC file specifies ``%config(noreplace)'' for a file. If the
>> ``noreplace'' option is not used, the .rpmsave files are created
>> either when a package is removed, or when a file specified as a
>> configuration file in the RPM SPEC file is updated and the file
>> is sufficiently different from the default (for some definition
>> of suffieiently).
>>
>> In the OpenPKG portable packaging system, which is RPM based, the
>> presence of any .rpmnew or .rpmsave configuration files will
>> prevent a package from starting, and warning messages will be
>> generated until the situation is resolved.
>
>That sounds like the kiss of death for any critical service. Can't it
>figure out ahead of time that this is going to happen and let the
>service keep running unchanged with a warning message about needing the
>update instead?
This has not proven a problem as we monitor updates, and generally know
which packages may generate the rpmsave or rpmnew files as a result of
testing on development machines before deploying to production systems.
We have an administrative script that monitors the status of all servers
running under our OpenPKG system, and quickly indicates anything that is
not running while doing updates. In addition, our systems all check
critical services under cron control, attempt to restart services that are
not running, and notifying our support system via direct SMTP (bypassing
postfix, amavisd, and clamv in case one of them is down) and with xmlrpc
calls to our support servers as well. Our systems keep track of systems
that are supposed to check in, and generate alerts when one or more miss
checkins.
Nothing is perfect of course, but this has worked well for us for almost 10
years now.
Bill
--
INTERNET: bill@xxxxxxxxxxxxx Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
Voice: (206) 236-1676 Mercer Island, WA 98040-0820
Fax: (206) 232-9186
Most people, sometime in their lives, stumble across truth. Most jump
up, brush themselves off, and hurry on about their business as if
nothing had happened. - Sir Winston Churchill
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
