radzap(1) [centos man page]

RADZAP(1)							 FreeRadius Daemon							 RADZAP(1)

NAME

       radzap - remove rogue entries from the active sessions database

SYNOPSIS

       radzap [-d raddb_directory] [-h] [-N nas_ip_address] [-P nas_port] [-u user] [-U user] [-x] server[:port] secret

DESCRIPTION

       The  FreeRadius	server can be configured to maintain an active session database in a file called radutmp. Commands like radwho(1) use this
       database. Sometimes that database can get out of sync, and then it might contain rogue entries. radzap can clean up this database.

       As of FreeRADIUS 1.1.0, radzap is a simple shell-script wrapper around radwho(1) and radclient(1).

       The sessions are "zapped" by sending an Accounting-Request packet which contains the information necessary for the  server  to  delete  the
       session	record.   radzap  sends a packet to the server, rather than writing to radutmp directly, because session records may also be main-
       tained in SQL.

OPTIONS

       -d raddb_directory
	      The directory that contains the RADIUS configuration files.  radzap reads radiusd.conf to determine  the	location  of  the  radutmp
	      file.

       -h     Print usage help information.

       -N nas_ip_address
	      Zap the entries which match the given NAS IP address.

       -P nas_port
	      Zap the entries which match the given NAS port.

       -u user
	      Zap the entries which match the given username (case insensitive).

       -U user
	      Zap the entries which match the given username (case sensitive).

       -x     Enable debugging output.

       server[:port]
	      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 /etc/services. The service name looked for is radacct for accounting packets, and radius for all other requests. If a  service
	      is not found in /etc/services, 1813 and 1812 are used respectively.

       secret The  shared  secret  for	this client.  It needs to be defined on the radius server side too, for the IP address you are sending the
	      radius packets from.

SEE ALSO

       radwho(1), radclient(1), radiusd(8), radiusd.conf(5).

AUTHOR

       Alan DeKok <aland@ox.org>

								   8 April 2005 							 RADZAP(1)

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)