This manual page is for Mac OS X Server version 10.6.3

If you are running Mac OS X (client), this command is not available.

If you are running a different version of Mac OS X Server, view the documentation locally:

  • In Xcode

  • In Terminal, using the man(1) command

Reading manual pages

Manual pages are intended as a quick reference for people who already understand a technology.

  • For more information about the manual page format, see the manual page for manpages(5).

  • For more information about this technology, look for other documentation in the Apple Reference Library.

  • For general information about writing shell scripts, read Shell Scripting Primer.



RADRELAY(8)                                   FreeRADIUS Daemon                                  RADRELAY(8)



NAME
       radrelay -- Deprecated command.

DESCRIPTION
       The  functions  of  radrelay have been added to radiusd.  One benefit is that one instance of radiusd
       can read multiple detail files, among others.

       The rlm_sql_log module does something similar, but for SQL queries.  See it's man page for details.

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.

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  data-base database
       base with a few minutes delay, without any harm being done.

       See raddb/sites-available/copy-to-home-server for more information.

SEE ALSO
       radiusd(8), rlm_sql_log(5)

AUTHOR
       The FreeRADIUS Server Project



                                               23 October 2007                                   RADRELAY(8)

Reporting Problems

The way to report a problem with this manual page depends on the type of problem:

Content errors
Report errors in the content of this documentation with the feedback links below.
Bug reports
Report bugs in the functionality of the described tool or API through Bug Reporter.
Formatting problems
Report formatting mistakes in the online version of these pages with the feedback links below.

Did this document help you? Yes It's good, but... Not helpful...