hi, okay. so i've been preaching that people use eg the buffered-sql virtual machine rather than do accounting DB entries 'live' - therefore giving the admin better FR performance with slower DBs etc... however, I've been approached today by someone who has a rather large detail file (few gigs) that has 'corrupt' records in it... eg entries with no Acct-Status-Type set (broken NAS, duff RADIUS server or possibly attrbute filtering along the path)...anyway, my first though was edit the accouting stanza of buffered-sql so that it looks like if(Acct-Status-Type){ sql } instead of just calling sql and borking over the lack of Accounting status in the packet. but, of course, whilst this stop the bork, it also stops the ingestion of the detail file as it sticks at that point, doesnt flush that entry and move on... so...can anyone info me the magic or steps to bypass this entry in the detail file so it can continue working on it? the code itself seems to need to go through something before flushing the packet.. ..i expect to then be told there are other broken records too - but i hope a simple solution can deal with all sorts.... then I can get them to ensure that the call to detail is protected in the first place so NULL records etc dont even go in. which reminds me...any best practice from the FR community regarding the detail file and the aforementioned protection from duff NAS etc (I've already got, on my list, use Calling-Station-Id instead of NAS-Port for the unique function as many NAS use the same port for every accounting packet :-|) thanks alan
A.L.M.Buxey@lboro.ac.uk wrote:
okay. so i've been preaching that people use eg the buffered-sql virtual machine rather than do accounting DB entries 'live' - therefore giving the admin better FR performance with slower DBs etc...
Yup.
however, I've been approached today by someone who has a rather large detail file (few gigs)
Bad. Bad, bad, bad. They should be writing detail files per day, or per hour. If they're using a version of the server from the last 6 months, it supports file globbing, which helps with this.
that has 'corrupt' records in it... eg entries with no Acct-Status-Type set (broken NAS, duff RADIUS server or possibly attrbute filtering along the path)...
But... that can happen no matter what the NAS. This needs to be handled in any case.
anyway, my first though was edit the accouting stanza of buffered-sql so that it looks like
if(Acct-Status-Type){ sql }
instead of just calling sql and borking over the lack of Accounting status in the packet.
but, of course, whilst this stop the bork, it also stops the ingestion of the detail file as it sticks at that point, doesnt flush that entry and move on... so...can anyone info me the magic or steps to bypass this entry in the detail file so it can continue working on it? the code itself seems to need to go through something before flushing the packet..
Easy. The accounting section has to be told "it's OK to continue": if (broken nas) { ok } else { sql } Or maybe better: sql if (noop || invalid) { ok } The module returns FAIL if it can't write to SQL, OK if it succeeded. It returns INVALID if there's no Acct-Status-Type, and NOOP for unknown Acct-Status-Type or zero session length.
which reminds me...any best practice from the FR community regarding the detail file and the aforementioned protection from duff NAS etc
Write small detail files, and handle failure codes from SQL as above.
(I've already got, on my list, use Calling-Station-Id instead of NAS-Port for the unique function as many NAS use the same port for every accounting packet :-|)
Create a patch, and send it to the list via git format-patch. "Best practices" really need to go into the server configuration. Anything else is too frustrating for the end users. Alan DeKok.
Hi,
(I've already got, on my list, use Calling-Station-Id instead of NAS-Port for the unique function as many NAS use the same port for every accounting packet :-|)
Create a patch, and send it to the list via git format-patch. "Best practices" really need to go into the server configuration. Anything else is too frustrating for the end users.
I was hoping to get a small discussion initiated that would hopefully bring up a few things that people find they have to do to their configs ...at the end of which we get a nice comprehensive list of updates needed for the core server configuration (and hopefully a large number of 'you need to change this or add that' blog/wiki/random document entries removed across the world) alan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
(I've already got, on my list, use Calling-Station-Id instead of NAS-Port for the unique function as many NAS use the same port for every accounting packet :-|) Create a patch, and send it to the list via git format-patch. "Best practices" really need to go into the server configuration. Anything else is too frustrating for the end users.
I was hoping to get a small discussion initiated that would hopefully bring up a few things that people find they have to do to their configs ...at the end of which we get a nice comprehensive list of updates needed for the core server configuration (and hopefully a large number of 'you need to change this or add that' blog/wiki/random document entries removed across the world) We write out a different detail file per hour. If for whatever reason the account buffer gets to be big, and you have to restart the server, at least you only have to deal with an hours worth of duplicate accounting logs.
And just as Alan DeKok suggested: accounting { # # Log traffic to an SQL database. # # See "Accounting queries" in sql.conf sql { invalid = 2 } if (invalid) { ok } } You can log it to a rejects detail file as well, if you want to dissect the packets later. The other (far more difficult) to handle one, is where you're using this to Proxy eduroam Accounting records back to an ORPS. If the administrator of the ORPS has been particularly... obnoxious. Then the ORPS will not send Accounting-Responses, and the packet will be stuck in the detail file indefinitely. Our workaround is: accounting { # # Icky workaround for lack of universal eduroam accounting support # Really need NRPS to manufacture accounting response. # if((Acct-Delay-Time < 600) || (Realm != 'remote.jrs')){ proxy_to_realm } # # Since we're proxying, we don't log anything # locally. Ensure that the accounting section # "succeeds" by forcing an "ok" return. ok } This sucks, because perfectly valid Accounting Requests might be lost if they were received at around the same time as invalid ones. I'd be interested to hear if anyone has a better solution than the above. Thanks, Arran -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkono1MACgkQcaklux5oVKKh8ACdHgDLbeRIF6wpJY9boGATfybU AiUAoIsSVWWYt6LUETZ6Ky15Out8Fm+w =cShM -----END PGP SIGNATURE-----
Hi,
Easy. The accounting section has to be told "it's OK to continue":
yep
Or maybe better:
sql if (noop || invalid) { ok }
doesnt appear to work...what happens is this.. okay detail packet rlm_sql (sql): Released sql socket id: 6 ++[sql] returns ok ++? if (noop || invalid) ? Evaluating (noop ) -> FALSE ? Evaluating (invalid) -> FALSE ++? if (noop || invalid) -> FALSE } # server buffered-sql Finished request 64. Cleaning up request 64 ID 32577 with timestamp +3 Going to the next request bad packet with no Acct-Status-Type [sql] packet has no accounting status type. [user 'XXX\User', nas '192.168.1.22'] ++[sql] returns invalid } # server buffered-sql Finished request 65. Cleaning up request 65 ID 21840 with timestamp +3 Going to the next request ..as you can see, the bit of unlang asking for the return code doesnt seem to be called at all (unlike the successful packet) and therefore the duff packet stays in the detail file queue...to keep the detail instance clogged up. alan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
Or maybe better:
sql if (noop || invalid) { ok }
doesnt appear to work... Tsk tsk, did you even read my post ? :P
sql { invalid = 2 } Gotta override the default priority, else it'll return a handled rcode. Arran -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkooTLkACgkQcaklux5oVKIHoACeN7vnEaa2vvJd/BRfI92Xfp+9 LIQAoIEAarVw2HM1ylCii0S7I2nrgaNx =FOmV -----END PGP SIGNATURE-----
Hi,
Hi,
Or maybe better:
sql if (noop || invalid) { ok }
doesnt appear to work... Tsk tsk, did you even read my post ? :P
sql { invalid = 2 }
Gotta override the default priority, else it'll return a handled rcode.
grrr. i was looking at the debug log sent and seeing the sql operation return an 'invalid' operator... and so Alans method seemed operative however - as you say, the code is doing something a little narky and unlogged underneath - hence the result code check didnt work :-| thanks! alan
A.L.M.Buxey@lboro.ac.uk wrote:
grrr. i was looking at the debug log sent and seeing the sql operation return an 'invalid' operator... and so Alans method seemed operative however - as you say, the code is doing something a little narky and unlogged underneath - hence the result code check didnt work :-|
Yes.... that's a hold-over from version 1.x, which didn't have unlang. It means you don't have to do: sql if (fail) return foo if (fail) return ... That could be made more clear, I think. Alan DeKok.
participants (3)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell