dealing with 'corrupt' detail file

[Alan DeKok]

A.L.M.Buxey at 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.