- openldap-bugs - openldap.org

(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 27 Oct '11

27 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 23 Oct '11

23 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

Re: (ITS#7065) changeType: modify "replace/delete" trick causes segmentation fault in cn=config
by h.b.furuseth＠usit.uio.no 23 Oct '11

23 Oct '11

Reproduced in master by trying to change olcSaslHost: config_modify_internal() does this with a == NULL: 5827 a->a_flags |= SLAP_ATTR_IXADD; jeffreyc(a)ucsc.edu writes: > To guarantee the removal of an attribute when I don't know if the attribute > exists already or not I often employ the following LDIF: > > ============== > dn: cn=config > changeType: modify > replace: attrToDelete > attrToDelete: dummy > - > delete: attrToDelete > ============== You can use this instead: dn: cn=config changeType: modify replace: attrToDelete - -- Hallvard

1 0

Re: (ITS#6763) slapd does not clear sr_entry/ctrls on sizelimit/busy
by h.b.furuseth＠usit.uio.no 23 Oct '11

23 Oct '11

I wrote: > slap_send_search_entry() does not always free/release the entry and > call slap_cleanup_play() on error. > > slap_send_search_reference() calls slap_cleanup_play(), but does not > always free/release the entry. > > I expect both functions always should do both, but don't know enough > myself to be sure. > > Resolution needed for ITS#6758 (SlapReply) - who should be responsible > for clearing out the entry? Nobody else were picking this up, and it was making back-monitor hang in ITS#7053. So I've made result.c always clean up. The code is still inconsistent: slap_send_search_entry() may flush the entry either before or after slap_cleanup_play(), while slap_send_search_reference() always flushes first. If anyone feels that should be regularized, feel free. I'm leaving it alone for now. -- Hallvard

1 0

Re: (ITS#7053) back-monitor blocks
by h.b.furuseth＠usit.uio.no 23 Oct '11

23 Oct '11

Fixed in master, dup of ITS#6763. Thank you for the simple test case. The '-z 10' identified the problem. slap_send_search_entry() did not call rs_flush_entry() when sizeLimitExceeded. I have not traced exactly what happened, but I expect this means some back-monitor entry kept its locks. -- Hallvard

1 0

Re: (ITS#7053) back-monitor blocks
by michael＠stroeder.com 22 Oct '11

22 Oct '11

This is still an issue also in HEAD.

1 0

Re: (ITS#7053) back-monitor blocks
by michael＠stroeder.com 22 Oct '11

22 Oct '11

But just for the records... Finally I managed to reproduce this with OpenLDAP's ldapsearch command-line tool. The bound entity needs read access to cn=monitor. Try this more than one time: ldapsearch -x -H ldapi://%2Ftmp%2Fopenldap-socket -b "cn=monitor" -z 10 -s one "(objectClass=*)" cn objectclass Do this as many times as you have threads configured and slapd becomes completely unresponsive and has to be stopped by kill -9. This was tested on my local install under openSUSE 11.4 but also on an installation running on HP-UX (64 bit build). Both running 2.4.26. Ciao, Michael.

1 0

Re: (ITS#7070) test058-syncrepl-asymmetric failed for hdb
by quanah＠zimbra.com 21 Oct '11

21 Oct '11

--On Friday, October 21, 2011 6:34 PM +0000 michael(a)stroeder.com wrote: > hyc(a)symas.com wrote: >> There's no evidence of an OpenLDAP bug here. All we can see from the >> testrun/slapd.1.log is that it took 15 seconds for slap_sasl_init to >> complete, which was long enough for the initial startup check to time >> out. You need to check your system to see why SASL took so long to >> initialize, most likely a DNS failure or some other transient issue. > > Hmm, this was with a local build of cyrus-sasl 2.1.25 which seg faulted on > GSSAPI in another test. I will retry with cyrus-sasl package shipped with > openSUSE 11.4. There was a patch posted to the cyrus-sasl list the other day for issues with the gssapi plugin in 2.1.25. It's working fine for me once it is fixed up. quanah@zre-ldap001:~/p4/main/ThirdParty/cyrus-sasl/patches$ cat gssapi.patch --- cyrus-sasl-2.1.25/plugins/gssapi.c.orig 2011-10-07 14:47:07.461866240 -0700 +++ cyrus-sasl-2.1.25/plugins/gssapi.c 2011-10-07 14:47:45.891872589 -0700 @@ -370,7 +370,7 @@ } if (output_token->value && output) { - unsigned char * p = (unsigned char *) text->encode_buf; + unsigned char * p; ret = _plug_buf_alloc(text->utils, &(text->encode_buf), @@ -384,6 +384,8 @@ return ret; } + p = (unsigned char *) text->encode_buf; + p[0] = (output_token->length>>24) & 0xFF; p[1] = (output_token->length>>16) & 0xFF; p[2] = (output_token->length>>8) & 0xFF; --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7070) test058-syncrepl-asymmetric failed for hdb
by michael＠stroeder.com 21 Oct '11

21 Oct '11

hyc(a)symas.com wrote: > There's no evidence of an OpenLDAP bug here. All we can see from the > testrun/slapd.1.log is that it took 15 seconds for slap_sasl_init to complete, > which was long enough for the initial startup check to time out. You need to > check your system to see why SASL took so long to initialize, most likely a > DNS failure or some other transient issue. Hmm, this was with a local build of cyrus-sasl 2.1.25 which seg faulted on GSSAPI in another test. I will retry with cyrus-sasl package shipped with openSUSE 11.4. Ciao, Michael.

1 0

Re: (ITS#7069) test061-syncreplication-initiation failed for hdb
by hyc＠symas.com 21 Oct '11

21 Oct '11

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD (from git) > OS: openSUSE 11.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.45.214) > > >>>>>> test061-syncreplication-initiation failed for hdb > (exit 255) > make[2]: *** [hdb-mod] Error 255 > 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 Not enough info in your testrun directory, what was the output from the script up this point? From reading the slapd.?.log files, it also looks like something in your environment is slowing down the SASL init here, enough to make the script timeout. On all of my tests here the timestamp for slap_sasl_init is always identical to the preceding timestamp, i.e., slap_sasl_init should never even take as long as 1 second. Fix your environment before submitting any more bug reports. -- -- 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#7070) test058-syncrepl-asymmetric failed for hdb
by hyc＠symas.com 21 Oct '11

21 Oct '11

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD (from git master) > OS: openSUSE 11.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.51.243) > > >>>>>> Starting test058-syncrepl-asymmetric for hdb... > running defines.sh > Initializing master configurations... > Initializing search configurations... > Starting central master slapd on TCP/IP port 9011... > Using ldapsearch to check that central master slapd is running... > Waiting 1 seconds for slapd to start... > Waiting 2 seconds for slapd to start... > Waiting 3 seconds for slapd to start... > Waiting 4 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > ldapsearch failed (255)! >>>>>> test058-syncrepl-asymmetric failed for hdb > (exit 255) > make[2]: *** [hdb-mod] Error 255 > 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 There's no evidence of an OpenLDAP bug here. All we can see from the testrun/slapd.1.log is that it took 15 seconds for slap_sasl_init to complete, which was long enough for the initial startup check to time out. You need to check your system to see why SASL took so long to initialize, most likely a DNS failure or some other transient issue. Closing this ITS. -- -- 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#7070) test058-syncrepl-asymmetric failed for hdb
by michael＠stroeder.com 21 Oct '11

21 Oct '11

See testrun/ here: http://www.stroeder.com/temp/openldap-its7070-testrun.tar.gz

1 0

(ITS#7070) test058-syncrepl-asymmetric failed for hdb
by michael＠stroeder.com 21 Oct '11

21 Oct '11

Full_Name: Michael Ströder Version: HEAD (from git master) OS: openSUSE 11.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.51.243) >>>>> Starting test058-syncrepl-asymmetric for hdb... running defines.sh Initializing master configurations... Initializing search configurations... Starting central master slapd on TCP/IP port 9011... Using ldapsearch to check that central master slapd is running... Waiting 1 seconds for slapd to start... Waiting 2 seconds for slapd to start... Waiting 3 seconds for slapd to start... Waiting 4 seconds for slapd to start... Waiting 5 seconds for slapd to start... ldapsearch failed (255)! >>>>> test058-syncrepl-asymmetric failed for hdb (exit 255) make[2]: *** [hdb-mod] Error 255 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

1 0

Re: (ITS#7067) openldap not properly starting
by Pierangelo Masarati 21 Oct '11

21 Oct '11

Current release is OpenLDAP 2.4.26. In any case, there is no clear indication in your report of a software bug. Please direct your message to the openldap-technical mailing list. p.

1 0

(ITS#7069)
by michael＠stroeder.com 21 Oct '11

21 Oct '11

See testrun/ here: http://www.stroeder.com/temp/openldap-its7069-testrun.tar.gz

1 0

(ITS#7069) test061-syncreplication-initiation failed for hdb
by michael＠stroeder.com 21 Oct '11

21 Oct '11

Full_Name: Michael Ströder Version: HEAD (from git) OS: openSUSE 11.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.45.214) >>>>> test061-syncreplication-initiation failed for hdb (exit 255) make[2]: *** [hdb-mod] Error 255 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

1 0

Re: (ITS#7042) [PATCH] allow unsetting of tls_* options for syncrepl
by pm＠datasphere.ch 20 Oct '11

20 Oct '11

--=-H9Xw5XBDhIDPupeYRJLz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I am the author of the patch at: ftp://ftp.openldap.org/incoming/jvcelak-20110912-syncrepl-allow-unsetting-o= f-tls-options.patch and I want to argue in favor of it: 1) In a configuration using a simple bind to authenticate a client, you have no choice but using ldaps to protect password sniffing: this requires a SERVER certificate only. 2) Since primary and replicated servers can have their role reversed (i.e.: after failure and/or recovery of the former primary server), the configurations should be kept as symmetric as possible (except for syncrepl) in order to speed-up switch: SSL in both servers should thus have the same configuration. 3) syncrepl then forces SSL to use a client certificate rather than a simple bind for authentication: this implies "normal" clients will also need a certificate... we are then in a situation lying very far from using ldaps for encryption only :-( 4) Using separate server and client certificates within a server, although safer, does not resolve my problem. For the above reason, I would really like to see my patch included in openldap code, or at least an equivalent solution. Because "third-party patch submissions cannot be accepted per our IPR policies. The original author is required to submit their own patches.", do you need me to re-submit it ? Thanks in advance for your reply. Regards, Patrick Monnerat DATASPHERE S.A. 16, chemin des Aulx CH-1228 Plan-les-Ouates (GE) --=-H9Xw5XBDhIDPupeYRJLz Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIH/DCCA9Mw ggK7oAMCAQICARQwDQYJKoZIhvcNAQEFBQAwgaIxCzAJBgNVBAYTAkNIMQ8wDQYDVQQIEwZHZW5l dmExGDAWBgNVBAcTD1BsYW4tbGVzLU91YXRlczEYMBYGA1UEChMPREFUQVNQSEVSRSBTLkEuMSQw IgYDVQQDExtEQVRBU1BIRVJFIG1haWwgc2VjdXJpdHkgQ0ExKDAmBgkqhkiG9w0BCQEWGWJ1cmVh dXRpcXVlQGRhdGFzcGhlcmUuY2gwHhcNMTEwODIzMTM1MzAwWhcNMTIxMjMxMjM1OTAwWjCBvDEL MAkGA1UEBhMCQ0gxDzANBgNVBAgTBkdlbmV2YTEYMBYGA1UEBxMPUGxhbi1sZXMtT3VhdGVzMRcw FQYDVQQKEw5EQVRBU1BIRVJFIFMuQTEZMBcGA1UEAxMQUGF0cmljayBNb25uZXJhdDEtMCsGCSqG SIb3DQEJARYecGF0cmljay5tb25uZXJhdEBkYXRhc3BoZXJlLmNoMR8wHQYJKoZIhvcNAQkBFhBw bUBkYXRhc3BoZXJlLmNoMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCzpT/ufabbhCa1JFvX ZWLCDP8tPBxTilXjEFKAnNirdOc8Sj667iey7ypcgkA2QUZu+gHDSVD3iNRro2rQPdTzjnLCml5P Up+AOB48X5jUwVbxihmAvtM21KQGZZwcmGdlj6AgY/Vxci48CRn+DzW6lY+VYCtf7HWhNHih4G1Y IwIDAQABo3wwejAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBR79vf/tmNLu8XwC0nU02j0WQLCzjAL BgNVHQ8EBAMCA7gwKwYDVR0lBCQwIgYIKwYBBQUHAwQGCisGAQQBgjcCARUGCisGAQQBgjcCARYw EQYJYIZIAYb4QgEBBAQDAgSwMA0GCSqGSIb3DQEBBQUAA4IBAQA8gckFW7PMcfcFhZoVkI1ePP2f XQ1UM4tChxfuPmKYXb2VbM2bYn33MiKnswlzsH/gDvQawYFKvRCehE5JiPUa42kGd8jXNzU8sRnm uMHpjengOO3aLKZLAZRXS1dGjD9q3CQa/KDT31+ODWG7vztY8ZMBv008lb/eJvKt9ssm0cPTeKA9 /YenJzklzyY/MlNnW+zRce+3Ms4171wnrjKcA4J+Zyr0Ow1eEYzoIVEphT1WmybDPr0EJoueDUvH 9uz5cxRpxlIFY4jgTqhUQid/7uHrkaKU/OrADsOy2sGr4YpcvRpHseZZIA3Z8ovOHQ9J4WGviz9w Z6gcTLtQu6baMIIEITCCAwmgAwIBAgIBEzANBgkqhkiG9w0BAQUFADCBsDELMAkGA1UEBhMCQ0gx DzANBgNVBAgTBkdlbmV2YTEYMBYGA1UEBxMPUGxhbi1sZXMtT3VhdGVzMRgwFgYDVQQKEw9EQVRB U1BIRVJFIFMuQS4xMjAwBgNVBAMTKURBVEFTUEhFUkUgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSAyMSgwJgYJKoZIhvcNAQkBFhlidXJlYXV0aXF1ZUBkYXRhc3BoZXJlLmNoMB4XDTExMDgy MzEzNTEwMFoXDTMwMTIzMTIzNTkwMFowgaIxCzAJBgNVBAYTAkNIMQ8wDQYDVQQIEwZHZW5ldmEx GDAWBgNVBAcTD1BsYW4tbGVzLU91YXRlczEYMBYGA1UEChMPREFUQVNQSEVSRSBTLkEuMSQwIgYD VQQDExtEQVRBU1BIRVJFIG1haWwgc2VjdXJpdHkgQ0ExKDAmBgkqhkiG9w0BCQEWGWJ1cmVhdXRp cXVlQGRhdGFzcGhlcmUuY2gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDTbQAxPu9L skt5ddMLzbS+bLQlW+gtcecHp9zL+x44dSXc663y6s+/XWxDbLZ0s+w6vp5CMB6pXxR5s8KfMDSC 22s7nq0t/BpQ1WfLkszG2JRs8BXIyrsDrFqYBBxcxiyyjzyQYVJg7qtPveUw9aQs53QCnZfXwG9s H2crPnAzoOzx5jptWvA5aHLMKqaZbGztUANABqZfZEwwGS/YG3nHxOKnl+UvmueJWiMs+plendlA 5+UBrUAk46/1IFNyjMqaBR8bug7IovHB9sn/k999eHVeBiu1qeTo0tcDEMvSBTh5JqIkl5lH7TU+ wgVCBA2/Eo1ccrvFkgTmztocbMczAgMBAAGjUjBQMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYE FFxbVp/ZdU5YlwvAFPbbFg+jGWehMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAAcwDQYJ KoZIhvcNAQEFBQADggEBAH6oFynXqL8Tk6sA032VbJyibS8woHni0/ayhrcBdEORc/wvfmhEA2kK 9Yy4xEaprsxT0fFyBJ4YGYyXX4SkQdr0pRCDO/niL2woQmar5vq4v9xa2FgrWOh7jKcXuh/SMpGq WZzQQTvYY0+X7SXX1+Ioje7rqzEDWNmzpp+mtPr/ENVmIxwTGEtXbDDLJN48sTmBDnKrca2UJrfU EFDDHon9CBBg53u+JodQiJfSbraqwje1QrGCvOHkyBr3ulBmssePVQzPphON39pPgbJCoE7sd/WK UX02QIorkbdaA8K/S38Ggc1xN9kNDE5tuClAYJSZUHeDnROgz1QncevRdKMxggGuMIIBqgIBATCB qDCBojELMAkGA1UEBhMCQ0gxDzANBgNVBAgTBkdlbmV2YTEYMBYGA1UEBxMPUGxhbi1sZXMtT3Vh dGVzMRgwFgYDVQQKEw9EQVRBU1BIRVJFIFMuQS4xJDAiBgNVBAMTG0RBVEFTUEhFUkUgbWFpbCBz ZWN1cml0eSBDQTEoMCYGCSqGSIb3DQEJARYZYnVyZWF1dGlxdWVAZGF0YXNwaGVyZS5jaAIBFDAJ BgUrDgMCGgUAoF0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEx MDIwMTYxMjEwWjAjBgkqhkiG9w0BCQQxFgQU/0S6iq+obCv1FnngaSJRbdoGRygwDQYJKoZIhvcN AQEBBQAEgYBXOHzJGvDyRJTXk7jxmGjef5QY39Ziyodp0BIYwRukyAgQ273nzPxBga96lZog7obN 2qsnWxGi9RtGEyua27OacgUPOb9+vjX5/xb3DGol81GnBqOusj8ZrdNTa7i7lKmA+o7cFD3hM6o0 PLi3EqA3rsEgu65uGpWuuyS8rzeRFAAAAAAAAA== --=-H9Xw5XBDhIDPupeYRJLz--

1 0

Re: (ITS#7068) openldap connection issue
by sanjiv.singh＠impetus.co.in 20 Oct '11

20 Oct '11

--_000_23A2685ED8B30D46A90227113A1ECE0758F3EAA3Mail3impetuscoi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi all, adding more details for debugging..... when i fire ldapadd utility with following ldif , it repeatedly throughing = following logs.... new.ldif ------------------------------------------------------ dn: cn=3DProcessor,dc=3Dmydomain,dc=3Dcom description: some description roleType: My Admin uniqueMember: uid=3Dmyadmin,dc=3Dmydomain,dc=3Dcom tenantId: Global cn: Processor objectClass: groupOfUniqueNames objectClass: top ------------------------------------------------------ /usr/local/bin/ldapadd -d 65535 -h 10.122.215.40 -p 6070 -x -w ***** -D "cn= =3DManager,dc=3Dmydomain,dc=3Dcom" -f new.ldif ------------------------------------------------------ ** ld 0x4185ad0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x4185ad0 request count 1 (abandoned 0) ** ld 0x4185ad0 Response Queue: Empty ld 0x4185ad0 response count 0 ldap_chkResponseList ld 0x4185ad0 msgid 2 all 1 ldap_chkResponseList returns ld 0x4185ad0 NULL ldap_int_select ldap_result ld 0x4185ad0 msgid 2 wait4msg ld 0x4185ad0 msgid 2 (timeout 100000 usec) wait4msg continue ld 0x4185ad0 msgid 2 all 1 ** ld 0x4185ad0 Connections: * host: 10.122.215.40 port: 6070 (default) refcnt: 2 status: Connected last used: Thu Oct 20 08:42:30 2011 -------------------------------------------------------- Regards, Sanjiv Singh Software Engineer (iLabs) Impetus Infotech (India) Pvt. Ltd. D-40, Sector-59, Noida - 201307, UP | (M) +91-9990-447-339 | www.impetus.c= om<http://www.impetus.com/> ________________________________ 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_23A2685ED8B30D46A90227113A1ECE0758F3EAA3Mail3impetuscoi_ 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"> hi all, adding more details for debugging.....   when i fire ldapadd utility with following ldif , it= repeatedly throughing following logs....   new.ldif ----------------------------------------------------= -- dn: cn=3DProcessor,dc=3Dmydomain,dc=3Dcom description: some description roleType: My Admin uniqueMember: uid=3Dmyadmin,dc=3Dmydomain,dc=3Dcom</= p> tenantId: Global cn: Processor objectClass: groupOfUniqueNames objectClass: top ----------------------------------------------------= --   /usr/local/bin/ldapadd -d 65535 -h 10.122.215.40 -p = 6070 -x -w ***** -D "cn=3DManager,dc=3Dmydomain,dc=3Dcom" -f new.= ldif ----------------------------------------------------= -- ** ld 0x4185ad0 Outstanding Requests: * msgid 2,  origid 2, status InProgress    outstanding referrals 0, parent count 0=   ld 0x4185ad0 request count 1 (abandoned 0)</p= > ** ld 0x4185ad0 Response Queue:    Empty   ld 0x4185ad0 response count 0 ldap_chkResponseList ld 0x4185ad0 msgid 2 all 1 ldap_chkResponseList returns ld 0x4185ad0 NULL ldap_int_select ldap_result ld 0x4185ad0 msgid 2 wait4msg ld 0x4185ad0 msgid 2 (timeout 100000 usec)<= /p> wait4msg continue ld 0x4185ad0 msgid 2 all 1 ** ld 0x4185ad0 Connections: * host: 10.122.215.40  port: 6070  (defaul= t)   refcnt: 2  status: Connected   last used: Thu Oct 20 08:42:30 2011 ----------------------------------------------------= ----   Regards, Sanjiv Singh Software Engineer (iLabs)</s= pan> Impetus Infotech (India) = Pvt. Ltd. D-40, Sector-59, Noida - 201= 307, UP |  (M) +91-9990-447-339 | <a href=3D"http://www.impetus.com/" title=3D"http://www.impetus.com">www.impetus.com</a>&nb= sp;     </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_23A2685ED8B30D46A90227113A1ECE0758F3EAA3Mail3impetuscoi_--

1 0

(ITS#7068) openldap connection issue
by sanjiv.is.on＠gmail.com 20 Oct '11

20 Oct '11

Full_Name: Sanjiv Singh Version: 2.4.20 OS: centOS 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (115.113.49.98) Hi all, I am facing openldap issue, facing problem during operation with openldap utilities. slapadd,ldapsearch and slapcat etc. I have installed & configure openldap 2.4.20 from source. enable debugging level -1(max debug level). here is my LDIF that i want to add to my ldap server. mydata.ldif ------------------------------------------------------ dn: cn=My Operator,dc=mydomain ,dc=com description: My Operator for managing job types roleType: Common tenantId: Global cn: My Operator objectClass: groupOfUniqueNames objectClass: top structuralObjectClass: groupOfUniqueNames entryUUID: 93385d1f-c9ec-4a1e-93fe-93f6cc58f759 creatorsName: cn=Manager,dc=mydomain,dc=com createTimestamp: 20110506070135Z entryCSN: 20110506070135.425379Z#000000#000#000000 modifiersName: cn=Manager,dc=mydomain,dc=com modifyTimestamp: 20110506070135Z ------------------------------------------------------- when I tried to fire slapadd ldap utility. following utility hand for infinite time. i had set max debug level( -d -1) for finding root cause. $ /usr/local/sbin/slapadd -v -d -1 -c -l mydata.ldif -f /usr/local/etc/openldap/slapd.conf -------------------------------------------------------- slapadd startup: initiated. backend_startup_one: starting "dc=mydomain,dc=com" bdb_db_open: "dc=mydomain,dc=com" bdb_db_open: database "dc=mydomain,dc=com": unclean shutdown detected; attempting recovery. bdb_db_open: database "dc=mydomain,dc=com": dbenv_open(/var/lib/ldap). bdb_monitor_db_open: monitoring disabled; configure monitor database to enable => str2entry: "dn: cn=SMGOperator,dc=mydomain,dc=com description: SMG Operator for managing job types roleType: Common tenantId: Global cn: SMGOperator objectClass: groupOfUniqueNames objectClass: top structuralObjectClass: groupOfUniqueNames entryUUID: 93385d1f-c9ec-4a1e-93fe-93f6cc58f759 creatorsName: cn=Manager,dc=mydomain,dc=com createTimestamp: 20110506070135Z entryCSN: 20110506070135.425379Z#000000#000#000000 modifiersName: cn=Manager,dc=mydomain,dc=com modifyTimestamp: 20110506070135Z " >>> dnPrettyNormal: <cn=SMGOperator,dc=mydomain,dc=com> <<< dnPrettyNormal: <cn=SMGOperator,dc=mydomain,dc=com>, <cn=smgoperator,dc=mydomain,dc=com> >>> dnPretty: <cn=Manager,dc=mydomain,dc=com> <<< dnPretty: <cn=Manager,dc=mydomain,dc=com> >>> dnNormalize: <cn=Manager,dc=mydomain,dc=com> <<< dnNormalize: <cn=manager,dc=mydomain,dc=com> >>> dnPretty: <cn=Manager,dc=mydomain,dc=com> <<< dnPretty: <cn=Manager,dc=mydomain,dc=com> >>> dnNormalize: <cn=Manager,dc=mydomain,dc=com> <<< dnNormalize: <cn=manager,dc=mydomain,dc=com> <= str2entry(cn=My Operator,dc=mydomain,dc=com) -> 0xb5e5be8 oc_check_required entry (cn=My Operator,dc=mydomain,dc=com), objectClass "groupOfUniqueNames" oc_check_allowed type "description" oc_check_allowed type "roleType" oc_check_allowed type "tenantId" oc_check_allowed type "cn" oc_check_allowed type "objectClass" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "entryUUID" oc_check_allowed type "creatorsName" oc_check_allowed type "createTimestamp" oc_check_allowed type "entryCSN" oc_check_allowed type "modifiersName" oc_check_allowed type "modifyTimestamp" => bdb_tool_entry_put( -1, "cn=My Operator,dc=mydomain,dc=com" ) => bdb_dn2id("dc=mydomain,dc=com") <= bdb_dn2id: got id=0x1 => bdb_dn2id("cn=myoperator,dc=mydomain,dc=com") ------------------------------------------------------------ and even after enabling -q option , it completes but ldap server would not be able to start. (-q : enable quick [fewer integrity checks mode] Does fewer consistency checks on the input data, and no consistency checks when writing the database. Improves the load time but if any errors or interruptions occur the resulting database will be unusable.) $ /usr/local/sbin/slapadd -v -d -1 -q -c -l mydata.ldif -f /usr/local/etc/openldap/slapd.conf ------------------------------------------------------------- slapadd startup: initiated. backend_startup_one: starting "dc=dmbsso,dc=com" bdb_db_open: "dc=dmbsso,dc=com" bdb_db_open: database "dc=dmbsso,dc=com": unclean shutdown detected; attempting recovery. bdb_db_open: database "dc=dmbsso,dc=com": dbenv_open(/var/lib/ldap). bdb(dc=dmbsso,dc=com): recovery requires transaction support bdb_db_open: database "dc=dmbsso,dc=com" cannot be recovered, err 22. Restore from backup! ====> bdb_cache_release_all backend_startup_one (type=bdb, suffix="dc=dmbsso,dc=com"): bi_db_open failed! (22) slap_startup failed. -------------------------------------------------------------- even I am face with ldap utility slapcat, after firing it hanged up for infinite. It seems , there are some problem with ldif file, but this ldif file works well on other hosts (having same schema and molules and ldap configuration). We are facing this issue intermittently on some hosts, works well on some hosts(all are CentOS 5.5). is there some wrong in my understanding? Am I missing some thing in my configuration ? Is anyboby able to find root cause ? Eagerly waiting for your response. I can provide more like ldap log , ldap configuration (if that can help in debugging the issue) We are passing through very critical time. Regards, Sanjiv Singh Software Engineer (iLabs) Impetus Infotech (India) Pvt. Ltd. D-40, Sector-59, Noida - 201307, UP | (M) +91-9990-447-339 | www.impetus.com

1 0

(ITS#7067) openldap not properly starting
by sanjiv.is.on＠gmail.com 20 Oct '11

20 Oct '11

Full_Name: Sanjiv Singh Version: 2.4.20 OS: centOS 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (115.113.49.98) Hi all, I am facing openldap issue, facing problem during operation with openldap utilities. slapadd,ldapsearch and slapcat etc. I have installed & configure openldap 2.4.20 from source. enable debugginf level -1(max debug level). here is my LDIF that i want to add to my ldap server. mydata.ldif ------------------------------------------------------ dn: cn=My Operator,dc=mydomain ,dc=com description: My Operator for managing job types roleType: Common tenantId: Global cn: My Operator objectClass: groupOfUniqueNames objectClass: top structuralObjectClass: groupOfUniqueNames entryUUID: 93385d1f-c9ec-4a1e-93fe-93f6cc58f759 creatorsName: cn=Manager,dc=mydomain,dc=com createTimestamp: 20110506070135Z entryCSN: 20110506070135.425379Z#000000#000#000000 modifiersName: cn=Manager,dc=mydomain,dc=com modifyTimestamp: 20110506070135Z ------------------------------------------------------- when I tried to fire slapadd ldap utility. following utility hand for infinite time. i had set max debug level( -d -1) for finding root cause. $ /usr/local/sbin/slapadd -v -d -1 -c -l mydata.ldif -f /usr/local/etc/openldap/slapd.conf -------------------------------------------------------- slapadd startup: initiated. backend_startup_one: starting "dc=mydomain,dc=com" bdb_db_open: "dc=mydomain,dc=com" bdb_db_open: database "dc=mydomain,dc=com": unclean shutdown detected; attempting recovery. bdb_db_open: database "dc=mydomain,dc=com": dbenv_open(/var/lib/ldap). bdb_monitor_db_open: monitoring disabled; configure monitor database to enable => str2entry: "dn: cn=SMGOperator,dc=mydomain,dc=com description: SMG Operator for managing job types roleType: Common tenantId: Global cn: SMGOperator objectClass: groupOfUniqueNames objectClass: top structuralObjectClass: groupOfUniqueNames entryUUID: 93385d1f-c9ec-4a1e-93fe-93f6cc58f759 creatorsName: cn=Manager,dc=mydomain,dc=com createTimestamp: 20110506070135Z entryCSN: 20110506070135.425379Z#000000#000#000000 modifiersName: cn=Manager,dc=mydomain,dc=com modifyTimestamp: 20110506070135Z " >>> dnPrettyNormal: <cn=SMGOperator,dc=mydomain,dc=com> <<< dnPrettyNormal: <cn=SMGOperator,dc=mydomain,dc=com>, <cn=smgoperator,dc=mydomain,dc=com> >>> dnPretty: <cn=Manager,dc=mydomain,dc=com> <<< dnPretty: <cn=Manager,dc=mydomain,dc=com> >>> dnNormalize: <cn=Manager,dc=mydomain,dc=com> <<< dnNormalize: <cn=manager,dc=mydomain,dc=com> >>> dnPretty: <cn=Manager,dc=mydomain,dc=com> <<< dnPretty: <cn=Manager,dc=mydomain,dc=com> >>> dnNormalize: <cn=Manager,dc=mydomain,dc=com> <<< dnNormalize: <cn=manager,dc=mydomain,dc=com> <= str2entry(cn=My Operator,dc=mydomain,dc=com) -> 0xb5e5be8 oc_check_required entry (cn=My Operator,dc=mydomain,dc=com), objectClass "groupOfUniqueNames" oc_check_allowed type "description" oc_check_allowed type "roleType" oc_check_allowed type "tenantId" oc_check_allowed type "cn" oc_check_allowed type "objectClass" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "entryUUID" oc_check_allowed type "creatorsName" oc_check_allowed type "createTimestamp" oc_check_allowed type "entryCSN" oc_check_allowed type "modifiersName" oc_check_allowed type "modifyTimestamp" => bdb_tool_entry_put( -1, "cn=My Operator,dc=mydomain,dc=com" ) => bdb_dn2id("dc=mydomain,dc=com") <= bdb_dn2id: got id=0x1 => bdb_dn2id("cn=myoperator,dc=mydomain,dc=com") ------------------------------------------------------------ and even after enabling -q option , it completes but ldap server would not be able to start. (-q : enable quick [fewer integrity checks mode] Does fewer consistency checks on the input data, and no consistency checks when writing the database. Improves the load time but if any errors or interruptions occur the resulting database will be unusable.) $ /usr/local/sbin/slapadd -v -d -1 -q -c -l mydata.ldif -f /usr/local/etc/openldap/slapd.conf ------------------------------------------------------------- slapadd startup: initiated. backend_startup_one: starting "dc=dmbsso,dc=com" bdb_db_open: "dc=dmbsso,dc=com" bdb_db_open: database "dc=dmbsso,dc=com": unclean shutdown detected; attempting recovery. bdb_db_open: database "dc=dmbsso,dc=com": dbenv_open(/var/lib/ldap). bdb(dc=dmbsso,dc=com): recovery requires transaction support bdb_db_open: database "dc=dmbsso,dc=com" cannot be recovered, err 22. Restore from backup! ====> bdb_cache_release_all backend_startup_one (type=bdb, suffix="dc=dmbsso,dc=com"): bi_db_open failed! (22) slap_startup failed. -------------------------------------------------------------- even I am face with ldap utility slapcat, after firing it hanged up for infinite. It seems , there are some problem with ldif file, but this ldif file works well on other hosts (having same schema and molules and ldap configuration). We are facing this issue intermittently on some hosts, works well on some hosts(all are CentOS 5.5). is there some wrong in my understanding? Am I missing some thing in my configuration ? Is anyboby able to find root cause ? Eagerly waiting for your response. I can provide more like ldap log , ldap configuration (if that can help in debugging the issue) We are passing through very critical time. Regards, Sanjiv Singh Software Engineer (iLabs) Impetus Infotech (India) Pvt. Ltd. D-40, Sector-59, Noida - 201307, UP | (M) +91-9990-447-339 | www.impetus.com

1 0

Re: (ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them
by ondrej.kuznik＠acision.com 19 Oct '11

19 Oct '11

On 07/07/2011 03:26 PM, ondrej.kuznik(a)acision.com wrote: > ftp://ftp.openldap.org/incoming/ondrej-kuznik-20110707.c > has an example of such overlay. To try it, initialize the overlay and > add these entries: > > dn: olcTestAttrOne=zero,$OVERLAY_DN > objectclass: olcTestOne > > dn: olcTestAttrTwo=one,$OVERLAY_DN > objectclass: olcTestTwo > > dn: olcTestAttrOne=two,$OVERLAY_DN > objectclass: olcTestOne > > dn: olcTestAttrTwo=three,$OVERLAY_DN > objectclass: olcTestTwo > > After a restart compare the output of slapcat -n0 with the output of > ldapsearch -b cn=config, you should see at least one different entry. > You might also try to modify the entries before and after the restart. > For those that do not match you get "no such object" as the dn is no > longer in the ldif database. The issue is in bconfig.c:4726, the code treats all siblings as part of one ordering (contrary to what http://highlandsun.com/hyc/drafts/draft-chu-ldap-xordered-xx.html implies since cn=config seems to treat everything as X-ORDERED 'SIBLINGS'), while back-ldif orders them accordingly. Also its caller (config_ldif_resp) does not expect any reordering to be necessary, after all it should be (and is) reading a valid cn=config db, so the entry renaming then never gets propagated to back-ldif causing this desync. -- Ondrej Kuznik This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

(ITS#7066) ACL added to back-config only active after restart
by rhafer＠suse.de 18 Oct '11

18 Oct '11

Full_Name: Ralf Haferkamp Version: RE24, master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.171.158) The first ACL added to "olcDatabase={0}config,cn=config" does only get active after slapd is restarted. This is because slapd upon startup creates a hardcoded deny-everything ACL when no ACL is defined explicitly for the database. ACLs added after slapd is started will be appended to that hardcoded ACL (but never evaluated as the hardcoded one already matches everything). I am working on a fix, reworking the way how the hardcoded default ACL for olcDatabase={0}config,cn=config is applied.

1 0

(ITS#7065) changeType: modify "replace/delete" trick causes segmentation fault in cn=config
by jeffreyc＠ucsc.edu 17 Oct '11

17 Oct '11

Full_Name: Jeffrey Crawford Version: 2.4.26 OS: FreeBSD 8.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (169.233.224.28) To guarantee the removal of an attribute when I don't know if the attribute exists already or not I often employ the following LDIF: ============== dn: cn=config changeType: modify replace: attrToDelete attrToDelete: dummy - delete: attrToDelete ============== Howver every time I run the above against cn=config it causes a segmentation fault. It does not cause any problems with a hdb backends. I like to set up ldifs that i can run generically without having to know if content is there or not so I do use this. I can work around it by just separating the above out into two "dn" instructions. but if for example one wanted to remove Indexes, that intermediate update might cause some process to start then abruptly stop or not stop. The above failure is consistant, so hopefully easy to find.

1 0

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

17 Oct '11

Full_Name: Massimo Gravino Version: 2.4.23-15 OS: Scientific Linux 6.1 URL: Submission from: (NULL) (192.84.143.111) We have an openldap server that uses LDAP over TLS/SSL and serves hundreds of clients. The CA used to sign the server certificate was created in 2005 with OpenSSL 0.9.7a. The CA self signed certificate and the server certificate have been used until now without any problem. In the server configuration (/etc/openldap/slapd.conf) we use TLSCertificateFile and TLSCertificateKeyFile to specify the path to the pem files of the certificate and private key of the server, and TLSCACertificateFile for the path to the pem file of the self signed certificate of the CA. In the client configuration (/etc/openldap/ldap.conf) we only define TLS_CACERT to specify the path to the pem file of the CA certificate. Now we are not able to use the the CA certificate on new Scientific Linux 6.1 clients with openldap 2.4.23-15: the problem appears with the standard openldap-2.4.23-15.el6 package that is compiled using MozNSS. If we recompile it using OpenSSL, the problem disappears (to recompile I simply edit the .spec file and omit -DHAVE_MOZNSS from the CFLAGS definition, change the --with-tls=no option to --with-tls=openssl and rebuild with rpmbuild -ba). This is the error obtained from the client with the original package when using ldapsearch: ldapsearch -x -d1 .... TLS: loaded CA certificate file /etc/openldap/cacerts/cacert.pem. TLS: certificate [CN=my.server.name,OU=Sezione di Padova,O=INFN,L=Padova,ST=Italia,C=IT] is not valid - error -8182:Unknown code ___f 10. TLS: error: connect - force handshake failure: errno 21 - moznss error -8182 TLS: can't connect: TLS error -8182:Unknown code ___f 10. ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) The problem appears to be related to our particular CA, that uses a DSA key. I've never been able to reproduce the problem creating new CA with an rsa key; however if possible I'd not change the the CA that signes my server certificate, because in this case I should change the CA certificate on a lot of clients. Nor I would manually recompile every new version of openldap packages. So I collected all the steps necessary to reproduce this problem on Scientific linux 6.1 server and client, with openldap 2.4.23-15 and openssl 1.0.0-10, hoping that the problem will be considered a bug in MozNSS. Certification Authority creation -------------------------------- mkdir CA cd CA/ mkdir certs crl newcerts private touch index.txt echo "01" > serial edit /etc/pki/tls/openssl.cnf and change the dir definition in [ CA_default ] to point to the CA/ directory openssl dsaparam -out dsaparam.pem 2048 openssl req -new -x509 -keyout private/cakey.pem -out cacert.pem -newkey dsa:dsaparam.pem -days 5000 Server certificate creation and signing --------------------------------------- openssl req -new -keyout key.pem -out req.pem -newkey rsa:2048 -nodes openssl ca -policy policy_anything -out cert.pem -in req.pem Now copy cert.pem and key.pem on the server, and cacert.pem on the server and the client (may be the same machine) and change appropriately the values of TLSCertificateFile, TLSCertificateKeyFile and TLSCACertificateFile in the server configuration, and TLS_CACERT in the client configuration. Start the server with /usr/sbin/slapd -h ldaps:/// -u ldap -d 1 Then on the client use: ldapsearch -x -d1 On the server side you should see something like this: TLS: loaded CA certificate file /etc/openldap/cacerts/cacert.pem. TLS: certificate [E=admin(a)my.domain,CN=server.fqdn,OU=Sezione di Padova,O=INFN,L=Padova ,ST=Italia,C=IT] is valid TLS: error: accept - force handshake failure: errno 21 - moznss error -12271 TLS: can't accept: TLS error -12271:Unknown code ___P 17. connection_read(11): TLS accept failure error=-1 id=1000, closing connection_close: conn=1000 sd=11 And on the client side: TLS: loaded CA certificate file /etc/openldap/cacerts/cacert.pem. TLS: certificate [E=admin(a)my.domain,CN=server.fqdn,OU=Sezione di Padova,O=INFN,L=Padova,ST=Italia,C=IT] is not valid - error -8182:Unknown code ___f 10. TLS: error: connect - force handshake failure: errno 21 - moznss error -8182 TLS: can't connect: TLS error -8182:Unknown code ___f 10. ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Note that server says: certificate is valid but SSL peer cannot verify it (moznss error -12271: SSL_ERROR_BAD_CERT_ALERT) On the other side the client says: certificate is not valid because has an invalid signature (moznss error -8182: SEC_ERROR_BAD_SIGNATURE) As I said above, the problem disappears recompiling openldap with OpenSSL instead of MozNSS.

1 0

Re: (ITS#6900) dnattr acl statement: users can produce dangling entries
by daniel＠pluta.biz 14 Oct '11

14 Oct '11

Hi Howard, as we've discussed during LDAPCon2011's get-together the following idea is currently not supported in slapd. For demonstration purposes I've introduced a <dnattrstyle> that only supports one style-descriptor called ".strict". It restricts "dnattr=..." ACL statements the way that self is not allowed to remove her own DN from dnattr. I've tested the patch with the following simple sample ACLs: to dn.base="ou=groups,dc=foo,dc=bar" attrs=children by users write to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,@groupOfNames by dnattr.strict=owner write by users read According these two ACLs a group's owner is allowed to write the whole object (not only add, but also delete, aka in sum "write"). Nevertheless, because of the ".strict" the owner is not able to delete his own DN from the owner attribute. You can find an updated version of my patch here: ftp://ftp.openldap.org/incoming/Daniel-Pluta-111014.patch As it is still intended for demonstration purposes, the patch is highly probable suboptimal regarding its implementation, in particular regarding the chosen place within slapd's code. Instead of the <dnattrstyle> probably a new "<access>" called e.g. "writeToSelfButSelfNoDelete" or similar should be introduced instead. Unfortunately, I don't know how to code this correctly without changing/breaking the whole acl-engine and introducing various "funny" side-effects. Best regards Daniel P.S. Furthermore, and although I've no related scenario in mind, it perhaps could make sense to generalize this kind of behaviour also into direction to "writeToSelfButSelfNoAdd" etc. I'm not sure whether this would make sense, too.

1 0

(ITS#7063) OpenLDAP don't provide some schema file in ldif format
by raphael.ouazana＠linagora.com 12 Oct '11

12 Oct '11

Full_Name: Raphael Ouazana Version: 2.4.26 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.232.151) Hi, Some schema files are missing from schema/ directory: collective.ldif corba.ldif duaconf.ldif java.ldif misc.ldif pmi.ldif ppolicy.ldif Regards, Raphaël Ouazana.

1 0

(ITS#7062) writes from lost connections not increasing contextCSN
by ebackes＠symas.com 11 Oct '11

11 Oct '11

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 can be seen without replicas being involved, but obviously still needs syncprov. $ ldapadd -x -D dc=example,dc=com -w secret -H ldap://localhost:1389/ -f people.ldif adding new entry "cn=1,ou=people,dc=example,dc=com" adding new entry "cn=2,ou=people,dc=example,dc=com" ... adding new entry "cn=22,ou=people,dc=example,dc=com" ^C $ ldapsearch -x -D dc=example,dc=com -w secret -H ldap://localhost:1389/ -b dc=example,dc=com -LLL '(cn=22)' entryCSN dn: cn=22,ou=people,dc=example,dc=com entryCSN: 20111011235653.469937Z#000000#001#000000 $ ldapsearch -x -D dc=example,dc=com -w secret -H ldap://localhost:1389/ -b dc=example,dc=com -LLL -s base contextCSN dn: dc=example,dc=com contextCSN: 20111011235653.380889Z#000000#001#000000 stats+sync log: conn=1000 op=21 ADD dn="cn=21,ou=people,dc=example,dc=com" slap_queue_csn: queing 0x105e00100 20111011235653.380889Z#000000#001#000000 conn=1000 op=21 RESULT tag=105 err=0 text= slap_graduate_commit_csn: removing 0x10178e0a0 20111011235653.380889Z#000000#001#000000 conn=1000 op=22 ADD dn="cn=22,ou=people,dc=example,dc=com" slap_queue_csn: queing 0x105e00100 20111011235653.469937Z#000000#001#000000 slap_graduate_commit_csn: removing 0x10178e520 20111011235653.469937Z#000000#001#000000 conn=1000 fd=10 closed (connection lost) The change isn't sent out to connected refreshAndPersist replicas either, and forcing them to reconnect doesn't help, as their contextCSNs still match across the board. This can cause persistent desynchronization of servers.

1 0

Re: (ITS#6924) www.openldap.org and git.openldap.org serve different repositories
by ondra＠mistotebe.net 11 Oct '11

11 Oct '11

Note that openldap.git is not the only repository serving different history, e.g.: ---------------- 8< ---------------- $ git clone http://www.openldap.org/software/repo/openldap-jldap.git openldap-jldap.http $ cd openldap-jldap.http $ git log -1 commit 07fc2a4b6f20dfb3a171ee0fa4b66082358b8b53 Author: Nachiappan Palaniappan <npalani(a)openldap.org> Date: Mon Jul 6 08:43:38 2009 +0000 Updated version to 4.6. ---------------- 8< ---------------- Compare it to: ---------------- 8< ---------------- $ git clone git://git.openldap.org/openldap-jldap.git openldap-jldap.git $ cd openldap-jldap.git $ git log -1 commit bae9f556e97ad5bb0f76fe897c9b298a6021e244 Date: Mon Jul 6 08:43:38 2009 +0000 Updated version to 4.6. ---------------- 8< ---------------- Cheers, Ondrej Kuznik

1 0

(ITS#7061) Only return requested attrs in sssvlv response
by ctcard＠hotmail.com 11 Oct '11

11 Oct '11

Full_Name: Chris Card Version: 2.4.26 + patch OS: Centos 5.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.194.158.133) There was a fix put into master on 18 Jul 2011 with subject "Only return requested attrs in sssvlv response" SHA: 8eecc9a017584ea0b56b25f0e4750e3b16929de6. I have patched openldap 2.4.26 with all the fixes to sssvlv.c, but there is still an issue with the attributes returned in an sssvlv response. On the first sssvlv request only the requested attributes are returned, but on subsequent sssvlv requests using the vlv context returned by the first requests, all the attributes are returned.

1 0

(ITS#7060) Bad compare results with back-sock (and I suspect back-shell)
by maurice＠perry.ch 09 Oct '11

09 Oct '11

Full_Name: Maurice Perry Version: 2.4.26 OS: Linux (debian) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (160.53.250.126) The result code returned for the COMPARE operation with back-sock. The problem is due to a bug (two actually) in function str2result in servers/slapd/result.c: while ( isspace( (unsigned char) next[ 0 ] ) ) next++; if ( next[ 0 ] != '\0' ) { Debug( LDAP_DEBUG_ANY, "str2result (%s) extra cruft after value\n", s, 0, 0 ); rc = -1; continue; } /* FIXME: what if it's larger that max int? */ *code = (int)retcode; The code is not set properly if the code is not the last line of the result. I corrected the issue as follows: while ( isspace( (unsigned char) next[ 0 ] ) && next[ 0 ] != '\n' ) next++; if ( next[ 0 ] != '\0' && next[ 0 ] != '\n' ) { Debug( LDAP_DEBUG_ANY, "str2result (%s) extra cruft after value\n", s, 0, 0 ); rc = -1; continue; } /* FIXME: what if it's larger that max int? */ *code = (int)retcode;

1 0

(ITS#7059) UTF8StringNormalize will overrun a zero-length value
by hyc＠OpenLDAP.org 06 Oct '11

06 Oct '11

Full_Name: Howard Chu Version: 2.4.x OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc According to the commit history this bug has been present since 2003-04-07 (commit 67d6b23d). A patch is in git master, but I'm continuing to investigate and will update it further.

1 0

Re: (ITS#6979) test062 portability
by richton＠nbcs.rutgers.edu 04 Oct '11

04 Oct '11

On Fri, 30 Sep 2011, Hallvard B Furuseth wrote: > I'm curious, what is this about - an observed bug, or not? There is > no function call here, 'wait' is checking a subprocess's exit status. > That's standard, and so is checking the return (not exit) status from > a function as far as I know, but I'm not surprised if some shells have > quirks. At the time I actually saw this on Solaris /bin/sh. I'll hopefully pull down a fresh copy and re-examine in a few days (I'm a bit backlogged at the moment trying to cram things in before I head to LDAPCon).

1 0

(ITS#7055) pwcheck Module for slapo-ppolicy
by lukas.graesslin＠collax.com 01 Oct '11

01 Oct '11

Full_Name: Lukas Grässlin Version: Latest Git OS: Arch Linux URL: http://dl.dropbox.com/u/32193848/src/0001-Added-pwcheck-module-for-the-slap… Submission from: (NULL) (88.67.244.45) Hi there, I wrote a new pwcheck module for the slapo-ppolicy overlay which is able to handle multiple different policies. My problem was: I have multiple password policies which are applied to different users. The policies differ in strength etc. The problem was that with the only pwcheck modul you can find on the net (https://ltb-project.org/svn/openldap-ppolicy-check-password/trunk/) you just define one 'policy-thing' which will be checked if check-password.so is run. I wanted to have something were you also can define multiple policies which also can differ, so I wrote my own module which reads two config files: $CONFDIR/ppolicies: There are the policies defined. Example: [Default] min_len = 8 min_digit = 1 min_lower = 1 min_special = 1 min_upper = 1 $CONFDIR/users: These file holds the relation between users and policies: uid=lukas,ou=People,dc=example,dc=com : Default Well, it would have been nicer if that policy definition & co would also be stored in ldap, but the config-file-way was the faster one as it had to be finished quick. Whatever, maybe some of you could need this or improve it.

1 0

RE: (ITS#7051) ldap_pvt_tls_get_peer_dn fails under gnutls
by Giampaolo＠Tomassoni.biz 30 Sep '11

30 Sep '11

> > This is the needed patch: > > This patch should not work either, you still need a skip_tag before the > get_int. > > > - tag = ber_skip_tag( ber,&len ); /* Context + > Constructed > > (version) */ > > + tag = ber_peek_tag( ber,&len ); /* Context + > Constructed I confirm this patch worked for me, at least it did on an amd64 I'm working on. It worked both with openssl-generated v1 (no version tag present) and v3 certificates (version tag present). I don't know if this is an cpu-architecture -dependent issue (I don't think so), nor I know how the ber_* library works, but FWICU the Context + Constructed stuff is handled as a tag prefix by the ber_get_int(), which then discards it when found and fetches the encapsulated value. Instead, ber_peek_tag() is probably more simple-minded in that it peeks the first word at the buffer pointer, which is the Context + Constructed prefix, not really the tag. I can of course be wrong, but with this patch I got i==2 from v3 certificates, which is the correct value. Giampaolo

1 0

Re: (ITS#6979) test062 portability
by h.b.furuseth＠usit.uio.no 30 Sep '11

30 Sep '11

Aaron Richton writes: > It looks like checking the function exit isn't portable; maybe some > kind of bash-ism. It looks like the code was on the path to > communicating the retval via $RCOUT file already? I'm curious, what is this about - an observed bug, or not? There is no function call here, 'wait' is checking a subprocess's exit status. That's standard, and so is checking the return (not exit) status from a function as far as I know, but I'm not surprised if some shells have quirks. I noticed because I saw the patch entering master. Which is fine by me, except the patch may be a bit incomplete. Since $SEARCHRC is now the output from `cat`, it may be best to quote it here: > if test $SEARCHRC != 52 ; then -- Hallvard

1 0

Re: (ITS#7006) openldap does not accept wildcard certificates with mozilla/nss
by hyc＠symas.com 30 Sep '11

30 Sep '11

hash_oldap(a)cycdolphin.net wrote: > Full_Name: Philippe Kueck > Version: 2.4.23 / 2.4.26 > OS: RHEL 6.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.98.65.86) > > > When compiled against Mozilla/NSS OpenLDAP does not accept wildcard > certificates. > > This is probably because in tls_m.c the certificate CN (*.domain.example) is > matched against the hostname (foo.domain.example), not against the domain > (.domain.example). > > I suggest the following patch: Thanks for the report, fixed in master. > > --%snip%-- > diff -Nru openldap-2.4.26-orig/libraries/libldap/tls_m.c > openldap-2.4.26/libraries/libldap/tls_m.c > --- openldap-2.4.26-orig/libraries/libldap/tls_m.c 2011-06-30 17:13:36.000000000 > +0200 > +++ openldap-2.4.26/libraries/libldap/tls_m.c 2011-08-01 16:29:42.000000000 > +0200 > @@ -2590,7 +2590,7 @@ > if ( av->len == nlen&& !strncasecmp( name, (char *)av->data, nlen )) { > ret = LDAP_SUCCESS; > } else if ( av->data[0] == '*'&& av->data[1] == '.'&& > - domain&& dlen == av->len - 1&& !strncasecmp( name, > + domain&& dlen == av->len - 1&& !strncasecmp( domain, > (char *)(av->data+1), dlen )) { > ret = LDAP_SUCCESS; > } else { > --%snip%-- > > > Kind regards, > > Philippe Kueck > > -- -- 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#7011) signal 6 got in ldap_abandon
by hyc＠symas.com 30 Sep '11

30 Sep '11

ogermain(a)tibco.com wrote: > Full_Name: Olivier GERMAIN > Version: 2.4.24 > OS: Solaris 5.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.157.248.2) > > > Dear All, > > One of our customer got a signal 6 during the execution of the ldap_abandon. > This signal occurred whereas some maintenance was doing on a firewall which is > not located on the same network. It seems that the ldap_abandon thrown this > assert because it was a situation like a can't happen. I don't have much > information on the action performed on the firewall which led to this sigabort. > > > Please find the logs I have : > 2011-07-19 04:08:52.876909|ENG|FATAL|84|engine.cpp(109)| > /appl/kabira/MIPSPLUS-1.5.1-110510-SOL64/kis/distrib/kabira/lib/libsyssrv.so:sw_debugSignalHandler+0x18 > 2011-07-19 04:08:52.877541|ENG|FATAL|84|engine.cpp(109)| > /lib/sparcv9/libc.so.1:<static-func>+0x5b0 > 2011-07-19 04:08:52.878082|ENG|FATAL|84|engine.cpp(109)| > /lib/sparcv9/libc.so.1:<static-func>+0x628 > 2011-07-19 04:08:52.878658|ENG|FATAL|84|engine.cpp(109)| > /lib/sparcv9/libc.so.1:_lwp_kill+0x8 [ Signal 6 (SIGABRT) ] > 2011-07-19 04:08:52.879196|ENG|FATAL|84|engine.cpp(109)| > /lib/sparcv9/libc.so.1:abort+0xd0 > 2011-07-19 04:08:52.879733|ENG|FATAL|84|engine.cpp(109)| > /lib/sparcv9/libc.so.1:_assert+0x74 > 2011-07-19 04:08:52.880325|ENG|FATAL|84|engine.cpp(109)| > /appl/kabira/MIPSPLUS-1.5.1-110510-SOL64/kis/3rdparty/sol/openldap/2.4.24_64/lib/libldap-2.4.so.2.6.0:<static-func>+0x4ec > 2011-07-19 04:08:52.880776|ENG|FATAL|84|engine.cpp(109)| > /appl/kabira/MIPSPLUS-1.5.1-110510-SOL64/kis/3rdparty/sol/openldap/2.4.24_64/lib/libldap-2.4.so.2.6.0:ldap_abandon+0xac > > I am in the process of a reproduction of this signal 6 but I would like to share > the following idea. > > Do you think there is a possibility to enhance the openldap library to avoid > this assert? Is it possible that instead of having an assert, we have a > exception or a status code which tell us something went wrong of obviously that > we can handle in our source code. An assert means there is a bug, either in your code or ours. Since this part of the library has been around for several years with no issues, that generally means it's a bug in your code. The way to handle this is to fix your code. Trapping or ignoring the conditions that are asserted is just a bad idea. > > My best regards > Olivier GERMAIN > TIBCO Support team > > -- -- 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#7040) Out of sync consumer replicas after standby master takes over (MMR)
by Howard Chu 30 Sep '11

30 Sep '11

Thanks for the report. Now fixed in master.

1 0

Re: (ITS#7037) slapd crashes with syncrepl when replica cleared out DB
by hyc＠symas.com 30 Sep '11

30 Sep '11

ml+openldap(a)esmtp.org wrote: > Full_Name: Claus Assmann > Version: 2.4.26 > OS: Red Hat Enterprise Linux Server release 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.211.143.38) > > > While trying to determine how syncrepl behaves in various error > conditions, I encountered a crash of slapd. A MASTER is set up to > use push replication to a REPLICA as follows: > > database ldap > hidden on > suffix "" > rootdn "cn=slapd-ldap" > uri ldap://REPLICA/ > lastmod on > restrict all > sync_use_subentry true > > acl-bind bindmethod=simple > binddn="cn=Monitor" > credentials=password > > syncrepl rid=001 > provider=ldapi://%2Fvar%2Frun%2Fldapi > binddn="cn=Manager" > bindmethod=simple > credentials=passwd > searchbase="" > type=refreshAndPersist > retry="5 5 60 +" > > Reproduce: > On REPLICA: stop slapd, clear out directory for DB, start > slapd. > On MASTER: > add an entry master which has to be "synced" to REPLICA; > run ldapsearch to lookup up that entry on MASTER > slapd dumps core, backtrace: Thanks for the report. There were two bugs here: 1) the syncrepl_add_glue_ancestors was not constructing a valid DN for the empty-suffix case. 2) it shouldn't have tried to add glue entries in this case anyway, since the underlying DB was pulled out from under it. Both fixed now in master, please test. > #0 0x00002b7e51344265 in raise () from /lib64/libc.so.6 > #1 0x00002b7e51345d10 in abort () from /lib64/libc.so.6 > #2 0x00002b7e5133d6e6 in __assert_fail () from /lib64/libc.so.6 > #3 0x0000000000549546 in ldap_add_ext (ld=0xbba1bc0, dn=0x0, attrs=0xbeb7ed0, > sctrls=0x0, cctrls=0x0, msgidp=0x435224c4) at add.c:126 > #4 0x00000000004dbe6d in ldap_back_add (op=0x43523150, rs=0x43522770) > at add.c:102 > #5 0x0000000000481152 in overlay_op_walk (op=0x43523150, rs=0x43522770, > which=op_add, oi=0xb9eb6c0, on=0x0) at backover.c:671 > #6 0x00000000004816a7 in over_op_func (op=0x43523150, rs=0x43522770, > which=op_add) at backover.c:723 > #7 0x0000000000473706 in syncrepl_add_glue_ancestors (op=0x43523150, > e=0x2b7e56628fb8) at syncrepl.c:3149 > #8 0x000000000047384e in syncrepl_add_glue (op=0x43523150, e=0x2b7e56628fb8) > at syncrepl.c:3193 > #9 0x0000000000474795 in syncrepl_entry (si=0xb9eb1c0, op=0x43523150, > entry=0x0, modlist=0x43523ca0, syncstate=<value optimized out>, > syncUUID=<value optimized out>, syncCSN=0xbeb86e0) at syncrepl.c:2448 > #10 0x000000000047c39b in do_syncrep2 (ctx=<value optimized out>, > arg=<value optimized out>) at syncrepl.c:982 > #11 do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>) > at syncrepl.c:1489 > #12 0x000000000041eee3 in connection_read_thread (ctx=0x43523da0, > argv=<value optimized out>) at connection.c:1276 > #13 0x00000000005412dc in ldap_int_thread_pool_wrapper (xpool=0xb8fa1c0) > at tpool.c:685 > #14 0x00002b7e510ff73d in start_thread () from /lib64/libpthread.so.0 > #15 0x00002b7e513e84bd in clone () from /lib64/libc.so.6 > > Note: this also happens with 2.4.23. On a VM instance, it causes > a different error (see mail on list: "killed after 120 seconds") > > -- -- 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#7051) ldap_pvt_tls_get_peer_dn fails under gnutls
by hyc＠symas.com 30 Sep '11

30 Sep '11

giampaolo(a)tomassoni.biz wrote: > Full_Name: Giampaolo Tomassoni > Version: 2.4.24 > OS: Linux 2.6.39-gentoo-r3 > URL: > Submission from: (NULL) (79.23.61.128) > > > A triky mistake (is it a typo?) in libraries/libldap/tls_g.c:tlsg_x509_cert_dn > prevents a gnutls-enabled server to correctly obtain the "subject" ASN.1 tree > from the client's certificate. Thanks for the report, now fixed in master, please test. > > This is the needed patch: This patch should not work either, you still need a skip_tag before the get_int. > --- libraries/libldap/tls_g.c.wrong 2011-09-25 14:58:30.000000000 +0200 > +++ libraries/libldap/tls_g.c 2011-09-25 14:35:06.000000000 +0200 > @@ -530,7 +530,7 @@ > ber_init2( ber, cert, LBER_USE_DER ); > tag = ber_skip_tag( ber,&len ); /* Sequence */ > tag = ber_skip_tag( ber,&len ); /* Sequence */ > - tag = ber_skip_tag( ber,&len ); /* Context + Constructed > (version) */ > + tag = ber_peek_tag( ber,&len ); /* Context + Constructed > (version) */ > if ( tag == 0xa0 ) /* Version is optional */ > tag = ber_get_int( ber,&i ); /* Int: Version */ > tag = ber_skip_tag( ber,&len ); /* Int: Serial (can be longer > than ber_int_t) */ > > > Basically, the optional version field in the certificate wasn't peeked, but > rather skipped. This resulted in walking in the certificate tree in the wrong > way, thereby impairing a correct result from > libraries/libldap/tls2.c:ldap_pvt_tls_get_peer_dn. > > I'm not using sasl, so I can't be sure about this, but I guess this problem > could impair client authentication via certificate using the sasl external > method. > > -- -- 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#7052) Spurious CSNs being recorded on syncrepl consumers.
by hyc＠symas.com 30 Sep '11

30 Sep '11

cmikk(a)qwest.net wrote: > Full_Name: Chris Mikkelson > Version: 2.4.26 > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (204.147.85.37) > > > When the provider sends a search response with state 'delete' with no / null > cookie, the syncrepl consumer queues an locally-generated CSN and updates its > context CSN with that. This appears to happen only with cookie-less deletion, > not with cookie-less modification. I have not observed a cookie-less addition, > so I do not know if it occurs there, too. Thanks for the report. The bug only affected Deletes, not add or modify. Fixed in master. > Example logs from a pure consumer (no server-id, replicating from a provider > with server id 002): > > Sep 26 13:05:42 mpls-auth-02 slapd[57295]: do_syncrep2: rid=100 cookie= > Sep 26 13:05:42 mpls-auth-02 slapd[57295]: syncrepl_entry: rid=100 > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_DELETE) > Sep 26 13:05:42 mpls-auth-02 slapd[57295]: syncrepl_entry: rid=100 be_search > (0) > Sep 26 13:05:42 mpls-auth-02 slapd[57295]: syncrepl_entry: rid=100 > uid=<snip>,ou=improv,dc=qwest,dc=net > Sep 26 13:05:42 mpls-auth-02 slapd[57295]: slap_queue_csn: queing 0x7ffffe3fa560 > 20110926130542.130924Z#000000#000#000000 > Sep 26 13:05:42 mpls-auth-02 slapd[57295]: slap_graduate_commit_csn: removing > 0x8f58a8a90 20110926130542.130924Z#000000#000#000000 > > This is problematic at our site because the provider cookie contains a SID 0 CSN > from before we migrated to multimaster, and the SID 0 CSN recorded at the > consumer renders the consumer state newer than the provider, breaking > replication. > > -- -- 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#7054) Please drop support to FreeBSD 1.x
by d＠delphij.net 28 Sep '11

28 Sep '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Kurt, On 09/28/11 18:26, Kurt Zeilenga wrote: > Given the project doesn't specifically attempt to support FreeBSD > 1.x, your request as summarized in the subject line is a bit odd. > > I suggest this be considered more of a request to enable future > support of the FreeBSD 10.x. > > Do the current release of libtool and autotools includes the > enabling features needed? > > If so, then this can simply be treated as a request to update these > tools (which are generally incorporated without any functional > change). > > If not, well, then we should just wait for thsoe enabling changes > to be released by the upstream tool provider first I think we will have to wait for upstream release then, the changes are already in their source tree. I'll patch OpenLDAP in the FreeBSD ports to make it work at this moment. > Regards, Kurt > > On Sep 28, 2011, at 2:38 PM, delphij(a)FreeBSD.org wrote: > >> Full_Name: Xin Li Version: git trunk OS: FreeBSD/amd64 10.1 URL: >> http://pastebin.com/G8gpJs0r Submission from: (NULL) >> (206.40.55.65) >> >> >> Code duplicated from GNU libtool and autotools uses 'freebsd1*' >> rather than 'freebsd1.*' to test if the system is FreeBSD 1.x. >> This logic would match FreeBSD 10.0, causing problem when >> building shared libraries. >> >> I'd like to propose that FreeBSD 1.x support be dropped since >> it's obsolete in 1994 (17 years ago). >> >> The patch is just for reference, it also drops FreeBSD 2.x and >> FreeBSD 3.x support but it's not complete. >> >> A libtool patched with git revision >> e94c6d6e0359d92f08f491f57e0ef3371e978952 would also be required >> to build OpenLDAP properly. >> > - -- Xin LI <delphij(a)delphij.net> https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOg87cAAoJEATO+BI/yjfBfwIIAIjdABO2EUPVNpGLRrOqt20I Yl5reH+OsBBwRTgjdDflZJcRA68fb5nsdsrRBheJA6oT0EJKWpPoW+uLjg84zx6s TvGAifKMDJv6+v/PHpTkv2wO7nYIKXiS6D9415cJk3xMdEcDdRSXi+ppA+6IXGzV fRL4rej0hoHNvgbXvowOL8F24rnnb6+r9fYYH773rwomL/+rYqZ1+iDbM4zs82d4 TSxOtjmfoEqUCyYJii3jo5CGs1LQ+Ndk16s7uwTArevba89GPVrNL3s/FxBLrEX+ Q8mBHaCkmsX1JuN7ZkYTJz7UvMJJO25IHDfEpjkM5aCqZvuy9nq7kflXxvuOASo= =Wmav -----END PGP SIGNATURE-----

1 0

Re: (ITS#7054) Please drop support to FreeBSD 1.x
by hyc＠symas.com 28 Sep '11

28 Sep '11

delphij(a)FreeBSD.org wrote: > Full_Name: Xin Li > Version: git trunk > OS: FreeBSD/amd64 10.1 > URL: http://pastebin.com/G8gpJs0r > Submission from: (NULL) (206.40.55.65) > > > Code duplicated from GNU libtool and autotools uses 'freebsd1*' rather than > 'freebsd1.*' to test if the system is FreeBSD 1.x. This logic would match > FreeBSD 10.0, causing problem when building shared libraries. > > I'd like to propose that FreeBSD 1.x support be dropped since it's obsolete in > 1994 (17 years ago). Probably a good idea. Thanks for the patch, but it's basically unusable. Never submit patches to generated files. Only patch the source files. configure is generated from configure.in by autoconf. aclocal.m4 is also generated by autoconf; the section you patched appears to come from the libtool sources. > The patch is just for reference, it also drops FreeBSD 2.x and FreeBSD 3.x > support but it's not complete. > > A libtool patched with git revision e94c6d6e0359d92f08f491f57e0ef3371e978952 > would also be required to build OpenLDAP properly. > > -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs