3.0 (master) build error

Fajar A. Nugraha list at fajar.net
Tue Jan 10 08:46:59 CET 2012

On Tue, Jan 10, 2012 at 1:49 PM, Stefan Winter <stefan.winter at restena.lu> wrote:
> Hi,
>> by the server. This might be a problem in the following scenarios:
>> - user install FR3 package (e.g. rpm/deb)
>> - user modifies modules/sql or modules/eap
>> - user upgrades FR3 package, and since the two files changed, new
>> files will be created (e.g.  modules/sql.rpmnew or
>> modules/sql.dpkg-new)
>> - both files (e.g. modules/sql and modules/sql.rpmnew) is included and
>> parsed by the server, and both define the same module instance. This
>> might mean the wrong instance is used, or at minimum create a
>> confusion.
>> What is the recommended way to solve this problem? Should packagers
>> warn users "don't edit any file in modules/*, instead copy to a new
>> file and assign new instance name"?
> Isn't that the exact same issue that all other modules/* files have,
> also now in 2.x? Say, I edited modules/detail.log because I don't like
> the default paths.

Correct. However, in v2.x several commonly-edited modules was not
located in modules/, but rather as files under raddb directly (e.g.
eap.conf, sql.conf, sqlipool.conf). If they edit those files (which,
most of the time they must, to get it to work), the extra
.rpmnew/.dpkg-new files wont matter because they won't be read.

> Same thing is going to happen. IMHO, the creation of .rpmnew files is to
> blame in this case. RPM shouldn't do that.

AFAIK neither rpm or deb has the option to say "this is a config file.
If this file changed, don't write anything, not even a .*new file"

> Not that I mind; installing from source is the way to go anyway :-)

Packages makes it easier to manage many servers :)

I'm thinking one of these options would make sense:
(1) Do it like sites-available and sites-enabled. That is, have a
directory (e.g. modules-enabled) which simply contains symlinks to
files in modules directory. Easy enough for packagers to implement by
themselves without changing upstream source
(2) Force users "don't edit any file in modules/*, instead copy to a
new file and assign new instance name".
(3) Modify FR code so that it blacklists several extensions, like
logrotate does via "tabooext" directive.


More information about the Freeradius-Devel mailing list