Hi,
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! Greetings, Stefan
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
-- Stefan WINTER 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 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66