jvcelak(a)redhat.com wrote:
> Full_Name: Jan Vcelak
> Version: 2.4.25
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/jvcelak-20110519-ldif-countlines.patch
> Submission from: (NULL) (209.132.186.34)
>
>
> Hello,
>
> adding entries to LDAP database from file using ldapadd tool causes memory
> corruption error, when the last line of the input file is not terminated by '\n'
> character.
Don't do that.
The LDIF specification says that all LDIF elements are terminated by SEP (CR
LF or LF). Anything not conforming to this is not valid LDIF. As usual,
garbage-in-garbage-out.
The entries are added correctly.
>
> All version since 2.4.23 are affected.
>
> $ cat>/tmp/input.ldif<< EOF
>> dn: cn=A,dc=my-domain,dc=com
>> objectClass: inetOrgPerson
>> objectClass: organizationalPerson
>> objectClass: person
>> objectClass: top
>> cn: A
>> sn: A
>> uid: A
>> mail: A(a)example.com
>> EOF
> $ wc -c /tmp/input.ldif
> 166 /tmp/input.ldif
> $ truncate -s 165 /tmp/input.ldif
> $ hexdump -c /tmp/input.ldif
> 0000000 d n : c n = A , d c = m y - d
> 0000010 o m a i n , d c = c o m \n o b j
> 0000020 e c t C l a s s : i n e t O r
> 0000030 g P e r s o n \n o b j e c t C l
> 0000040 a s s : o r g a n i z a t i o
> 0000050 n a l P e r s o n \n o b j e c t
> 0000060 C l a s s : p e r s o n \n o b
> 0000070 j e c t C l a s s : t o p \n c
> 0000080 n : A \n s n : A \n u i d :
> 0000090 A \n m a i l : A @ e x a m p l
> 00000a0 e . c o m
> 00000a5
> $ ldapadd -H ldap:// -D cn=Manager,dc=my-domain,dc=com -x -w password -f
> /tmp/input.ldif
> adding new entry "cn=A,dc=my-domain,dc=com"
>
> *** glibc detected *** ldapadd: free(): invalid pointer: 0x0000000001c435c8 ***
> ======= Backtrace: =========
> /lib64/libc.so.6[0x3626e76d63]
> ldapadd[0x404505]
> /lib64/libc.so.6(__libc_start_main+0xfd)[0x3626e1ee5d]
> ldapadd[0x4037e9]
> ======= Memory map: ========
> ...
>
> I am attaching proposed patch, which fixes this issue.
The patch uses a GNU-specific function. Since GLIBC is not supported on all of
the platforms OpenLDAP supports, the patch is not acceptable as-is.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
ryans(a)aweber.com wrote:
> Some more information: once I changed the search base from ou=Users,dc=example,dc=com to dc=example,dc=com to "fix" the
> problem for that particular user (after which the original query with the ou=Users,dc=example,dc=com search base began
> working again), the following entries popped up in the log:
> ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-log-fixing-br…
>
> It gets stranger, though. If I start out by using the root entry as the search base (dc=example,dc=com) with a user who
> is not yet in the cache, not only will it say it is ANSWERABLE (which it clearly isn't) and then return nothing without
> even trying to reach out to the upstream host, but if I then change the search base to ou=Users,dc=example,dc=com, I get
> the following error on the CLI (and this is with a successful bind as the directory admin):
>
>
> ldapsearch -x -D cn=admin,dc=example,dc=com -y /etc/ldap.secret -H ldaps://localhost -LLL -b cn=admin,dc=example,dc=com
> '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe4))' uid
> No such object (32)
> Matched DN: dc=example,dc=com
>
> Debugging logs generated by that query can be found here:
> ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-log-attempt-t…
I'm not sure I reproduced all the behaviors you were seeing, but I've
reproduced at least one of them and fixed it in git. Please pull the latest
pcache.c and test, thanks.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
frank.muzzulini(a)comsoft.aero wrote:
> Full_Name: Frank Muzzulini
> Version: 2.4.25
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (91.221.120.78)
>
>
> Hi,
>
> Reading the documentation of ldap_str2dn I was wondering how to free the
> allocated DN. After browsing for a while I loaded the latest tarball to see some
> example code and found ldap_dnfree.
>
> I re-checked and indeed the function is not mentioned anywhere in the docs
> ("find doc -type f | xargs grep ldap_dnfree" found nothing).
Added to git, thanks for the report.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
ArunPrasathSevugan(a)oracle.com wrote:
> Full_Name: Arun Prasath
> Version: 3
> OS: Window Xp
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (220.225.129.57)
>
>
> Hi,
>
> We have a tool integrated with LDAP to load all the users in Cognos reporting.
> There are about 5000+ users and while running LDAPCONFIG we have been getting
> out of memory exception issue.
>
> In the task manage I could see the LDAP is using memory of around 3 GB and
> finally errors out.
>
> Please help us to load the 5000+ users.
It doesn't sound like you're using OpenLDAP. We have no LDAPCONFIG to run and
we have no "Version 3" of our software. Please try contacting the actual
vendor of your LDAP software. Closing this ITS.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
yuribank(a)gmail.com wrote:
> Full_Name: Yuri Bank
> Version: 2.4.23-24
> OS: Linux Ubuntu 10.10
> URL: http://yuri.easytospell.net/consumer.provider.txt
> Submission from: (NULL) (67.180.182.165)
>
>
> This issue exists in both versions 2.4.23 and 2.4.24
>
> I've found an interesting problem with delta-sync replication in which the
> ContextCSN on my consumers is higher than the contextCSN on my provider. This is
> because the Provider does not properly update its contextCSN for its base suffix
> (dc=test,dc=com) when changes are made to group membership. Of couse, if it so
> happens that the last change in my database was not a group membership change,
> then the contextCSNs will be consistent between my consumers and provider.
Sounds like this bug was introduced by patches for ITS#6766 or #6329. Both of
those patches have been reverted for ITS#6915. This bug should be fixed in the
current git HEAD.
>
>
> I use the following command to check the ContextCSN on each consumer:
>
> Consumer: 1
> root@neteng1.oak:/etc/ldap# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b
> "dc=test,dc=com" contextCSN dn: dc=test,dc=com
> dn: dc=test,dc=com
> contextCSN: 20110313041653.752098Z#000000#000#000000
>
> Consumer: 2
> ybank@neteng1.iad:~$ ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b
> "dc=test,dc=com" contextCSN dn: dc=test,dc=com
> dn: dc=test,dc=com
> contextCSN: 20110313041653.752098Z#000000#000#000000
>
> So we can see that the two consumers have matching contextCSNs:
> ContextCSN. 20110313041653.752098Z#000000#000#000000
>
> Lets check the Provider now.
>
> Provider:
> root@neteng0.iad:~# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b
> "dc=test,dc=com" ContextCSN dn: dc=test,dc=com
> dn: dc=test,dc=com
> contextCSN: 20110313041653.709140Z#000000#000#000000
>
> The providers CSN is smaller!?
>
> Lets take a closer look and search cn=accesslog
>
> These are the last two entries: ( first the user was added, and then the user
> was added to a group)
>
> # 20110313041653.000003Z, accesslog
> dn: reqStart=20110313041653.000003Z,cn=accesslog
> objectClass: auditAdd
> reqStart: 20110313041653.000003Z
> reqEnd: 20110313041653.000004Z
> reqType: add
> reqSession: 34633
> reqAuthzID: cn=admin,dc=test,dc=com
> reqDN: cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com
> reqResult: 0
> reqMod: sn:+ Bank
> reqMod: userPassword:+ {SASL}banky
> reqMod: uid:+ banky
> reqMod: objectClass:+ top
> reqMod: objectClass:+ person
> reqMod: objectClass:+ shadowAccount
> reqMod: structuralObjectClass:+ person
> reqMod: cn:+ Bank, Yuri(banky)
> reqMod: entryUUID:+ 78a75ef6-e174-102f-9571-ffecbfef68e5
> reqMod: creatorsName:+ cn=admin,dc=test,dc=com
> reqMod: createTimestamp:+ 20110313041653Z
> reqMod: entryCSN:+ 20110313041653.709140Z#000000#000#000000
> reqMod: modifiersName:+ cn=admin,dc=test,dc=com
> reqMod: modifyTimestamp:+ 20110313041653Z
>
> # 20110313041653.000006Z, accesslog
> dn: reqStart=20110313041653.000006Z,cn=accesslog
> objectClass: auditModify
> reqStart: 20110313041653.000006Z
> reqEnd: 20110313041653.000007Z
> reqType: modify
> reqSession: 34633
> reqAuthzID: cn=admin,dc=test,dc=com
> reqDN: cn=SSLVPN,o=Groups,dc=test,dc=com
> reqResult: 0
> reqMod: member:+ cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com
> reqMod: entryCSN:= 20110313041653.752098Z#000000#000#000000
> reqMod: modifiersName:= cn=admin,dc=test,dc=com
> reqMod: modifyTimestamp:= 20110313041653Z
>
> You can see that the consumers have the latest entryCSN (20110313041653.752098Z)
> as their contextCSN, but the provider has the entryCSN (20110313041653.709140Z)
> before that as its contextCSN:
>
> If I search the contextCSN on -s base -b cn=accesslog it yields correctly, the
> same result as the consumers:
> 20110313041653.752098Z#000000#000#000000
>
>
> As you can see, the provider is not using the latest entryCSN as its ContextCSN,
> where as the consumer nodes are. Also notice that the last modification was to
> group membership. This problem only seems to exist when Adding/Removing users
> from a group.
>
> A side effect of this issue causes brand new consumers to get stuck in an
> infinite loop while syncing for the first time.
>
> A work around is to make a random change to a User/Person, such as injecting a
> random number into their description field AFTER making a change to a group
> membership. Such a change will: A. cause the Provider to correctly update its
> contextCSN, B. provider and all consumer[s] will have the same contextCSN C.
> brand new consumers can be added without getting stuck in an infinite loop when
> syncing the database. ( they seem to get stuck on the last entry which makes
> sense if the last entry has a higher entryCSN than that of the Providers
> contextCSN? )
>
> Confgiuration: ( See URL )
> http://yuri.easytospell.net/consumer.provider.txt
>
> Overlays:
> syncprov
> accesslog
> memberof
>
>
> Please feel free to email me about reproducing this problem. I have a lab with
> various configurations and would be happy to give access to anyone interested.
>
> - Yuri Bank
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
demian.djrn(a)gmail.com writes:
> all mirrors are down, i can't download the program.
The mirror list needs to be updated. These are down or obsolete:
Costa Rica: No /openldap directory.
Italy: Unknown host it.openldap.org.
Korea: No route to host ftp.holywar.net; TTL exceeded.
Portugal: Last update was in 2008.
The others work for me.
--
Hallvard
Full_Name: Demian J Ramirez
Version: -----
OS: windows 7
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (189.178.46.195)
all mirrors are down, i can't download the program.
On 06/01/2011 07:36 PM, Yuri Bank wrote:
> Do you think this could be related to:
> http://www.openldap.org/its/index.cgi?findid=6864
>
> I've been having similar issues with MemberOf and Accesslog overlays
> used together.
I've occasionally experienced similar things that you describe but
haven't captured the detailed data to be able to correlate that with
this issue.
> In your fix, is the memberof overlay enabled on your consumer nodes?
No, it is disabled everywhere.
-Kartik