openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6286) auditlog incorrectly prints end of modify operation
by masarati＠aero.polimi.it 08 Sep '09

08 Sep '09

> In auditlog overlay the same variable is used to print what command and > what > modify operations are executed, resulting in somewhat mismatched logs. Applied to HEAD, please test. Thanks, p.

1 0

Re: (ITS#6281) Duplicate entries when changing DN on newly created consumer
by masarati＠aero.polimi.it 08 Sep '09

08 Sep '09

> The problem was mine, no syncrepl. I usually start the client with a > fresh/recent dump from the master, but neglected to dump the extended > attrs along with the regular ones. That resulted in "slapadd" creating > new entryUUID/etc attrs on the consumer, which then would not match > the master. > > If a warning would be useful, then perhaps "slapadd" could warn on > importing an LDIF without entryUUIDs, but it's not a bug in this case. > > An alternate to reduce "operator error" might be to compare a master > UUID on the first sync and notify of a mismatch, which could also help > prevent accidentally trying to sync from the wrong master. Please keep replies to the ITS. OK, I understand. In this case, slapadd(8) needs to be able to load a LDIF without operational attrs and create them accordingly. Still, there's room for warning in that case if slapadd(8) is done for a database configured to use syncrepl. p.

1 0

(ITS#6286) auditlog incorrectly prints end of modify operation
by baggins＠sith.mimuw.edu.pl 07 Sep '09

07 Sep '09

Full_Name: Jan Rekorajski Version: 2.4.17 OS: Linux PLD URL: http://sith.mimuw.edu.pl/~baggins/openldap/openldap-auditlog-modify.patch Submission from: (NULL) (2001:6a0:1:b001::2) In auditlog overlay the same variable is used to print what command and what modify operations are executed, resulting in somewhat mismatched logs. Example: # modify 1252272953 dn: dc=example,dc=com changetype: modify replace: contextCSN contextCSN: 20090828130628.442551Z#000000#001#000000 - # end replace 1252272953 ^^^^^^^^^^^^^^^^^ should read: # end modify 1252272953 I provided a patch to fix this at http://sith.mimuw.edu.pl/~baggins/openldap/openldap-auditlog-modify.patch

1 0

ITS#6285
by masarati＠aero.polimi.it 06 Sep '09

06 Sep '09

Please direct software interoperation questions to <openldap-technical(a)openldap.org>. This ITS will be closed. p.

1 0

Re: (ITS#6284) New libtoolized autogroup Makefile broken
by hyc＠symas.com 06 Sep '09

06 Sep '09

ryans(a)aweber.com wrote: > Upon further review, it seems that the problem is $LIBTOOL not being defined. Should automake be setting this in > configure.in or Makefile.in ahead of time, The OpenLDAP Project does not use automake. > or is it up to each individual module to set the environment variables needed > for compiling/linking? -- -- 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#6282) Assertion failure in openldap clients when server is frozen and limits are in place
by masarati＠aero.polimi.it 05 Sep '09

05 Sep '09

>> I think hitting an assert is always a bug, while exit(nonzero) is fine. >> Looks like a small fix anyway, if that's all there is to it. >> >> A quick grep found that back-ldap and back-meta also try to use the >> result message from ldap_result()==0. > > Unless I missed something, all times back-ldap and back-meta ignore > ldap_result()==0 it's because no timeout was specified. Actually, syncrepl is already requesting that objectClass, structuralObjectClass and entryCSN be present in the attrslist. I wonder whether entryUUID should be added. p.

1 0

Re: (ITS#6281) Duplicate entries when changing DN on newly created consumer
by masarati＠aero.polimi.it 05 Sep '09

05 Sep '09

> UPDATE: this appears to be a case of user-error > > the ldapsearch was not pulling the entryUUID because of a malformed search > line. > The required syntax for the "attrs" (last part of line) should have been > '*' '+' > when making a dump. Omitting the '+' caused LDAP to regenerate the > entryUUIDs on the consumer, which would then subsequently mess up > syncing operations Perhaps slapd should at least warn when syncrepl is configured in a way that entryUUID and entryCSN are not replicated. p.

1 0

Re: (ITS#6282) Assertion failure in openldap clients when server is frozen and limits are in place
by masarati＠aero.polimi.it 05 Sep '09

05 Sep '09

> I think hitting an assert is always a bug, while exit(nonzero) is fine. > Looks like a small fix anyway, if that's all there is to it. > > A quick grep found that back-ldap and back-meta also try to use the > result message from ldap_result()==0. Unless I missed something, all times back-ldap and back-meta ignore ldap_result()==0 it's because no timeout was specified. p.

1 0

Re: (ITS#6284) New libtoolized autogroup Makefile broken
by quanah＠zimbra.com 05 Sep '09

05 Sep '09

--On Friday, September 04, 2009 7:15 PM +0000 ryans(a)aweber.com wrote: > Upon further review, it seems that the problem is $LIBTOOL not being > defined. Should automake be setting this in configure.in or Makefile.in > ahead of time, or is it up to each individual module to set the > environment variables needed for compiling/linking? For contrib modules, the variables must be defined by the user doing the compiling. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6284) New libtoolized autogroup Makefile broken
by ryans＠aweber.com 04 Sep '09

04 Sep '09

Upon further review, it seems that the problem is $LIBTOOL not being defined. Should automake be setting this in configure.in or Makefile.in ahead of time, or is it up to each individual module to set the environment variables needed for compiling/linking? -Ryan

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs