Re: (ITS#7400) Memberof and Syncrepl incompatibility
by hyc＠symas.com
arunkumar_1123(a)yahoo.com wrote:
> Full_Name: Arunkumar shanmugam
> Version: 2.4.29
> OS: rhel5
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (203.83.248.32)
>
>
> Hi,
>
> I'm currently using Openldap 2.4.29 to model an Authorization platform. I
> noticed some inconsistent behavior with syncrepl and memberof overlays.
Does this issue occur with the current release, 2.4.32?
>
> The issue happens as follows:
>
> If I Create groups with a large number of members and delete them in quick
> succession on the writemaster, the data replicated to the readslave is
> incorrect, in particular, the memberof fields of the User objects.
>
> This seems to happen because the memberof field is getting replicated to the
> slave nodes, although the documentation states that it shouldn't.
Indeed. Do you have debug logs showing the replication traffic, and showing
that the memberof attribute got replicated?
> While
> replicating, the User object is replicated inclusive of the memberof fields, but
> by the time the syncrepl search comes to the group object, it has already been
> deleted, and hence not replicated. This leaves a dangling memberof field in the
> read slave instance.
>
> I was wondering if anyone has faced this issues (I did not see any ITS related
> to this), and has a workaround.
>
> Thanks,
> Arunkumar
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years, 12 months
Re: (ITS#7407) (&(>=)(<=)) filter does not honor upper bound (<=)
by devel＠romanr.info
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.
10 years, 12 months
Re: (ITS#7406) Search with scope for newer entries don't work
by quanah＠zimbra.com
--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
10 years, 12 months
(ITS#7407) (&(>=)(<=)) filter does not honor upper bound (<=)
by devel＠romanr.info
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.
10 years, 12 months
(ITS#7406) Search with scope for newer entries don't work
by a.stefanello＠mclink.eu
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.
10 years, 12 months
RE: (ITS#7401) OpenLDAP 2.4.32 - deadlock issues
by vb4607＠att.com
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
10 years, 12 months
Re: (ITS#7384) Assert Crash in ppolicy_ctrls_cleanup
by ghola＠rebelbase.com
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
10 years, 12 months
Re: (ITS#7384) Assert Crash in ppolicy_ctrls_cleanup
by hyc＠symas.com
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/
10 years, 12 months
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
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/
10 years, 12 months
