radrelay integration & other issues

[Guy Fraser]

On Fri, 2006-07-07 at 16:51 -0400, Alan DeKok wrote:
> Guy Fraser <guy at 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.