On Wed, Dec 14, 2011 at 07:13:05PM +0100, Alan DeKok wrote:
> So submit a patch which implements accounting replication which (a)
> doesn't write to disk, and (b) is robust in the event of temporary
> process/system failures.
>
> I don't think you can satisfy both requirements at the same time
Florian Lohoff wrote:
> For most of my purposes i dont care about systems not available for a longer
> period as backend systems take care on synchronisation.
Then why replicate via RADIUS? Why not synchronise via the backend?
> In the past 15 years i have seen a lot of broken Radius implement
Hi,
On Wed, Dec 14, 2011 at 05:45:17PM +0100, Alan DeKok wrote:
> Florian Lohoff wrote:
> > A "duplicate" policy would be what i was looking for. Acknowledge the
> > packet to the sending NAS and sending requests to all final systems
> > and waiting for their acknowlegde.
>
> This can be done.
Florian Lohoff wrote:
> A "duplicate" policy would be what i was looking for. Acknowledge the
> packet to the sending NAS and sending requests to all final systems
> and waiting for their acknowlegde.
This can be done.
> A limit in queue or storage capacity
> would be acceptable e.g. max 1000 r
Hi,
i'd like to forward accounting requests to multiple locations. We use radius
accounting not just for billing/accounting but also monitoring, tr069
configuration and other stuff so we need multiple locations to send the
information to.
I have found the home_server_pool stuff but the policys a
5 matches
Mail list logo