openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#6309) missing SEARCH information
by hyc＠symas.com 11 Nov '09

11 Nov '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.18 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > I see the following logged at level 256: > > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 fd=117 ACCEPT from > IP=171.67.219.70:51122 (IP=0.0.0.0:389) > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=0 BIND dn="" method=163 > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=0 RESULT tag=97 err=14 > text=SASL(0): successful result: > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=1 BIND dn="" method=163 > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=1 RESULT tag=97 err=14 > text=SASL(0): successful result: > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=2 BIND dn="" method=163 > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=2 BIND > authcid="service/vacation(a)stanford.edu" authzid="service/vacation(a)stanford.edu" > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=2 BIND > dn="cn=vacation,cn=service,cn=applications,dc=stanford,dc=edu" mech=GSSAPI > sasl_ssf=56 ssf=56 > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=2 RESULT tag=97 err=0 text= > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=3 do_search: invalid dn > (basedn) > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=3 SEARCH RESULT tag=101 err=34 > nentries=0 text=invalid DN > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 fd=117 closed (connection lost) > > > Since the actual search is not logged, there is no way to determine what the > invalid DN being used is in this case. This seems faulty. I'd expect to see > some additional logging like: The invalid DN *was* logged, it was "basedn". Sounds like you have a really badly configured client out there somewhere. 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

(ITS#6372) slapd lockup on shutdown
by quanah＠zimbra.com 11 Nov '09

11 Nov '09

Full_Name: Quanah Gibson-Mount Version: 2.4.19 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Had an idle slapd lock up during shutdown. Backtrace as follows: Thread 10 (process 627): #0 0x0000003c0c70b04f in __write_nocancel () from /lib64/tls/libpthread.so.0 #1 0x0000000000431d3e in slap_sig_shutdown (sig=2) at daemon.c:2926 #2 <signal handler called> #3 0x0000003c0c70b04d in __write_nocancel () from /lib64/tls/libpthread.so.0 #4 0x0000000000431d3e in slap_sig_shutdown (sig=15) at daemon.c:2926 #5 <signal handler called> #6 0x0000003c0c706ffb in pthread_join () from /lib64/tls/libpthread.so.0 #7 0x0000002a956b2408 in ldap_pvt_thread_join (thread=1082132832, thread_return=0x0) at thr_posix.c:197 #8 0x0000000000431c8c in slapd_daemon () at daemon.c:2835 #9 0x00000000004146d8 in main (argc=10, argv=0x7fbfffae38) at main.c:950 Thread 9 (process 637): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 8 (process 636): #0 0x0000003c0c70b04f in __write_nocancel () from /lib64/tls/libpthread.so.0 #1 0x0000000000431d3e in slap_sig_shutdown (sig=15) at daemon.c:2926 #2 <signal handler called> #3 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #4 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #5 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #6 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #7 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 7 (process 635): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 6 (process 634): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 5 (process 633): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 4 (process 632): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 3 (process 631): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 2 (process 630): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 1 (process 629): #0 0x0000003c0c70b04f in __write_nocancel () from /lib64/tls/libpthread.so.0 #1 0x0000000000431d3e in slap_sig_shutdown (sig=15) at daemon.c:2926 #2 <signal handler called> #3 0x0000003c0c70b04d in __write_nocancel () from /lib64/tls/libpthread.so.0 #4 0x000000000042d17d in slapd_clr_write (s=4113, wake=1) at daemon.c:951 #5 0x0000000000433ae8 in connection_wake_writers (c=0x1451ec0) at connection.c:778 #6 0x0000000000433c40 in connection_closing (c=0x1451ec0, why=0x4e3ee2 "slapd shutdown") at connection.c:806 #7 0x00000000004322bb in connections_shutdown () at connection.c:209 #8 0x0000000000431b31 in slapd_daemon_task (ptr=0x0) at daemon.c:2761 #9 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #10 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6

1 0

Re: (ITS#6362) slapd 2.4.19 Segmentation fault under load
by mbackes＠symas.com 10 Nov '09

10 Nov '09

Hello, Aleksey. > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > Freebsd 7.2 amd64 Slapd built with the "-g" flag and install with > the make install STRIP="" Okay. > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000) At the same time? Your ldd list below shows only berkeley db 4.6. These don't mix... > In slapd config added using hdb as backend and indexes. Testing > database consist of 1000 users accounts with minimum attributes. On > stress test load slapd Segmentation fault in 10-30 sec. What sort of operations? > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x803404560 (LWP 100116)] > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory > address > 0x7ffffd9f9f38: Bad s. > ) at idl.c:511 Does it always fail at the same location? How reproducible is this? Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

(ITS#6371) problem with ber_flatten2
by dave.daugherty＠centrify.com 10 Nov '09

10 Nov '09

Full_Name: Dave Daugherty Version: 2.2.6 and 2.4.17 OS: RedHat EL3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.170.119.248) We use ber_flatten2 in an unusual way, but I think this issue is generic int ber_flatten2( BerElement *ber, struct berval *bv, int alloc ) { /* copy the berval */ ber_len_t len = ber_pvt_ber_write( ber ); if ( alloc ) { bv->bv_val = (char *) ber_memalloc_x( len + 1, ber->ber_memctx ); if ( bv->bv_val == NULL ) { return -1; } AC_MEMCPY( bv->bv_val, ber->ber_buf, len ); } else { bv->bv_val = ber->ber_buf; } bv->bv_val[len] = '\0'; <- ???? bv->bv_len = len; The problem I have is a crash, because of the bv->bv_val[len] = \0 when alloc is set to zero, AND the buffer that was passed in was generated by ber_realloc, which did not leave an extra byte at the end, resulting in a write beyond the allocated memory block. The questions I have are: 1) Is the zero terminator really necessary? 2) If so, seems like it should only be done if we actually allocated a new buffer (which does leave one byte at the end).

