Jonathan Gazeley <jonathan.gaze...@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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html