Re: .rpmnew files during RPM upgrade
On 10/09/2012 08:57 PM, Fajar A. Nugraha wrote: On Wed, Oct 10, 2012 at 5:39 AM, John Dennis 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 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: .rpmnew files during RPM upgrade
On Wed, Oct 10, 2012 at 5:39 AM, John Dennis 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: .rpmnew files during RPM upgrade
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 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: .rpmnew files during RPM upgrade
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//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!
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: .rpmnew files during RPM upgrade
> -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 :-) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: .rpmnew files during RPM upgrade
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.conf.in#L760 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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: .rpmnew files during RPM upgrade
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. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: .rpmnew files during RPM upgrade
Jonathan Gazeley 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
.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.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
