openldap-bugs December 2006

openldap-bugs@openldap.org

23 participants
120 discussions

Re: (ITS#4770) monitoringslapd.sdf patch
by ando＠sys-net.it 15 Dec '06

15 Dec '06

Gavin, from the preamble, one may infer that monitoring is optional in the sense it can be optionally built. That's how it used to be; however, in 2.4, it is always enabled, but it still must be explicitly exposed in slapd.conf/slapd.d by using "database monitor". I would replace "enabled" with "exposed", and possibly explicitly indicate that in 2.4 it is no longer an option to build the monitor interface. No global directive should occur after "database monitor", as it represents a database instantiation like any other. Although most global directives wouldn't complain if appearing __after__ a database instantiation, such use should be considered at least "bad practice". About access control, it may be worth stressing that some attributes can actually be written; this requires to protect them and, at the same time, to grant the desired identities write privileges on them. Sorry I haven't time to go into too much detail. Anyway, it seems you're doing a great job. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4756) IPv6 Addresses are not supported in ACL peername
by ando＠sys-net.it 14 Dec '06

14 Dec '06

Damon.Groenveld(a)ca.com wrote: > Given that the code (in aclparse.c) calls inet_addr() with the > peername.ip parameter, I can't see how it could will work with IPv6. > > The only possible workaround is using a regex instead of ip type which > by passes the inet_addr() call. > > I raised it as a bug since the latest version (as far as I can tell) is > meant to support IPv6 and there is no way that peername.ip does and > there isn't an alternative. > This is now fixed in HEAD; please test it. Porting this feature to re23 is unlikely, though. Thanks for reporting. p.

1 0

Re: [JunkMail] Re: ITS#4510 syncrepl starttls in Admin Guide
by quanah＠stanford.edu 14 Dec '06

14 Dec '06

--On Friday, December 15, 2006 12:15 AM +0000 hyc(a)symas.com wrote: > Quanah Gibson-Mount wrote: >> >> >> --On Wednesday, December 13, 2006 2:55 AM +0000 hyc(a)symas.com wrote: >> >>> Feel free to submit a patch. This may need to be two separate patches >>> since there are several new TLS config keywords in RE24 vs RE23. >> > You might as well incorporate the ITS#4540 patch while you're at it. Done, in both slapd.conf(5) and the admin guide. >> I've made the following change to the 2.3 admin guide: > > I'd probably put starttls a little lower on the list, but no big deal. I'm going to leave it as is, as it matches slapd.conf(5). > The last two sentences are a little ambiguous to me. I would say > > If the the StartTLS request fails and the {{EX:critical}} argument was > used, the session will be aborted. Otherwise the syncrepl session > continues without TLS. Fixed in the admin guide, and slapd.conf(5), which is where I had grabbed the text from. ;) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: [JunkMail] Re: ITS#4510 syncrepl starttls in Admin Guide
by hyc＠symas.com 14 Dec '06

14 Dec '06

Quanah Gibson-Mount wrote: > > > --On Wednesday, December 13, 2006 2:55 AM +0000 hyc(a)symas.com wrote: > >> Feel free to submit a patch. This may need to be two separate patches >> since there are several new TLS config keywords in RE24 vs RE23. > You might as well incorporate the ITS#4540 patch while you're at it. > I've made the following change to the 2.3 admin guide: I'd probably put starttls a little lower on the list, but no big deal. > (OL) helpus2:/tmp/quanah/ldap-rel-eng-2-3/doc/guide/admin> cvs diff -u > slapdconf2.sdf > Index: slapdconf2.sdf > =================================================================== > RCS file: /repo/OpenLDAP/pkg/openldap-guide/admin/slapdconf2.sdf,v > retrieving revision 1.1.2.10 > diff -u -r1.1.2.10 slapdconf2.sdf > --- slapdconf2.sdf 3 Jan 2006 22:16:03 -0000 1.1.2.10 > +++ slapdconf2.sdf 15 Dec 2006 00:05:16 -0000 > @@ -609,6 +609,7 @@ > > > olcSyncrepl: rid=<replica ID> > > provider=ldap[s]://<hostname>[:port] > +> [starttls=yes|critical] > > [type=refreshOnly|refreshAndPersist] > > [interval=dd:hh:mm:ss] > > [retry=[<retry interval> <# of retries>]+] > @@ -658,6 +659,11 @@ > {{EX:replica}} directives define two independent replication > mechanisms. They do not represent the replication peers of each other. > > +The {{EX:starttls}} parameter specifies use of the StartTLS extended > +operation to establish a TLS session before Binding to the provider. If > the > +critical argument is supplied, the session will be aborted if the StartTLS > +request fails. Otherwise the syncrepl session continues without TLS. > + The last two sentences are a little ambiguous to me. I would say If the the StartTLS request fails and the {{EX:critical}} argument was used, the session will be aborted. Otherwise the syncrepl session continues without TLS. > The content of the syncrepl replica is defined using a search > specification as its result set. The consumer slapd will > send search requests to the provider slapd according to the search > > > If this is acceptable, I will commit it. > > --Quanah -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: ITS#4510 syncrepl starttls in Admin Guide
by quanah＠stanford.edu 14 Dec '06

