copy-acct-to-home-server

使用最广泛的radius的linux的源码

# -*- 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: copy-acct-to-home-server,v 1.3 2008/04/26 15:23:43 aland Exp $
#
######################################################################

server copy-acct-to-home-server {
	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
	}

	#
	#  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
	
		#
		#  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 {
	#	attr_rewrite
	
		#  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
	
	#	attr_rewrite
	
		#  Uncomment the following line if you want to filter
		#  replies from remote proxies based on the rules
		#  defined in the 'attrs' file.
	
	#	attr_filter
	}
}