- openldap-bugs - openldap.org

(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 20 Sep '10

20 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 20 Sep '10

20 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

Re: ITS#6653
by jargon＠molb.org 20 Sep '10

20 Sep '10

Hello, On Tue, Sep 21, 2010 at 12:12:54AM +0200, masarati(a)aero.polimi.it wrote: > Fixed (differently) in HEAD; please test. Thanks for the report. p. It works as expected! Thanks! --=20 Johannes Wei=C3=9Fl

1 0

ITS#6653
by masarati＠aero.polimi.it 20 Sep '10

20 Sep '10

Fixed (differently) in HEAD; please test. Thanks for the report. p.

1 0

(ITS#6654) ldifutil.c introduced a dependence of libldap on liblutil that is not strictly necessary
by masarati＠aero.polimi.it 20 Sep '10

20 Sep '10

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.153.50.138) Submitted by: ando lutil_atoix() is used to parse the version; since we only explicitly allow LDIFv1, a string comparison suffices right now. p.

1 0

(ITS#6653) Segfault when getting LDAP_OPT_HOST_NAME and URI = ldapi://
by jargon＠molb.org 20 Sep '10

20 Sep '10

Full_Name: Johannes Weißl Version: HEAD OS: Debian GNU/Linux AMD64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.104.127.153) This is only a minor issue: When URI is e.g. ldapi:// in ldap.conf and ldap_get_option() for LDAP_OPT_HOST_NAME is called, ldap_url_list2hosts() [url.c:1416] segfaults because the lud_host field in LDAPURLDesc is NULL. Adding an additional test in the loop header fixes this bug: diff -Naur openldap/libraries/libldap/url.c openldap.new/libraries/libldap/url.c --- openldap/libraries/libldap/url.c 2010-04-13 22:17:57.000000000 +0200 +++ openldap.new/libraries/libldap/url.c 2010-09-20 22:44:58.325892001 +0200 @@ -1424,7 +1424,7 @@ /* figure out how big the string is */ size = 1; /* nul-term */ - for (ludp = ludlist; ludp != NULL; ludp = ludp->lud_next) { + for (ludp = ludlist; ludp != NULL && ludp->lud_host != NULL; ludp = ludp->lud_next) { size += strlen(ludp->lud_host) + 1; /* host and space */ if (strchr(ludp->lud_host, ':')) /* will add [ ] below */ size += 2; @@ -1436,7 +1436,7 @@ return NULL; p = s; - for (ludp = ludlist; ludp != NULL; ludp = ludp->lud_next) { + for (ludp = ludlist; ludp != NULL && ludp->lud_host != NULL; ludp = ludp->lud_next) { if (strchr(ludp->lud_host, ':')) { p += sprintf(p, "[%s]", ludp->lud_host); } else {

1 0

(ITS#6652) accesslog anomaly in db drop/re-import
by marco.pizzoli＠gmail.com 20 Sep '10

20 Sep '10

Full_Name: Marco Pizzoli Version: 2.4.23 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.41.84.11) Hi, I had a problem with my Accesslog database. I was investigating an anomaly that I had and, in doing this, I tried to: - backup (slapcat) my accesslog db - drop the entire db (rm -f alock, *.bdb, log.*, __db*) - slapadd the db In slapadd I obtained this error: --- BEGIN /usr/sbin/slapadd -b "cn=log,dc=mycorp.it" -l /srv/bck/dump_db_log.ldif.20100916 . 0.00% eta 08h35m elapsed spd 90.2 k/s str2entry: invalid value for attributeType reqControls #0 (syntax 1.3.6.1.4.1.4203.666.11.5.3.1) slapadd2.4: could not parse entry (line=4907) - 0.01% eta 05h58m elapsed spd 205.7 k/s Closing DB... --- END I went to that line and found this entry: --- BEGIN dn: reqStart=20100913065628.000008Z,cn=log,dc=mycorp.it objectClass: auditSearch structuralObjectClass: auditSearch reqStart: 20100913065628.000008Z reqEnd: 20100913065628.000009Z reqType: search reqSession: 1129 reqAuthzID: cn=syncrepl-ldap04,ou=utenze_tecniche_openldap,ou=Gestori,dc=mycorp.it reqControls: {0}{1.3.6.1.4.1.4203.1.9.1.1 controlValue "30440K0103043M7269643N 3030332M7369643N3030342M63736O3N32303130303931333036353130362O3932343735355K2 330303030303023303033233030303030300001PP"} reqControls: {1}{2.16.840.1.113730.3.4.2 criticality TRUE} reqDN: dc=mycorp.it reqResult: 0 reqScope: base reqDerefAliases: never reqAttrsOnly: TRUE reqFilter: (objectclass=*) reqAttr: 1.1 reqEntries: 0 reqTimeLimit: -1 reqSizeLimit: 1 entryUUID: 2beb0bd0-ba32-4a00-93da-748ef2177cc7 creatorsName: cn=Manager,cn=log,dc=mycorp.it createTimestamp: 20100913065628Z entryCSN: 20100913065628.167225Z#000000#003#000000 modifiersName: cn=Manager,cn=log,dc=mycorp.it modifyTimestamp: 20100913065628Z --- END Having produced this ldif using slapcat and not having "touched" the environment in between could I assume this to be a bug? The entry showed is related to an access made by another OL server of my deployment, which is in mirrormode(=true). This OL is 2.4.23 with BDB4.8.30. Other OLs are 2.4.22 with BDB4.8.26 I deleted this entry and retried the import. Now I have the following error: --- BEGIN /usr/sbin/slapadd2.4 -b "cn=log,dc=mycorp.it" -l /tmp/dump_db_log.ldif.20100916_Corrected " 4.69% eta 01h07m elapsed 03m19s spd 542.3 k/s str2entry: invalid value for attributeType reqRespControls #0 (syntax 1.3.6.1.4.1.4203.666.11.5.3.1) slapadd2.4: could not parse entry (line=3099715) * 4.70% eta 01h07m elapsed 03m20s spd 979.8 k/s Closing DB... --- END The "corrupted" entry is this one: --- BEGIN dn: reqStart=20100913093021.000000Z,cn=log,dc=mycorp.it objectClass: auditBind structuralObjectClass: auditBind reqStart: 20100913093021.000000Z reqEnd: 20100913093021.000001Z reqType: bind reqSession: 2746 reqAuthzID: reqControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1} reqRespControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1 controlValue "3000"} reqDN: uid=pe1597,ou=People,dc=mycorp.it reqResult: 0 reqVersion: 3 reqMethod: SIMPLE entryUUID: 192cbddf-4b5c-431d-a92e-c2f84fa4b7be creatorsName: cn=Manager,cn=log,dc=mycorp.it createTimestamp: 20100913093021Z entryCSN: 20100913093021.411398Z#000000#003#000000 modifiersName: cn=Manager,cn=log,dc=mycorp.it modifyTimestamp: 20100913093021Z --- END Is this a software bug? If yes, do I need to produce other infos related to my environment? Regards Marco Pizzoli

1 0

Re: (ITS#6650) The synchronization between two Mirror Servers is not stable
by changhong_sun＠yahoo.cn 19 Sep '10

19 Sep '10

I've updated the openLdap version from 2.4.12 to 2.4.23, and it works corre= ctly. =0A=0APreviously, I installed the OpenLdap 2.4.12 directly by YaST So= ftware Management of SUSE Linux Enterprise Server 11, and the Linux was ins= talled in VMWare 7.0. =0A=0AI don't know if the unstable synchronization is= a common issue of the openLdap 2.4.12? =0A=0AThanks and Best Regards,=0ACh= angHong=0A=0A=0A=0A=0A

1 0

Re: (ITS#6642) back-meta idassert with SASL EXTERNAL ignoring parameters
by masarati＠aero.polimi.it 18 Sep '10

18 Sep '10

>> Just to make sure, can you pull the entire HEAD? Thanks for checking, >> in >> any case. p. > I finally had the time to reproduce the issue using the cvs source > code from HEAD. > The following command was used to build OpenLDAP: > -------------------------------- > CPPFLAGS="-I/home/openldap/software/include -D_AVL_H" \ > LDFLAGS="-L/home/openldap/software/lib > -Wl,-rpath=/home/openldap/software/lib" \ > ./configure --prefix=/home/openldap/software --enable-rewrite > --enable-dnssrv \ > --enable-ldap --enable-meta --enable-auditlog --enable-rwm > --enable-sssvlv \ > --with-cyrus-sasl --with-tls=openssl --enable-bdb > make depend; make; make install > -------------------------------- > > The necessary SSL certificates are selfsigned: > -------------------------------- > openssl genrsa -out server1.key 2048 > openssl req -new -key server1.key -x509 -days 365 -out server1.crt > openssl genrsa -out server2.key 2048 > openssl req -new -key server2.key -x509 -days 365 -out server2.crt > -------------------------------- > > "server2" was started with the command: > slapd -f /home/openldap/config/slapd.conf.server2 -h > "ldaps://server2:6361" > At this point I could already authenticate via SASL EXTERNAL using the > ldapsearch command: > LDAPTLS_CACERT=server2.crt LDAPTLS_CERT=server1.crt > LDAPTLS_KEY=server1.key \ > ldapsearch -H "ldaps://server2:6361" -b "" -s base -Y EXTERNAL > 'objectclass=*' > > Now I started "server1": > slapd -f /home/openldap/config/slapd.conf.server1 -h "ldap://server1:3891" > > Searching with > ldapsearch -H ldap://server1:3891 -b "dc=server2,dc=example,dc=com" -x > gives me no result, but the following output on server1's debug log (level > 1): > -------------------------------- > ldap_connect_to_host: Trying 127.0.0.1:6361 > ldap_pvt_connect: fd: 9 tm: -1 async: 0 > TLS trace: SSL_connect:before/connect initialization > TLS trace: SSL_connect:SSLv2/v3 write client hello A > TLS trace: SSL_connect:SSLv3 read server hello A > TLS certificate verification: depth: 0, err: 18, subject: > /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server2, issuer: > /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server2 > TLS certificate verification: Error, self signed certificate > TLS trace: SSL3 alert write:fatal:unknown CA I think the real error is that you're using self-signed certificates; this has nothing to do with the way OpenLDAP is using them. Using certificates signed by a CA known to the servers I obtain the expected behavior. p. > TLS trace: SSL_connect:error in SSLv3 read server certificate B > TLS trace: SSL_connect:error in SSLv3 read server certificate B > TLS: can't connect: error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self > signed certificate). > conn=1000 op=1 meta_search_dobind_init[0]: retrying > URI="ldaps://server2:6361" DN="". > -------------------------------- > > And again: > Starting "server1" with the environment variables and everything works > fine: > LDAPTLS_CACERT=server2.crt LDAPTLS_CERT=server1.crt > LDAPTLS_KEY=server1.key \ > slapd -f /home/openldap/config/slapd.conf.server1 -h > "ldap://server1:3891" > > I hope you can reproduce this issue using the information I provided. > The configurations of both servers are attached below. > > Best Regards, > Manuel > > > slapd.conf.server1 > -------------------------------- > include /home/openldap/software/etc/openldap/schema/core.schema > include /home/openldap/software/etc/openldap/schema/cosine.schema > include > /home/openldap/software/etc/openldap/schema/inetorgperson.schema > database meta > suffix "dc=example,dc=com" > uri "ldaps://server2:6361/dc=server2,dc=example,dc=com" > idassert-authzFrom "*" > idassert-bind bindmethod=sasl > saslmech=EXTERNAL > tls_cert=/home/openldap/config/server1.crt > tls_key=/home/openldap/config/server1.key > tls_cacert=/home/openldap/config/server2.crt > mode=none > -------------------------------- > > > slapd.conf.server2 > -------------------------------- > include /home/openldap/software/etc/openldap/schema/core.schema > include /home/openldap/software/etc/openldap/schema/cosine.schema > include > /home/openldap/software/etc/openldap/schema/inetorgperson.schema > TLSCertificateFile /home/openldap/config/server2.crt > TLSCertificateKeyFile /home/openldap/config/server2.key > TLSCACertificateFile /home/openldap/config/server1.crt > TLSVerifyClient demand > database bdb > suffix "dc=server2,dc=example,dc=com" > rootdn "cn=manager,dc=server2,dc=example,dc=com" > directory /home/openldap/db.server2 > -------------------------------- > >

1 0

ITS#6650
by masarati＠aero.polimi.it 18 Sep '10

18 Sep '10

There exists no 4.2.12 version of OpenLDAP. The latest stable is 2.4.23; please check and report. Unless you are actually using 2.4.23, this ITS will be closed. p.

1 0

(ITS#6651) Parsing of multiple generic controls (-E <oid>) broken
by masarati＠aero.polimi.it 18 Sep '10

18 Sep '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.153.50.138) Submitted by: ando A fix has been committed to HEAD. p.

1 0

ITS#6649
by masarati＠aero.polimi.it 18 Sep '10

18 Sep '10

I assume you are not talking about ldapsearch(1) the command-line tool. In any case, please try HEAD's overlays/sssvlv.c commit of few minutes ago and report through the ITS. Thanks, p.

1 0

(ITS#6650) The synchronization between two Mirror Servers is not stable
by changhong_sun＠yahoo.cn 18 Sep '10

18 Sep '10

Full_Name: Chang Hong Sun Version: 4.2.12 OS: SUSE Linux Enterprise Server 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.15.219.84) Hi, I'm using OpenLdap 4.2.12 Mirror Mode to make protection between two LDAP servers. Sometimes it works prettey good, but sometimes the synchronization between two servers doesn't work, I don't know if the Mirror Mode is not stable in 4.2.12, should I update to a higher version? Thanks and Best Regards, Changhong

1 0

(ITS#6649) Possible bug in ldapsearch
by kacoroski＠gmail.com 17 Sep '10

17 Sep '10

Full_Name: Ski Kacoroski Version: 2.4.23 OS: debian 64 bit linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (152.157.64.243) When I run a search with the following parameters: 0 'base' 1 'dc=nsd,dc=org' 2 'attr' 3 ARRAY(0x23f0cf0) 0 'nsduidnumber' 4 'filter' 5 '(&(objectClass=nsdAcct)(nsdUIDNumber<=80000)(nsdUIDNumber>=70000))' 6 'control' 7 ARRAY(0x23f0fa8) 0 Net::LDAP::Control::Sort=HASH(0x2374e60) 'order' => ARRAY(0x23f05b8) 0 'nsduidnumber' 'type' => '1.2.840.113556.1.4.473' 'value' => "0\cP0\cN\cD\cLnsduidnumber" 1 Net::LDAP::Control::Paged=HASH(0x23f0b88) 'asn' => HASH(0x23f0d80) 'cookie' => '' 'size' => 10 'size' => 10 'type' => '1.2.840.113556.1.4.319' 'value' => "0\cE\cB\cA\cJ\cD\c@" I can reliably crash the slapd server. Logs are in Ski-Kacoroski-100917.ext If I only use one or the other control it works fine. It only crashed when both controls are used together. Let me know if you need anything else.

1 0

Re: (ITS#6642) back-meta idassert with SASL EXTERNAL ignoring parameters
by mgaupp＠googlemail.com 17 Sep '10

17 Sep '10

> Just to make sure, can you pull the entire HEAD? =A0Thanks for checking, = in > any case. =A0p. I finally had the time to reproduce the issue using the cvs source code from HEAD. The following command was used to build OpenLDAP: -------------------------------- CPPFLAGS=3D"-I/home/openldap/software/include -D_AVL_H" \ LDFLAGS=3D"-L/home/openldap/software/lib -Wl,-rpath=3D/home/openldap/softwa= re/lib" \ ./configure --prefix=3D/home/openldap/software --enable-rewrite --enable-dn= ssrv \ --enable-ldap --enable-meta --enable-auditlog --enable-rwm --enable-sssvl= v \ --with-cyrus-sasl --with-tls=3Dopenssl --enable-bdb make depend; make; make install -------------------------------- The necessary SSL certificates are selfsigned: -------------------------------- openssl genrsa -out server1.key 2048 openssl req -new -key server1.key -x509 -days 365 -out server1.crt openssl genrsa -out server2.key 2048 openssl req -new -key server2.key -x509 -days 365 -out server2.crt -------------------------------- "server2" was started with the command: slapd -f /home/openldap/config/slapd.conf.server2 -h "ldaps://server2:6361" At this point I could already authenticate via SASL EXTERNAL using the ldapsearch command: LDAPTLS_CACERT=3Dserver2.crt LDAPTLS_CERT=3Dserver1.crt LDAPTLS_KEY=3Dserve= r1.key \ ldapsearch -H "ldaps://server2:6361" -b "" -s base -Y EXTERNAL 'objectcla= ss=3D*' Now I started "server1": slapd -f /home/openldap/config/slapd.conf.server1 -h "ldap://server1:3891" Searching with ldapsearch -H ldap://server1:3891 -b "dc=3Dserver2,dc=3Dexample,dc=3Dcom" -= x gives me no result, but the following output on server1's debug log (level = 1): -------------------------------- ldap_connect_to_host: Trying 127.0.0.1:6361 ldap_pvt_connect: fd: 9 tm: -1 async: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 0, err: 18, subject: /C=3DAU/ST=3DSome-State/O=3DInternet Widgits Pty Ltd/CN=3Dserver2, issuer: /C=3DAU/ST=3DSome-State/O=3DInternet Widgits Pty Ltd/CN=3Dserver2 TLS certificate verification: Error, self signed certificate TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self signed certificate). conn=3D1000 op=3D1 meta_search_dobind_init[0]: retrying URI=3D"ldaps://server2:6361" DN=3D"". -------------------------------- And again: Starting "server1" with the environment variables and everything works fine= : LDAPTLS_CACERT=3Dserver2.crt LDAPTLS_CERT=3Dserver1.crt LDAPTLS_KEY=3Dserve= r1.key \ slapd -f /home/openldap/config/slapd.conf.server1 -h "ldap://server1:3891= " I hope you can reproduce this issue using the information I provided. The configurations of both servers are attached below. Best Regards, Manuel slapd.conf.server1 -------------------------------- include /home/openldap/software/etc/openldap/schema/core.schema include /home/openldap/software/etc/openldap/schema/cosine.schema include /home/openldap/software/etc/openldap/schema/inetorgperson.s= chema database meta suffix "dc=3Dexample,dc=3Dcom" uri "ldaps://server2:6361/dc=3Dserver2,dc=3Dexample,dc=3Dcom" idassert-authzFrom "*" idassert-bind bindmethod=3Dsasl saslmech=3DEXTERNAL tls_cert=3D/home/openldap/config/server1.crt tls_key=3D/home/openldap/config/server1.key tls_cacert=3D/home/openldap/config/server2.crt mode=3Dnone -------------------------------- slapd.conf.server2 -------------------------------- include /home/openldap/software/etc/openldap/schema/core.schema include /home/openldap/software/etc/openldap/schema/cosine.schema include /home/openldap/software/etc/openldap/schema/inetorgperson.s= chema TLSCertificateFile /home/openldap/config/server2.crt TLSCertificateKeyFile /home/openldap/config/server2.key TLSCACertificateFile /home/openldap/config/server1.crt TLSVerifyClient demand database bdb suffix "dc=3Dserver2,dc=3Dexample,dc=3Dcom" rootdn "cn=3Dmanager,dc=3Dserver2,dc=3Dexample,dc=3Dcom" directory /home/openldap/db.server2 --------------------------------

1 0

(ITS#6648) Syncrepl cold refresh fails with mirrormode supplier
by andrew.findlay＠skills-1st.co.uk 15 Sep '10

15 Sep '10

Full_Name: Andrew Findlay Version: 2.4.23 OS: OpenSuSE 11.1 URL: ftp://ftp.openldap.org/incoming/ajf-syncrepl-config-20100915a.tgz Submission from: (NULL) (88.97.25.132) When a read-only consumer server uses one peer of a mirrormode pair as its supplier, there is a case where the initial refresh phase of the synchronisation loses deletions. This is very similar to the case where a single master server has its serverID changed between taking a slapcat backup to LDIF and bringing up a consumer server fom that LDIF file. See this thread for some background: http://www.openldap.org/lists/openldap-technical/201009/msg00193.html The problem occurs when a deletion was originated on a server whose serverID does not match the serverID of the supplier when a new consumer is brought up. It is masked by the volatile syncprov-sessionlog if the deletion is still in the provider's log, which is why the instructions below stop and start the servers so much. I have uploaded the configs and data files for this to ftp.openldap.org. Case 1: serverID of supplier server changes during the creation of a consumer: people.ldif contains entries #1, #2, #3, #4 under dc=people,dc=example,dc=org 1) Load people.ldif into empty master server 2) Start master 3) Stop master 4) Dump master DB using slapcat > m1.ldif 5) Start master 6) Delete entry#1 7) Stop master 8) change master serverID 9) Start master 10) Dump master DB using slapcat > m2.ldif 11) Delete entry#2 11a) Stop master 11b) Start master 12) Load m1.ldif into empty consumer server 13) Start consumer 14) Check ContextCSN matches on each server 15) Check for Entry#1 Entry#2 Entry#3 If 11a/b are run: Entry#1 and Entry#2 are still found on the consumer If 11a/b are not run: Entry#1 is still found on the consumer Entry#2 is deleted - presumably because it was in the volatile sessionlog Case 2: mirrormode pair supplying read-only consumer: 1) Load people.ldif into empty peer server with serverID 1 2) Start peer 1 3) Start peer 2 and allow it to sync up 4) Stop peer 1 4) Dump peer 1 DB using slapcat > p1.ldif 5) Start peer 1 6) Delete entry#1 on peer 1 7) Delete entry#2 on peer 2 8) Verify that both entries have gone on both servers 9) Stop both peer servers (this clears the volatile syncrepl-sessionlog) 10) Start peer 1 and peer 2 11) Load p1.ldif into empty consumer server (which is configured to sync from peer 1) 12) Start consumer 13) Check ContextCSN matches on each server 14) Check for Entry#1 Entry#2 Entry#3 on all servers Entries #1 and #2 have gone on both mirrormode peers Entries #1 and #2 are still present on the consumer The consumer only has a ContextCSN value from peer 1 15) Restart the consumer server The consumer now has both ContextCSN values but it still has entries #1 and #2 16) Delete Entry #3 on peer 1 17) Check for entry #3 on all servers Correctly deleted 18) Delete Entry #4 on peer 2 19) Check for entry #3 on all servers Correctly deleted Entries #1 and #2 are still present on the consumer Andrew

1 0

Re: (ITS#6647) Overlay sssvlv is always loaded
by masarati＠aero.polimi.it 14 Sep '10

14 Sep '10

> Please try this (nearly blind) patch > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.pat…> > > and report through the ITS. Thanks, p. I note that I have messed things up a bit in cleanup; however, this should not affect the testing of the functionality, except if you delete the overlay from the configuration using back-config. If the patch works fine, I'll fix that part. p.

1 0

Re: (ITS#6647) Overlay sssvlv is always loaded
by masarati＠aero.polimi.it 14 Sep '10

14 Sep '10

> 2010/9/14 <masarati(a)aero.polimi.it>: >>> On 14/09/2010 11:33, clem.oudot(a)gmail.com wrote: >>>> Full_Name: Clement OUDOT >>>> Version: 2.4.23 >>>> OS: GNU/Linux >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (83.145.72.122) >>>> >>>> >>>> Hi, >>>> >>>> I am using OpenLDAP 2.4.23 compiled with --enable-overlays (RPMs from >>>> http://www.ltb-project.org). Overlays are not compiled as modules. >>>> >>>> Overlay sssvlv is compiled, but not activated in configuration >>>> >>>> But: >>>> * SSS and VLV controls are displayed in RootDSE >>>> * SSS control is taken into account if present in an LDAP search >>>> operation >>>> >>>> For example, a search with SSS control on cn (which has no ordering >>>> rule) >>>> gives: >>>> result: 18 Inappropriate matching >>>> text: serverSort control: No ordering rule >>>> >>>> >>>> The error would be normal if overlay has been activated, but I think >>>> control >>>> should be ignored if overlay is not active. >>> >>> I hit this exact same issue just last week - it seems that when the >>> overlay is compiled in, the SSS control is displayed in the rootDSE. >>> >>> In my case, this caused a client to attempt to use the control, then >>> fail with a similar message as above. Without the overlay compiled in, >>> the client just doesn't use the control, and the client's operation >>> suceeded. >>> >>> My point is that I agree this probably shouldn't be activated by >>> default, or at the very least a clear warning added in the >>> documentation= > . >> >> This behavior is common to all overlays that register a general feature, >> like controls, extended ops or even just a bit of custom schema: the >> registration is done when the module is loaded (or at startup, if the >> module is statically built into slapd). =A0As a consequence, the feature >> = > is >> advertised because slapd knows about it, but since it is not explicitly >> configured, does not know how to handle it. >> >> In the end, slapd's behavior is correct: it recognizes the feature, it >> recognizes requests for the feature, but does not know how to handle >> them= > , >> thus returns an appropriate error. =A0This looks pretty consistent with >> RFC4511 and specifications of each feature, although I understand it >> coul= > d >> be disappointing. >> >> Perhaps we could modify this behavior so that the module initialization >> does nothing or so, and only the first instantiation of the feature >> cause= > s >> the real initialization. =A0This was discussed in the past, and I recall >> = > it >> created trouble when part of the initialization was needed earlier (e.g. >> registering schema items that need to be used later in the configuration >> or so; a clear case was back-monitor, which registers schema items that >> are needed by other backends when registering custom monitoring; if >> back-monitor startup didn't occur early enough, one had to instantiate >> it >> before any database that wanted to register custom monitoring). >> >> In conclusion: the current behavior is consistent; on a case by case >> basis, feature instantiation could perhaps be deferred as much as >> possible, unless this conflicts with other features. >> > > I understand your point of view. Indeed, recompiling OpenLDAP without > sssvlv overlay works. > > The fact is that for people compiling OpenLDAP with --enable-overlays, > we have a 'regression' with overlay sssvlv, because LDAP clients are > now using the control and get errors. > > Maybe the issue can be retargeted to sssvlv overlay: if an LDAP client > is using the SSS control in a non-critical mode, OpenLDAP should > return search results (unsorted) even if the control fails (because of > missing ordering rule for requested attribute). If the control is > critical, then the error must be returned. Please try this (nearly blind) patch <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.pat…> and report through the ITS. Thanks, p.

1 0

Re: (ITS#6647) Overlay sssvlv is always loaded
by clem.oudot＠gmail.com 14 Sep '10

14 Sep '10

2010/9/14 <masarati(a)aero.polimi.it>: >> On 14/09/2010 11:33, clem.oudot(a)gmail.com wrote: >>> Full_Name: Clement OUDOT >>> Version: 2.4.23 >>> OS: GNU/Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (83.145.72.122) >>> >>> >>> Hi, >>> >>> I am using OpenLDAP 2.4.23 compiled with --enable-overlays (RPMs from >>> http://www.ltb-project.org). Overlays are not compiled as modules. >>> >>> Overlay sssvlv is compiled, but not activated in configuration >>> >>> But: >>> * SSS and VLV controls are displayed in RootDSE >>> * SSS control is taken into account if present in an LDAP search >>> operation >>> >>> For example, a search with SSS control on cn (which has no ordering >>> rule) >>> gives: >>> result: 18 Inappropriate matching >>> text: serverSort control: No ordering rule >>> >>> >>> The error would be normal if overlay has been activated, but I think >>> control >>> should be ignored if overlay is not active. >> >> I hit this exact same issue just last week - it seems that when the >> overlay is compiled in, the SSS control is displayed in the rootDSE. >> >> In my case, this caused a client to attempt to use the control, then >> fail with a similar message as above. Without the overlay compiled in, >> the client just doesn't use the control, and the client's operation >> suceeded. >> >> My point is that I agree this probably shouldn't be activated by >> default, or at the very least a clear warning added in the documentation= . > > This behavior is common to all overlays that register a general feature, > like controls, extended ops or even just a bit of custom schema: the > registration is done when the module is loaded (or at startup, if the > module is statically built into slapd). =A0As a consequence, the feature = is > advertised because slapd knows about it, but since it is not explicitly > configured, does not know how to handle it. > > In the end, slapd's behavior is correct: it recognizes the feature, it > recognizes requests for the feature, but does not know how to handle them= , > thus returns an appropriate error. =A0This looks pretty consistent with > RFC4511 and specifications of each feature, although I understand it coul= d > be disappointing. > > Perhaps we could modify this behavior so that the module initialization > does nothing or so, and only the first instantiation of the feature cause= s > the real initialization. =A0This was discussed in the past, and I recall = it > created trouble when part of the initialization was needed earlier (e.g. > registering schema items that need to be used later in the configuration > or so; a clear case was back-monitor, which registers schema items that > are needed by other backends when registering custom monitoring; if > back-monitor startup didn't occur early enough, one had to instantiate it > before any database that wanted to register custom monitoring). > > In conclusion: the current behavior is consistent; on a case by case > basis, feature instantiation could perhaps be deferred as much as > possible, unless this conflicts with other features. > I understand your point of view. Indeed, recompiling OpenLDAP without sssvlv overlay works. The fact is that for people compiling OpenLDAP with --enable-overlays, we have a 'regression' with overlay sssvlv, because LDAP clients are now using the control and get errors. Maybe the issue can be retargeted to sssvlv overlay: if an LDAP client is using the SSS control in a non-critical mode, OpenLDAP should return search results (unsorted) even if the control fails (because of missing ordering rule for requested attribute). If the control is critical, then the error must be returned. What is your opinion? Cl=E9ment.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs