openldap-bugs

openldap-bugs@openldap.org

1 participants
20962 discussions

Re: (ITS#7407) (&(>=)(<=)) filter does not honor upper bound (<=)
by devel＠romanr.info 28 Sep '12

28 Sep '12

I've just noticed, that there are subclasses that match the filter criteria. I.e. (attr1>=100) filter part matched attr1 attribute, but (attr1<=200) matched some attr2 (attr2=42) attribute in the same object, and attr2 is a subclass of attr1. This is probably not a bug, better I'll ask the mail-list.

1 0

Re: (ITS#7406) Search with scope for newer entries don't work
by quanah＠zimbra.com 28 Sep '12

28 Sep '12

--On Friday, September 28, 2012 10:04 AM +0000 a.stefanello(a)mclink.eu wrote: > Full_Name: Andrea Stefanello > Version: 2.4.23-r1 Use a current openldap build. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7407) (&(>=)(<=)) filter does not honor upper bound (<=)
by devel＠romanr.info 28 Sep '12

28 Sep '12

Full_Name: Roman Rybalko Version: git a1c2dc6 OS: Linux Debian x64 URL: ftp://ftp.openldap.org/incoming/romanr-120928.tgz Submission from: (NULL) (82.146.61.98) olcAttributeTypes: ( 2.999.777.1.1.1.3 NAME 'logOrderingInteger' DESC 'Integer with ordering' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) olcAttributeTypes: ( 2.999.777.1.1.2.16 NAME 'logTimeInteger' DESC 'Integer time representation' SUP logOrderingInteger ) olcDbIndex: logTimeInteger Search filter (&(logTimeInteger>=1348137600)(logTimeInteger<=1348137620)) provides entries with logTimeInteger>1348137620. Should be only entries with logTimeInteger>=1348137600 and logTimeInteger<=1348137620. See data on ftp.

1 0

(ITS#7406) Search with scope for newer entries don't work
by a.stefanello＠mclink.eu 28 Sep '12

28 Sep '12

Full_Name: Andrea Stefanello Version: 2.4.23-r1 OS: Gentoo Base System release 1.12.14 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.21.176.129) Hi, i have this problem , searching a just created entries using base DN OU doesn't works, searching with his real base DN works. This happened with all new entries. This is an example : SEARCH USING BASE ou=mail : #ldapsearch -b ou=mail,OTHER OU-ROOTDN mailaddress=MAILADDRESS doesn't find nothing . SEARCH USING BASE cn=DOMAIN.COM,ou=mail,OTHER OU-ROOTDN : #ldapsearch -b cn=DOMAIN.COM,ou=mail,OTHER OU-ROOTDN mailaddress=MAILADDRESS find the entry. The scope used is "sub". After a couple of hour(i think 2 hours) the entry can be found even with the first query, using the "contenitor" ou just like somethings appenned inside the DB. There is a way to find out why we have this behaviour ? Can it be a index problem ? (mailAddress index is ok otherwise the second query shall not work, right?) Can i force something on ldap to resync something inside to find the entry just after is creation ? Thanks for your answer.

1 0

RE: (ITS#7401) OpenLDAP 2.4.32 - deadlock issues
by vb4607＠att.com 27 Sep '12

27 Sep '12

Thanks, Quanah. We will try this version and see how it performs. Venkatesh -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Tuesday, September 25, 2012 1:12 PM To: BAGLODI, VENKATESH; openldap-its(a)openldap.org Subject: RE: (ITS#7401) OpenLDAP 2.4.32 - deadlock issues --On Tuesday, September 25, 2012 4:22 PM +0000 vb4607(a)att.com wrote: > Thank you so much for the quick reply. We are a bit hesitant to try > 4.7.25 as it is a 4 year old product. What about version 5.1 (5.1.29) as > it is mentioned on your Web site > (http://www.openldap.org/software/release/readme.html)? I've been using BDB 4.7.25 (+all patches) for several years, and it has been quite stable. No deadlocks. This version is used on all Zimbra deployments across the world, with plenty of customers having millions of entry DBs. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7384) Assert Crash in ppolicy_ctrls_cleanup
by ghola＠rebelbase.com 27 Sep '12

27 Sep '12

I'll have to see if I can track down stderr when this happens. Here is the configuration on that host: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/custom.schema include /etc/openldap/schema/ldapux.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/puppet.schema TLSVerifyClient never TLSCertificateFile /etc/openldap/slapd.pem TLSCertificateKeyFile /etc/openldap/slapd.pem TLSCACertificateFile /etc/openldap/ca.pem pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args loglevel sync reverse-lookup on # old ACLs include /etc/openldap/legacy.acl # new ACLs include /etc/openldap/new.acl # Allow anonymous access to userPassword for directory binds access to dn.onelevel="ou=users,dc=example2,dc=net" attrs="userPassword" by anonymous auth by self read by * none # Secure unix passwords access to dn.onelevel="ou=users,ou=posix,dc=example2,dc=net" attrs="userPassword" by self read by * none # Secure unix passwords # legacy access to dn.onelevel="ou=people,dc=example,dc=com" attrs="userPassword" by self read by * none access to dn.onelevel="ou=people,dc=example2,dc=net" attrs="userPassword" by self read by * none # posix info is public access to dn.subtree="ou=posix,dc=example2,dc=net" by * read # posix info is public # legacy access to dn.subtree="ou=people,dc=example,dc=com" by * read access to dn.subtree="ou=people,dc=example2,dc=net" by * read access to dn.subtree="ou=group,dc=example2,dc=net" by * read # access to the base dn access to dn.base="dc=example2,dc=net" by * read # access to the base dn # legacy access to dn.base="dc=example,dc=com" by * none # basic access # legacy access to dn.subtree="dc=example,dc=com" by * none # basic access access to * by users read by * none database hdb suffix "dc=example2,dc=net" rootdn "cn=manager,dc=example2,dc=net" rootpw password index objectClass,uidNumber,gidNumber eq index cn,sn,uid,displayName pres,sub,eq index memberUid,mail,givenname eq,subinitial index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq index entryUUID,modifyTimestamp eq index location eq index service subinitial index uniqueMember eq directory /var/lib/ldap sizelimit unlimited cachesize 1000000 idlcachesize 3000000 overlay ppolicy ppolicy_default cn=default,ou=ppolicy,dc=example2,dc=net syncrepl rid=1 provider=ldap://syncrepl.example2.net:389 type=refreshAndPersist searchbase="dc=example2,dc=net" bindmethod=simple binddn=user=sync-user,ou=users,dc=example2,dc=net starttls=critical credentials=password retry="10 100 300 +" database relay suffix "dc=example,dc=com" overlay rwm rwm-suffixmassage "dc=example,dc=com" "dc=example2,dc=net" overlay ppolicy ppolicy_default cn=default,ou=ppolicy,dc=example2,dc=net

1 0

Re: (ITS#7384) Assert Crash in ppolicy_ctrls_cleanup
by hyc＠symas.com 27 Sep '12

27 Sep '12

ghola(a)rebelbase.com wrote: > Full_Name: Duncan Idaho > Version: 2.4.32 > OS: Centos 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.148.0.72) > > > We are seeing this a few times a week in our environment. Can you provide a sample config to reproduce the issue? What is the exact error message on stderr that accompanies this assert? > #0 0x0000003874c30265 in raise () from /lib64/libc.so.6 > #1 0x0000003874c31d10 in abort () from /lib64/libc.so.6 > #2 0x0000003874c296e6 in __assert_fail () from /lib64/libc.so.6 > #3 0x000000000055c369 in ctrls_cleanup (op=0x11144d40, rs=0x42e3cc10, > oldctrls=0x11251620) at ppolicy.c:870 > #4 0x000000000055c4aa in ppolicy_ctrls_cleanup (op=0x11144d40, rs=0x42e3cc10) > at ppolicy.c:895 > #5 0x0000000000442a46 in slap_cleanup_play (op=0x11144d40, rs=0x42e3cc10) at > result.c:541 > #6 0x0000000000443229 in send_ldap_response (op=0x11144d40, rs=0x42e3cc10) at > result.c:733 > #7 0x0000000000443a5d in slap_send_ldap_result (op=0x11144d40, rs=0x42e3cc10) > at result.c:860 > #8 0x000000000052d7d7 in hdb_bind (op=0x11144d40, rs=0x42e3cc10) at bind.c:158 > #9 0x00000000004bc67a in overlay_op_walk (op=0x11144d40, rs=0x42e3cc10, > which=op_bind, oi=0x10af8670, on=0x0) at backover.c:671 > #10 0x00000000004bc87d in over_op_func (op=0x11144d40, rs=0x42e3cc10, > which=op_bind) at backover.c:723 > #11 0x00000000004bc903 in over_op_bind (op=0x11144d40, rs=0x42e3cc10) at > backover.c:738 > #12 0x0000000000514136 in relay_back_op (op=0x11144d40, rs=0x42e3cc10, which=0) > at op.c:210 > #13 0x00000000005142b9 in relay_back_op_bind (op=0x11144d40, rs=0x42e3cc10) at > op.c:243 > #14 0x00000000004bc67a in overlay_op_walk (op=0x11144d40, rs=0x42e3cc10, > which=op_bind, oi=0x10af97f0, on=0x0) at backover.c:671 > #15 0x00000000004bc87d in over_op_func (op=0x11144d40, rs=0x42e3cc10, > which=op_bind) at backover.c:723 > #16 0x00000000004bc903 in over_op_bind (op=0x11144d40, rs=0x42e3cc10) at > backover.c:738 > #17 0x000000000045520d in fe_op_bind (op=0x11144d40, rs=0x42e3cc10) at > bind.c:383 > #18 0x000000000045493c in do_bind (op=0x11144d40, rs=0x42e3cc10) at bind.c:205 > #19 0x000000000042cbd4 in connection_operation (ctx=0x42e3cd60, > arg_v=0x11144d40) at connection.c:1150 > #20 0x000000000042d159 in connection_read_thread (ctx=0x42e3cd60, argv=0xc7) at > connection.c:1286 > #21 0x000000000058c6c1 in ldap_int_thread_pool_wrapper (xpool=0x109dfe80) at > tpool.c:688 > #22 0x000000387540673d in start_thread () from /lib64/libpthread.so.0 > #23 0x0000003874cd3d1d in clone () from /lib64/libc.so.6 > #24 0x0000000000000000 in ?? () > > -- -- 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#7399) ¡¾Syncrepl¡¿when consumer doing the syncrepl with the provider, reboot the consumer, the cusummer does not continue the task any more
by hyc＠symas.com 27 Sep '12

27 Sep '12

xinrong.li(a)163.com wrote: > Full_Name: mark > Version: 2.4.20 > OS: sles11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (113.116.144.106) > > The current version is 2.4.32. Bugs in old versions will not be investigated. If you can still encounter this issue in the current release, we can work from there. For now this ITS will be closed. > I meet some problem when doing as following: > --> consumer and provider OK. mean that if you add/delete some records to > provider, consumer will sync with the provder > > --> let consumer ldap service stop > --> provider add 100 records > --> consumer start and it will begin to sync the 100 records from provider > --> consumer restart when have sync 60 records from provider > --> consumer wounld not Syncrepl the rest 40 records from provider > > --> then, you add or delete some records, consumer will sync with provider OK > except the 40 records > > May anyone give me some help? thanks! > > my slapd.conf content is thus: > > provider: > database bdb > suffix dc=Example,dc=com > rootdn dc=Example,dc=com > directory /var/ldap/db > index objectclass,entryCSN,entryUUID eq > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > comsumer: > database hdb > suffix dc=Example,dc=com > rootdn dc=Example,dc=com > directory /var/ldap/db > index objectclass,entryCSN,entryUUID eq > > syncrepl rid=123 > provider=ldap://provider.example.com:389 > type=refreshOnly > interval=01:00:00:00 > searchbase="dc=example,dc=com" > filter="(objectClass=organizationalPerson)" > scope=sub > attrs="cn,sn,ou,telephoneNumber,title,l" > schemachecking=off > bindmethod=simple > binddn="cn=syncuser,dc=example,dc=com" > credentials=secret > > > > -- -- 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#7246) Addition of FedFS schema LDIF
by chuck.lever＠oracle.com 27 Sep '12

27 Sep '12

It appears that the schema LDIF files shipped with OpenLDAP are strictly for basic LDAP attribute type and object class definitions. Everything else is considered a "user schema," including schemas for implementing a DNS or NIS backend, and so on. It appears to me that FedFS would fall into this latter category, and thus should not be included in the packaged schema. Comments?

1 0

Re: (ITS#7385) back_mdb ENOSPC error returned from mdb_node_add incorrectly
by hyc＠symas.com 27 Sep '12

27 Sep '12

marco(a)schirrmeister.net wrote: > On Sep 18, 2012, at 1:59 PM, hyc(a)symas.com wrote: > >> Marco Schirrmeister wrote: >>> I pulled latest RE24 on Sep 15th and now I get this. >>> >>> ... >>> indexing id=00010d0e >>> indexing id=00010d0f >>> 5056de89 => mdb_tool_entry_reindex: txn_commit failed: Unknown error 18446744073709520830 (-30786) >> >> That was fixed yesterday in commit 8bb10add2465eee34e79abeaa62011e3e234effb. >> Please pull RE24 again today and try again, it should all be working fine. > > Just tested with latest RE24 > > indexing id=00010d0e > indexing id=00010d0f > 50587b72 => mdb_tool_entry_reindex: txn_commit failed: MDB_PAGE_FULL: Internal error - page has no more space (-30786) Thanks for your help, this is now fixed in master. -- -- 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

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