14 Dec '06

--On Wednesday, December 13, 2006 2:55 AM +0000 hyc(a)symas.com wrote: > Feel free to submit a patch. This may need to be two separate patches > since there are several new TLS config keywords in RE24 vs RE23. I've made the following change to the 2.3 admin guide: (OL) helpus2:/tmp/quanah/ldap-rel-eng-2-3/doc/guide/admin> cvs diff -u slapdconf2.sdf Index: slapdconf2.sdf =================================================================== RCS file: /repo/OpenLDAP/pkg/openldap-guide/admin/slapdconf2.sdf,v retrieving revision 1.1.2.10 diff -u -r1.1.2.10 slapdconf2.sdf --- slapdconf2.sdf 3 Jan 2006 22:16:03 -0000 1.1.2.10 +++ slapdconf2.sdf 15 Dec 2006 00:05:16 -0000 @@ -609,6 +609,7 @@ > olcSyncrepl: rid=<replica ID> > provider=ldap[s]://<hostname>[:port] +> [starttls=yes|critical] > [type=refreshOnly|refreshAndPersist] > [interval=dd:hh:mm:ss] > [retry=[<retry interval> <# of retries>]+] @@ -658,6 +659,11 @@ {{EX:replica}} directives define two independent replication mechanisms. They do not represent the replication peers of each other. +The {{EX:starttls}} parameter specifies use of the StartTLS extended +operation to establish a TLS session before Binding to the provider. If the +critical argument is supplied, the session will be aborted if the StartTLS +request fails. Otherwise the syncrepl session continues without TLS. + The content of the syncrepl replica is defined using a search specification as its result set. The consumer slapd will send search requests to the provider slapd according to the search If this is acceptable, I will commit it. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4779) Problem using BDB replication in OpenLDAP
by Kurt＠OpenLDAP.org 14 Dec '06

14 Dec '06

This issue will be closed, see ITS#4778. At 09:57 PM 12/13/2006, seuler.shi(a)gmail.com wrote: >Full_Name: Seuler >Version: OpenLDAP:2.3.30 >OS: Fedora 5 Linux >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (194.138.202.50) > > >Problem using BDB replication in OpenLDAP >> >> Software version: >> Berkeley DB: 4.5.20 >> OpenLDAP:2.3.30 >> >> We want to configure the replication management in OpenLDAP's backend >> database. All write requests in OpenLDAP master site will spread to >> OpenLDAP client site for we have configured the backend database >> replication. >> >> We mend the source code the OpenLDAP according to the rep_mgr example >> provide by >> >> Berkeley DB. >> >> A test case is executed as follow: >> >> step 1: start openldap server site and client site; >> step 2: send write requests to the master site; >> step 3: search the master site and ensure the records are inserted in >> backend; database successfully; >> >> step 4: search the client site, but not ldap entry is displayed; >> step 5: kill the client site process and reboot it; >> step 5: search the client site right now after it reboot; >> >> Result: After step 5(reboot the client site), the search results from >> client site >> is same as the master site. >> >> At step 4: If we intend to insert an entry into the openLDAP server with >> BDB client configuration via ldapadd command, it will return "the entry >> already exists". After the failed insert operation, if search operation >> is executed, one entry will be displayed.Once a insert operation is >> tried, the number of entries in the subsequent search will increase by 1. >> >> >> >> My question: >> >> Why we can not search any info during the client is normally running? But >> once I rebooted the client site, it worked well and could accept search >> requests? How to solve this problem:)

1 0

