openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#5895) Example in constraint manual and documentation
by ghenry＠suretecsystems.com 21 Jan '09

21 Jan '09

----- ando(a)sys-net.it wrote: > Gavin Henry wrote: > > Sorry, I presume this was a bug in the code and the docs document > the > > right behaviour? > > > > I'll revert them when you've confirmed. > > As far as I remember, the bug was in the example in > slapo-constraint(5) > man page ("[:digit:]" indicates the collection of values ":", "d", > "i", > ..., while "[[:digit:]]" indicates "0"->"9"). The man page is correct > OK, it was actually this bit: constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$ and in HEAD it still only had one set of []. Both the admin guide and man page have been updated for this in my last commit. Thanks. -- 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#5889) [PATCH] Sending dereference field when retrying connection in meta backend
by ando＠sys-net.it 21 Jan '09

21 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. > > Patch attached. Thanks, fixed (with minor modifications). 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#5897) trailing characters in olcserverids after conversion
by oliver＠itc.li 21 Jan '09

21 Jan '09

Howard Chu schrieb: > oliver(a)itc.li wrote: >> Full_Name: Oliver Liebel >> Version: 2.4.13 >> OS: opensuse 11 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (80.144.97.81) >> >> >> using openldap 2.4.13 (compiled from openldap.org source-package) >> i have noticed the following, reproducable behaviour when converting >> a slapd.conf to slapd.d: >> >> if slapd.conf contains serverids with ldap-urls, e.g. in this format: >> >> ServerID 1 "ldap://ldapmaster.local.site:9000" >> ServerID 2 "ldap://ldapslave.local.site:9000" >> >> the olcserverids in cn=config.ldif always contains some trailing >> (garbage) >> characters after the conversion, and are base64 encoded. when i set >> them >> manually in cn=config with ldapmodify, they are displayed "clean". >> >> the serverid-lines in slapd.conf are "clean" (they contain no >> whitespaces / tabs >> at the end of the line or similar, invisible characters). >> >> i have tested it several times, without using \"\ in the string >> and/or without >> portnumber. i have tested the conversion with both slaptest and slapd, >> in virtual and real machines, >> result was always the same. > > Thanks for the report, this is now fixed in HEAD. Note, URLs don't > need to be surrounded with quotes. By definition, they are already > "safe". okay, understood. thanks for your response. greetings oliver

1 0

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

21 Jan '09

> When using the back-ldif backend with test044, it aborts: Probably ITS#5340. -- Hallvard

1 0

(ITS#5898) test044 abort with back-ldif
by quanah＠OpenLDAP.org 20 Jan '09

20 Jan '09

Full_Name: Quanah Gibson-Mount Version: HEAD OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) When using the back-ldif backend with test044, it aborts: Program terminated with signal 6, Aborted. (gdb) bt #0 0x000000395e030155 in raise () from /lib64/libc.so.6 #1 0x000000395e031bf0 in abort () from /lib64/libc.so.6 #2 0x000000395e0295d6 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000438a3b in entry2str (e=0x1e88, len=0x438a49) at entry.c:452 #4 0x0000000004fe9748 in ?? () #5 0x0000000000000000 in ?? () (gdb) frame 3 #3 0x0000000000438a3b in entry2str (e=0x1e88, len=0x438a49) at entry.c:452 452 tmplen = e->e_name.bv_len; (gdb) l 447 ecur = ebuf; 448 449 /* put the dn */ 450 if ( e->e_dn != NULL ) { 451 /* put "dn: <dn>" */ 452 tmplen = e->e_name.bv_len; 453 MAKE_SPACE( LDIF_SIZE_NEEDED( 2, tmplen )); 454 ldif_sput( &ecur, LDIF_PUT_VALUE, "dn", e->e_dn, tmplen ); 455 } 456

1 0

