Re: dealing with 'corrupt' detail file
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dealing with 'corrupt' detail file
a.l.m.bu...@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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dealing with 'corrupt' detail file
a.l.m.bu...@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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dealing with 'corrupt' detail file
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dealing with 'corrupt' detail file
-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-
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dealing with 'corrupt' detail file
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dealing with 'corrupt' detail file
-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-
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
dealing with 'corrupt' detail file
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
