> On 23 Jan 2019, at 20:14, Mihai Carabas <mihai.carabas@xxxxxxxxx> wrote: > > I've tried playing with the filters on the ou=DPPD which has issues: > # extended LDIF > # > # LDAPv3 > # base <ou=DPPD,ou=People,dc=curs,dc=pub,dc=ro> with scope oneLevel > # filter: ou=Profeso > # requesting: ALL > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > > # extended LDIF > # > # LDAPv3 > # base <ou=DPPD,ou=People,dc=curs,dc=pub,dc=ro> with scope oneLevel > # filter: ou=Profesor > # requesting: ALL > # > > # Profesori, DPPD, People, curs.pub.ro > dn: ou=Profesori,ou=DPPD,ou=People,dc=curs,dc=pub,dc=ro > ou: Profesori > objectClass: top > objectClass: organizationalunit > > # Asistenti-Man, DPPD, People, curs.pub.ro > dn: ou=Asistenti-Man,ou=DPPD,ou=People,dc=curs,dc=pub,dc=ro > objectClass: top > objectClass: organizationalunit > ou: ou=Asistenti-Man > ou: Asistenti-Man > > # Profesori-Man, DPPD, People, curs.pub.ro > dn: ou=Profesori-Man,ou=DPPD,ou=People,dc=curs,dc=pub,dc=ro > objectClass: top > objectClass: organizationalunit > ou: ou=Profesori-Man > ou: Profesori-Man > > # Externi, DPPD, People, curs.pub.ro > dn: ou=Externi,ou=DPPD,ou=People,dc=curs,dc=pub,dc=ro > objectClass: top > objectClass: organizationalunit > ou: ou=Externi > ou: Externi > > # Auxiliari, DPPD, People, curs.pub.ro > dn: ou=Auxiliari,ou=DPPD,ou=People,dc=curs,dc=pub,dc=ro > objectClass: top > objectClass: organizationalunit > ou: Auxiliari > > # search result > search: 2 > result: 0 Success > > # numResponses: 6 > # numEntries: 5 > > If I put a filter of ou=Profeso, no entry is returned which is _fine_. > If I put ou=Profesor, all the entries are returned (even no entry is > matching the string). Something is matching on all entries. This sounds like it could be an index corruption or issue perhaps. Would you be able to run a dbscan of: cd /var/lib/dirsrv/slapd-<instance name>/<backend name> dbscan -r -f ou.db4 For me this is: cd /var/lib/dirsrv/slapd-localhost/userRoot It would be interesting to see if you have a result of “=Profeso” but not “=Profesor” Please do this first, but after this, the solution may be a db2index to rebuild your index content. I would like to see the dbscans first though :) Thanks, > > On Wed, Jan 23, 2019 at 9:06 AM Mihai Carabas <mihai.carabas@xxxxxxxxx> wrote: >> >> On Wed, Jan 23, 2019 at 4:52 AM William Brown <wbrown@xxxxxxx> wrote: >>> >>> >>> >>>> On 23 Jan 2019, at 02:01, Mihai Carabas <mihai.carabas@xxxxxxxxx> wrote: >>>> >>>> Helllo, >>>> >>>> On Tue, Jan 22, 2019 at 11:45 AM Ludwig <lkrispen@xxxxxxxxxx> wrote: >>>>> >>>>> The issue you are reporting does match exactly the issue in #49443, but >>>>> this was fixed and the fix is in current master. Also I cannot reproduce >>>>> it in current master and not with 1.4.20 - >>>>> >>>>> So this is a bit weird. Can you share a bit more of your data, eg >>>>> provide all entries below ou=DPPD dn and ou attribute, do you have an >>>>> index for ou ? >>>> >>>> Those are all _direct_ entries under ou=DPPD: >>>> # extended LDIF >>>> # >>>> # LDAPv3 >>>> # base <ou=DPPD,ou=People,dc=curs,dc=pub,dc=ro> with scope oneLevel >>>> # filter: (objectclass=*) >>>> # requesting: ALL >>>> # >>>> >>>> # Profesori, DPPD, People, curs.pub.ro >>>> dn: ou=Profesori,ou=DPPD,ou=People,dc=curs,dc=pub,dc=ro >>>> objectClass: top >>>> objectClass: organizationalunit >>>> ou: ou=Profesori >>>> ou: Profesori >>>> >>>> # Asistenti-Man, DPPD, People, curs.pub.ro >>>> dn: ou=Asistenti-Man,ou=DPPD,ou=People,dc=curs,dc=pub,dc=ro >>>> objectClass: top >>>> objectClass: organizationalunit >>>> ou: ou=Asistenti-Man >>>> ou: Asistenti-Man >>>> >>>> # Profesori-Man, DPPD, People, curs.pub.ro >>>> dn: ou=Profesori-Man,ou=DPPD,ou=People,dc=curs,dc=pub,dc=ro >>>> objectClass: top >>>> objectClass: organizationalunit >>>> ou: ou=Profesori-Man >>>> ou: Profesori-Man >>>> >>>> # Externi, DPPD, People, curs.pub.ro >>>> dn: ou=Externi,ou=DPPD,ou=People,dc=curs,dc=pub,dc=ro >>>> objectClass: top >>>> objectClass: organizationalunit >>>> ou: ou=Externi >>>> ou: Externi >>>> >>>> # Auxiliari, DPPD, People, curs.pub.ro >>>> dn: ou=Auxiliari,ou=DPPD,ou=People,dc=curs,dc=pub,dc=ro >>>> objectClass: top >>>> objectClass: organizationalunit >>>> ou: Auxiliari >>>> >>>> # search result >>>> search: 2 >>>> result: 0 Success >>>> >>>> # numResponses: 6 >>>> # numEntries: 5 >>>> >>>> >>>> But for out=ACS, the filter is working: >>>> # extended LDIF >>>> # >>>> # LDAPv3 >>>> # base <ou=ACS,ou=People,dc=curs,dc=pub,dc=ro> with scope oneLevel >>>> # filter: ou=Profesori >>>> # requesting: ALL >>>> # >>>> >>>> # Profesori, ACS, People, curs.pub.ro >>>> dn: ou=Profesori,ou=ACS,ou=People,dc=curs,dc=pub,dc=ro >>>> objectClass: top >>>> objectClass: organizationalunit >>>> ou: ou=Profesori >>>> ou: Profesori >>>> >>>> # search result >>>> search: 2 >>>> result: 0 Success >>>> >>>> # numResponses: 2 >>>> # numEntries: 1 >>>> >>>> This is very wierd. I have an index for ou. >>>> >>> >>> This is indeed weird. Do you have the access log for this search operation? Can you please provide it? >>> >> [23/Jan/2019:09:01:00.759258088 +0200] conn=208222 fd=71 slot=71 >> connection from 141.85.241.48 to 141.85.241.48 >> [23/Jan/2019:09:01:00.759495689 +0200] conn=208222 op=0 BIND >> dn="cn=directory manager" method=128 version=3 >> [23/Jan/2019:09:01:00.759638289 +0200] conn=208222 op=0 RESULT err=0 >> tag=97 nentries=0 etime=0.0000258701 dn="cn=directory manager" >> [23/Jan/2019:09:01:00.760046290 +0200] conn=208222 op=1 SRCH >> base="ou=DPPD,ou=People,dc=curs,dc=pub,dc=ro" scope=1 >> filter="(ou=Profesori)" attrs=ALL >> [23/Jan/2019:09:01:00.760605892 +0200] conn=208222 op=1 RESULT err=0 >> tag=101 nentries=5 etime=0.0000696102 >> [23/Jan/2019:09:01:00.761964296 +0200] conn=208222 op=2 UNBIND >> [23/Jan/2019:09:01:00.761988896 +0200] conn=208222 op=2 fd=71 closed - U1 >> >>> Additionally, have you been able to reproduce this in a new instance? Or only on your “current” instance. >>> >> Honestly I did not. >> >> One particular thing is that I have upgraded my Fedora25 step-by-step >> (I went through each version) and also 389-ds was upgraded. The >> dataset would contain old metadata from the old version of 389-ds? >> >> Thank you, >> Mihai >> >>> Thanks, >>> >>> >>> — >>> Sincerely, >>> >>> William Brown >>> Software Engineer, 389 Directory Server >>> SUSE Labs >>> _______________________________________________ >>> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx >>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx — Sincerely, William Brown Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
