ttls chbind: update VSA to use
[freeradius.git] / raddb / radiusd.conf.in
index 0dd0eab..be2d2f6 100644 (file)
@@ -1,6 +1,6 @@
 # -*- text -*-
 ##
-## radiusd.conf        -- FreeRADIUS server configuration file.
+## radiusd.conf        -- FreeRADIUS server configuration file - @RADIUSD_VERSION@
 ##
 ##     http://www.freeradius.org/
 ##     $Id$
@@ -66,6 +66,8 @@ name = radiusd
 
 #  Location of config and logfiles.
 confdir = ${raddbdir}
+certdir = ${confdir}/certs
+cadir   = ${confdir}/certs
 run_dir = ${localstatedir}/run/${name}
 
 # Should likely be ${localstatedir}/lib/radiusd
@@ -116,57 +118,6 @@ libdir = @libdir@
 #
 pidfile = ${run_dir}/${name}.pid
 
-#  chroot: directory where the server does "chroot".
-#
-#  The chroot is done very early in the process of starting the server.
-#  After the chroot has been performed it switches to the "user" listed
-#  below (which MUST be specified).  If "group" is specified, it switchs
-#  to that group, too.  Any other groups listed for the specified "user"
-#  in "/etc/group" are also added as part of this process.
-#
-#  The current working directory (chdir / cd) is left *outside* of the
-#  chroot until all of the modules have been initialized.  This allows
-#  the "raddb" directory to be left outside of the chroot.  Once the
-#  modules have been initialized, it does a "chdir" to ${logdir}.  This
-#  means that it should be impossible to break out of the chroot.
-#
-#  If you are worried about security issues related to this use of chdir,
-#  then simply ensure that the "raddb" directory is inside of the chroot,
-#  end be sure to do "cd raddb" BEFORE starting the server.
-#
-#  If the server is statically linked, then the only files that have
-#  to exist in the chroot are ${run_dir} and ${logdir}.  If you do the
-#  "cd raddb" as discussed above, then the "raddb" directory has to be
-#  inside of the chroot directory, too.
-#
-#chroot = /path/to/chroot/directory
-
-# user/group: The name (or #number) of the user/group to run radiusd as.
-#
-#   If these are commented out, the server will run as the user/group
-#   that started it.  In order to change to a different user/group, you
-#   MUST be root ( or have root privleges ) to start the server.
-#
-#   We STRONGLY recommend that you run the server with as few permissions
-#   as possible.  That is, if you're not using shadow passwords, the
-#   user and group items below should be set to radius'.
-#
-#  NOTE that some kernels refuse to setgid(group) when the value of
-#  (unsigned)group is above 60000; don't use group nobody on these systems!
-#
-#  On systems with shadow passwords, you might have to set 'group = shadow'
-#  for the server to be able to read the shadow password file.  If you can
-#  authenticate users while in debug mode, but not in daemon mode, it may be
-#  that the debugging mode server is running as a user that can read the
-#  shadow info, and the user listed below can not.
-#
-#  The server will also try to use "initgroups" to read /etc/groups.
-#  It will join all groups where "user" is a member.  This can allow
-#  for some finer-grained access controls.
-#
-#user = radius
-#group = radius
-
 #  max_request_time: The maximum time (in seconds) to handle a request.
 #
 #  Requests which take more time than this to process may be killed, and
