118 lines
4.4 KiB
Plaintext
118 lines
4.4 KiB
Plaintext
{
|
|
# PROXY CONFIGURATION
|
|
#
|
|
# proxy_requests: Turns proxying of RADIUS requests on or off.
|
|
#
|
|
# The server has proxying turned on by default. If your system is NOT
|
|
# set up to proxy requests to another server, then you can turn proxying
|
|
# off here. This will save a small amount of resources on the server.
|
|
#
|
|
# If you have proxying turned off, and your configuration files say
|
|
# to proxy a request, then an error message will be logged.
|
|
#
|
|
# To disable proxying, change the "yes" to "no", and comment the
|
|
# $INCLUDE line.
|
|
#
|
|
# allowed values: \{no, yes\}
|
|
}
|
|
proxy_requests = no
|
|
$INCLUDE $\{confdir\}/proxy.conf
|
|
{
|
|
# CLIENTS CONFIGURATION
|
|
#
|
|
# Client configuration is defined in "clients.conf".
|
|
#
|
|
# The 'clients.conf' file contains all of the information from the old
|
|
# 'clients' and 'naslist' configuration files. We recommend that you
|
|
# do NOT use 'client's or 'naslist', although they are still
|
|
# supported.
|
|
#
|
|
# Anything listed in 'clients.conf' will take precedence over the
|
|
# information from the old-style configuration files.
|
|
}
|
|
$INCLUDE $\{confdir\}/clients.conf
|
|
{
|
|
# THREAD POOL CONFIGURATION
|
|
#
|
|
# The thread pool is a long-lived group of threads which
|
|
# take turns (round-robin) handling any incoming requests.
|
|
#
|
|
# You probably want to have a few spare threads around,
|
|
# so that high-load situations can be handled immediately. If you
|
|
# don't have any spare threads, then the request handling will
|
|
# be delayed while a new thread is created, and added to the pool.
|
|
#
|
|
# You probably don't want too many spare threads around,
|
|
# otherwise they'll be sitting there taking up resources, and
|
|
# not doing anything productive.
|
|
#
|
|
# The numbers given below should be adequate for most situations.
|
|
}
|
|
thread pool \{
|
|
{ # Number of servers to start initially --- should be a reasonable
|
|
# ballpark figure.
|
|
} start_servers = 5
|
|
{
|
|
# Limit on the total number of servers running.
|
|
#
|
|
# If this limit is ever reached, clients will be LOCKED OUT, so it
|
|
# should NOT BE SET TOO LOW. It is intended mainly as a brake to
|
|
# keep a runaway server from taking the system with it as it spirals
|
|
# down...
|
|
#
|
|
# You may find that the server is regularly reaching the
|
|
# 'max_servers' number of threads, and that increasing
|
|
# 'max_servers' doesn't seem to make much difference.
|
|
#
|
|
# If this is the case, then the problem is MOST LIKELY that
|
|
# your back-end databases are taking too long to respond, and
|
|
# are preventing the server from responding in a timely manner.
|
|
#
|
|
# The solution is NOT do keep increasing the 'max_servers'
|
|
# value, but instead to fix the underlying cause of the
|
|
# problem: slow database, or 'hostname_lookups=yes'.
|
|
#
|
|
# For more information, see 'max_request_time', above.
|
|
} max_servers = 32
|
|
{
|
|
# Server-pool size regulation. Rather than making you guess
|
|
# how many servers you need, FreeRADIUS dynamically adapts to
|
|
# the load it sees, that is, it tries to maintain enough
|
|
# servers to handle the current load, plus a few spare
|
|
# servers to handle transient load spikes.
|
|
#
|
|
# It does this by periodically checking how many servers are
|
|
# waiting for a request. If there are fewer than
|
|
# min_spare_servers, it creates a new spare. If there are
|
|
# more than max_spare_servers, some of the spares die off.
|
|
# The default values are probably OK for most sites.
|
|
} min_spare_servers = 3
|
|
max_spare_servers = 10
|
|
{
|
|
# There may be memory leaks or resource allocation problems with
|
|
# the server. If so, set this value to 300 or so, so that the
|
|
# resources will be cleaned up periodically.
|
|
#
|
|
# This should only be necessary if there are serious bugs in the
|
|
# server which have not yet been fixed.
|
|
#
|
|
# '0' is a special value meaning 'infinity', or 'the servers never
|
|
# exit'
|
|
} max_requests_per_server = 0
|
|
{
|
|
# If the received PPS is larger than the processed PPS, *and*
|
|
# the queue is more than half full, then new accounting
|
|
# requests are probabilistically discarded. This lowers the
|
|
# number of packets that the server needs to process. Over
|
|
# time, the server will "catch up" with the traffic.
|
|
#
|
|
# Throwing away accounting packets is usually safe and low
|
|
# impact. The NAS will retransmit them in a few seconds, or
|
|
# even a few minutes. Vendors should read RFC 5080 Section 2.2.1
|
|
# to see how accounting packets should be retransmitted. Using
|
|
# any other method is likely to cause network meltdowns.
|
|
#
|
|
} auto_limit_acct = no
|
|
|
|
\}
|