On Tue, Sep 13, 2011 at 2:43 PM, Phil Mayers <p.may...@imperial.ac.uk> wrote: > On 09/12/2011 10:42 PM, Fajar A. Nugraha wrote: >> 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.
possible, though not ideal. > > 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:...}" > } > } That's what we currently do (for another purpose, not for dynamic client). However: - I lost load-balancing feature that comes with redundant-load-balance - imagine having to create 8 if-elsif block to properly catch error when working with 8 sql nodes, and write the same sql query 8 times in the configuration file. Works, but kinda messy. With current sql module (that only reads nas list from sql during startup/HUP) I can use one sql/mysql/*.conf to specify the query, and have each sql instance $INCLUDE it. If we can do similar thing with "%{sql:" expansion (e.g. store the query in some temporary internal variable/attribute) it'd be reduce the measiness greatly, but I haven't found out how to do it yet. -- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html