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
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
|
# -*- 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$
#
######################################################################
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!
#
# 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
#
# 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
#
# In some circumstances it may be desirable for the
# server to start up, process a detail file, and
# immediately quit. To do this enable the "one_shot"
# option below.
#
# Do not enable this for normal server operation. The
# default is "no".
#
# one_shot = no
}
#
# 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 mods-config/sql/main/$driver/queries.conf
# sql
# Cisco VoIP specific bulk accounting
# pgsql-voip
}
# The requests are not being proxied, so no pre/post-proxy
# sections are necessary.
}
|
