New FreeRADIUS module: rlm_backcounter
Hi folks, I've finished next FreeRADIUS module, rlm_backcounter, which can be used to implement various end-user limits basing on counting resource usage in defined time period. Seems like classic monthly bandwidth usage limits, eh? Not really, it has a bit more to offer :-). Main differences to the classic approach are: counters count back, they can be resetted for each user individually and each user is given two counters - one being periodically resetted by the module itself, and one which it can only decrease (a "prepaid" counter). More information: http://projects.asn.pl/freemods/wiki/rlm_backcounter SVN repo: http://svn.asn.pl/freemods/trunk/rlm_backcounter/ The code has just been finished, so be sure to test it before using in production environments. BTW, could someone from the FreeRADIUS team contact me in regard of putting references to our open source projects and commercial support on the project's website? Sorry - couldn't find any contact information on this matter there. Regards, -- Pawel Foremski pjf@asn.pl
On Fri 23 Feb 2007 20:37, Pawel Foremski wrote:
BTW, could someone from the FreeRADIUS team contact me in regard of putting references to our open source projects and commercial support on the project's website? Sorry - couldn't find any contact information on this matter there.
Alan or myself would be the people to talk with :-) Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Fri 23 Feb 2007 20:37, Pawel Foremski wrote:
Hi folks,
I've finished next FreeRADIUS module, rlm_backcounter, which can be used to implement various end-user limits basing on counting resource usage in defined time period. Seems like classic monthly bandwidth usage limits, eh? Not really, it has a bit more to offer :-).
Main differences to the classic approach are: counters count back, they can be resetted for each user individually and each user is given two counters - one being periodically resetted by the module itself, and one which it can only decrease (a "prepaid" counter).
Can you provide a comparison of how its better than rlm_sqlcounter?
More information: http://projects.asn.pl/freemods/wiki/rlm_backcounter SVN repo: http://svn.asn.pl/freemods/trunk/rlm_backcounter/
The code has just been finished, so be sure to test it before using in production environments.
Would you like this code to go into cvs? Do you plan to add/support different sql databases in future? It's not critical that you do, we thank you for the code contribution either way but at some point someone will try to use postgresql or some other database (me for example :-) and someone will need to support it... Same question applies to rlm_netvim_pools... Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Saturday 24 February 2007 15:47, Peter Nixon wrote: > On Fri 23 Feb 2007 20:37, Pawel Foremski wrote: > > Main differences to the classic approach are: counters count back, they > > can be resetted for each user individually and each user is given two > > counters - one being periodically resetted by the module itself, and one > > which it can only decrease (a "prepaid" counter). > > Can you provide a comparison of how its better than rlm_sqlcounter? >From what I can see so far: * 50 lines of code less + better documentation on how it works + support for "prepaid" counters, e.g. a dialup user can buy additional transfer when he reaches the monthly limit before the reset time + rlm_sqlcounter uses xlat to access SQL database (I suppose that's slower; the code doesn't check for errors) + support for bigger counters (compare e.g. lines 507 of backcounter with 662 of sqlcounter) + can add a new VAP instead of denying access in case of reaching the limit + far more flexible - supports only per-user limits (ie. not configurable counter "key") - hardcoded queries - support for MySQL only BTW, there seems to be a typo in line 551 of rlm_sqlcounter.c ;-P. Sorry, but rlm_sqlcounter seems to me too complicated for further analysis. Specifically, handling resets is so weird I can't even compare it to backcounter, which stores reset time for each user individually. > > The code has just been finished, so be sure to test it before using in > > production environments. > > Would you like this code to go into cvs? Sure, but please give me a few more days for testing. I'll inform you when I think it's ready for inclusion. > Do you plan to add/support different sql databases in future? No, because I don't need it. > It's not critical that you do, we thank you for the code contribution either > way but at some point someone will try to use postgresql or some other > database (me for example :-) and someone will need to support it... That's how open source works, don't it? Someone who needs some feature adds it ;-P > Same question applies to rlm_netvim_pools... I don't plan to add support for other rdbms than MySQL (at least in near future) in it, either. Bye, -- Pawel Foremski pjf@asn.pl
On Sat 24 Feb 2007 18:39, Pawel Foremski wrote:
On Saturday 24 February 2007 15:47, Peter Nixon wrote:
On Fri 23 Feb 2007 20:37, Pawel Foremski wrote:
Main differences to the classic approach are: counters count back, they can be resetted for each user individually and each user is given two counters - one being periodically resetted by the module itself, and one which it can only decrease (a "prepaid" counter).
Can you provide a comparison of how its better than rlm_sqlcounter?
From what I can see so far:
* 50 lines of code less + better documentation on how it works + support for "prepaid" counters, e.g. a dialup user can buy additional transfer when he reaches the monthly limit before the reset time + rlm_sqlcounter uses xlat to access SQL database (I suppose that's slower; the code doesn't check for errors) + support for bigger counters (compare e.g. lines 507 of backcounter with 662 of sqlcounter) + can add a new VAP instead of denying access in case of reaching the limit + far more flexible - supports only per-user limits (ie. not configurable counter "key") - hardcoded queries - support for MySQL only
BTW, there seems to be a typo in line 551 of rlm_sqlcounter.c ;-P.
Sorry, but rlm_sqlcounter seems to me too complicated for further analysis. Specifically, handling resets is so weird I can't even compare it to backcounter, which stores reset time for each user individually.
The code has just been finished, so be sure to test it before using in production environments.
Would you like this code to go into cvs?
Sure, but please give me a few more days for testing. I'll inform you when I think it's ready for inclusion.
Do you plan to add/support different sql databases in future?
No, because I don't need it.
It's not critical that you do, we thank you for the code contribution either way but at some point someone will try to use postgresql or some other database (me for example :-) and someone will need to support it...
That's how open source works, don't it? Someone who needs some feature adds it ;-P
Same question applies to rlm_netvim_pools...
I don't plan to add support for other rdbms than MySQL (at least in near future) in it, either.
Regarding the additional attributes you define for the dictionary, you should register an Enterprise number for them, and then we can add them to your very own dictionary.asnet as a VSA. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Saturday 24 February 2007 19:24, Peter Nixon wrote:
Regarding the additional attributes you define for the dictionary, you should register an Enterprise number for them, and then we can add them to your very own dictionary.asnet as a VSA.
I don't understand. The attributes there are only as an example, the module does not send any attributes in auth/acct replies. The final configuration depends strongly on local setup. Defining any attributes would break the module flexibility -- it's not meant to do only the monthly transfer limits. How defining new VSA could help if the module is going to be included in cvs (I hope)? We already have our dictionary in FreeRADIUS cvs, dictionary.asn, BTW. -- Pawel Foremski pjf@asn.pl
On Sat 24 Feb 2007 20:50, Pawel Foremski wrote:
On Saturday 24 February 2007 19:24, Peter Nixon wrote:
Regarding the additional attributes you define for the dictionary, you should register an Enterprise number for them, and then we can add them to your very own dictionary.asnet as a VSA.
I don't understand.
The attributes there are only as an example, the module does not send any attributes in auth/acct replies. The final configuration depends strongly on local setup. Defining any attributes would break the module flexibility -- it's not meant to do only the monthly transfer limits.
Hmm... Alan what do you think of this?
How defining new VSA could help if the module is going to be included in cvs (I hope)?
We already have our dictionary in FreeRADIUS cvs, dictionary.asn, BTW.
Yep. I just found it a few minutes ago.. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon wrote:
The attributes there are only as an example, the module does not send any attributes in auth/acct replies. The final configuration depends strongly on local setup. Defining any attributes would break the module flexibility -- it's not meant to do only the monthly transfer limits.
Hmm... Alan what do you think of this?
I'm not sure. If the attributes are server-specific, they shouldn't go into a vendor dictionary. The module can also create them, if they don't exist... Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Do you plan to add/support different sql databases in future?
No, because I don't need it.
It's not critical that you do, we thank you for the code contribution either way but at some point someone will try to use postgresql or some other database (me for example :-) and someone will need to support it...
That's how open source works, don't it? Someone who needs some feature adds it ;-P
Same question applies to rlm_netvim_pools...
I don't plan to add support for other rdbms than MySQL (at least in near future) in it, either.
I have been attempting to make rlm_sqlhpwippool work with Postgresql. The biggest issue so far is the way you define zeroed dates in the sql schema like: `modified` datetime NOT NULL default '0000-00-00 00:00:00' Most databases (Postgresql included) do not allow invalid dates like this and give "ERROR: date/time field value out of range". This should with be NULL or should default to now() or some date in the distant past. Do you think there will be any problems if I set this to: modified TIMESTAMP NOT NULL default now() or simply (Allowing NULLS): modified TIMESTAMP Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Sunday 25 February 2007 16:53, Peter Nixon wrote:
I have been attempting to make rlm_sqlhpwippool work with Postgresql. The biggest issue so far is the way you define zeroed dates in the sql schema like: `modified` datetime NOT NULL default '0000-00-00 00:00:00' (...) Do you think there will be any problems if I set this to: modified TIMESTAMP NOT NULL default now()
or simply (Allowing NULLS): modified TIMESTAMP
Neither of these should cause any problems. P.S. Isn't it wrong topic? ;-P -- Pawel Foremski pjf@asn.pl
On Sun 25 Feb 2007 18:36, Pawel Foremski wrote:
On Sunday 25 February 2007 16:53, Peter Nixon wrote:
I have been attempting to make rlm_sqlhpwippool work with Postgresql. The biggest issue so far is the way you define zeroed dates in the sql schema like: `modified` datetime NOT NULL default '0000-00-00 00:00:00' (...) Do you think there will be any problems if I set this to: modified TIMESTAMP NOT NULL default now()
or simply (Allowing NULLS): modified TIMESTAMP
Neither of these should cause any problems.
ok. Good
P.S. Isn't it wrong topic? ;-P
Well, yes and no. I was replying to the content of the mail, not the topic :-) Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Pawel Foremski wrote:
Main differences to the classic approach are: counters count back, they can be resetted for each user individually and each user is given two counters - one being periodically resetted by the module itself, and one which it can only decrease (a "prepaid" counter).
I'm not sure why you just wouldn't run two copies the SQL counter module. Sure, it doesn't count down, but a small patch would fix that, I think. The whole point of configurable modules is to avoid re-inventing the wheel.
BTW, could someone from the FreeRADIUS team contact me in regard of putting references to our open source projects and commercial support on the project's website? Sorry - couldn't find any contact information on this matter there.
Just send an email to the list, with text for the web page. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (3)
-
Alan DeKok -
Pawel Foremski -
Peter Nixon