openldap-bugs

openldap-bugs@openldap.org

1 participants
21026 discussions

(ITS#4922) test_filter problem on uid filter
by juritanganelli＠gmail.com 10 Apr '07

10 Apr '07

Full_Name: juri tanganelli Version: 2.3.27 OS: Red Hat EL 3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.7.19.10) I have developed a custom backend that uses the test_filter function to determine if an entry is matching a given input filter. Filter on any of the entry attribute but Uid works fine. When i specify i filter on the uid attribute i get very strange results for example: - when i use the complete value of the attribute such as uid=e497004 no result is returned, but there is an entry with that value. - when i use some regular expressions the result is correclty such as uid=e* the corresponding entry is correctly returned. Regards, Juri

1 0

(ITS#4921) back-config and included ACLs
by ghenry＠suretecsystems.com 10 Apr '07

10 Apr '07

Full_Name: Gavin Henry Version: 2.3.35 OS: Fedora Core 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Dear All, Minor issue. When including an acl file, this acl file appears in cn=schema: dn: cn=include{8},cn=config objectClass: olcIncludeFile cn: include{8} olcInclude: /usr/local/etc/openldap/suretec.acl Shows as: dn: cn={8}suretec,cn=schema,cn=config objectClass: olcSchemaConfig cn: {8}suretec I don't think this should show in the schema tree. Thanks, Gavin.

1 0

Re: (ITS#4920) bad connection sequencing
by hyc＠symas.com 09 Apr '07

09 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: http://folk.uio.no/hbf/OpenLDAP/bug032.tgz > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > Statslog() from even successful tests can show strange sequencing. > > grep '^conn=' testrun/slapd.*.log from a test032-chain run shows > - Operations logged on connections before ACCEPT > (slapd.1.log conn=2,3 + slapd.2.log conn=7,9) > - Operations on a connection with no ACCEPT (slapd.1.log conn=10), > but a 'conn=-1 fd=21 ACCEPT' _after_ that fd's 'close', > and valgrind shows memory errors between the close and the ACCEPT. > The enclosed URL gives the testrun directory and test output. Haven't looked at that yet. > Similar things show up in other tests. A test019 run with a > conn=-1 ACCEPT did not get valgrind memory compaints though. > grep 'conn=-1' testrun/slapd.*.log also found a number of > send_ldap_result: conn=-1 op=0 p=<0 or 3> > even in logs without any conn=-1, but maybe that's a "fake > connection"? Don't know why results are sent though. send_ldap_result is always logged, since it occurs before callback processing. So even if it's an internal op with a null callback, it will get logged. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4920) bad connection sequencing
by h.b.furuseth＠usit.uio.no 09 Apr '07

09 Apr '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: http://folk.uio.no/hbf/OpenLDAP/bug032.tgz Submission from: (NULL) (129.240.202.105) Submitted by: hallvard Statslog() from even successful tests can show strange sequencing. grep '^conn=' testrun/slapd.*.log from a test032-chain run shows - Operations logged on connections before ACCEPT (slapd.1.log conn=2,3 + slapd.2.log conn=7,9) - Operations on a connection with no ACCEPT (slapd.1.log conn=10), but a 'conn=-1 fd=21 ACCEPT' _after_ that fd's 'close', and valgrind shows memory errors between the close and the ACCEPT. The enclosed URL gives the testrun directory and test output. Similar things show up in other tests. A test019 run with a conn=-1 ACCEPT did not get valgrind memory compaints though. grep 'conn=-1' testrun/slapd.*.log also found a number of send_ldap_result: conn=-1 op=0 p=<0 or 3> even in logs without any conn=-1, but maybe that's a "fake connection"? Don't know why results are sent though.

1 0

Re: (ITS#4919) Why CPU usage can not reach 100% while doing modify operation?
by hyc＠symas.com 09 Apr '07

09 Apr '07

The ITS is for tracking bug reports and enhancement requests. I don't see a bug report here. Try asking your question on the OpenLDAP-software mailing list. This ITS will be closed. seuler(a)163.com wrote: > Full_Name: Seuler Shi > Version: openldap-2.3.30 > OS: SUSE 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.138.202.50) > > > When I do the search operation, the CPU usage of OpenLDAP Server can reach 100% > when the number of search operations per second arise? But for the modify > operation, > the CPU usage can only reach 87% at most? > > What is the bottleneck that makes OpenLDAP can not make CPU recource fully while > > doing modify operation? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4919) Why CPU usage can not reach 100% while doing modify operation?
by seuler＠163.com 09 Apr '07

09 Apr '07

Full_Name: Seuler Shi Version: openldap-2.3.30 OS: SUSE 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.138.202.50) When I do the search operation, the CPU usage of OpenLDAP Server can reach 100% when the number of search operations per second arise? But for the modify operation, the CPU usage can only reach 87% at most? What is the bottleneck that makes OpenLDAP can not make CPU recource fully while doing modify operation?

1 0

Re: (ITS#4916) syncrpl consumer not listing contextcsn as operation attr
by brian＠zimbra.com 06 Apr '07

06 Apr '07

thanks, that worked, this case can be closed. Brian Peterson On Apr 6, 2007, at 1:58 PM, Howard Chu wrote: > brian(a)zimbra.com wrote: >> Full_Name: Brian Peterson >> Version: 2.3.34 >> OS: Linux >> URL: pro >> Submission from: (NULL) (66.92.25.194) >> When setup sync replication the contextCSN is available via >> ldapsearch on the >> provider but not the consumer as an operation attribute. If we do >> a slapcat on >> the consumer the resulting ldif contains the contextCSN. > > This is because your context entry has no DN, it's a glue entry. > When you do a search on it you get the contents of the server > rootDSE instead of your glue entry. The search works on the > provider because the syncprov overlay intercepts searches to insert > the current contextCSN value in the result. You can add a syncprov > overlay to the consumer to get the same effect. > >> Top entry from slapcat ldif on the consumer. >> dn: >> objectClass: glue >> structuralObjectClass: glue >> contextCSN: 20070405182202Z#000000#00#000000 >> entryCSN: 20070405182202Z#000000#00#000000 >> modifiersName: uid=zimbra,cn=admins,cn=zimbra >> modifyTimestamp: 20070405182202Z > > > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4918) int = pointer assignment in syncrepl
by hyc＠symas.com 06 Apr '07

06 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE23 > OS: > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > In RE23:syncrepl.c:do_syncrepl() lin 1155, the statement > fail = si->si_retrynum; > assigns an int* to an int. > > > . > Thanks, fixed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4918) int = pointer assignment in syncrepl
by h.b.furuseth＠usit.uio.no 06 Apr '07

06 Apr '07

Full_Name: Hallvard B Furuseth Version: RE23 OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard In RE23:syncrepl.c:do_syncrepl() lin 1155, the statement fail = si->si_retrynum; assigns an int* to an int.

1 0

Re: (ITS#4916) syncrpl consumer not listing contextcsn as operation attr
by hyc＠symas.com 06 Apr '07

06 Apr '07

brian(a)zimbra.com wrote: > Full_Name: Brian Peterson > Version: 2.3.34 > OS: Linux > URL: pro > Submission from: (NULL) (66.92.25.194) > > > When setup sync replication the contextCSN is available via ldapsearch on the > provider but not the consumer as an operation attribute. If we do a slapcat on > the consumer the resulting ldif contains the contextCSN. This is because your context entry has no DN, it's a glue entry. When you do a search on it you get the contents of the server rootDSE instead of your glue entry. The search works on the provider because the syncprov overlay intercepts searches to insert the current contextCSN value in the result. You can add a syncprov overlay to the consumer to get the same effect. > Top entry from slapcat ldif on the consumer. > dn: > objectClass: glue > structuralObjectClass: glue > contextCSN: 20070405182202Z#000000#00#000000 > entryCSN: 20070405182202Z#000000#00#000000 > modifiersName: uid=zimbra,cn=admins,cn=zimbra > modifyTimestamp: 20070405182202Z > > > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs