4 |
- |
1 |
# -*- text -*-
|
|
|
2 |
######################################################################
|
|
|
3 |
#
|
|
|
4 |
# In 2.0.0, radrelay functionality is integrated into the
|
|
|
5 |
# server core. This virtual server gives an example of
|
|
|
6 |
# using radrelay functionality inside of the server.
|
|
|
7 |
#
|
|
|
8 |
# In this example, the detail file is read, and the data
|
|
|
9 |
# is put into SQL. This configuration is used when a RADIUS
|
|
|
10 |
# server on this machine is receiving accounting packets,
|
|
|
11 |
# and writing them to the detail file.
|
|
|
12 |
#
|
|
|
13 |
# The purpose of this virtual server is to de-couple the storage
|
|
|
14 |
# of long-term accounting data in SQL from "live" information
|
|
|
15 |
# needed by the RADIUS server as it is running.
|
|
|
16 |
#
|
|
|
17 |
# The benefit of this approach is that for a busy server, the
|
|
|
18 |
# overhead of performing SQL qeuries may be significant. Also,
|
|
|
19 |
# if the SQL databases are large (as is typical for ones storing
|
|
|
20 |
# months of data), the INSERTs and UPDATEs may take a relatively
|
|
|
21 |
# long time. Rather than slowing down the RADIUS server by
|
|
|
22 |
# having it interact with a database, you can just log the
|
|
|
23 |
# packets to a detail file, and then read that file later at a
|
|
|
24 |
# time when the RADIUS server is typically lightly loaded.
|
|
|
25 |
#
|
|
|
26 |
# If you use on virtual server to log to the detail file,
|
|
|
27 |
# and another virtual server (i.e. this one) to read from
|
|
|
28 |
# the detail file, then this process will happen automatically.
|
|
|
29 |
# A sudden spike of RADIUS traffic means that the detail file
|
|
|
30 |
# will grow in size, and the server will be able to handle
|
|
|
31 |
# large volumes of traffic quickly. When the traffic dies down,
|
|
|
32 |
# the server will have time to read the detail file, and insert
|
|
|
33 |
# the data into a long-term SQL database.
|
|
|
34 |
#
|
34 |
- |
35 |
# $Id: 3f64cbb500cdda5014157e4776e871419f0b64df $
|
4 |
- |
36 |
#
|
|
|
37 |
######################################################################
|
|
|
38 |
|
|
|
39 |
server buffered-sql {
|
|
|
40 |
listen {
|
|
|
41 |
type = detail
|
|
|
42 |
|
|
|
43 |
# The location where the detail file is located.
|
|
|
44 |
# This should be on local disk, and NOT on an NFS
|
|
|
45 |
# mounted location!
|
|
|
46 |
filename = "${radacctdir}/detail-*"
|
|
|
47 |
|
|
|
48 |
#
|
|
|
49 |
# The server can read accounting packets from the
|
|
|
50 |
# detail file much more quickly than those packets
|
|
|
51 |
# can be written to a database. If the database is
|
|
|
52 |
# overloaded, then bad things can happen.
|
|
|
53 |
#
|
|
|
54 |
# The server will keep track of how long it takes to
|
|
|
55 |
# process an entry from the detail file. It will
|
|
|
56 |
# then pause between handling entries. This pause
|
|
|
57 |
# allows databases to "catch up", and gives the
|
|
|
58 |
# server time to notice that other packets may have
|
|
|
59 |
# arrived.
|
|
|
60 |
#
|
|
|
61 |
# The pause is calculated dynamically, to ensure that
|
|
|
62 |
# the load due to reading the detail files is limited
|
|
|
63 |
# to a small percentage of CPU time. The
|
|
|
64 |
# "load_factor" configuration item is a number
|
|
|
65 |
# between 1 and 100. The server will try to keep the
|
|
|
66 |
# percentage of time taken by "detail" file entries
|
|
|
67 |
# to "load_factor" percentage of the CPU time.
|
|
|
68 |
#
|
|
|
69 |
# If the "load_factor" is set to 100, then the server
|
|
|
70 |
# will read packets as fast as it can, usually
|
|
|
71 |
# causing databases to go into overload.
|
|
|
72 |
#
|
|
|
73 |
load_factor = 10
|
|
|
74 |
|
|
|
75 |
#
|
|
|
76 |
# Set the interval for polling the detail file.
|
|
|
77 |
# If the detail file doesn't exist, the server will
|
|
|
78 |
# wake up, and poll for it every N seconds.
|
|
|
79 |
#
|
|
|
80 |
# Useful range of values: 1 to 60
|
|
|
81 |
poll_interval = 1
|
|
|
82 |
|
|
|
83 |
#
|
|
|
84 |
# Set the retry interval for when the home server
|
|
|
85 |
# does not respond. The current packet will be
|
|
|
86 |
# sent repeatedly, at this interval, until the
|
|
|
87 |
# home server responds.
|
|
|
88 |
#
|
|
|
89 |
# Useful range of values: 5 to 30
|
|
|
90 |
retry_interval = 30
|
|
|
91 |
|
|
|
92 |
}
|
|
|
93 |
|
|
|
94 |
#
|
|
|
95 |
# Pre-accounting. Decide which accounting type to use.
|
|
|
96 |
#
|
|
|
97 |
preacct {
|
|
|
98 |
preprocess
|
|
|
99 |
|
|
|
100 |
#
|
|
|
101 |
# Ensure that we have a semi-unique identifier for every
|
|
|
102 |
# request, and many NAS boxes are broken.
|
|
|
103 |
acct_unique
|
|
|
104 |
|
|
|
105 |
#
|
|
|
106 |
# Read the 'acct_users' file. This isn't always
|
|
|
107 |
# necessary, and can be deleted if you do not use it.
|
|
|
108 |
files
|
|
|
109 |
}
|
|
|
110 |
|
|
|
111 |
#
|
|
|
112 |
# Accounting. Log the accounting data.
|
|
|
113 |
#
|
|
|
114 |
accounting {
|
|
|
115 |
#
|
|
|
116 |
# Log traffic to an SQL database.
|
|
|
117 |
#
|
|
|
118 |
# See "Accounting queries" in sql.conf
|
|
|
119 |
# sql
|
|
|
120 |
|
|
|
121 |
|
|
|
122 |
# Cisco VoIP specific bulk accounting
|
|
|
123 |
# pgsql-voip
|
|
|
124 |
|
|
|
125 |
}
|
|
|
126 |
|
|
|
127 |
# The requests are not being proxied, so no pre/post-proxy
|
|
|
128 |
# sections are necessary.
|
|
|
129 |
}
|