.rpmnew files during RPM upgrade

[Phil Mayers]

Jonathan Gazeley <jonathan.gazeley at bristol.ac.uk> wrote:

>I rolled and deployed an RPM of FreeRADIUS 2.2.0. As expected for RPM 
>packages, it left a number of *.rpmnew files in /etc/raddb.
>
>Trouble is, FreeRADIUS reads these files as live configs and was unable
>
>to start after the upgrade, until I had manually intervened and deleted
>
>the .rpmnew files.
>
>This isn't a new issue, I found this old thread in the archive:
>
>http://lists.freeradius.org/pipermail/freeradius-users/2008-December/033694.html
>
>It seems to me that the "broken" behaviour is not with RPM but with 
>FreeRADIUS. Can the regular expression that includes config files and 
>modules be tweaked to exclude *.rpmnew files? It would be nice if an 
>automated package management system didn't require manual intervention 
>to ensure that a critical service keeps running upon upgrade.
>
>If I hadn't rolled my own RPM, I would eventually have received an 
>overnight update from CentOS, and my RADIUS servers would have remained
>
>broken until the morning. That's something I'd rather avoid, and 
>something a lot of other admins would run into as well.
>
>I don't really know much C but I looked at the source code.
>Blacklisting 
>specific file suffixes seems like a bad way to do it, but I suppose
>it's 
>too late now to insist that all config files end with .conf. Any other 
>ideas?
>
>Thanks,
>Jonathan
>-
>List info/subscribe/unsubscribe? See
>http://www.freeradius.org/list/users.html

Change the modules directory to a locally-managed one:

$INCLUDE modules-active/

...and symlink from there to the files in the rpm-managed directory, or edit locally as needed.

Also, don't do unattended patching of critical services I.e. don't let centos / rhel touch your freeradius rpm without manual confirmation. This is just a bad idea on all counts based on my unfortunate personal experiences.
-- 
Sent from my phone. Please excuse brevity and typos.