Re: (ITS#5303) idlcache problem with new entries
by hyc＠symas.com
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/
15 years, 9 months
(ITS#5303) idlcache problem with new entries
by quanah＠zimbra.com
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
15 years, 9 months
(ITS#5302) Possible leak in slapo-memberof
by ando＠sys-net.it
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.
15 years, 9 months
(ITS#5301) Slapo-memberof cannot be used as global
by ando＠sys-net.it
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.
15 years, 9 months
I find a errorin this function LDAPSearchResults search(LDAPUrl toGet)
by 周建国
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
15 years, 9 months
Re: (ITS#5293) ldapdelete issue
by ando＠sys-net.it
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
---------------------------------------
15 years, 9 months
Re: (ITS#5286) NULL value in sets
by ando＠sys-net.it
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
---------------------------------------
15 years, 9 months
(ITS#5300) Filter causes abort
by aej＠wpi.edu
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
15 years, 9 months
(ITS#5299) slapo-memberof objectClass inheritance
by ando＠sys-net.it
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.
15 years, 9 months
Re: (ITS#5222) Missing PDF manual for 2.4
by ghenry＠suretecsystems.com
> Hi Kurt -
>
> The link on the website (http://www.openldap.org/doc/) for the 2.4 pdf
> manual is actually the 2.3 manual. I was somewhat confused by this
> until after I compiled the 2.4.7 sources, and then was finding differences
> and noticed that the title page was still 2.3. Anyway, I was able to
> locate, download and install sdf and htmldoc so that I could generate a
> copy of the pdf. It would be nice however if you could update the link
> on the website, re-generate the doc to have the actual 2.4 guide, or fix
> the Makefile to put the correct doc pdf in place on the website.
>
> Raymond - Attached is the 2.4 pdf, I generated yesterday in case you
> didn't actually get the 2.4 PDF manual.
>
Hmmm:
http://www.openldap.org/doc/admin24/OpenLDAP-Admin-Guide.pdf
Linked from http://www.openldap.org/doc/
15 years, 9 months
