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
11 years, 5 months
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.
11 years, 5 months
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
11 years, 5 months
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/
11 years, 5 months
(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.
11 years, 5 months
(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.
11 years, 5 months