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.