Need help

[Peter Nixon]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20070115/50795691/attachment.pgp>