openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#5746) Guide updates
by ghenry＠OpenLDAP.org 17 Oct '08

17 Oct '08

> I think the organization of this chapter is wrong, it should not start > with > section 17.1 describing how to use syncrepl to replace slurpd before > it > describes syncrepl (section 17.2). OK. This is easily changed. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5746) Guide updates
by ghenry＠OpenLDAP.org 17 Oct '08

17 Oct '08

----- quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.12 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > In looking at the admin guide sections on replication, I notice the > following: > > (a) The syncrepl configuration suggests using the rootdn on the > consumer, which > we advise people *not* to do. > > http://www.openldap.org/doc/admin24/replication.html#Syncrepl > > "The consumer uses the rootdn to write to its database so it always > has full > permissions to write all content." > > (b) It makes no mention of using the "limits" option in slapd.conf to > bypass > sizelimit/timelimit restrictions on a non-rootdn user Eh? It says no such thing Quanah? "In this example, the consumer will connect to the provider slapd(8) at port 389 of ldap://provider.example.com to perform a polling (refreshOnly) mode of synchronization once a day. It will bind as cn=syncuser,dc=example,dc=com using simple authentication with password "secret". Note that the access control privilege of cn=syncuser,dc=example,dc=com should be set appropriately in the provider to retrieve the desired replication content. Also the search limits must be high enough on the provider to allow the syncuser to retrieve a complete copy of the requested content. The consumer uses the rootdn to write to its database so it always has full permissions to write all content." It binds to the remote db as "cn=syncuser,dc=example,dc=com", but writes to its own db as the rootdn, as per Syncrepl. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5746) Guide updates
by hyc＠symas.com 17 Oct '08

17 Oct '08

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.12 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > In looking at the admin guide sections on replication, I notice the following: > > (a) The syncrepl configuration suggests using the rootdn on the consumer, which > we advise people *not* to do. > > http://www.openldap.org/doc/admin24/replication.html#Syncrepl > > "The consumer uses the rootdn to write to its database so it always has full > permissions to write all content." The Admin Guide is correct here. We have never advised people against this. > (b) It makes no mention of using the "limits" option in slapd.conf to bypass > sizelimit/timelimit restrictions on a non-rootdn user You're confused. The above text refers to the rootdn on the consumer, not the identity the consumer uses to talk to the provider. Note that the example at the top of the page shows the appropriate limit directives. I think the organization of this chapter is wrong, it should not start with section 17.1 describing how to use syncrepl to replace slurpd before it describes syncrepl (section 17.2). -- -- 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

(ITS#5748) tavl_find3(root=NULL,,,) - and pcache? - undefined values
by h.b.furuseth＠usit.uio.no 17 Oct '08

17 Oct '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard libraries/liblutil/tavl.c:tavl_find3(NULL,,, &ret) returns an undefined value and sets ret = undefined. I don't know if that can happen; it would be if pcache.c:add_query() does: new_cached_query = find_filter( op, qbase->scopes[query->scope], query->filter, first ); with qbase->scopes[query->scope] == NULL and not a substrings filter. If nobody says anything I'll change tavl_find3(NULL,...) to return NULL and set ret = -1. I think a "no match" value fits better than 0 (match), even though there are two "no match" values (<0, >0).

1 0

(ITS#5747) collect overlay does not compile with C89
by h.b.furuseth＠usit.uio.no 17 Oct '08

17 Oct '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard overlays/collect.c:struct collect_info.ci_ad is a C99 flexible array member. Rewriting to use a C89 "struct hack" variant for C89 except gcc. That may be formally incorrect, but normally it works. The correct way would be to use offsetof() to access the struct member. Maybe later...

1 0

Re: (ITS#5744) Automatically close issues when no feedback is received within a reasonable time
by ando＠sys-net.it 17 Oct '08

17 Oct '08

quanah(a)zimbra.com wrote: >> The ITS is polluted by issues opened, considered by developers, and >> pending feedback since ever. I suggest the ITS automatically closes >> issues not fed back after a reasonable amount of time. Closed issues can >> always be re-opened if issueers wake up and respond. > > > The problem I see with this is we have a number of ITS' that are open > because the work was partially done, but there is work remaining to be > done, and that needs to be tracked. I'm not sure if "Open" is the best > state, but they definitely shouldn't be "closed" either. > > I feel what we really need is a much improved bug tracking system where we > can do things like assign target releases to bugs, keywords, and have > better-tuned states. I don't want to make the story too long. Changing the ITS system could be an option, but I don't see it as a priority. Your point about partially addressed issues could probably be fixed by: - adding a comment on what release saw what portion of the fix - adding a new "needswork" state My point is about tickets opened with only partial information, answered with a request for clarification that never comes in: 5712, 5652, 5651, ... 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

(ITS#5746) Guide updates
by quanah＠zimbra.com 17 Oct '08

17 Oct '08

Full_Name: Quanah Gibson-Mount Version: 2.4.12 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) In looking at the admin guide sections on replication, I notice the following: (a) The syncrepl configuration suggests using the rootdn on the consumer, which we advise people *not* to do. http://www.openldap.org/doc/admin24/replication.html#Syncrepl "The consumer uses the rootdn to write to its database so it always has full permissions to write all content." (b) It makes no mention of using the "limits" option in slapd.conf to bypass sizelimit/timelimit restrictions on a non-rootdn user

1 0

Re: (ITS#5744) Automatically close issues when no feedback is received within a reasonable time
by quanah＠zimbra.com 17 Oct '08

17 Oct '08

--On Thursday, October 16, 2008 12:12 PM +0000 ando(a)sys-net.it wrote: > The ITS is polluted by issues opened, considered by developers, and > pending feedback since ever. I suggest the ITS automatically closes > issues not fed back after a reasonable amount of time. Closed issues can > always be re-opened if issueers wake up and respond. The problem I see with this is we have a number of ITS' that are open because the work was partially done, but there is work remaining to be done, and that needs to be tracked. I'm not sure if "Open" is the best state, but they definitely shouldn't be "closed" either. I feel what we really need is a much improved bug tracking system where we can do things like assign target releases to bugs, keywords, and have better-tuned states. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5745) slapcat doesn't return correct error status for bdb fatal error
by Guillaume.Rousse＠inria.fr 17 Oct '08

17 Oct '08

Full_Name: Guillaume Rousse Version: 2.4.12 OS: URL: Submission from: (NULL) (193.55.250.67) [root@etoile ~]# slapcat -b dc=msr-inria,dc=inria,dc=fr ... bdb(dc=msr-inria,dc=inria,dc=fr): pthread lock failed: Invalid argument bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: Invalid argument bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: DB_RUNRECOVERY: Fatal error, run database recovery bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: fatal region error detected; run recovery bdb_db_close: database "dc=msr-inria,dc=inria,dc=fr": close failed: DB_RUNRECOVERY: Fatal error, run database recovery (-30975) [root@etoile ~]# echo $? 0 It makes a bit difficult to know if slapcat-based backup were successful.

1 0

Re: (ITS#5744) Automatically close issues when no feedback is received within a reasonable time
by ando＠sys-net.it 17 Oct '08

17 Oct '08

michael(a)stroeder.com wrote: > Although I try to keep up with testing sometimes 30 days could be a > little bit short. > > Anyway I wonder what the state "Feedback" really means. I've checked if > there are still open issues in this state submitted by me. The only one > seems to be ITS#5574, but I can't resolve this since assigning the > official OID needed in this case is not something I can do. I could only > test something and give feedback. It means some feedback is expected from the submitter. In ITS#5574 case, the most appropriate status is "suspended" (just changed). 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

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