Thibault Le Meur wrote:

T I've searched and finally found out what occured. I'm using Fedora Core 9 and after the FR package update here is what occured: a lot of files including module files from the new RPM package were added as /etc/raddb/modules/<modulename>.rpmnew So at startup here is what is loaded: ... including configuration file /etc/raddb/modules/pap.rpmnew ... including configuration file /etc/raddb/modules/pap ...

Most of my setup was working because I use specific instance of the modules such as "ldap-mycompany" and not the default "ldap" name. However, I use the std name for the pap module... I may change this in the future to avoid such issues after upgrade.

I don't know if I should report this to the package maintainer or not. What do you think ?

I'm here :-) The files under /etc/raddb/modules are configuration files. Configuration files by definition are available for editing. It is usually considered bad practice for rpm during an upgrade to overwrite user modified configuration files. If rpm thinks a configuration file has been modified instead of overwriting the configuration file with the version from the new package it instead lays a new copy of that file down with the .rpmnew extension. It's your job as a system administrator to pay attention to the presence of .rpmnew files, during installation it will warn you such files were created which is your signal to investigate. If you miss the warnings you should still periodically check under /etc for the presence of .rpmnew files and .rpmsave by the same token. Now having said that, it's entirely possible there is a packaging problem and the .rpmnew files should not have been created, I'll go off and take a look at that issue. My recollection is that rpm is smart enough to detect the case where the old version of a config file differs from the new version but the old version was not locally edited. I believe this is case you're describing. In this instance rpm should replace the config files and not generate a .rpmnew. Did you edit the pap config file in any manner? -- John Dennis <jdennis@redhat.com>

Hi John,

Nice to meet you ;-)

John Dennis a écrit :
> John Dennis wrote:
>> Thibault Le Meur wrote:
>>> T
>>> I've searched and finally found out what occured. I'm using Fedora 
>>> Core 9 and after the FR package update here is what occured: a lot 
>>> of files including module files from the new RPM package were added 
>>> as /etc/raddb/modules/<modulename>.rpmnew
>>> So at startup here is what is loaded:
>>> ...
>>> including configuration file /etc/raddb/modules/pap.rpmnew
>>> ...
>>> including configuration file /etc/raddb/modules/pap
>>> ...
>>>
>>> I don't know if I should report this to the package maintainer or not.
>>> What do you think ?
>>
>> I'm here :-)
>>
>> The files under /etc/raddb/modules are configuration files. 
>> Configuration files by definition are available for editing. It is 
>> usually considered bad practice for rpm during an upgrade to 
>> overwrite user modified configuration files.
I agree ;-)


>> If rpm thinks a configuration file has been modified instead of 
>> overwriting the configuration file with the version from the new 
>> package it instead lays a new copy of that file down with the .rpmnew 
>> extension.
I understand, and this runs great _for most other softwares because the 
xxx.rpmnew files are not read_ by the application at startup:
* the applications are correctly updated,
* the configuration files that were customized by the system 
administrator are not overwritten and are still read at the application 
startup,
* _usually_ the updated applications are working well, despite having 
old configuration files. This is because new configuration files usually 
have new optional parameters (for which a default value is assumed by 
the application).

However, as far as FR is concerned, all files in /etc/raddb/modules/ 
matching the regex /[a-zA-Z0-9_.]+/ are read, this includes any 
xxx.rpmnew file: In fact adding an xxx.rpmnew file in /etc/raddb/modules 
has the same effect as to modify the configuration files !
This will cause most Freeradius 2.x upgrades (using RPM) to end up with 
an updated server which is not working anymore

>> It's your job as a system administrator to pay attention to the 
>> presence of .rpmnew files, during installation it will warn you such 
>> files were created which is your signal to investigate.
This may mean that automatic updates of FR should be disabled by default 
in the OS, maybe in /etc/yum.conf for Fedora ?

>> If you miss the warnings you should still periodically check under 
>> /etc for the presence of .rpmnew files and .rpmsave by the same token.
No need to do this: I've been warned immediately by my users that the 
network access wasn't possible anymore ;-)

>>
>> Now having said that, it's entirely possible there is a packaging 
>> problem and the .rpmnew files should not have been created, I'll go 
>> off and take a look at that issue. My recollection is that rpm is 
>> smart enough to detect the case where the old version of a config 
>> file differs from the new version but the old version was not locally 
>> edited. I believe this is case you're describing.
No, I've modified the old configuration file, the problem is that the 
.rpmnew files is read by the server at startup and thus this overwrites 
my old customizations.

>>
> I've looked at the packaging with respect to how the .rpmnew files are 
> being handled and I believe everything is correct. What is probably 
> missing is documentation on this so I've updated the FreeRADIUS Red 
> Hat FAQ (http://wiki.freeradius.org/Red_Hat_FAQ) and added a section 
> describing what happens to configuration files during a RPM upgrade 
> (http://wiki.freeradius.org/Red_Hat_FAQ#How_are_configuration_files_handled_during_an_RPM_upgrade.3F) 
>
Thanks this is very valuable.
Maybe 'we' should add a specific paragraph concerning /etc/raddb/modules 
configuration .rpmnew files as they are read by FR at startup?
Do you want me to do so?


Regards,
Thibault