Subversion Repositories configs

# -*- text -*-

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

#

#	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 data

#	is put into SQL.  This configuration is used when a RADIUS

#	server on this machine is receiving accounting packets,

#	and writing them to the detail file.

#

#	The purpose of this virtual server is to de-couple the storage

#	of long-term accounting data in SQL from "live" information

#	needed by the RADIUS server as it is running.

#

#	The benefit of this approach is that for a busy server, the

#	overhead of performing SQL qeuries may be significant.  Also,

#	if the SQL databases are large (as is typical for ones storing

#	months of data), the INSERTs and UPDATEs may take a relatively

#	long time.  Rather than slowing down the RADIUS server by

#	having it interact with a database, you can just log the

#	packets to a detail file, and then read that file later at a

#	time when the RADIUS server is typically lightly loaded.

#

#	If you use on virtual server to log to the detail file,

#	and another virtual server (i.e. this one) to read from

#	the detail file, then this process will happen automatically.

#	A sudden spike of RADIUS traffic means that the detail file

#	will grow in size, and the server will be able to handle

#	large volumes of traffic quickly.  When the traffic dies down,

#	the server will have time to read the detail file, and insert

#	the data into a long-term SQL database.

#

#	$Id: 3f64cbb500cdda5014157e4776e871419f0b64df $

#

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

server buffered-sql {

	listen {

		type = detail

		#  The location where the detail file is located.

		#  This should be on local disk, and NOT on an NFS

		#  mounted location!

		filename = "${radacctdir}/detail-*"

		#

		#  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.

		#

		load_factor = 10

		#

		#  Set the interval for polling the detail file.

		#  If the detail file doesn't exist, the server will

		#  wake up, and poll for it every N seconds.

		#

		#  Useful range of values: 1 to 60

		poll_interval = 1

		#

		#  Set the retry interval for when the home server

		#  does not respond.  The current packet will be

		#  sent repeatedly, at this interval, until the

		#  home server responds.

		#

		#  Useful range of values: 5 to 30

		retry_interval = 30

	}

	#

	#  Pre-accounting.  Decide which accounting type to use.

	#

	preacct {

		preprocess

		#

		#  Ensure that we have a semi-unique identifier for every

		#  request, and many NAS boxes are broken.

		acct_unique

		#

		#  Read the 'acct_users' file.  This isn't always

		#  necessary, and can be deleted if you do not use it.

		files

	}

	#

	#  Accounting.  Log the accounting data.

	#

	accounting {

		#

		#  Log traffic to an SQL database.

		#

		#  See "Accounting queries" in sql.conf

	#	sql

		#  Cisco VoIP specific bulk accounting

	#	pgsql-voip

	}

	# The requests are not being proxied, so no pre/post-proxy

	# sections are necessary.

}