openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

(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 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

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