Chetan Gaonker | 7f4bf74 | 2016-05-04 15:56:08 -0700 | [diff] [blame] | 1 | # -*- text -*- |
| 2 | ###################################################################### |
| 3 | # |
| 4 | # In 2.0.0, radrelay functionality is integrated into the |
| 5 | # server core. This virtual server gives an example of |
| 6 | # using radrelay functionality inside of the server. |
| 7 | # |
| 8 | # In this example, the detail file is read, and the data |
| 9 | # is put into SQL. This configuration is used when a RADIUS |
| 10 | # server on this machine is receiving accounting packets, |
| 11 | # and writing them to the detail file. |
| 12 | # |
| 13 | # The purpose of this virtual server is to de-couple the storage |
| 14 | # of long-term accounting data in SQL from "live" information |
| 15 | # needed by the RADIUS server as it is running. |
| 16 | # |
| 17 | # The benefit of this approach is that for a busy server, the |
| 18 | # overhead of performing SQL queries may be significant. Also, |
| 19 | # if the SQL databases are large (as is typical for ones storing |
| 20 | # months of data), the INSERTs and UPDATEs may take a relatively |
| 21 | # long time. Rather than slowing down the RADIUS server by |
| 22 | # having it interact with a database, you can just log the |
| 23 | # packets to a detail file, and then read that file later at a |
| 24 | # time when the RADIUS server is typically lightly loaded. |
| 25 | # |
| 26 | # If you use on virtual server to log to the detail file, |
| 27 | # and another virtual server (i.e. this one) to read from |
| 28 | # the detail file, then this process will happen automatically. |
| 29 | # A sudden spike of RADIUS traffic means that the detail file |
| 30 | # will grow in size, and the server will be able to handle |
| 31 | # large volumes of traffic quickly. When the traffic dies down, |
| 32 | # the server will have time to read the detail file, and insert |
| 33 | # the data into a long-term SQL database. |
| 34 | # |
| 35 | # $Id: bc5abe8e104accca792de61201c741d07e825894 $ |
| 36 | # |
| 37 | ###################################################################### |
| 38 | |
| 39 | server buffered-sql { |
| 40 | listen { |
| 41 | type = detail |
| 42 | |
| 43 | # The location where the detail file is located. |
| 44 | # This should be on local disk, and NOT on an NFS |
| 45 | # mounted location! |
| 46 | filename = "${radacctdir}/detail-*" |
| 47 | |
| 48 | # |
| 49 | # The server can read accounting packets from the |
| 50 | # detail file much more quickly than those packets |
| 51 | # can be written to a database. If the database is |
| 52 | # overloaded, then bad things can happen. |
| 53 | # |
| 54 | # The server will keep track of how long it takes to |
| 55 | # process an entry from the detail file. It will |
| 56 | # then pause between handling entries. This pause |
| 57 | # allows databases to "catch up", and gives the |
| 58 | # server time to notice that other packets may have |
| 59 | # arrived. |
| 60 | # |
| 61 | # The pause is calculated dynamically, to ensure that |
| 62 | # the load due to reading the detail files is limited |
| 63 | # to a small percentage of CPU time. The |
| 64 | # "load_factor" configuration item is a number |
| 65 | # between 1 and 100. The server will try to keep the |
| 66 | # percentage of time taken by "detail" file entries |
| 67 | # to "load_factor" percentage of the CPU time. |
| 68 | # |
| 69 | # If the "load_factor" is set to 100, then the server |
| 70 | # will read packets as fast as it can, usually |
| 71 | # causing databases to go into overload. |
| 72 | # |
| 73 | load_factor = 10 |
| 74 | |
| 75 | # |
| 76 | # Set the interval for polling the detail file. |
| 77 | # If the detail file doesn't exist, the server will |
| 78 | # wake up, and poll for it every N seconds. |
| 79 | # |
| 80 | # Useful range of values: 1 to 60 |
| 81 | poll_interval = 1 |
| 82 | |
| 83 | # |
| 84 | # Set the retry interval for when the home server |
| 85 | # does not respond. The current packet will be |
| 86 | # sent repeatedly, at this interval, until the |
| 87 | # home server responds. |
| 88 | # |
| 89 | # Useful range of values: 5 to 30 |
| 90 | retry_interval = 30 |
| 91 | |
| 92 | } |
| 93 | |
| 94 | # |
| 95 | # Pre-accounting. Decide which accounting type to use. |
| 96 | # |
| 97 | preacct { |
| 98 | preprocess |
| 99 | |
| 100 | # |
| 101 | # Ensure that we have a semi-unique identifier for every |
| 102 | # request, and many NAS boxes are broken. |
| 103 | acct_unique |
| 104 | |
| 105 | # |
| 106 | # Read the 'acct_users' file. This isn't always |
| 107 | # necessary, and can be deleted if you do not use it. |
| 108 | files |
| 109 | } |
| 110 | |
| 111 | # |
| 112 | # Accounting. Log the accounting data. |
| 113 | # |
| 114 | accounting { |
| 115 | # |
| 116 | # Log traffic to an SQL database. |
| 117 | # |
| 118 | # See "Accounting queries" in sql.conf |
| 119 | # sql |
| 120 | |
| 121 | |
| 122 | # Cisco VoIP specific bulk accounting |
| 123 | # pgsql-voip |
| 124 | |
| 125 | } |
| 126 | |
| 127 | # The requests are not being proxied, so no pre/post-proxy |
| 128 | # sections are necessary. |
| 129 | } |