From: Jorge Pereira Date: Fri, 3 May 2019 21:15:09 +0000 (-0300) Subject: Update raddb/sites-available/buffered-sql X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=d3a53a1e0352e40169daaadef2bb92be0fe05157;p=thirdparty%2Ffreeradius-server.git Update raddb/sites-available/buffered-sql --- diff --git a/raddb/sites-available/buffered-sql b/raddb/sites-available/buffered-sql index cdd35fc6eb1..89cdd2469fd 100644 --- a/raddb/sites-available/buffered-sql +++ b/raddb/sites-available/buffered-sql @@ -1,159 +1,173 @@ # -*- text -*- +# +# :toc: +# +# $Id$ + ###################################################################### # -# 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. +# = Buffered SQL # -# In this example, the detail file is read, and the data -# is put into SQL. This configuration is used when a RADIUS -# server on this machine is receiving accounting packets, -# and writing them to the detail file. +# 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. # -# The purpose of this virtual server is to de-couple the storage -# of long-term accounting data in SQL from "live" information -# needed by the RADIUS server as it is running. +# In this example, the `detai` file is read, and the data +# is put into SQL. This configuration is used when a RADIUS +# server on this machine is receiving accounting packets, +# and writing them to the detail file. # -# The benefit of this approach is that for a busy server, the -# overhead of performing SQL queries may be significant. Also, -# if the SQL databases are large (as is typical for ones storing -# months of data), the INSERTs and UPDATEs may take a relatively -# long time. Rather than slowing down the RADIUS server by -# having it interact with a database, you can just log the -# packets to a detail file, and then read that file later at a -# time when the RADIUS server is typically lightly loaded. +# The purpose of this virtual server is to de-couple the storage +# of long-term accounting data in SQL from "live" information +# needed by the RADIUS server as it is running. # -# If you use on virtual server to log to the detail file, -# and another virtual server (i.e. this one) to read from -# the detail file, then this process will happen automatically. -# A sudden spike of RADIUS traffic means that the detail file -# will grow in size, and the server will be able to handle -# large volumes of traffic quickly. When the traffic dies down, -# the server will have time to read the detail file, and insert -# the data into a long-term SQL database. +# The benefit of this approach is that for a busy server, the +# overhead of performing SQL queries may be significant. Also, +# if the SQL databases are large (as is typical for ones storing +# months of data), the `INSERTs` and `UPDATEs` may take a relatively +# long time. Rather than slowing down the RADIUS server by +# having it interact with a database, you can just log the +# packets to a detail file, and then read that file later at a +# time when the RADIUS server is typically lightly loaded. # -# $Id$ +# If you use on virtual server to log to the detail file, +# and another virtual server (i.e. this one) to read from +# the detail file, then this process will happen automatically. +# A sudden spike of RADIUS traffic means that the detail file +# will grow in size, and the server will be able to handle +# large volumes of traffic quickly. When the traffic dies down, +# the server will have time to read the detail file, and insert +# the data into a long-term SQL database. # -###################################################################### +# +# # Default instance +# server buffered-sql { + # + # ## listen { ... } + # listen { + # + # type:: It should be `detail`. + # type = detail - # 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. + # + # filename:: The location where the detail file is located. + # + # IMPORTANT: 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. # 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:: + # + # 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 server will try to keep the + # percentage of time taken by "detail" file entries to `load_factor` percentage of + # the CPU time. + # + # NOTE: 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. + # + # allowed values: `1 to 100` # load_factor = 10 # - # Set the interval for polling the detail file. - # If the detail file doesn't exist, the server will - # wake up, and poll for it every N seconds. + # poll_interval:: Interval for polling the detail file. + # + # If the detail file doesn't exist, the server will wake up, and poll for it every N seconds. # - # Useful range of values: 1 to 60 + # Useful range of values: `1 to 60` # poll_interval = 1 # - # Set the retry interval for when the home server - # does not respond. The current packet will be - # sent repeatedly, at this interval, until the - # home server responds. + # retry_interval:: Set the retry interval for when the home server does not respond. + # + # The current packet will be sent repeatedly, at this interval, until the home server responds. # - # Useful range of values: 5 to 30 + # Useful range of values: `5 to 30` # retry_interval = 30 # - # 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. + # track:: 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. # - # Setting "track = yes" means it will skip packets which - # have already been processed. The default is "no". + # The default is `no`. # - # track = yes +# track = yes # - # In some circumstances it may be desirable for the - # server to start up, process a detail file, and - # immediately quit. To do this enable the "one_shot" - # option below. + # one_shot:: # - # Do not enable this for normal server operation. The - # default is "no". + # In some circumstances it may be desirable for the server to start up, process a detail file, + # and immediately quit. To do this enable the `one_shot` option below. # - # one_shot = no + # NOTE: Do not enable this for normal server operation. + # + # The default is `no`. + # +# one_shot = no } # - # Pre-accounting. Decide which accounting type to use. + # ## recv Accounting-Request + # + # Pre-accounting. Decide which accounting type to use. # recv Accounting-Request { # - # Ensure that we have a semi-unique identifier for every - # request, and many NAS boxes are broken. + # Ensure that we have a semi-unique identifier for every request, and many NAS + # boxes are broken. + # acct_unique # - # Read the 'acct_users' file. This isn't always - # necessary, and can be deleted if you do not use it. + # 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. + # ## send Accounting-Response + # + # Accounting. Log the accounting data. # send Accounting-Response { # # Log traffic to an SQL database. # - # See "Accounting queries" in sql.conf - # sql - + # See `Accounting queries` in `mods-config/sql/main/$driver/queries.conf` + # +# sql + # # Cisco VoIP specific bulk accounting - # pgsql-voip - + # +# pgsql-voip } - - # The requests are not being proxied, so no pre/post-proxy - # sections are necessary. }