FR Developer for hire: Adding Accounting support to the rlm_ldap module?
Hello I was wanting to know if someone would be interested in being paid to add "accounting" support into the RLM_LDAP module. For this I am wanting when calling the ldap module during the "accounting" section so it can update/delete records in the LDAP directory based on the Acct-Status-Type and using a new field type into the ldap.attrmap. Ideally I would be looking for when you get an accounting Start it adds or updates an attribute, for an Interim-Update also add/update and for a Stop then removes the attribute. In the ldap.attrmap the following ItemType should be extended to support both accounting start / interim update and stop verbs over and above the current checkItem/replyItem. checkItem NAS-IP-Address radiusNASIpAddress replyItem Framed-IP-Address radiusIpAddress acctStartItem NAS-Port-Id radiusNASPortId acctIntUpdItem NAS-Port-Id radiusNASPortId acctStopItem NAS-Port-Id radiusNASPortId This would mean that when an accounting start packet came through the same LDAP Filter lookup used for the authenticate & authorize would be done for the customer record and query for the acctStartItem attributes if the accounting request had the matching VSA then the LDAP Module would do a LDAP replace attribute or if the attribute didn't exist do a ldap add attribute. The same applies for an Interim-Update and subsequently for a stop packet remove the attribute from the directory if it exists. The wrinkle with LDAP is you can't always do a LDAP add, you need to use replace if the attribute exists. I've written this in Perl and it works reasonably well but it would be ideal to have this working inside ldap as then the custom perl code I wrote wouldn't be needed. Below is the perl i've written. my $ldap = Net::LDAP->new ( "127.0.0.1" ) or die "$@"; my $mesg = $ldap->bind ( "cn=admin,o=admin", password => "password", version => 3 ); my $attrs = [ 'radiusNASPortId' ]; my $result = $ldap->search ( base => "o=Identities", scope => "sub", filter => "(radiusRemoteID=$RAD_REQUEST{'ADSL-Agent-Remote-Id'})", attrs => $attrs ); my $attrcount = $result->count; if ($result->count > 0) { my @entries = $result->entries; my $userdn = @entries[0]->dn; my $sessionfound = @entries[0]->exists('radiusNASPortId'); if ( $RAD_REQUEST{'Acct-Status-Type'} =~ "Start" ) { if ( @entries[0]->exists('radiusNASPortId') ) { my $newresult = $ldap->modify($userdn , replace => { 'radiusNASPortId' => "$RAD_REQUEST{'NAS-Port-Id'}" } ); } else { my $newresult = $ldap->modify($userdn , add => { 'radiusNASPortId' => "$RAD_REQUEST{'NAS-Port-Id'}" } ); } } if ( $RAD_REQUEST{'Acct-Status-Type'} =~ "Stop" ) { if ( @entries[0]->exists('radiusNASPortId') ) { my $newresult = $ldap->modify($userdn , delete => { 'radiusNASPortId' => [] } ); } } } To get someone who is familiar with the freeradius code base and can write code which would be acceptable to be committed back into the mainline FR codebase as this should be code contributed back to the community. How much development effort would be required (x days?) and who would be interested in being paid (and how much) to do the work? Feel free to email me directly off list if you're interested. Cheers Peter
Peter Lambrechtsen wrote:
I was wanting to know if someone would be interested in being paid to add "accounting" support into the RLM_LDAP module.
Just a note: I've been re-writing the LDAP module. The code is *much* better. I should be able to make it public in a week or two. Adding accounting support to the existing module is something I'd avoid. The code has large amounts of duplication (e.g. eDir support). Adding more code to that mess is a big problem.
For this I am wanting when calling the ldap module during the "accounting" section so it can update/delete records in the LDAP directory based on the Acct-Status-Type and using a new field type into the ldap.attrmap. Ideally I would be looking for when you get an accounting Start it adds or updates an attribute, for an Interim-Update also add/update and for a Stop then removes the attribute.
That's probably not too hard.
I've written this in Perl and it works reasonably well but it would be ideal to have this working inside ldap as then the custom perl code I wrote wouldn't be needed. Below is the perl i've written.
If it works in Perl, that's a good start. I'm not sure adding it to the LDAP module would make much difference in speed or flexibility.
To get someone who is familiar with the freeradius code base and can write code which would be acceptable to be committed back into the mainline FR codebase as this should be code contributed back to the community.
That's always nice to hear. :)
How much development effort would be required (x days?) and who would be interested in being paid (and how much) to do the work?
If you can wait a bit, the new code base should make this work MUCH easier to do. Alan DeKok.
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). Alister On 3 May 2012, at 10:47, Alan DeKok wrote:
Peter Lambrechtsen wrote:
I was wanting to know if someone would be interested in being paid to add "accounting" support into the RLM_LDAP module.
Just a note: I've been re-writing the LDAP module. The code is *much* better. I should be able to make it public in a week or two.
Adding accounting support to the existing module is something I'd avoid. The code has large amounts of duplication (e.g. eDir support). Adding more code to that mess is a big problem.
For this I am wanting when calling the ldap module during the "accounting" section so it can update/delete records in the LDAP directory based on the Acct-Status-Type and using a new field type into the ldap.attrmap. Ideally I would be looking for when you get an accounting Start it adds or updates an attribute, for an Interim-Update also add/update and for a Stop then removes the attribute.
That's probably not too hard.
I've written this in Perl and it works reasonably well but it would be ideal to have this working inside ldap as then the custom perl code I wrote wouldn't be needed. Below is the perl i've written.
If it works in Perl, that's a good start. I'm not sure adding it to the LDAP module would make much difference in speed or flexibility.
To get someone who is familiar with the freeradius code base and can write code which would be acceptable to be committed back into the mainline FR codebase as this should be code contributed back to the community.
That's always nice to hear. :)
How much development effort would be required (x days?) and who would be interested in being paid (and how much) to do the work?
If you can wait a bit, the new code base should make this work MUCH easier to do.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On Thu, May 03, 2012 at 05:10:11PM +0100, Alister Winfield 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).
Just to add: if you want to track the IP address and usage when a user is currently online (as it sounds like this is intended for), you'd be much better off with a redis in-RAM database. freeradius-2.1.12 has rlm_redis. Regards, Brian.
On Fri, May 4, 2012 at 4:10 AM, Alister Winfield <alister@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.
On Fri, May 04, 2012 at 04:49:59PM +1200, Peter Lambrechtsen wrote:
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.
Given that RADIUS accounting is over UDP and not guaranteed (e.g. NASes usually give up retransmits after a few attempts), it's usually wise to have periodic interim accounting enabled on your NAS. In this case each session will send an update at whatever interval you configure (typically 1-2 hours). This deals with missing Start records. To deal with missing Stop records, you have to look at the timestamp of when you last saw an update. If it's more than, say, 3 times the update interval, then you can assume the user is no longer online. Unfortunately, this will generate significant update traffic :-( However I see where you're coming from with your tried-and-trusted LDAP server.
Hi Peter, I have three plus years of experience in Free Radius and Cisco Access Registrar (AAA server) specialized on LDAP client and server side I'm interested to do the work of LDAP accounting write-ups. I can be paid My expectation and work completion would be in 10 days and $1000 Thanks, Sakthi +91 9032908542 On Thu, May 3, 2012 at 2:39 PM, Peter Lambrechtsen <peter@crypt.co.nz>wrote:
Hello
I was wanting to know if someone would be interested in being paid to add "accounting" support into the RLM_LDAP module.
For this I am wanting when calling the ldap module during the "accounting" section so it can update/delete records in the LDAP directory based on the Acct-Status-Type and using a new field type into the ldap.attrmap. Ideally I would be looking for when you get an accounting Start it adds or updates an attribute, for an Interim-Update also add/update and for a Stop then removes the attribute.
In the ldap.attrmap the following ItemType should be extended to support both accounting start / interim update and stop verbs over and above the current checkItem/replyItem.
checkItem NAS-IP-Address radiusNASIpAddress replyItem Framed-IP-Address radiusIpAddress acctStartItem NAS-Port-Id radiusNASPortId acctIntUpdItem NAS-Port-Id radiusNASPortId acctStopItem NAS-Port-Id radiusNASPortId
This would mean that when an accounting start packet came through the same LDAP Filter lookup used for the authenticate & authorize would be done for the customer record and query for the acctStartItem attributes if the accounting request had the matching VSA then the LDAP Module would do a LDAP replace attribute or if the attribute didn't exist do a ldap add attribute. The same applies for an Interim-Update and subsequently for a stop packet remove the attribute from the directory if it exists. The wrinkle with LDAP is you can't always do a LDAP add, you need to use replace if the attribute exists.
I've written this in Perl and it works reasonably well but it would be ideal to have this working inside ldap as then the custom perl code I wrote wouldn't be needed. Below is the perl i've written.
my $ldap = Net::LDAP->new ( "127.0.0.1" ) or die "$@"; my $mesg = $ldap->bind ( "cn=admin,o=admin", password => "password", version => 3 ); my $attrs = [ 'radiusNASPortId' ]; my $result = $ldap->search ( base => "o=Identities", scope => "sub", filter => "(radiusRemoteID=$RAD_REQUEST{'ADSL-Agent-Remote-Id'})", attrs => $attrs ); my $attrcount = $result->count; if ($result->count > 0) { my @entries = $result->entries; my $userdn = @entries[0]->dn; my $sessionfound = @entries[0]->exists('radiusNASPortId'); if ( $RAD_REQUEST{'Acct-Status-Type'} =~ "Start" ) { if ( @entries[0]->exists('radiusNASPortId') ) { my $newresult = $ldap->modify($userdn , replace => { 'radiusNASPortId' => "$RAD_REQUEST{'NAS-Port-Id'}" } ); } else { my $newresult = $ldap->modify($userdn , add => { 'radiusNASPortId' => "$RAD_REQUEST{'NAS-Port-Id'}" } ); } } if ( $RAD_REQUEST{'Acct-Status-Type'} =~ "Stop" ) { if ( @entries[0]->exists('radiusNASPortId') ) { my $newresult = $ldap->modify($userdn , delete => { 'radiusNASPortId' => [] } ); } } }
To get someone who is familiar with the freeradius code base and can write code which would be acceptable to be committed back into the mainline FR codebase as this should be code contributed back to the community.
How much development effort would be required (x days?) and who would be interested in being paid (and how much) to do the work?
Feel free to email me directly off list if you're interested.
Cheers
Peter
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On 3 May 2012, at 12:18, Sakthi Ulaganathan wrote:
Hi Peter,
I have three plus years of experience in Free Radius and Cisco Access Registrar (AAA server) specialized on LDAP client and server side
I'm interested to do the work of LDAP accounting write-ups. I can be paid
My expectation and work completion would be in 10 days and $1000
Thanks, Sakthi +91 9032908542
Might want to continue that discussion off list? Arran Cudbard-Bell a.cudbardb@freeradius.org Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !
On 05/03/2012 05:09 AM, Peter Lambrechtsen wrote:
Hello
I was wanting to know if someone would be interested in being paid to add "accounting" support into the RLM_LDAP module.
For this I am wanting when calling the ldap module during the "accounting" section so it can update/delete records in the LDAP directory based on the Acct-Status-Type and using a new field type into the ldap.attrmap. Ideally I would be looking for when you get an accounting Start it adds or updates an attribute, for an Interim-Update also add/update and for a Stop then removes the attribute.
Be careful of what you wish for and be aware of the design goals of various technologies. LDAP is designed for look-ups, it is not designed for frequent data updating. SQL databases are designed for frequent data updating as well as relational logic. You might be better served by keeping your accounting data in a SQL database, not an LDAP directory. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
participants (7)
-
Alan DeKok -
Alister Winfield -
Arran Cudbard-Bell -
Brian Candler -
John Dennis -
Peter Lambrechtsen -
Sakthi Ulaganathan