On 09/12/2011 10:42 PM, Fajar A. Nugraha wrote:
On Tue, Sep 13, 2011 at 2:42 AM, Alan DeKok<[email protected]> wrote:
Christ Schlacta wrote:
Even if this has not changed, the advantages of storing NASs in a table
is pretty significant. make changes, call quick restart script, done.
Uh... no. My message (again) talked about adding clients dynamically.
If I understand raddb/sites-available/dynamic-clients correctly, the
only way to store (well, to retrieve actualy) dynamic clients
definition in SQL is to use "%{sql:" expansion. Is there a way to make
it have some level of redundancy? Last time I check, "%{sql:" can't be
used on "virtual" modules (from instantiate or policy section) which
groups multiple sql instance together using "redundant".
You could also use "exec", rlm_perl/python or whatever, all of which can
themselves call SQL.
Or, perform an SQL query that MUST return some output, parse the results
and call the individual SQL modules directly - like so:
update control {
Tmp-String-0 := "%{sql1:select name||','||secret ...}"
}
if (control:Tmp-String-0 == "") {
update control {
Tmp-String-0 := "%{sql2:...}"
}
}
if (control:Tmp-String-0 =~ /(.+),(.+)/) {
update control {
FreeRADIUS-Client-Shortname := %{1}"
FreeRADIUS-Client-Secret := "%{2}"
}
}
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
