Need help

[Valts Mazurs]

On Mon, 15 Jan 2007 15:51:36 +0100
Alan DeKok <aland at 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.

-------------- 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/23c3523b/attachment.pgp>