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 | <lund...@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) -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project