openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

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

Re: (ITS#7405) Improve refint documentation
by hyc＠symas.com 27 Sep '12

27 Sep '12

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.32 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.196.25.250) > > > As per debian bug#688857: > > Modifications made by refint are not replicated. They neither update the > modification timestamp nor the CSN used for replication. This is serious > data loss, because the replicas gets out of sync pretty quickly. There > seems to be no way to recover from this discrepancy without doing a > complete replication. > > While this seems to be known, it is not documented at all in the > man-pages related to the refint and memberof overlays. Also it violates > the principle of least surprise, because the changes are not limited to > operational attributes. slapo-refint(5) manpage updated in master. slapo-memberof(5) was updated in 2.4.26 (ITS#6915) so at least that part of the bug report is invalid. -- -- 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

(ITS#7405) Improve refint documentation
by quanah＠OpenLDAP.org 26 Sep '12

26 Sep '12

Full_Name: Quanah Gibson-Mount Version: 2.4.32 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.196.25.250) As per debian bug#688857: Modifications made by refint are not replicated. They neither update the modification timestamp nor the CSN used for replication. This is serious data loss, because the replicas gets out of sync pretty quickly. There seems to be no way to recover from this discrepancy without doing a complete replication. While this seems to be known, it is not documented at all in the man-pages related to the refint and memberof overlays. Also it violates the principle of least surprise, because the changes are not limited to operational attributes.

1 0

Re: (ITS#7404) back-ldap connection cache error
by hyc＠symas.com 26 Sep '12

26 Sep '12

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: RE24/master > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (37.19.96.255) > Submitted by: hyc > > > back-ldap resets the local DN of a connection after a Bind request, even if the > Bind failed. Subsequent operations for that DN will reuse this connection, even > though it hasn't bound successfully. This is clearly wrong. Hm, false alarm. back-ldap is correct here. Something else is lying about its identity... -- -- 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

(ITS#7404) back-ldap connection cache error
by hyc＠OpenLDAP.org 26 Sep '12

26 Sep '12

Full_Name: Howard Chu Version: RE24/master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.19.96.255) Submitted by: hyc back-ldap resets the local DN of a connection after a Bind request, even if the Bind failed. Subsequent operations for that DN will reuse this connection, even though it hasn't bound successfully. This is clearly wrong.

1 0

(ITS#7403) back-ldap idassert always overrides
by hyc＠OpenLDAP.org 26 Sep '12

26 Sep '12

Full_Name: Howard Chu Version: RE24/master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.19.96.255) Submitted by: hyc If an idassert-bind directive has been configured, idassert processing is always performed, even if a direct bind has occurred. In effect, back-ldap always behaves as if flags=override was set in the idassert configuration. This is not the documented or intended behavior. A fix is coming shortly.

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