WARNING: This configuration file has not been updated for v4,
          and therefore WILL NOT WORK.  Please do not use it.









See sites-available/buffered-sql for more details on
all the options available for the detail reader.


#####################################################

!!!! WARNING !!!!

The detail file reader acts just like a NAS.

This means that if accounting fails, the packet
is re-tried FOREVER.  It is YOUR responsibility
to write an accounting policy that returns "ok"
if the packet was processed properly, "fail" on
a database error, AND "ok" if you want to ignore
the packet (e.g. no Acct-Status-Type).

Neither the detail file write OR the detail file
reader look at the contents of the packets.  They
just either dump the packet verbatim to the file,
or read it verbatim from the file and pass it to
the server.

#####################################################

The location where the detail file is located.
This should be on local disk, and NOT on an NFS
mounted location!

On most systems, this should support file globbing
e.g. "${radacctdir}/detail-*:*"
This lets you write many smaller detail files as in
the example in radiusd.conf: ".../detail-%Y%m%d:%H"
Writing many small files is often better than writing
one large file.  File globbing also means that with
a common naming scheme for detail files, then you can
have many detail file writers, and only one reader.



The server can read accounting packets from the
detail file much more quickly than those packets
can be written to a database.  If the database is
overloaded, then bad things can happen.

The server will keep track of how long it takes to
process an entry from the detail file.  It will
then pause between handling entries.  This pause
allows databases to "catch up", and gives the
server time to notice that other packets may have
arrived.

The pause is calculated dynamically, to ensure that
the load due to reading the detail files is limited
to a small percentage of CPU time.  The
"load_factor" configuration item is a number
between 1 and 100.  The server will try to keep the
percentage of time taken by "detail" file entries
to "load_factor" percentage of the CPU time.

If the "load_factor" is set to 100, then the server
will read packets as fast as it can, usually
causing databases to go into overload.



Track progress through the detail file.  When the detail
file is large, and the server is restarted, it will
read from the START of the file.

Setting "track = yes" means it will skip packets which
have already been processed.  The default is "no".

track = yes



Pre-accounting.  Decide which accounting type to use.


Read the 'acct_users' file.  This isn't always
necessary, and can be deleted if you do not use it.


Accounting.  Log the accounting data.


Since we're proxying, we don't log anything
locally.  Ensure that the accounting section
"succeeds" by forcing an "ok" return.


When the server decides to proxy a request to a home server,
the proxied request is first passed through the pre-proxy
stage.  This stage can re-write the request, or decide to
cancel the proxy.

Only a few modules currently have this method.


If you want to have a log of packets proxied to a home
server, uncomment the following line, and the
'detail pre_proxy_log' section in radiusd.conf.
pre_proxy_log


When the server receives a reply to a request it proxied
to a home server, the request may be massaged here, in the
post-proxy stage.



If you want to have a log of replies from a home
server, uncomment the following line, and the
'detail post_proxy_log' section in radiusd.conf.
post_proxy_log

Uncomment the following line if you want to filter
replies from remote proxies based on the rules
defined in the 'attrs' file.

attr_filter

== Default Configuration

```
#	In 2.0.0, radrelay functionality is integrated into the
#	server core.  This virtual server gives an example of
#	using radrelay functionality inside of the server.
#	In this example, the detail file is read, and the packets
#	are proxied to a home server.  You will have to configure
#	realms, home_server_pool, and home_server in proxy.conf
#	for this to work.
#	The purpose of this virtual server is to enable duplication
#	of information across a load-balanced, or fail-over set of
#	servers.  For example, if a group of clients lists two
#	home servers (primary, secondary), then RADIUS accounting
#	messages will go only to one server at a time.  This file
#	configures a server (primary, secondary) to send copies of
#	the accounting information to each other.
#	That way, each server has the same set of information, and
#	can make the same decision about the user.
server copy-acct-to-home-server {
	listen {
		type = detail
		filename = ${radacctdir}/detail
		load_factor = 10
	}
	recv Accounting-Request {
		files
	}
	send Accounting-Response {
		   ok
	}
	pre-proxy {
	}
	post-proxy {
	}
}
```
