/etc/freeradius/3.0/sites-available/buffered-sql is in freeradius-config 3.0.12+dfsg-5+deb9u1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 | # -*- 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: ba71ea5ae42b054e8b43ad54092a768b76050bcb $
#
######################################################################
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!
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
}
#
# 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 sql.conf
# sql
# Cisco VoIP specific bulk accounting
# pgsql-voip
}
# The requests are not being proxied, so no pre/post-proxy
# sections are necessary.
}
|