openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#6659) logfile directive not logging any log
by masarati＠aero.polimi.it 28 Sep '10

28 Sep '10

> Full_Name: Soichi Hayashi > Version: 2.3.43-12.el5_5.2 > OS: RHEL5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (99.50.225.74) > > > I have following in my slapd.conf > > logfile /var/log/ldap.log > > When I start slapd, it creates the file specified but the filesize remains > 0 > although I see a lot of log sent to syslog. > > It looks like the logging through "logfile" directive is not working. According to the documentation, this directive collects messages that are sent to stderr when "-d" is used, so it is not related to syslog. It is equivalent to $ slapd -d <level> >>/var/log/ldap.log 2>&1 I've checked recent code and it works as expected. Unless this is what you're expecting, and it does not happen, this ITS will be closed. p.

1 0

modifyTimestamp does not always update
by Jani Salonen 27 Sep '10

27 Sep '10

Seems that modifyTimestamp of groupOfUniqueNames does not always update as it should. We have one application that updates uniqueMembers of groupOfUniqueNames groups (we have about 30000 groups, from 5 to 1000 members each). Another application syncs its sql database based on groupOfUniqueNames member's once an hour, and for speeding things up, that another application first looks from modifyTimeStamp if group has changed within last hour, and if so, it will be synced. But here is the problem: another application's database does not always sync because modifyTimestamp does not always update for some group. Unfortunately this happens quite rarely and I cannot provide exact instructions how to reproduce this, I was not able to find any pattern either. If anyone has any ideas/experiments what is wrong/how to fix this, they are most welcome. Thanks, Jani Salonen

2 1

