Re: (ITS#7168) [PATCH] Fix count constraint when using multiple modifications
by hyc＠symas.com
jsynacek(a)redhat.com wrote:
> Full_Name: Jan Synacek
> Version: 2.4.29
> OS: Fedora 16
> URL: http://jsynacek.fedorapeople.org/openldap/jsynacek-20120216-constraint-co...
> Submission from: (NULL) (209.132.186.34)
>
>
> Constraint overlay doesn't take into account multiple modifications when using
> count.
>
> Example: If count for 'description' attribute is set e.g. to 2, the following
> results in a constraint violation:
>
> dn: cn=usr2, dc=my-domain,dc=com
> add: description
> description: d1
> description: d2
> description: d3-viol
>
> However, this passes:
>
> dn: cn=usr2, dc=my-domain,dc=com
> add: description
> description: d1
> -
> add: description
> description: d2
> -
> add: description
> description: d3
>
> This patch fixes the behavior in case multiple modifications are used.
>
> Original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=742163
>
> The patch is uploaded on fedorapeople.org:
> http://jsynacek.fedorapeople.org/openldap/jsynacek-20120216-constraint-co...
>
> I wasn't able to use ftp.openldap.org due to 'No space left' error.
This code (and the original) don't seem to properly take deletes into account.
It resets the ce counter to 0 on any delete op, but it should be decrementing
based on the number of values provided. (And of course, it can only do that if
the specified value is actually present in the attribute.)
> The attached file is derived from OpenLDAP Software. All of the modifications
> to
> OpenLDAP Software represented in the following patch(es) were developed by Red
> Hat. Red Hat has not assigned rights and/or interest in this work to any party.
> I, Jan Synacek am authorized by Red Hat, my employer, to release this work
> under
> the following terms.
>
> Red Hat 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.
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years, 9 months
Re: (ITS#7292) Memory leak with MMR + delta syncrepl
by brandon.hume＠DAL.CA
On 06/ 6/12 12:57 PM, Quanah Gibson-Mount wrote:
>
> These may not be causing the issue you are seeing, but they should be
> fixed and then the setup retested. Of particular concern to me is
> item (a). I would make cn=monitor be olcDatabase {3}.
Done, thanks for pointing out the problems. I think I introduced them
accidentally while backend-hopping during testing, but I'll check my
prod setup as well.
I've made the changes and retested. The new node is still replicating,
but after 50 cpu-minutes the process is at 10.2G and still going. I
believe the leak is still present.
10 years, 9 months
Re: (ITS#7286) Malformed search filter to back-ldap/slapo-rwm crashes slapd
by michael＠stroeder.com
masarati(a)aero.polimi.it wrote:
> On 06/05/2012 12:48 PM, hyc(a)symas.com wrote:
>> gahaverkamp(a)lbl.gov wrote:
>>> --e89a8fb1fbfae973ef04c1b0bad6
>>> Content-Type: text/plain; charset=ISO-8859-1
>>>
>>> I thought I had, but I now see that I left off "full".
>>>
>>> (gdb) bt full
>>
>> We slso need to see the slapd config.
>
> Without carefully looking at it, it could be related to reinstalling the
> original context because of the error. See ITS#6166.
There's a similar issue ITS#6997 in which you also referenced ITS#6166. In
case of ITS#6997 it used to work with OpenLDAP 2.4.23 but does not with 2.4.24+.
Maybe Greg could check whether his setup would also work with 2.4.23.
Ciao, Michael.
10 years, 9 months
Re: (ITS#7292) Memory leak with MMR + delta syncrepl
by quanah＠zimbra.com
--On Wednesday, June 06, 2012 2:33 PM +0000 brandon.hume(a)dal.ca wrote:
> Full_Name: Brandon Hume
> Version: 2.4.31
> OS: RHEL EL6.1, kernel 2.6.32-131.12.1.el6.x86_64
> URL: http://den.bofh.ca/~hume/ol-2.4.31_memleak.tar.gz
> Submission from: (NULL) (2001:410:a010:2:223:aeff:fe74:400e)
>
>
> OpenLDAP 2.4.31 compiled in 64-bit with BerkeleyDB 5.3.15 appears to
> exhibit a memory leak while replicating the full database from another
> node in MMR.
There are definite errors in your cn=config configuration.
a) You have multiple databases numbered "1":
dn: olcDatabase={1}hdb,cn=config
dn: olcDatabase={1}monitor,cn=config
b) Syncprov overlay for accesslog:
dn: olcOverlay={0}syncprov,olcDatabase={1}hdb,cn=config
Remove the checkpoint and sessionlog settings
c) There should be no sessionlog on the primary DB with delta-syncrepl MMR:
dn: olcOverlay={0}syncprov,olcDatabase={2}hdb,cn=config
Remove olcSpSessionlog: 10000
These may not be causing the issue you are seeing, but they should be fixed
and then the setup retested. Of particular concern to me is item (a). I
would make cn=monitor be olcDatabase {3}.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
10 years, 9 months
(ITS#7292) Memory leak with MMR + delta syncrepl
by brandon.hume＠dal.ca
Full_Name: Brandon Hume
Version: 2.4.31
OS: RHEL EL6.1, kernel 2.6.32-131.12.1.el6.x86_64
URL: http://den.bofh.ca/~hume/ol-2.4.31_memleak.tar.gz
Submission from: (NULL) (2001:410:a010:2:223:aeff:fe74:400e)
OpenLDAP 2.4.31 compiled in 64-bit with BerkeleyDB 5.3.15 appears to exhibit a
memory leak while replicating the full database from another node in MMR.
A two-node MMR configuration has been set up. Node 1 is full populated with
data, approximately 338k DNs, which occupies around 1G on-disk (including bdb
__db.* and log.* files). Node 1 is brought up and on a 64-bit system occupies
around 5.5G VM and 4.7G RSS.
Node 2 is initialized with a copy of cn=config (slapcat/slapadd method) and
brought up with an empty database to begin replication. Over the course of the
replication, node 2's slapd will grow continuously. On the one occasion it
managed to "finish" the replication (with the test database), node 2's slapd
occupied 14G VM and approximately 6G RSS.
I've included a link to the test kit I put together. This includes a fairly
large, anonimized database, as well as a simplified copy of the configuration.
I've left in the sendmail and misc schemas but removed irrelevant local schemas.
Also included are the DB_CONFIGs used for the main database and accesslog, and
the configuration scripts used for compiling both bdb and OpenLDAP.
Steps to reproduce:
- Compile and install bdb and OpenLDAP with options the same as in the
config-db.sh and config-ldap.sh scripts.
- Initialize configuration on node 1 and 2 using "slapadd -F etc/slapd.d -b
cn=config -l slapd-conf.ldif".
- Initialize main DB on node 1 using "slapadd -l test_dit.ldif"
- Start node 1. The slapd process should stabilize at around 5G VM in use.
- Start node 2 and allow it to begin replication.
I've tested with node 2 on both RHEL6 and on Solaris 10. In both cases, node
2's slapd became extremely bloated over the course of several hours. Only the
Solaris SPARC box was able to complete the replication, stabilizing at 14G VM
used. The Redhat x86 box continued to grow far beyond the 16G swap limit and
was killed by the OS.
I've attempted to use the Solaris libumem tools to trace the memory leak, using
gcore on the running process and "::findleaks -dv" within mdb running on the
core. I've included the report generated in case it provides any useful
information as "mdb_findleaks_analysis.txt". Disregard if you wish.
(I apologize for the large test LDIF. I wanted something to definitively show
the problem so didn't want to trim it too much...)
10 years, 9 months
(ITS#7291) [PATCH] MozNSS: read pin from file file can cause infinite loop
by jvcelak＠redhat.com
Full_Name: Jan Vcelak
Version: git master
OS: Linux
URL: ftp://ftp.openldap.org/incoming/jvcelak-20120606-moznss-read-pin-from-fil...
Submission from: (NULL) (209.132.186.34)
The buffer allocated for reading password (pin) file has to be initialized with
zeros, or we need to append zero at the end of the file. Otherwise we might read
initialized memory and consider it to be a password. In this situation, all
incoming TLS connections can hang.
Attached patch fixes this bug.
The attached file is derived from OpenLDAP Software. All of the modifications to
OpenLDAP Software represented in the following patch(es) were developed by Red
Hat. Red Hat has not assigned rights and/or interest in this work to any party.
I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under
the following terms.
Red Hat 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.
10 years, 9 months
