On 09/12/2011 10:42 PM, Fajar A. Nugraha wrote:
On Tue, Sep 13, 2011 at 2:42 AM, Alan DeKok<aland@deployingradius.com> 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}" } }