Adding upstream version 3.2.1+dfsg.upstream/3.2.1+dfsgupstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 161 insertions, 0 deletions

diff --git a/raddb/sites-available/buffered-sql b/raddb/sites-available/buffered-sql
new file mode 100644
index 0000000..74574ac
--- /dev/null
+++ b/raddb/sites-available/buffered-sql
@@ -0,0 +1,161 @@
+# -*- 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 queries 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$
+#
+######################################################################
+
+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!
+		#
+		#  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.
+		#
+		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
+
+		#
+		#  Track progress through the detail file.  When the detail
+		#  file is large, and the server is re-started, 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
+
+		#
+		#  In some circumstances it may be desirable for the
+		#  server to start up, process a detail file, and
+		#  immediately quit. To do this enable the "one_shot"
+		#  option below.
+		#
+		#  Do not enable this for normal server operation. The
+		#  default is "no".
+		#
+	#	one_shot = no
+	}
+
+	#
+	#  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 mods-config/sql/main/$driver/queries.conf
+	#	sql
+
+
+		#  Cisco VoIP specific bulk accounting
+	#	pgsql-voip
+
+	}
+
+	# The requests are not being proxied, so no pre/post-proxy
+	# sections are necessary.
+}