RHEL Patches Broke FreeRADIUS

[Fajar A. Nugraha]

On Fri, Mar 2, 2012 at 7:49 PM, McNutt, Justin M. <McNuttJ at 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