openldap-bugs November 2011

openldap-bugs@openldap.org

22 participants
92 discussions

Re: (ITS#7081) test020-proxycache failed for bdb
by hyc＠symas.com 04 Nov '11

04 Nov '11

michael(a)stroeder.com wrote: > Full_Name: > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.128.242.48) > > > Seems there's a regression in HEAD's slapo-pcache possibly due to the recent > commits. Thanks for the report, fixed in master. > >>>>>> Starting test020-proxycache for bdb... > Starting master slapd on TCP/IP port 9011... > Using ldapsearch to check that master slapd is running... > Using ldapadd to populate the master directory... > Starting proxy cache on TCP/IP port 9012... > Using ldapsearch to check that proxy slapd is running... > Making queries on the proxy cache... > Query 1: filter:(sn=Jon) attrs:all (expect nothing) > Query 2: filter:(|(cn=*Jon*)(sn=Jon*)) attrs:cn sn title uid > Query 3: filter:(sn=Smith*) attrs:cn sn uid > Query 4: filter:(sn=Doe*) attrs:cn sn title uid > Query 5: filter:(uid=johnd) attrs:mail postaladdress telephonenumber cn uid > Query 6: filter:(mail=*@mail.alumni.example.com) attrs:cn sn title uid > Query 7: filter:(mail=*) attrs:cn sn title uid > Query 8: filter:(mail=*example.com) attrs:cn sn title uid > ldapsearch failed (4) > Query 9: filter:(uid=b*) attrs:mail > ldapsearch failed (4) > Query 10: filter:(|(cn=All Staff)(sn=All Staff)) attrs:sn cn title uid > undefinedAttr > Query 1 not cacheable > Query 2 cacheable > Query 3 cacheable > Query 4 cacheable > Query 5 cacheable > Query 6 cacheable > Query 7 not cacheable > Query 8 cacheable > Query 9 cacheable > Query 10 cacheable > Successfully verified cacheability > Query 11: filter:(|(cn=*Jones)(sn=Jones)) attrs:cn sn title uid > Query 12: filter:(sn=Smith) attrs:cn sn title uid > Query 13: filter:(uid=bjorn) attrs:mail postaladdress telephonenumber cn uid > Query 14: filter:(mail=jaj@mail.alumni.example.com) attrs:cn sn title uid > Query 15: filter:(mail=*example.com) attrs:cn sn title uid > ldapsearch failed (4) > Query 16: filter:(uid=b*) attrs:mail > ldapsearch should have failed! >>>>>> test020-proxycache failed for bdb > (exit 1) > make[2]: *** [bdb-mod] Error 1 > make[2]: Leaving directory `/usr/src/michael/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/tests' > make: *** [test] Error 2 > m > > -- -- 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#7081) test020-proxycache failed for bdb
by michael＠stroeder.com 04 Nov '11

04 Nov '11

Full_Name: Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.128.242.48) Seems there's a regression in HEAD's slapo-pcache possibly due to the recent commits. >>>>> Starting test020-proxycache for bdb... Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to populate the master directory... Starting proxy cache on TCP/IP port 9012... Using ldapsearch to check that proxy slapd is running... Making queries on the proxy cache... Query 1: filter:(sn=Jon) attrs:all (expect nothing) Query 2: filter:(|(cn=*Jon*)(sn=Jon*)) attrs:cn sn title uid Query 3: filter:(sn=Smith*) attrs:cn sn uid Query 4: filter:(sn=Doe*) attrs:cn sn title uid Query 5: filter:(uid=johnd) attrs:mail postaladdress telephonenumber cn uid Query 6: filter:(mail=*@mail.alumni.example.com) attrs:cn sn title uid Query 7: filter:(mail=*) attrs:cn sn title uid Query 8: filter:(mail=*example.com) attrs:cn sn title uid ldapsearch failed (4) Query 9: filter:(uid=b*) attrs:mail ldapsearch failed (4) Query 10: filter:(|(cn=All Staff)(sn=All Staff)) attrs:sn cn title uid undefinedAttr Query 1 not cacheable Query 2 cacheable Query 3 cacheable Query 4 cacheable Query 5 cacheable Query 6 cacheable Query 7 not cacheable Query 8 cacheable Query 9 cacheable Query 10 cacheable Successfully verified cacheability Query 11: filter:(|(cn=*Jones)(sn=Jones)) attrs:cn sn title uid Query 12: filter:(sn=Smith) attrs:cn sn title uid Query 13: filter:(uid=bjorn) attrs:mail postaladdress telephonenumber cn uid Query 14: filter:(mail=jaj@mail.alumni.example.com) attrs:cn sn title uid Query 15: filter:(mail=*example.com) attrs:cn sn title uid ldapsearch failed (4) Query 16: filter:(uid=b*) attrs:mail ldapsearch should have failed! >>>>> test020-proxycache failed for bdb (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/tests' make: *** [test] Error 2 m

1 0

(ITS#7080) post read control in back-config
by michael＠stroeder.com 03 Nov '11

03 Nov '11

Full_Name: Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.60.140) back-config should support the post read control so that applications can determine the possibly renumbered DN after adding/modifying an entry

1 0

(ITS#7079) back-mdb
by hyc＠OpenLDAP.org 03 Nov '11

03 Nov '11

Full_Name: Howard Chu Version: HEAD/RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc back-mdb is working well in master, should be added to RE24 and marked Experimental.

1 0

(ITS#7078) slapadd should be pipelined
by hyc＠OpenLDAP.org 03 Nov '11

03 Nov '11

Full_Name: Howard Chu Version: HEAD/RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc When using slapadd -q and tool-threads is > 1, slapadd should use a separate thread for reading/parsing the input LDIF, to allow it to run concurrently with the backend add operation. Already implemented in master.

1 0

(ITS#7077) olcMirrorMode implicit change not seen in cn=config
by christopher_wood＠pobox.com 03 Nov '11

03 Nov '11

Full_Name: Christopher Wood Version: 2.4.26 OS: Debian 6 (Squeeze) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (173.206.227.67) Quoth Howard Chu: "There's a bit of a glitch here; when you modify the olcSyncrepl attribute, it is internally a delete followed by an add. When the delete occurs, the olcMirrorMode flag is implicitly turned off. (Because it is only allowed to be On for a database that is being replicated.) When the add occurs, the flag is not automatically turned back on. "The solution is to set it explicitly in your LDAPModify request." http://www.openldap.org/lists/openldap-technical/201109/msg00010.html The issue is that when this implicit flag toggle happens, the directory still reports that olcMirrorMode is TRUE. Assuming starting with a working MMR pair, this reproduces the issue: $ ldapmodify -x -w password -D 'cn=config' -h ldapmm1 dn: olcDatabase={0}config,cn=config changetype: modify replace: olcRootPW olcRootPW: password2 - replace: olcSyncrepl olcSyncrepl: rid=1 provider=ldap://ldapmm1 binddn="cn=config" bindmethod=simple credentials=password2 searchbase="cn=config" type=refreshAndPersist retry="5 5 30 +" timeout=5 olcSyncrepl: rid=2 provider=ldap://ldapmm2 binddn="cn=config" bindmethod=simple credentials=password2 searchbase="cn=config" type=refreshAndPersist retry="5 5 30 +" timeout=5 modifying entry "olcDatabase={0}config,cn=config" dn: olcDatabase={0}config,cn=config changetype: modify replace: olcRootPW olcRootPW: password3 modifying entry "olcDatabase={0}config,cn=config" ldap_modify: Server is unwilling to perform (53) additional info: shadow context; no update referral $ ldapsearch -x -w password2 -D 'cn=config' -b 'olcDatabase={0}config,cn=config' -s base -h ldapmm1 '' 'olcMirrorMode' # extended LDIF # # LDAPv3 # base <olcDatabase={0}config,cn=config> with scope baseObject # filter: (objectclass=*) # requesting: olcMirrorMode # # {0}config, config dn: olcDatabase={0}config,cn=config olcMirrorMode: TRUE # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1

1 0

Re: (ITS#6981) slapd crashes when using sssvlv and pcache overlays
by hyc＠symas.com 02 Nov '11

02 Nov '11

h.b.furuseth(a)usit.uio.no wrote: > Though the original case is now fixed in master, this simpler test > case crashes in the same way. It forces REP_ENTRY_MUSTRELEASE to be > set, since the current fix is to restore OpenLDAP 2.4.23's behavior of > not flushing the entry otherwise. But 2.4.23 also crashes with this: > > $ cat<<EOF>its6981.conf > include servers/slapd/schema/core.schema > database bdb > suffix o=test > rootdn o=test > directory its6981/a > > overlay pcache > pcache bdb 10000 1 50 100 > pcacheAttrset 0 * + > pcacheTemplate (objectClass=) 0 60 > pcacheTemplate (o=) 0 60 > pcache-directory its6981/b > EOF > > $ mkdir -p its6981/a its6981/b; rm -f its6981/?/* > $ servers/slapd/slapd -Tadd -f its6981.conf<<EOF > dn: o=test > objectclass: organization > o: test > EOF > > $ servers/slapd/slapd -f its6981.conf -d0 -h ldap://localhost:3890/& > $ clients/tools/ldapsearch -LLLxh localhost:3890 -b o=test '(o=test)' > > > It doesn't seem to make sense for code to assume sr_entry persists > past the point it'd be flushed if REP_ENTRY_MUSTRELEASE is set. > That's why this change snuck into ITS#6758 (SlapyReply usage). > Probably we should put the flush back someday - after checking better > than I did last time. > OK, the flush is back to where it was in 2.4.26. pcache.c has been reorganized again, taking ITS#5112 into account. REP_RESULT handling is still in pcache_op_cleanup (as #5112 requires) but REP_SEARCH is back in op_response (where it used to be, before the #5112 patch). -- -- 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#6981) slapd crashes when using sssvlv and pcache overlays
by h.b.furuseth＠usit.uio.no 02 Nov '11

02 Nov '11

Though the original case is now fixed in master, this simpler test case crashes in the same way. It forces REP_ENTRY_MUSTRELEASE to be set, since the current fix is to restore OpenLDAP 2.4.23's behavior of not flushing the entry otherwise. But 2.4.23 also crashes with this: $ cat <<EOF >its6981.conf include servers/slapd/schema/core.schema database bdb suffix o=test rootdn o=test directory its6981/a overlay pcache pcache bdb 10000 1 50 100 pcacheAttrset 0 * + pcacheTemplate (objectClass=) 0 60 pcacheTemplate (o=) 0 60 pcache-directory its6981/b EOF $ mkdir -p its6981/a its6981/b; rm -f its6981/?/* $ servers/slapd/slapd -Tadd -f its6981.conf <<EOF dn: o=test objectclass: organization o: test EOF $ servers/slapd/slapd -f its6981.conf -d0 -h ldap://localhost:3890/ & $ clients/tools/ldapsearch -LLLxh localhost:3890 -b o=test '(o=test)' It doesn't seem to make sense for code to assume sr_entry persists past the point it'd be flushed if REP_ENTRY_MUSTRELEASE is set. That's why this change snuck into ITS#6758 (SlapyReply usage). Probably we should put the flush back someday - after checking better than I did last time. -- Hallvard

1 0

(ITS#7076) Duplicate result messages on entry/searchref error
by h.b.furuseth＠usit.uio.no 01 Nov '11

01 Nov '11

Full_Name: Hallvard B Furuseth Version: all OS: URL: Submission from: (NULL) (193.71.61.60) Submitted by: hallvard If slap_send_search_entry() or slap_send_search_reference() fail, the client receives two responses. These functions should not send_ldap_error(). Their caller does that. Only tested with slap_send_search_entry(), by replacing the first 'if ( rc == -1 )' with 'if ( 1 )'.

1 0

Re: (ITS#7074) back-ldap module compilation issue with gcc 4.6.1
by hyc＠symas.com 01 Nov '11

01 Nov '11

stephane.paquot(a)gmail.com wrote: > Full_Name: Stéphane PAQUOT > Version: 2.4.26 > OS: Windows (MingW) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.194.186.14) > > > Hi > > I am actually compiling backend modules for openldap 2.4.26 with MingW (gcc > version 4.6.1, GNU make 3.81, GNU libtool 2.4, GNU automake 1.11.1, GNU autoconf > 2.68. > An issue occurs when compiling back-ldap module. > > The GNU tools used are the following : > host-triplet: i686-pc-mingw32 > shell: /bin/sh > compiler: gcc > compiler flags: -O3 -s -mms-bitfields -march=i386 -mtune=i686 > linker: c:/mingw/mingw32/bin/ld.exe (gnu? yes) > libtool: (GNU libtool) 2.4 > automake: automake (GNU automake) 1.11.1 > autoconf: autoconf (GNU Autoconf) 2.68 > > The command line to compile openldap 2.4.26 is the following > > ./configure --prefix=/software/openldap \ > --enable-slapd \ > --enable-modules \ > --enable-rewrite \ > --enable-bdb=mod \ > --enable-hdb=mod \ > --enable-ldap=mod \ > --enable-sql=mod \ > --enable-monitor=mod \ > --enable-accesslog=mod \ > --enable-auditlog=mod \ > --enable-rwm=mod \ > --enable-syncprov=mod \ > --with-odbc=odbc32 \ > --with-tls=openssl \ > --without-cyrus-sasl > > Here are the compilation flags : > CPPFLAGS="-I/software/openssl/include > -I/software/berkeleydb/berkeleydb-5.2/include" > LDFLAGS="-I/software/openssl/lib -I/software/berkeleydb/berkeleydb-5.2/lib" > LIBS="-lodbc32 -lws2_32" > > All backends modules and overlays compile fine but when compiling backend > back-ldap as a module, the following compile error occurs : error: initializer > element is not constant. > > $ make > /bin/sh ../../../libtool --tag=disable-static --mode=compile gcc -g -O2 > -std=c89 > -I../../../include -I../../../include -I.. -I./.. > -I/software/openssl/i > nclude -I/software/berkeleydb/berkeleydb-5.2/include -DSLAPD_IMPORT -c > chain.c > > gcc -g -O2 -std=c89 -I../../../include -I../../../include -I.. -I./.. > -I/softwa > re/openssl/include -I/software/berkeleydb/berkeleydb-5.2/include -DSLAPD_IMPORT > -c chain.c -DDLL_EXPORT -DPIC -o .libs/chain.o > chain.c:1273:3: error: initializer element is not constant > chain.c:1273:3: error: (near initialization for 'chainocs[1].co_table') > make: *** [chain.lo] Error 1 > > gcc 4.6.1 complains about > > static ConfigOCs chainocs[] = { > { "( OLcfgOvOc:3.1 " > "NAME 'olcChainConfig' " > "DESC 'Chain configuration' " > "SUP olcOverlayConfig " > "MAY ( " > #ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR > "olcChainingBehavior $ " > #endif /* LDAP_CONTROL_X_CHAINING_BEHAVIOR */ > "olcChainCacheURI $ " > "olcChainMaxReferralDepth $ " > "olcChainReturnError " > ") )", > Cft_Overlay, chaincfg, NULL, chain_cfadd }, > { "( OLcfgOvOc:3.2 " > "NAME 'olcChainDatabase' " > "DESC 'Chain remote server configuration' " > "AUXILIARY )", > Cft_Misc, olcDatabaseDummy, chain_ldadd > #ifdef SLAP_CONFIG_DELETE > , NULL, chain_lddel > #endif > }, > { NULL, 0, NULL} > }; > > I try to solve this problem but I'm a little stuck. When back-ldap is not > compiled as a module, no problem, slapd compiles fine with this backend > back-ldap. This type of problem seems to crop up regularly with Windows modules; the Windows linker is too stupid to figure out how to reference a data symbol from a different binary. In this case you can fix it by making a local copy of the definition of olcDatabaseDummy (which is in slapd/bconfig.c) and use the local copy in this table instead of the original. -- -- 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

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2011