On Tue, Jan 24, 2012 at 9:57 PM, Alan DeKok <aland@deployingradius.com> wrote:
Fajar A. Nugraha wrote:
Really? How do I put policies it (e.g.) sites-enabled/dhcp? I tried using another policy {} block (but also on policy.conf), the second policy block is not loaded.
You can just write "unlang" blocks.
Do you mean I can assign a name to an unlang block and call it elsewhere, without it needing to be on policy section? Or do you mean I need to put the unlang blocks wherever I need to call it (thus the possible code duplication)?
(2) policy vs method In sites-available/dhcp, you used "dhcp_sqlippool". In my test, that would call the dhcp_sqlipool module instance, bypassing the policy, so the compatibility code was never used. So I change the policy name to dhcp_sqlippool.compat, and call that instead in sites-available/dhcp.
That's a typo. The policy *should* be "dhcp_sqlippool.post-auth". It will take care of over-riding the dhcp_sqlippool call.
I see
Also, I have two questions regarding modules and method: (1) calling the instance dhcp_sqlippool works, without having to force it to call the method post-auth (dhcp_sqlippool.post-auth). Does this mean post-auth is the default method? Is it safe to just call it like that, or should we explicitly call dhcp_sqlippool.post-auth instead?
It's the default method for DHCP. You should just use the module name.
Noted.
(2) Is calling the policy dhcp_sqlippool.post-auth (in your commit) or dhcp_sqlippool.compat (in my lastest change) considered "safe" enough? e.g. should the policy be called something else (e.g. dhcp_sqlippool_compat) to avoid namespace conflict with dhcp_sqlippool (the module instance)?
The idea is that the DHCP SQL stuff is in dhcp_sqlippool. The user sees that, and manages DHCP like that. The "magic" to glue DHCP to RADIUS is in policy.conf, in the dhcp_sqlippool.post-auth method
Thanks, will try it again tomorrow. -- Fajar