RHEL Patches Broke FreeRADIUS
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". 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. 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? I'd like to tackle this from the FreeRADIUS side rather than by reconfiguring rpm because I can think of other reasons why some idio^H^H^H^H well-meaning admin might stick a test file in there without realizing that it causes problems. Switching to a site-specific module name (or some other method that allows FR to ignore the "extra" files) would prevent any such scenario. Thx! --J
McNutt, Justin M. wrote:
I'd like to tackle this from the FreeRADIUS side rather than by reconfiguring rpm because I can think of other reasons why some idio^H^H^H^H well-meaning admin might stick a test file in there without realizing that it causes problems. Switching to a site-specific module name (or some other method that allows FR to ignore the "extra" files) would prevent any such scenario.
The "modules" directory is just a convention. It can be changed. Instead, put the modules into raddb/missouri/ :) Change radiusd.conf to edit $INCLUDE modules/ to missouri/ And the problem will go away. Alan DeKok.
... *facepalm* Yeah, that'd do it. Much easier than what I was doing. Thanks, Alan. :) --J From: Alan DeKok <aland@deployingradius.com<mailto:aland@deployingradius.com>> Reply-To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org<mailto:freeradius-users@lists.freeradius.org>> Date: Sat, 3 Mar 2012 09:14:31 +0100 To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org<mailto:freeradius-users@lists.freeradius.org>> Subject: Re: RHEL Patches Broke FreeRADIUS McNutt, Justin M. wrote: I'd like to tackle this from the FreeRADIUS side rather than by reconfiguring rpm because I can think of other reasons why some idio^H^H^H^H well-meaning admin might stick a test file in there without realizing that it causes problems. Switching to a site-specific module name (or some other method that allows FR to ignore the "extra" files) would prevent any such scenario. The "modules" directory is just a convention. It can be changed. Instead, put the modules into raddb/missouri/ :) Change radiusd.conf to edit $INCLUDE modules/ to missouri/ And the problem will go away. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Fri, Mar 2, 2012 at 7:49 PM, McNutt, Justin M. <McNuttJ@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
On Fri, Mar 02, 2012 at 12:49:33PM +0000, McNutt, Justin M. wrote:
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. ... Ideas?
I put my entire configuration (the whole raddb directory) in /srv/radius, and then start FR with '-d /srv/radius'. Then when I upgrade, I know it's not going to touch my config. I also have a convenient distribution config in /etc/freeradius to refer to, with all associated comments, etc. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On Fri, Mar 2, 2012 at 7:49 PM, McNutt, Justin M. <McNuttJ@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.
Is this on RHEL5? If yes, I HIGHLY suggest you look at /etc/logorotate.d/radiusd. I just check freeradius2-2.1.12-3.el5.i386.rpm, and it doesn't do a reload, which means you either: - will be missing logs (since the one with the open handle is deleted), OR - have an old logfile (e.g. radius.log.3) that will continue to grow Fedora should have the fix since freeradius-2.1.11-2 (http://freeradius.1045715.n5.nabble.com/Version-2-1-11-has-been-released-td4...), while RHEL6 would probably have the fix in freeradius-2.1.12-1.el6 when it's out (https://bugzilla.redhat.com/show_bug.cgi?id=705723). If you have redhat support I suggest you open a support ticket. -- Fajar
participants (4)
-
Alan DeKok -
Fajar A. Nugraha -
Matthew Newton -
McNutt, Justin M.