Authenticating groups via LDAP

John Dennis jdennis at
Sat May 22 19:45:59 CEST 2010

On 05/22/2010 12:32 PM, Alan DeKok wrote:
> John Dennis wrote:
>> Alan I didn't see any open bugs on this, should we open one? Is this a
>> planned modification for 2.2?
>    Yes.
>> I recall some discussion of this a while
>> back on the mailing list. I suppose changing this is 2.1 would be a
>> version violation. But it has such serious negative consequences I
>> wonder if we shouldn't bite the bullet and change it in 2.1.9 before
>> more people get bitten by this. But to be honest I'm not sure which is
>> worse, an unexpected config file change on upgrade or mysterious
>> *silent* failures after upgrade.
>    I'd make the change in 2.1.10, if at all.  It's a relatively rare
> problem compared to other issues seen regularly on the list.
>> I think the RPM spec file (and the deb files) could include a script
>> which would detect the an old modules directory layout and convert it to
>> modules-{available,enabled} layout automatically during a package upgrade.
>    Sure...
>> Also, I was just looking at our RPM spec file and I noticed that files
>> in /etc/raddb/sites-enabled (which should just be symlinks) are marked
>> as config(noreplace) which means RPM will leave backup files there
>> instead of treating sites-enabled as just a collection of symlinks to be
>> left alone. I think this represents a packaging bug on my end. However I
>> noticed the suse freeradius.spec file in the freeradius-server tarballs
>> also have the exact same config(noreplace) in raddb/sites-enabled so
>> that packaging bug seems universal.
>    Sure.  Not everyone uses symlinks in sites-enabled.  Some put files
> there directly.

Well, if that's the case then the current practice of reading every file 
found in the directory won't work. Why? Because many package managers 
leave backup files behind for configuration files. Then there is also 
the issue of editor backup files (e.g. the ~ files from emacs). When 
this issue originally came up I thought I recalled the argument was 
rather than renaming all the config files to have a common extension and 
only loading those files with extension the correct extension the 
preferred model would be to utilize enabled,available directories. The 
filenames would stay the same as would the practice of loading every 
file in the enabled directory. But the enabled directory would contain 
only symlinks. However that would still probably leave the problem of 
editor back up files and the naive admin who might copy a file (which 
invisibly would be a symlink) to a backup name.

Bottom line: I think the practice of loading every file found in a 
directory is inherently risky and bug prone. I think it should only load 
files with a specific extension, that seems much safer. This still works 
nicely with the enabled/available split.

John Dennis <jdennis at>

Looking to carve out IT costs?

More information about the Freeradius-Users mailing list