A Logo

Feel free to include my content in your page via my
RSS feed

Help Irongeek.com pay for
bandwidth and research equipment:

Search Irongeek.com:

Affiliates:
Irongeek Button
Social-engineer-training Button

Help Irongeek.com pay for bandwidth and research equipment:

paypalpixle


Man page of rlm_sql_log

rlm_sql_log

Section: FreeRADIUS Module (5)
Updated: 28 May 2005
Index of this MAN page

Back To MAN Pages From BackTrack 5 R1 Master List  

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 databases 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 database 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 dictionary.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>


 

Index

NAME
DESCRIPTION
LIMITATIONS
CONFIGURATION
SECTIONS
FILES
SEE ALSO
AUTHOR

This document was created by man2html, using the manual pages.
Time: 07:34:21 GMT, September 13, 2011

Printable version of this article

15 most recent posts on Irongeek.com:


If you would like to republish one of the articles from this site on your webpage or print journal please contact IronGeek.

Copyright 2016, IronGeek
Louisville / Kentuckiana Information Security Enthusiast