Best Practices - maximum NAS entries in clients.conf

[Fajar A. Nugraha]

On Tue, Sep 13, 2011 at 2:43 PM, Phil Mayers <p.mayers at 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