I have performed the following actions, however, the listener files are still being deleted when the home accounting server is down. Alan DeKok wrote:
1) Don't write to the detail file twice.
I have commented out ALL detail lines from all active configuration files (including sites-enabled/default) except for the one that corresponds to the robust-proxy-accounting example.
See raddb/sites-available/robust-proxy-accounting.
My configuration matches robust-proxy-accounting as much as it can and still work in my site (see attached).
Note that the listen section that reads from the detail file is in a virtual server. AND the "accounting" section for that virtual server does NOT log to the detail file.
The accounting section for that virtual server matches robust-proxy-accounting.
2) Ensure that only the "accounting" section is logging to the detail file, and not any others.
Done. I have attached my site configuration for reference. Jim L. # -*- 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. # # $Id$ # ###################################################################### # Authentication Servers ###################################################################### home_server auth_home1.imaginenet.net { type = auth ipaddr = 192.168.78.115 port = 1812 secret = xxxxxxxx # Mark this home server alive ONLY when it starts being responsive status_check = status-server # Set the response timeout aggressively low. # You MAY have to increase this, depending on tests with # your local installation. response_window = 6 # response_window = 20 # zombie_period = 40 # revive_interval = 120 # check_interval = 30 # num_answers_to_alive = 3 } home_server auth_home2.imaginenet.net { type = auth ipaddr = 192.168.78.6 port = 1812 secret = xxxxxxxx # Mark this home server alive ONLY when it starts being responsive status_check = status-server # Set the response timeout aggressively low. # You MAY have to increase this, depending on tests with # your local installation. response_window = 6 # response_window = 20 # zombie_period = 40 # revive_interval = 120 # check_interval = 30 # num_answers_to_alive = 3 } home_server_pool auth_pool.imaginenet { type = load-balance # type = fail-over home_server = auth_home1.imaginenet.net home_server = auth_home2.imaginenet.net } # Accounting Servers ###################################################################### home_server acct_home1.imaginenet.net { type = acct ipaddr = 192.168.78.115 port = 1813 secret = xxxxxxxx # Mark this home server alive ONLY when it starts being responsive status_check = status-server # Set the response timeout aggressively low. # You MAY have to increase this, depending on tests with # your local installation. response_window = 6 # response_window = 20 # zombie_period = 40 # revive_interval = 120 # check_interval = 30 # num_answers_to_alive = 3 } home_server acct_detail.imaginenet { virtual_server = acct_detail.imaginenet } home_server_pool acct_pool.imaginenet { type = load-balance # type = fail-over home_server = acct_home1.imaginenet.net # If all home servers are down, try a home server that is a local virtual server. fallback = acct_detail.imaginenet # for pre/post-proxy policies virtual_server = ImagineNet } # Realms ###################################################################### realm imaginenet.net { auth_pool = auth_pool.imaginenet acct_pool = acct_pool.imaginenet nostrip } realm linkup.us { auth_pool = auth_pool.imaginenet acct_pool = acct_pool.imaginenet nostrip } # (3) Define a realm for these home servers. # It should NOT be used as part of normal proxying decisions! realm acct_realm.imaginenet { acct_pool = acct_pool.imaginenet nostrip } # Detail File Writer ###################################################################### # (4) Define a detail file writer. # raddb/modules/imaginenet contains the following #detail detail.imaginenet { # detailfile = ${radacctdir}/ImagineNet/detail-%Y%m%d:%H #} # (5) Define the virtual server to write the packets to the detail file # This will be called when ALL home servers are down, because of the # "fallback" configuration in the home server pool. server acct_detail.imaginenet { #preacct { # attr_filter.imaginenet #} accounting { #detail detail.imaginenet } } # (6) Define a virtual server to handle pre/post-proxy re-writing server ImagineNet { # 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}/ImagineNet/detail-*:*" #filename = "${radacctdir}/ImagineNet/detail-*" load_factor = 10 } 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 { detail.imaginenet } } # 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.imaginenet" } } }