[bind10-dev] LDAP in BIND 10

Michal 'vorner' Vaner michal.vaner at nic.cz
Tue Apr 9 09:41:38 UTC 2013


Good morning

On Tue, Apr 09, 2013 at 10:54:33AM +0200, Petr Spacek wrote:
> Basically, we start own thread and this 'listener' thread sits on LDAP 
> connection and waits for entry change notifications. The listener fires a new 
> event for each change, each event is handled asynchronously by functions 
> internal to backend.

Is this a thread inside bind?

In bind10, you probably could create a listener module (separate program) that
would listen and push updates.

> UI can do things like 'change forward policy for master zone example.com to 
> "only"' or 'add new global forwarder'. The new value is stored in LDAP and 
> replicated everywhere by LDAP server, so each server has identical 
> configuration. 'Listener' thread on each server (as mentioned above) fetches 
> new value and pushes some BIND's internal knobs to make the change without reload.
> 
> It is definitely bad and ugly solution! Sometimes we push BIND's 'internal 
> knobs' in wrong order (or time...) and it crashes the whole server. Also, it 
> is limited to options we explicitly support, we don't have any universal solution.
> 
> 
>  From my point of view, some (string-based?) API for structured reading and 
> modification of configuration *run-time* would be great.
> 
> config.get("/forwarders/addrs", &forwarders_array)
> config.add("/forwarders/addrs", "192.0.2.1")
> config.set("/forwarders/policy", "only")
> config.del("/forwarders/addrs", "192.0.2.1")

Then you probably will find bind10 more friendly to your needs I hope. There's a
configuration API. You could either access it through restfull/HTTP API (send
commands/configuration options to the system), or communicate directly with the
configuration manager over our communication bus (depending on if your listener
would sit outside or inside of bind10, but even inside it would probably be a
separate process).

> Would it be possible to do this?
> 1) Load old 'image' during startup and start replying to queries from the image.
> 2) In background, load all new data from LDAP and create new 'image'.
> 3) Switch to the new 'image'.
> 4) Drop old image from memory.

Yes. Something like that is planned. We would fall back to full reload in case
the diffs are not available.

> And also:
> 0) Disable this mechanism completely :-)

By disable, you mean the caching, or the load of old and just wait for the new
one on each start? Yes would be to both.

With regards

-- 
BOFH Excuse #452:
Somebody ran the operating system through a spelling checker.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20130409/a2814474/attachment.bin>


More information about the bind10-dev mailing list