openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#5281) doc contribution - set examples - following references
by ghenry＠OpenLDAP.org 02 Jan '08

02 Jan '08

andreas(a)mandriva.com.br wrote: > Full_Name: Andreas Hasenack > Version: 2.4.6 > OS: Linux > URL: http://users.mandriva.com.br/~andreas/ldap-doc/doc-set-examples/set-followi… > Submission from: (NULL) (200.140.247.99) > > > http://users.mandriva.com.br/~andreas/ldap-doc/doc-set-examples/set-followi… > > Documentation contribution with further examples regarding the usage of sets in > ACLs. This time, using a user/manager/secretary/group example. > > These files are derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by > Andreas Hasenack <andreas(a)mandriva.com.br>. These modifications are not subject > to any license of Mandriva. > I, Andreas Hasenack, hereby place the following modifications to OpenLDAP > Software (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose with or > without attribution and/or other notice. > > Thanks for this Andreas. I'll be working on a sets section in the ACL section shortly. It's up for discussion if the ACL discussion in the current config sections of the admin guide should stay there or be moved out into their own. More later. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5303) idlcache problem with new entries
by hyc＠symas.com 31 Dec '07

31 Dec '07

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.39 > OS: NA > URL: ftp://ftp.openldap.org/incoming/idlcache-bug.tar.gz > Submission from: (NULL) (76.21.80.71) > > > While testing heavy account provisioning using multiple threads to create > accounts in an OpenLDAP server, we discovered that the idl cache fails to > properly update, making searches for successfully added accounts fail to find > them. Setting the idlcachesize to zero resolved the search problem, indicating > an issue inside the idl cache code. This is a dup of ITS#5086, fixed in HEAD. Please test... > Zimbra bug is here: > > http://bugzilla.zimbra.com/show_bug.cgi?id=22933 > > > Description: > ============ > - OpenLDAP build: openldap-2.3.39 > - 20 concurrent threads are ADDing (distinct) entries in a loop under a > common base DN. > - It seems intermittently upon DB_LOCK_DEADLOCK errors, the integrity of > indexes are broken > for a period of time even after the ADD returns a good code(err=0). > Search filtered on an indexed > attribute of the newly ADDed entry cannot be found. If the same query is > done again later, it > did find the entry. > - This seems to happen only after "many" DB_LOCK_DEADLOCK errors. The > search failure usually happens > after 20 to 80 iterations into the loop, while the deadlock error would > start happening since earlier > iterations. > > Notes on info in attached slapd.log: > ==================================== > 1. The described test started on line 996. > > 2. Line 25510 shows the ADD > Dec 20 14:45:51 phoebe slapd[209]: conn=2235 op=1 ADD > dn="uid=a-120-thread-3,ou=people,dc=test-accounts-20071220-143806,dc=ldaptest" > > 3. Line 25542 shows the ADD was successful > Dec 20 14:45:52 phoebe slapd[209]: conn=2235 op=1 RESULT tag=105 err=0 > text= > > This entry should contain (among other attributes): > objectClass: zimbraAccount > zimbraId: be0b628b-b8d1-4fce-99cd-7b7f6864149a > > 4. Line 25549 - 25550 shows the search on that zimbraId returned 0 entry: > Dec 20 14:45:52 phoebe slapd[209]: conn=2235 op=2 SRCH base="" scope=2 > deref=3 filter="(&(zimbraId=be0b628b-b8d1-4fce-99cd-7b7f6864149a)(objectClass=zimbraAccount))" > Dec 20 14:45:52 phoebe slapd[209]: conn=2235 op=2 SEARCH RESULT tag=101 > err=0 nentries=0 text= > > 5. Later, the same search(as in 3) was attempted. Line 25756 - 25757 shows the > same query did find one entry this time: > Dec 20 14:48:25 phoebe slapd[209]: conn=2250 op=1 SRCH base="" scope=2 > deref=3 filter="(&(zimbraId=be0b628b-b8d1-4fce-99cd-7b7f6864149a)(objectClass=zimbraAccount))" > Dec 20 14:48:25 phoebe slapd[209]: conn=2250 op=1 SEARCH RESULT tag=101 > err=0 nentries=1 text= > > 6. As shown in the log, there was no MOD or anything on DN > dn="uid=a-120-thread-3,ou=people,dc=test-accounts-20071220-143806,dc=ldaptest" > between 3 and 4. > > 7. Other info: > - zimbraId is an indexed attribute. see slapd.conf. > - Note, the test stops when it encounters the first failed search after a > successful create. > > > > slapd.conf and slapd.log files are on the OpenLDAP ftp server as: > ftp://ftp.openldap.org/incoming/idlcache-bug.tar.gz > > > > -- -- 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#5303) idlcache problem with new entries
by quanah＠zimbra.com 31 Dec '07

31 Dec '07

Full_Name: Quanah Gibson-Mount Version: 2.3.39 OS: NA URL: ftp://ftp.openldap.org/incoming/idlcache-bug.tar.gz Submission from: (NULL) (76.21.80.71) While testing heavy account provisioning using multiple threads to create accounts in an OpenLDAP server, we discovered that the idl cache fails to properly update, making searches for successfully added accounts fail to find them. Setting the idlcachesize to zero resolved the search problem, indicating an issue inside the idl cache code. Zimbra bug is here: http://bugzilla.zimbra.com/show_bug.cgi?id=22933 Description: ============ - OpenLDAP build: openldap-2.3.39 - 20 concurrent threads are ADDing (distinct) entries in a loop under a common base DN. - It seems intermittently upon DB_LOCK_DEADLOCK errors, the integrity of indexes are broken for a period of time even after the ADD returns a good code(err=0). Search filtered on an indexed attribute of the newly ADDed entry cannot be found. If the same query is done again later, it did find the entry. - This seems to happen only after "many" DB_LOCK_DEADLOCK errors. The search failure usually happens after 20 to 80 iterations into the loop, while the deadlock error would start happening since earlier iterations. Notes on info in attached slapd.log: ==================================== 1. The described test started on line 996. 2. Line 25510 shows the ADD Dec 20 14:45:51 phoebe slapd[209]: conn=2235 op=1 ADD dn="uid=a-120-thread-3,ou=people,dc=test-accounts-20071220-143806,dc=ldaptest" 3. Line 25542 shows the ADD was successful Dec 20 14:45:52 phoebe slapd[209]: conn=2235 op=1 RESULT tag=105 err=0 text= This entry should contain (among other attributes): objectClass: zimbraAccount zimbraId: be0b628b-b8d1-4fce-99cd-7b7f6864149a 4. Line 25549 - 25550 shows the search on that zimbraId returned 0 entry: Dec 20 14:45:52 phoebe slapd[209]: conn=2235 op=2 SRCH base="" scope=2 deref=3 filter="(&(zimbraId=be0b628b-b8d1-4fce-99cd-7b7f6864149a)(objectClass=zimbraAccount))" Dec 20 14:45:52 phoebe slapd[209]: conn=2235 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= 5. Later, the same search(as in 3) was attempted. Line 25756 - 25757 shows the same query did find one entry this time: Dec 20 14:48:25 phoebe slapd[209]: conn=2250 op=1 SRCH base="" scope=2 deref=3 filter="(&(zimbraId=be0b628b-b8d1-4fce-99cd-7b7f6864149a)(objectClass=zimbraAccount))" Dec 20 14:48:25 phoebe slapd[209]: conn=2250 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= 6. As shown in the log, there was no MOD or anything on DN dn="uid=a-120-thread-3,ou=people,dc=test-accounts-20071220-143806,dc=ldaptest" between 3 and 4. 7. Other info: - zimbraId is an indexed attribute. see slapd.conf. - Note, the test stops when it encounters the first failed search after a successful create. slapd.conf and slapd.log files are on the OpenLDAP ftp server as: ftp://ftp.openldap.org/incoming/idlcache-bug.tar.gz

1 0

(ITS#5302) Possible leak in slapo-memberof
by ando＠sys-net.it 29 Dec '07

29 Dec '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando slapo-memberof re-injects internal modifications through the overlay stack, in case other overlays need to be processed. This may cause the leaking of saved membership values, since those modifications pass through all related instances of slapo-memberof. Better stored values disposal has been added.

1 0

(ITS#5301) Slapo-memberof cannot be used as global
by ando＠sys-net.it 29 Dec '07

29 Dec '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando Basically, because it makes use of be_entry_get_rw(), which is not available for the frontent, and because it can try to modify operational attributes (e.g. the modifiersName), while the frontend does not expect modifications to be SLAP_MOD_INTERNAL that early. A fix is coming. p.

1 0

I find a errorin this function LDAPSearchResults search(LDAPUrl toGet)
by 周建国 28 Dec '07

28 Dec '07

when i use connection pool i run this function search(LDAPUrl toGet),it will appear a error :can not close the connection so i try to correct the bug,it is no problem: LDAPConfigurationReader LDAPConfigurationReader = null; LDAPConfigurationReader=LDAPConfigurationReader.getInstance (); Map hashMap = null; try { hashMap = LDAPConfigurationReader.getConfiguration(); } catch (Exception e) { // TODO Auto-generated catch block e.printStackTrace(); } connectionFactory=ConnectionFactory.getInstance(); poolManager=connectionFactory.connection(hashMap); LDAPConnection=connectionFactory.bindConnection (poolManager); LDAPSearchResults searchResults = LDAPConnection.search(LDAPConnection,myUrl ); public static LDAPSearchResults search(LDAPConnection LDAPConnection,LDAPUrl toGet) throws LDAPException { // Get a clone of default search constraints, method alters batchSize return search( LDAPConnection,toGet, null); } public static LDAPSearchResults search(LDAPConnection LDAPConnection,LDAPUrl toGet, LDAPSearchConstraints cons) throws LDAPException { if( Debug.LDAP_DEBUG) { Debug.trace( Debug.apiRequests, "LDAPConnection.search(" + toGet.toString() + ")"); } //LDAPConnection lconn = new LDAPConnection(); LDAPConnection.connect(toGet.getHost(),toGet.getPort()); if( cons == null) { // This is a clone, so we already have our own copy cons = LDAPConnection.getSearchConstraints(); } else { // get our own copy of user's constraints because we modify it cons = (LDAPSearchConstraints)cons.clone(); } cons.setBatchSize(0); // Must wait until all results arrive LDAPSearchResults toReturn = LDAPConnection.search(toGet.getDN(), toGet.getScope(), toGet.getFilter(), toGet.getAttributeArray (), false, cons); //lconn.disconnect(); return toReturn; } -- My MSN:zhoujianguo_leo@hotmail.com i from china shanghai

1 0

Re: (ITS#5293) ldapdelete issue
by ando＠sys-net.it 27 Dec '07

27 Dec '07

chitrav(a)us.ibm.com wrote: > when I tried to do an ldapdelete command with -r option, I get the following > error for every entry in the server, although all the entries do get deleted. > > ldap_search: Server is unwilling to perform (53) > additional info: critical control unavailable in context > > On looking at the ldapdelete.c source code, lines 390 and 391 say > c.ldctl_oid = LDAP_CONTROL_SUBENTRIES; > c.ldctl_iscritical = 1; > > Marking the iscritical flag to 0, makes the error go away. > > I am not sure what this control does. This seems like a bug though. > If so, please let me know what the fix should be, and in which release it will > be available. This control was added because in early implementations of sync replication subentries were added to the database to contain replication-related data; without the control, a recursive delete would have failed since the subentry wouldn't be returned by the search that determines the list of DNs to be deleted. The fact slapd complains seems to indicate you're using a backend that does not support that control. AFAIK, it is only supported by back-bdb (and back-hdb); usually, you shouldn't be using anything else, though. p. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5286) NULL value in sets
by ando＠sys-net.it 27 Dec '07

27 Dec '07

raphael.ouazana(a)linagora.com wrote: > I repost this here as I think the discussion was lost in a closed ITS (#4860). > The two solutions (other operation or previous behavior) would be fine for us, > but I have not really time to make a patch for the moment. Should be fixed in HEAD; please test. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5300) Filter causes abort
by aej＠wpi.edu 27 Dec '07

27 Dec '07

Full_Name: Allan E. Johannesen Version: 2.4.7 OS: Linux URL: Submission from: (NULL) (24.177.50.33) in 2.4.7 a search filter "(cn=** *stuff)" causes an abort. In a program: ./x '(cn=** *stuff)' x: getentry.c:36: ldap_first_entry: Assertion `chain != ((void *)0)' failed. Abort With ldapsearch: > ldapsearch -VV ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.7 (Dec 17 2007 09:23:50) $ aej@CCC1.WPI.EDU:/tools/src/openldap/RHEL4-i686/openldap-2.4.7/clients/tools (LDAP library: OpenLDAP 20407) > ldapsearch '(cn=** *stuff)' SASL/GSSAPI authentication started SASL username: aej(a)WPI.EDU SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <dc=WPI, dc=EDU> (default) with scope subtree # filter: (cn=** *stuff) # requesting: ALL # # extended result response extended: 1.3.6.1.4.1.1466.20036 result: 2 Protocol error text: unexpected data in PDU # numResponses: 1 # numExtended: 1

1 0

(ITS#5299) slapo-memberof objectClass inheritance
by ando＠sys-net.it 27 Dec '07

27 Dec '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando When adding a group object containing member values, if group's objectClass(es) is derived from the memberOf group class backward references are not updated, while they are as a consequence of modify operations (because in that case objectClass inheritance is guaranteed by internal search filtering). Consistency should be restored by supporting objectClass inheritance during adds as well. A fix is coming. p.

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