openldap-bugs March 2009

openldap-bugs@openldap.org

48 participants
245 discussions

(ITS#6020) MMR sends too many redundant messages
by hyc＠OpenLDAP.org 12 Mar '09

12 Mar '09

Full_Name: Howard Chu Version: HEAD/RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Currently syncprov knows not to send a change back to the originating server, but it will still send changes back to the server that delivered it. (E.g., server 1 replicates to server 2, server 2 to server 3. Server 3 will immediately try to send the same message back to server 2.) Syncrepl isn't providing any information for syncprov to know where a change came from. The fix is for syncrepl to attach the incoming sync_cookie state to the operation it uses when writing to its own database. Coming in HEAD shortly.

1 0

Re: (ITS#6019) puzon@eska.pl
by michael＠stroeder.com 12 Mar '09

12 Mar '09

puzon(a)eska.pl wrote: > Full_Name: Lukasz Brodowski > Version: 2.4.15 > OS: freebsd 7.1 > URL: > Submission from: (NULL) (62.29.173.121) > > > Command like this: 'ldapsearch -x -D "cn=Manager,dc=example" -H > ldap://ldap.example -W' ends segmentation fault 11 (core dumped), when I send > correct password. I use this on several machines and effect is the same. Can you obtain a stack trace with gdb and the core file? See here how to obtain it: http://www.openldap.org/faq/data/cache/59.html Ciao, Michael.

1 0

Re: (ITS#5973) Syncrepl can update more than one csn value
by hyc＠symas.com 12 Mar '09

12 Mar '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: irrelevant > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > Syncrepl can update more than one csn value in one operation, False. An operation can only affect one entry. An entry has only one CSN (entryCSN is single-valued). Multiple changes may have occurred to an entry before a consumer sees it, but the consumer will only see the final result and only the last entryCSN. On the other hand, multiple CSNs may have changed in the cookie that is transmitted to the consumer. That's a separate issue... > but only one can > be passed to syncprov in the csn queue. > Syncprov should instead pick the > updated values from the modify operation. > > A patch that fixes this is coming. This patch depends on the ITS#5972 patch, > and is required for the new test058 to succeed. > > Rein Tollevik > Basefarm AS > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5973) Syncrepl can update more than one csn value
by hyc＠symas.com 12 Mar '09

12 Mar '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: irrelevant > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > Syncrepl can update more than one csn value in one operation, but only one can > be passed to syncprov in the csn queue. Syncprov should instead pick the > updated values from the modify operation. The syncrepl patch broke the CSN queue, which has caused out-of-order updates in test050. I have reverted it. Every write operation begins with a queued CSN and ends by graduating a CSN. You removed the enqueueing step, and so the queue contents were invalid. > A patch that fixes this is coming. This patch depends on the ITS#5972 patch, > and is required for the new test058 to succeed. test058 has the same number of errors with or without the syncrepl patch, so I don't think it was relevant to the issues you were addressing. I'm still skeptical about the syncprov half of the patch. The two patches were actually unrelated, the syncprov patch takes effect regardless of the syncrepl patch. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6015) ldapsearch can not retrieve same uid that has been added after it was deleted
by michael＠stroeder.com 12 Mar '09

12 Mar '09

arun_patel(a)yahoo.com wrote: > Version: 2.2.13 In general: This is a *very* ancient release. Also there's no information about the underlying Berkeley-DB and the database backend used in your setup. It's very unlikely that anybody can help you track issues down with this setup. > 6) ldapsearch -LLL -x -b uid=tesid,xyz.com > unable to retrieve the testid (Problem) > > I know the testid is in ldap, because went thru ldap browser and did see the > entry. > [..] > I then did /etc/init.d/ldap stop and /etc/init.d/ldap start > > After entering ldapsearch -LLL -x -b uid=tesid,xyz.com, it works, > > Why does this happen? Not much information about your setup. You should provide more details (e.g. database backend used, indexing and ACLs in slapd.conf). Preferrably discuss your setup on the openldap-software mailing list. Ciao, Michael.

1 0

Re: (ITS#6012) segmentation fault triggered with slapcat
by martin.konold＠erfrakon.de 12 Mar '09

12 Mar '09

Am Dienstag, 10. März 2009 06:53:34 schrieben Sie: > Please provide steps to reproduce the segfault, thanks. Hi Howard, I tried to reproduce the problem on either OpenSUSE 11.1 or Fedora but I could not reproduce the crash. The crash was reproducable with OpenPKG though I guess the crash depends on the version of bdb beeing used. The code fetches an transaction from an internal table which might have slightly different semantics with regards to initialization depending on bdb version. Anyway if you look at the rather trivial patch you will see that it indeed solves a problem independent of bdb version used so the code does not depend on a side effect anymore. On one hand the void pointer *data should not be dangeling and therefore initialization with NULL is correct. On the other hand TXN_ABORT() must not be called with potentially dangeling pointers and therefor a trivial check for the validitiy of the pointer is a good idea. Yours, --martin -- e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Sitz: Adolfstraße 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126 http://www.erfrakon.com/

1 0

(ITS#6019) puzon@eska.pl
by puzon＠eska.pl 12 Mar '09

12 Mar '09

Full_Name: Lukasz Brodowski Version: 2.4.15 OS: freebsd 7.1 URL: Submission from: (NULL) (62.29.173.121) Command like this: 'ldapsearch -x -D "cn=Manager,dc=example" -H ldap://ldap.example -W' ends segmentation fault 11 (core dumped), when I send correct password. I use this on several machines and effect is the same.

1 0

Re: (ITS#6018) TLS memory leak
by ando＠sys-net.it 12 Mar '09

12 Mar '09

timling2003(a)gmail.com wrote: > I have checked it on openldap-2.4.15. But, it still has this problem. > btw, I use cyrus-sasl-2.1.22.tar.gz for building. We cannot assume there's a bug in OpenLDAP code only because your code triggers an unexpected behavior, without seeing your code entirely. The simple fact that your code calls fairly common OpenLDAP functions that appear to behave correctly when used by other software seems to indicate that there is no issue with those functions. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6014) rev. 1.121 of clients/tools/common.c makes ldapmodify coredump
by ando＠sys-net.it 12 Mar '09

12 Mar '09

d(a)delphij.net wrote: > Here is a patch that intends to fix #6014. getpassphrase() (which in > turn would be a getpass() call, or lutil_getpass() call), returns a > pointer from a static char * pointer, which should never be free()'ed. > Therefore, a strdup() should be called. > > Note that, since both getpass() implementation could return NULL, we can > not strdup() directly. Instead, we need to detect whether it's NULL and > handle separately. Probably, a better solution would be to implement a lutil_get_terminal_password(char *prompt, struct berval *passwd) routine that mallocs as appropriate. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6015) ldapsearch can not retrieve same uid that has been added after it was deleted
by Pierangelo Masarati 12 Mar '09

12 Mar '09

Please direct software usage questions to openldap-software(a)openldap.org. Also, note that 2.2.13 is ancient. You should upgrade to 2.4.15. This ITS will be closed. p.

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2009