1 0

Re: (ITS#6370) Error converting syncprov-checkpoint option to olcSpCheckpoint attribute
by masarati＠aero.polimi.it 10 Nov '09

10 Nov '09

Fixed in HEAD, servers/slapd/overlays/syncprov.c 1.289 -> 1.290 Please test. The fix should apply smoothly to recent 2.4 releases. Thanks for reporting, p.

1 0

(ITS#6370) Error converting syncprov-checkpoint option to olcSpCheckpoint attribute
by kblaney＠nortel.com 10 Nov '09

10 Nov '09

Full_Name: Kyle Blaney Version: 2.4.15 OS: Redhat Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.11.182.187) In OpenLDAP 2.4.19, values change when converting from the syncprov-checkpoint option in file-based configuration to the olcSpCheckpoint attribute in online configuration. To reproduce: 1. Configure OpenLDAP using file-based slapd.conf configuration that contains the following line: syncprov-checkpoint 100 10 2. Make slapd.d directory. 3. Convert file-based configuration to online configuration using the following command: slapd -f slapd.conf -F slapd.d File-based configuration is converted to the cn=config database, but after conversion the value of the olcSpCheckpoint attribute in the "olcOverlay={1}syncprov,olcDatabase={1}bdb,cn=config entry" is "100 600" when it should be the same as in file-based configuration ("100 10").

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by masarati＠aero.polimi.it 10 Nov '09

10 Nov '09

pitpalme+openldap(a)gmail.com wrote: > Full_Name: Peter Palmreuther > Version: 2.4.19 > OS: FreeBSD 7.2 / Solaris 8 > URL: > Submission from: (NULL) (87.123.91.4) > > > I've set up OpenLDAP to run in "MirrorMode": > > # [...] > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > # [...] > syncrepl rid=001 > provider=ldap://localhost:11389 > type=refreshAndPersist > searchbase="o=esolution,dc=deutscherv,dc=de" > schemachecking=on > bindmethod=simple > binddn="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de" > credentials="M1rr0rM3" > retry="60 +" > > serverID 1 > mirrormode on > # [...] > > The second server is set up identically, except "serverID" is 2 and "provider" > is set to URL of first server. The fact addresses are "localhost" is because I > replicated my main setup on my private server (FreeBSD) to better inspect and > debug the problem. > > When adding, modifying and deleting an entry it can happend I do get a positive > return from delete, but a subsequent "add" fails with "code=68: Already > exists". Can you check whether the entry actually exist, although in "glue" state? You can do this by searching (e.g. with ldapsearch) as the rootdn, to bypass access checking, and using the manageDSAit control (-MM). p.

1 0

(ITS#6247)
by daniel＠pluta.biz 10 Nov '09

10 Nov '09

Hi, I've uploaded a cleaned up version. It's nearly a complete rewrite of the original contribution. In addition to the previous version which (intentionally) just supported the constant MRA "NOW" the updated version also supports now[+/-]offset calculation and matching. The offset's syntax is "NYears#Nmonths#Ndays#NHours#NMinutes#NSeconds" where '#' separates the different time unit fields and N is the amount of time (offset) for a distinct time unit. N can be a negative or positive value (all none-digits and blanks are ignored, multiple signs are simply aggregated to a single (the first from the left) sign). Thanks to previous normalization before the actual matching the "timedrift effect" (see followup #4 above) isn't present any more, too. The two matching rule's (nowOrEarlier/nowOrLaterMatch) are compatible with any generalizedTime-syntax based attribute. Additionally the module introduces two specialized syntaxes exclusively dedicated to this modules matching rules (intentionally not supporting any kind of generalizedTime[Ordering]Match-ing extensible match). Please have a look at the README, the sample schema definition, and/or the source for further details. The current version can be found here: ftp://ftp.openldap.org/incoming/daniel-pluta-now-091110-1.tgz Any kind of feedback is very welcome. Thanks a lot! Daniel

1 0

(ITS#6369) Get rid of cacertdir_rehash
by FullName＠in-valid.com 10 Nov '09

10 Nov '09

Full_Name: Full Name Version: 2.3.43 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:708:10:10:21c:25ff:fe98:3f0e) It is inconvenient to have to use cacertdir_rehash command to hash the certs. IMO it does not service any purpose. It would be nice if cert could be just dropped to a dir and then openldap sees it.

1 0

(ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme+openldap＠gmail.com 09 Nov '09

09 Nov '09

Full_Name: Peter Palmreuther Version: 2.4.19 OS: FreeBSD 7.2 / Solaris 8 URL: Submission from: (NULL) (87.123.91.4) I've set up OpenLDAP to run in "MirrorMode": # [...] overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # [...] syncrepl rid=001 provider=ldap://localhost:11389 type=refreshAndPersist searchbase="o=esolution,dc=deutscherv,dc=de" schemachecking=on bindmethod=simple binddn="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de" credentials="M1rr0rM3" retry="60 +" serverID 1 mirrormode on # [...] The second server is set up identically, except "serverID" is 2 and "provider" is set to URL of first server. The fact addresses are "localhost" is because I replicated my main setup on my private server (FreeBSD) to better inspect and debug the problem. When adding, modifying and deleting an entry it can happend I do get a positive return from delete, but a subsequent "add" fails with "code=68: Already exists". This does not happen all the time, but often enough to name it "reproducible". This seems not to happen if there's a "sleep" between modify and delete. It also seems not to happen if secondary server is down.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs