radsqlrelay: can't it just give up sometimes?

Stefan Winter stefan.winter at restena.lu
Wed Nov 6 13:44:39 CET 2013


> I think the issue with modifying radsqlrelay is that it's hard to know
> what a general, robust solution to this problem would look like. I guess
> the simplest solution would be to try a line for N times/M seconds, then
> give up and write it to a .failed logfile which the admin can monitor

That sounds good, ...

> However, if you're using the newer radsqlrelay which sends the logs in
> batches and uses transactions, you have to:
>  1. Rollback the transaction
>  2. Seek backwards in the log to your start point
>  3. Re-process from there
>  4. Remember the logs that failed and ignore them
> ...so it gets more complex quite quickly.

... but since I am using this, yes, the code complexity makes this a
non-trivial approach in the end :-(

> In the past, one solution I considered was writing "--" into the file at
> the start point of the failed query, which has the advantage of putting
> the "skip" state into the file and simplifying the implementation
> somewhat, but it has bad code smell ;o)
> As others have pointed out, decoupled accounting has some other ways to
> handle this; OTOH it can't handle post_auth and AFAIK doesn't batch
> insertions into transactions, so has some of the performance issues of
> the old radsqlrelay.

The batching performance hit is not an issue for me, but our queries
include post-auth ones. :-( Of course I could limit the radsqlrelay to
just those, and do the rest with buffered-sql. I'll see about that.

Thanks for the suggestions!



> In a way, what we really need is something like an ORM that maps radius
> accounting & post-auth packets to SQL in a more intelligent way than
> using string interpolation, and that could realise a mapping was going
> to fail before it tried the SQL query.
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html

Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x8A39DC66.asc
Type: application/pgp-keys
Size: 3243 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20131106/e29ccf21/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20131106/e29ccf21/attachment.pgp>

More information about the Freeradius-Users mailing list