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
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
|
# -*- 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$
#
######################################################################
server copy-acct-to-home-server {
listen {
type = detail
#
# See sites-available/buffered-sql for more details on
# all the options available for the detail reader.
#
######################################################
#
# !!!! 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.
#
# Do NOT copy the "filename" configuration from the
# "detail" module here. It won't work. Instead, use
# file globbing (or wildcards), such as:
#
# filename = ${radacctdir}/reader1/detail-*
#
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
#
# 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
# 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
#
# Edit proxy.conf to add a "home_server" section,
# which points to the other server.
#
# Then set that home_server name here.
#
update control {
Home-Server-Name := "name_of_home_server_from_proxy.conf"
}
#
# 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 {
# 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
# Uncomment the following line if you want to filter
# replies from remote proxies based on the rules
# defined in the 'attrs' file.
# attr_filter
}
}
|
