On Fri, Mar 2, 2012 at 7:49 PM, McNutt, Justin M. <mcnu...@missouri.edu> wrote:
> So my server admins did what they're supposed to do and ran "yum update" on
> everything last weekend. The updates included a refresh of the "freeradius2"
> packages that took FR from 2.1.7 to 2.1.12.
>
> That's all fine and dandy, except that what rpm does when it has config files
> that are part of a package - like /etc/raddb/modules/ldap - and those config
> files exist on your system already AND those config files have changed, is
> that it renames the new one to "blah.rpmnew".
Yup.
It's not really RHEL's fault though. It's a combination on 2.1.x
default behavior (including all files in modules/ directory) and how
RPM works when it detects a config file has changed (*.rpmsave or
*.rpmnew)
>
> This created a nasty problem. Now I have an /etc/raddb/modules/ldap and an
> /etc/raddb/modules/ldap.rpmnew, both of which define how "ldap { }" is
> supposed to work. Same thing happened to the mschap module.
This has been discussed on -devel list. That's why 3.0 (from git
master branch) uses raddb/mods-available and mods-enabled by default.
>
> SO...
>
> The way I avoided this problem in the $RADDB/certs and $RADDB/sites-available
> directories is that I'm not using the default filenames in the first place.
> My certs are not named "ca.pem" and "server.pem" and so on. I'm not using
> the "default" or "inner-tunnel" virtual server definitions. I copied them to
> site-specific names and used THOSE, so I get the benefit of the sanity of the
> built-in virtual server definitions (not to mention an unsullied copy for
> contrast), but rpm doesn't screw me up.
>
> The $RADDB/modules directory doesn't seem to work that way. I can't just do
> "cp ldap ldap-site" and call "ldap-site" from my virtual server instead of
> "ldap". I also can't leave it the way it is (stock) because rpm is going to
> come along and put another "ldap.rpmnew" file in there. I can't "not patch"
> FR because my predecessor went down that road and that's why he's not in
> charge of the RADIUS servers any more.
>
> Ideas?
Like Alan said, you can change what directory gets included.
My testing ppa for Ubuntu does something like this:
- create a new symlink from raddb/modules to raddb/mods-available (so
that it's similar to 3.0-style)
- create a new directory, raddb/mods-enabled
- create symlinks of modules you use (or just everything that doesn't
end with ".rpm*", if you're not sure)
- change radiusd.conf to include mods-enabled instead of modules
You should be able to apply those changes manually. Future updates
will not overwrite it.
--
Fajar
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
