radrelay integration & other issues

[Guy Fraser]

On Wed, 2006-05-07 at 17:23 -0400, Alan DeKok wrote:
>   I've been looking into the issues surrounding adding radrelay to the
> server.  While it's made some things better, it's made other things
> worse.
> 
>   In the future, I'd like to add tacacs+ to RADIUS gatewaying (bug
> #254), and radsec.  After working on it for a while, it appears to be
> easier and better to do these as separate gateways, rather than
> integrating them into the server.
> 
>   So... maybe pulling radrelay out of the server isn't a bad idea,
> either.  We could take a page from "radzap", and make radrelay into a
> tiny program that runs radclient, and sends the data to a server.  It
> could even start the server itself, and monitor the server for process
> death.  So it could still *look* like one program, even if 3-4 are
> running behind the scenes.
> 
>   That would be simpler and easier to manage.
> 
>   Comments?  Flames?  Other priorities?
> 
While migrating the last 6 months of accounting data to 
FreeRadius from my custom Cistron server, I found radrelay
to be quite helpful, but I also discovered a couple of 
minor issues.

1) I had to change proxy.conf to not proxy the packets to 
the other proxy servers. It might be nice if radrelay could 
be configurable to disable proxying while importing data to 
repopulate the database, especially on a live server.

2) The duplicate entry detection did not work while importing 
data using radrelay. I am using PostGreSQL as a backend so I 
added a "unique constraint" to the radacct table to block the
duplicate entries. The "unique constraint" stops the duplicate
data from being inserted, but causes nasty looking messages 
in the log, that look like this :

Fri Jul  7 13:06:47 2006 : Error: rlm_sql (sql): failed after re-connect
Fri Jul  7 13:06:47 2006 : Error: rlm_sql (sql): Couldn't insert SQL
accounting START record - ERROR:  duplicate key violates unique
constraint "radacct_unique_session"

I prefer having the nasty messages, rather than having 
duplicated accounting data. I noticed this scenario before 
going live, by accident when I was comparing a users time 
usage between the old server and the new server. The 
discrepancy was caused by 6 accounting records that had 
the same Acct-Session-Id but the delay times and 
Unique-Session-Id were different. I cleaned them up 
with a tricky delete statement, but did not want to have 
to regularly delete records.

I am considering an option [log_failed_query = YES|NO] in 
the ...sql.conf file for the rlm_sql module that would 
allow failed SQL queries to be printed in the log.

Since the system is now live I don't want to make too 
many source changes, so I will work towards putting some 
patches together and getting them into CVS.

That's it for now, have a great weekend.