Re: (ITS#5896) search error on ldap_search_ext_s
by hyc＠symas.com 20 Jan '09

20 Jan '09

eduard.budulea(a)axigen.com wrote: > Full_Name: Eduard Budulea > Version: 2.4.11 > OS: gnu/linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.230.245.6) > > > ldap_search_ext_s does not return all the messages that the server sends. > If the response from the ldap server is compose from 2 messages: > - a LDAP Intermediate Response Message > - a SearchResultDone Message > > the ldap_search_ext_s returns only the intermediate one. > > Step to reporduce: > have a ldap running with some entries. > have a the syncprov overlay deploy. > make a synchronous search with a null cookie and a filter that does not match > all the entries. > now modify an entry that is not in the previous result set. > make another synchronous search with the cookie from the previous search. > you will be able to see only the intermediate and not the done (that holds the > cookie). > > If you do the same but using ldap_search_ext and ldap_result you will get the > result done message also. This behavior is by design, and has been in place since 2000. Whether the design is correct or not may be an open question; since Kurt wrote that code I'd ask him to comment further. -- -- 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#5897) trailing characters in olcserverids after conversion
by hyc＠symas.com 20 Jan '09

20 Jan '09

oliver(a)itc.li wrote: > Full_Name: Oliver Liebel > Version: 2.4.13 > OS: opensuse 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.144.97.81) > > > using openldap 2.4.13 (compiled from openldap.org source-package) > i have noticed the following, reproducable behaviour when converting > a slapd.conf to slapd.d: > > if slapd.conf contains serverids with ldap-urls, e.g. in this format: > > ServerID 1 "ldap://ldapmaster.local.site:9000" > ServerID 2 "ldap://ldapslave.local.site:9000" > > the olcserverids in cn=config.ldif always contains some trailing (garbage) > characters after the conversion, and are base64 encoded. when i set them > manually in cn=config with ldapmodify, they are displayed "clean". > > the serverid-lines in slapd.conf are "clean" (they contain no whitespaces / tabs > at the end of the line or similar, invisible characters). > > i have tested it several times, without using \"\ in the string and/or without > portnumber. i have tested the conversion with both slaptest and slapd, > in virtual and real machines, > result was always the same. Thanks for the report, this is now fixed in HEAD. Note, URLs don't need to be surrounded with quotes. By definition, they are already "safe". -- -- 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#5897) trailing characters in olcserverids after conversion
by quanah＠zimbra.com 20 Jan '09

20 Jan '09

--On Monday, January 19, 2009 5:41 PM +0000 oliver(a)itc.li wrote: > Full_Name: Oliver Liebel > Version: 2.4.13 > OS: opensuse 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.144.97.81) > > > using openldap 2.4.13 (compiled from openldap.org source-package) > i have noticed the following, reproducable behaviour when converting > a slapd.conf to slapd.d: > i have tested it several times, without using \"\ in the string and/or > without portnumber. i have tested the conversion with both slaptest and > slapd, in virtual and real machines, > result was always the same. Can you test with current CVS of HEAD? back-ldif has been largely reworked. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5895) Example in constraint manual and documentation
by ando＠sys-net.it 20 Jan '09

20 Jan '09

Gavin Henry wrote: > Sorry, I presume this was a bug in the code and the docs document the > right behaviour? > > I'll revert them when you've confirmed. As far as I remember, the bug was in the example in slapo-constraint(5) man page ("[:digit:]" indicates the collection of values ":", "d", "i", ..., while "[[:digit:]]" indicates "0"->"9"). The man page is correct in HEAD, but the correction is not in re24. The code has always been correct with respect to this issue both in HEAD and re24. 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#5894) test039 fails: ldap_back_conn_delete: Assertion
by quanah＠zimbra.com 20 Jan '09

20 Jan '09

--On Saturday, January 17, 2009 3:25 PM +0000 michael(a)stroeder.com wrote: > Howard Chu wrote: >> michael(a)stroeder.com wrote: >>> Full_Name: Michael Str?der >>> Version: HEAD >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (84.163.100.169) >>> >>> >>> lt-slapd: bind.c:157: ldap_back_conn_delete: Assertion >>> `!(*(&((lc))->lc_lcflags) >>> & (((0x00000020U))))' failed. >> >> I'm not seeing that here. Ran into a couple other problems though, fixed >> now in HEAD. Please re-test... > > Now test008 hangs... Multiple runs of test008 work for me, using BDB 4.7.25 with all 3 patches, and HEAD CVS as of 1/20/2009 @ 12:00 PST. Did you fully rebuild OpenLDAP after the latest commits? What version of BDB are you using? Is it fully patched? What backend was it using when it hung? Did you get a backtrace of where it hung? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

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