- openldap-bugs - openldap.org

Re: (ITS#7082) smbk5pwd not respecting olcSmbK5PwdEnable on 64-bit platforms
by h.b.furuseth＠usit.uio.no 07 Nov '11

07 Nov '11

Thank you. I've committed your fix. verbs_to_mask() adds bits to an existing mask. > (...) I'm not sure why this only > manifests on 64-bit architectures, as my reduced test case (can > provide if necessary) also fails on 32-bit architectures. Probably just a coincidence: There happens to be a 0 on the stack where the compiler puts the m variable on on your 32-bit hosts. -- Hallvard

1 0

(ITS#7083) Broken verb_to_mask() calls
by h.b.furuseth＠usit.uio.no 07 Nov '11

07 Nov '11

Full_Name: Hallvard B Furuseth Version: 2.3-2.4.26 OS: URL: Submission from: (NULL) (193.71.61.60) Submitted by: hallvard slapd/bconfig.c and contrib:smbk5pwd.c use verb_to_mask() as if it returned a bitmask instead of an index. This affects delete operations of restrict, allows, disallows, requires, syslog loglevel, and smbk5pwd modules.

1 0

(ITS#7082) smbk5pwd not respecting olcSmbK5PwdEnable on 64-bit platforms
by zanchey＠ucc.gu.uwa.edu.au 07 Nov '11

07 Nov '11

Full_Name: David Adam Version: 2.4.23 OS: Debian URL: http://www.openldap.org/lists/openldap-technical/201111/msg00034.html Submission from: (NULL) (2001:44b8:6112:bc00:6ef0:49ff:fe74:26c4) On 64-bit machines using the contributed smbk5pwd overlay, the smbk5pwd module insists on trying to load all the Kerberos configuration regardless, even if smbk5PwdEnable is set to 'samba'. I suspect this has something to do with the call to verbs_to_mask() in smbk5pwd_cf_func (under the case PC_SMB_ENABLE) - my very basic printf() debugging shows that m is set correctly on 32-bit architectures but on 64-bit architectures returns a varying and strangely-numbered value (4511419, -1407332384, 353253328 in subsequent runs). The problem goes away if the m variable is initialised to 0 before the call to verbs_to_mask(). Most of the calls to verbs_to_mask() in the rest of the source initialise the fourth variable to 0 before calling. Either smbk5pwd also needs to do this, or the verbs_to_mask function needs to initialise the variable before use. I'm not sure why this only manifests on 64-bit architectures, as my reduced test case (can provide if necessary) also fails on 32-bit architectures.

1 0

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 02 Nov '11

02 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

Re: (ITS#7062) writes from lost connections not increasing contextCSN
by hyc＠symas.com 01 Nov '11

01 Nov '11

ebackes(a)symas.com wrote: > Full_Name: Emily Backes > Version: 2.4.26 > OS: any > URL: > Submission from: (NULL) (75.244.124.114) > > > If a client connects and writes, e.g. ADDs entries, then disconnects > before seeing the result, the writes are stored in the database but do > not increment contextCSN. This is an obvious consequence of the fact that checks for abandoned ops are performed before any response callbacks are invoked. The main op might have completed but no overlay code will run, so syncprov never gets a chance to update itself. (See result.c send_ldap_response()) The fix is less obvious. Probably we should only bypass the callbacks if rs->sr_err == SLAPD_ABANDON, meaning that the operation itself was actually aborted. -- -- 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#7075) back-perl initialization broken
by h.b.furuseth＠usit.uio.no 01 Nov '11

01 Nov '11

Full_Name: Hallvard B Furuseth Version: 2.4.17-2.4.26 OS: URL: http://groups.google.com/group/comp.lang.perl.misc/browse_thread/thread/151… Submission from: (NULL) (193.71.61.60) Submitted by: hallvard back-perl initialization broken PERL_SYS_INIT3() is called with wrong arguments. Introduced by ITS#5658. Fixing it to do the same as the Perl main program, but I can not test it on a system where these params are used so it is relevant - e.g. Windows. - arg 3 (env) is NULL, but Perl:proto.h requires non-NULL. Fixing to use PERL_SYS_INIT() instead. That also affects Perl versions before 5.6. 5.6 introduced INIT3, INIT is older. The alternative would be to pass &(char **environ) to PERL_SYS_INIT3(), but who knows what Perl does with the environment. Seems simpler to avoid it. - PERL_SYS_INIT/INIT3() can change their arguments. back-perl passed the changed argc but not the changed argv to perl_parse(). Fixing to pass both the changed argc and the changed argv. - arg 2 is passed char *(*argv)[3]. Fixing to pass as a char ***argv: char *embedding[] = { "", "-e", "0", NULL }, **argv = embedding; char ***old = (char ***) &embedding, ***corrected = &argv; 'old' is how the address was passed, 'new' is how it should be passed. 'old' holds the address of the embedding array, but it should hold the address of a variable which holds that address. See comp.lang.perl.misc discussion "PERL_SYS_INIT()" from Oct 31 2011.

1 0

Re: (ITS#7072) caseIgnoreMatch equals regular capital I with dotted capital I
by hyc＠symas.com 31 Oct '11

31 Oct '11

Frank.Meisschaert(a)UGent.be wrote: > Full_Name: Frank Meisschaert > Version: 2.4.26 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (157.193.44.200) > > > When I try to add the names "İsmail" (original, with dotted capital I) and > "Ismail" (transcribed, regular capital I) to an entry using ldapmodify: > > dn: ... > changetype: modify > replace: givenName > givenName: Ismail > givenName:: xLBzbWFpbA== > - > > I get the error: > > ldap_modify: Type or value exists (20) > additional info: givenName: value #0 provided more than once > > The lowercase version of dotted and regular capital I is regular i which > explains this error. However according to unicode case folding the dotted > capital I should be mapped to 0069 0307 (i, combining dot above) which would > make Ismail andİsmail different when compared case-insensitively as I > would expect. Apparently our liblunicode implementation doesn't use the CaseFolding data. I believe that means our implementation corresponds to the "Simple" case folding rules. They're valid, just not doing what you want in this case. So it appears that this is an enhancement request. I don't believe this request warrants a very high priority. Looking at the Unicode charts, I-with-dot-above is the only character where the two case folding alternatives actually makes a difference. -- -- 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#7074) back-ldap module compilation issue with gcc 4.6.1
by stephane.paquot＠gmail.com 29 Oct '11

29 Oct '11

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. Best regards and many thanks to you. Stéphane PAQUOT Database Administrator (Sybase, Oracle, MS SQL Server, MySQL). France, Paris.

1 0

Re: (ITS#7010) Deadlock in Producer/Consumer Nodes
by ghola＠rebelbase.com 28 Oct '11

28 Oct '11

Here is the data requested from the most recent lock-up. Default locking region information: 14 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 1000 Maximum number of locks possible 1000 Maximum number of lockers possible 1000 Maximum number of lock objects possible 160 Number of lock object partitions 27 Number of current locks 682 Maximum number of locks at any one time 5 Maximum number of locks in any one bucket 0 Maximum number of locks stolen by for an empty partition 0 Maximum number of locks stolen for any one partition 63 Number of current lockers 63 Maximum number of lockers at any one time 21 Number of current lock objects 377 Maximum number of lock objects at any one time 3 Maximum number of lock objects in any one bucket 0 Maximum number of objects stolen by for an empty partition 0 Maximum number of objects stolen for any one partition 13M Total number of locks requested (13581842) 13M Total number of locks released (13581804) 0 Total number of locks upgraded 13 Total number of locks downgraded 6 Lock requests not available due to conflicts, for which we waited 1 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 808KB The size of the lock region 15280 The number of partition locks that required waiting (0%) 10921 The maximum number of times any partition lock was waited for (0%) 0 The number of object queue operations that required waiting (0%) 4742 The number of locker allocations that required waiting (0%) 0 The number of region locks that required waiting (0%) 3 Maximum hash bucket length =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock REGINFO information: Lock Region type 5 Region ID __db.005 Region name 0x2aeb3285c000 Region address 0x2aeb3285c138 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 327 allocations, 0 failures, 0 frees, 1 longest Allocations by power-of-two sizes: 1KB 322 2KB 0 4KB 0 8KB 0 16KB 1 32KB 2 64KB 0 128KB 1 256KB 1 512KB 0 1024KB 0 REGION_JOIN_OK Region flags =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock region parameters: 262177 Lock region region mutex [0/450861 0% 15746/47187942583984] 1031 locker table size 1031 object table size 952 obj_off 122400 locker_off 1 need_dd =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock conflict matrix: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- 1 dd=22 locks held 1 write locks 0 pid/thread 7123/47021676422512 priority 100 1 READ 1 HELD id2entry.bdb handle 0 2 dd=21 locks held 1 write locks 0 pid/thread 7123/47021676422512 priority 100 2 READ 1 HELD dn2id.bdb handle 0 3 dd=20 locks held 0 write locks 0 pid/thread 7123/47021676422512 priority 100 4 dd=16 locks held 1 write locks 0 pid/thread 7123/1113479488 priority 100 4 READ 1 HELD entryUUID.bdb handle 0 5 dd=15 locks held 1 write locks 0 pid/thread 7123/1113479488 priority 100 5 READ 1 HELD modifyTimestamp.bdb handle 0 6 dd=12 locks held 1 write locks 0 pid/thread 7123/1113479488 priority 100 6 READ 1 HELD cn.bdb handle 0 7 dd=11 locks held 1 write locks 0 pid/thread 7123/1113479488 priority 100 7 READ 1 HELD givenName.bdb handle 0 8 dd=10 locks held 1 write locks 0 pid/thread 7123/1113479488 priority 100 8 READ 1 HELD sn.bdb handle 0 9 dd= 9 locks held 1 write locks 0 pid/thread 7123/1113479488 priority 100 9 READ 1 HELD objectClass.bdb handle 0 a dd= 6 locks held 1 write locks 0 pid/thread 7123/1113479488 priority 100 a READ 1 HELD uid.bdb handle 0 b dd= 5 locks held 1 write locks 0 pid/thread 7123/1113479488 priority 100 b READ 1 HELD uidNumber.bdb handle 0 c dd= 4 locks held 1 write locks 0 pid/thread 7123/1113479488 priority 100 c READ 1 HELD gidNumber.bdb handle 0 d dd= 3 locks held 1 write locks 0 pid/thread 7123/1121872192 priority 100 d READ 1 HELD sambaSID.bdb handle 0 e dd= 2 locks held 1 write locks 0 pid/thread 7123/1121872192 priority 100 e READ 1 HELD sambaPrimaryGroupSID.bdb handle 0 80000380 dd=14 locks held 0 write locks 0 pid/thread 7123/1121872192 priority 100 80000381 dd=13 locks held 0 write locks 0 pid/thread 7123/1092884800 priority 100 80000003 dd=19 locks held 0 write locks 0 pid/thread 7123/47021676422512 priority 100 80000004 dd=18 locks held 0 write locks 0 pid/thread 7123/47021676422512 priority 100 80000005 dd=17 locks held 1 write locks 0 pid/thread 7123/1113479488 priority 100 80000005 READ 1 HELD 0x3dc78 len: 9 data: a2b007000000000000 80000938 dd= 8 locks held 0 write locks 0 pid/thread 7123/1138657600 priority 100 80000939 dd= 7 locks held 0 write locks 0 pid/thread 7123/1130264896 priority 100 80048a47 dd= 1 locks held 0 write locks 0 pid/thread 7123/1147050304 priority 100 800dc266 dd= 0 locks held 11 write locks 5 pid/thread 7123/1138657600 priority 100 800dc266 WRITE 1 WAIT 0x3dc78 len: 9 data: a2b007000000000000 800dc266 READ 2 HELD dn2id.bdb page 11658 800dc266 WRITE 4 HELD dn2id.bdb page 11658 800dc266 READ 2 HELD objectClass.bdb page 115 800dc266 WRITE 2 HELD objectClass.bdb page 115 800dc266 READ 1 HELD objectClass.bdb page 3 800dc266 READ 1 HELD entryUUID.bdb page 2839 800dc266 WRITE 2 HELD entryUUID.bdb page 2839 800dc266 READ 1 HELD modifyTimestamp.bdb page 3168 800dc266 WRITE 2 HELD modifyTimestamp.bdb page 3168 800dc266 WRITE 3 HELD id2entry.bdb page 14475 800dc266 READ 1 HELD 0x36718 len: 9 data: 9cb007000000000000 800dc268 dd= 0 locks held 0 write locks 0 pid/thread 7123/1163835712 priority 100 800dc269 dd= 0 locks held 0 write locks 0 pid/thread 7123/1155443008 priority 100 800dc26a dd= 0 locks held 0 write locks 0 pid/thread 7123/1172228416 priority 100 800dc26b dd= 0 locks held 0 write locks 0 pid/thread 7123/1180621120 priority 100 800dc26c dd= 0 locks held 0 write locks 0 pid/thread 7123/1189013824 priority 100 800dc26d dd= 0 locks held 0 write locks 0 pid/thread 7123/1197406528 priority 100 800dc26e dd= 0 locks held 0 write locks 0 pid/thread 7123/1205799232 priority 100 800dc26f dd= 0 locks held 0 write locks 0 pid/thread 7123/1214191936 priority 100 800dc270 dd= 0 locks held 0 write locks 0 pid/thread 7123/1222584640 priority 100 800dc271 dd= 0 locks held 0 write locks 0 pid/thread 7123/1230977344 priority 100 800dc272 dd= 0 locks held 0 write locks 0 pid/thread 7123/1239370048 priority 100 800dc273 dd= 0 locks held 0 write locks 0 pid/thread 7123/1247762752 priority 100 800dc274 dd= 0 locks held 0 write locks 0 pid/thread 7123/1256155456 priority 100 800dc275 dd= 0 locks held 0 write locks 0 pid/thread 7123/1264548160 priority 100 800dc276 dd= 0 locks held 0 write locks 0 pid/thread 7123/1272940864 priority 100 800dc277 dd= 0 locks held 0 write locks 0 pid/thread 7123/1289726272 priority 100 800dc278 dd= 0 locks held 0 write locks 0 pid/thread 7123/1281333568 priority 100 800dc279 dd= 0 locks held 0 write locks 0 pid/thread 7123/1298118976 priority 100 800dc27a dd= 0 locks held 0 write locks 0 pid/thread 7123/1306511680 priority 100 800dc27b dd= 0 locks held 0 write locks 0 pid/thread 7123/1314904384 priority 100 800dc27c dd= 0 locks held 0 write locks 0 pid/thread 7123/1331689792 priority 100 800dc27d dd= 0 locks held 0 write locks 0 pid/thread 7123/1340082496 priority 100 800dc27e dd= 0 locks held 0 write locks 0 pid/thread 7123/1348475200 priority 100 800dc27f dd= 0 locks held 0 write locks 0 pid/thread 7123/1356867904 priority 100 800dc280 dd= 0 locks held 0 write locks 0 pid/thread 7123/1365260608 priority 100 800dc281 dd= 0 locks held 0 write locks 0 pid/thread 7123/1373653312 priority 100 800dc282 dd= 0 locks held 0 write locks 0 pid/thread 7123/1382046016 priority 100 800dc283 dd= 0 locks held 0 write locks 0 pid/thread 7123/1390438720 priority 100 800dc284 dd= 0 locks held 0 write locks 0 pid/thread 7123/1407224128 priority 100 800dc285 dd= 0 locks held 0 write locks 0 pid/thread 7123/1398831424 priority 100 800dc286 dd= 0 locks held 0 write locks 0 pid/thread 7123/1415616832 priority 100 800dc287 dd= 0 locks held 0 write locks 0 pid/thread 7123/1424009536 priority 100 800dc288 dd= 0 locks held 0 write locks 0 pid/thread 7123/1432402240 priority 100 800dc289 dd= 0 locks held 0 write locks 0 pid/thread 7123/1440794944 priority 100 800dc28a dd= 0 locks held 0 write locks 0 pid/thread 7123/1449187648 priority 100 800dc28b dd= 0 locks held 0 write locks 0 pid/thread 7123/1457580352 priority 100 800dc28c dd= 0 locks held 0 write locks 0 pid/thread 7123/1474365760 priority 100 800dc28d dd= 0 locks held 0 write locks 0 pid/thread 7123/1465973056 priority 100 800dc28e dd= 0 locks held 0 write locks 0 pid/thread 7123/1482758464 priority 100 800dc28e READ 1 WAIT dn2id.bdb page 11658 800dc28f dd= 0 locks held 0 write locks 0 pid/thread 7123/1491151168 priority 100 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- 800dc266 READ 2 HELD objectClass.bdb page 115 800dc266 WRITE 2 HELD objectClass.bdb page 115 800dc266 WRITE 3 HELD id2entry.bdb page 14475 4 READ 1 HELD entryUUID.bdb handle 0 1 READ 1 HELD id2entry.bdb handle 0 b READ 1 HELD uidNumber.bdb handle 0 80000005 READ 1 HELD 0x3dc78 len: 9 data: a2b007000000000000 800dc266 WRITE 1 WAIT 0x3dc78 len: 9 data: a2b007000000000000 e READ 1 HELD sambaPrimaryGroupSID.bdb handle 0 2 READ 1 HELD dn2id.bdb handle 0 800dc266 READ 1 HELD entryUUID.bdb page 2839 800dc266 WRITE 2 HELD entryUUID.bdb page 2839 a READ 1 HELD uid.bdb handle 0 6 READ 1 HELD cn.bdb handle 0 800dc266 READ 1 HELD 0x36718 len: 9 data: 9cb007000000000000 800dc266 READ 1 HELD modifyTimestamp.bdb page 3168 800dc266 WRITE 2 HELD modifyTimestamp.bdb page 3168 d READ 1 HELD sambaSID.bdb handle 0 c READ 1 HELD gidNumber.bdb handle 0 5 READ 1 HELD modifyTimestamp.bdb handle 0 8 READ 1 HELD sn.bdb handle 0 7 READ 1 HELD givenName.bdb handle 0 800dc266 READ 1 HELD objectClass.bdb page 3 9 READ 1 HELD objectClass.bdb handle 0 800dc266 READ 2 HELD dn2id.bdb page 11658 800dc266 WRITE 4 HELD dn2id.bdb page 11658 800dc28e READ 1 WAIT dn2id.bdb page 11658

1 0

(ITS#7073) zero-length entries should be allowed
by hyc＠OpenLDAP.org 28 Oct '11

28 Oct '11

Full_Name: Howard Chu Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc entry_header() rejects "entries" that have zero attributes. As it turns out, overlays like pcache and translucent can create such entries in their normal operation. With back-bdb/hdb, such entries will work OK while slapd is running, because they're in the entry cache. But after a restart, such entries can't be read back from the DB because they're considered invalid by entry_header(). Already fixed in master, entry_header() now allows zero length entries.

1 0

(ITS#7072) caseIgnoreMatch equals regular capital I with dotted capital I
by Frank.Meisschaert＠UGent.be 27 Oct '11

27 Oct '11

Full_Name: Frank Meisschaert Version: 2.4.26 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (157.193.44.200) When I try to add the names "İsmail" (original, with dotted capital I) and "Ismail" (transcribed, regular capital I) to an entry using ldapmodify: dn: ... changetype: modify replace: givenName givenName: Ismail givenName:: xLBzbWFpbA== - I get the error: ldap_modify: Type or value exists (20) additional info: givenName: value #0 provided more than once The lowercase version of dotted and regular capital I is regular i which explains this error. However according to unicode case folding the dotted capital I should be mapped to 0069 0307 (i, combining dot above) which would make Ismail and İsmail different when compared case-insensitively as I would expect.

1 0

Re: (ITS#7054) Please drop support to FreeBSD 1.x
by d＠delphij.net 24 Oct '11

24 Oct '11

Just a headsup -- libtool 2.4.2 should have the required changes to support FreeBSD 10.x. Cheers, -- Xin LI <delphij(a)delphij.net> https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die

1 0

Re: (ITS#7064) moznss SEC_ERROR_BAD_SIGNATURE with a certificate trusted by OpenSSL
by massimo.gravino＠pd.infn.it 24 Oct '11

24 Oct '11

On Mon, 24 Oct 2011, jvcelak(a)redhat.com wrote: > I believe this is a bug in Mozilla NSS and not in OpenLDAP. I have > successfully reproduced on Fedora. > > If you are interested in some details from my investigation, check: > https://bugzilla.redhat.com/show_bug.cgi?id=748394 > > -- > Jan V?el?k > Base Operating Systems Brno > Red Hat Inc. Thank you very much, I'll follow the discussion about this bug at bugzilla.redhat.com Best regards, Massimo Gravino System Administrator National Institute of Nuclear Physics - Padova (Italy)

1 0

Re: (ITS#7064) moznss SEC_ERROR_BAD_SIGNATURE with a certificate trusted by OpenSSL
by jvcelak＠redhat.com 24 Oct '11

24 Oct '11

I believe this is a bug in Mozilla NSS and not in OpenLDAP. I have successfully reproduced on Fedora. If you are interested in some details from my investigation, check: https://bugzilla.redhat.com/show_bug.cgi?id=748394 -- Jan Vèelák Base Operating Systems Brno Red Hat Inc.

1 0

Re: (ITS#7067) openldap not properly starting
by masarati＠aero.polimi.it 24 Oct '11

24 Oct '11

On 10/24/2011 07:18 AM, sanjiv.singh(a)impetus.co.in wrote: > --_000_23A2685ED8B30D46A90227113A1ECE0758F47662Mail3impetuscoi_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > How can I redirect to openldap-technical mailing list ? > Not getting any link for this . Subscribe to openldap-technical <http://www.openldap.org/lists/mm/listinfo/openldap-technical>; post your message to <mailto:openldap-technical@openldap.org> -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

Re: (ITS#7067) openldap not properly starting
by sanjiv.singh＠impetus.co.in 24 Oct '11

24 Oct '11

--_000_23A2685ED8B30D46A90227113A1ECE0758F47662Mail3impetuscoi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How can I redirect to openldap-technical mailing list ? Not getting any link for this . Regards, Sanjiv Singh ________________________________ New Impetus webcast on-demand 'Big Data Technologies for Social Media Analy= tics' available at http://bit.ly/nFdet0. Visit http://www.impetus.com to know more. Follow us on www.twitter.com/imp= etuscalling NOTE: This message may contain information that is confidential, proprietar= y, privileged or otherwise protected by law. The message is intended solely= for the named addressee. If received in error, please destroy and notify t= he sender. Any use of this email is prohibited when received in error. Impe= tus does not represent, warrant and/or guarantee, that the integrity of thi= s communication has been maintained nor that the communication is free of e= rrors, virus, interception or interference. --_000_23A2685ED8B30D46A90227113A1ECE0758F47662Mail3impetuscoi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <style>  </style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <pre>How can I redirect to openldap-technical mailing list ?</pre> Not getting any  link for this .   Regards, Sanjiv Singh     </div> <hr> New Impetus webcast on-demand ‘Big Data Technologies for Social Media= Analytics’ available at http://bit.ly/nFdet0. Visit http://www.impetus.com to know more. Follow us on www.twitter.com/imp= etuscalling NOTE: This message may contain information that is confidential, proprietar= y, privileged or otherwise protected by law. The message is intended solely= for the named addressee. If received in error, please destroy and notify t= he sender. Any use of this email is prohibited when received in error. Impetus does not represent, warrant = and/or guarantee, that the integrity of this communication has been maintai= ned nor that the communication is free of errors, virus, interception or in= terference. </body> </html> --_000_23A2685ED8B30D46A90227113A1ECE0758F47662Mail3impetuscoi_--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs