aland at deployingradius.com
Mon Jan 15 01:44:10 CET 2007
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,
> The very
> most of FreeRADIUS users don't want to develop their own modules in
> 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
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
> 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
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.
> 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.
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog
More information about the Freeradius-Devel