.rpmnew files during RPM upgrade
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.... 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
Jonathan Gazeley <jonathan.gazeley@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....
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.
On 11/09/12 12:16, Phil Mayers wrote:
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.
(In more length now that I'm back at my desk) This approach of a separate available/enabled modules dir is the default approach in the MASTER branch (to be 3.x): https://github.com/alandekok/freeradius-server/blob/master/raddb/radiusd.con... I don't think blacklisting specific extensions in the conffile.c source is helpful, personally. It's "magic" and hardcoded lists are a pain - what seems reasonable to one person can be annoying to another. You could possibly extend the syntax to be a glob e.g. $INCLUDE mods/*.mod ...but the default would need to stay as-is in the 2.x branch for backwards compatibility. Possibly you could persuade people to change all the $INCLUDE'ed files to have relevant extensions e.g. modules/mschap.mod sites-enabled/inner-tunnel.vserver ...but they seem like "noise" to me. I like the separate dir / symlink approach.
-----Original Message----- On 11/09/12 12:16, Phil Mayers wrote:
This approach of a separate available/enabled modules dir is the default approach in the MASTER branch (to be 3.x)
Would redhat packaging policy allow the package scripts to instead create e.g. modules.rpmnew/ and stuff its files under there instead? (My hopes aren't high.)
I don't think blacklisting specific extensions in the conffile.c source is helpful, personally. It's "magic" and hardcoded lists are a pain - what seems reasonable to one person can be annoying to another.
Sounds like the job of a main config file directive, e.g. ignore_suffixes= That way it could appear right before the INCLUDE line in the configuration file so it's right out there in the open. Not that I'm volunteering :-)
On 09/11/2012 04:37 PM, Brian Julin wrote:
-----Original Message----- On 11/09/12 12:16, Phil Mayers wrote:
This approach of a separate available/enabled modules dir is the default approach in the MASTER branch (to be 3.x)
Would redhat packaging policy allow the package scripts to instead create e.g. modules.rpmnew/ and stuff its files under there instead? (My hopes aren't high.)
I guess I don't see how this is qualitatively different than having RPM put the modules into modules-available/ then include&symlink to modules-enabled/ Well, not true; I think the latter solution is *superior*. But sure - you can use %postinstall tricks to make RPM do anything. Since the OP said he "rolled and deployed" the RPM himself, I don't see why the solution isn't: %postinstall find /etc/raddb -name \*.rpmnew -exec rm -f {} \; We adopt another solution - our local RPM puts the included /etc/raddb into /usr/share/doc/<name>/raddb for reference, and doesn't touch /etc/raddb (which we manage from SVN).
Sounds like the job of a main config file directive, e.g. ignore_suffixes=
Shrug. Sounds like a job for proper config directory management to me! We don't have this problem - never have. We use various solutions - config in SVN, local package builds without confg files, cfengine "tidy" actions to manage package post-installs, never let something upgrade critical packages unattended, etc.
That way it could appear right before the INCLUDE line in the configuration file so it's right out there in the open.
Well, config is hierarchial, so "immediately preceding" has problems. This: modules { ignore_suffixes=*.rpmnew $INCLUDE modules/ } ignore_suffixes=*.rpmnew *~ $INCLUDE sites-enabled/ ...is harder to implement. Best you can sensibly manage without undue confusion is probably a top-level global. It's not a feature I'd ever use, so as long as there isn't some hard-coded source "skip" list I don't care!
On 09/11/2012 07:42 AM, Alan DeKok wrote:
Jonathan Gazeley wrote:
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?
As always, patches are welcome.
O.K. I did just that. The freeradius-2.2.0 RPM's I've been pushing now includes a patch to ignore config filenames that should be excluded from being loaded. I'll send the patch to the developers list via a github pull request. The list is hardcoded, at the moment it excludes: Any basename beginning with a dot (.) Any basename beginning with a hash (i.e. pound sign, octothorp) (#) Any basename ending with a tilde (~) Any basename ending with the substring ".rpmsave" Any basename ending with the substring ".rpmnew" Any basename ending with the substring ".bak" It also logs any files it skips which is really handy information to know (including files that previously were skipped for reasons like invalid characters in the filename). -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
On Wed, Oct 10, 2012 at 5:39 AM, John Dennis <jdennis@redhat.com> wrote:
On 09/11/2012 07:42 AM, Alan DeKok wrote:
Jonathan Gazeley wrote:
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?
As always, patches are welcome.
O.K. I did just that. The freeradius-2.2.0 RPM's I've been pushing now includes a patch to ignore config filenames that should be excluded from being loaded. I'll send the patch to the developers list via a github pull request. The list is hardcoded, at the moment it excludes:
Any basename beginning with a dot (.) Any basename beginning with a hash (i.e. pound sign, octothorp) (#) Any basename ending with a tilde (~) Any basename ending with the substring ".rpmsave" Any basename ending with the substring ".rpmnew" Any basename ending with the substring ".bak"
Can you please add ".dpkg-new", ".dpkg-dist", and ".dpkg-old" as well? Thanks -- Fajar
On 10/09/2012 08:57 PM, Fajar A. Nugraha wrote:
On Wed, Oct 10, 2012 at 5:39 AM, John Dennis <jdennis@redhat.com> wrote:
On 09/11/2012 07:42 AM, Alan DeKok wrote:
Jonathan Gazeley wrote:
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?
As always, patches are welcome.
O.K. I did just that. The freeradius-2.2.0 RPM's I've been pushing now includes a patch to ignore config filenames that should be excluded from being loaded. I'll send the patch to the developers list via a github pull request. The list is hardcoded, at the moment it excludes:
Any basename beginning with a dot (.) Any basename beginning with a hash (i.e. pound sign, octothorp) (#) Any basename ending with a tilde (~) Any basename ending with the substring ".rpmsave" Any basename ending with the substring ".rpmnew" Any basename ending with the substring ".bak"
Can you please add ".dpkg-new", ".dpkg-dist", and ".dpkg-old" as well?
Sure, no problem, done. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
participants (6)
-
Alan DeKok -
Brian Julin -
Fajar A. Nugraha -
John Dennis -
Jonathan Gazeley -
Phil Mayers