On 23 Jan 2019, at 20:14, Mihai Carabas
<mihai.carabas(a)gmail.com> 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(a)gmail.com> wrote:
>
> On Wed, Jan 23, 2019 at 4:52 AM William Brown <wbrown(a)suse.de> wrote:
>>
>>
>>
>>> On 23 Jan 2019, at 02:01, Mihai Carabas <mihai.carabas(a)gmail.com>
wrote:
>>>
>>> Helllo,
>>>
>>> On Tue, Jan 22, 2019 at 11:45 AM Ludwig <lkrispen(a)redhat.com> 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(a)lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>> 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@lists.fedoraproje...
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
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@lists.fedoraproje...
—
Sincerely,
William Brown
Software Engineer, 389 Directory Server
SUSE Labs