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, 202 insertions, 0 deletions

diff --git a/raddb/sites-available/copy-acct-to-home-server b/raddb/sites-available/copy-acct-to-home-server
new file mode 100644
index 0000000..cd085e0
--- /dev/null
+++ b/raddb/sites-available/copy-acct-to-home-server
@@ -0,0 +1,202 @@
+# -*- 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 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.
+#
+#	$Id$
+#
+######################################################################
+
+server copy-acct-to-home-server {
+	listen {
+		type = detail
+
+		#
+		#  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.
+		#
+		#  Do NOT copy the "filename" configuration from the
+		#  "detail" module here.  It won't work.  Instead, use
+		#  file globbing (or wildcards), such as:
+		#
+		#	filename = ${radacctdir}/reader1/detail-*
+		#
+		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
+
+		#
+		#  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
+
+	}
+
+	#
+	#  Pre-accounting.  Decide which accounting type to use.
+	#
+	preacct {
+		preprocess
+
+		# Since we're just proxying, we don't need acct_unique.
+
+		#
+		#  Look for IPASS-style 'realm/', and if not found, look for
+		#  '@realm', and decide whether or not to proxy, based on
+		#  that.
+		#
+		#  Accounting requests are generally proxied to the same
+		#  home server as authentication requests.
+#		IPASS
+#		suffix
+#		ntdomain
+
+		#
+		#  Edit proxy.conf to add a "home_server" section,
+		#  which points to the other server.
+		#
+		#  Then set that home_server name here.
+		#
+		update control {
+			Home-Server-Name := "name_of_home_server_from_proxy.conf"
+		}
+
+		#
+		#  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 {
+		   #
+		   # Since we're proxying, we don't log anything
+		   # locally.  Ensure that the accounting section
+		   # "succeeds" by forcing an "ok" return.
+		   ok
+	}
+
+
+	#
+	#  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.
+	#
+	pre-proxy {
+
+		#  If you want to have a log of packets proxied to a home
+		#  server, un-comment 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.
+	#
+	post-proxy {
+		#
+
+		#  If you want to have a log of replies from a home
+		#  server, un-comment 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
+	}
+}