LDAP Accounting

Phil Mayers p.mayers at imperial.ac.uk
Tue Dec 11 10:56:53 CET 2012

On 12/10/2012 03:27 PM, John Dennis wrote:
> On 12/09/2012 07:33 PM, Arran Cudbard-Bell wrote:
>> Just pushed up a few patches to add LDAP accounting.
> Just out of curiosity why are we adding support for "worst practice",
> shouldn't we be encouraging "best practice" via the choice of supported
> configurations?
> Maintaining accounting data in LDAP is an abuse of the LDAP design goals
> of "frequent lookup, infrequent modification". Databases were designed
> for the type of data management that radius accounting involves,
> directories were not. Accounting should be in a database, not a
> directory. Directories were designed to solve different problems.

This is a bit OT, but I'm honestly curious here...

I've heard this sort of general statement about directories 
(specifically LDAP) being suitable for read-heavy workloads, and SQL 
being suitable for read/write-heavy, for well over 15 years now.

No-one has ever adequately explained to me *why* sending an LDAP write 
op PDU is somehow different than sending an LDAP read op PDU.

It may be that all or most LDAP *implementations* are relatively slow at 
writes, but if so, it doesn't follow that this *must* be the case.

Obviously writes are slower than reads in LDAP, but that's true of 
almost any datastore backed by permanent storage. However, having done 
mass/bulk LDAP updates to OpenLDAP (and on older versions) I've found it 
pretty snappy. So I'd love to know why this is an "abuse" any more than 
using any other protocol in unanticipated-but-compliant ways.


More information about the Freeradius-Devel mailing list