Re: (ITS#4755) Show peer's name when syncrepl fails
by daveh＠ci.com.au 14 Dec '06

14 Dec '06

On Wed, 13 Dec 2006, Howard Chu wrote: > I don't have time to backport the changes from HEAD to RE23 myself, but > if someone submits the patch I can commit it. Seeing as I asked for it in the first place (and need it, due to our baroque setup), I guess I can. Probably won't happen before the weekend, though, but it looks straight-forward enough. -- Dave Horsfall DTM VK2KFU daveh(a)ci.com.au Ph: +61 2 9552-5509 (d) -5500 (sw) Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU

1 0

(ITS#4779) Problem using BDB replication in OpenLDAP
by seuler.shi＠gmail.com 13 Dec '06

13 Dec '06

Full_Name: Seuler Version: OpenLDAP:2.3.30 OS: Fedora 5 Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.138.202.50) Problem using BDB replication in OpenLDAP > > Software version: > Berkeley DB: 4.5.20 > OpenLDAP:2.3.30 > > We want to configure the replication management in OpenLDAP's backend > database. All write requests in OpenLDAP master site will spread to > OpenLDAP client site for we have configured the backend database > replication. > > We mend the source code the OpenLDAP according to the rep_mgr example > provide by > > Berkeley DB. > > A test case is executed as follow: > > step 1: start openldap server site and client site; > step 2: send write requests to the master site; > step 3: search the master site and ensure the records are inserted in > backend; database successfully; > > step 4: search the client site, but not ldap entry is displayed; > step 5: kill the client site process and reboot it; > step 5: search the client site right now after it reboot; > > Result: After step 5(reboot the client site), the search results from > client site > is same as the master site. > > At step 4: If we intend to insert an entry into the openLDAP server with > BDB client configuration via ldapadd command, it will return "the entry > already exists". After the failed insert operation, if search operation > is executed, one entry will be displayed.Once a insert operation is > tried, the number of entries in the subsequent search will increase by 1. > > > > My question: > > Why we can not search any info during the client is normally running? But > once I rebooted the client site, it worked well and could accept search > requests? How to solve this problem:)

1 0

Re: ITS#4545 bug in libldap
by hyc＠symas.com 13 Dec '06

13 Dec '06

hyc(a)symas.com wrote: > I tried again with chase-referrals TRUE in the slapd.3.conf, and that > seems to have been the difference. Without the patch, slapd.3.log is > 3.4GB. With the patch it's only 400MB and there are no leaked requests. > Probably I had forgotten that I'd enabled chase-referrals when I > submitted the original ITS, since they're originally disabled in this test. > Bah. The last patch was still wrong, it skips the normal cleanup for a completed request. New patch coming up. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4778) Problem using Berkeley DB replication in OpenLDAP
by Kurt＠OpenLDAP.org 13 Dec '06

13 Dec '06

Discussion of the development of OpenLDAP Software enhancements are more appropriately directed to a list about OpenLDAP Software development, e.g., openldap-devel(a)openldap.org. This issue report will be closed. Kurt At 05:52 PM 12/13/2006, seuler.shi(a)gmail.com wrote: >Full_Name: Seuler Shi >Version: 2.3.30 >OS: Fedora 5 Linux >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (194.138.202.50) > > >Problem using BDB as backend of OpenLDAP > >Software version: >Berkeley DB: 4.5.20 >OpenLDAP:2.3.30 > >We want to configure the replication management in OpenLDAP's backend database. >All write requests in OpenLDAP master site will spread to OpenLDAP client site >for we have configured the backend database replication. > >We mend the source code the OpenLDAP according to the rep_mgr example provide by > >Berkeley DB. > >A test case is executed as follow: > >step 1: start openldap server site and client site; >step 2: send write requests to the master site; >step 3: search the master site and ensure the records are inserted in backend; >database successfully; > >step 4: search the client site, but not ldap entry is displayed; >step 5: kill the client site process and reboot it; >step 5: search the client site right now after it reboot; > >Result: After step 5(reboot the client site), the search results from client >site >is same as the master site. > >At step 4: If we intend to insert an entry into the openLDAP server with BDB >client configuration via ldapadd command, it will return "the entry already >exists". After the failed insert operation, if search operation is executed, one >entry will be displayed.Once a insert operation is tried, the number of entries >in the subsequent search will increase by 1. > > > >My question: > >Why we can not search any info during the client is normally running? But once >I rebooted the client site, it worked well and could accept search requests? >How to solve this problem:)

1 0

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2006