rlm_dbm_parse(8) [debian man page]
RLM_DBM_PARSE(8) System Manager's Manual RLM_DBM_PARSE(8) NAME
rlm_dbm_parse - transforms simple syntax into rlm_dbm format SYNOPSIS
rlm_dbm_parse [-c] [-d raddb] [-i inputfile] [-o outputfile] [-x] [-v] [-q] [username ...] DESCRIPTION
rlm_dbm_parse reads a file of the syntax defined below, and writes a database file usable by rlm_dbm or edits current database. INPUT FORMAT
rlm_dbm_parse reads a format similar to the one used by the files module. In incomplete RFC2234 ABNF, it looks like this: entries = *entry entry = identifier TAB definition identifier = username / group-name username = +PCHAR groupname = +PCHAR definition = (check-item ",")* LF ( *( reply-item ",") / ";" ) LF check-item = AS IN FILES reply-item = AS IN FILES * need definition of username and groupname As an example, these are the standard files definitions (files module). DEFAULT Service-Type == Framed-User Framed-IP-Address = 255.255.255.254, Framed-MTU = 576, Service-Type = Framed-User, Fall-Through = Yes #except who call from number 555-666 DEFAULT Auth-Type := Reject,Service-Type ==Framed-User, Calling-Station-ID == "555-666" #or call number 555-667 DEFAULT Auth-Type := Reject,Service-Type ==Framed-User, Calling-Station-ID == "555-667" To be a valid rlm_dbm input file, it should look like this: DEFAULT Service-Type == Framed-User # (1) Framed-IP-Address = 255.255.255.254, # comma, list cont'd Framed-MTU = 576, Service-Type = Framed-User, Fall-Through = Yes # , end of list Auth-Type := Reject,Service-Type ==Framed-User, # (2) Calling-Station-ID == "555-666" ; # ;, no reply items Auth-Type := Reject,Service-Type ==Framed-User, # (3) Calling-Station-ID == "555-667" ; # ditto This user (the DEFAULT user) contains three entries, 1, 2 and 3. The first entry has a list of reply items, terminated by a reply item without a trailing comma. Entries 2 and 3 has empty reply lists, as indicated by the semicolon. This is necessary to separate an empty line (which is ignored) from the empty list. Definition Fall-Through = Yes used in order to say module to check next record. By default Fall- Through = Yes. OPTIONS
-d raddb Use raddb as the radiusd configuration directory. -i inputfile Use file as the input file. If not defined then use standard input. -o outputfile Use file as the output file. -c Create a new database (empty output file before writing) -x Enable debug mode. Multiple x flags increase debug level. -q Do not print statistics (quiet). -v Print the version and exit. -r Remove a username or group name from the database. SEE ALSO
radiusd(8) AUTHORS
Author: Andrei Koulik <rlm_dbm@agk.nnov.ru> Documentation: Bjorn Nordbo <bn@nextra.com> RLM_DBM_PARSE(8)
Check Out this Related Man Page
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)