Now that we have virtual servers, we don't need radrelay.conf
[freeradius.git] / man / man8 / radrelay.8
index 51dcaed..9cb61ec 100644 (file)
@@ -1,77 +1,49 @@
-.TH RADRELAY 1 "09 June 2002" "" "FreeRADIUS Daemon"
+.TH RADRELAY 8 "19 July 2005" "" "FreeRADIUS Daemon"
 .SH NAME
-radrelay -- replicate accounting data to another RADIUS server
-.SH SYNOPSIS
-.B radrelay
-.RB [ \-a
-.IR accounting_dir ]
-.RB [ \-d
-.IR radius_dir ]
-.RB [ \-f ]
-.RB [ \-i
-.IR source_ip ]
-.RB [ \-n
-.IR shortname ]
-.RB [ \-r
-.IR remote-server[:port] ]
-.RB [ \-s
-.IR secret ]
-.RB [ \-S
-.IR secret_file ]
-.RB [ \-x ]
-\fIdetailfile\fP
+radrelay -- Deprecated command.
 .SH DESCRIPTION
-\fBRadrelay\fP reads a file in the \fIdetail\fP file format,
-reconstructs radius packets from it and sends them to a remote
-radius server. When end-of-file is reached, the file is truncated.
-\fBRadrelay\fP then waits for additional data to be written to
-the file, and starts over again.
+The functions of \fIradrelay\fP have been added to \fIradiusd\fP.  One
+benefit is that one instance of \fIradiusd\fP can read multiple detail
+files, among others.
 .PP
-
-.SH OPTIONS
-
-.IP "\-a \fIaccounting_directory\fP"
-The base directory to use to read the detail file from.
-
-.IP "\-d \fIradius_directory\fP"
-The base radius (raddb) directory, where the config files live.
-
-.IP \-f
-Do \fInot\fP fork and run in the background as a daemon.
-
-.IP "\-i \fIsource_ip\fP"
-The source IP address to use for sending radius packets.
-
-.IP "\-n \fIshortname\fP"
-The radius configuration files (most probably clients.conf), will be
-searched for a client section with 'shortname' set to the used argument.
-Both the server secret and the remote-server address are obtained in
-this way. Do not use the -r, -s or -S parameters in combination with -n.
-
-.IP "\-r \fIremote-server\fP"
-The hostname or IP address of the remote server. Optionally a UDP port
-can be specified. If no UDP port is specified, it is looked up in
-\fI/etc/services\fP. The service name looked for is \fBradacct\fP for
-accounting packets. If a service is not found in \fI/etc/services\fP,
-1813 is used. The -r parameter can't be used in combination with -n.
-
-.IP "\-s \fIsecret\fP"
-Remote server secret.
-
-.IP "\-S \fIsecret_file\fP"
-Read remote server secret from file, the file should contain
-nothing other then the plain-text secret.
-
-.IP \-x
-Enable debug mode, -x will activate radrelay internal debugging, -xx will
-also activate librad debugging.
-
-.IP "detailfile"
-The detail file to use, this will be appended to the base accounting
-directory.
-
+The \fIrlm_sql_log\fP module does something similar, but for SQL
+queries.  See it's man page for details.
+.SH "REPLICATION FOR BACKUPS"
+Many sites run multiple radius servers; at least one primary and one
+backup server. When the primary goes down, most NASes detect that and
+switch to the backup server.
+
+That will cause your accounting packets to go the the backup server -
+and some NASes don't even switch back to the primary server when it
+comes back up.
+
+The result is that accounting records are missed, and/or the
+administrator must jump through hoops in order to combine the
+different detail files from multiple servers. It also means that the
+session database ("radutmp", used for radwho and simultaneous use
+detection) gets out of sync.
+
+We solve this issue by "relaying" packets from one server to
+another, so they both have the same set of accounting data.
+
+See raddb/sites-available/buffered-sql for more information.
+.SH "BUFFERING FOR HIGH-LOAD SERVERS"
+If the RADIUS server suddenly receives a many accounting packets,
+there may be insufficient CPU power to process them all in a timely
+manner.  This problem is especially noticable when the accounting
+packets are going to a back-end database.
+
+Similarly, you may have one database that tracks "live" sessions, and
+another that tracks historical accounting data.  In that case,
+accessing the first database is fast, as it is small.  Accessing the
+second database many be slower, as it may contain multiple gigabytes
+of data.  In addition, writing to the first database in a timely
+manner is important, while data may be written to the second database
+with a few minutes delay, without any harm being done.
+
+See raddb/sites-available/copy-to-home-server for more information.
 .SH SEE ALSO
-radiusd(8),
-doc/radrelay.
+.BR radiusd(8),
+.BR rlm_sql_log(5)
 .SH AUTHOR
-Miquel van Smoorenburg, miquels@cistron.nl.
+The FreeRADIUS Server Project