- openldap-bugs - openldap.org

(ITS#5519) Compilation fails when linking with ldap threading symbols
by fredme＠gmail.com 19 May '08

19 May '08

Full_Name: Eugenio Grytsenko Version: 2.4.9 OS: Suse Linux Enterprise Server 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.5.92.164) Ldap compilation fails when I am trying to compile with-threads and back_shell enabled. Here is the trace: ============ CUT HERE ============ creating .libs/slapdS.c (cd .libs && cc -c -fno-builtin "slapdS.c") rm -f .libs/slapdS.c .libs/slapd.nm .libs/slapd.nmS .libs/slapd.nmT cc -g -O2 .libs/slapdS.o -o .libs/slapd main.o globals.o bconfig.o config.o daemon.o connection.o search.o filter.o add.o cr.o attr.o entry.o backend.o backends.o result.o operation.o dn.o compare.o modify.o delete.o modrdn.o ch_malloc.o value.o ava.o bind.o unbind.o abandon.o filterentry.o phonetic.o acl.o str2filter.o aclparse.o init.o user.o lock.o controls.o extended.o passwd.o schema.o schema_check.o schema_init.o schema_prep.o schemaparse.o ad.o at.o mr.o syntax.o oc.o saslauthz.o oidm.o starttls.o index.o sets.o referral.o root_dse.o sasl.o module.o mra.o mods.o sl_malloc.o zn_malloc.o limits.o operational.o matchedValues.o cancel.o syncrepl.o backglue.o backover.o ctxcsn.o ldapsync.o frontend.o slapadd.o slapcat.o slapcommon.o slapdn.o slapindex.o slappasswd.o slaptest.o slapauth.o slapacl.o component.o aci.o alock.o txn.o version.o -rdynamic -Wl,-rpath -Wl,/usr/lib/perl5/5.8.3/x86_64-linux-thread-multi/CORE -Wl,--export-dynamic libbackends.a liboverlays.a ../../libraries/liblunicode/liblunicode.a ../../libraries/librewrite/librewrite.a ../../libraries/liblutil/liblutil.a ../../libraries/libldap_r/.libs/libldap_r.so /root/fred/ldap24/openldap-2.4.9/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so /usr/lib64/libdb-4.2.so -L/usr/local/lib64 /usr/lib/perl5/5.8.3/x86_64-linux-thread-multi/auto/DynaLoader/DynaLoader.a -L/usr/lib/perl5/5.8.3/x86_64-linux-thread-multi/CORE -lperl /usr/lib64/libodbc.so -lpthread /usr/lib64/libslp.so -lm -lnsl /usr/lib64/libsasl2.so -lssl -lcrypto -lcrypt -lresolv libslapi.a /usr/lib64/libltdl.so -ldl -lwrap daemon.o(.text+0xe3f): In function `slap_listener_thread': /root/fred/ldap24/openldap-2.4.9/servers/slapd/daemon.c:1824: warning: `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead daemon.o(.text+0xe2e):/root/fred/ldap24/openldap-2.4.9/servers/slapd/daemon.c:1824: warning: `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead result.o(.text+0x12cd): In function `slap_send_search_entry': /root/fred/ldap24/openldap-2.4.9/servers/slapd/result.c:1042: undefined reference to `ldap_pvt_thread_pool_pausing' syncrepl.o(.text+0x6bd5): In function `do_syncrep2': /root/fred/ldap24/openldap-2.4.9/servers/slapd/syncrepl.c:1140: undefined reference to `ldap_pvt_thread_pool_pausing' syncrepl.o(.text+0x6d2c):/root/fred/ldap24/openldap-2.4.9/servers/slapd/syncrepl.c:1140: undefined reference to `ldap_pvt_thread_pool_pausing' liboverlays.a(syncprov.o)(.text+0x4e2d): In function `syncprov_op_mod': /root/fred/ldap24/openldap-2.4.9/servers/slapd/overlays/syncprov.c:1809: undefined reference to `ldap_pvt_thread_pool_pausecheck' collect2: ld returned 1 exit status make[2]: *** [slapd] Error 1 make[2]: Leaving directory `/root/fred/ldap24/openldap-2.4.9/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/root/fred/ldap24/openldap-2.4.9/servers' make: *** [all-common] Error 1 ============ CUT HERE ============ OS I am using: Suse Linux Enterprise Server 9 GCC version string: Reading specs from /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/specs Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada --disable-checking --libdir=/usr/lib64 --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit x86_64-suse-linux Thread model: posix gcc version 3.3.3 (SuSE Linux) My machine architecture: x86_64 My Kernel: Linux cs9 2.6.16.27-0.9-xen #1 SMP Tue Feb 13 09:35:18 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux My OpenLDAP configure command: ./configure \ --prefix=/usr \ --exec-prefix=/usr \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --libexecdir=/usr/lib64 \ --datadir=/usr/share \ --sysconfdir=/etc \ --sharedstatedir=/usr/share/com \ --localstatedir=/var/run/slapd \ --libdir=/usr/lib64 \ --includedir=/usr/include \ --oldincludedir=/usr/include \ --infodir=/usr/share/info \ --mandir=/usr/share/man \ --enable-debug \ --enable-dynamic \ --enable-syslog \ --enable-proctitle \ --enable-ipv6 \ --enable-local \ --enable-slapd \ --enable-dynacl \ --enable-aci \ --enable-cleartext \ --enable-crypt \ --enable-lmpasswd \ --enable-spasswd \ --enable-modules \ --enable-rewrite \ --enable-rlookups \ --enable-slapi \ --enable-slp \ --enable-wrappers \ --enable-backends \ --enable-bdb \ --enable-dnssrv \ --enable-hdb \ --enable-ldap \ --enable-meta \ --enable-monitor \ --enable-null \ --enable-passwd \ --enable-perl \ --enable-relay \ --enable-shell \ --enable-sock \ --enable-sql \ --enable-overlays \ --enable-accesslog \ --enable-auditlog \ --enable-constraint \ --enable-dds \ --enable-dyngroup \ --enable-dynlist \ --enable-memberof \ --enable-ppolicy \ --enable-proxycache \ --enable-refint \ --enable-retcode \ --enable-rwm \ --enable-seqmod \ --enable-syncprov \ --enable-translucent \ --enable-unique \ --enable-valsort \ --enable-static \ --enable-shared \ --enable-fast-install \ --with-cyrus-sasl \ --without-threads \ --with-tls \ --with-yielding-select \ --with-mp \ --with-odbc=unixodbc \ --with-gnu-ld \ --with-pic Thanks.

