Sam Morris wrote: > On Mon, Apr 24, 2023 at 12:07:16PM -0400, Rob Crittenden via FreeIPA-users > wrote: >>> However, this attribute can be read from the second search! Although >>> it's not included in the results when 'ALL' attributes are requested, >>> explicitly adding it to the search query works fine: >> >> The third search is looking for tombstone entries, >> https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/tombstones >> , and there don't appear to be any. This is fine. >> >> I don't think you need to do anything here. > > But here's what I see from ds-replcheck: > > $ ds-replcheck -v state -Z /etc/ipa/nssdb -m > ldap://ipa0.ipa.example.com:389 -r ldap://ipa1.ipa.example.com:389 -D > uid=repl-mon,cn=sysaccounts,cn=etc,dc=ipa,dc=example,dc=com -w ... -b o=ipaca > Connecting to servers... > Validating suffix ... > Gathering Supplier's RUV... > Error: Supplier does not have an RUV entry > > That error is caused by the tombstone search returning no entries. But > with the directory manager, I get: > > $ ds-replcheck -v state -Z /etc/ipa/nssdb -m > ldap://ipa0.ipa.example.com:389 -r ldap://ipa1.ipa.example.com:389 -D > cn='Directory Manager' -W -b o=ipaca > Enter password: > Connecting to servers... > Validating suffix ... > Gathering Supplier's RUV... > Gathering Replica's RUV... > Getting Supplier's replica ID > Replication State: Supplier and Replica are in perfect synchronization > > Hence I figured I needed to add some ACIs somewhere. But the ones I've > tried adding to 'cn=mapping tree,cn=config' aren't sufficient. > > Here's the search that I think ds-replcheck is doing: > > $ ldapsearch -H ldaps://ipa0.ipa.example.com -x -D > uid=repl-mon,cn=sysaccounts,cn=etc,dc=ipa,dc=example,dc=com -w ... -s sub -b > o=ipaca > '(&(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)(objectClass=nstombstone))' > nsds50ruv > # extended LDIF > # > # LDAPv3 > # base <o=ipaca> with scope subtree > # filter: > (&(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)(objectClass=nstombstone)) > # requesting: nsds50ruv > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > > ... and here it is, run as the directory manager: > > # ldapsearch -LLL -o ldif-wrap=no -s sub -b o=ipaca > '(&(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)(objectClass=nstombstone))' > nsds50ruv > SASL/EXTERNAL authentication started > SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nsds50ruv: {replicageneration} 5cb8bedf000000060000 > nsds50ruv: {replica 14 ldap://ipa0.ipa.example.com:389} > 610ad7470001000e0000 6446aa160000000e0000 > nsds50ruv: {replica 12 ldap://ipa1.ipa.example.com:389} > 6082f5e10001000c0000 6446ae080000000c0000 > nsds50ruv: {replica 18 ldap://ipa2.ipa.example.com:389} > 628d6a07000100120000 6446afa4000000120000 >
I don't use this tool so I don't know the details on the searches it performs. If you can get a quiet LDAP server and run as your bind user and Directory Manager and provide the access logs we can try to figure out what is going on. rob _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
