Proxying accounting to create a "tee"
I'm looking to process RADIUS accounting locally (SQL) as well as proxy it to a remote host (to some third party software that also wants to receive a copy of all accounting). Is this possible with FreeRADIUS? john -- John Morrissey _o /\ ---- __o jwm@horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__
John Morrissey wrote:
I'm looking to process RADIUS accounting locally (SQL) as well as proxy it to a remote host (to some third party software that also wants to receive a copy of all accounting).
Is this possible with FreeRADIUS?
Yes. Just configure "sql" in the accounting section, *and* configure it to proxy. Alan DeKok.
Alan DeKok wrote:
Yes. Just configure "sql" in the accounting section, *and* configure it to proxy.
Alan DeKok.
But if proxy does not respond, FR will insert duplicate records into SQL table :( Is there some way to avoid it? Best regards, Denis Volkov
volkov@ufamts.ru wrote:
Alan DeKok wrote:
Yes. Just configure "sql" in the accounting section, *and* configure it to proxy.
Alan DeKok. But if proxy does not respond, FR will insert duplicate records into SQL table :( Is there some way to avoid it?
What do you mean "duplicate records"? Alan DeKok.
Alan DeKok wrote:
What do you mean "duplicate records"?
Alan DeKok.
If home server does not respond, FR does not respond too -> NAS repeats request -> FR writes request data to SQL again. So we got two problems: 1) repeating requests 2) NAS does not receive response Or am I missing something?
volkov@ufamts.ru wrote:
If home server does not respond, FR does not respond too -> NAS repeats request -> FR writes request data to SQL again.
So... configure the server to respond. See the file raddb/sites-available/decoupled-accounting
So we got two problems: 1) repeating requests 2) NAS does not receive response
Or am I missing something?
You can configure the server to respond. The examples exist. Alan DeKok.
On Sun, Aug 16, 2009 at 10:11:02AM +0200, Alan DeKok wrote:
volkov@ufamts.ru wrote:
If home server does not respond, FR does not respond too -> NAS repeats request -> FR writes request data to SQL again.
So... configure the server to respond. See the file raddb/sites-available/decoupled-accounting
Is decoupled-accounting (writing all detail to disk and replaying it serialized with a detail listener) the only way to configure FreeRADIUS to respond to the NAS? I'm adapting robust-proxy-accounting for our environment and can't figure out how (or if it's possible) to get FreeRADIUS to respond to the originating NAS when proxying fails and the detail is logged for later proxying. Rejecting request 0 due to lack of any response from home server 66.133.129.108 port 1813 Found Post-Proxy-Type server buffered-radacct-dpi-proxy-tee { +- entering group Fail expand: /var/log/freeradius/radacct/detail.dpi-proxy-tee -> /var/log/freeradius/radacct/detail.dpi-proxy-tee rlm_detail: /var/log/freeradius/radacct/detail.dpi-proxy-tee expands to /var/log/freeradius/radacct/detail.dpi-proxy-tee expand: %t -> Fri Aug 21 20:10:39 2009 rlm_detail: Freeradius-Proxied-To = 66.133.129.108 ++[detail.dpi-proxy-tee] returns ok } Finished request 0. Cleaning up request 0 ID 24 with timestamp +2 Going to the next request WARNING: Marking home server 66.133.129.108 port 1813 as zombie (it looks like it is dead). Waking up in 0.8 seconds. john -- John Morrissey _o /\ ---- __o jwm@horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/08/2009 21:15, John Morrissey wrote:
On Sun, Aug 16, 2009 at 10:11:02AM +0200, Alan DeKok wrote:
volkov@ufamts.ru wrote:
If home server does not respond, FR does not respond too -> NAS repeats request -> FR writes request data to SQL again.
So... configure the server to respond. See the file raddb/sites-available/decoupled-accounting
Is decoupled-accounting (writing all detail to disk and replaying it serialized with a detail listener) the only way to configure FreeRADIUS to respond to the NAS?
Yes. Otherwise it'll wait for the response from the proxy server, and proxy the Accounting-Response from the proxy server back to the NAS. It's the only way the NAS could be sure the remote server received the Accounting-Request.
I'm adapting robust-proxy-accounting for our environment and can't figure out how (or if it's possible) to get FreeRADIUS to respond to the originating NAS when proxying fails and the detail is logged for later proxying.
Yep that's a good idea if the data is time critical, it also allows multiple requests to be forwarded in parallel.
Rejecting request 0 due to lack of any response from home server 66.133.129.108 port 1813 Found Post-Proxy-Type server buffered-radacct-dpi-proxy-tee { +- entering group Fail expand: /var/log/freeradius/radacct/detail.dpi-proxy-tee -> /var/log/freeradius/radacct/detail.dpi-proxy-tee rlm_detail: /var/log/freeradius/radacct/detail.dpi-proxy-tee expands to /var/log/freeradius/radacct/detail.dpi-proxy-tee expand: %t -> Fri Aug 21 20:10:39 2009 rlm_detail: Freeradius-Proxied-To = 66.133.129.108 ++[detail.dpi-proxy-tee] returns ok } Finished request 0. Cleaning up request 0 ID 24 with timestamp +2 Going to the next request WARNING: Marking home server 66.133.129.108 port 1813 as zombie (it looks like it is dead). Waking up in 0.8 seconds.
- -Arran - -- Arran Cudbard-Bell <A.Cudbard-Bell@sussex.ac.uk>, Systems Administrator (AAA), Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqPQtQACgkQcaklux5oVKLLVQCbBlskWJ+Rut1Ibc3HjW8taA+H +0MAniE6WHS8ica55UNXrpI6R2bXgMdx =xja9 -----END PGP SIGNATURE-----
On Sat, Aug 22, 2009 at 7:59 AM, Arran Cudbard-Bell<A.Cudbard-Bell@sussex.ac.uk> wrote:
On 21/08/2009 21:15, John Morrissey wrote:
Is decoupled-accounting (writing all detail to disk and replaying it serialized with a detail listener) the only way to configure FreeRADIUS to respond to the NAS?
Yes. Otherwise it'll wait for the response from the proxy server, and proxy the Accounting-Response from the proxy server back to the NAS. It's the only way the NAS could be sure the remote server received the Accounting-Request.
In that setup, where does one get AcctStartTime and AcctStopTime values? - is it from the NAS? - is it determined by the radius when writing to detail file, and everything after that simply reads what's in the detail file? - Or does every radius/SQL server involved create its own depending on when it receives the packet/query? -- Fajar
Fajar A. Nugraha wrote:
On Sat, Aug 22, 2009 at 7:59 AM, Arran Cudbard-Bell<A.Cudbard-Bell@sussex.ac.uk> wrote:
On 21/08/2009 21:15, John Morrissey wrote:
Is decoupled-accounting (writing all detail to disk and replaying it serialized with a detail listener) the only way to configure FreeRADIUS to respond to the NAS?
Yes. Otherwise it'll wait for the response from the proxy server, and proxy the Accounting-Response from the proxy server back to the NAS. It's the only way the NAS could be sure the remote server received the Accounting-Request.
In that setup, where does one get AcctStartTime and AcctStopTime values? - is it from the NAS?
Yes. As in any other setup. Ivan Kalik Kalik Informatika ISP
Fajar A. Nugraha wrote:
On Sat, Aug 22, 2009 at 7:59 AM, Arran Cudbard-Bell<A.Cudbard-Bell@sussex.ac.uk> wrote:
On 21/08/2009 21:15, John Morrissey wrote:
Is decoupled-accounting (writing all detail to disk and replaying it serialized with a detail listener) the only way to configure FreeRADIUS to respond to the NAS?
Yes. Otherwise it'll wait for the response from the proxy server, and proxy the Accounting-Response from the proxy server back to the NAS. It's the only way the NAS could be sure the remote server received the Accounting-Request.
In that setup, where does one get AcctStartTime and AcctStopTime values?
The RADIUS server records the amount of delay between the packet being received and the packet being entered into the database, you then have to compensate for this (you should be already) when you read Accounting-Sessions out of the database. The attribute it uses is Acct-Delay-Time, and it's a simple sum of the received Acct-Delay-Time and how much time has passed since the request was written to the detail file. To calculate the real AcctStartTime and AcctStopTime, you may use the following SQL snippets: (UNIX_TIMESTAMP(`acctstarttime`) - `acctstartdelay`) as 'acctstartadj' (UNIX_TIMESTAMP(`acctstoptime`) - `acctstopdelay`) as 'acctstopadj' Or just use whatever functions are available in your scripting environment.
- is it from the NAS?
No, the NAS doesn't include any timestamps. There is no guarantee that the NAS's clock would be in sync. Including an Acct-Delay-Time attribute means that timestamps are calculated using a common reference (the local time on the server).
- is it determined by the radius when writing to detail file, and everything after that simply reads what's in the detail file?
When the packet is written to the detail file, an attribute is written along with the request attributes (I think it's something like Packet-Original-Timestamp), this is subtracted from the current time and added to the original Acct-Delay-Time value.
- Or does every radius/SQL server involved create its own depending on when it receives the packet/query?
RADIUS server creates its own.
On Sat, Aug 22, 2009 at 5:53 PM, Arran Cudbard-Bell<a.cudbard-bell@sussex.ac.uk> wrote:
Fajar A. Nugraha wrote:
In that setup, where does one get AcctStartTime and AcctStopTime values?
Or just use whatever functions are available in your scripting environment.
- is it from the NAS?
No, the NAS doesn't include any timestamps.
Your answer is the complete opposite of Ivan's response :D So which one is correct? I'm using freeradius 2.1.6, and on sql/mysql/dialup.conf I found these lines: accounting_start_query = " \ INSERT INTO ${acct_table1} \ (acctsessionid, acctuniqueid, username, \ realm, nasipaddress, nasportid, \ nasporttype, acctstarttime, acctstoptime, \ acctsessiontime, acctauthentic, connectinfo_start, \ connectinfo_stop, acctinputoctets, acctoutputoctets, \ calledstationid, callingstationid, acctterminatecause, \ servicetype, framedprotocol, framedipaddress, \ acctstartdelay, acctstopdelay, xascendsessionsvrkey) \ VALUES \ ('%{Acct-Session-Id}', '%{Acct-Unique-Session-Id}', \ '%{SQL-User-Name}', \ '%{Realm}', '%{NAS-IP-Address}', '%{NAS-Port}', \ '%{NAS-Port-Type}', '%S', NULL, \ '0', '%{Acct-Authentic}', '%{Connect-Info}', \ '', '0', '0', \ '%{Called-Station-Id}', '%{Calling-Station-Id}', '', \ '%{Service-Type}', '%{Framed-Protocol}', '%{Framed-IP-Address}', \ '%{%{Acct-Delay-Time}:-0}', '0', '%{X-Ascend-Session-Svr-Key}')" I understand that most of them (like %{Acct-Session-Id} or %{NAS-IP-Address}) should be attributes coming from the NAS, or calculated by the radius from some attribute coming from the NAS, but I cant find where "%S" that fills acctstarttime comes from. -- Fajar
On Sat, Aug 22, 2009 at 5:53 PM, Arran Cudbard-Bell<a.cudbard-bell@sussex.ac.uk> wrote:
Fajar A. Nugraha wrote:
In that setup, where does one get AcctStartTime and AcctStopTime values?
Or just use whatever functions are available in your scripting environment.
- is it from the NAS?
No, the NAS doesn't include any timestamps.
Your answer is the complete opposite of Ivan's response :D So which one is correct?
His. Packet timestamp is generated by radius server. Ivan Kalik Kalik Informatika ISP
On Sun, Aug 23, 2009 at 11:54 PM, Ivan Kalik<tnt@kalik.net> wrote:
On Sat, Aug 22, 2009 at 5:53 PM, Arran Cudbard-Bell<a.cudbard-bell@sussex.ac.uk> wrote:
Fajar A. Nugraha wrote:
In that setup, where does one get AcctStartTime and AcctStopTime values?
Or just use whatever functions are available in your scripting environment.
- is it from the NAS?
No, the NAS doesn't include any timestamps.
Your answer is the complete opposite of Ivan's response :D So which one is correct?
His. Packet timestamp is generated by radius server.
So %S in dialup.conf is packet timestamp, and if I'm reading from detail file I should make use of the attribute Packet-Original-Timestamp (or similar) to get the real packet timestamp? Thanks for the help. I'm trying to deploy a setup similar to John's, proxying acct packets only, where proxying failure should not affect response to the NAS. Decoupled accounting along with getting the original packet timestamp seems to be the key of getting this right. -- Fajar
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23/08/2009 18:17, Fajar A. Nugraha wrote:
On Sun, Aug 23, 2009 at 11:54 PM, Ivan Kalik<tnt@kalik.net> wrote:
On Sat, Aug 22, 2009 at 5:53 PM, Arran Cudbard-Bell<a.cudbard-bell@sussex.ac.uk> wrote:
Fajar A. Nugraha wrote:
In that setup, where does one get AcctStartTime and AcctStopTime values?
Or just use whatever functions are available in your scripting environment.
- is it from the NAS?
No, the NAS doesn't include any timestamps.
Your answer is the complete opposite of Ivan's response :D So which one is correct?
His. Packet timestamp is generated by radius server.
So %S in dialup.conf is packet timestamp, and if I'm reading from detail file I should make use of the attribute Packet-Original-Timestamp (or similar) to get the real packet timestamp?
No, that'll get you the timestamp of when the packet was read back into the server. The only way to calculate the original received timestamp is to write the original Acct-Delay-Time into a custom attribute (say Acct-Delay-Time-Orig), subtract that from the current Acct-Delay-Time, then that from the current UNIX timestamp. received_time = current_unix_ts - (Acct-Delay-Time - Acct-Delay-Time-Orig) If you just want an accurate start time, you need to subtract Acct-Delay-Time from the current timestamp. start_time = current_unix_ts - Acct-Delay-Time See it's all pretty simple :) You can do the above calculations with the expressions module (expr) which operates in pretty much the same way as the TCL expressions module.
Thanks for the help. I'm trying to deploy a setup similar to John's, proxying acct packets only, where proxying failure should not affect response to the NAS. Decoupled accounting along with getting the original packet timestamp seems to be the key of getting this right.
Yeah it's a pretty common setup, we do it too. One thing you have to watch out for is packets with fatal errors. Where the remote accounting server never acknowledged receipt of the packet, so it gets stuck in an infinite loop in the proxying queue. I haven't figured out how to solve this properly with the current setup, so it'd be good to see some discussion on list about it. - -- Arran Cudbard-Bell <A.Cudbard-Bell@sussex.ac.uk>, Systems Administrator (AAA), Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqSh58ACgkQcaklux5oVKJ2dwCfRfTa/8sX9l1UzzGOmErC0d6E pfYAn2cJc/RZvOog6r2mAW2xbo96upaV =/n/e -----END PGP SIGNATURE-----
Arran Cudbard-Bell wrote:
No, that'll get you the timestamp of when the packet was read back into the server. The only way to calculate the original received timestamp is to write the original Acct-Delay-Time into a custom attribute (say Acct-Delay-Time-Orig), subtract that from the current Acct-Delay-Time, then that from the current UNIX timestamp.
The detail file reader creates/updates the Acct-Delay-Time based on how long the packet has been sitting in the "detail" file. There's no need to update it manually.
Yeah it's a pretty common setup, we do it too. One thing you have to watch out for is packets with fatal errors. Where the remote accounting server never acknowledged receipt of the packet, so it gets stuck in an infinite loop in the proxying queue.
I haven't figured out how to solve this properly with the current setup, so it'd be good to see some discussion on list about it.
Hmm... it should continue sending a packet from the detail file until the upstream server has responded. It shouldn't write packets to the detail file if they've been read from the detail file. Alan DeKok.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/08/2009 13:56, Alan DeKok wrote:
Arran Cudbard-Bell wrote:
No, that'll get you the timestamp of when the packet was read back into the server. The only way to calculate the original received timestamp is to write the original Acct-Delay-Time into a custom attribute (say Acct-Delay-Time-Orig), subtract that from the current Acct-Delay-Time, then that from the current UNIX timestamp.
The detail file reader creates/updates the Acct-Delay-Time based on how long the packet has been sitting in the "detail" file. There's no need to update it manually.
I wasn't suggesting that. I was suggesting a way of getting the Packet-Original-Timestamp is a usable form.
Yeah it's a pretty common setup, we do it too. One thing you have to watch out for is packets with fatal errors. Where the remote accounting server never acknowledged receipt of the packet, so it gets stuck in an infinite loop in the proxying queue.
I haven't figured out how to solve this properly with the current setup, so it'd be good to see some discussion on list about it.
Hmm... it should continue sending a packet from the detail file until the upstream server has responded. It shouldn't write packets to the detail file if they've been read from the detail file.
It doesn't. But they're only removed from the detail file if the server actually responded. Some usernames are permenantly unroutable for accounting requests. i.e. their home accounting server just doesn't accept the Accounting-Requests and never send Accounting-Responses. Ideally there'd be a mechanism to remove Accounting-Requests after X number of attempts at proxying. At the moment were using a request expiry time based on the length of the period between the request being received and it being proxied. i.e 'This request has been in the Queue for X seconds, X seconds is longer than our expiry time, remove packet from queue' This is a *horrible horrible* hacky work around, because if a bunch of requests are received around the same time, and one is 'unroutable' then all the packets received around that time will be dropped. If you don't do this, then the unproxyable packet stays at the head of the queue and blocks all the requests behind it. Arran - -- Arran Cudbard-Bell <A.Cudbard-Bell@sussex.ac.uk>, Systems Administrator (AAA), Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqTtpsACgkQcaklux5oVKJxcgCbBqY/nEHORyplNym1jNSPOAtU 9VIAnRG64wVCOkGmLxPlF+zR5T3Ejt7y =cIre -----END PGP SIGNATURE-----
Arran Cudbard-Bell wrote:
Ideally there'd be a mechanism to remove Accounting-Requests after X number of attempts at proxying. At the moment were using a request expiry time based on the length of the period between the request being received and it being proxied.
OK. I'll take a look at adding a "Packet-Retry-Counter" attribute. You should then be able to use that to make this determination on a packet by packet basis. Please open a bug so I don't forget... Alan DeKok.
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Ideally there'd be a mechanism to remove Accounting-Requests after X number of attempts at proxying. At the moment were using a request expiry time based on the length of the period between the request being received and it being proxied.
OK. I'll take a look at adding a "Packet-Retry-Counter" attribute. You should then be able to use that to make this determination on a packet by packet basis.
Ok, yes that'd be great.
Please open a bug so I don't forget...
Sure, want me to open one for the unlang rcode inheritance bug too? -- Also you need to add the CSS files back in for the bug tracking system. Currently bugzilla is trying to load them from /bugzilla/skins/standard/global.css , but I get a 404 error when trying to access them. Thanks, Arran
Arran Cudbard-Bell wrote:
Sure, want me to open one for the unlang rcode inheritance bug too?
Yes, thanks.
Also you need to add the CSS files back in for the bug tracking system. Currently bugzilla is trying to load them from /bugzilla/skins/standard/global.css , but I get a 404 error when trying to access them.
That's why it looked so crappy... Alan DeKok.
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Sure, want me to open one for the unlang rcode inheritance bug too?
Yes, thanks.
Done.
Also you need to add the CSS files back in for the bug tracking system. Currently bugzilla is trying to load them from /bugzilla/skins/standard/global.css , but I get a 404 error when trying to access them.
That's why it looked so crappy...
Yes, now it only looks slightly crappy instead of very crappy :) Thanks, Arran
On Sat, Aug 22, 2009 at 01:59:00AM +0100, Arran Cudbard-Bell wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 21/08/2009 21:15, John Morrissey wrote:
On Sun, Aug 16, 2009 at 10:11:02AM +0200, Alan DeKok wrote:
volkov@ufamts.ru wrote:
If home server does not respond, FR does not respond too -> NAS repeats request -> FR writes request data to SQL again.
So... configure the server to respond. See the file raddb/sites-available/decoupled-accounting
Is decoupled-accounting (writing all detail to disk and replaying it serialized with a detail listener) the only way to configure FreeRADIUS to respond to the NAS?
Yes. Otherwise it'll wait for the response from the proxy server, and proxy the Accounting-Response from the proxy server back to the NAS. It's the only way the NAS could be sure the remote server received the Accounting-Request.
Right. I was hoping there was a way for robust-proxy-accounting to respond to the NAS when the proxy isn't responding, since the accounting request has been "successfully" processed (i.e., written to the detail log and saved for later proxying).
I'm adapting robust-proxy-accounting for our environment and can't figure out how (or if it's possible) to get FreeRADIUS to respond to the originating NAS when proxying fails and the detail is logged for later proxying.
Yep that's a good idea if the data is time critical, it also allows multiple requests to be forwarded in parallel.
nod, this is my preference. Unfortunately (as I mentioned above), I haven't been able to figure out if/how it's possible to have FreeRADIUS always respond to the NAS, even when the proxy isn't responding and accounting is spooled to the detail file for later processing. john -- John Morrissey _o /\ ---- __o jwm@horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__
Right. I was hoping there was a way for robust-proxy-accounting to respond to the NAS when the proxy isn't responding, since the accounting request has been "successfully" processed (i.e., written to the detail log and saved for later proxying).
So it's still waiting to be processed - it hasn't been successfully processed.
I'm adapting robust-proxy-accounting for our environment and can't figure out how (or if it's possible) to get FreeRADIUS to respond to the originating NAS when proxying fails and the detail is logged for later proxying.
Yep that's a good idea if the data is time critical, it also allows multiple requests to be forwarded in parallel.
nod, this is my preference. Unfortunately (as I mentioned above), I haven't been able to figure out if/how it's possible to have FreeRADIUS always respond to the NAS, even when the proxy isn't responding and accounting is spooled to the detail file for later processing.
Use appropriate policy (decoupled accounting). Ivan Kalik Kalik Informatika ISP
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/08/2009 16:46, John Morrissey wrote:
On Sat, Aug 22, 2009 at 01:59:00AM +0100, Arran Cudbard-Bell wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 21/08/2009 21:15, John Morrissey wrote:
On Sun, Aug 16, 2009 at 10:11:02AM +0200, Alan DeKok wrote:
volkov@ufamts.ru wrote:
If home server does not respond, FR does not respond too -> NAS repeats request -> FR writes request data to SQL again.
So... configure the server to respond. See the file raddb/sites-available/decoupled-accounting
Is decoupled-accounting (writing all detail to disk and replaying it serialized with a detail listener) the only way to configure FreeRADIUS to respond to the NAS?
Yes. Otherwise it'll wait for the response from the proxy server, and proxy the Accounting-Response from the proxy server back to the NAS. It's the only way the NAS could be sure the remote server received the Accounting-Request.
Right. I was hoping there was a way for robust-proxy-accounting to respond to the NAS when the proxy isn't responding, since the accounting request has been "successfully" processed (i.e., written to the detail log and saved for later proxying).
I don't think that's possible unfortunately... If you proxy the request from the server in which it was received (and not the detail listener), the server will never send a response directly. It will instead just forward the Accounting-Response sent by the home server. Hmm come to think of it I'm not sure there's actually a way to determine that a proxy is down from within unlang. So it may not even be possible to do the switch between proxying and detail writer... I know it sounds a little clunky, but another option could be to use a chain of detail readers/writers? If you set the primary detail reader load factor to 100% the actual delay is likely to be pretty minimal... So you'd have: NAS->Outer Server->Detail Writer (Primary)->Detail Reader->Detail Writer Queue 1 ->Detail Writer Queue 2 ->Detail Writer Queue n. Detail Reader Queue 1 -> Proxy Server Detail Reader Queue 2 -> Proxy Server Detail Reader Queue n -> Proxy Server That way the NAS always receives a response, and you get pseudo parallel Accounting requests going to the proxy server. To balance between the detail writers you can use the load-balance unlang stanza, or just the expressions module with the modulo operator.
I'm adapting robust-proxy-accounting for our environment and can't figure out how (or if it's possible) to get FreeRADIUS to respond to the originating NAS when proxying fails and the detail is logged for later proxying.
Yep that's a good idea if the data is time critical, it also allows multiple requests to be forwarded in parallel.
nod, this is my preference. Unfortunately (as I mentioned above), I haven't been able to figure out if/how it's possible to have FreeRADIUS always respond to the NAS, even when the proxy isn't responding and accounting is spooled to the detail file for later processing.
I don't think it is. It'd be a nice thing to have, but I suspect quite hard to actually implement. - -Arran - -- Arran Cudbard-Bell <A.Cudbard-Bell@sussex.ac.uk>, Systems Administrator (AAA), Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqTs6EACgkQcaklux5oVKL8ngCfUe9KbYiyi9+sQbKOcrNyPcX7 jyQAnixL+xx6Jj64x+MtcWAW2GtskQRu =nKD4 -----END PGP SIGNATURE-----
On Tue, Aug 25, 2009 at 10:49:21AM +0100, Arran Cudbard-Bell wrote:
I know it sounds a little clunky, but another option could be to use a chain of detail readers/writers? If you set the primary detail reader load factor to 100% the actual delay is likely to be pretty minimal...
So you'd have:
NAS->Outer Server->Detail Writer (Primary)->Detail Reader->Detail Writer Queue 1 ->Detail Writer Queue 2 ->Detail Writer Queue n.
Detail Reader Queue 1 -> Proxy Server Detail Reader Queue 2 -> Proxy Server Detail Reader Queue n -> Proxy Server
That way the NAS always receives a response, and you get pseudo parallel Accounting requests going to the proxy server.
To balance between the detail writers you can use the load-balance unlang stanza, or just the expressions module with the modulo operator.
I settled on something similar to this. The outer server (processing requests from the NAS) uses redundant-load-balance to write round-robin across several (currently 5) detail files. Five detail listeners (one for each detail file) then feed data to their final destinations (remote proxies, SQL databases, etc.). It turned out a bit neater than having the outer server write a single file that's exploded by a dedicated detail listener into several files that, in turn, each have a detail listener that actually processes the detail. FWIW, it turned out to be impossible to implement that way since detail listeners won't write to a detail files, even if the output file is different from the input file. Thanks again for the idea Arran, I'm glad it worked out. john -- John Morrissey _o /\ ---- __o jwm@horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__
I settled on something similar to this. The outer server (processing requests from the NAS) uses redundant-load-balance to write round-robin across several (currently 5) detail files.
Five detail listeners (one for each detail file) then feed data to their final destinations (remote proxies, SQL databases, etc.).
It turned out a bit neater than having the outer server write a single file that's exploded by a dedicated detail listener into several files that, in turn, each have a detail listener that actually processes the detail. FWIW, it turned out to be impossible to implement that way since detail listeners won't write to a detail files, even if the output file is different from the input file.
Weird, I wonder what hackery is in the server to stop that... But yes you're correct you only need the detail writers in the outer server, not sure why I suggested the chain. Glad it worked out all the same :) Arran
volkov@ufamts.ru wrote:
Alan DeKok wrote:
What do you mean "duplicate records"?
Alan DeKok.
If home server does not respond, FR does not respond too -> NAS repeats request -> FR writes request data to SQL again.
So we got two problems: 1) repeating requests 2) NAS does not receive response
Or am I missing something?
Yeah the fact the unique accounting ID column is the primary key in the DB... No duplicates. But that won't happen anyway if you use the detail writer/listeners, because FR will respond to the NAS immediately. Read the post I made; it explains what you want to do. Unlimited 'tees' and everything.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Fri, Aug 14, 2009 at 09:43:05PM +0200, Alan DeKok wrote:
John Morrissey wrote:
I'm looking to process RADIUS accounting locally (SQL) as well as proxy it to a remote host (to some third party software that also wants to receive a copy of all accounting).
Yes. Just configure "sql" in the accounting section, *and* configure it to proxy.
ach, I was presuming that local processing precluded proxying (and vice versa). Thanks, Alan. john -- John Morrissey _o /\ ---- __o jwm@horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__
John Morrissey wrote:
I'm looking to process RADIUS accounting locally (SQL) as well as proxy it to a remote host (to some third party software that also wants to receive a copy of all accounting).
Is this possible with FreeRADIUS?
Check sites-available/copy-acct-to-home-server Best regards, Denis Volkov
On 14/08/2009 20:43, volkov@ufamts.ru wrote:
John Morrissey wrote:
I'm looking to process RADIUS accounting locally (SQL) as well as proxy it to a remote host (to some third party software that also wants to receive a copy of all accounting).
Is this possible with FreeRADIUS?
Yes. Works great. Log the Accounting-Request using the 'detail' module, and write the request to your DB using the SQL module. Then use the detail file listener (check the example file listed earlier in this thread), to proxy the Accounting-Requests off to the remote server. So the accounting request comes in, is written to the flat file, is written to your SQL DB, if both modules return ok an Accounting-Response is sent to the NAS. The virtual server tailing the flat file, reads the request out and proxies it to the home server, if all goes well the request is removed from the file and the next request is processed. This also has the advantage of buffering requests in case of the remote server goes down. For additional Tees into other DBs,Remote server just create additional detail writer/reader pairs. Regards, Arran -- Arran Cudbard-Bell <A.Cudbard-Bell@sussex.ac.uk>, Systems Administrator (AAA), Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2
participants (6)
-
Alan DeKok -
Arran Cudbard-Bell -
Fajar A. Nugraha -
Ivan Kalik -
John Morrissey -
volkov＠ufamts.ru