Hi, as said on the other mail thread https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/GR2ZOFFNICWKLI3YBFYVTFZHUNNKDIQZ/, 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 <ke...@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@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@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@lists.fedorahosted.org > >> To unsubscribe send an email to > freeipa-users-le...@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.fedorahosted.org > >> Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > > > > > > _______________________________________________ > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > > To unsubscribe send an email to > freeipa-users-le...@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.fedorahosted.org > > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > > > > -- > Rafael Guterres Jeffman > Senior Software Engineer > FreeIPA - Red Hat > > >
_______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
