openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

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

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

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

21 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

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