(ITS#6659) logfile directive not logging any log
by hayashis＠indiana.edu 24 Sep '10

24 Sep '10

Full_Name: Soichi Hayashi Version: 2.3.43-12.el5_5.2 OS: RHEL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (99.50.225.74) I have following in my slapd.conf logfile /var/log/ldap.log When I start slapd, it creates the file specified but the filesize remains 0 although I see a lot of log sent to syslog. It looks like the logging through "logfile" directive is not working.

1 0

ITS#6657
by masarati＠aero.polimi.it 23 Sep '10

23 Sep '10

Please - rebuild with -DSLAP_NO_SL_MALLOC=1 (you only need to recompile sl_malloc.c) - run slapd under valgrind --tool=memcheck --leak-check=full and minimal loglevel (e.g. -d stats) - send valgrind's output (if anything surfaces) Thanks, p.

1 0

Re: (ITS#6657) back-sql segfault in backsql_search
by david＠dasz.at 22 Sep '10

22 Sep '10

I've tried the same configuration with 2.4.11-1+lenny2 from lenny and it didn't segfault on my test-queries. Regards, David

1 0

(ITS#6657) back-sql segfault in backsql_search
by david＠dasz.at 22 Sep '10

22 Sep '10

Full_Name: David Schmitt Version: 2.4.23-5 OS: Debian squeeze URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.170.188.2) I'm seeing reproducible but inconsistent segfaults from within back-sql: #0 slap_sl_free (ptr=0x9cc440, ctx=0x98e270) at /home/devel/openldap/trunk/servers/slapd/sl_malloc.c:490 p = 0xffffffee009bc130 tmpp = <value optimized out> #1 0x00007ffff35f7877 in backsql_free_entryID (id=0x7ffff139d678, freeit=0, ctx=0x98e270) at /home/devel/openldap/trunk/servers/slapd/back-sql/entry-id.c:84 next = 0x0 __PRETTY_FUNCTION__ = "backsql_free_entryID" #2 0x00007ffff35f0ad8 in backsql_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/back-sql/search.c:2552 dbh = 0x965590 sres = <value optimized out> user_entry = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} base_entry = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} manageDSAit = 0 stoptime = 1285164120 bsi = {bsi_op = 0x98b500, bsi_rs = 0x7ffff139ea40, bsi_flags = 1, bsi_base_ndn = 0x98b538, bsi_use_subtree_shortcut = 0, bsi_base_id = {eid_id = 1, eid_keyval = 1, eid_oc_id = 1, eid_oc = 0x98bb50, eid_dn = {bv_len = 0, bv_val = 0x0}, eid_ndn = {bv_len = 18, bv_val = 0x9cc440 "ou=samba,ou=uni-ak"}, eid_next = 0x0}, bsi_scope = 2, bsi_filter = 0x9bbf98, bsi_stoptime = 1285164120, bsi_id_list = 0x0, bsi_id_listtail = 0x7ffff139d6d8, bsi_c_eid = 0x7ffff139d678, bsi_n_candidates = -2, bsi_status = 0, bsi_oc = 0x98b3f0, bsi_sel = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_from = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_join_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_flt_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_filter_oc = 0x0, bsi_dbh = 0x965590, bsi_attrs = 0x0, bsi_e = 0x0} eid = <value optimized out> lastid = 0 #3 0x00000000004355c9 in fe_op_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/search.c:366 bd = 0x7347e0 #4 0x0000000000435ddc in do_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/search.c:217 base = {bv_len = 18, bv_val = 0x9ac727 "ou=samba,ou=uni-ak"} siz = 0 i = 140737240492960 #5 0x0000000000433479 in connection_operation (ctx=0x7ffff139eba0, arg_v=<value optimized out>) at /home/devel/openldap/trunk/servers/slapd/connection.c:1109 rc = <value optimized out> cancel = <value optimized out> op = 0x98b500 rs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 2, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = { r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = { r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x7ffff7f3b690 memctx = 0x98e270 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #6 0x0000000000433c65 in connection_read_thread (ctx=<value optimized out>, argv=<value optimized out>) at /home/devel/openldap/trunk/servers/slapd/connection.c:1245 s = 14 I've configured back-sql with suffix 'ou=uni-ak' and am searching for '(&(cn=p0002001)(objectclass=sambasamaccount))' (which doesn't return results) within 'ou=samba,ou=uni-ak', which exists and has ~10k items in the whole tree. The segfault happens on the second such ldapsearch in the slapd's lifetime. Using a filter that returns multiple entries '(&(cn=x0004291)(objectclass=sambasamaccount))', back-sql segfaults already within the first query: #0 slap_sl_free (ptr=0x9dd7f8, ctx=0x98e270) at /home/devel/openldap/trunk/servers/slapd/sl_malloc.c:490 p = 0xffffffc9009cc582 tmpp = <value optimized out> #1 0x00007ffff35f7896 in backsql_free_entryID (id=0x9dd7f8, freeit=1, ctx=0x98e270) at /home/devel/openldap/trunk/servers/slapd/back-sql/entry-id.c:101 next = 0x0 __PRETTY_FUNCTION__ = "backsql_free_entryID" #2 0x00007ffff35f0ee7 in backsql_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/back-sql/search.c:2223 dbh = 0x965590 sres = <value optimized out> user_entry = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} base_entry = {e_id = 1, e_name = {bv_len = 18, bv_val = 0x9cc468 "ou=samba,ou=uni-ak"}, e_nname = {bv_len = 18, bv_val = 0x9cc490 "ou=samba,ou=uni-ak"}, e_attrs = 0x82e7b8, e_ocflags = 256, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} manageDSAit = 0 stoptime = 1285164373 bsi = {bsi_op = 0x98b500, bsi_rs = 0x7ffff139ea40, bsi_flags = 1, bsi_base_ndn = 0x98b538, bsi_use_subtree_shortcut = 0, bsi_base_id = {eid_id = 1, eid_keyval = 1, eid_oc_id = 1, eid_oc = 0x98bb50, eid_dn = {bv_len = 18, bv_val = 0x9cc3d8 "ou=samba,ou=uni-ak"}, eid_ndn = {bv_len = 18, bv_val = 0x9cc440 "ou=samba,ou=uni-ak"}, eid_next = 0x0}, bsi_scope = 2, bsi_filter = 0x9bbf98, bsi_stoptime = 1285164373, bsi_id_list = 0x9dcc18, bsi_id_listtail = 0x9dd838, bsi_c_eid = 0x9dd7f8, bsi_n_candidates = -5, bsi_status = 0, bsi_oc = 0x993690, bsi_sel = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_from = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_join_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_flt_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_filter_oc = 0x0, bsi_dbh = 0x965590, bsi_attrs = 0x0, bsi_e = 0x7ffff139d890} eid = 0x9dd7f8 lastid = 0 #3 0x00000000004355c9 in fe_op_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/search.c:366 bd = 0x7347e0 #4 0x0000000000435ddc in do_search (op=0x98b500, rs=0x7ffff139ea40) at /home/devel/openldap/trunk/servers/slapd/search.c:217 base = {bv_len = 18, bv_val = 0x9ac727 "ou=samba,ou=uni-ak"} siz = 0 i = 140737240492960 #5 0x0000000000433479 in connection_operation (ctx=0x7ffff139eba0, arg_v=<value optimized out>) at /home/devel/openldap/trunk/servers/slapd/connection.c:1109 rc = <value optimized out> cancel = <value optimized out> op = 0x98b500 rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 3, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 1} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x7ffff7f3b690 memctx = 0x98e270 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #6 0x0000000000433c65 in connection_read_thread (ctx=<value optimized out>, argv=<value optimized out>) at /home/devel/openldap/trunk/servers/slapd/connection.c:1245 s = 14 A third query for a different mapped object class doesn't lead to a segfault at all (within the 15 tries I tested). I would not exclude an error in the schema mapping, but I'd prefer an error message instead of a segfault ;-) Thanks for your time and work, David

1 0

(ITS#6656) logging "reqEntryUUID" in accesslog
by michael＠stroeder.com 22 Sep '10

22 Sep '10

Full_Name: Michael Ströder Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.92.147.99) Feature request: In accesslog the value of entryUUID of the entry affected by a write operation should be logged in a separate attribute 'reqEntryUUID' so that this write operations are also searchable in case an entry was renamed afterwards. Searching in reqOld is not an option because for performance reasons one would not index this multi-valued attribute which can contain lots of values.

1 0

Re: (ITS#6655) Error on delete for jpegPhoto attribute
by masarati＠aero.polimi.it 21 Sep '10

21 Sep '10

This is not a bug, but a legitimate error. The definition of the attribute jpegPhoto contains no matching rule, so deleting a specific value is not possible. This ITS will be closed. p. > Full_Name: Philippe EYCHART > Version: 2.4.15 > OS: slackware > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (123.50.121.95) > > > Hi, > It seems that the delete of a jpegPhoto attribute (specifing its value) > produce > the error 18 (Inappropriate matching). > With other attribute ("title", for exemple), this error doesn't appear ... > > source (C++): > m_errNo = ldap_modify_ext_s ( m_desc, > (*m_entryIn)->getIdentifier().c_str(), > tmpMods, NULL, NULL ); > > Trace Debug (code::blocks 8.02): > **tmpMods > mod_op=129 > mod_type = 0xcc9950 "jpegPhoto" > mod_vals > modv_strvals = 0xc3dad0 > modv_bvals = 0xc3dad0 > *tmpMods->mod_vals->modv_bvals[0] > bv_len = 816 > bv_val = 0xec9480 "iVBORwOKGgoAAAANSUh... // (*) > tmpMods->mod_vals->modv_bvals[1] = (berval *) 0x0,, > this->m_errNo = 18 > > (*): here, the value seems correct: (std::string(..."a search jpegPhoto > attribute result in > Base"...getAttribute()->getStrValue()))->compare(bv_val)==0... > > but: > **tmpMods > mod_op=129 > mod_type = 0xd76130 "title" > mod_vals > modv_strvals = 0xcc7e90 > modv_bvals = 0xcc7e90 > *tmpMods->mod_vals->modv_bvals[0] > bv_len = 4 > bv_val = 0xdd3b40 "test" > tmpMods->mod_vals->modv_bvals[1] = (berval *) 0x0,, > this->m_errNo = 0 > > > Please, tell me if you need some more samples of code or trace debug ... > Regards. > PE > <http://homepage.gna.org/ldapcppei/Frontends/Howto-7.fr.html> > > >

1 0

Re: (ITS#6655) Error on delete for jpegPhoto attribute
by philippe.eychart＠mail.pf 21 Sep '10

21 Sep '10

Le lundi 20 septembre 2010 à 23:36 +0000, openldap-its(a)OpenLDAP.org a écrit : > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6655. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#6655) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6655) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=6655 > > Please remember to retain your issue tracking number (ITS#6655) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > More context here : http://homepage.gna.org/ldapcppei/archives/ldapEasyAdminFrontends/personFro… line # 707...

1 0

(ITS#6655) Error on delete for jpegPhoto attribute
by philippe.eychart＠mail.pf 21 Sep '10

21 Sep '10

Full_Name: Philippe EYCHART Version: 2.4.15 OS: slackware URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.121.95) Hi, It seems that the delete of a jpegPhoto attribute (specifing its value) produce the error 18 (Inappropriate matching). With other attribute ("title", for exemple), this error doesn't appear ... source (C++): m_errNo = ldap_modify_ext_s ( m_desc, (*m_entryIn)->getIdentifier().c_str(), tmpMods, NULL, NULL ); Trace Debug (code::blocks 8.02): **tmpMods mod_op=129 mod_type = 0xcc9950 "jpegPhoto" mod_vals modv_strvals = 0xc3dad0 modv_bvals = 0xc3dad0 *tmpMods->mod_vals->modv_bvals[0] bv_len = 816 bv_val = 0xec9480 "iVBORwOKGgoAAAANSUh... // (*) tmpMods->mod_vals->modv_bvals[1] = (berval *) 0x0,, this->m_errNo = 18 (*): here, the value seems correct: (std::string(..."a search jpegPhoto attribute result in Base"...getAttribute()->getStrValue()))->compare(bv_val)==0... but: **tmpMods mod_op=129 mod_type = 0xd76130 "title" mod_vals modv_strvals = 0xcc7e90 modv_bvals = 0xcc7e90 *tmpMods->mod_vals->modv_bvals[0] bv_len = 4 bv_val = 0xdd3b40 "test" tmpMods->mod_vals->modv_bvals[1] = (berval *) 0x0,, this->m_errNo = 0 Please, tell me if you need some more samples of code or trace debug ... Regards. PE <http://homepage.gna.org/ldapcppei/Frontends/Howto-7.fr.html>

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