radrelay(8) [centos man page]

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  man-
       ner.  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.

SEE ALSO

       radiusd(8), rlm_sql_log(5)

AUTHOR

       The FreeRADIUS Server Project

								  23 October 2007						       RADRELAY(8)

rlm_sql_log(5)							 FreeRADIUS Module						    rlm_sql_log(5)

NAME

       rlm_sql_log - FreeRADIUS Module

DESCRIPTION

       The rlm_sql_log module appends the SQL queries in a log file which is read later by the scripts/radsqlrelay Perl program.

       The  purpose  of  this  module is to de-couple the storage of long-term accounting data in SQL from "live" information needed by the RADIUS
       server as it's running.	If you are not using SQL for simultaneous login restrictions (i.e. "sql" is not listed in the "session" section of
       "radiusd.conf"), then this module allows you to log SQL queries to a file, and then process them at your leisure.

       The  benefit of this approach is that for a busy server, the overhead of performing SQL qeuries may be significant.  Also, if the SQL data-
       bases are large (as is typical for ones storing months of data), the INSERTs and UPDATEs may take a  relatively	long  time.   Rather  than
       slowing down the RADIUS server by having it interact with a database, you can just log the queries to a file, and then run those queries on
       another machine, or at a time when the RADIUS server is typically lightly loaded.

       If the "sql" module is listed in the "session" section of "radiusd.conf", then a similar system can still be used.  In that case, one data-
       base  would  be	used to maintain "live" session information.  That database would be small, fast, and information would be deleted from it
       when a user logs out.  A second database would store long-term accounting information, as described above.

LIMITATIONS

       This module only performs the dynamic expansion of the variables found in the SQL statements. No operation  is  executed  on  the  database
       server.	(this would be done later by an external program) That means the module is useful only with non-"SELECT" statements.

CONFIGURATION

       The main configuration items to be aware of are the path of the log file and the different SQL queries.

       path   An  entry  named	"path"	sets  the  full path of the file where the SQL queries are recorded. (this variable is run through dynamic
	      string expansion, and can include FreeRADIUS variables to create a dynamic filename)

       Accounting queries
	      When a accounting record is processed, the module searches a config entry keyed by the Acct-Status-Type  attribute  present  in  the
	      packet. For example, the SQL to be run on an accounting start must be named "Start" in the configuration for the module. Other usual
	      values for Acct-Status-Type are "Stop", "Alive",	"Accounting-On",  etc.	 See  the  VALUEs  for	Acct-Status-Type  in  the  dictio-
	      nary.rfc2866 file.

       Post-Auth query
	      An  entry  named	"Post-Auth" sets the query to run during the post-authentication stage.  This query is mainly used to log sessions
	      where there may not be a later accounting packet.

       modules {
	 ...
	 sql_log {
	   path = "${radacctdir}/sql-relay"
	   acct_table = "radacct"
	   postauth_table = "radpostauth"
	   sql_user_name = "%{%{User-Name}:-DEFAULT}"

	   Start = "INSERT INTO ${acct_table} ..."
	   Stop = "UPDATE ${acct_table} SET ..."
	   Alive = "UPDATE ${acct_table} SET ..."

	   Post-Auth = "INSERT INTO ${postauth_table} ..."
	 }
	 ...
       }

       accounting {
	 ...
	 sql_log
	 ...
       }

       post-auth {
	 ...
	 sql_log
	 ...
       }

SECTIONS

       accounting, post-auth

FILES

       /etc/raddb/radiusd.conf

SEE ALSO

       radsqlrelay(8), radiusd(8), radiusd.conf(5)

AUTHOR

       Nicolas Baradakis <nicolas.baradakis@cegetel.net>

								    28 May 2005 						    rlm_sql_log(5)