Hi, I am developing a billing package for ISPs. I am trying to use the freeradius server, but my problem is that my database schemas are complex and won't be working with the available modules. That means I will have to develop a custom module for my software and compile it with freeradius. My problem is that if I do that, it won't be compatible with general RADIUS servers and I'll have to provide the software with freeradius server and my module. So will it mean that I'll have to keep my software GPL, since I am using and distributing freeradius and also it contains mysql server, or can I distribute my software commercially? Kindly help me and tell me what can be done regarding the same? Thanks in advance. Abhinay
On Sun 14 Jan 2007 19:33, Abhinay Sinha wrote:
Hi,
I am developing a billing package for ISPs. I am trying to use the freeradius server, but my problem is that my database schemas are complex and won't be working with the available modules.
Complex database structures can still be accommodated via database stored procedures which are usually faster than sending multiple queries to a database in any case.
That means I will have to develop a custom module for my software and compile it with freeradius. My problem is that if I do that, it won't be compatible with general RADIUS servers and I'll have to provide the software with freeradius server and my module. So will it mean that I'll have to keep my software GPL
Yes
, since I am using and distributing freeradius and also it contains mysql server, or can I distribute my software commercially?
Yes. You may of course sell the software, however under the terms of the GPL you will of course have to make the source code to your module available also. Regards -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Hello. To avoid GPLish stuff you could either develop Python or Perl module for FreeRADIUS or just use RADIUS server which doesn't come with GPL "goodies". Since I am maintainer of BSDRadius project (http://www.bsdradius.org) I suggest you to try it. BSDRadius provides quick and easy way how to write additional modules in Python. However there is also Openradius (http://www.openradius.org) which allows to write external modules in any programming language. Sorry guys but FreeRADIUS's support for external, Python and Perl modules is not very bright at the moment. Best regards, Valts. Peter Nixon wrote:
On Sun 14 Jan 2007 19:33, Abhinay Sinha wrote:
Hi,
I am developing a billing package for ISPs. I am trying to use the freeradius server, but my problem is that my database schemas are complex and won't be working with the available modules.
Complex database structures can still be accommodated via database stored procedures which are usually faster than sending multiple queries to a database in any case.
That means I will have to develop a custom module for my software and compile it with freeradius. My problem is that if I do that, it won't be compatible with general RADIUS servers and I'll have to provide the software with freeradius server and my module. So will it mean that I'll have to keep my software GPL
Yes
, since I am using and distributing freeradius and also it contains mysql server, or can I distribute my software commercially?
Yes. You may of course sell the software, however under the terms of the GPL you will of course have to make the source code to your module available also.
Regards
Valts Mazurs wrote:
To avoid GPLish stuff you could either develop Python or Perl module for FreeRADIUS or just use RADIUS server which doesn't come with GPL "goodies".
If you're going to bash the server and direct people to your own product, I suggest you unsubscribe. As for the comments on your web page:
While there are quite large number of Radius servers (including free) available in the world, little number of them (if any) are developed with VoIP specific needs in mind.
FreeRADIUS is developed with VOIP in mind, along with 802.1x, and almost anything else RADIUS related. In fact, by editing 3 lines of text in "radiusd.conf", the server will support VOIP out of the box. But you're right, that's too much work. I'll update the "digest" module so that that much work is no longer necessary.
Typical VoIP RADIUS server should be able to take high amount of AAA requests in short time periods, handle large databases, and respond timely to prevent time-outs and request retransmission cases.
RADIUS servers that don't do that are servers that no one uses.
Most commonly used VoIP protocols (SIP and H.323) use small number of Authentication methods (e.g. CHAP and Digest), and this can allow reduce processing overhead and code size of server.
"reduce processing overhead" - Nonsense. FreeRADIUS is configurable, to let you process only what you need for your site. And if your RADIUS server is handling more than 10 requests per second, you have a HUGE site. And commodity hardware can handle 1000's of requests per second, so "processing overhead" is negligible. "reduce code size" - Nonsense. FreeRADIUS is modular, so that the only code you need to install is code you will use. The developers of FreeRADIUS have to maintain more code than most systems use, of course. But that's not rocket science. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
I already had a suspicion that I would get reply to my previous email really fast. Alan DeKok wrote:
If you're going to bash the server and direct people to your own product, I suggest you unsubscribe.
This is not the case. I have been user of FreeRADIUS for very long time, and I (and company I worked for then) decided that it will be much easier and comfortable to make small RADIUS server which would not be designed for general use. It's main purpose is to provide easy and stable backend for writing modules in Python. I tried to do the same with FreeRADIUS some time ago. There were fixes to rlm_python but it still has never worked as expected (at least on all my systems). I am not going to redirect any FreeRADIUS user to my product. The very most of FreeRADIUS users don't want to develop their own modules in Python. Oh, and I am so unlucky to be the maintainer of another RADIUS project. Seems like this is very serious reason for bashing me.
As for the comments on your web page:
While there are quite large number of Radius servers (including free) available in the world, little number of them (if any) are developed with VoIP specific needs in mind.
FreeRADIUS is developed with VOIP in mind, along with 802.1x, and almost anything else RADIUS related. In fact, by editing 3 lines of text in "radiusd.conf", the server will support VOIP out of the box.
But you're right, that's too much work. I'll update the "digest" module so that that much work is no longer necessary.
VoIP doesn't consist only of digest authorization. Digest is SIP specific, by the way.
Typical VoIP RADIUS server should be able to take high amount of AAA requests in short time periods, handle large databases, and respond timely to prevent time-outs and request retransmission cases.
RADIUS servers that don't do that are servers that no one uses.
In case of all known radius servers they become slow when there's serious business logic implemented in the backend. And what if authorization requests had higher priority than the accounting ones? And what if accounting response could be sent even before processing the request? It is a major speedup. It is optimization in design, not in several parts of code.
Most commonly used VoIP protocols (SIP and H.323) use small number of Authentication methods (e.g. CHAP and Digest), and this can allow reduce processing overhead and code size of server.
"reduce processing overhead" - Nonsense.
FreeRADIUS is configurable, to let you process only what you need for your site. And if your RADIUS server is handling more than 10 requests per second, you have a HUGE site. And commodity hardware can handle 1000's of requests per second, so "processing overhead" is negligible.
In VoIP world 50 requests per second is nothing BIG. Users begin and terminate their sessions very often. The main reason is bad link quality which results in many unsuccessful call attempts.
"reduce code size" - Nonsense.
I think that code size matters, a lot. It is much easier to hold in your head all the stuff if it takes less space. The same is with screen.
FreeRADIUS is modular, so that the only code you need to install is code you will use.
The developers of FreeRADIUS have to maintain more code than most systems use, of course. But that's not rocket science.
Of course. And thank you for that. I am sure that FreeRADIUS is the best tool for vast majority of use cases. Just, please, Alan, don't take it so personally that there are other RADIUS servers in the world. I was just offering a person something I think is better for particular case. You should agree that there are easier ways how to add non GPLed code to the server than the ways offered by FreeRADIUS. Valts. P.S. You should take a look at openradius.org I really like the idea when RADIUS server communicates with modules through pipes.
On January 14, 2007 10:53:30 PM +0200 Valts Mazurs <valts@bsdradius.org> wrote:
And what if accounting response could be sent even before processing the request? It is a major speedup. It is optimization in design, not in several parts of code.
Sounds like sql_relay in FreeRADIUS. -frank
On Sun, 14 Jan 2007 14:26:17 -0800 Frank Cusack <fcusack@fcusack.com> wrote:
On January 14, 2007 10:53:30 PM +0200 Valts Mazurs <valts@bsdradius.org> wrote:
And what if accounting response could be sent even before processing the request? It is a major speedup. It is optimization in design, not in several parts of code.
Sounds like sql_relay in FreeRADIUS.
Thanks. I'll take a look. Valts.
Valts Mazurs wrote:
I already had a suspicion that I would get reply to my previous email really fast.
That's what happens when you troll on a list.
Alan DeKok wrote:
If you're going to bash the server and direct people to your own product, I suggest you unsubscribe.
This is not the case.
Simple contradiction doesn't establish your point, or make mine not true.
I have been user of FreeRADIUS for very long time, and I (and company I worked for then) decided that it will be much easier and comfortable to make small RADIUS server which would not be designed for general use. It's main purpose is to provide easy and stable backend for writing modules in Python. I tried to do the same with FreeRADIUS some time ago. There were fixes to rlm_python but it still has never worked as expected (at least on all my systems).
Hmm.. You're saying it's easier to write & support a complete RADIUS server than to fix rlm_python. Right.
I am not going to redirect any FreeRADIUS user to my product.
So when you said people should use bsdradius, you were doing what, exactly?
The very most of FreeRADIUS users don't want to develop their own modules in Python. Oh, and I am so unlucky to be the maintainer of another RADIUS project. Seems like this is very serious reason for bashing me.
Ah, yes. I'm being rude for asking you to follow common politeness.
In case of all known radius servers they become slow when there's serious business logic implemented in the backend.
You've successfully optimized the backends by writing a BSD-licensed server? i.e. This response indicates that your web site claims about the need for a fast, small server are B.S.
And what if authorization requests had higher priority than the accounting ones?
You can do this with FreeRADIUS. Read the config files, and the documentation for the "nice" command.
And what if accounting response could be sent even before processing the request? It is a major speedup. It is optimization in design, not in several parts of code.
It optimizes away robust accounting. That's a non-starter for anyone who's basing a business on correct accounting. FreeRADIUS won't be implementing this "feature" It can destroy a business.
In VoIP world 50 requests per second is nothing BIG. Users begin and terminate their sessions very often. The main reason is bad link quality which results in many unsuccessful call attempts.
Is that near the 1000's/s limit I said? Nope. Then why the B.S. claims about the need for a fast & efficient server?
"reduce code size" - Nonsense.
I think that code size matters, a lot. It is much easier to hold in your head all the stuff if it takes less space. The same is with screen.
Try using something called "structured programming". It helps.
Just, please, Alan, don't take it so personally that there are other RADIUS servers in the world.
It's easier to dismiss my points by labelling me as taking it "personally". It's harder to dismiss my points by arguing the facts.
P.S. You should take a look at openradius.org I really like the idea when RADIUS server communicates with modules through pipes.
Really? Wow... it's only been listed as another open source RADIUS server on freeradius.org for what, 3-4 years now? And the author of OpenRADIUS hasn't trolled in this list, either. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Sun, 14 Jan 2007 19:44:10 -0500 Alan DeKok <aland@deployingradius.com> wrote:
Valts Mazurs wrote:
I already had a suspicion that I would get reply to my previous email really fast.
That's what happens when you troll on a list.
Alan DeKok wrote:
If you're going to bash the server and direct people to your own product, I suggest you unsubscribe.
This is not the case.
Simple contradiction doesn't establish your point, or make mine not true.
I have been user of FreeRADIUS for very long time, and I (and company I worked for then) decided that it will be much easier and comfortable to make small RADIUS server which would not be designed for general use. It's main purpose is to provide easy and stable backend for writing modules in Python. I tried to do the same with FreeRADIUS some time ago. There were fixes to rlm_python but it still has never worked as expected (at least on all my systems).
Hmm.. You're saying it's easier to write & support a complete RADIUS server than to fix rlm_python. Right.
Yes, it is. rlm_python was not the only problem.
I am not going to redirect any FreeRADIUS user to my product.
So when you said people should use bsdradius, you were doing what, exactly?
Hmmm... I suppose that the person who started this thread is not user of any RADIUS server yet. If I was not the maintainer of that evil BSDRadius project would you also call me a troll? I was just trying to save some headache for particular person. There are easier ways how to write non GPL modules for RADIUS server. This is my opinion whether I am maintainer of any project at all or not. BTW I recommended also Openradius but I haven't seen much activity from your side regarding this fact. Is it considered less evil than BSDRadius?
The very most of FreeRADIUS users don't want to develop their own modules in Python. Oh, and I am so unlucky to be the maintainer of another RADIUS project. Seems like this is very serious reason for bashing me.
Ah, yes. I'm being rude for asking you to follow common politeness.
In case of all known radius servers they become slow when there's serious business logic implemented in the backend.
You've successfully optimized the backends by writing a BSD-licensed server?
i.e. This response indicates that your web site claims about the need for a fast, small server are B.S.
And what if authorization requests had higher priority than the accounting ones?
You can do this with FreeRADIUS. Read the config files, and the documentation for the "nice" command.
Thank you for pointing to this feature. I'll take a look.
And what if accounting response could be sent even before processing the request? It is a major speedup. It is optimization in design, not in several parts of code.
It optimizes away robust accounting. That's a non-starter for anyone who's basing a business on correct accounting.
FreeRADIUS won't be implementing this "feature" It can destroy a business.
I have completely different opinion regarding this feature. It can help slow backends to appear faster for end users thus reducing unneccessary usage of network bandwidth, cpu resources of radius server etc., etc. In real life it is a common situation that during peak hours multiple cloned accounting stop messages are sent to radius server. Radius server appears to send acct response too late to the client. In client side it has to keep bunch of requests into the memory until it receives accounting response. If you need old good robust accounting, just don't enable this feature. It is turned off by default.
In VoIP world 50 requests per second is nothing BIG. Users begin and terminate their sessions very often. The main reason is bad link quality which results in many unsuccessful call attempts.
Is that near the 1000's/s limit I said? Nope. Then why the B.S. claims about the need for a fast & efficient server?
"reduce code size" - Nonsense.
I think that code size matters, a lot. It is much easier to hold in your head all the stuff if it takes less space. The same is with screen.
Try using something called "structured programming". It helps.
Just, please, Alan, don't take it so personally that there are other RADIUS servers in the world.
It's easier to dismiss my points by labelling me as taking it "personally". It's harder to dismiss my points by arguing the facts.
Yeah, right. And it is so pleasant to try to dismiss my points calling them as "B.S.", "nonsense" and ranting about how badly designed is BSDRadius. Why don't you take the ideas, opinions, needs of people and try to make FreeRADIUS better? Because these are not your ideas? Or what? It would be much better if you focused more to your own project instead of trying to discredit other ones.
P.S. You should take a look at openradius.org I really like the idea when RADIUS server communicates with modules through pipes.
Really? Wow... it's only been listed as another open source RADIUS server on freeradius.org for what, 3-4 years now?
I was not talking about the project itself but about the FEATURE.
And the author of OpenRADIUS hasn't trolled in this list, either.
I suppose that he is a cool person. Regards, Valts.
Valts Mazurs wrote:
Hmmm... I suppose that the person who started this thread is not user of any RADIUS server yet. If I was not the maintainer of that evil BSDRadius
Stop pretending it's personal. It's not.
project would you also call me a troll?
Yes.
FreeRADIUS won't be implementing this "feature" It can destroy a business.
I have completely different opinion regarding this feature. It can help slow backends to appear faster for end users thus reducing unneccessary usage of network bandwidth, cpu resources of radius server etc., etc.
Why not just implement a robust and scalable solution?
Yeah, right. And it is so pleasant to try to dismiss my points calling them as "B.S.", "nonsense" and ranting about how badly designed is BSDRadius.
You're pretending it's personal again. Facts are not "rants", no matter how often you claim they are.
Why don't you take the ideas, opinions, needs of people and try to make FreeRADIUS better?
Stop being a troll. If you've spent any time reading the lists, you know your comments are wrong.
Because these are not your ideas? Or what? It would be much better if you focused more to your own project instead of trying to discredit other ones.
I post hundreds of messages helping people, and making FreeRADIUS better. You say nothing. I post one message pointing out your troll, and you get annoyed that I should "focus more to your own project". I think you're over-reacting. A lot. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Sun 14 Jan 2007 22:53, Valts Mazurs wrote:
I already had a suspicion that I would get reply to my previous email really fast.
Alan DeKok wrote:
If you're going to bash the server and direct people to your own product, I suggest you unsubscribe.
This is not the case. I have been user of FreeRADIUS for very long time, and I (and company I worked for then) decided that it will be much easier and comfortable to make small RADIUS server which would not be designed for general use. It's main purpose is to provide easy and stable backend for writing modules in Python. I tried to do the same with FreeRADIUS some time ago. There were fixes to rlm_python but it still has never worked as expected (at least on all my systems).
I am not going to redirect any FreeRADIUS user to my product. The very most of FreeRADIUS users don't want to develop their own modules in Python. Oh, and I am so unlucky to be the maintainer of another RADIUS project. Seems like this is very serious reason for bashing me.
As for the comments on your web page:
While there are quite large number of Radius servers (including free) available in the world, little number of them (if any) are developed with VoIP specific needs in mind.
FreeRADIUS is developed with VOIP in mind, along with 802.1x, and almost anything else RADIUS related. In fact, by editing 3 lines of text in "radiusd.conf", the server will support VOIP out of the box.
But you're right, that's too much work. I'll update the "digest" module so that that much work is no longer necessary.
VoIP doesn't consist only of digest authorization. Digest is SIP specific, by the way.
Typical VoIP RADIUS server should be able to take high amount of AAA requests in short time periods, handle large databases, and respond timely to prevent time-outs and request retransmission cases.
RADIUS servers that don't do that are servers that no one uses.
In case of all known radius servers they become slow when there's serious business logic implemented in the backend.
If the backend is slow there is not alot the radius server can do about...
And what if authorization requests had higher priority than the accounting ones?
This is possible in FreeRADIUS. I run separate sql modules for accounting and auth with different DB usernames. You may then assign different numbers of sockets to them, fail them over differently (even use sql_log for accounting if you wish) and assign different priorities to the queries on the database side (if your DB supports such options), or different physical machines if you wish.. (Auth queries can run on a read only slave mirror of the master DB for example)
And what if accounting response could be sent even before processing the request?
This is possible in FreeRADIUS.
It is a major speedup. It is optimization in design, not in several parts of code.
Most commonly used VoIP protocols (SIP and H.323) use small number of Authentication methods (e.g. CHAP and Digest), and this can allow reduce processing overhead and code size of server.
"reduce processing overhead" - Nonsense.
FreeRADIUS is configurable, to let you process only what you need for your site. And if your RADIUS server is handling more than 10 requests per second, you have a HUGE site. And commodity hardware can handle 1000's of requests per second, so "processing overhead" is negligible.
In VoIP world 50 requests per second is nothing BIG. Users begin and terminate their sessions very often. The main reason is bad link quality which results in many unsuccessful call attempts.
Yes. You are correct. I have happily put 1000 requests per second through FreeRADIUS. It all depends on a properly setup backend..
"reduce code size" - Nonsense.
I think that code size matters, a lot. It is much easier to hold in your head all the stuff if it takes less space. The same is with screen.
FreeRADIUS is modular, so that the only code you need to install is code you will use.
The developers of FreeRADIUS have to maintain more code than most systems use, of course. But that's not rocket science.
Of course. And thank you for that. I am sure that FreeRADIUS is the best tool for vast majority of use cases. Just, please, Alan, don't take it so personally that there are other RADIUS servers in the world. I was just offering a person something I think is better for particular case. You should agree that there are easier ways how to add non GPLed code to the server than the ways offered by FreeRADIUS.
Valts.
P.S. You should take a look at openradius.org I really like the idea when RADIUS server communicates with modules through pipes.
-- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Mon, 15 Jan 2007 11:54:46 +0200 Peter Nixon <listuser@peternixon.net> wrote:
And what if authorization requests had higher priority than the accounting ones?
This is possible in FreeRADIUS. I run separate sql modules for accounting and auth with different DB usernames. You may then assign different numbers of sockets to them, fail them over differently (even use sql_log for accounting if you wish) and assign different priorities to the queries on the database side (if your DB supports such options), or different physical machines if you wish.. (Auth queries can run on a read only slave mirror of the master DB for example)
What I mean is that I would like to process all authorization requests before accounting requests. That means if there are any auth requests in queue, working thread takes the youngest auth request. The logic is that it is more reasonable to give answer to the youngest auth request and deliver the answer in time. Older auth requests might be already unworthy and there is no point of processing them. Accounting requests may wait into the queue until they are processed.
And what if accounting response could be sent even before processing the request?
This is possible in FreeRADIUS.
My needs are: 1) incoming acct request 2) send acct response 3) pass request for modules to process 4) see if processing was ok 5) log the request to special file if processing failed If it is possible in FreeRADIUS I will consider it as my fault that I have not found this functionality by myself.
In VoIP world 50 requests per second is nothing BIG. Users begin and terminate their sessions very often. The main reason is bad link quality which results in many unsuccessful call attempts.
Yes. You are correct. I have happily put 1000 requests per second through FreeRADIUS. It all depends on a properly setup backend..
I'm not telling that FreeRADIUS would be slow. It really is not. Simply... there are ways how to help slow backends appear as not so slow for end user. Valts.
Valts Mazurs wrote:
What I mean is that I would like to process all authorization requests before accounting requests. That means if there are any auth requests in queue, working thread takes the youngest auth request. The logic is that it is more reasonable to give answer to the youngest auth request and deliver the answer in time. Older auth requests might be already unworthy and there is no point of processing them. Accounting requests may wait into the queue until they are processed.
a) run a radius server for authentication b) run a different radius server for accounting c) "nice +15" the accounting server. Why write code when you can use standard Unix utilities? This won't do *exactly* what you want, but it will come close.
And what if accounting response could be sent even before processing the request? This is possible in FreeRADIUS.
My needs are: 1) incoming acct request 2) send acct response 3) pass request for modules to process 4) see if processing was ok 5) log the request to special file if processing failed
In a word: No. It's possible, but it's wrong. A better approach is to use rlm_sql_log, which is a fast & cheap way to log the SQL inserts. A perl script can then run the inserts when the system isn't busy. Your approach involves the possibility of losing data, and still writes to a "special file". Why not just write to a "special file" all of the time?
I'm not telling that FreeRADIUS would be slow. It really is not. Simply... there are ways how to help slow backends appear as not so slow for end user.
Decouple the backend from the front end. This is a standard way to make systems more robust, scalable, and easy to maintain. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Mon, 15 Jan 2007 15:51:36 +0100 Alan DeKok <aland@deployingradius.com> wrote:
Valts Mazurs wrote:
What I mean is that I would like to process all authorization requests before accounting requests. That means if there are any auth requests in queue, working thread takes the youngest auth request. The logic is that it is more reasonable to give answer to the youngest auth request and deliver the answer in time. Older auth requests might be already unworthy and there is no point of processing them. Accounting requests may wait into the queue until they are processed.
a) run a radius server for authentication b) run a different radius server for accounting c) "nice +15" the accounting server.
Why write code when you can use standard Unix utilities? This won't do *exactly* what you want, but it will come close.
In this case I would like to exactly as I want. It seems the best possible approach for me. I might be wrong, of course.
And what if accounting response could be sent even before processing the request? This is possible in FreeRADIUS.
My needs are: 1) incoming acct request 2) send acct response 3) pass request for modules to process 4) see if processing was ok 5) log the request to special file if processing failed
In a word: No.
It's possible, but it's wrong.
A better approach is to use rlm_sql_log, which is a fast & cheap way to log the SQL inserts. A perl script can then run the inserts when the system isn't busy.
It is another way how to do accounting. But it comes with other problems. I chose some risc for getting more comfort.
Your approach involves the possibility of losing data, and still writes to a "special file". Why not just write to a "special file" all of the time?
It writes to "special file" only failed requests. List of failed requests is helpful for later debugging. Of course, this feature comes with some risc because disks might get full or just get out of order. RADIUS server then would happily accept incoming acct requests and respond with acct response as if it was operating normally. So, don't enable this feature unless you are sure that you need it.
I'm not telling that FreeRADIUS would be slow. It really is not. Simply... there are ways how to help slow backends appear as not so slow for end user.
Decouple the backend from the front end. This is a standard way to make systems more robust, scalable, and easy to maintain.
Yes, of course. But there is more what can be done :) Valts.
On Mon 15 Jan 2007 16:24, Valts Mazurs wrote:
On Mon, 15 Jan 2007 11:54:46 +0200
Peter Nixon <listuser@peternixon.net> wrote:
And what if authorization requests had higher priority than the accounting
ones?
This is possible in FreeRADIUS. I run separate sql modules for accounting and auth with different DB usernames. You may then assign different numbers of sockets to them, fail them over differently (even use sql_log for accounting if you wish) and assign different priorities to the queries on the database side (if your DB supports such options), or different physical machines if you wish.. (Auth queries can run on a read only slave mirror of the master DB for example)
What I mean is that I would like to process all authorization requests before accounting requests. That means if there are any auth requests in queue, working thread takes the youngest auth request. The logic is that it is more reasonable to give answer to the youngest auth request and deliver the answer in time. Older auth requests might be already unworthy and there is no point of processing them.
I suspect that this give similars result as the reply caching in FreeRADIUS ("cleanup_delay" etc). What happens to "older" requests that are still in the queue? Do you expire them after some time? Reply to them eventiually or keep track of duplicates?
Accounting requests may wait into the queue until they are processed.
And what if accounting response could be sent even before processing the request?
This is possible in FreeRADIUS.
My needs are: 1) incoming acct request 2) send acct response 3) pass request for modules to process 4) see if processing was ok 5) log the request to special file if processing failed
If it is possible in FreeRADIUS I will consider it as my fault that I have not found this functionality by myself.
ok. Basically the way you handle this with FreeRADIUS is: * you use the sql (or ldap) module to directly service Authentication requests. All Authentication requests are handled as fast as the backend can respond. * you pass all accounting requests to either the sqllog module OR a specially configured detail module. (I prefer the detail method, and I am going describe that, but the concept and result is effectively the same.) * The detail module writes the accounting request to an on disk spool (on a big system this should be a dedicated disk so that speed is not effected by other system utilization) and sends accounting response. * A second copy of FreeRADIUS configured in "radrelay" mode lazily reads this spool from disk and processes it into your accounting database. (As I mentioned in a previous email, your accounting database may be a Master while your Auth database is a read only slave if you wish to split up the load between multiple machines) This is superior to your method in that it is not possible to lose an accounting record after having already sent an accounting response. If your radius server crashes/disappears your NASes will think that the accounting packet has been logged and forget about it, mine will resend it to my secondary RADIUS server and the packet will not be lost. While there IS a difference in speed between writing to an on-disk spool and your method (in memory queue) our method is "correct" and a dedicated disk (or raid set) is more than fast enough to keep up with thousands of requests per second. (I haven't benchmarked it recently but I suspect we are in 100K requests per second territory here depending on disk spindle speed, filesystem and cache configuration) This could be possibly improved by adding an in memory authentication queue to make sure that radiusd never tries to send more than the maximum number of sql sockets to the database backend at one time, however this only buys you a small advantage (given that we are already queuing acct) in that if the request is delayed for more than 1 second (this is typically configurable on the NAS of course) the NAS will resend the Auth request to the secondary RADIUS. This results in duplicated load on the backend (assuming its shared, although it could be a second slave database) which makes the problem even worse. Basically a queue of more than a second (or the timeout configured on your NAS) is worse than sending an Authentication reject to a couple of users as the whole thing just snowballs! An Auth queue only helps in the case where you have a huge peak of requests that cannot be serviced simultaneously but CAN be serviced quicker than the configurable timeout of your NAS. If you continually have a deep queue then you need to increase the speed of your backend.
In VoIP world 50 requests per second is nothing BIG. Users begin and terminate their sessions very often. The main reason is bad link quality which results in many unsuccessful call attempts.
Yes. You are correct. I have happily put 1000 requests per second through FreeRADIUS. It all depends on a properly setup backend..
I'm not telling that FreeRADIUS would be slow. It really is not. Simply... there are ways how to help slow backends appear as not so slow for end user.
Yes. There are _some_ tricks you can play to try and deal with restart conditions (When one or more NAS reset a group of interfaces due to an error condition or reboot completely) more effectively. In the end however if your Authentication backend cannot clear the load backlog within a second or so you are lost anyway. Accounting of course can be handled lazily, as I explain above. I would be interested to see you run a benchmark to show that your algorithm for dealing with newest Auth request first is actually a performance gain in a high load environment. (I suspect that it will make very little difference compared with out caching system) If it does make a considerable difference, then of course we would consider adding a similar feature to FreeRADIUS. (ie. Please prove to us that what you have done is actually better!) Regarding your accounting optimization, it would be trivial for us to do the same thing but it would be wrong as it introduces the possibility of lost packets. (While there ARE companies out there that can enough accounting packets to saturate a single disk, they can afford to purchase a raid set, and they DO care about doing everything possible to not losing data!) Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon wrote:
While there IS a difference in speed between writing to an on-disk spool and your method (in memory queue) our method is "correct" and a dedicated disk (or raid set) is more than fast enough to keep up with thousands of requests per second. (I haven't benchmarked it recently but I suspect we are in 100K requests per second territory here depending on disk spindle speed, filesystem and cache configuration)
To put it another way, if a system doesn't have to be correct, you can make it run as fast as you want. Never underestimate that speed of a process that does "exit 0". It's not correct, but *man* is it fast!
Basically a queue of more than a second (or the timeout configured on your NAS) is worse than sending an Authentication reject to a couple of users as the whole thing just snowballs! An Auth queue only helps in the case where you have a huge peak of requests that cannot be serviced simultaneously but CAN be serviced quicker than the configurable timeout of your NAS. If you continually have a deep queue then you need to increase the speed of your backend.
The CVS head tries to be a little smarter. The priority is: a) replies from proxies (i.e. ongoing requests) b) requests with State attribute (i.e. EAP) c) everything else. This means that people get to finish their authentications.
I would be interested to see you run a benchmark to show that your algorithm for dealing with newest Auth request first is actually a performance gain in a high load environment. (I suspect that it will make very little difference compared with out caching system) If it does make a considerable difference, then of course we would consider adding a similar feature to FreeRADIUS. (ie. Please prove to us that what you have done is actually better!)
Dealing the the newest request first is *bad*. FreeRADIUS puts requests into a queue, and discards requests from the queue if it determines that they've timed out, or that the NAS has given up on them. Priority (or time-based) queues stabilize networks. FILO queues do not. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Mon 15 Jan 2007 22:16, Alan DeKok wrote:
I would be interested to see you run a benchmark to show that your algorithm for dealing with newest Auth request first is actually a performance gain in a high load environment. (I suspect that it will make very little difference compared with out caching system) If it does make a considerable difference, then of course we would consider adding a similar feature to FreeRADIUS. (ie. Please prove to us that what you have done is actually better!)
Dealing the the newest request first is *bad*. FreeRADIUS puts requests into a queue, and discards requests from the queue if it determines that they've timed out, or that the NAS has given up on them.
Priority (or time-based) queues stabilize networks. FILO queues do not.
Yeah. It seems to me that a FILO queue on a AAA server could lead to some very difficult to debug network behavior... -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Mon, 15 Jan 2007 22:41:55 +0200 Peter Nixon <listuser@peternixon.net> wrote:
On Mon 15 Jan 2007 22:16, Alan DeKok wrote:
I would be interested to see you run a benchmark to show that your algorithm for dealing with newest Auth request first is actually a performance gain in a high load environment. (I suspect that it will make very little difference compared with out caching system) If it does make a considerable difference, then of course we would consider adding a similar feature to FreeRADIUS. (ie. Please prove to us that what you have done is actually better!)
Dealing the the newest request first is *bad*. FreeRADIUS puts requests into a queue, and discards requests from the queue if it determines that they've timed out, or that the NAS has given up on them.
Priority (or time-based) queues stabilize networks. FILO queues do not.
Yeah. It seems to me that a FILO queue on a AAA server could lead to some very difficult to debug network behavior...
Your opinion seems to be reasonable. Although BSDRadius has timeout for auth packets I think that there is place for some experiments. FILO vs FIFO. Expiration time for auth packets is here to stay, of course. Valts.
On January 15, 2007 4:24:52 PM +0200 Valts Mazurs <valts@bsdradius.org> wrote:
What I mean is that I would like to process all authorization requests before accounting requests. That means if there are any auth requests in queue, working thread takes the youngest auth request. The logic is that it is more reasonable to give answer to the youngest auth request and deliver the answer in time. Older auth requests might be already unworthy and there is no point of processing them.
That's a pretty bad method. Under a dos attack, where dos traffic is substantially greater than good traffic, real auths will tend to get dropped in favor of processing attack auths. It's better to process them in order, short-circuiting the hard work by testing the age of the request before going on to do any work, including sending a response at all. You could even set up a new queue every second and simply drop all requests older than 3s without even looking at the timestamps on them. (Although you'd probably want to use 12s as the cutoff, to allow for retransmission. That way the age of the packet is established from the first transmission.) FreeRADIUS essentially does this. -frank
On Mon, 15 Jan 2007 09:33:29 -0800 Frank Cusack <fcusack@fcusack.com> wrote:
On January 15, 2007 4:24:52 PM +0200 Valts Mazurs <valts@bsdradius.org> wrote:
What I mean is that I would like to process all authorization requests before accounting requests. That means if there are any auth requests in queue, working thread takes the youngest auth request. The logic is that it is more reasonable to give answer to the youngest auth request and deliver the answer in time. Older auth requests might be already unworthy and there is no point of processing them.
That's a pretty bad method. Under a dos attack, where dos traffic is substantially greater than good traffic, real auths will tend to get dropped in favor of processing attack auths. It's better to process them in order, short-circuiting the hard work by testing the age of the request before going on to do any work, including sending a response at all. You could even set up a new queue every second and simply drop all requests older than 3s without even looking at the timestamps on them. (Although you'd probably want to use 12s as the cutoff, to allow for retransmission. That way the age of the packet is established from the first transmission.)
In my implementation requests from unauthorized clients (as in FreeRADIUS - whose IP address is not found in clients.conf) are not put into the queue at all. I decided to ignore them completely. It seems safer for DOS attackers. But anyway... if there are 1'000'000 zombed windows pc's attacking the site, nothing can be done in RADIUS server software to prevent it. Valts.
Valts Mazurs wrote:
In my implementation requests from unauthorized clients (as in FreeRADIUS - whose IP address is not found in clients.conf) are not put into the queue at all. I decided to ignore them completely.
That's what the RFC's say, because it's a good idea. But look at the following scenario, which actually happened in a FreeRADIUS installation. Something went wrong in a customer site, and they continually tried to login. As soon as they logged in, they logged off again. The result was a DoS from a *known* client. Using a FILO queue means that it's likely that most of the "new" requests are from the broken user, so *good* users get blocked. A FIFO queue isn't a whole lot better, but FreeRADIUS also limits the queue size. So the bad user is more likely to get blocked than good users, and if users wait long enough, they get on the net. Again, your ideas are interesting, but not realistic. Many of the FreeRADIUS developers have been working with RADIUS for over a decade (nearly 15 years for some), and there are often good reasons why "optimizations" are not done. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Tue, 16 Jan 2007 15:50:28 +0100 Alan DeKok <aland@deployingradius.com> wrote:
Valts Mazurs wrote:
In my implementation requests from unauthorized clients (as in FreeRADIUS - whose IP address is not found in clients.conf) are not put into the queue at all. I decided to ignore them completely.
That's what the RFC's say, because it's a good idea. But look at the following scenario, which actually happened in a FreeRADIUS installation.
Something went wrong in a customer site, and they continually tried to login. As soon as they logged in, they logged off again. The result was a DoS from a *known* client.
I haven't had such scenario yet :)
Using a FILO queue means that it's likely that most of the "new" requests are from the broken user, so *good* users get blocked. A FIFO queue isn't a whole lot better, but FreeRADIUS also limits the queue size. So the bad user is more likely to get blocked than good users, and if users wait long enough, they get on the net.
Queue size is limited also in my implementation. However I don't see clear evidence that FIFO is definately better than FILO. In both cases there is lot of garbage between "normal" auth requests, and that garbage has to be processed. The server anyway will be busy to get those requests done. It seems for me that it is a greater chance that "normal" request will be answered in time if it is taken from the fresh ones.
Again, your ideas are interesting, but not realistic. Many of the FreeRADIUS developers have been working with RADIUS for over a decade (nearly 15 years for some), and there are often good reasons why "optimizations" are not done.
I don't push anyone to use these optimizations. This is just how my implementation works. Btw, BSDRadius is not "ready" yet. It has to survive some serious tests before I can call it BSDRadius 1.0 I really appreciate your experience and critics. But there are real business requirements and needs why I have made such decisions. The time will show if I am totally wrong or not :) Valts.
Hi everybody and thanks for so big response for my thread. Looks like I started a heated debate, but that was not my idea. I just wanted to get my software working with any and all RADIUS servers. Initially I developed a separate AAA module which did not confirm to RADIUS protocol and was entirely written differently. The problem was that I was not happy with the results and then I heard of RADIUS and tried my hands on that. So it was true that I was not a user of any RADIUS server beforehand as said in a post. Thanks everybody for helping me in this. I guess I will write a module for freeradius, GPL it, and will send it to the community for inclusion if they like it. I can then keep my NAS server closed. :) Will it be OK then? -Abhinay
On January 17, 2007 2:08:46 PM +0530 Abhinay Sinha <sinhabhinay@gmail.com> wrote:
Thanks everybody for helping me in this. I guess I will write a module for freeradius, GPL it, and will send it to the community for inclusion if they like it.
I can then keep my NAS server closed. :)
Will it be OK then?
Unfortunately not. The GPL doesn't require that you send the original authors your derived code. It requires that if YOU DISTRIBUTE a binary of the GPL code or derived code, that YOU DISTRIBUTE the source code at a reasonable cost to THOSE PEOPLE that you have distributed the binary to, and without restriction (such as limiting them to not be allowed to redistribute) except that they may not apply additional restrictions. That is, if you create a NAS server which runs freeradius, or code derived from freeradius, you must make the freeradius and derived code available to the folks whome you sell (or give away) your NAS server to. But since you're willing to send your module to "us", it shouldn't be difficult for you to simply make it available yourself. You don't need to publish it to "the world", just to those who obtain your NAS server (if that makes a difference). Note that only the freeradius (or other GPL parts) of your NAS server need to be redistributed as source. For example if you create a configuration GUI that isn't derived from some GPL source, you need not distribute source code for that, even if it modifies configuration for GPL software (ie, freeradius). -frank
On 1/17/07, Frank Cusack <fcusack@fcusack.com> wrote:
On January 17, 2007 2:08:46 PM +0530 Abhinay Sinha <sinhabhinay@gmail.com> wrote:
Thanks everybody for helping me in this. I guess I will write a module for freeradius, GPL it, and will send it to the community for inclusion if they like it.
I can then keep my NAS server closed. :)
Will it be OK then?
Unfortunately not.
The GPL doesn't require that you send the original authors your derived code. It requires that if YOU DISTRIBUTE a binary of the GPL code or derived code, that YOU DISTRIBUTE the source code at a reasonable cost to THOSE PEOPLE that you have distributed the binary to, and without restriction (such as limiting them to not be allowed to redistribute) except that they may not apply additional restrictions.
That is, if you create a NAS server which runs freeradius, or code derived from freeradius, you must make the freeradius and derived code available to the folks whome you sell (or give away) your NAS server to.
But since you're willing to send your module to "us", it shouldn't be difficult for you to simply make it available yourself. You don't need to publish it to "the world", just to those who obtain your NAS server (if that makes a difference).
Note that only the freeradius (or other GPL parts) of your NAS server need to be redistributed as source. For example if you create a configuration GUI that isn't derived from some GPL source, you need not distribute source code for that, even if it modifies configuration for GPL software (ie, freeradius).
-frank - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Thanks :)
On January 16, 2007 4:35:52 PM +0200 Valts Mazurs <valts@bsdradius.org> wrote:
On Mon, 15 Jan 2007 09:33:29 -0800 Frank Cusack <fcusack@fcusack.com> wrote:
On January 15, 2007 4:24:52 PM +0200 Valts Mazurs <valts@bsdradius.org> wrote:
What I mean is that I would like to process all authorization requests before accounting requests. That means if there are any auth requests in queue, working thread takes the youngest auth request. The logic is that it is more reasonable to give answer to the youngest auth request and deliver the answer in time. Older auth requests might be already unworthy and there is no point of processing them.
That's a pretty bad method. Under a dos attack, where dos traffic is substantially greater than good traffic, real auths will tend to get dropped in favor of processing attack auths. It's better to process them in order, short-circuiting the hard work by testing the age of the request before going on to do any work, including sending a response at all. You could even set up a new queue every second and simply drop all requests older than 3s without even looking at the timestamps on them. (Although you'd probably want to use 12s as the cutoff, to allow for retransmission. That way the age of the packet is established from the first transmission.)
In my implementation requests from unauthorized clients (as in FreeRADIUS - whose IP address is not found in clients.conf) are not put into the queue at all. I decided to ignore them completely. It seems safer for DOS attackers. But anyway... if there are 1'000'000 zombed windows pc's attacking the site, nothing can be done in RADIUS server software to prevent it.
That has nothing to do with what I'm talking about. I am only talking about requests that get queued for processing, not requests from unauthorized clients. I thought that was obvious. On January 16, 2007 5:54:03 PM +0200 Valts Mazurs <valts@bsdradius.org> wrote:
On Tue, 16 Jan 2007 15:50:28 +0100 Alan DeKok <aland@deployingradius.com> wrote:
Valts Mazurs wrote:
In my implementation requests from unauthorized clients (as in FreeRADIUS - whose IP address is not found in clients.conf) are not put into the queue at all. I decided to ignore them completely.
That's what the RFC's say, because it's a good idea. But look at the following scenario, which actually happened in a FreeRADIUS installation.
Something went wrong in a customer site, and they continually tried to login. As soon as they logged in, they logged off again. The result was a DoS from a *known* client.
I haven't had such scenario yet :)
Ah, since you haven't experienced it, you don't have enough forward vision to handle it? Sounds like some great software you have there. Sorry, I don't really mean to be so caustic, but I hope it does make my point.
Using a FILO queue means that it's likely that most of the "new" requests are from the broken user, so *good* users get blocked. A FIFO queue isn't a whole lot better, but FreeRADIUS also limits the queue size. So the bad user is more likely to get blocked than good users, and if users wait long enough, they get on the net.
Queue size is limited also in my implementation. However I don't see clear evidence that FIFO is definately better than FILO. In both cases there is lot of garbage between "normal" auth requests, and that garbage has to be processed. The server anyway will be busy to get those requests done. It seems for me that it is a greater chance that "normal" request will be answered in time if it is taken from the fresh ones.
It is clear (seems obvious to me) that answering requests in order is the best approach. If you're so busy that you are dropping requests for sitting on the queue too long, handling the first request makes you handle that much more retransmission traffic, and pushes old requests into the bin thus causing the client to present a new request, again increasing the load. Handling the oldest packet STILL gives you the chance to handle that newer packet even under load. This is pretty well understood in the network -- are you aware of any routers that deliver packets out of order when output queues get busy? (Sometimes they do, but under priority criteria, not FILO.) That would be a disaster. -frank
participants (5)
-
Abhinay Sinha -
Alan DeKok -
Frank Cusack -
Peter Nixon -
Valts Mazurs