openldap-bugs April 2010

openldap-bugs@openldap.org

45 participants
233 discussions

Start a nNew thread

Re: (ITS#6472) Syncrepl : loop problem with moddn on a new node
by masarati＠aero.polimi.it 17 Apr '10

17 Apr '10

A fix is in HEAD, please test slapd/syncrepl.c 1.502 -> 1.503 Thanks for reporting, p.

1 0

Re: (ITS#6472) Syncrepl : loop problem with moddn on a new node
by hyc＠symas.com 17 Apr '10

17 Apr '10

masarati(a)aero.polimi.it wrote: > >> It's not clear to me where the issue is. What is the "right" sequence the >> add of the new superior and the mordrdn should be transmitted? Should the >> provider operate differently, or should the consumer check all syncrepl >> messages and try to rebuild the final state, instead of giving up when the >> internal lookup for the newsuperior fails? Probably, a workaround could >> be to perform the modrdn by crating the new superior as a glue object, >> which eventually will be replaced by the actual add. > > I've quickly hacked things this way, and it seems to work fine. > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-17-sync-rename.…> > > Please let me know if this approach is sound enough, I might have > overlooked some implications. Patch looks good, solution makes sense. This is one of the reasons we would expect glue entries to be used. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6524) gnutls cipher spec is unclear
by matthijs＠cacholong.nl 17 Apr '10

17 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kurt Zeilenga wrote: > On Apr 17, 2010, at 3:15 AM, matthijs(a)cacholong.nl wrote: > >> On Apr 16, 2010, at 6:01 PM, Howard Chu wrote: >>> If Peter wants his patch considered for inclusion in OpenLDAP he = >> should write to the ITS himself, we cannot accept 3rd party = >> contributions. >> >> What's the reasoning behind this? > > 3rd parties (middle men) not only hinder good communication between the authors(s) of the contribution and the Project/Foundation, they introduce various risks to both the author and the Project/Foundation. > > Regard, Kurt (Executive Director, The OpenLDAP Foundation) > Hi, Thanks for the explanation, I'll keep it in mind when forwarding patches and / or bug reports from the Debian bugtracker. Regards, Matthijs Mohlmann -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvKDnUACgkQ2n1ROIkXqbDFtwCgjOrjYmDPXtqYpQrQTNzq7gqL RcsAmgKRRJB28cke29WMHhKIIcB/+q7L =QTpi -----END PGP SIGNATURE-----

1 0

Re: (ITS#6472) Syncrepl : loop problem with moddn on a new node
by masarati＠aero.polimi.it 17 Apr '10

17 Apr '10

> It's not clear to me where the issue is. What is the "right" sequence the > add of the new superior and the mordrdn should be transmitted? Should the > provider operate differently, or should the consumer check all syncrepl > messages and try to rebuild the final state, instead of giving up when the > internal lookup for the newsuperior fails? Probably, a workaround could > be to perform the modrdn by crating the new superior as a glue object, > which eventually will be replaced by the actual add. I've quickly hacked things this way, and it seems to work fine. <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-17-sync-rename.…> Please let me know if this approach is sound enough, I might have overlooked some implications. p.

1 0

Re: (ITS#6472) Syncrepl : loop problem with moddn on a new node
by masarati＠aero.polimi.it 17 Apr '10

17 Apr '10

>> Full_Name: Julien COMBES >> Version: 2.4.21 >> OS: Debian 5.0.4 >> URL: ftp://ftp.openldap.org/incoming/its-syncrepl-loop-moddn.tar.bz2 >> Submission from: (NULL) (212.23.175.185) >> >> >> Hello, >> >> I think I have found a loop problem with syncrepl replication with >> openldap >> 2.4.21, BDB 4.7.25 with all patches and hdb database. The problem >> appears >> sometimes when an entry is moved with "modrdbn -s" in a node which has >> just been >> created. I have reproduced the problem with the creation of a node and a >> moddn >> while the consumer was stopped and then restarted after. >> >> The problem follows these steps : >> - When it starts, the consumer does a request objectClass=* on the >> provider : >> Feb 12 09:09:19 ldapma24-ida01 slapd[30445]: conn=1007 op=1 SRCH >> base="dc=my,dc=domain" scope=2 deref=0 filter="(objectClass=*)" >> >> - The consumer finds the modrdn and tries to do this : >> Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: >> ==>hdb_modrdn(cn=user1,ou=A,dc=my,dc=domain,cn=user1,ou=X,dc=my,dc=domain) >> >> - The consumer fails with these errors : >> Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: => >> hdb_dn2id("ou=x,dc=my,dc=domain") >> Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: <= hdb_dn2id: get failed: >> DB_NOTFOUND: No matching key/data pair found (-30988) >> Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: hdb_modrdn: >> newSup(ndn=ou=x,dc=my,dc=domain) not here! >> Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: send_ldap_result: conn=-1 >> op=0 p=0 >> Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: send_ldap_result: err=32 >> matched="" >> text="new superior not found" >> >> - The consumer retries the request objectClass=* on the provider and >> loops on >> the problem. The replication doesn't work anymore. >> >> To reproduce the problem, I have used these steps : >> - start an empty provider >> - ldapadd the entries in mydomain.ldif >> ldapadd -x -h 127.0.0.1 -D "dc=my,dc=domain" -W -f mydomain.ldif >> - start the consumer. >> - stop the consumer when replication is finished >> - ldapadd the new node >> ldapadd -x -h 127.0.0.1 -D "dc=my,dc=domain" -W -f add.ldif >> - modrdn -s >> ldapmodrdn -x -h 127.0.0.1 -D "dc=my,dc=domain" -W -r -s >> "ou=X,dc=my,dc=domain" >> "cn=user1,ou=A,dc=my,dc=domain" "cn=user1" >> - start the consumer >> >> I join in its-syncrepl-loop-moddn.tar.bz2 : >> - slapd.conf of provider and consummer >> - log files of provider and consummer >> - mydomain.ldif and add.ldif > > Thanks for the detailed report. The bug is confirmed, and it's not > related to back-hdb, but seems to be syncrepl-related in general. It's not clear to me where the issue is. What is the "right" sequence the add of the new superior and the mordrdn should be transmitted? Should the provider operate differently, or should the consumer check all syncrepl messages and try to rebuild the final state, instead of giving up when the internal lookup for the newsuperior fails? Probably, a workaround could be to perform the modrdn by crating the new superior as a glue object, which eventually will be replaced by the actual add. p.

1 0

Re: (ITS#6472) Syncrepl : loop problem with moddn on a new node
by masarati＠aero.polimi.it 17 Apr '10

17 Apr '10

> Full_Name: Julien COMBES > Version: 2.4.21 > OS: Debian 5.0.4 > URL: ftp://ftp.openldap.org/incoming/its-syncrepl-loop-moddn.tar.bz2 > Submission from: (NULL) (212.23.175.185) > > > Hello, > > I think I have found a loop problem with syncrepl replication with > openldap > 2.4.21, BDB 4.7.25 with all patches and hdb database. The problem appears > sometimes when an entry is moved with "modrdbn -s" in a node which has > just been > created. I have reproduced the problem with the creation of a node and a > moddn > while the consumer was stopped and then restarted after. > > The problem follows these steps : > - When it starts, the consumer does a request objectClass=* on the > provider : > Feb 12 09:09:19 ldapma24-ida01 slapd[30445]: conn=1007 op=1 SRCH > base="dc=my,dc=domain" scope=2 deref=0 filter="(objectClass=*)" > > - The consumer finds the modrdn and tries to do this : > Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: > ==>hdb_modrdn(cn=user1,ou=A,dc=my,dc=domain,cn=user1,ou=X,dc=my,dc=domain) > > - The consumer fails with these errors : > Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: => > hdb_dn2id("ou=x,dc=my,dc=domain") > Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: <= hdb_dn2id: get failed: > DB_NOTFOUND: No matching key/data pair found (-30988) > Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: hdb_modrdn: > newSup(ndn=ou=x,dc=my,dc=domain) not here! > Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: send_ldap_result: conn=-1 > op=0 p=0 > Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: send_ldap_result: err=32 > matched="" > text="new superior not found" > > - The consumer retries the request objectClass=* on the provider and > loops on > the problem. The replication doesn't work anymore. > > To reproduce the problem, I have used these steps : > - start an empty provider > - ldapadd the entries in mydomain.ldif > ldapadd -x -h 127.0.0.1 -D "dc=my,dc=domain" -W -f mydomain.ldif > - start the consumer. > - stop the consumer when replication is finished > - ldapadd the new node > ldapadd -x -h 127.0.0.1 -D "dc=my,dc=domain" -W -f add.ldif > - modrdn -s > ldapmodrdn -x -h 127.0.0.1 -D "dc=my,dc=domain" -W -r -s > "ou=X,dc=my,dc=domain" > "cn=user1,ou=A,dc=my,dc=domain" "cn=user1" > - start the consumer > > I join in its-syncrepl-loop-moddn.tar.bz2 : > - slapd.conf of provider and consummer > - log files of provider and consummer > - mydomain.ldif and add.ldif Thanks for the detailed report. The bug is confirmed, and it's not related to back-hdb, but seems to be syncrepl-related in general. p.

1 0

Re: (ITS#6482) slapcat doesn't continue with -c after the first corrupted database entry
by masarati＠aero.polimi.it 17 Apr '10

17 Apr '10

> Full_Name: Himmelbauer > Version: 2.4.19 > OS: Gentoo Linux > URL: ftp://ftp.openldap.org/incoming/himmelbauer-100301.patch > Submission from: (NULL) (92.248.100.200) > > > Was not able to retrieve database entries from a corrupted LDAP database > using > slapcat (openldap 2.4.19) with option -c. It aborts after the first > corrupted > entry with > > <= entry_decode: slap_str2undef_ad(object�!p): > AttributeDescription > contains inappropriate characters > # no data for entry id=xxxxxxxx > > and doesn't continue with the next valid entry as I would have expected. > > A damaged database is not good, but as slapcat is described as the tool to > recover the non-corrupted data in various forums, it would be good when it > really continues on errors. Other ldap-related tools like ldapsearch > ignore the > damaged data, so it is really annoying, when you want to recover your data > and > don't even get all the readable entries. > > The patch corrects the handling of damaged entries by slapcat when -c is > used, > so that the output is continued with the next non-damaged entry. When -c > is not > used slapcat stops after the first corrupted entry (as expected). > > The patch works for me, but I know that it is not really correct, because > when > there would be no non-damaged entry left it would either cause a endless > loop or > some crashes. > > So a modification would be needed to stop the loop when the last database > entry > was processed, but I didn't know how to access that id. I do not quite understand this report and your fix. The code seems to work as intended. "continue" here means keep processing the database if an entry can't be extracted from the database. This does by no means imply that processing can always continue. If the database is corrupted, it is likely that from the first appearance of the corruption, not even the next entry id can be retrieved at all. Otherwise, if the only error consists in not being able to extract an entry, continuation occurs as expected in the current code. What likely happened in your case was that as soon as the database corruption was encountered, be_entry_next() was unable to compute the id of the next entry. This is why you don't even get a log of the ids of the entries that couldn't be extracted. I'd close this ITS. p.

1 0

Re: (ITS#6524) gnutls cipher spec is unclear
by Kurt＠OpenLDAP.org 17 Apr '10

17 Apr '10

On Apr 17, 2010, at 3:15 AM, matthijs(a)cacholong.nl wrote: > On Apr 16, 2010, at 6:01 PM, Howard Chu wrote: >> If Peter wants his patch considered for inclusion in OpenLDAP he =3D > should write to the ITS himself, we cannot accept 3rd party =3D > contributions. >=20 > What's the reasoning behind this? 3rd parties (middle men) not only hinder good communication between the = authors(s) of the contribution and the Project/Foundation, they = introduce various risks to both the author and the Project/Foundation. Regard, Kurt (Executive Director, The OpenLDAP Foundation)

1 0

(ITS#6526) slapd does not start: slapo-rwm + rewriteContext searchfilter + rewriteRule + cn=config
by daniel＠pluta.biz 17 Apr '10

17 Apr '10

Full_Name: Daniel Pluta Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:9feb:ff02:749a:cf80:5be3:e252) Using the following rwm configuration: overlay rwm rwm-rewriteEngine on rwm-rewriteContext searchFilter rwm-rewriteRule "(.*)" "(&(ou=openldap)$1)" ":@I" 1.) works fine after starting slapd with: slapd -f slapd.conf 2.) converts fine (at least no error messages): slaptest -f slapd.conf -F slapd.d 3.) but slapd's startup aborts when using: slapd -F slapd.d fyi here's slapd's output when started "slapd -F slapd.d -d -1" (rwm-related output): ldif_read_file: read entry file: "/tmp/openldap/etc/openldap/slapd.d/cn=config/olcDatabase={2}hdb/olcOverlay={1}rwm.ldif" => str2entry: "dn: olcOverlay={1}rwm objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {1}rwm olcRwmRewrite: {0}rwm-rewriteEngine "on" olcRwmRewrite: {1}rwm-rewriteContext "searchFilter" olcRwmRewrite: {2}rwm-rewriteRule "(.*)" "(&(ou=openldap)$1)" ":@I" olcRwmTFSupport: false olcRwmNormalizeMapped: FALSE structuralObjectClass: olcRwmConfig entryUUID: 2dbc3768-de64-102e-990e-a3438cd19586 creatorsName: cn=config createTimestamp: 20100417115744Z entryCSN: 20100417115744.885645Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100417115744Z " >>> dnPrettyNormal: <olcOverlay={1}rwm> => ldap_bv2dn(olcOverlay={1}rwm,0) <= ldap_bv2dn(olcOverlay={1}rwm)=0 => ldap_dn2bv(272) <= ldap_dn2bv(olcOverlay={1}rwm)=0 => ldap_dn2bv(272) <= ldap_dn2bv(olcOverlay={1}rwm)=0 <<< dnPrettyNormal: <olcOverlay={1}rwm>, <olcOverlay={1}rwm> >>> dnNormalize: <cn=config> => ldap_bv2dn(cn=config,0) <= ldap_bv2dn(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 <<< dnNormalize: <cn=config> >>> dnNormalize: <cn=config> => ldap_bv2dn(cn=config,0) <= ldap_bv2dn(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 <<< dnNormalize: <cn=config> <= str2entry(olcOverlay={1}rwm) -> 0x9581ef4 => test_filter PRESENT => access_allowed: search access to "olcOverlay={1}rwm,olcDatabase={2}hdb,cn=config" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 6 line 0 (rwm-rewriteEngine "on") line 0 (rwm-rewriteEngine "on") line 0 (rwm-rewriteContext "searchFilter" ==> here the shell is back :-/ BTW: after commenting out 'rwm-rewriteRule "(.*)" "(&(ou=openldap)$1)" ":@I"' slapd starts just fine. Adding this rule vi cn=config works, but searchfilter-rewriting does not work. Removeing the rule via cn=config results in assertion error rwm.c's function "rwm_cf_gen" in line 2158.

1 0

(ITS#6525) gnutls cipher spec is unclear
by peter＠adpm.de 17 Apr '10

17 Apr '10

Full_Name: Peter Marschall Version: 2.4.21 OS: Linux / BSD URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-20100417-*.patch Submission from: (NULL) (94.217.132.71) Hi, as Matthijs Mohlmann already noted in ITS#6524, the man pages about the TLSCipherSuite resp. TLS_CIPHER_SUITE are for gnutls a bit unclear, only an example for OpenSSL is provided. I wrote patches to alleviate this problem and sent them to the Debian bug tracking system (from where Matthijs they kindly [and with my permission] forwarded to ITS#6524). Please find the patches in * ftp://ftp.openldap.org/incoming/Peter-Marschall-20100417-ldap.conf_TLS_CIPH… * ftp://ftp.openldap.org/incoming/Peter-Marschall-20100417-slapd.conf-TLSCiph… Please consider them for inclusion in the next release of OpenLDAP (BTW, when will that be?) Thanks Peter Marschall

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
24
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2010