FR Developer for hire: Adding Accounting support to the rlm_ldap module?

[Peter Lambrechtsen]

On Fri, May 4, 2012 at 4:10 AM, Alister Winfield <alister at ticklers.org>wrote:

> Writing accounting to LDAP is nasty I understand why it sounds a good
> idea.  But most LDAP implementations are v-slow on write (hundreds to
> thousands per second) compared to read (tens of thousands to hundreds of
> thousands per second).
>


Whilst I agree with you in principal I'll give everyone some background as
to what I am doing.

This is for DSL customer subscriber authentication which we only get when a
subscriber comes up which is normally a long running session of many weeks
if not months so it's not going to be a huge number of writes (or reads for
that matter) unless there is a significant outage and everyone needs to
re-auth.  We run a geographically diverse environment spread across 5
copies of the database in 3 physically different geographic locations in
two different islands more than 1000km apart from each other and are
running Novell eDirectory as the back-end LDAP directory.  One of the
things which eDirectory does extremely well is to have a multi-master LDAP
directory which keeps itself loosely consistent across all servers.  I've
successfully run up to about 12 replicas of a large (700k+ records) without
too much trouble.

So what I am looking to do is write the NAS IP, Subscriber IP & NAS Port Id
against the subscriber so then when we make a change to the subscriber
profile such as to rate limit or to disconnect we use Novell Identity
Manager running ontop of eDirectory to pick up on the record change, and
call JRadius Client from Coova to send a CoA/DM message to the subscriber
to change their policy or disconnect them.

If someone else knows of a telco grade robust enough either SQL database or
LDAP directory which can handle running a geographically diverse
mulit-master replicating database that recovers if you kill -9 the running
server, or cut the network links for replication for a few hours and it
will recover and get back into sync without admin input which doesn't cost
your first and second born in software licensing and hardware costs I would
love to see it.

eDirectory has served us extremely well over the many years now happily
holding in excess of 4 million subscribers with an average update rate of
80-200k updates per day and keeping an in-sync rate of less than 1 min and
without a significant customer impacting outage in the last 4 years I have
been working with it.

So.....

Since this is for our telco I am always trying to have the least number of
moving parts in a solution and keeping it simple.  If we had the LDAP
module via accounting update the directory that would be great since then
we wouldn't need the perl code I wrote.  Otherwise I am planning to do
extensive testing to make sure I can't break it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20120504/21bd7eea/attachment.html>