[Freeipa-users] bind-dyndb-ldap vs DLZ

[Jorgen Lundman]

Petr Spacek wrote:
> 
> Perfect! I can merge your changes upstream if you send me a patch with your
> changes. It would make your life easier later when you need to pick new code.

Not a problem, I need to figure out why Solaris mkdir returns -1, with
errno = 0. Goes against the manpage and all logic. Checking for ||errno==0
after mkdir "fixes" it but it is still odd.

I also compiled without krb5. It basically compiled, but running would fail
to find gss/mech_krb5.so  - no idea how that is supposed to link, but since
it was a quick test, I just took it out.

Otherwise it compiled smoothly, some minor linux-ism with linker flags.




> 
> Hmm, that might be a challenge. bind-dyndb-ldap code implicitly assumes that
> there is 1:1 mapping between DNS name<->LDAP DN. This makes implementation of
> dynamic updates much easier.

Actually yes, I did mean to ask about this too. DLZ-LDAP is pretty much a
read-only setup (for us), so a quick scan of the sources led me to believe
that simple string replacement of "idnsName" with "DNSZoneName" (and of
course, all the others), should get "a large chunk" of it done. The schemas
are quite close, on a whole..

But I was surprised to see bind-dyndb actually modify the LDAP data, for my
test, just "idnsSOAserial". What is the purpose of this? I would guess for
zone xfers? By why update LDAP (and not just internal DNS memory), if you
essentially do not use it on restart (just gets updated again on restart,
from the looks of it?)




>> the same delay each time I start it. slapd is running on localhost, and is
>> otherwise idle. 
> 
> Hmm, that stinks! I would be happy to look into it if you can provide me with
> output from a profiler of your choice. (It might be a good idea to profile
> bind-dyndb-ldap together with whole named process to see all the interactions.)

It is in line with what we experience with LDAP generally. If I blow away
the DNS-ldap tree, a full syncrepl update takes about 1 hour. If I remove
the whole LDAP tree, about 4 hours. It is not something that goes faster
with more threads afaik.



>> Is it supposed to be able to use the "dump-file" on exit for faster loads?
> 
> Yes, something like that is planned but not implemented yet.

Ah ok great, good to know it is planned. We could probably live with 50
mins startup time, as there are 28 servers in the DNS cluster. Just needs
some care in case they are restarted, or worse, some bug causes coredump
which affects all of them





>> [3]
>> However, that has a side-effect that, once bind-dyndb is loaded, it will
>> also query DLZ+LDAP on negative entries. Thus decreasing the performance to
>> 3884qps.  Wonder if there is a way to have bind-dyndb ignore DLZ+LDAP /once
>> it has loaded/.
> 
> Wow, I'm surprised that this combination actually works! I expect that there
> will be some nasty surprises in there, especially when it comes to dynamic
> updates.

I must admit it would be tempting to see if bind-dyndb could issue a
definitive reply (once loaded) for both positive and negative lookups,
thereby causing DLZ-LDAP to be inert. Or making it a feature of bind-dyndb
to use DLZ-LDAP during load. But only in the case that they both use the
same schema and source tree in LDAP.

Feels a bit hackish but just evaluating possible solutions.



-- 
Jorgen Lundman       | <lundman at lundman.net>
Unix Administrator   | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo    | +81 (0)90-5578-8500          (cell)
Japan                | +81 (0)3 -3375-1767          (home)