Description of problem: After automatic updates of freeradius2-ldap, new configuration files get created next to current ones with a .rpmnew suffix. For example there would be 2 files for ldap module: /etc/raddb/modules/ldap /etc/raddb/modules/ldap.rpmnew Unfortunately, as radiusd parses all files in /etc/raddb/modules/, both files get parsed (in alphabetical order I guess) so the working ldap configuration is overwritten by the .rpmnew one. This breaks authentication after a radiusd service restart. Version-Release number of selected component (if applicable): freeradius2-ldap.x86_64 2.1.12-3.el5 How reproducible: Easily. Steps to Reproduce: 1. create a second config file /etc/raddb/modules/ldap.rpmnew 2. put wrong parameters in it 3. restart radiusd Actual results: Wrong parameters from /etc/raddb/modules/ldap.rpmnew are used. Expected results: Good parameters from /etc/raddb/modules/ldap are used. Additional info: I think we can generalize this problem to all module config files in freeradius2 package. The solution might be either to skip .rpmnew files while parsing module configs, or to move these files outside of /etc/raddb/modules/.
I appreciate the difficulty this presents and recognize it's not ideal. The problem arises because of two pieces of software with long histories that are in conflict with one another. RPM creates .rpmnew and .rpmsave files and has for years. Our packaging guidelines specify that configuration files enable the creation of these files during package upgrade. It's a long existing standard. On the other hand FreeRADIUS has a long history of reading every file in the config area, apparently Apache has similar behaviour. However, there are simple solutions, such as using a different configuration directory, the issue is discussed in this recent thread. http://lists.freeradius.org/pipermail/freeradius-users/2012-March/059185.html Should we change the FreeRADIUS RPM's to not create these files in violation of our packaging policies? I'm not inclined to do that because of the following: * It's not not .rpmnew and .rpmsave files that create the problem, any superfluous file will create the problem. If you use Emacs to edit one of the config files (e.g. foo) and it leaves a foo~ or #foo# backup file (very easy to do) you'll have the same issue. If you copy a config file to foo.bak before editing it you'll have the same problem, another very common thing for admins to do. So if just preventing the creation of .rpmnew and .rpmsave files would fix this I'd be inclined to remove the RPM behaviour but in reality all it would do is just push the problem in a slightly different direction, not eliminate it while at the same time losing the advantage of RPM configuration file management. * FreeRADIUS recognizes this as a problem (not just because of RPM, folks have been burned by this in lots of other ways, some of which I alluded to above) and the next major release will use a different strategy. The 2.x series of FreeRADIUS is coming to a close shortly, there won't be that many more RPM updates of FreeRADIUS 2.x. * As an administrator you're supposed to check for the presence of .rpmnew and .rpmsave files after a package install. They're there for a reason, in part to make you aware of configuration changes and provide a mechanism to recover from them if necessary. * There is a simple workaround for the issue as described in the mail thread. For these reasons I'm going to close this bug. However if you feel strongly to the contrary and do not think the justifications provided are valid or sufficient you may reopen the bug and we can pursue this further.