openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(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

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