summaryrefslogtreecommitdiffstats
path: root/raddb/sites-available/robust-proxy-accounting
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--raddb/sites-available/robust-proxy-accounting177
1 files changed, 177 insertions, 0 deletions
diff --git a/raddb/sites-available/robust-proxy-accounting b/raddb/sites-available/robust-proxy-accounting
new file mode 100644
index 0000000..7371643
--- /dev/null
+++ b/raddb/sites-available/robust-proxy-accounting
@@ -0,0 +1,177 @@
+# -*- text -*-
+######################################################################
+#
+# This is a sample configuration for robust proxy accounting.
+# accounting packets are proxied, OR logged locally if all
+# home servers are down. When the home servers come back up,
+# the accounting packets are forwarded.
+#
+# This method enables the server to proxy all packets to the
+# home servers when they're up, AND to avoid writing to the
+# detail file in most situations.
+#
+# In most situations, proxying of accounting messages is done
+# in a "pass-through" fashion. If the home server does not
+# respond, then the proxy server does not respond to the NAS.
+# That means that the NAS must retransmit packets, sometimes
+# forever. This example shows how the proxy server can still
+# respond to the NAS, even if all home servers are down.
+#
+# This configuration could be done MUCH more simply if ALL
+# packets were written to the detail file. But that would
+# involve a lot more disk writes, which may not be a good idea.
+#
+# This file is NOT meant to be used as-is. It needs to be
+# edited to match your local configuration.
+#
+# Please see the sites-available/default file, in the
+# "Post-Proxy-Type Fail-Accounting" section. That should be
+# configured to write packets to the "detail.example.com"
+# file when proxying fails. The "listen" section below will
+# then read packets from that file, and proxy them.
+#
+# See also mods-available/detail.example.com, which is the
+# module that writes the "detail.example.com" file.
+#
+#
+# $Id$
+#
+######################################################################
+
+# (1) Define two home servers.
+home_server home1.example.com {
+ type = acct
+ ipaddr = 192.0.2.10
+ port = 1813
+ secret = testing123
+
+ # Mark this home server alive ONLY when it starts being responsive
+ status_check = request
+ username = "test_user_status_check"
+
+ # Set the response timeout aggressively low.
+ # You MAY have to increase this, depending on tests with
+ # your local installation.
+ response_window = 6
+}
+
+home_server home2.example.com {
+ type = acct
+ ipaddr = 192.0.2.20
+ port = 1813
+ secret = testing123
+
+ # Mark this home server alive ONLY when it starts being responsive
+ status_check = request
+ username = "test_user_status_check"
+
+ # Set the response timeout aggressively low.
+ # You MAY have to increase this, depending on tests with
+ # your local installation.
+ response_window = 6
+}
+
+# (2) Put all of the servers into a pool.
+home_server_pool acct_pool.example.com {
+ type = load-balance # other types are OK, too.
+
+ home_server = home1.example.com
+ home_server = home2.example.com
+ # add more home_server's here.
+
+ # for pre/post-proxy policies
+ virtual_server = home.example.com
+}
+
+# (3) Define a realm for these home servers.
+# It should NOT be used as part of normal proxying decisions!
+realm acct_realm.example.com {
+ acct_pool = acct_pool.example.com
+}
+
+# (4) Define a detail file writer.
+# See raddb/modules/detail.example.com
+
+# (5) Define a virtual server to handle pre/post-proxy re-writing
+server home.example.com {
+ pre-proxy {
+ # Insert pre-proxy rules here
+ }
+
+ post-proxy {
+ # Insert post-proxy rules here
+
+ # This will be called when the CURRENT packet failed
+ # to be proxied. This may happen when one home server
+ # suddenly goes down, even though another home server
+ # may be alive.
+ #
+ # i.e. the current request has run out of time, so it
+ # cannot fail over to another (possibly) alive server.
+ #
+ # We want to respond to the NAS, so that it can stop
+ # re-sending the packet. We write the packet to the
+ # "detail" file, where it will be read, and sent to
+ # another home server.
+ #
+ Post-Proxy-Type Fail-Accounting {
+ detail.example.com
+
+ # Now that the packet has been stored
+ # mark that we can respond to the NAS
+ acct_response
+ }
+
+ #
+ # This section is run when there are problems
+ # proxying Access-Request packets
+ #
+ Post-Proxy-Type Fail-Authentication {
+ # add policies here
+ }
+
+ }
+
+
+ # Read accounting packets from the detail file(s) for
+ # the home server.
+ #
+ # Note that you can have only ONE "listen" section reading
+ # detail files from a particular directory. That is why the
+ # destination host name is used as part of the directory name
+ # below. Having two "listen" sections reading detail files
+ # from the same directory WILL cause problems. The packets
+ # may be read by one, the other, or both "listen" sections.
+ listen {
+ type = detail
+ filename = "${radacctdir}/detail.example.com/detail-*:*"
+
+ #
+ # See sites-available/buffered-sql for documentation
+ # on the configuration items for a detail listener.
+ #
+ load_factor = 90
+ track = yes
+ }
+
+ # All packets read from the detail file are proxied back to
+ # the home servers.
+ #
+ # The normal pre/post-proxy rules are applied to them, too.
+ #
+ # If the home servers are STILL down, then the server stops
+ # reading the detail file, and queues the packets for a later
+ # retransmission. The Post-Proxy-Type "Fail" handler is NOT
+ # called.
+ #
+ # When the home servers come back up, the packets are forwarded,
+ # and the detail file processed as normal.
+ accounting {
+ # You may want accounting policies here...
+
+ update control {
+ &Proxy-To-Realm := 'acct_realm.example.com'
+ }
+ }
+
+}