DHCP + sqlpippol test, v2.1.x

[Alan DeKok]

Fajar A. Nugraha wrote:
> Glad to hear it :D
> Most of my changes are simple ones,

  I've committed a number of the changes.

> Yes. Which brings me to two other questions:
> 1) dhcp functionality is a good example that uses policy. It SHOULD be
> site specific, but currently all policies must be defined on
> policy.conf. So currently I must either:
> a. write the same block twice (as in your original
> sites-available/dhcp example. OR
> b. put all changes on policy.conf. OR
> c. Implement something like polcies directory (or, following the
> recent changes on modules, policies-available and policies-enabled).

  The policies can go anywhere you want.  If you're only running one
DHCP server, you can put them in sites-enabled/dhcp

> 2) I need a place to store centralized configuration variable, where
> the same variable is used by policy, module, and sites. It can be:
> a. write the same value many times. Not good.
> b. edit radiusd.conf (or policy.conf) and place it there. Messy.
> c. create a new file included by radiusd.conf just before modules
> section. Works, but it still requires adding 1 line to radiusd.conf.
> d. Implement configs-available and configs-enabled directory, loaded
> just before modules section on radiusd.conf.

  Yeah, that needs addressing in a general way for 3.0.

> Current version of dhcp config code (with static IP, central config,
> and comment changes), diff against v2.1.x:
> https://github.com/fajarnugraha/freeradius-server/commit/fdff057

  I've pulled in the changes && pushed updates back.

  The changes I made are much simpler than what you had.  The extra
policies you created were site-specific, and not suitable for general
use.  The MySQL example, and the dhcp_sqlippool module went in pretty
much unchanged.

  The rest of the changes are much simpler, and should be easier to
understand for most people.  Please test them out.

> As a side note, I noticed you closed pull request
> https://github.com/alandekok/freeradius-server/pull/40 , but it hasn't
> been merged in v2.1.x. Without that, debian package build still fails.
> Are you planning to commit an alternate fix? This is different btw
> from pull request #41, which you've applied (thanks for that).

  It was pulled in, but not pushed back to github.  I've done that now.

  Alan DeKok.