172 lines
5.3 KiB
Plaintext
172 lines
5.3 KiB
Plaintext
# -*- 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: 5f9a522f0b02178a956f63145b6b43c427260ce0 $
|
|
#
|
|
######################################################################
|
|
|
|
server copy-acct-to-home-server {
|
|
listen {
|
|
type = detail
|
|
|
|
######################################################
|
|
#
|
|
# !!!! 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.
|
|
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
|
|
}
|
|
}
|