Throwing in more details. At startup we have this in the log
Jun 29 14:32:36 linge.ghs.nl named-pkcs11[6945]: 10 master zones from
LDAP instance 'ipa' loaded (10 zones defined, 0 inactive, 0 failed to load)
Jun 29 14:32:36 linge.ghs.nl named-pkcs11[6945]: managed-keys-zone:
Unable to fetch DNSKEY set '.': timed out
Jun 29 14:32:37 linge.ghs.nl named-pkcs11[6945]: bug in
ldap_entry_reconstruct(): protocol violation: attempt to reconstruct
non-existing entry
Jun 29 14:32:37 linge.ghs.nl named-pkcs11[6945]: ldap_sync_search_entry
failed: not found
Jun 29 14:32:38 linge.ghs.nl named-pkcs11[6945]: bug in
ldap_entry_reconstruct(): protocol violation: attempt to reconstruct
non-existing entry
Jun 29 14:32:38 linge.ghs.nl named-pkcs11[6945]: ldap_sync_search_entry
failed: not found
Jun 29 14:32:38 linge.ghs.nl named-pkcs11[6945]: bug in
ldap_entry_reconstruct(): protocol violation: attempt to reconstruct
non-existing entry
Jun 29 14:32:38 linge.ghs.nl named-pkcs11[6945]: ldap_sync_search_entry
failed: not found
Jun 29 14:32:41 linge.ghs.nl named-pkcs11[6945]: zone
16.16.172.in-addr.arpa/IN: sending notifies (serial 1624969953)
...
The "Unable to fetch" message is probably because this network has
no Internet.
On 29-06-2021 13:38, Kees Bakker via FreeIPA-users wrote:
Three weeks ago I had to disable dnssec (due to problem with one of
the forwarding domains). So I changed/added
dnssec-enable no;
dnssec-validation no;
Could that have any influence?
On 29-06-2021 11:03, Kees Bakker via FreeIPA-users wrote:
> Hi Flo,
>
> Now that I know all the plugins are present, I was suspecting
> nsslapd-changelogmaxage.
> But that was false hope. It is set to 2d (which is the default, I think).
>
> I definitely don't see the syncrepl_update output in
> /var/named/data/named.run
> WIth one exception, two days ago around 03:18 (in the morning) there
> was a burst
> of syncrepl_update messages. Other than that, nothing.
>
> There are DHCP updates coming in, these go to the CentOS7 system. I
> see them in
> LDAP (and through the web interface). But they are not updated in the
> other
> nameservers.
> -- Kees
>
>
> On 29-06-2021 10:40, Florence Renaud wrote:
>> Hi,
>>
>> as said on the other mail thread
>>
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>
<
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...;,
>> I suspect the search for plugins is executed with ldapsearch -Y
>> GSSAPI ... and the ACIs are filtering part of the output. The
>> command ldapsearch -D "cn=directory manager" -W ... should allow to
>> see everything.
>>
>> With the command "rndc trace 10" I am able to see additional logs
>> (on centos 8 replica) in /var/named/data/named.run when an A record
>> is added on centos 7 master, for instance:
>> 29-Jun-2021 04:29:14.828 syncrepl_update: updating name in rbtdb,
>> resource record DN
>> 'idnsname=test6,idnsname=ipa.test.,cn=dns,dc=ipa,dc=test'
>>
>> flo
>>
>> On Wed, Jun 23, 2021 at 1:39 PM Kees Bakker <keesb(a)ghs.com
>> <mailto:keesb@ghs.com>> wrote:
>>
>> So far not much luck in finding what is wrong. No sign of sync_repl
>> or syncrepl in the logs.
>>
>> What I don't understand is why the cn=plugins,cn=config LDAP
>> of the three masters is so different.
>>
>> On the "old main" Centos7 master there are 388 entries. On the
newer
>> CentOS 8 Stream masters there are only 30 entries. And no
>> cn=Retro Changelog Plugin,cn=plugins,cn=config
>>
>> Are my two CentOS 8 Stream masters installed properly?
>>
>> For example
>> ========================================
>> "main" master, CentOS 7
>>
>> dn: cn=config,cn=ldbm database,cn=plugins,cn=config
>> cn: config
>> objectClass: top
>> objectClass: extensibleObject
>> nsslapd-lookthroughlimit: 100000
>> nsslapd-mode: 600
>> nsslapd-idlistscanlimit: 100000
>> nsslapd-directory: /var/lib/dirsrv/slapd-GHS-NL/db
>> nsslapd-dbcachesize: 328402697
>> nsslapd-db-logdirectory: /var/lib/dirsrv/slapd-GHS-NL/db
>> nsslapd-db-durable-transaction: on
>> nsslapd-db-transaction-wait: off
>> nsslapd-db-checkpoint-interval: 60
>> nsslapd-db-compactdb-interval: 2592000
>> nsslapd-db-transaction-batch-val: 0
>> nsslapd-db-transaction-batch-min-wait: 50
>> nsslapd-db-transaction-batch-max-wait: 50
>> nsslapd-db-logbuf-size: 0
>> nsslapd-db-locks: 50000
>> nsslapd-db-private-import-mem: on
>> nsslapd-import-cache-autosize: -1
>> nsslapd-cache-autosize: 10
>> nsslapd-cache-autosize-split: 25
>> nsslapd-import-cachesize: 16777216
>> nsslapd-idl-switch: new
>> nsslapd-search-bypass-filter-test: on
>> nsslapd-search-use-vlv-index: on
>> nsslapd-exclude-from-export: entrydn entryid dncomp parentid
>> numSubordinates tombstonenumsubordinates entryusn
>> nsslapd-serial-lock: on
>> nsslapd-subtree-rename-switch: on
>> nsslapd-pagedlookthroughlimit: 0
>> nsslapd-pagedidlistscanlimit: 0
>> nsslapd-rangelookthroughlimit: 5000
>> nsslapd-backend-opt-level: 1
>> nsslapd-db-deadlock-policy: 9
>> ========================================
>> Other replica, CentOS 8 Stream
>>
>> dn: cn=config,cn=ldbm database,cn=plugins,cn=config
>> cn: config
>> objectClass: top
>> objectClass: extensibleObject
>> nsslapd-directory: /var/lib/dirsrv/slapd-GHS-NL/db
>> ========================================
>>
>> On 21-06-2021 21:20, Rafael Jeffman wrote:
>>> Hello,
>>>
>>> On Mon, Jun 21, 2021 at 3:40 PM Kees Bakker via FreeIPA-users
>>> <freeipa-users(a)lists.fedorahosted.org
>>> <mailto:freeipa-users@lists.fedorahosted.org>> wrote:
>>> >
>>> > Hi,
>>> >
>>> > There is nothing in the daemon logs with "syncrepl" or
>>> "sync_repl".
>>> >
>>> > Should there be a syncrepl log for every update? Or only when
>>> there
>>> > is a failure?
>>> >
>>> > Do I need to enable debugging of the dyndb plugin?
>>>
>>> You might need to increase bind log level with something like
>>> `rdnc trace 10` (or more, I don't remember the exact level
>>> you'll need).
>>>
>>> Rafael
>>>
>>> > -- Kees
>>> >
>>> > On 21-06-2021 18:56, Florence Renaud wrote:
>>> >
>>> > Hi,
>>> >
>>> > the high level view is the following: when there is an update
>>> related to DNS data on an IPA server (new/updated/deleted zone,
>>> new/updated/deleted record), it gets written to LDAP. As the
>>> LDAP data is replicated to the other IPA servers, their local
>>> LDAP database gets updated.
>>> > The bind daemon running on the replica is configured with
>>> bind-dyndb-ldap plugin, that uses the syncrepl mechanism to be
>>> warned of updates in the LDAP database. So each time there is a
>>> change in the DNS data in the LDAP server, the bind daemon is
>>> notified and can handle the change locally and update its view.
>>> >
>>> > If the LDAP data is properly replicated but the bind daemon
>>> does not serve the expected records, it probably means that the
>>> syncrepl mechanism is broken. If you have a look at the journal
>>> you may see logs with "sync_repl" or "syncrepl"
keywords and
>>> they will help diagnose the problem.
>>> > The bind daemon logs are located in /var/named/data/ and may
>>> also help.
>>> >
>>> > flo
>>> >
>>> > On Mon, Jun 21, 2021 at 2:17 PM Kees Bakker via FreeIPA-users
>>> <freeipa-users(a)lists.fedorahosted.org
>>> <mailto:freeipa-users@lists.fedorahosted.org>> wrote:
>>> >>
>>> >> Hey,
>>> >>
>>> >> Recently I discovered that the nameservers of two out the
>>> three IPA
>>> >> masters (replicas) are
>>> >> not responding with up-to-date information.
>>> >>
>>> >> Our setup has three masters. Each is configured as
>>> nameserver. Most of
>>> >> the time I use
>>> >> one as the main master when I modify DNS entries. We also
>>> have a DHCP
>>> >> server that
>>> >> sends updates to that "main" master.
>>> >>
>>> >> What I now discovered is that updates are not available when
>>> clients use
>>> >> the two
>>> >> other masters.
>>> >>
>>> >> On all three masters the DNS record is present when I use local
>>> >> ldapsearch [1]. But with dig
>>> >> the record is only present on one master.
>>> >>
>>> >> If I restart the nameserver it then has all records available.
>>> >>
>>> >> What would be the best method to find out what is wrong?
>>> >>
>>> >> BTW. There are two things that changed recently. I mention
>>> this in case
>>> >> it rings a bell.
>>> >> 1. one master was re-installed with CentOS 8 Stream. An
>>> other CentOS8
>>> >> master was added
>>> >> a few weeks ago.
>>> >> 2. our nameservers don't have connection to the Internet
any
>>> more. So,
>>> >> root servers cannot
>>> >> be found.
>>> >>
>>> >> [1] by local ldapsearch I mean doing a command like this:
>>> >> ldapsearch -H ldapi://%2fvar%2frun%2f...
>>> >> --
>>> >> Kees
>>> >> _______________________________________________
>>> >> FreeIPA-users mailing list --
>>> freeipa-users(a)lists.fedorahosted.org
>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>> >> To unsubscribe send an email to
>>> freeipa-users-leave(a)lists.fedorahosted.org
>>> <mailto:freeipa-users-leave@lists.fedorahosted.org>
>>> >> Fedora Code of Conduct:
>>>
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> <
https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
>>> >> List Guidelines:
>>>
https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> <
https://fedoraproject.org/wiki/Mailing_list_guidelines>
>>> >> List Archives:
>>>
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>>
<
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>> >> Do not reply to spam on the list, report it:
>>>
https://pagure.io/fedora-infrastructure
>>> <
https://pagure.io/fedora-infrastructure>
>>> >
>>> >
>>> > _______________________________________________
>>> > FreeIPA-users mailing list --
>>> freeipa-users(a)lists.fedorahosted.org
>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>> > To unsubscribe send an email to
>>> freeipa-users-leave(a)lists.fedorahosted.org
>>> <mailto:freeipa-users-leave@lists.fedorahosted.org>
>>> > Fedora Code of Conduct:
>>>
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> <
https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
>>> > List Guidelines:
>>>
https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> <
https://fedoraproject.org/wiki/Mailing_list_guidelines>
>>> > List Archives:
>>>
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>>
<
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>> > Do not reply to spam on the list, report it:
>>>
https://pagure.io/fedora-infrastructure
>>> <
https://pagure.io/fedora-infrastructure>
>>>
>>>
>>>
>>> --
>>> Rafael Guterres Jeffman
>>> Senior Software Engineer
>>> FreeIPA - Red Hat
>>
>
>
> _______________________________________________
> FreeIPA-users mailing list --freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email tofreeipa-users-leave(a)lists.fedorahosted.org
> Fedora Code of
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List
Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
> List
Archives:https://lists.fedorahosted.org/archives/list/freeipa-users@lists...
> Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure