On 13.10.2016 01:42, Brendan Kearney wrote:
> On 10/12/2016 02:35 AM, Petr Spacek wrote:
>> Hello,
>> these are debug messages and are harmless. Apparently you have verbose/debug
>> messages enabled in named.conf:
>>              arg "verbose_checks yes";
>> If you want to get rid of these messages, just remove the line.
>> What version of bind-dyndb-ldap are you using?
>> Sufficiently new versions should use SyncRepl to pull all data from LDAP to
>> memory (on start) so the read performance should be nearly identical as with
>> plain BIND.
>> Of course, writes/DNS updates will generate load on your LDAP server so the
>> server needs to handle the load.
>> Petr^2 Spacek
>> On 11.10.2016 20:41, Brendan Kearney wrote:
>>> i am using bind-dyndb-ldap on fedora 24 without FreeIPA, and continue to 
>>> have
>>> my logs swamped with errors about "check failed" from settings.c and fwd.c. 
>>>  i
>>> am completely up to date with every package, so the latest versions of
>>> everything are installed.
>>> [settings.c : 420: setting_update_from_ldap_entry] check failed: ignore
>>> [settings.c : 436: setting_update_from_ldap_entry] check failed: ignore
>>> [fwd.c : 378: fwd_setting_isexplicit] check failed: not found
>>> i have two boxes running a named instance each, in a "master/master" config.
>>> each has the zone data configured per below.  the uri refers to the local ip
>>> of each server.
>>>      dynamic-db "bpk2.com" {
>>>              library "ldap.so";
>>>              arg "uri ldap://";;
>>>              arg "base cn=dns,ou=Daemons,dc=bpk2,dc=com";
>>>              arg "auth_method simple";
>>>              arg "bind_dn cn=dnsUser,dc=bpk2,dc=com";
>>>              arg "password dnsPass";
>>>              arg "fake_mname server1.bpk2.com.";
>>>              arg "dyn_update yes";
>>>              arg "connections 2";
>>>              arg "verbose_checks yes";
>>>      };
>>>      zone "." IN {
>>>          type hint;
>>>          file "named.ca";
>>>      };
>>>      include "/etc/named.rfc1912.zones";
>>> my dns container is defined in openldap as such:
>>> dn: cn=dns,ou=Daemons,dc=bpk2,dc=com
>>> cn: dns
>>> idnspersistentsearch: FALSE
>>> idnszonerefresh: 30
>>> objectclass: top
>>> objectclass: nsContainer
>>> objectclass: idnsConfigObject
>>> where and how can i find the source of my issue?  these issues are causing
>>> performance issues on the rest of my network.  because of these errors, ldap
>>> throws errors about deferred operations for binding, too many executing, and
>>> pending operations.  additionally, recursion also seems to be impacted.  
>>> this
>>> is noticed most when streaming content.  buffering, stuttering and 
>>> pixelation
>>> are seen in the video streams.  it could be the swamping of logs killing I/O
>>> or the actual recurision, but 100% the video issues are related.  the log
>>> events match up exactly with the buffering.
>>> i had this issue with bind-dyndb-ldap and fedora 20 up until i recently
>>> upgraded.  i went from F20 to F24, and put things on nice new SSDs, instead 
>>> of
>>> spinning disks.  the problem followed the upgrade.  are there configuration
>>> items i am missing?  are there tweaks i can do to improve something?  how 
>>> do i
>>> get rid of these errors, so dns performance (or the log swamping) is not
>>> affecting the rest of my network?
>>> thank you,
>>> brendan
> i am running 10.1.1 on F24.
> why or how would those error logs be related to LDAP seeing an influx of
> updates, 

Again, these are just debug logs. Do not get confused by word 'failed' here,
it just means that return code from a function is not ISC_R_SUCCESS. In some
cases it is expected and does not imply error condition. (You can mentally
replace word 'failed' with string 'debug: function returned ').

These two cases are just fine:
- ISC_R_IGNORE from setting_update_from_ldap_entry function means that there
was no update to particular setting in the LDAP a entry - plugin processed the
change notification from LDAP server and found nothing new.

- ISC_R_NOTFOUND from fwd_setting_isexplicit is most likely fine as well, it
is an internal function which determines if a zone has explicitly configured
forwarding. It is not :-)

> that wind up causing LDAP operations to queue up and require pended
> transactions, etc?

Again, these are not errors and certainly do not indicate anything bad.
Disable the debug logs if you do not want see it, but in any case, these are
part of normal operation.

> are there tweaks and tuning options i should have in my
> LDAP to manage this?

If you see a performance problem, you need to dig deeper. Bind-dyndb-ldap is
most likely not a root cause because it does "nothing" from performance
perspective :-) I would inspect disk I/O on the LDAP and DNS servers to see if
I/O subsystem is saturated (or not).

DNS server is keeping its transaction logs on disk so big number of updates
might generate a lot of synchronous I/O. LDAP is even worse from this 

If you have a lot of DNS updates and beefy servers, you might increase
"connections" parameter in named.conf. It will use more LDAP connections and
parallelize updates to different zones, which might or might not help in your

I hope this description helps to understand the situation.

Petr^2 Spacek

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to