Hello Joe -
I would be inclined to use method d) so you get a copy of the accounting
requests in a separate process where you can do whatever you need to without
impacting your main process.
You would do something like this (assuming you are using Handlers):
…..
<Handler Request-Type = Accounting-Request>
AuthByPolicy ContinueAlways
<AuthBy RADIUS>
# forward a copy to a separate process
……
IgnoreAccountingResponse
</AuthBy>
<AuthBy SQL>
# do normal accounting
…..
</AuthBy>
</Handler>
Its also a good idea to have separate Radiator processes for authentication and
accounting in any case.
regards
Hugh
On 28 Jul 2013, at 18:21, Joe Hughes <[email protected]> wrote:
> Hi
>
> Simple question really.
>
> I want to introduce MongoDB as a "test" server for storing accounting and
> session data.
>
> We currently use MSSQL, it works well, but the large amount of data (and
> related joins into other data islands) can become unwieldy over time -
> especially for historic reporting. I have done some work with MongoDB and
> other systems (with relatively straight forward schemas), and storing
> accounting\session seems well suited for this. Don't get me wrong, its not
> that MSSQL\MySQL aren't up to the task, I just think this is well suited for
> NoSQL and I am keen to satisfy my technical curiosity..
>
> I am considering the best ways of getting the accounting data from our RADIUS
> servers \ SQL databases into MongoDB.
>
> Looking for some feedback\comments.
>
> Some options;
>
> a) Write a accounting hook to break apart the accounting message, construct a
> JSON request and send it off to a remote application server. * Downside is
> the risk of blocking\disrupting the main process.
>
> b) Spool the messages to disk, have an out-of-process script parse the files,
> construct a JSON (or MongoDB request) , send it to a remote server and delete
> the file. Downside is some disk\write IO, nothing too taxing. * Out of
> process = good.
>
> c) At the DB level, clone the accounting messages into another table. Script
> reads the rows, processes as above, then deletes the rows. * Some extra DB
> load.
>
> d) Possibly silently forwarding (or replicating) the accounting message to
> another server and doing one of the above
>
> Anything I have missed. I am leaning towards b) or c)
>
> Is anybody else using NoSQL for this type of application? Any feedback?
>
> Regards
>
> Joe
>
>
>
>
>
>
> _______________________________________________
> radiator mailing list
> [email protected]
> http://www.open.com.au/mailman/listinfo/radiator
--
Hugh Irvine
[email protected]
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc.
Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
_______________________________________________
radiator mailing list
[email protected]
http://www.open.com.au/mailman/listinfo/radiator
