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...