openldap-bugs November 2007

openldap-bugs@openldap.org

44 participants
170 discussions

Re: ITS#5240
by quanah＠zimbra.com 25 Nov '07

25 Nov '07

--On November 26, 2007 3:53:34 AM +0000 hyc(a)symas.com wrote: > I don't know what timestamp you're looking at, but according to CVS > init.c still has not been sync'd. (11/18/2007) > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-bdb/init.c?hi > deattic=1&sortbydate=0 > > You should not be making blind commits into the Release Engineering > branches. It's your job to verify that the commits are correct. back-bdb > is broken in RE24 right now. I wasn't making blind commits, I've been making commits in the same sequence as they come into the commit list, after confirming with you. In any case, I think I must have been looking at your commit to fix back-bdb/init.c, because I was seeing 0 difference between HEAD/2.4 when looking prior to writing my mail, and missed that it had been your commit. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: ITS#5240
by hyc＠symas.com 25 Nov '07

25 Nov '07

quanah(a)zimbra.com wrote: > --On November 22, 2007 5:11:30 PM +0000 ando(a)sys-net.it wrote: > >> A fix for ITS#5183 has been partially imported into re24 (back-bdb.h; >> init.c not yet). I don't know if it was intended, or if the merging is >> just in progress. > > init.c was sync'd prior to this ITS even being filed, unless its a > timestamp issue somewhere (11/21/2007). back-bdb.h was sync'd except for > the ifdef LDAP_DEVEL, which shouldn't have had an effect since > BDB_MONITOR_IDX was already defined. If things still aren't working with > 2.4, then something else is the matter. I don't know what timestamp you're looking at, but according to CVS init.c still has not been sync'd. (11/18/2007) http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-bdb/init.c?hide… You should not be making blind commits into the Release Engineering branches. It's your job to verify that the commits are correct. back-bdb is broken in RE24 right now. -- -- Howard Chu Chief Architect, 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#5240
by quanah＠zimbra.com 25 Nov '07

25 Nov '07

--On November 22, 2007 5:11:30 PM +0000 ando(a)sys-net.it wrote: > A fix for ITS#5183 has been partially imported into re24 (back-bdb.h; > init.c not yet). I don't know if it was intended, or if the merging is > just in progress. init.c was sync'd prior to this ITS even being filed, unless its a timestamp issue somewhere (11/21/2007). back-bdb.h was sync'd except for the ifdef LDAP_DEVEL, which shouldn't have had an effect since BDB_MONITOR_IDX was already defined. If things still aren't working with 2.4, then something else is the matter. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5245) auditlog man page and feature request
by hyc＠symas.com 25 Nov '07

25 Nov '07

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: 2.4.6 > OS: F8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > > Note to self about man page missing any cn=config examples, for example: > > dn: cn=module{0},cn=config > changetype: modify > add: olcModuleLoad > olcModuleLoad: {2}auditlog.la > > dn: olcOverlay=auditlog,olcDatabase={1}hdb,cn=config > changetype: add > objectClass: olcOverlayConfig > objectClass: olcAuditLogConfig > olcOverlay: auditlog > > dn: olcOverlay={0}auditlog,olcDatabase={1}hdb,cn=config > changetype: modify > add: olcAuditlogFile > olcAuditlogFile: /tmp/auditlog.ldif > The above is a poor example, you should set all the relevant attributes when the object is created. Doing a subsequent modify is a waste. > Nothing noting the format of olcAuditlogFile, i.e. /tmp or file:///tmp The doc says it's a fully qualified path. That means it is not a URL. This point is superfluous. > Feature request: > > New config setting to define mode. At the moment it's 0644 > > Thanks. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5245) auditlog man page and feature request
by ghenry＠OpenLDAP.org 25 Nov '07

25 Nov '07

Full_Name: Gavin Henry Version: 2.4.6 OS: F8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Note to self about man page missing any cn=config examples, for example: dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: {2}auditlog.la dn: olcOverlay=auditlog,olcDatabase={1}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcAuditLogConfig olcOverlay: auditlog dn: olcOverlay={0}auditlog,olcDatabase={1}hdb,cn=config changetype: modify add: olcAuditlogFile olcAuditlogFile: /tmp/auditlog.ldif Nothing noting the format of olcAuditlogFile, i.e. /tmp or file:///tmp Feature request: New config setting to define mode. At the moment it's 0644 Thanks.

1 0

(ITS#5244) Problem configuring openldap 2.4.6
by pierre42d＠9online.fr 25 Nov '07

25 Nov '07

Full_Name: Pierre Version: 2.4.6 OS: GNU/Linux URL: Submission from: (NULL) (82.224.217.20) [...] checking number of arguments of ctime_r... 2 checking number of arguments of gethostbyname_r... 6 checking number of arguments of gethostbyaddr_r... 8 checking db.h usability... no checking db.h presence... no checking for db.h... no configure: error: BDB/HDB: BerkeleyDB not available I have Berkeley DB 4.6.21 installed

1 0

Re: ITS#5243
by ando＠sys-net.it 23 Nov '07

23 Nov '07

hyc(a)symas.com wrote: >> There have been at least 10 syncrepl-related fixes in 2.3 since 2.3.32, >> with substantial bug fixes and improvements. Please update and check if >> the issue has been already fixed. > > This works as designed. The identity that the syncrepl consumer uses to > retrieve results must have sufficient privilege to retrieve a complete set of > results. Right, I probably misunderstood the question. If it was related to the "sizelimit" option of the "syncrepl" statement, as far as I understand, that parameter sets the amount of data the consumer is willing to replicate, in case one wants to set up a partial replica. It must be set to "unlimited" (i.e. no "sizelimit" used) to replicate as much as possible of the producer. In the latter case, the amount of data a consumer can get depends on the size limit the producer is willing to return. For this purpose, the identity used by the consumer must have no size limits to work correctly. A "limits" statement that sets the size limit to "unlimited" for a "who" clause that includes the consumer's replication identity should be used. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: ITS#5243
by hyc＠symas.com 23 Nov '07

23 Nov '07

ando(a)sys-net.it wrote: > There have been at least 10 syncrepl-related fixes in 2.3 since 2.3.32, > with substantial bug fixes and improvements. Please update and check if > the issue has been already fixed. This works as designed. The identity that the syncrepl consumer uses to retrieve results must have sufficient privilege to retrieve a complete set of results. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ITS#5243
by ando＠sys-net.it 23 Nov '07

23 Nov '07

There have been at least 10 syncrepl-related fixes in 2.3 since 2.3.32, with substantial bug fixes and improvements. Please update and check if the issue has been already fixed. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

ITS#5242
by ando＠sys-net.it 23 Nov '07

23 Nov '07

There's a difference between the two: "sizelimit" is DSA-wide; "limits" are per-database and per "who" clause. This is reflected in the man page by the respective location of the statements in the "GLOBAL CONFIGURATION OPTIONS" and in the "GENERAL DATABASE OPTIONS". Of course, if "sizelimit" overrides a "limits" for a client identity matching the "who" clause of that "limits" on a search spanning the database the "limits" was defined for, then it's a bug. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2007