openldap-bugs

openldap-bugs@openldap.org

1 participants
21513 discussions

Re: (ITS#5764) addpartial patch
by hyc＠symas.com 04 Nov '08

04 Nov '08

dhawes(a)vt.edu wrote: > The patch referenced previously can be discarded. This patch contains > all changes against 2.4.12. I suspect HEAD and 2.4.12 are identical here so it's no big deal this time, but remember for future reference, http://www.openldap.org/devel/contributing.html all contributions must be relative to HEAD. -- -- Howard Chu CTO, 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#5764) addpartial patch
by dhawes＠vt.edu 04 Nov '08

04 Nov '08

dhawes(a)vt.edu wrote: > Pierangelo Masarati wrote: >> dhawes(a)vt.edu wrote: >>> Full_Name: David Hawes >>> Version: 2.4.12 >>> OS: URL: ftp://ftp.openldap.org/incoming/david-hawes-081021.patch >>> Submission from: (NULL) (128.173.38.164) >>> >>> >>> This patch includes the following changes: >>> >>> - -fPIC added to the Makefile for compilation on x86_64 systems. >>> - No longer use be_search() to retrieve the entry that is to be >>> compared. Use >>> be_entry_get_rw() instead. >> You should probably use overlay_entry_get_ov() rather than >> be_entry_get_rw() from inside an overlay (AFAIR). > > Okay, I'll make that change, thanks. > > I notice that most overlays seem to use be_entry_get_rw(), and one > (translucent) uses both. What is the reasoning to use one over the other? New patch that uses overlay_entry_get_ov() available at: ftp://ftp.openldap.org/incoming/david-hawes-081104.patch The patch referenced previously can be discarded. This patch contains all changes against 2.4.12.

1 0

Re: (ITS#5783) Possible DB corruption
by ando＠sys-net.it 04 Nov '08

04 Nov '08

moya(a)latertulia.org wrote: > Full_Name: Maykel Moya > Version: 2.4.11 > OS: Debian Lenny > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.55.135.211) > > > It's second time that I have bitten by this: > > Oct 31 07:49:24 swage slapd[4308]: PROXIED attributeDescription "DC" inserted. > > After that I'm unable to bind against the DSA. The problem has arise in two > independent systems. > > Steps to reproduce: > > 1. Create a minor db (like Debian does), a dc=foo,dc=org node and a > cn=admin,rootdn node > 2. Migrate to cn=config > 3. Edit cn=config > I've added olcTLSCACertificateFile / olcTLSCertificateFile / > olcTLSCertificateKeyFiel attributes > 4. Restart the server > > After restarting I see the PROXIED error. I'd wrote to the list before [1][2] > but the same thing has come in another system. This does not look like a db corruption. It looks like you restarted slapd with back-config in a compromised state, since it is now missing the definition of "dc", which is in core.schema. You don't specify how you edited cn=config; did you manually edited the corresponding ldif files? You're supposed to modify them only via operations using the LDAP protocol while the server is running. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr 04 Nov '08

04 Nov '08

Howard Chu wrote : >I see. > >This has been fixed for back-bdb/hdb in HEAD. If the database was shut down >cleanly before, there will be no scan on the next startup. Hi Howard, Thanks for the corrections. We tested the HEAD extracted on monday november 3. Unfortunately the problem explained in point 2 persists (even after a clean shutdown). Our directory contains 10 million entries. It can evolve to 40 million entries next year. The local sacanning speed is around 250 000 entries per minute. So the scan of the recent objects on the standby mirror after startup can take several minutes (unless if we distribute the write operations on both mirrors). Best Regards Ali

1 0

Re: (ITS#5709) slapd sync provider skips some objects
by sylvain.thomas＠gmail.com 04 Nov '08

04 Nov '08

We tested the HEAD version extracted november 4th : the problem is fixed. The ITS can be closed. thank you for your help ! Best regards Sylvain Thomas

1 0

Re: (ITS#5789) using IP address in CN with GnuTLS
by hyc＠symas.com 04 Nov '08

04 Nov '08

leva(a)ecentrum.hu wrote: > Full_Name: LÉVAI Dániel > Version: 2.4.11 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (78.131.56.68) > > > I'm using OpenLDAP 2.4.11 on a Debian testing/lenny system. > The GnuTLS version is 2.4.2. > > So it seems, according to OpenLDAP, 192.168.1.3 != 192.168.1.3. Why is that? > > And please allow me include some additional information, which was told me by > Philip Guenther on openldap-software@: > "It appears the routine used with GNUtls > refuses to match IP addresses against a CN subjects component, thus > explaining that weird message. > > (In ldap_pvt_tls_check_hostname(), 'len1' is only non-zero if the hostname > doesn't look like an IPv6 or IPv4 address, while the subject CN test needs > 'len1' to be the same as the length of the CN value.)" Thanks for the report, now fixed in HEAD. Note that using an IP address in the CN is not the way you're supposed to generate certs; IP addresses belong in the subjectAltName extension. The CN is only supposed to contain a fully qualified domain name. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5791) searches with entryDN in the filter scan the whole db
by ando＠sys-net.it 04 Nov '08

04 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando Filtering for entryDN equality requires scanning the whole DB, although dn's are indexed in dn2id. See also ITS#5790

1 0

(ITS#5790) Indexing for entryDN results in no entry found
by ando＠sys-net.it 04 Nov '08

04 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando If an explicit equality index is set for entryDN, searches with entryDN in the filter find no entries.

1 0

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by toby＠inf.ed.ac.uk 04 Nov '08

04 Nov '08

On 4 Nov 2008, at 09:26, Pierangelo Masarati wrote: > toby(a)inf.ed.ac.uk wrote: >> Hi there, is there any further debugging I could usefully carry >> out for this issue, or does it need someone who understands the >> code a bit better? > > It's not a debugging problem, but rather a design issue. The > current design makes use of the first AVA of the filter to decide > how two filters are compared. In your case, the first component is > common to all filters, so only the first occurrence of a search with > that template can be cached. This fact, to my knowledge, is > undocumented, but there's little to do except redesign this weighing > criterium. As I already pointed out, you need to make the most > significant filter AVA appear first in your filter template. Unless > anyone voluteers for a complete redesign [*] of this portion of > slapo-pcache(5), I take your ITS as a request to document this > aspect of template design. > > p. > > [*] a complete redesign could also get rid of strict ordering of > filter AVAs, allow "static" portions of the filter (something like > (&(objectClass=person)(uid=)) and so) and other relatively > unfriendly aspects of slapo-pcache(5) configuration. The problem with changing the ordering in the template is that it then doesn't match the real lookups that occur and so the entries aren't cached - this is something over which I have no control - e.g. queries generated by 'ls -l', or by somebody logging into the machine, etc, etc. This is why we have the filters this way. e.g. sshing into one of our scientific linux 5.2 hosts generates the following lookups: [sybies]toby: grep 'query template' ~/tmp/pcache-login |cut -d' ' -f13| sort|uniq -c 1 (&(objectClass=)(cn=)) 2 (&(objectClass=)(|(memberUid=)(uniqueMember=))) 28 (&(objectClass=)(uid=)) 5 (&(objectClass=)(uidNumber=)) 26 (&(objectClass=)(uniqueMember=)) [sybies]toby: Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by ando＠sys-net.it 04 Nov '08

04 Nov '08

toby(a)inf.ed.ac.uk wrote: > Hi there, is there any further debugging I could usefully carry out > for this issue, or does it need someone who understands the code a bit > better? It's not a debugging problem, but rather a design issue. The current design makes use of the first AVA of the filter to decide how two filters are compared. In your case, the first component is common to all filters, so only the first occurrence of a search with that template can be cached. This fact, to my knowledge, is undocumented, but there's little to do except redesign this weighing criterium. As I already pointed out, you need to make the most significant filter AVA appear first in your filter template. Unless anyone voluteers for a complete redesign [*] of this portion of slapo-pcache(5), I take your ITS as a request to document this aspect of template design. p. [*] a complete redesign could also get rid of strict ordering of filter AVAs, allow "static" portions of the filter (something like (&(objectClass=person)(uid=)) and so) and other relatively unfriendly aspects of slapo-pcache(5) configuration. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs