June 2012 - openldap-bugs

Re: (ITS#7299) Memory leaks when using ldapmodify to add members to groupOfNames objectclass

by jsynacek＠redhat.com

On 06/15/2012 03:16 PM, hyc(a)symas.com wrote: > jsynacek(a)redhat.com wrote: >> Full_Name: Jan Synacek >> Version: git (c73ec15) >> OS: linux-fedora17 >> URL: http://jsynacek.fedorapeople.org/openldap/leak/openldap-mmr-leak.tar.gz >> Submission from: (NULL) (209.132.186.34) >> >> >> I'm using a 2-node mmr setup on my local machine - configuration files and >> 'uploader' scripts are provided in the archive. >> >> 1) I have the two nodes running. >> 2) Execute run.sh (only a wrapper for ldapusradm.sh) and start monitoring >> slapd's memory usage. >> 3) After some time (at about 2k users on my system), slapd consumes a large >> amount of memory which is still growing >> >> Note that not using ldapmodify to add members to 'cn=users,dc=yes,dc=my', but >> using it e.g. for modifying each user's email, does NOT result in any memory >> leakage. >> >> I have also created a massif output using valgrind's massif tool: >> http://jsynacek.fedorapeople.org/openldap/leak/massif.out.17906 >> >> I found a very similar bug (#7292), but I'm not sure if it's related. > > Running RE24 with valgrind --leak-check=full I see no leak when running your > test. That should be the same as git c73ec15. No idea what leak you're seeing. > The memory consumption still grows and slapd eventually gets killed by oom-killer. Also, the second node (the one that the data is being replicated to) constantly calls dnPretty and dnNormalize on every single user that it has synced. At about 2k users, this starts to really show on CPU usage and overall speed as well. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

10 years, 9 months

1
0
0 / 0

Re: (ITS#7307) Inconsistent "!" evaluation

by kurt＠OpenLDAP.org

Read the spec. OpenLDAP follows it to a T here. -- Kurt

10 years, 9 months

1
0
0 / 0

Re: (ITS#7307) Inconsistent "!" evaluation

by michael＠stroeder.com

kurt(a)OpenLDAP.org wrote: > quanah(a)zimbra.com wrote: >> Kurt(a)OpenLDAP.org wrote: >>> On Jun 14, 2012, at 2:10 PM, quanah(a)openldap.org wrote: >>>> Handling "!" with objectClasses appears to be broken. For example, >>>> if I perform the following ldap query: >>>> >>>> zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config >>>> -w zimbra -b "" '(!(objectclass=junk))' >>>> >>>> This result appears incorrect to me. I would expect it to return >>>> all entries without that objectClass (which in this case, would be every >>>> entry). >>> >>> which object class (by OID)? If the server doesn't know what junk >>> is (!(objectClass=junk)) is just as undefined (objectclass=junk) is. So basically the question is: What is the negation of undefined in this context. You're saying undefined and this would mean False. But I agree with Quanah: I also expect the server to return all entries if object class 'junk' is not in the server's schema. This seems to be canonical behaviour. Various other LDAP server vendors have implemented it like this (tested on OpenDJ). > if the server doesn't know what objectClass (by OID) the descriptor > refers to, it doesn't know whether the objectClass is in the schema or > not. The server already evaluates this to "undefined" based on what's in the server's schema. So I don't understand your argument. > 'junk', for all the server knows, could refer to the same objectClass > the 'top' descriptor refers to. Why? >> I don't think it should fail to evaluate. > > It evaluates the expression to Undefined, which is exactly the > situation. Junk is not defined. To evaluate (objectClass=junk) to > true or false requires the server to know exactly what object class > 'junk' refers to. It doesn't in this case. I don't think that in case of negation a server has to mean exactly what object class 'junk' refers to. It has to simply know that none of the existing object classes refer to 'junk'. If 'junk' is not in the server's subschema the negation evaluates to True. >> Clearly, if none of the objects match the filter, >> it should return them. > > No, that's not clear. junk could be defined as: > > ( 2.5.6.0 NAME ( 'top' 'junk' ABSTRACT MUST objectClass ) If this object class description is not in the server's schema this argument is not relevant at all. > You are making assumptions regarding how junk is actually defined. The > server should not make any assumptions. Yes, the server should only look in its schema. Still I don't see any true argument why the fact that (objectClass=junk) cannot be true leads to the conclusion that (!(objectClass=junk)) is not true either. > Also, even if junk was defined in the client's schema: > ( 1.1.1.1 NAME ( 'junk' 'crap' ) AUXILIARY MUST objectClass ) > > and the server could easily have in its schema: > ( 1.1.1.1 NAME 'crap' AUXILIARY MUST objectClass ) > in its schema and lots of entries belonging to this class. Such a situation is not relevant for this discussion. And IMO there is no such thing like a client's schema (saying this while being the author of a LDAP client which makes the most versatile use of subschema information with a fall-back schema on the client's side). Ciao, Michael.

10 years, 9 months

1
0
0 / 0

Re: (ITS#7299) Memory leaks when using ldapmodify to add members to groupOfNames objectclass

by hyc＠symas.com

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: git (c73ec15) > OS: linux-fedora17 > URL: http://jsynacek.fedorapeople.org/openldap/leak/openldap-mmr-leak.tar.gz > Submission from: (NULL) (209.132.186.34) > > > I'm using a 2-node mmr setup on my local machine - configuration files and > 'uploader' scripts are provided in the archive. > > 1) I have the two nodes running. > 2) Execute run.sh (only a wrapper for ldapusradm.sh) and start monitoring > slapd's memory usage. > 3) After some time (at about 2k users on my system), slapd consumes a large > amount of memory which is still growing > > Note that not using ldapmodify to add members to 'cn=users,dc=yes,dc=my', but > using it e.g. for modifying each user's email, does NOT result in any memory > leakage. > > I have also created a massif output using valgrind's massif tool: > http://jsynacek.fedorapeople.org/openldap/leak/massif.out.17906 > > I found a very similar bug (#7292), but I'm not sure if it's related. Running RE24 with valgrind --leak-check=full I see no leak when running your test. That should be the same as git c73ec15. No idea what leak you're seeing. -- -- 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

1
0
0 / 0

Re: (ITS#7299) Memory leaks when using ldapmodify to add members to groupOfNames objectclass

by jsynacek＠redhat.com

On 06/15/2012 01:52 PM, Howard Chu wrote: > jsynacek(a)redhat.com wrote: >> Full_Name: Jan Synacek >> Version: git (c73ec15) >> OS: linux-fedora17 >> URL: http://jsynacek.fedorapeople.org/openldap/leak/openldap-mmr-leak.tar.gz >> Submission from: (NULL) (209.132.186.34) >> >> >> I'm using a 2-node mmr setup on my local machine - configuration files and >> 'uploader' scripts are provided in the archive. >> >> 1) I have the two nodes running. >> 2) Execute run.sh (only a wrapper for ldapusradm.sh) and start monitoring >> slapd's memory usage. >> 3) After some time (at about 2k users on my system), slapd consumes a large >> amount of memory which is still growing >> >> Note that not using ldapmodify to add members to 'cn=users,dc=yes,dc=my', but >> using it e.g. for modifying each user's email, does NOT result in any memory >> leakage. >> >> I have also created a massif output using valgrind's massif tool: >> http://jsynacek.fedorapeople.org/openldap/leak/massif.out.17906 > > I get no permission to access this URL. > Sorry about that, should be fixed now. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

10 years, 9 months

1
0
0 / 0

Re: (ITS#7299) Memory leaks when using ldapmodify to add members to groupOfNames objectclass

by hyc＠symas.com

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: git (c73ec15) > OS: linux-fedora17 > URL: http://jsynacek.fedorapeople.org/openldap/leak/openldap-mmr-leak.tar.gz > Submission from: (NULL) (209.132.186.34) > > > I'm using a 2-node mmr setup on my local machine - configuration files and > 'uploader' scripts are provided in the archive. > > 1) I have the two nodes running. > 2) Execute run.sh (only a wrapper for ldapusradm.sh) and start monitoring > slapd's memory usage. > 3) After some time (at about 2k users on my system), slapd consumes a large > amount of memory which is still growing > > Note that not using ldapmodify to add members to 'cn=users,dc=yes,dc=my', but > using it e.g. for modifying each user's email, does NOT result in any memory > leakage. > > I have also created a massif output using valgrind's massif tool: > http://jsynacek.fedorapeople.org/openldap/leak/massif.out.17906 I get no permission to access this URL. -- -- 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

1
0
0 / 0

Re: (ITS#7310) unable to perform ldapadd for rootdb ""(empty)

by hyc＠symas.com

The ITS is for bug reports only. Usage questions should be posted to the openldap-technical mailing list. This ITS will be closed. pratima.boddepalli(a)syniverse.com wrote: > Full_Name: Pratima Boddepalli > Version: openldap-2.4.31 > OS: Red Hat Enterprise Linux Server release 5.5 (Tikanga) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (115.111.13.77) > > > Configured in slapd.conf as below: > > suffix "" > rootdn "" > > > sample.ldif file: > dn: o=sample > objectclass: organization > o: sample > > Add Command: > ldapadd -a -D "" -h localhost -p 389 -w secret -x -f sample.ldif > ldap_bind: Invalid credentials (49) > > Please help to resolve this issue where I like to add ldap entries for rootdn "" > (empty/blank) > > This is a requirement in my company's project. Kindly help as soon as possible. > > > > -- -- 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

1
0
0 / 0

(ITS#7310) unable to perform ldapadd for rootdb ""(empty)

by pratima.boddepalli＠syniverse.com

Full_Name: Pratima Boddepalli Version: openldap-2.4.31 OS: Red Hat Enterprise Linux Server release 5.5 (Tikanga) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (115.111.13.77) Configured in slapd.conf as below: suffix "" rootdn "" sample.ldif file: dn: o=sample objectclass: organization o: sample Add Command: ldapadd -a -D "" -h localhost -p 389 -w secret -x -f sample.ldif ldap_bind: Invalid credentials (49) Please help to resolve this issue where I like to add ldap entries for rootdn "" (empty/blank) This is a requirement in my company's project. Kindly help as soon as possible.

10 years, 9 months

1
0
0 / 0

Re: (ITS#7278) [PATCH] SHA-2: Add support salted SHA-2 password hashes

by fumiyas＠osstech.jp

At Wed, 13 Jun 2012 09:30:03 +0200, Michael Ströder wrote: > >>> Add -fPIC to $CCFLAGS in Makefile if you are using GCC. > >> > >> I hoped that this would not be necessary and the module work include something > >> detected via autoconf before. > > > > Can you try the following Makefile? > > > > https://gist.github.com/2915450 > Could you please submit a patch with your recent Makefile? I've filed a patch to ITS: http://www.openldap.org/its/index.cgi?findid=7309 and another one: http://www.openldap.org/its/index.cgi?findid=7308 -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/

10 years, 9 months

1
0
0 / 0

(ITS#7309) [PATCH] contrib/slapd-modules: Unify the structure and usage of Makefile

by fumiyas＠osstech.co.jp

Full_Name: SATOH Fumiyasu Version: master, 2.4.31 OS: URL: https://gist.github.com/2931594 Submission from: (NULL) (114.48.132.80) In contrib/slapd-modules, there are many Makefiles for each contrib modules, but there is no common style and usage of Makefile. E.g, some Makefile use $LDAP_SRC to specify a location of OpenLDAP source tree but others use $LDAPSRC or $OPENLDAP_SRC. I've created a patch to unify the structure and usage of Makefiles in contrib/slapd-modules.

10 years, 9 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2012