Need help

[Valts Mazurs]

On Sun, 14 Jan 2007 19:44:10 -0500
Alan DeKok <aland at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20070115/5caf9590/attachment.pgp>