- openldap-bugs - openldap.org

Re: (ITS#5916) Allow alias dereferencing in search C API
by Kurt＠OpenLDAP.org 31 Jan '09

31 Jan '09

On Jan 31, 2009, at 11:21 AM, hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> ando(a)sys-net.it writes: >>>> Proxy backends use ldap_set_option(3) to set alias dereferencing >>>> when >>>> requested by a search operation (and do not clean it up >>>> afterwards, as >>>> far as I can tell). Since LDAP handlers are pooled and reused, >>>> this >>>> behavior is inherently broken. >>> I note you committed this with an ldap_int_* interface. >> >> Yes, that's because I needed it internally. > > I think ldap_pvt would make more sense. _int_ means internal to the library. _pvt_ means private to OpenLDAP Software. > I recall complaining about this deficiency in the API back in 1998, > when I > first wrote back-ldap. Alias deref has always been a part of the > protocol, but > it has always been missing from the API. Perplexing... Yes, of course, one might use the client control mechanism to add an ability to set deref on a call by call basis instead of introducing yet another function. > > >>> But it could >>> be useful outside OpenLDAP code too. >> >> Yes, that will probably be the next step. But to make it publicly >> available I should have called it ldap_search_ext2, or >> ldap_search_really_ext or something like that. I think we need to >> make >> it public based on demand and after a ballot on the name. > > Ok. > >>> Seems to me this is what client-side controls are for. Extending >>> the >>> client-side functionality without needing a new API. >> >> Well, since alias dereferencing is part of the protocol, I think >> using a >> client-side control is sort of an overkill :) > > Agreed. > > -- > -- 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#5916) Allow alias dereferencing in search C API
by hyc＠symas.com 31 Jan '09

31 Jan '09

ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> ando(a)sys-net.it writes: >>> Proxy backends use ldap_set_option(3) to set alias dereferencing when >>> requested by a search operation (and do not clean it up afterwards, as >>> far as I can tell). Since LDAP handlers are pooled and reused, this >>> behavior is inherently broken. >> I note you committed this with an ldap_int_* interface. > > Yes, that's because I needed it internally. I think ldap_pvt would make more sense. I recall complaining about this deficiency in the API back in 1998, when I first wrote back-ldap. Alias deref has always been a part of the protocol, but it has always been missing from the API. Perplexing... >> But it could >> be useful outside OpenLDAP code too. > > Yes, that will probably be the next step. But to make it publicly > available I should have called it ldap_search_ext2, or > ldap_search_really_ext or something like that. I think we need to make > it public based on demand and after a ballot on the name. Ok. >> Seems to me this is what client-side controls are for. Extending the >> client-side functionality without needing a new API. > > Well, since alias dereferencing is part of the protocol, I think using a > client-side control is sort of an overkill :) Agreed. -- -- 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#5916) Allow alias dereferencing in search C API
by ando＠sys-net.it 31 Jan '09

31 Jan '09

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> Proxy backends use ldap_set_option(3) to set alias dereferencing when >> requested by a search operation (and do not clean it up afterwards, as >> far as I can tell). Since LDAP handlers are pooled and reused, this >> behavior is inherently broken. > > I note you committed this with an ldap_int_* interface. Yes, that's because I needed it internally. > But it could > be useful outside OpenLDAP code too. Yes, that will probably be the next step. But to make it publicly available I should have called it ldap_search_ext2, or ldap_search_really_ext or something like that. I think we need to make it public based on demand and after a ballot on the name. > Seems to me this is what client-side controls are for. Extending the > client-side functionality without needing a new API. Well, since alias dereferencing is part of the protocol, I think using a client-side control is sort of an overkill :) 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

Re: (ITS#5916) Allow alias dereferencing in search C API
by h.b.furuseth＠usit.uio.no 31 Jan '09

31 Jan '09

ando(a)sys-net.it writes: > Proxy backends use ldap_set_option(3) to set alias dereferencing when > requested by a search operation (and do not clean it up afterwards, as > far as I can tell). Since LDAP handlers are pooled and reused, this > behavior is inherently broken. I note you committed this with an ldap_int_* interface. But it could be useful outside OpenLDAP code too. Seems to me this is what client-side controls are for. Extending the client-side functionality without needing a new API. -- Hallvard

1 0

(ITS#5916) Allow alias dereferencing in search C API
by ando＠sys-net.it 31 Jan '09

31 Jan '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando Proxy backends use ldap_set_option(3) to set alias dereferencing when requested by a search operation (and do not clean it up afterwards, as far as I can tell). Since LDAP handlers are pooled and reused, this behavior is inherently broken. The only reason for doing this is that the C API does not allow to explicitly define alias dereferencing when sending a search request. This is a feature request for an internal API extension (ldap_int_search*) that allows alias dereferencing. The current C API (essentially, ldap_search_ext*) should wrap the new one, until promoted to public. A patch is coming. p.

1 0

Re: (ITS#5889) [PATCH] Sending dereference field when retrying connection in meta backend
by ando＠sys-net.it 31 Jan '09

31 Jan '09

jorge.perez(a)adaptia.net wrote: > When we have two slapds with a established meta connection between them and the > connection is reset, for example by a router, the next search query will always > be send with never in dereferencing. > > Steps to reproduce: > > - Established a meta connection between 2 slapds > - Reset the connection, for example with cutter > - Send a search dereferencing with something different to never. > - See the results are no dereferenced. Actually, I was reviewing this fix, and it seems that the code for alias dereferencing is inherently broken, essentially because the (C) API for alias dereferencing is broken. In fact, back-ldap and back-meta reuse and pool connections, so setting this parameter using ldap_set_option() will actually affect all (search) operations occurring simultaneously in an unprotected manner. I think this needs to be fixed. The simplest (and my favorite) solution would be to have back-ldap and back-meta discontinue aliasing support. Another option, which I do not consider particularly viable, is to separately pool connections with different alias dereferencing strategies Finally (my second favorite option) is to add a new C API for ldap_search* operations that allows to explicitly set the alias dereferencing parameter. This API does not need to be public, since it is mostly useful inside the proxy backends. 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

Re: slapo-unique man page misleading (ITS#5908)
by ghenry＠suretecsystems.com 30 Jan '09

30 Jan '09

Ok, but we should mention this somewhere like in the admin guide perhaps. ------Original Message------ From: Quanah Gibson-Mount Sender: To: Gavin Henry To: openldap-its(a)openldap.org Subject: Re: slapo-unique man page misleading (ITS#5908) Sent: 30 Jan 2009 19:13 --On Friday, January 30, 2009 7:08 PM +0000 Gavin Henry <ghenry(a)suretecsystems.com> wrote: > Ok, so this should be in the man page. Where else should this be listed > that affects other overlays? Eh, I'm not sure it should be in the man page. The point is, if you ever want guaranteed atomic writes, you have to use slapo-accesslog to serialize them. That's an issue that affects other LDAP servers as well. AS Pierangelo said: There is no guarantee of DSA-wide or even database-wide atomicity in write operations, including internal ones. This was never even intended to be in place. This is a known design limitation not only of slapo-unique, but also of slapd (and, I'd say, of LDAP itself). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: slapo-unique man page misleading (ITS#5908)
by quanah＠zimbra.com 30 Jan '09

30 Jan '09

--On Friday, January 30, 2009 7:08 PM +0000 Gavin Henry <ghenry(a)suretecsystems.com> wrote: > Ok, so this should be in the man page. Where else should this be listed > that affects other overlays? Eh, I'm not sure it should be in the man page. The point is, if you ever want guaranteed atomic writes, you have to use slapo-accesslog to serialize them. That's an issue that affects other LDAP servers as well. AS Pierangelo said: There is no guarantee of DSA-wide or even database-wide atomicity in write operations, including internal ones. This was never even intended to be in place. This is a known design limitation not only of slapo-unique, but also of slapd (and, I'd say, of LDAP itself). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: slapo-unique man page misleading (ITS#5908)
by ghenry＠suretecsystems.com 30 Jan '09

30 Jan '09

Ok, so this should be in the man page. Where else should this be listed that affects other overlays? ------Original Message------ From: Quanah Gibson-Mount Sender: To: Gavin Henry To: openldap-its(a)openldap.org Subject: Re: slapo-unique man page misleading (ITS#5908) Sent: 30 Jan 2009 19:04 --On Thursday, January 29, 2009 3:48 PM +0000 ghenry(a)suretecsystems.com wrote: >> Huh? slapo-unique only does internal searches. The writes are all user >> ops, >> and accesslog will serialize all of them. > > So, where does this leave us? If you want guaranteed atomic writes, use slapo-accesslog on your master to serialize them. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: slapo-unique man page misleading (ITS#5908)
by quanah＠zimbra.com 30 Jan '09

30 Jan '09

--On Thursday, January 29, 2009 3:48 PM +0000 ghenry(a)suretecsystems.com wrote: >> Huh? slapo-unique only does internal searches. The writes are all user >> ops, >> and accesslog will serialize all of them. > > So, where does this leave us? If you want guaranteed atomic writes, use slapo-accesslog on your master to serialize them. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5898) test044 abort with back-ldif
by ando＠sys-net.it 30 Jan '09

30 Jan '09

Hallvard B Furuseth wrote: > Pierangelo Masarati writes: >> I don't know how useful it would be to have back-ldif directly implement >> compare, as soon as one only uses it for back-config and not for a real >> storage with stacked overlays (however I note that back-config needs at >> least to nicely interoperate with one overlay: slapo-syncprov). > > Syncprov does use compare, and back-config doesn't provide it. > I don't know if that's a problem. In any case, the fallthru compare works fine, except for those cases that require overlay manipulation of the call before actually comparing data. This is what happens to slapo-dynlist: compare gets straight to back-ldif without prior generating the dynamic listing. > I forgot, back-config doesn't fall back to back-ldif for reads. > So I guess it's just as well to leave back-ldif as it is. :) 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

Re: (ITS#5898) test044 abort with back-ldif
by h.b.furuseth＠usit.uio.no 30 Jan '09

30 Jan '09

Pierangelo Masarati writes: > I don't know how useful it would be to have back-ldif directly implement > compare, as soon as one only uses it for back-config and not for a real > storage with stacked overlays (however I note that back-config needs at > least to nicely interoperate with one overlay: slapo-syncprov). Syncprov does use compare, and back-config doesn't provide it. I don't know if that's a problem. I forgot, back-config doesn't fall back to back-ldif for reads. So I guess it's just as well to leave back-ldif as it is. -- Hallvard

1 0

Re: (ITS#5898) test044 abort with back-ldif
by ando＠sys-net.it 30 Jan '09

30 Jan '09

h.b.furuseth(a)usit.uio.no wrote: > Pierangelo Masarati writes: >> Probably related; in any case, misused in slapo-dynlist(5). Now slapd >> doesn't assert() any more. However, the test fails because back-ldif >> does not implement compare, and falls back to be_fetch(), which does not >> trigger dynlist expansion. > > Yes, the "compare without help from the backend" functionality has been > broken for years - which I presume means it's hard to fix, or needs a > different design. > > Should we patch it over by adding Compare to back-ldif and whatever else > lacks it? Or is this a "fix coming Real Soon Now" issue so it's good > to have this reminder from a backend which doesn't provide Compare? Not sure whether it's about to come sooner or later, but the issue is always about be_fetch, aka bi_entry_get_rw() whose design Is Broken (TM) (actually, it broke when overlays came into play). I don't know how useful it would be to have back-ldif directly implement compare, as soon as one only uses it for back-config and not for a real storage with stacked overlays (however I note that back-config needs at least to nicely interoperate with one overlay: slapo-syncprov). 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

Re: (ITS#5898) test044 abort with back-ldif
by h.b.furuseth＠usit.uio.no 30 Jan '09

30 Jan '09

Pierangelo Masarati writes: > Probably related; in any case, misused in slapo-dynlist(5). Now slapd > doesn't assert() any more. However, the test fails because back-ldif > does not implement compare, and falls back to be_fetch(), which does not > trigger dynlist expansion. Yes, the "compare without help from the backend" functionality has been broken for years - which I presume means it's hard to fix, or needs a different design. Should we patch it over by adding Compare to back-ldif and whatever else lacks it? Or is this a "fix coming Real Soon Now" issue so it's good to have this reminder from a backend which doesn't provide Compare? -- Hallvard

1 0

Re: (ITS#5915) Some man pages still only talk about slapd.conf
by h.b.furuseth＠usit.uio.no 30 Jan '09

30 Jan '09

hyc(a)symas.com writes: > I guess for this release (and probably for 2.5) we're just going to > have to document both, as cumbersome as that will be. When we get to > to 2.6/3.0 and drop support for slapd.conf we'll have to come back > thru again and delete the slapd.conf references from all the > docs. Unless anyone has a better idea... I'm not sure I see the problem, except that Someone(TM) must do the work... For each configuration keyword, use two headers in the manpages: Both the slapd.conf syntax and the cn=config syntax. Explain at the beginning of slapd.conf.5 or slapd-config.5. We'll be deleting most of the other one, since they are mostly duplicates. Other manpages need just one-line reminder for explanation. There'll be exceptions that spell things out too differently, or use slightly different parameters in slapd.conf and cn=config. Keep them in just slapd.conf-syntax, and add a separate cn=config attribute description below. Likely that'll only need to explain the difference. Don't go trough literary contortions to fit them both into the same description. Some of these will likely be things that could use some cleanup in the code anyway, bringing the two config formats in sync. Take a random sample of the slapd.conf-syntax example sections and replace with their cn=config equivalent. Ensure all example sections say either "slapd.conf example" or "cn=config example". slapd.conf.5 and slapd-config.5 themselves will need sections about how they work as interfaces to configuration, separate from the configuration keywords/attributes themselves. Since we are moving towards cn=config, I suppose it's that one which should keep the actual keyword/attribute descriptions. Or they could move to a third file. -- Hallvard

1 0

Re: (ITS#5898) test044 abort with back-ldif
by ando＠sys-net.it 29 Jan '09

29 Jan '09

h.b.furuseth(a)usit.uio.no wrote: >> When using the back-ldif backend with test044, it aborts: > > Probably ITS#5340. Probably related; in any case, misused in slapo-dynlist(5). Now slapd doesn't assert() any more. However, the test fails because back-ldif does not implement compare, and falls back to be_fetch(), which does not trigger dynlist expansion. 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

Re: (ITS#5913) supportedSASLMechanisms EXTERNAL not Work
by ando＠sys-net.it 29 Jan '09

29 Jan '09

jarbas.peixoto(a)gmail.com wrote: > Full_Name: Jarbas Peixoto Junior > Version: 2.4.11 > OS: Debian Lenny > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.152.43.195) > > > I have two servers: > > * Server A: Debian Etch - Works Fine > > * Server B: Debian Lenny - Do not Works supportedSASLMechanisms EXTERNAL > > In Server A I have: > > # ldapsearch -v -H ldap://server-Etch -b "" -LLL -s base supportedSASLMechanisms > -ZZ > ldap_initialize( ldap://server-Etch ) > SASL/EXTERNAL authentication started > SASL username: emailAddress=jarbas.peixoto(a)previdencia.gov.br,CN=jarbas.peixoto,OU=DATAPREV,O=Previdencia > Social,L=Campo Grande,ST=Mato Grosso do Sul,C=BR > SASL SSF: 0 > filter: (objectclass=*) > requesting: supportedSASLMechanisms > dn: > supportedSASLMechanisms: PLAIN > supportedSASLMechanisms: DIGEST-MD5 > supportedSASLMechanisms: LOGIN > supportedSASLMechanisms: NTLM > supportedSASLMechanisms: CRAM-MD5 > supportedSASLMechanisms: EXTERNAL > > In Server B I have: > > # ldapsearch -v -H ldap://server-Lenny -b "" -LLL -s base > supportedSASLMechanisms -ZZ > ldap_initialize( ldap://server-Lenny:389/??base ) > ldap_start_tls: Connect error (-11 ^^^ start TLS is failing. There is no evidence of a bug in the software; likely either the client or the server's TLS is misconfigured. Please direct software usage questions to the openldap-software list. 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

Re: (ITS#5915) Some man pages still only talk about slapd.conf
by hyc＠symas.com 29 Jan '09

29 Jan '09

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.41.236.102) > Submitted by: ghenry > > > Some discussion will be needed on the best way to talk about config. We don't > want to list everything twice for both formats...lots of slapd.conf written > throughout most (5/8) man pages. I guess for this release (and probably for 2.5) we're just going to have to document both, as cumbersome as that will be. When we get to to 2.6/3.0 and drop support for slapd.conf we'll have to come back thru again and delete the slapd.conf references from all the docs. Unless anyone has a better idea... -- -- 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#5915) Some man pages still only talk about slapd.conf
by ghenry＠OpenLDAP.org 29 Jan '09

29 Jan '09

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.41.236.102) Submitted by: ghenry Some discussion will be needed on the best way to talk about config. We don't want to list everything twice for both formats...lots of slapd.conf written throughout most (5/8) man pages. Thanks.

1 0

(ITS#5914) Update all man pages that only "SEE ALSO slapd.conf(5)" to list slapd-config(5)
by ghenry＠OpenLDAP.org 29 Jan '09

29 Jan '09

Full_Name: Gavin Henry Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.41.164.91) Submitted by: ghenry Will commit shortly.

1 0

(ITS#5913) supportedSASLMechanisms EXTERNAL not Work
by jarbas.peixoto＠gmail.com 29 Jan '09

29 Jan '09

Full_Name: Jarbas Peixoto Junior Version: 2.4.11 OS: Debian Lenny URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.152.43.195) I have two servers: * Server A: Debian Etch - Works Fine * Server B: Debian Lenny - Do not Works supportedSASLMechanisms EXTERNAL In Server A I have: # ldapsearch -v -H ldap://server-Etch -b "" -LLL -s base supportedSASLMechanisms -ZZ ldap_initialize( ldap://server-Etch ) SASL/EXTERNAL authentication started SASL username: emailAddress=jarbas.peixoto(a)previdencia.gov.br,CN=jarbas.peixoto,OU=DATAPREV,O=Previdencia Social,L=Campo Grande,ST=Mato Grosso do Sul,C=BR SASL SSF: 0 filter: (objectclass=*) requesting: supportedSASLMechanisms dn: supportedSASLMechanisms: PLAIN supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: LOGIN supportedSASLMechanisms: NTLM supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: EXTERNAL In Server B I have: # ldapsearch -v -H ldap://server-Lenny -b "" -LLL -s base supportedSASLMechanisms -ZZ ldap_initialize( ldap://server-Lenny:389/??base ) ldap_start_tls: Connect error (-11 # ldapsearch -v -H ldap://server-Lenny -b "" -LLL -s base supportedSASLMechanisms -ZZ -d 1 ldap_url_parse_ext(ldap://server-Lenny) ldap_create ldap_url_parse_ext(ldap://server-Lenny:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP server-Lenny:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.82.0.234:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x9d73280 msgid 1 wait4msg ld 0x9d73280 msgid 1 (infinite timeout) wait4msg continue ld 0x9d73280 msgid 1 all 1 ** ld 0x9d73280 Connections: * host: www-mmldap port: 389 (default) refcnt: 2 status: Connected last used: Thu Jan 29 18:17:22 2009 ** ld 0x9d73280 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x9d73280 request count 1 (abandoned 0) ** ld 0x9d73280 Response Queue: Empty ld 0x9d73280 response count 0 ldap_chkResponseList ld 0x9d73280 msgid 1 all 1 ldap_chkResponseList returns ld 0x9d73280 NULL ldap_int_select read1msg: ld 0x9d73280 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x9d73280 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x9d73280 0 new referrals read1msg: mark request completed, ld 0x9d73280 msgid 1 request done: ld 0x9d73280 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_start_tls: Connect error (-11) In the /var/log/syslog I have: Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 fd=21 ACCEPT from IP=10.82.0.234:50441 (IP=0.0.0.0:389) Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 op=0 STARTTLS Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 op=0 RESULT oid= err=0 text= Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 fd=21 closed (TLS negotiation failure) This is very important for use openldap with user certificates. Anybody have a help for me? Tanks!

1 0

Re: (ITS#5912) Meta modify increment feature
by ando＠sys-net.it 29 Jan '09

29 Jan '09

Fixed in HEAD; please test. Thanks, 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

Re: (ITS#5912) Meta modify increment feature
by ando＠sys-net.it 29 Jan '09

29 Jan '09

jorge.nevado(a)ericsson.com wrote: > Full_Name: Jorge Nevado > Version: 2.4.12 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.7) > > > We are trying to send an increment modify operation on an entry. This request > has to be proxied using the meta to a backend we have developed. When we send > the operation directly to the backend it works without any problem. But when we > have to pass through the meta backend we receive the following error: > > ldapmodify -x -H ldap://localhost:9090 -D "cn=manager,dc=operator,dc=com" -w > manager -f ldif/nam.ldif modifying entry > "appName=CsPs,subsId=10000000000000000000000000000000,ou=subscribers,dc=operator,dc=com" > ldap_modify: Server is unwilling to perform (53) > additional info: modify/increment not supported in context > > However we see that the operation has been performed and the attribute > incremented. The same problem occurs in back-ldap. The frontend is sending the error message, but it allows the operation to continue, and eventually it succeeds. I'm fixing it. 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

Re: slapo-unique man page misleading (ITS#5908)
by ghenry＠suretecsystems.com 29 Jan '09

29 Jan '09

----- hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: > > quanah(a)zimbra.com wrote: > >> --On January 28, 2009 10:39:41 PM +0000 Magne.Land(a)citrix.com > wrote: > >> > >>> Hi, > >>> Please see this thread for background info: > >>> > http://www.openldap.org/lists/openldap-software/200901/msg00112.html > >>> > >>> To me, something is either guaranteed or not. And I think > "enforce" means > >>> something that is guaranteed. In this case, the uniqueness is not > >>> guaranteed, therefore it is not enforced. > >> Set up slapo-accesslog on your master. Then uniqueness is > guaranteed. > > > > Are you sure about this? I didn't look in detail to the code, so I > > can't tell whether serializing writes that way will cause the > desired > > behavior, since slapo-unique is using internal writes. > > Huh? slapo-unique only does internal searches. The writes are all user > ops, > and accesslog will serialize all of them. So, where does this leave us? -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: (ITS#5909) stack overflow in tavl_delete (libraries/liblutil/tavl.c)?
by h.b.furuseth＠usit.uio.no 29 Jan '09

29 Jan '09

ulrich.windl(a)rz.uni-regensburg.de writes: > To make a long discussion short, you cold add a comment regarding the > use of "8". The 8 should be CHAR_BIT. /* Maximum tree depth this host's address space could support */ #define MAX_TREE_DEPTH (sizeof(void *) * CHAR_BIT) -- Hallvard

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs