openldap-bugs October 2008

openldap-bugs@openldap.org

36 participants
187 discussions

Re: ITS#5695
by ando＠sys-net.it 17 Oct '08

17 Oct '08

A modified version of the patch is now in HEAD code. The complete schema related to PMI has been placed in file pmi.schema; unsupported syntaxes have been added using the X-SUBST extension (ITS#5663, released with 2.4.12). Please test and report. 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#5749) client didn't send its own certificate to the server
by bugs＠shiva.hostoffice.hu 17 Oct '08

17 Oct '08

Full_Name: Gabor Mayer Version: 2.4.11 OS: debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.120.131.147) i discovered it when i turned on the peer verification at server side. i'm using the following configuration at client side: ldap.conf: BASE dc=example,dc=org URI ldaps://ldap.example.org TLS_CACERT /etc/ldap/server.crt /root/.ldaprc: TLS_CERT /etc/ldap/client.crt TLS_KEY /etc/ldap/client.key i tried TLS_CERT & TLS_KEY in ldap.conf and in .ldaprc without success. i tested it with ldapsearch -x and i got the following debug message at server if the TLSVerifyClient was turned on: TLS trace: SSL3 alert write:fatal:handshake failure TLS trace: SSL_accept:error in SSLv3 read client certificate B TLS: can't accept. TLS: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate s3_srvr.c:2455 i captured the tcp flow at client side and i saw the server's certificate only. the client didn't send its own certificate to the server!

1 0

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

17 Oct '08

----- quanah(a)zimbra.com wrote: > --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. http://www.mantisbt.org/ ? -- 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

> 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

← Newer
1
...
9
10
11
12
13
14
15
...
19
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 October 2008