openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

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

Bug in deleting entry in MirrorMode?
by Peter Palmreuther 09 Nov '09

09 Nov '09

Hello, I'm writing to this list to clarify if I discovered a bug or just did not configure OpenLDAP properly. 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 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. So either I've got a configuration problem or there's a problem with synchronization. Anybody here to help, tracking down this problem? Thanks a lot, and -- Regards, Peter

2 1

(ITS#6367) syncprov ... changed by peer, ignored
by olivier.chirossel＠sfr.com 09 Nov '09

09 Nov '09

Full_Name: olivier chirossel Version: 2.4.17 and 2.4.19 OS: linux URL: http://86.64.145.174:8080/ Submission from: (NULL) (62.39.9.251) in refreshend persist mode, the replication is incorrect for an entry which be delete/add after master restart and before the reconnection of the slave. steps to reproduce : 0) two linux server (one for the master, one for the slave) on the master ip : 10.143.73.9 on the slave ip : 10.143.73.71 1) kernel configuration on the slave by default tcp_keepalive_time 7200 on linux and tcp_keepalive_probes 9 put in /etc/sysctl.conf net.ipv4.tcp_keepalive_time = 60 net.ipv4.tcp_keepalive_probes = 2 and sysctl -p 2) master set up on /etc/openldap tar xvf slapd_master.tar (get on the url ) and slapd -F /etc/openldap/slapd.d and ldapadd -h 10.153.73.9 -D "cn=admin, cn=config" -w secret -f first.ldif (get on url) 2) slave set up on /etc/openldap tar xvf slapd_slave.tar (get on the url ) and slapd -F /etc/openldap/slapd.d 2) on the master : add the entry ldapadd -h 10.153.73.9 -D "cn=admin, cn=config" -w secret -f test1init.ldif (get on url) 3) on the master : restart the master and delete/add (with new value) kill `pidof slapd` slapd -F /etc/openldap/slapd.d ldapdelete -h 10.153.73.9 -D "cn=admin, cn=config" -w secret msisdn=6666666660,suffix=0,dc=sfr.com ldapadd -h 10.153.73.9 -D "cn=admin, cn=config" -w secret -f testcreate.ldif (get on url) verify the entry ldapsearch -L -L -L -D "cn=admin, cn=config" -w secret -b " suffix=0,dc=sfr.com" 4) on the slave : see the slave reconnect netstat -an | grep 389 for see the connection between the slave and the master ldapsearch -L -L -L -D "cn=admin, cn=config" -w secret -b " suffix=0,dc=sfr.com" see the logs 5) on the slave after reconnection to the master ldapsearch -L -L -L -D "cn=admin, cn=config" -w secret -b " suffix=0,dc=sfr.com" ( "no entry for dn msisdn=6666666660,suffix=0,dc=sfr.com" ) 6) on the master after reconnection from the slave to the master in the logs syncprov ... changed by peer, ignored

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