man/man5/radrelay.conf.5

   1 .\"     # DS - begin display
   2 .de DS
   3 .RS
   4 .nf
   5 .sp
   6 ..
   7 .\"     # DE - end display
   8 .de DE
   9 .fi
  10 .RE
  11 .sp
  12 ..
  13 .TH radrelay.conf 5 "27 May 2005" "" "FreeRADIUS configuration file"
  14 .SH NAME
  15 radrelay.conf \- configuration file for the FreeRADIUS server "radrelay" personality
  16 .SH DESCRIPTION
  17 The \fBradrelay.conf\fP file resides in the radius database directory,
  18 by default \fB/etc/raddb\fP.  It defines the global configuration for
  19 the FreeRADIUS server, when the server is operating as "radrelay".
  20 .SH "FILE FORMAT"
  21 For a detailed description of the file format, see "man radiusd.conf".
  22 The configuration entries are much the same for radrelay.conf, with a
  23 few differences as noted here.
  24 .SH "REPLICATION FOR BACKUPS"
  25 Many sites run multiple radius servers; at least one primary and one
  26 backup server. When the primary goes down, most NASes detect that and
  27 switch to the backup server.
  28
  29 That will cause your accounting packets to go the the backup server -
  30 and some NASes don't even switch back to the primary server when it
  31 comes back up.
  32
  33 The result is that accounting records are missed, and/or the
  34 administrator must jump through hoops in order to combine the
  35 different detail files from multiple servers. It also means that the
  36 session database ("radutmp", used for radwho and simultaneous use
  37 detection) gets out of sync.
  38
  39 radrelay solves this issue by "relaying" packets from one server to
  40 another, so they both have the same set of accounting data.
  41 .SH "BUFFERING FOR HIGH-LOAD SERVERS"
  42 If the RADIUS server suddenly receives a many accounting packets,
  43 there may be insufficient CPU power to process them all in a timely
  44 manner.  This problem is especially noticable when the accounting
  45 packets are going to a back-end database.
  46
  47 Similarly, you may have one database that tracks "live" sessions, and
  48 another that tracks historical accounting data.  In that case,
  49 accessing the first database is fast, as it is small.  Accessing the
  50 second database many be slower, as it may contain multiple gigabytes
  51 of data.  In addition, writing to the first database in a timely
  52 manner is important, while data may be written to the second database
  53 with a few minutes delay, without any harm being done.
  54 .SH "RELAYING OF ACCOUNTING PACKETS"
  55 The \fBradrelay.conf\fP file controls the "radrelay" personality of
  56 the server, which can perform both of the functions above at the same
  57 time.
  58 .SH USAGE
  59 First, you should configure the main radius server to log to an extra,
  60 single detail file.  This may be done by adding an extra instance of
  61 the detail module to \fBradiusd.conf\fP:
  62
  63 For example:
  64
  65 .DS
  66         detail radrelay-detail {
  67 .br
  68                 detailfile = ${radacctdir}/radrelay/detail
  69 .br
  70                 detailperm = 0600
  71 .br
  72                 dirperm = 0755
  73 .br
  74                 locking = yes
  75 .br
  76         }
  77 .br
  78         ...
  79 .br
  80         accounting {
  81 .br
  82                 ...
  83 .br
  84                 radrelay-detail
  85 .br
  86                 ...
  87 .br
  88         }
  89 .br
  90 .DE
  91 This configuration will cause accounting packets to be logged to the
  92 \fI${radacctdir}/radrelay/detail\fP file.  This file should not be
  93 rotated by standard log rotation scripts, as the \fBradrelay\fP
  94 program will read and rotate it.
  95 .SH RADRELAY.CONF EXAMPLE
  96 See the \fBradrelay.conf\fP file for detailed instructions on
  97 configuration entries, what they mean, and how to use them.
  98
  99 To have the "radrelay" portion of the server read the above detail
 100 file, configure \fBradrelay.conf\fP with the following section:
 101
 102 .DS
 103 .br
 104         listen {
 105 .br
 106                 type = detail
 107 .br
 108                 detail = ${radacctdir}/radrelay/detail
 109 .br
 110                 max_outstanding = 100
 111 .br
 112                 identity = radrelay
 113 .br
 114         }
 115 .br
 116 .DE
 117
 118 The server will read the accounting packets from the detail file, and
 119 process them just as if it had received them from the NAS.  Therefore,
 120 you should configure the "accounting" section of \fBradrelay.conf\fP
 121 to write the accounting records to an "sql" module, or to proxy them
 122 to another RADIUS server.
 123
 124 Then, start the server via the following command:
 125
 126 $ radiusd -n radrelay
 127
 128 The server should start up, read the detail file, and process
 129 accounting packets from it.
 130 .SH NOTES
 131 The \fBradiusd.conf\fP file is not read at all when the server is
 132 running as radrelay.  Please edit \fBradrelay.conf\fP.
 133 .SH CREDITS
 134 The original "radrelay" program was written by Miquel van Smoorenburg
 135 for the Cistron radius project, and ported to FreeRADIUS by Simon
 136 Ekstrand.  The "radsqlrelay" was written by Kostas Kalavras.  It was
 137 never released as part of an offical FreeRADIUS release, but served as
 138 a basis for the design of this implementation.
 139 .PP
 140 .SH FILES
 141 /etc/raddb/radrelay.conf
 142 .SH "SEE ALSO"
 143 .BR radiusd (8),
 144 .BR radiusd.conf (5)
 145 .SH AUTHOR
 146 Alan DeKok <aland@ox.org>