On Mon, Apr 24, 2023 at 03:54:30PM -0400, Rob Crittenden via FreeIPA-users 
wrote:
> 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.

Sure, here's the command used:

  $ ds-replcheck -v state -Z /etc/ipa/nssdb -m ldap://ipa0.ipa.example.com:389 
-r ldap://ipa1.ipa.example.com:389 -D DN -w PASSWORD -b o=ipaca

Here are the logs when running it using the root DN:

  [25/Apr/2023:08:09:38.547193776 +0000] conn=1529 op=1 BIND dn="cn=Directory 
Manager" method=128 version=3
  [25/Apr/2023:08:09:38.547501267 +0000] conn=1529 op=1 RESULT err=0 tag=97 
nentries=0 wtime=0.010675418 optime=0.000343664 etime=0.011014089 
dn="cn=directory manager"
  [25/Apr/2023:08:09:38.556818128 +0000] conn=1529 op=2 SRCH base="o=ipaca" 
scope=0 filter="(objectClass=*)" attrs=ALL
  [25/Apr/2023:08:09:38.557355407 +0000] conn=1529 op=2 RESULT err=0 tag=101 
nentries=1 wtime=0.000350868 optime=0.000545608 etime=0.000878460
  [25/Apr/2023:08:09:38.558868700 +0000] conn=1529 op=3 SRCH base="cn=config" 
scope=2 filter="(&(objectClass=nsds5replica)(nsDS5ReplicaRoot=o=ipaca))" 
attrs=ALL
  [25/Apr/2023:08:09:38.561344851 +0000] conn=1529 op=3 RESULT err=0 tag=101 
nentries=1 wtime=0.000338392 optime=0.002481952 etime=0.002814677
  [25/Apr/2023:08:09:38.565951829 +0000] conn=1529 op=4 SRCH base="o=ipaca" 
scope=2 
filter="(&(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)(objectClass=nstombstone))"
 attrs="nsds50ruv"
  [25/Apr/2023:08:09:38.567222484 +0000] conn=1529 op=4 RESULT err=0 tag=101 
nentries=1 wtime=0.000293867 optime=0.001279436 etime=0.001568497
  [25/Apr/2023:08:09:38.574172428 +0000] conn=1529 op=5 UNBIND

... and with my repl-mon user:

  [24/Apr/2023:11:35:34.468602164 +0000] conn=789 op=1 BIND 
dn="uid=repl-mon,cn=sysaccounts,cn=etc,dc=ipa,dc=example,dc=com" method=128 
version=3
  [24/Apr/2023:11:35:34.470810908 +0000] conn=789 op=1 RESULT err=0 tag=97 
nentries=0 wtime=0.020082546 optime=0.002246180 etime=0.022324130 
dn="uid=repl-mon,cn=sysaccounts,cn=etc,dc=ipa,dc=example,dc=com"
  [24/Apr/2023:11:35:34.475518328 +0000] conn=789 op=2 SRCH base="o=ipaca" 
scope=0 filter="(objectClass=*)" attrs=ALL
  [24/Apr/2023:11:35:34.475918861 +0000] conn=789 op=2 RESULT err=0 tag=101 
nentries=0 wtime=0.000211040 optime=0.000406466 etime=0.000612026
  [24/Apr/2023:11:35:34.477210042 +0000] conn=789 op=3 SRCH base="cn=config" 
scope=2 filter="(&(objectClass=nsds5replica)(nsDS5ReplicaRoot=o=ipaca))" 
attrs=ALL
  [24/Apr/2023:11:35:34.487675914 +0000] conn=789 op=3 RESULT err=0 tag=101 
nentries=1 wtime=0.000248974 optime=0.010471906 etime=0.010715383
  [24/Apr/2023:11:35:34.502207252 +0000] conn=789 op=4 SRCH base="o=ipaca" 
scope=2 
filter="(&(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)(objectClass=nstombstone))"
 attrs="nsds50ruv"
  [24/Apr/2023:11:35:34.502647379 +0000] conn=789 op=4 RESULT err=0 tag=101 
nentries=0 wtime=0.000333635 optime=0.000446668 etime=0.000773723
  [24/Apr/2023:11:35:34.504273914 +0000] conn=789 op=5 UNBIND

It's the 3rd query for the tombstone object's nsds50ruv attribute that
returns nothing when run as repl-mon.

Either my ACIs are wrong, or there's something funky about how the
tombstone query works; note that the search base is o=ipaca, but the DN
of the entry in the result is not within o=ipaca:

  [root@ipa0 ~]# ldapsearch -Q -LLL -o ldif-wrap=no -s sub -b o=ipaca 
'(&(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)(objectClass=nstombstone))' 
nsds50ruv
  dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
  nsds50ruv: {replicageneration} 5cb8bedf000000060000
  nsds50ruv: {replica 14 ldap://ipa0.ipa.example.com:389} 610ad7470001000e0000 
64478b160000000e0000
  nsds50ruv: {replica 12 ldap://ipa1.ipa.example.com:389} 6082f5e10001000c0000 
64478b840000000c0000
  nsds50ruv: {replica 18 ldap://ipa2.ipa.example.com:389} 628d6a07000100120000 
64478293000000120000

-- 
Sam Morris <https://robots.org.uk/>
CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9
_______________________________________________
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to