@@ -256,10 +207,14 @@ listen {
        #  Note: "type = proxy" lets you control the source IP used for
        #        proxying packets, with some limitations:
        #
-       #    * Only ONE proxy listener can be defined.
        #    * A proxy listener CANNOT be used in a virtual server section.
        #    * You should probably set "port = 0".
        #    * Any "clients" configuration will be ignored.
+       #
+       #  See also proxy.conf, and the "src_ipaddr" configuration entry
+       #  in the sample "home_server" section.  When you specify the
+       #  source IP address for packets sent to a home server, the
+       #  proxy listeners are automatically created.
 
        #  IP address on which to listen.
        #  Allowed values are:
@@ -335,24 +290,6 @@ listen {
 #
 hostname_lookups = no
 
-#  Core dumps are a bad thing.  This should only be set to 'yes'
-#  if you're debugging a problem with the server.
-#
-#  allowed values: {no, yes}
-#
-allow_core_dumps = no
-
-#  Regular expressions
-#
-#  These items are set at configure time.  If they're set to "yes",
-#  then setting them to "no" turns off regular expression support.
-#
-#  If they're set to "no" at configure time, then setting them to "yes"
-#  WILL NOT WORK.  It will give you an error.
-#
-regular_expressions    = @REGEX@
-extended_expressions   = @REGEX_EXTENDED@
-
 #
 #  Logging section.  The various "log_*" configuration items
 #  will eventually be moved here.
@@ -446,6 +383,18 @@ log {
        #
        auth_badpass = no
        auth_goodpass = no
+
+       #  Log additional text at the end of the "Login OK" messages.
+       #  for these to work, the "auth" and "auth_goopass" or "auth_badpass"
+       #  configurations above have to be set to "yes".
+       #
+       #  The strings below are dynamically expanded, which means that
+       #  you can put anything you want in them.  However, note that
+       #  this expansion can be slow, and can negatively impact server
+       #  performance.
+       #
+#      msg_goodpass = ""
+#      msg_badpass = ""
 }
 
 #  The program to execute to do concurrency checks.
@@ -458,6 +407,74 @@ checkrad = ${sbindir}/checkrad
 #  of those attacks
 #
 security {
+       #  chroot: directory where the server does "chroot".
+       #
+       #  The chroot is done very early in the process of starting
+       #  the server.  After the chroot has been performed it
+       #  switches to the "user" listed below (which MUST be
+       #  specified).  If "group" is specified, it switches to that
+       #  group, too.  Any other groups listed for the specified
+       #  "user" in "/etc/group" are also added as part of this
+       #  process.
+       #
+       #  The current working directory (chdir / cd) is left
+       #  *outside* of the chroot until all of the modules have been
+       #  initialized.  This allows the "raddb" directory to be left
+       #  outside of the chroot.  Once the modules have been
+       #  initialized, it does a "chdir" to ${logdir}.  This means
+       #  that it should be impossible to break out of the chroot.
+       #
+       #  If you are worried about security issues related to this
+       #  use of chdir, then simply ensure that the "raddb" directory
+       #  is inside of the chroot, end be sure to do "cd raddb"
+       #  BEFORE starting the server.
+       #
+       #  If the server is statically linked, then the only files
+       #  that have to exist in the chroot are ${run_dir} and
+       #  ${logdir}.  If you do the "cd raddb" as discussed above,
+       #  then the "raddb" directory has to be inside of the chroot
+       #  directory, too.
+       #
+#      chroot = /path/to/chroot/directory
+
+       # user/group: The name (or #number) of the user/group to run radiusd as.
+       #
+       #   If these are commented out, the server will run as the
+       #   user/group that started it.  In order to change to a
+       #   different user/group, you MUST be root ( or have root
+       #   privleges ) to start the server.
+       #
+       #   We STRONGLY recommend that you run the server with as few
+       #   permissions as possible.  That is, if you're not using
+       #   shadow passwords, the user and group items below should be
+       #   set to radius'.
+       #
+       #  NOTE that some kernels refuse to setgid(group) when the
+       #  value of (unsigned)group is above 60000; don't use group
+       #  "nobody" on these systems!
+       #
+       #  On systems with shadow passwords, you might have to set
+       #  'group = shadow' for the server to be able to read the
+       #  shadow password file.  If you can authenticate users while
+       #  in debug mode, but not in daemon mode, it may be that the
+       #  debugging mode server is running as a user that can read
+       #  the shadow info, and the user listed below can not.
+       #
+       #  The server will also try to use "initgroups" to read
+       #  /etc/groups.  It will join all groups where "user" is a
+       #  member.  This can allow for some finer-grained access
+       #  controls.
+       #
+#      user = radius
+#      group = radius
+
+       #  Core dumps are a bad thing.  This should only be set to
+       #  'yes' if you're debugging a problem with the server.
+       #
+       #  allowed values: {no, yes}
+       #
+       allow_core_dumps = no
+
        #
        #  max_attributes: The maximum number of attributes
        #  permitted in a RADIUS packet.  Packets which have MORE
@@ -604,6 +621,23 @@ thread pool {
        min_spare_servers = 3
        max_spare_servers = 10
 
+       #  When the server receives a packet, it places it onto an
+       #  internal queue, where the worker threads (configured above)
+       #  pick it up for processing.  The maximum size of that queue
+       #  is given here.
+       #
+       #  When the queue is full, any new packets will be silently
+       #  discarded.
+       #
+       #  The most common cause of the queue being full is that the
+       #  server is dependent on a slow database, and it has received
+       #  a large "spike" of traffic.  When that happens, there is
+       #  very little you can do other than make sure the server
+       #  receives less traffic, or make sure that the database can
+       #  handle the load.
+       #
+#      max_queue_size = 65536
+
        #  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.
@@ -646,42 +680,13 @@ modules {
        #
 
        #
-       #  As of 2.0.5, most of the module configurations are in a
-       #  sub-directory.  Files matching the regex /[a-zA-Z0-9_.]+/
-       #  are loaded.  The modules are initialized ONLY if they are
-       #  referenced in a processing section, such as authorize,
-       #  authenticate, accounting, pre/post-proxy, etc.
-       #
-       $INCLUDE ${confdir}/modules/
-
-       #  Extensible Authentication Protocol
-       #
-       #  For all EAP related authentications.
-       #  Now in another file, because it is very large.
-       #
-       $INCLUDE eap.conf
-
-       #  Include another file that has the SQL-related configuration.
-       #  This is another file only because it tends to be big.
-       #
-#      $INCLUDE sql.conf
-
-       #
-       #  This module is an SQL enabled version of the counter module.
-       #
-       #  Rather than maintaining seperate (GDBM) databases of
-       #  accounting info for each counter, this module uses the data
-       #  stored in the raddacct table by the sql modules. This
-       #  module NEVER does any database INSERTs or UPDATEs.  It is
-       #  totally dependent on the SQL module to process Accounting
-       #  packets.
-       #
-#      $INCLUDE sql/mysql/counter.conf
-
-       #
-       #  IP addresses managed in an SQL table.
+       #  As of 3.0, modules are in mods-enabled/.  Files matching
+       #  the regex /[a-zA-Z0-9_.]+/ are loaded.  The modules are
+       #  initialized ONLY if they are referenced in a processing
+       #  section, such as authorize, authenticate, accounting,
+       #  pre/post-proxy, etc.
        #
-#      $INCLUDE sqlippool.conf
+       $INCLUDE ${confdir}/mods-enabled/
 }
 
 # Instantiation
@@ -755,6 +760,14 @@ $INCLUDE policy.conf
 
 ######################################################################
 #
+#  SNMP notificiations.  Uncomment the following line to enable
+#  snmptraps.  Note that you MUST also configure the full path
+#  to the "snmptrap" command in the "trigger.conf" file.
+#
+#$INCLUDE trigger.conf
+
+######################################################################
+#
 #      Load virtual servers.
 #
 #      This next $INCLUDE line loads files in the directory that