A while back, I setup a couple of radacct relays for archiving using the new mechanism, however occasionally the archive server is slow (the reason we moved the archival process to another server to start with), and it's impacting the primary because it doesn't respond until the proxying is done. With radrelay, this is done independently and it doesn't matter if it gets a little behind. Is there a way to make the builtin mechanism behave in the same way? If not, I'm going to resurrect radrelay...
On Jan 4, 2017, at 6:37 PM, Alan Batie <alan@peak.org> wrote:
A while back, I setup a couple of radacct relays for archiving using the new mechanism, however occasionally the archive server is slow (the reason we moved the archival process to another server to start with), and it's impacting the primary because it doesn't respond until the proxying is done. With radrelay, this is done independently and it doesn't matter if it gets a little behind. Is there a way to make the builtin mechanism behave in the same way? If not, I'm going to resurrect radrelay...
There's a sample config file: raddb/sites-available/decoupled-accounting Alan DeKok.
Dear Alan! Thank you! I think it is somehow related with Duo Auth Proxy. Whenever it is involved (before/after/post auth) with mschap the devices are not connected. I have a feeling, that the Freeradius and Duo Auth Proxy shares resources somehow (Duo written in python) and this cause the strange behaviour. Tomorrow I'll move the Duo to an independent linux server and this will clears the situation. This is the easiest test to avoid further issues with scripting. Peter Dudas On 5 January 2017 at 00:52, Alan DeKok <aland@deployingradius.com> wrote:
On Jan 4, 2017, at 6:37 PM, Alan Batie <alan@peak.org> wrote:
A while back, I setup a couple of radacct relays for archiving using the new mechanism, however occasionally the archive server is slow (the reason we moved the archival process to another server to start with), and it's impacting the primary because it doesn't respond until the proxying is done. With radrelay, this is done independently and it doesn't matter if it gets a little behind. Is there a way to make the builtin mechanism behave in the same way? If not, I'm going to resurrect radrelay...
There's a sample config file:
raddb/sites-available/decoupled-accounting
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On 1/4/17 3:52 PM, Alan DeKok wrote:
On Jan 4, 2017, at 6:37 PM, Alan Batie <alan@peak.org> wrote:
A while back, I setup a couple of radacct relays for archiving using the new mechanism, however occasionally the archive server is slow (the reason we moved the archival process to another server to start with), and it's impacting the primary because it doesn't respond until the proxying is done. With radrelay, this is done independently and it doesn't matter if it gets a little behind. Is there a way to make the builtin mechanism behave in the same way? If not, I'm going to resurrect radrelay...
There's a sample config file:
raddb/sites-available/decoupled-accounting
That gave me the right idea once I remembered how things work, thanks.
Dear Alan! If I cannot make it work with the radclient I'll try the radrelay. Thank you for the idea - I was not aware of this possibility. Peter Dudas On 5 January 2017 at 00:37, Alan Batie <alan@peak.org> wrote:
A while back, I setup a couple of radacct relays for archiving using the new mechanism, however occasionally the archive server is slow (the reason we moved the archival process to another server to start with), and it's impacting the primary because it doesn't respond until the proxying is done. With radrelay, this is done independently and it doesn't matter if it gets a little behind. Is there a way to make the builtin mechanism behave in the same way? If not, I'm going to resurrect radrelay...
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On 1/4/17 4:37 PM, Dudás Péter wrote:
Dear Alan!
If I cannot make it work with the radclient I'll try the radrelay.
I'm not sure how it applies to your situation, but if it works ;-) Resolving mine was a simple matter of having the primary server write detail files and having separate virtual servers that read the detail files and do the proxying independently.
participants (3)
-
Alan Batie -
Alan DeKok -
Dudás Péter