[bind10-dev] LDAP in BIND 10

[Petr Spacek]

On 8.4.2013 19:53, JINMEI Tatuya / 神明達哉 wrote:
> At Mon, 08 Apr 2013 11:56:34 +0200,
> Petr Spacek <pspacek at redhat.com> wrote:
>
>> later messages in thread 'SQL in BIND 10' called for real-world requirements
>> and use cases for SQL backends in BIND. I'm 2 months late, but I will add one
>> real-world case where LDAP database is used as backend for BIND 9.
>
> Thanks for sharing the usage.  It's interesting and informative.
>
> Some quick comments in the context of BIND 10:
> - one big missing piece (other than handling LDAP API) for supporting
>    this type of use is the asynchronous notification/pull mechanism to
>    incorporate changes to the LDAP DB.
I should say that in BIND9 we handle this situation internally in our backend, 
i.e. BIND itself is not aware of any asynchronous notifications.

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.

Record cache we use is internal to our backend, so BIND passes each request 
directly to the backend. As a result, 'listener' thread can auto-magically 
change content of the cache and configuration on-the-fly.

> - where to store other zone related data (or a kind of config) such as
>    per zone ACLs is one open question.  but your use case is
>    interesting in that some users want to manage it outside of the
>    nameserver's configuration.
I'll add more details:
We do not invent new options and we try to follow BIND's syntax as much as 
possible. The only difference is that selected configuration options are 
stored as strings in LDAP instead of plain text file.

The reason is that the users see some parts of configuration 'translated' to 
web page/command line/XMLRPC/JSONRPC , so we need to access the configuration 
in a structured way.

The backend fetches all the data from LDAP and imitate the work of original 
configuration parser.


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")

My point is that 'config' API should handle all the magic with parsing, 
locking, all the 'internal knobs'. Now it is a nightmare. We have to parse 
strings to appropriate data structures and call every internal function by 
hand, which is big adventure.


Two more points:
- We store settings for zones and also *global* configuration options 
(forwarders and forward policy).
- Options from configuration file are respected as long as the options are not 
present in LDAP, i.e. it is possible to set forwarders per-server.

> - I don't know if startup time is important for you, but in BIND 10 it
>    would still be possible to minimize it once we complete the current
>    shared memory support: the latest memory image is saved in a
>    memory-mappable file.  when BIND 10 starts it would map the file into
>    memory, check the LDAP data, and only apply the diffs between the
>    saved in-memory data and the latest DB data (if the diff can be
>    easily retrieved, e.g., by specifying the old version of zone SOA).
Interesting idea. AFAIK LDAP databases are not able to supply diffs between 
two versions.

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.

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

-- 
Petr Spacek
Software Engineer
Red Hat