Subversion Repositories configs

Rev

Rev 4 | Details | Compare with Previous | Last modification | View Log | RSS feed

Rev Author Line No. Line
4 - 1 
# -*- text -*-
2 
######################################################################
3 
#
4 
#	This is a sample configuration for robust proxy accounting.
5 
#	accounting packets are proxied, OR logged locally if all
6 
#	home servers are down.  When the home servers come back up,
7 
#	the accounting packets are forwarded.
8 
#
9 
#	This method enables the server to proxy all packets to the
10 
#	home servers when they're up, AND to avoid writing to the
11 
#	detail file in most situations.
12 
#
13 
#	In most situations, proxying of accounting messages is done
14 
#	in a "pass-through" fashion.  If the home server does not
15 
#	respond, then the proxy server does not respond to the NAS.
16 
#	That means that the NAS must retransmit packets, sometimes
17 
#	forever.  This example shows how the proxy server can still
18 
#	respond to the NAS, even if all home servers are down.
19 
#
20 
#	This configuration could be done MUCH more simply if ALL
21 
#	packets were written to the detail file.  But that would
22 
#	involve a lot more disk writes, which may not be a good idea.
23 
#
24 
#	This file is NOT meant to be used as-is.  It needs to be
25 
#	edited to match your local configuration.
26 
#
34 - 27 
#	$Id: 9bf86978db676ef16f6062f4d359385e291cc930 $
4 - 28 
#
29 
######################################################################
30 
 
31 
#  (1) Define two home servers.
32 
home_server home1.example.com {
33 
	type = acct
34 
	ipaddr = 192.0.2.10
35 
	port = 1813
36 
	secret = testing123
37 
 
38 
	#  Mark this home server alive ONLY when it starts being responsive
39 
	status_check = request
40 
	username = "test_user_status_check"
41 
 
42 
	#  Set the response timeout aggressively low.
43 
	#  You MAY have to increase this, depending on tests with
44 
	#  your local installation.
45 
	response_window = 6
46 
}
47 
 
48 
home_server home2.example.com {
49 
	type = acct
50 
	ipaddr = 192.0.2.20
51 
	port = 1813
52 
	secret = testing123
53 
 
54 
	#  Mark this home server alive ONLY when it starts being responsive
55 
	status_check = request
56 
	username = "test_user_status_check"
57 
 
58 
	#  Set the response timeout aggressively low.
59 
	#  You MAY have to increase this, depending on tests with
60 
	#  your local installation.
61 
	response_window = 6
62 
}
63 
 
64 
#  (2) Define a virtual server to be used when both of the
65 
#  home servers are down.
66 
home_server acct_detail.example.com {
67 
	virtual_server = acct_detail.example.com
68 
}
69 
 
70 
#  Put all of the servers into a pool.
71 
home_server_pool acct_pool.example.com {
72 
	type = load-balance	# other types are OK, too.
73 
 
74 
	home_server = home1.example.com
75 
	home_server = home2.example.com
76 
	# add more home_server's here.
77 
 
78 
	# If all home servers are down, try a home server that
79 
	# is a local virtual server.
80 
	fallback = acct_detail.example.com
81 
 
82 
	# for pre/post-proxy policies
83 
	virtual_server = home.example.com
84 
}
85 
 
86 
#  (3) Define a realm for these home servers.
87 
#  It should NOT be used as part of normal proxying decisions!
88 
realm acct_realm.example.com {
89 
	acct_pool = acct_pool.example.com
90 
}
91 
 
92 
#  (4) Define a detail file writer.
93 
#   See raddb/modules/detail.example.com
94 
 
95 
#  (5) Define the virtual server to write the packets to the detail file
96 
#  This will be called when ALL home servers are down, because of the
97 
#  "fallback" configuration in the home server pool.
98 
server acct_detail.example.com {
99 
	accounting {
100 
		detail.example.com
101 
	}
102 
}
103 
 
104 
#  (6) Define a virtual server to handle pre/post-proxy re-writing
105 
server home.example.com {
106 
	pre-proxy {
107 
		#  Insert pre-proxy rules here
108 
	}
109 
 
110 
	post-proxy {
111 
		#  Insert post-proxy rules here
112 
 
113 
		#  This will be called when the CURRENT packet failed
114 
		#  to be proxied.  This may happen when one home server
115 
		#  suddenly goes down, even though another home server
116 
		#  may be alive.
117 
		#
118 
		#  i.e. the current request has run out of time, so it
119 
		#  cannot fail over to another (possibly) alive server.
120 
		#
121 
		#  We want to respond to the NAS, so that it can stop
122 
		#  re-sending the packet.  We write the packet to the
123 
		#  "detail" file, where it will be read, and sent to
124 
		#  another home server.
125 
		#
126 
		Post-Proxy-Type Fail {
127 
			detail.example.com
128 
		}
129 
	}
130 
 
131 
 
132 
	#  Read accounting packets from the detail file(s) for
133 
	#  the home server.
134 
	#
135 
	#  Note that you can have only ONE "listen" section reading
136 
	#  detail files from a particular directory.  That is why the
137 
	#  destination host name is used as part of the directory name
138 
	#  below.  Having two "listen" sections reading detail files
139 
	#  from the same directory WILL cause problems.  The packets
140 
	#  may be read by one, the other, or both "listen" sections.
141 
	listen {
142 
		type = detail
143 
		filename = "${radacctdir}/detail.example.com/detail-*:*"
144 
		load_factor = 10
145 
	}
146 
 
147 
	#  All packets read from the detail file are proxied back to
148 
	#  the home servers.
149 
	#
150 
	#  The normal pre/post-proxy rules are applied to them, too.
151 
	#
152 
	#  If the home servers are STILL down, then the server stops
153 
	#  reading the detail file, and queues the packets for a later
154 
	#  retransmission.  The Post-Proxy-Type "Fail" handler is NOT
155 
	#  called.
156 
	#
157 
	#  When the home servers come back up, the packets are forwarded,
158 
	#  and the detail file processed as normal.
159 
	accounting {
160 
		# You may want accounting policies here...
161 
 
162 
		update control {
163 
			Proxy-To-Realm := "acct_realm.example.com"
164 
		}
165 
	}
166 
 
167 
}