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