radrelay integration & other issues
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? Alan DeKok.
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.
Guy Fraser <guy@incentre.net> wrote:
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.
Ok... if the "read detail code" isn't part of the server, this can be done in the CVS head by: 1) having a "listen" section with a socket-specific client (localhost) 2) have radrelay send data to that socket 3) mark the socket as "radrelay only" 4) have the socket add a server-side attribute "FreeRADIUS-Data-Source" with value "Radrelay". Maing it server-specific means it can't go into a packet 5) update the proxy code to abandon proxying if that attribute is set.
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.
Hmm... that's bad.
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.
Ah... the Unique session Id is partly based on Client-IP-Address, which is the "radrelay" address, and not the NAS. That's a problem which should be fixed. Maybe rlm_detail should log Client-IP-Address, too, and radrelay needs to find a place to put it in the packet. Hmm... that restrictions means it's probably better to leave radrelay in the server core, as it's easier to play those games there. Damn... Alan DeKok.
On Fri, 2006-07-07 at 16:51 -0400, Alan DeKok wrote:
Guy Fraser <guy@incentre.net> wrote:
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.
Ok... if the "read detail code" isn't part of the server, this can be done in the CVS head by:
1) having a "listen" section with a socket-specific client (localhost) 2) have radrelay send data to that socket 3) mark the socket as "radrelay only" 4) have the socket add a server-side attribute "FreeRADIUS-Data-Source" with value "Radrelay". Maing it server-specific means it can't go into a packet 5) update the proxy code to abandon proxying if that attribute is set.
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.
Hmm... that's bad.
Which part is bad, the "unique constraint" or the duplicate entries? The unique constraint only stops the insert from working, the update succeeds, which is what I want when the record already exists. This is the same way I designed my customized Cistron Radius to work, it the insert of the record fails try an update, if that fails, log it as an error and save the query in a cache file for input after recovery. I have only had a handful of entries end up in the cache file in over 5 years.
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.
Ah... the Unique session Id is partly based on Client-IP-Address, which is the "radrelay" address, and not the NAS. That's a problem which should be fixed.
Most of the radius transactions I use are from redundant proxy servers. I believe there may be some circumstances where the duplicates may come from a different proxy server than the one the original packet came from. Would it help if I removed the Client-IP-Address from the Unique session ID? If you think there should be more entropy values, I could possibly add the Framed-IP-Address or the Calling-Station-Id. Example: --- Default --- acct_unique { key = "User-Name, Acct-Session-Id, NAS-IP-Address, Client-IP-Address, NAS-Port" } --- No Client IP --- acct_unique { key = "User-Name, Acct-Session-Id, NAS-IP-Address, NAS-Port" } --- With Framed IP --- acct_unique { key = "User-Name, Acct-Session-Id, NAS-IP-Address, NAS-Port, Framed-IP- Address" } Actually I think I may have just realized that was probably what I should have done to solve the problem, I just didn't have time to work it out after switching to FreeRadius, from my Custom system.
Maybe rlm_detail should log Client-IP-Address, too, and radrelay needs to find a place to put it in the packet.
Hmm... that restrictions means it's probably better to leave radrelay in the server core, as it's easier to play those games there. Damn...
Alan DeKok.
The move went quite smoothly, after taking a month to prepare scripts to migrate the users, and develop a PHP interface. The interface was required to allow users to check their time usage and change their password, as well as allow hierarchal administration of users and other administrators, for our affiliate organizations. The interface is far from all I wanted it to be, but provides all the absolutely necessary functions and allows reports to be downloaded. I have built some other PHP functions that will allow access to the configuration files and dictionaries, but that functionality will not be added for some time to come. So far the code is only good enough for in-house use, and needs a lot of cleanup and some more auditing before I would consider providing it to the project. Their is currently a fair bit of redundant code, and bit kludge, from reusing code originally developed for other totally unrelated projects.
participants (2)
-
Alan DeKok -
Guy Fraser