On Aug 21, 2015, at 3:10 PM, Michael Ströder <michael@stroeder.com> wrote:
Arran Cudbard-Bell wrote:
On Aug 21, 2015, at 12:42 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On Aug 21, 2015, at 12:34 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Aug 21, 2015, at 12:18 PM, Michael Ströder <michael@stroeder.com> wrote:
I'd also like to try to replace ISC dhcpd currently used with LDAP backend by FreeRADIUS already running for WLAN access. Any change to set up a plain DHCP server with LDAP as backend?
It's probably possible. The only consideration is what's in LDAP?
If you're doing static IPs in LDAP, it's pretty simple. I don't think there's a standard for doing dynamic leases in LDAP.
There's a draft from 99 https://tools.ietf.org/html/draft-gu-dhcp-ldap-schema-00 Could follow that.
Yes, references to ManagedSystemElement sounds like that bloated DEN / CIM stuff. I'm pretty sure you don't want to get into that.
There were even two more drafts for a DHCP-LDAP schema: https://tools.ietf.org/html/draft-ietf-dhc-schema (March 2000) https://tools.ietf.org/html/draft-miller-dhcp-ldap-schema
AFAICS the ISC schema is not one of the above.
And MS AD has its own schema. And I also vaguely remember that Novell has something in eDirectory (maybe almost draft-miller-dhcp-ldap-schema).
I have to dig my harddisk...we should invent another LDAP schema. ;-)
:/
Or there's whatever ISC is using. I guess that's better as it'd allow an easy migration path.
The ISC schema has schema descriptions for DHCP leases (but they don't use it). Mainly they develop their new DHCP server "kea" which stores leases into SQL DBs (DB abstraction layer).
Ug.
But I'd rather avoid the ISC-LDAP schema. It makes my eyes hurt because it was simply designed for easily converting an existing textual configuration. So attributes contain text bloat instead of indexable, searchable information. I have to look at your leases SQL schema...
I'd be interested to know if ISC have found a way to do sparse allocation of DHCP leases. AFAICT our SQL schemas require rows to be inserted into the SQL db, representing each lease in the pool, before the module can allocate them. Which is fine, I guess, just seems a little wasteful. The problem with using LDAP for IP allocation, is with OpenLDAP at least, the whole server is setup for read performance. When you start writing you blow out the object caches in BDB and OpenLDAP and read performance starts to suck too. With LMDB you're looking at around 3000 writes/s max, as there's only a single writer thread. It's really not designed for balanced read/write loads. For that you'd want to look at either SQL or one of the numerous in memory K/V stores which have popped up in recent years. -Arran