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