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 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
        }
}