openldap-bugs December 2008

openldap-bugs@openldap.org

36 participants
131 discussions

Re: (ITS#5861) Assert control on Add request fails
by Kurt＠OpenLDAP.org 20 Dec '08

20 Dec '08

On Dec 20, 2008, at 12:13 PM, ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Full_Name: Hallvard B Furuseth >> Version: HEAD >> OS: Linux >> URL: >> Submission from: (NULL) (129.240.6.233) >> Submitted by: hallvard >> >> >> RFC 4528 says the Assert control is appropriate for Add. Yes. >> Slapd disagrees: No. slapd(8) is saying the control is unavailable. That's quite different than saying it is inappropriate. >> >> >> $ ldapadd -xhlocalhost:3890 -e\!assert='(objectClass=organization)' >> <test.ldif >> adding new entry "o=test" >> ldap_add: Critical extension is unavailable (12) >> additional info: critical extension is unavailable > > According to this thread > > <http://www.openldap.org/lists/openldap-software/200512/msg00250.html> > > the author of the assertion control (Kurt :) believes the current > specification is flawed. In fact, the assertion control is intended > to > apply to the contents of the DIT. The entry does not belong to the > DIT > until the operation is completed, so assertion cannot apply. Those comments were in respect to the I-D (when it was a work in progress). The specification does allow for the control to be attached to Add requests. Though it might seem kind of pointless, a client might do it as it is not itself capable of evaluating some assertion. I would argue that it fine for a server which cannot handle the control in this (or other cases) to return unavailableCriticalExtension. The specification certainly doesn't require a server to make use of the control in cases where it might be asserted. This is not to say slapd(8) shouldn't be updated to make use of the control when provided with Add requests, just saying it's technically okay that it doesn't.

1 0

Re: (ITS#5863) assertion failed in ber_bvreplace_x() with translucent overlay
by ando＠sys-net.it 20 Dec '08

20 Dec '08

guillaume.pujol(a)eds.com wrote: > idassert-bind bindmethod=simple mode=self This line makes no sense. In fact, it assumes an empty DN ("anonymous") can authorize users. This idassert-bind statement should be invalid. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by ando＠sys-net.it 20 Dec '08

20 Dec '08

rlvcosta(a)yahoo.com wrote: > Full_Name: Rodrigo Costa > Version: 2.4.11 > OS: RHEL4 U4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (201.82.161.220) > > > Opeldap dev team, > > I'm facing an issue and after many tentatives I believe this is really a bug > that maybe could be identified and solved by openldap community. I tried to > include dmalloc into openldap 2.4.11 code but even I could compile with it any > tentative to execute the code generated "Segmentation Fault" so I could not use > dmalloc to identify where the memory leak is happening. Can you try with valgrind? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5858) Segfault with overlay ppolicy
by ando＠sys-net.it 20 Dec '08

20 Dec '08

A workaround is in HEAD. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5861) Assert control on Add request fails
by ando＠sys-net.it 20 Dec '08

20 Dec '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > RFC 4528 says the Assert control is appropriate for Add. Slapd disagrees: > > $ ldapadd -xhlocalhost:3890 -e\!assert='(objectClass=organization)' <test.ldif > adding new entry "o=test" > ldap_add: Critical extension is unavailable (12) > additional info: critical extension is unavailable According to this thread <http://www.openldap.org/lists/openldap-software/200512/msg00250.html> the author of the assertion control (Kurt :) believes the current specification is flawed. In fact, the assertion control is intended to apply to the contents of the DIT. The entry does not belong to the DIT until the operation is completed, so assertion cannot apply. > back-bdb and back-sql do not apply the assert control to Add. As per what seems to be the intention of the author of the specification (although it is in contrast with the current specification, RFC4528). > The message comes from slapd/controls.c. Don't fix that before fixing > Add in the backends, otherwise critical controls can be ignored. > > Another strangeness: overlays/syncprov.c applies the Assert control to > Compare but not other operations. I don't know why, there are no > comments about it. No clue. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5867) back-config does not return sizeLimitExceeded
by h.b.furuseth＠usit.uio.no 20 Dec '08

20 Dec '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard back-config obeys sizelimit, but returns success instead of sizeLimitExceeded. slapd.conf: database config access to * by * read sizelimit 2 $ ldapsearch -xhlocalhost:3890 -b cn=config 1.1 # extended LDIF # (...) # config dn: cn=config # schema, config dn: cn=schema,cn=config # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2

1 0

(ITS#5866) syncrepl : all entries not replicated (glue entryCSN problem)
by julien.combes＠i-carre.net 19 Dec '08

19 Dec '08

Full_Name: Julien Combes Version: 2.4.13 OS: debian 4.0 etch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.23.162.38) Hello, I am studying the migration of my architecture from 2.3.39 to 2.4.13. The provider is in 2.4.13. I have a problem with syncrepl (and delta-syncrepl) with two consumers in openldap 2.4.13 when I start them with an empty database : some entries are not replicated. A consumer with openldap 2.3.39 is not affected by the problem : all entries are replicated correctly. All consumers are using the same replication account. As I am in a testing environment, I have retried several times the test: every time, the same entries are not replicated on both consumers. All entries not replicated are "organizationalUnit" on the provider and have entries below them. All entries below them are correctly replicated. With a slapcat on the consumers I can see that the entries not replicated are "glue". Servers : -> provider : openldap 2.4.13, BDB 4.7.25 - number of entries : 191961 -> consumer-1 : openldap 2.4.13, BDB 4.7.25 - number of entries after replication : 191937 -> consumer-2 : openldap 2.4.13, BDB 4.7.25 - number of entries after replication : 191937 -> consumer-3 : openldap 2.3.39, BDB 4.2.52 - number of entries after replication : 191961 The logfile (sync, stats) indicate that : -> one entry below the organizationalUnit (not replicated) is replicated before the organizationalUnit itself Dec 18 18:18:17 consumer-2 slapd[13897]: syncrepl_entry: rid=003 mineqRDN=_uid_john.doe,ou=foo6,ou=foo5,ou=foo4,ou=foo3,ou=foo2,ou=foo,ou=bar,dc=my,dc=domain -> when it's the turn of this organizationalUnit to be replicated, the log indicate lignes like that : Dec 18 18:18:17 consumer-2 slapd[13897]: syncrepl_entry: rid=003 ou=foo6,ou=foo5,ou=foo4,ou=foo3,ou=foo2,ou=foo,ou=bar,dc=my,dc=domain Dec 18 18:18:17 consumer-2 slapd[13897]: syncrepl_entry: rid=003 be_add (68) Dec 18 18:18:17 consumer-2 slapd[13897]: dn_callback : new entry is older than ours ou=foo6,ou=foo5,ou=foo4,ou=foo3,ou=foo2,ou=foo,ou=bar,dc=my,dc=domain ours 20081204104512.468400Z#000000#000#000000, new 20081020233519.000000Z#000018#000#000000 Dec 18 18:18:17 consumer-2 slapd[13897]: syncrepl_entry: rid=003 entry unchanged, ignored (ou=foo6,ou=foo5,ou=foo4,ou=foo3,ou=foo2,ou=foo,ou=bar,dc=my,dc=domain) About the entryCSN of this log : -> "ours 20081204104512.468400Z#000000#000#000000" seems to be the entryCSN of the entry below replicated befor the organizationalUnit : On consumer-[12] : dn: mineqRDN=_uid_john.doe,ou=foo6,ou=foo5,ou=foo4,ou=foo3,ou=foo2,ou=foo,ou=bar,dc=my,dc=domain entryCSN: 20081204104512.468400Z#000000#000#000000 On Provider : dn: mineqRDN=_uid_john.doe,ou=foo6,ou=foo5,ou=foo4,ou=foo3,ou=foo2,ou=foo,ou=bar,dc=my,dc=domain entryCSN: 20081204104512.468400Z#000000#000#000000 -> "new 20081020233519.000000Z#000018#000#000000" is the entryCSN of the organisazionalUnit on the provider : dn: ou=foo6,ou=foo5,ou=foo4,ou=foo3,ou=foo2,ou=foo,ou=bar,dc=my,dc=domain entryCSN: 20081020233519.000000Z#000018#000#000000 All servers are a the same time. Configuration files : ===================================================================== provider : openldap 2.4.13, BDB 4.7.25 ===================================================================== include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/pamela.schema include /etc/ldap/schema/rfc2739.schema include /etc/ldap/schema/samba.schema sizelimit 5000 timelimit 10 pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats sync modulepath /usr/lib/ldap moduleload back_hdb moduleload syncprov moduleload accesslog moduleload back_monitor defaultsearchbase "dc=my,dc=domain" TLSCACertificateFile /etc/certs/CA_cert.pem TLSCertificateFile /etc/certs/provider.my.domain.pem TLSCertificateKeyFile /etc/certs/provider.my.domain.key access to dn.subtree="cn=monitor" by peername.ip=127.0.0.1 read by * none access to dn.subtree="cn=accesslog" by dn.base="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" read by dn.base="cn=syncuser.csac,ou=admin,ou=ressources,dc=my,dc=domain" read by * none access to attrs=userPassword by dn.base="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" write by dn.base="cn=syncuser.csac,ou=admin,ou=ressources,dc=my,dc=domain" read by anonymous auth by self write by * none access to * by dn.base="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" write by dn.base="cn=syncuser.csac,ou=admin,ou=ressources,dc=my,dc=domain" read by * read database hdb suffix "cn=accesslog" rootdn "cn=accesslog" directory "/var/lib/ldap/accesslog" index entryCSN,objectClass,reqEnd,reqResult,reqStart eq overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE limits dn.base="cn=syncuser.csac,ou=admin,ou=ressources,dc=my,dc=domain" size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited limits dn.base="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited database hdb suffix "dc=my,dc=domain" directory "/var/lib/ldap/database" cachesize 75000 cachefree 1000 idlcachesize 225000 heckpoint 512 10 index objectClass eq index mineqMelPartages,mineqLiensImport,mineqMelmailEmission,cn pres,eq,sub index mail pres,eq index uid,mineqMelMembres,employeeNumber,ou,gidnumber,uidNumber,mineqTypeEntree,sn,drink,aliasedObjectName,memberUid pres,eq index entryCSN,entryUUID eq lastmod on overlay syncprov syncprov-checkpoint 100 10 overlay accesslog logdb "cn=accesslog" logops writes logsuccess TRUE logpurge 07+00:00 01+00:00 limits dn.base="cn=syncuser.csac,ou=admin,ou=ressources,dc=my,dc=domain" size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited limits dn.base="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited database monitor ===================================================================== consumer-1 : openldap 2.4.13, BDB 4.7.25 ===================================================================== allow bind_v2 include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/pamela.schema include /etc/ldap/schema/rfc2739.schema include /etc/ldap/schema/samba.schema sizelimit 20000 pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats sync modulepath /usr/lib/ldap moduleload back_hdb moduleload back_monitor defaultsearchbase "dc=my,dc=domain" TLSCACertificateFile /etc/certs/CA_cert.pem TLSCertificateFile /etc/certs/consumer-01.my.domain.pem TLSCertificateKeyFile /etc/certs/consumer-01.my.domain.key access to dn.subtree="cn=monitor" by peername.ip=127.0.0.1 read by * none access to attrs=userPassword by dn="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" write by anonymous auth by self write by * none access to * by dn="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" write by * read database hdb suffix "dc=my,dc=domain" rootdn "dc=my,dc=domain" limits dn.exact="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited syncrepl rid=2 provider=ldaps://provider.my.domain type=refreshAndPersist retry="10 3 30 3 60 +" searchbase="dc=my,dc=domain" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=simple binddn="cn=syncuser.csac,ou=admin,ou=ressources,dc=my,dc=domain" credentials=<secret> logbase="cn=accesslog" syncdata=accesslog updateref ldaps://provider.my.domain directory "/var/lib/ldap/database" cachesize 75000 cachefree 1000 idlcachesize 225000 checkpoint 0 10 index objectClass eq index uid,mail pres,eq index cn pres,eq,sub index entryCSN,entryUUID eq lastmod on database monitor ===================================================================== consumer-2 : openldap 2.4.13, BDB 4.7.25 ===================================================================== include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/pamela.schema include /etc/ldap/schema/rfc2739.schema include /etc/ldap/schema/samba.schema sizelimit 5000 timelimit 10 pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats sync modulepath /usr/lib/ldap moduleload back_hdb moduleload back_monitor defaultsearchbase "dc=my,dc=domain" TLSCACertificateFile /etc/certs/CA_cert.pem TLSCertificateFile /etc/certs/consumer-02.my.domain.pem TLSCertificateKeyFile /etc/certs/consumer-02.my.domain.key access to dn.subtree="cn=monitor" by peername.ip=127.0.0.1 read by * none access to attrs=userPassword by dn.base="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" write by anonymous auth by self write by * none access to * by dn.base="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" write by * read database hdb suffix "dc=my,dc=domain" rootdn "dc=my,dc=domain" directory "/var/lib/ldap/database" cachesize 75000 cachefree 1000 idlcachesize 225000 checkpoint 512 10 index objectClass eq index mineqMelPartages,mineqLiensImport,mineqMelmailEmission,cn eq,sub index mail eq index uid,mineqMelMembres,employeeNumber,ou,gidnumber,uidNumber,mineqTypeEntree,sn,drink,aliasedObjectName,memberUid eq index entryCSN,entryUUID eq lastmod on syncrepl rid=3 provider=ldaps://provider.my.domain type=refreshAndPersist retry="10 3 30 3 60 +" searchbase="dc=my,dc=domain" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=simple binddn="cn=syncuser.csac,ou=admin,ou=ressources,dc=my,dc=domain" credentials=<secret> updateref ldaps://provider.my.domain limits dn.base="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited database monitor ===================================================================== consumer-3 : openldap 2.3.39, BDB 4.2.52 ===================================================================== allow bind_v2 include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/pamela.schema include /etc/ldap/schema/rfc2739.schema include /etc/ldap/schema/samba.schema schemacheck on sizelimit 20000 pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats sync modulepath /usr/lib/ldap moduleload back_hdb moduleload back_monitor defaultsearchbase "dc=my,dc=domain" TLSCACertificateFile /etc/certs/CA_cert.pem TLSCertificateFile /etc/certs/consumer-03.my.domain.pem TLSCertificateKeyFile /etc/certs/consumer-03.my.domain.key access to dn.subtree="cn=monitor" by peername.ip=127.0.0.1 read by * none access to attrs=userPassword by dn="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" write by anonymous auth by self write by * none access to * by dn="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" write by * read database hdb suffix "dc=my,dc=domain" rootdn "dc=my,dc=domain" limits dn.exact="cn=admin,ou=admin,ou=ressources,dc=my,dc=domain" size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited syncrepl rid=1 provider=ldaps://provider.my.domain type=refreshAndPersist retry="10 3 30 3 60 +" searchbase="dc=my,dc=domain" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=simple binddn="cn=syncuser.csac,ou=admin,ou=ressources,dc=my,dc=domain" credentials=<secret> logbase="cn=accesslog" syncdata=accesslog updateref ldaps://provider.my.domain directory "/var/lib/ldap/database" cachesize 75000 cachefree 1000 idlcachesize 225000 checkpoint 0 10 index objectClass eq index uid,mail eq index cn eq,sub index entryCSN,entryUUID eq lastmod on database monitor Regards, Julien

1 0

Re: (ITS#5858) Segfault with overlay ppolicy
by maniac＠maniac.nl 18 Dec '08

18 Dec '08

This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_server11-8238-1229608279-0001-2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I've figured it out... I got everything working now with 2.4.13. I had the overlay configured before the database definition... this caused the segfault. This same setup didn't segfault on 2.3.x, but still didn't work. Once I got it working on 2.3.x I migrated my config back to 2.4.13, and it works again. Still, openldap shouldn't segfault on something like this, but I am a happy camper again. Mark --=_server11-8238-1229608279-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAklKVVcACgkQb6urvDV9IXjZdwCdFnV9JBfHsdiHDGunptLUs25H VJwAn3m2OQQ/lo/yJ6Z/KwWkmOqGRlZV =A0Pg -----END PGP SIGNATURE----- --=_server11-8238-1229608279-0001-2--

1 0

Re: (ITS#5859) back-hdb entrycache problem
by rhafer＠suse.de 17 Dec '08

17 Dec '08

Am Mittwoch 17 Dezember 2008 15:03:49 schrieb rhafer(a)suse.de: > This problem seems to be only present when using an empty suffix. I wasn't > able to reproduce it with a non-empty suffix at least. > > It seems to be a problem with the idlcache. After setting "idlcachesize" to > 0 the problem went a way for me. > > And yes, it seems to have been in the RE24 tree for a longer time already > (2.4.12 was affected as well). Digging a bit deeper into this, I found that only back-hdb is affected and that it is most probably a bug in hdb_dn2id_add(). It seems that after adding a new entry, hdb_dn2id_add() fails to correctly update the IDLs in the idl- cache for the entry's parent entries. The following patch seems to fix the problem for me: --- dn2id.c 31 Oct 2008 23:23:59 -0000 1.137.2.13 +++ dn2id.c 17 Dec 2008 19:45:32 -0000 @@ -620,6 +620,11 @@ tmp[1] = eip->bei_id; bdb_idl_cache_add_id( bdb, db, &key, e->e_id ); } + if ( !op->o_bd->be_suffix[0].bv_len && eip) + { + tmp[1] = eip->bei_id; + bdb_idl_cache_add_id( bdb, db, &key, e->e_id ); + } } } I suspect that hdb_dn2id_delete() has a similar issue. -- Ralf

1 0

Re: (ITS#5859) back-hdb entrycache problem
by rhafer＠suse.de 17 Dec '08

17 Dec '08

This problem seems to be only present when using an empty suffix. I wasn't able to reproduce it with a non-empty suffix at least. It seems to be a problem with the idlcache. After setting "idlcachesize" to 0 the problem went a way for me. And yes, it seems to have been in the RE24 tree for a longer time already (2.4.12 was affected as well). -- Ralf

1 0

← Newer
1
2
3
4
5
6
7
8
...
14
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 December 2008