1 0

Re: (ITS#5515) v2.4.9 + GnuTLS fails with wildcard certificate, OpenSSL works correctly
by quanah＠zimbra.com 19 May '08

19 May '08

--On Sunday, May 18, 2008 6:24 AM +0000 hyc(a)symas.com wrote: > bgoldsbury(a)gleim.com wrote: >> Full_Name: Ben Goldsbury >> Version: 2.4.9 >> OS: Debian >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (209.208.68.2) >> >> >> When OpenLDAP 2.4.9 is compiled against GnuTLS (version 2.2.1 in my >> testing) and using a valid Wildcard SSL certificate, TLS connections to >> OpenLDAP fail with: >> >> TLS certificate verification: Error, unable to get local issuer >> certificate User verifies that this is a GnuTLS bug, this ITS will be closed. See last follow up in: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477396> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5518) Assertion error in io.c:234: ber_flush2
by zulcss＠ubuntu.com 19 May '08

19 May '08

Full_Name: Chuck Short Version: 2.4.7 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.142.121.161) We are getting assertion errors in libraries/liblber/io.c. The original bug report is located at the following: http://bugs.launchpad.net/bugs/215904 Thanks chuck

1 0

(ITS#5517) add superclass of existing class fails
by h.b.furuseth＠usit.uio.no 18 May '08

18 May '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard If objectclass B is a subclass of A, and an entry contains objectclass B but not A, slapd returns attributeOrValueExists to a request to add A. OTOH it allows replace(objectClass: <A, B>), and after that it allows delete(objectClass: A). This is inconsistent. If the objectClass attribute contains B, does it "really" contain A as well? I couldn't find such a statement in the RFCs, so my guess is that add(objectClass: A) should be allowed. Though I haven't looked all that hard. Example: ldapadd -cx <<'EOF' # Create initial object dn: c=NO objectClass: friendlyCountry c: NO co: Norway # error dn: c=NO changetype: modify add: objectClass objectClass: top - # error dn: c=NO changetype: modify add: objectClass objectClass: country - # success dn: c=NO changetype: modify replace: objectClass objectClass: top objectClass: country objectClass: friendlyCountry - # success dn: c=NO changetype: modify delete: objectClass objectClass: top - # success dn: c=NO changetype: modify delete: objectClass objectClass: country - EOF

1 0

Re: (ITS#5515) v2.4.9 + GnuTLS fails with wildcard certificate, OpenSSL works correctly
by bpgoldsb＠gleim.com 18 May '08

18 May '08

We're using *.domain.tld in the CN and subjectAltName:DNS:*.domain.tld This may be a GnuTLS issue, as I am able to reproduce it with the GnuTLS server/client testing tools. On Sat, 2008-05-17 at 23:23 -0700, Howard Chu wrote: > bgoldsbury(a)gleim.com wrote: > > Full_Name: Ben Goldsbury > > Version: 2.4.9 > > OS: Debian > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (209.208.68.2) > > > > > > When OpenLDAP 2.4.9 is compiled against GnuTLS (version 2.2.1 in my testing) and > > using a valid Wildcard SSL certificate, TLS connections to OpenLDAP fail with: > > > > TLS certificate verification: Error, unable to get local issuer certificate > > > > When OpenLDAP 2.4.9 is compiled against OpenSSL (version 0.9.8c in my testing) > > and using the same certificate, connections work properly. > > > > Please contact me if you need any additional information. > > This sounds an awful lot like ITS#5361, which is a known defect in GnuTLS. > > What exactly do you mean by "Wildcard SSL certificate" ? There are a couple > different approaches to that. One uses the subjectAltName extension, and that > is the officially sanctioned approach. One uses "*" in the certificate CN, and > that is non-standard and generally not supposed to work.

1 0

Re: (ITS#5513) back-ldap+ppolicy bind assertion failure
by ando＠sys-net.it 18 May '08

18 May '08

mbackes(a)symas.com wrote: > Thanks; this seems to fix the issue, at least in my test cases. OK, I've applied the fix to re23/re24 as well. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5515) v2.4.9 + GnuTLS fails with wildcard certificate, OpenSSL works correctly
by hyc＠symas.com 17 May '08

17 May '08

bgoldsbury(a)gleim.com wrote: > Full_Name: Ben Goldsbury > Version: 2.4.9 > OS: Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.208.68.2) > > > When OpenLDAP 2.4.9 is compiled against GnuTLS (version 2.2.1 in my testing) and > using a valid Wildcard SSL certificate, TLS connections to OpenLDAP fail with: > > TLS certificate verification: Error, unable to get local issuer certificate > > When OpenLDAP 2.4.9 is compiled against OpenSSL (version 0.9.8c in my testing) > and using the same certificate, connections work properly. > > Please contact me if you need any additional information. This sounds an awful lot like ITS#5361, which is a known defect in GnuTLS. What exactly do you mean by "Wildcard SSL certificate" ? There are a couple different approaches to that. One uses the subjectAltName extension, and that is the officially sanctioned approach. One uses "*" in the certificate CN, and that is non-standard and generally not supposed to work. -- -- 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#5513) back-ldap+ppolicy bind assertion failure
by mbackes＠symas.com 17 May '08

17 May '08

> I've been able to reproduce the issue, and I think it's solved > (back-ldap/search.c 1.235 -> 1.236); however I'm afraid I didn't > understand all the details of your configuration, so I might have > tested something different. > > The bug was in ldap_back_entry_get() setting up a connection based > on the o_tag field, which is that of the current operation (a bind, > in your case). I fixed it by always re-setting the tag to > LDAP_REQ_SEARCH, under the assumption that ldap_back_entry_get() > doesn't need to know what operation required the entry to be looked > up. > > Please test and report; in case of further issues, I might need the > full slapd.conf of the proxy (unless the above is all, of course...) Thanks; this seems to fix the issue, at least in my test cases. Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

(ITS#5516) acl_set_cb_gather() incorrectly handles multiple attrs
by ando＠sys-net.it 17 May '08

17 May '08

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando Only the last attribute is considered. Reported in <http://www.openldap.org/lists/openldap-devel/200805/msg00075.html>. A fix is coming.

1 0

Re: (ITS#5513) back-ldap+ppolicy bind assertion failure
by ando＠sys-net.it 17 May '08

17 May '08

mbackes(a)symas.com wrote: > A basic back-ldap configuration with the password policy overlay stacked on top > results in an assertfail for the second bind. e.g. given a working (possibly > empty db) on ldap://localhost:1389/... > > include ...../core.schema > include ...../ppolicy.schema > > modulepath ..... > moduleload back_ldap.la > moduleload ppolicy.la > > database ldap > suffix "" > uri ldap://localhost:1389/ > > After performing a successful remote bind, the next bind attempt halts the > back-ldap directory with: > > slapd: bind.c:905: ldap_back_getconn: Assertion `( li->li_idassert.si_flags & > (0x02U) )' failed. > > where 0x02U here is LDAP_BACK_AUTH_OVERRIDE. > > This happens under both OpenLDAP 2.3 and 2.4. I've been able to reproduce the issue, and I think it's solved (back-ldap/search.c 1.235 -> 1.236); however I'm afraid I didn't understand all the details of your configuration, so I might have tested something different. The bug was in ldap_back_entry_get() setting up a connection based on the o_tag field, which is that of the current operation (a bind, in your case). I fixed it by always re-setting the tag to LDAP_REQ_SEARCH, under the assumption that ldap_back_entry_get() doesn't need to know what operation required the entry to be looked up. Please test and report; in case of further issues, I might need the full slapd.conf of the proxy (unless the above is all, of course...) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5502) LDAP problem
by ando＠sys-net.it 17 May '08

17 May '08

javed_ansari(a)infosys.com wrote: > Full_Name: Javed Ansari > Version: 2.3.30 > OS: Sun > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (220.225.64.6) > > > Since yesterday, we are facing LDAP problems while insertion of data. When we > try to insert data in the ldap we get the following error: > > [LDAP: error code 80 - entry store failed] > > There however seems to be no problem with the login though, this occurs only > during registration You seem to be a little bit too confident on our capability to predict the server's behavior based on a very limited amount of information. Based on the accuracy of your issue report, all I can tell is that you seem to have a problem. Please follow guidelines at <http://www.openldap.org/faq/data/cache/56.html> and provide a decent issue report. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5515) v2.4.9 + GnuTLS fails with wildcard certificate, OpenSSL works correctly
by bgoldsbury＠gleim.com 16 May '08

16 May '08

Full_Name: Ben Goldsbury Version: 2.4.9 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.208.68.2) When OpenLDAP 2.4.9 is compiled against GnuTLS (version 2.2.1 in my testing) and using a valid Wildcard SSL certificate, TLS connections to OpenLDAP fail with: TLS certificate verification: Error, unable to get local issuer certificate When OpenLDAP 2.4.9 is compiled against OpenSSL (version 0.9.8c in my testing) and using the same certificate, connections work properly. Please contact me if you need any additional information.

1 0

Re: (ITS#5510) Does GSSAPI failure kill slapd?
by h.b.furuseth＠usit.uio.no 16 May '08

16 May '08

hyc(a)symas.com writes: > This looks like a pretty major compiler bug, assuming the trace is > correct. Not necessarily, valid optimizations can rearrange memory beyond a debugger's ability to figure out what's going on. Still, this does look like a strange optimization if it's a valid one. > What version of compiler did you use, were you using optimization? Can > you try with a different version and/or without optimization? -- Hallvard

1 0

Re: (ITS#5133) Synchronous replication on slave doesn't notice lost network connection
by stelios.xx.grigoriadis＠ericsson.com 16 May '08

16 May '08

We also have a patch for the stable version should anybody be interested in it. ----- # This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software # represented in the following patch(es) were developed by Stelios Grigoriadis stelios.xx.grigoriadis(a)ericsson.com. # These modifications are not subject to any license of Ericsson AB. # I, Stelios Grigoriadis, hereby place the following modifications to OpenLDAP Software (and only these modifications) # into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or # without attribution and/or other notice. # Bug Fix - This patch fixes the bug ITS#5133. # The fix works as follows. A periodic check in the runqueue (called do_mastercheck). The intervall is determined by # a slapd.conf parameter (mastercheckint) in the syncrepl section and is optional. If it's not specified, it's not # inserted in the runqueue. --- servers/slapd/syncrepl.c 2007-10-05 10:36:13.000000000 +0200 +++ syncrepl.c 2008-05-13 14:27:09.000000000 +0200 @@ -78,6 +78,7 @@ int si_manageDSAit; int si_slimit; int si_tlimit; + int si_mastercheck_int; int si_refreshDelete; int si_refreshPresent; int si_syncdata; @@ -89,6 +90,9 @@ ldap_pvt_thread_mutex_t si_mutex; } syncinfo_t; +/* Necessary in order to use asynchronous searches in mastercheck */ +static ber_int_t ps_msgid; + static int syncuuid_cmp( const void *, const void * ); static void avl_ber_bvfree( void * ); static void syncrepl_del_nonpresent( Operation *, syncinfo_t *, BerVarray, struct berval * ); @@ -314,7 +318,6 @@ BerElement *ber = (BerElement *)&berbuf; LDAPControl c[2], *ctrls[3]; struct timeval timeout; - ber_int_t msgid; int rc; int rhint; char *base; @@ -402,7 +405,7 @@ rc = ldap_search_ext( si->si_ld, base, scope, filter, attrs, attrsonly, ctrls, NULL, si->si_tlimit > 0 ? &timeout : NULL, - si->si_slimit, &msgid ); + si->si_slimit, &ps_msgid ); ber_free_buf( ber ); return rc; } @@ -667,7 +670,7 @@ tout_p = NULL; } - while (( rc = ldap_result( si->si_ld, LDAP_RES_ANY, LDAP_MSG_ONE, + while (( rc = ldap_result( si->si_ld, ps_msgid, LDAP_MSG_ONE, tout_p, &res )) > 0 ) { if ( slapd_shutdown ) { @@ -2769,6 +2772,7 @@ #define OLDAUTHCSTR "bindprincipal" #define EXATTRSSTR "exattrs" #define MANAGEDSAITSTR "manageDSAit" +#define MASTERCHECKINTSTR "mastercheckint" /* FIXME: unused */ #define LASTMODSTR "lastmod" @@ -3198,6 +3202,17 @@ Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 ); return 1; } + } else if ( !strncasecmp( c->argv[ i ], MASTERCHECKINTSTR "=", + STRLENOF( MASTERCHECKINTSTR "=" ) ) ) + { + val = c->argv[ i ] + STRLENOF( MASTERCHECKINTSTR "=" ); + if ( lutil_atoi( &si->si_mastercheck_int, val ) != 0 || si->si_mastercheck_int < 0 ) { + snprintf( c->msg, sizeof( c->msg ), + "invalid master check interval value \"%s\".\n", + val ); + Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 ); + return 1; + } } else if ( !strncasecmp( c->argv[ i ], SYNCDATASTR "=", STRLENOF( SYNCDATASTR "=" ) ) ) { @@ -3273,6 +3288,7 @@ si->si_tlimit = 0; si->si_slimit = 0; si->si_conn_setup = 0; + si->si_mastercheck_int = 0; si->si_presentlist = NULL; LDAP_LIST_INIT( &si->si_nonpresentlist ); @@ -3435,6 +3451,68 @@ ber_dupbv( bv, &bc ); } +static void * +do_mastercheck( + void *ctx, + void *arg ) +{ + struct re_s* rtask = arg; + syncinfo_t *si = ( syncinfo_t * ) rtask->arg; + int rc; + char *search_attrs[] = { NULL }; + LDAPMessage *res = 0; + struct timeval timeout; + timeout.tv_sec = 0; + timeout.tv_usec = 0; + static int mc_msg=-1; + + ldap_pvt_thread_mutex_lock( &si->si_mutex ); + if (si->si_ld) { + if (mc_msg != -1) { + res=0; + ldap_result(si->si_ld, mc_msg, 1, &timeout, &res); + if (res) { ldap_msgfree(res);} + if (rc != LDAP_SUCCESS) { + ldap_abandon_ext(si->si_ld, mc_msg, NULL, NULL); + } + } + mc_msg=-1; + rc=ldap_search_ext(si->si_ld, "", LDAP_SCOPE_BASE, "(objectClass=*)", search_attrs, + 0, NULL, NULL, NULL, 0, &mc_msg); + if (rc != LDAP_SUCCESS) { + Debug(LDAP_DEBUG_ANY,"Failed to send\n",0,0,0); + } + } + + ldap_pvt_thread_mutex_lock( &slapd_rq.rq_mutex ); + + if ( ldap_pvt_runqueue_isrunning( &slapd_rq, rtask )) { + ldap_pvt_runqueue_stoptask( &slapd_rq, rtask ); + } + + rtask->interval.tv_sec = si->si_mastercheck_int; + ldap_pvt_runqueue_resched( &slapd_rq, rtask, 0 ); + + ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex ); + + ldap_pvt_thread_mutex_unlock( &si->si_mutex ); +} + +static int add_mastercheck( ConfigArgs *c ) { + int rc; + syncinfo_t *si = c->be->be_syncinfo; + + if ( si->si_mastercheck_int == 0 ) + return 0; + + rc = ldap_pvt_runqueue_insert( &slapd_rq, si->si_mastercheck_int * 60, + do_mastercheck, si, "do_mastercheck", c->be->be_suffix[0].bv_val ); + if (rc < 0) + Debug( LDAP_DEBUG_ANY, "failed to add syncinfo\n", 0, 0, 0 ); + + return rc; +} + int syncrepl_config( ConfigArgs *c ) { @@ -3470,5 +3548,6 @@ } else if ( add_syncrepl( c ) ) { return(1); } + add_mastercheck( c ); return config_sync_shadow( c ); }

1 0

Re: (ITS#5510) Does GSSAPI failure kill slapd?
by hyc＠symas.com 15 May '08

15 May '08

aej(a)WPI.EDU wrote: >>>>>> "rein" == Rein Tollevik<rein(a)OpenLDAP.org> writes: > > rein> Could you also "print *so" from frame 5, the entry from frame 4 looks > rein> corrupt. > > connection_read(33): no connection! > SASL [conn=27] Failure: GSSAPI Error: The context has expired (No error) > sb_sasl_write: failed to encode packet: generic failure > send_search_entry: conn 27 ber write failed. > slapd: rq.c:92: ldap_pvt_runqueue_remove: Assertion `e == entry' failed. > > Program received signal SIGABRT, Aborted. > [Switching to Thread 1986071456 (LWP 27434)] > 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > (gdb) where > #0 0x00a977a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > #1 0x00ad8815 in raise () from /lib/tls/libc.so.6 > #2 0x00ada279 in abort () from /lib/tls/libc.so.6 > #3 0x00ad1d91 in __assert_fail () from /lib/tls/libc.so.6 > #4 0x08114473 in ldap_pvt_runqueue_remove (rq=0x82c1820, entry=0x6b2a) at rq.c:92 > #5 0x080ffd9f in syncprov_free_syncop (so=0x8403c88) at syncprov.c:744 > #6 0x0810011d in syncprov_qtask (ctx=0x76610210, arg=0x845e880) at syncprov.c:949 > #7 0x08113cfd in ldap_int_thread_pool_wrapper (xpool=0x82e6c78) at tpool.c:663 > #8 0x00d123cc in start_thread () from /lib/tls/libpthread.so.0 > #9 0x00b7a1ae in clone () from /lib/tls/libc.so.6 > (gdb) frame 5 > #5 0x080ffd9f in syncprov_free_syncop (so=0x8403c88) at syncprov.c:744 > 744 ldap_pvt_runqueue_remove(&slapd_rq, so->s_qtask ); > (gdb) print so > $1 = (syncops *) 0x8403c88 > (gdb) print *so > $2 = {s_next = 0x0, s_base = {bv_len = 6, bv_val = 0x83f9b50 "cn=log"}, s_eid = 1, s_op = 0x83fe748, s_rid = 1, s_sid = -1, > s_filterstr = {bv_len = 46, bv_val = 0x7881811c "0\001.\b\022"}, s_flags = 2, s_inuse = 0, s_res = 0x0, s_restail = 0x0, > s_qtask = 0x845e880, s_mutex = {__m_reserved = 1, __m_count = 0, __m_owner = 0x6b2a, __m_kind = 0, __m_lock = {__status = 1, > __spinlock = 0}}} This is extremely odd - the structure definition clearly shows the value of s_qtask that should have been passed to ldap_pvt_runqueue_remove, and yet your trace shows that the value that actually got passed is s_mutex.__m_owner. This looks like a pretty major compiler bug, assuming the trace is correct. What version of compiler did you use, were you using optimization? Can you try with a different version and/or without optimization? -- -- 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#5514) Query about openLDAP on windows
by ando＠sys-net.it 15 May '08

15 May '08

sushmita_mishra(a)infosys.com wrote: > I want to use openLDAP for authentication, for this purpose I have gone > through the documents available at <www.openldap.org/doc/admin24/>. In all these > documents, I found the installation for openLDAP directory server is given for > LINUX or UNIX only and not for Windows. > > My query is Can we install openLDAP directory server on windows machine? If yes > can you please send me the steps for installing/configuring openLDAP directory > server on windows machine? Please direct OpenLDAP software usage questions to the openldap-software mailing lists; the ITS is to track bugs and issues. This ITS will be closed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5511) SIGABRT in slapo-unique when setting uidNumber to 0
by h.b.furuseth＠usit.uio.no 15 May '08

15 May '08

Confirmed in HEAD. Unique makes too small buffer for filter "(uidNumber=0)", so build_filter() line 931: assert( len >= 0 && len < ks ); fails because len == ks == 13 == strlen(filter). slapd.conf: include ...core.schema include ...cosine.schema include ...nis.schema database bdb directory /tmp/db suffix uid=dwhite rootdn uid=dwhite rootpw secret overlay unique unique_attributes uidNumber 'ldapadd'ed ldif: dn: uid=dwhite objectClass: account objectClass: posixAccount uid: dwhite uidNumber: 0 cn: Dan White gidNumber: 1 homeDirectory: /home/dwhite -- Hallvard

1 0

Re: (ITS#5133) Synchronous replication on slave doesn't notice lost network connection
by stelios.xx.grigoriadis＠ericsson.com 15 May '08

15 May '08

We have created a patch that works for us. An updated version is available for 2.4.9 The patch is using the parameter "mastercheckint" in slapd.conf, if present. A separate thread then continously askes the master for the root DSE. An excerpt from the slapd.conf file: # from master ldapt1.roadrunner syncrepl rid=102 provider=ldap://ldapt1.roadrunner type=refreshAndPersist retry="10 10 60 +" searchbase="dc=example,dc=com" filter="(objectClass=*)" scope=sub schemachecking=off sizelimit=500000 timelimit=360000 bindmethod=simple mastercheckint=5 ### THIS is the new parameter. binddn="cn=admin,dc=example,dc=com" credentials=secret updateref ldap://ldapt1.roadrunner overlay syncprov If the master unexpectedly terminates (eg. due to a power failure) the replicas will get a new connection once it's up again. The patch is available at: http://www.freewebs.com/stigri/Stelios-Grigoriadis-its5133-080514.patch It must be run while in openlda-2.4.9 directory. /Stelios Grigoriadis

1 0

Re: (ITS#5507) Ldap clients leak file descriptors
by jsafrane＠redhat.com 15 May '08

15 May '08

Hallvard B Furuseth wrote: > I've no idea how SELinux works, so I'm not up to testing any of what > I'm saying here myself, but some notes follow anyway. Please clarify: > >> On system protected by SELinux, when an application with active LDAP >> connection tries to exec() binary with different security context, >> SELinux inspects all opened filedescriptors, including the ldap one, >> and denies access to the ones, which do not conform active policy (the >> executed binary is not authorized to contact LDAP servers). Users are >> then annoyed by security warnings in the logs. > > More to the point, some of those security warnings may indicate real > security problems. Bind with password, exec some application, and then > that application has the bound user's access to LDAP. That's exactly the case SELinux is trying to prevent. > The message could be indicating a bug in the app - that it should > release its resources (such as descriptors) before exec(). > Except, I presume this happens in system() as well? > I'd be unfortunate if LDAP apps could not use system() safely. I assume system() calls fork() and exec() internally, so yes, it's protected as well. SELinux can be extensively configured and if an admin thinks that executed application can safely use inherited ldap connection, he/she can allow it. But this is nearly impossible, because LDAP can be integrated into pam (via nss_ldap). If pam uses nss_ldap, then really lot of applications use ldap client indirectly. And nss_ldap can be configured to keep the connection open for certain time so it's reused, and the applications don't know, if the pam with nss_ldap has opened ldap connection and they can't close it. >> +#ifdef _GNU_SOURCE >> + fcntl(s, F_SETFD, FD_CLOEXEC); >> +#endif > > _GNU_SOURCE depends on the compiler flags. Please try > #ifdef FD_CLOEXEC > instead. Agreed.. > Also I expect the same should be done in os-local.c:ldap_pvt_socket(), Yes, it should. Again, please use fcntl(s, F_SETFD, FD_CLOEXEC); Jan

1 0

Re: (ITS#5504) ldapsearch hangs retrieving info
by Javier.Fernandez＠cern.ch 15 May '08

15 May '08

Thanks Quanah for your time. I have some answers/comments inline: Quanah Gibson-Mount escribió: > --On Wednesday, May 14, 2008 9:56 AM +0000 Javier.Fernandez(a)cern.ch > wrote: > >> unfortunately there?s no update for openladp under SL4, that?s why we >> are using such version. In fact I see no newer versions but for Fedora >> and Mandriva > <http://staff.telkomsa.net/packages/> > or > <http://www.symas.com> I have tried installing last 2.4 version for RH but I get the same result, since problem is not related to ldap version I'm afraid >> In fact, other sites are living nice with that version or older ones. >> In any case, I have compiled and built latest stable version from >> openldap project webpage (2.3.39) and I get the same problem. I'm not >> saying this is a bug from ldap, but something with local area network >> configuration. >> >> I'm asking for some support to debug this problem actually. > If the bug is not specifically in the OpenLDAP software, I suggest you > peruse: > > <http://www.openldap.org/support/> Well, this is the first thing I tried, but I got no solutions browsing through the pages and therefore I tried this mailing list referenced from that link. > I would note I don't see anything particular in what you provide > indicating the problem is with ldapsearch. What version of OpenLDAP > is the server in question running (I see it is OpenLDAP by querying > its rootDSE)? > > I'll note that a *limited* ldapsearch works just fine: > > [quanah@freelancer ~]$ ldapsearch -x -H ldap://exp-bdii.cern.ch:2170 > -b "" -s base + > # extended LDIF > # > # LDAPv3 snip > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 That works fine for me. > I would also note that for me, doing a dump of the entire server works > just fine: > > ldapsearch -x -H ldap://exp-bdii.cern.ch:2170 -b "o=grid" > > results in: > > # search result > search: 2 > result: 0 Success > > # numResponses: 43962 > # numEntries: 43961 I do not reach that point, in fact that is the problem: command gets stuck retrieving one of the entries, in particular today it hangs at: GlueCEAccessControlBaseRule: VO:ops GlueForeignKey: GlueClusterUniqueID=ce104.cern.ch GlueInformationServiceURL: ldap://ce104.cern.ch:2170/mds-vo-name=resource,o=gr id GlueSchemaVersionMajor: 1 GlueSchemaVersionMinor: 3 and after a long long time, the output gives/jumps to another entry... and it continues dripping entries from time to time for an indefinite period until the command gives timeout. A ping to exp-bdii.cern.ch gives an average delay of 40ms which I consider normal. From any other sites (e.g. any machine from CERN) the command works fine in any openldap version, although I do not see any summary at the end with such big number of entries and results as you do. > > Adding -d -1 to the query, I eventually see the same thing you do: > I just added it to perform some debugging but I do not know how to interpret the results. Once more: any hint on how to trace back this problem would be really apreciated. Thank you very much. -- +--------------------------------------------------------------+ Javier Fernandez Menendez Grupo de Fisica de AAEE Universidad de Oviedo C/ Calvo Sotelo, s/n 33005 Oviedo Phone: +34 985106252 mailto:Javier.Fernandez@cern.ch +---------------------------------------------------------------+

1 0

Re: (ITS#5512) Doc contribution for search privileges in 2.4
by ghenry＠suretecsystems.com 15 May '08

15 May '08

> Hello, > > ITS #5400 outlines a change in the privileges required by search > operations in > 2.4. I would like to suggest documentation for this in the admin guide > (the > slapd.access man page is already accurate). > > Please find propositions here: > 1) http://www.phillipoux.net/jonathan-clarke-20080515-upgrading.patch > Explanation and example in the "Upgrading from 2.3" appendix. > > 2) http://www.phillipoux.net/jonathan-clarke-20080515-access-control.patch > Detail of the required privileges on the "entry" pseudo-attribute in the > access > control section (static and dynamic config - same text is repeated twice). > > > As a side note, I encountered a "452 Error writing file: No space left on > device." error on ftp.openldap.org/incoming while trying to upload these > patches. > Thanks for this. I was hoping to do this tomorrow as I've been so busy this week, but now I don't need to! Will patch, review and provide feedback as soon as I can. Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP.

1 0

(ITS#5514) Query about openLDAP on windows
by sushmita_mishra＠infosys.com 14 May '08

14 May '08

Full_Name: Sushmita Mishra Version: 2.3.41 OS: Windows XP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (220.225.64.6) Hi, I want to use openLDAP for authentication, for this purpose I have gone through the documents available at <www.openldap.org/doc/admin24/>. In all these documents, I found the installation for openLDAP directory server is given for LINUX or UNIX only and not for Windows. My query is Can we install openLDAP directory server on windows machine? If yes can you please send me the steps for installing/configuring openLDAP directory server on windows machine? Thanks, Sushmita Mishra

1 0

(ITS#5513) back-ldap+ppolicy bind assertion failure
by mbackes＠symas.com 14 May '08

14 May '08

Full_Name: Matthew Backes Version: 2.3, 2.4 OS: linux URL: Submission from: (NULL) (76.88.99.93) A basic back-ldap configuration with the password policy overlay stacked on top results in an assertfail for the second bind. e.g. given a working (possibly empty db) on ldap://localhost:1389/... include ...../core.schema include ...../ppolicy.schema modulepath ..... moduleload back_ldap.la moduleload ppolicy.la database ldap suffix "" uri ldap://localhost:1389/ After performing a successful remote bind, the next bind attempt halts the back-ldap directory with: slapd: bind.c:905: ldap_back_getconn: Assertion `( li->li_idassert.si_flags & (0x02U) )' failed. where 0x02U here is LDAP_BACK_AUTH_OVERRIDE. This happens under both OpenLDAP 2.3 and 2.4.

1 0

(ITS#5512) Doc contribution for search privileges in 2.4
by jclarke＠linagora.com 14 May '08

14 May '08

Full_Name: Jonathan Clarke Version: 2.4 OS: URL: Submission from: (NULL) (88.167.76.100) Hello, ITS #5400 outlines a change in the privileges required by search operations in 2.4. I would like to suggest documentation for this in the admin guide (the slapd.access man page is already accurate). Please find propositions here: 1) http://www.phillipoux.net/jonathan-clarke-20080515-upgrading.patch Explanation and example in the "Upgrading from 2.3" appendix. 2) http://www.phillipoux.net/jonathan-clarke-20080515-access-control.patch Detail of the required privileges on the "entry" pseudo-attribute in the access control section (static and dynamic config - same text is repeated twice). As a side note, I encountered a "452 Error writing file: No space left on device." error on ftp.openldap.org/incoming while trying to upload these patches. Regards, Jonathan

1 0

(ITS#5511) SIGABRT in slapo-unique when setting uidNumber to 0
by dwhite＠olp.net 14 May '08

14 May '08

Full_Name: Dan White Version: 2.4.9 OS: Debian Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2610:b8:1:0:21a:70ff:fe8f:e0b3) I'm experiencing SIGABRT crashes when the slapo-unique overlay is enabled, and I attempt to set one of the unique attributes to '0'. A configuration snippet: ... modulepath /usr/lib/ldap moduleload back_bdb moduleload smbk5pwd moduleload unique ... overlay unique #unique_base ou=People,dc=olp,dc=net unique_attributes uidNumber btcAltUID I'm triggering the crash while modifying the uidNumber attribute with the ldapmodify command: hiro:/var/lib/ldap# ldapsearch -LLL uid=dwhite(a)olp.net uidNumber dn: uid=dwhite(a)olp.net,ou=people,dc=olp,dc=net uidNumber: 497913425 hiro:/var/lib/ldap# ldapmodify dn: uid=dwhite(a)olp.net,ou=people,dc=olp,dc=net changeType: modify replace: uidNumber uidNumber: 0 modifying entry "uid=dwhite(a)olp.net,ou=people,dc=olp,dc=net" ldap_result: Can't contact LDAP server (-1) If I comment out all the unique overlay related configuration items and restart slapd, and rerun my ldapmodify command, the process completes normally. Details from the coredump: ... Core was generated by `/usr/sbin/slapd -h ldap:/// ldaps:/// ldapi:/// -g root -u root -f /etc/ldap/sl'. Program terminated with signal 6, Aborted. #0 0xb7eee410 in ?? () (gdb) thread apply all bt Thread 3 (process 9354): #0 0xb7eee410 in ?? () #1 0xbfdb51a8 in ?? () #2 0x0000248b in ?? () #3 0x00000000 in ?? () Thread 2 (process 9355): #0 0xb7eee410 in ?? () #1 0xb717a458 in ?? () #2 0x00000400 in ?? () #3 0x081c4148 in ?? () #4 0xb7bf2b0e in epoll_wait () from /lib/tls/i686/cmov/libc.so.6 #5 0x08075ca9 in slapd_daemon_task (ptr=0x0) at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/daemon.c:2281 #6 0xb7c5d240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #7 0xb7bf249e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 1 (process 9359): #0 0xb7eee410 in ?? () #1 0xb6d77a38 in ?? () #2 0x00000006 in ?? () #3 0x0000248f in ?? () #4 0xb7b4f811 in raise () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7b50fb9 in abort () from /lib/tls/i686/cmov/libc.so.6 #6 0xb7b48fbf in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #7 0xb7579032 in build_filter (domain=0x822f130, uri=0x822b748, ad=0x81e20b0, b=0x82bd980, kp=0xb6878266 "(uidNumber=0", ks=13, ctx=0x82bdab8) at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/overlays/unique.c:931 #8 0xb7579d89 in unique_modify (op=0x82bd6f8, rs=0xb6d791c8) at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/overlays/unique.c:1185 #9 0x080f1c69 in overlay_op_walk (op=0x82bd6f8, rs=0xb6d791c8, which=op_modify, oi=0x822cbc8, on=0x822f148) at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/backover.c:636 #10 0x080f1ea0 in over_op_func (op=0x82bd6f8, rs=0xb6d791c8, which=op_modify) at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/backover.c:698 #11 0x080f1f68 in over_op_modify (op=0x82bd6f8, rs=0xb6d791c8) at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/backover.c:732 #12 0x08096290 in fe_op_modify (op=0x82bd6f8, rs=0xb6d791c8) at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/modify.c:300 #13 0x08095cd4 in do_modify (op=0x82bd6f8, rs=0xb6d791c8) at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/modify.c:175 #14 0x080795c2 in connection_operation (ctx=0xb6d792ac, arg_v=0x82bd6f8) at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/connection.c:1084 #15 0x08079aaf in connection_read_thread (ctx=0xb6d792ac, argv=0x12) at /usr/src/build/slapd.noopt/openldap-2.4.9/servers/slapd/connection.c:1211 #16 0xb7ea812e in ldap_int_thread_pool_wrapper (xpool=0x81e38d0) at /usr/src/build/slapd.noopt/openldap-2.4.9/libraries/libldap_r/tpool.c:663 #17 0xb7c5d240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #18 0xb7bf249e in clone () from /lib/tls/i686/cmov/libc.so.6 (gdb) quit

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs