openldap-bugs October 2012

openldap-bugs@openldap.org

29 participants
84 discussions

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites

by hyc＠symas.com

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: git master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20120823-moznss-update-list-of-ci... > Submission from: (NULL) (209.132.186.34) > > > I'm attaching patch which updates the list of supported cipher suites for > Mozilla NSS backend. All ciphers currently implemented in NSS (3.13.5) are > included. Recall what I said in ITS#7388 about an endless stream of patches to an unmaintainable code base... This is completely the wrong approach. There is no way you should be putting hardcoded constants in libldap that are tied to specific MozNSS versions. The MozNSS library needs to provide a cipher enumerator API. There were 11 MozNSS patches in 2.4.32. Looks like 5 more waiting for review here, plus 2 already committed for 2.4.33. We will not accept patches that require constant revisiting every time NSS updates. This is too much. No more. Tell the NSS guys to fix their design, or tell Red Hat to use a crypto library that actually works for the intended purpose. MozNSS clearly doesn't. > Default ciphers are selected on the same basis as in OpenSSL. > NULL/EXPORT/LOW/MEDIUM/HIGH classification is taken from OpenSSL as well. > > > The attached file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by Red > Hat. Red Hat has not assigned rights and/or interest in this work to any party. > I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under > the following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software (and only > these modifications) into the public domain. Hence, these modifications may be > freely used and/or redistributed for any purpose with or without attribution > and/or other notice. > > -- -- 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, 11 months

1
0
0 / 0

Re: (ITS#7400) Memberof and Syncrepl incompatibility

by hyc＠symas.com

arun s wrote: > Hi, > Yes, I am able to reproduce the issue with 2.4.32 > > Making sense of the logs for the exact reproduction is hard since it needs a > lot of operations in a short time. But this will probably help: > > 1. At the start of the test, the group temp_group existed. > > 2. I created a user temp_user and added temp_user to temp_group. > > 3. During replication, the group was replicated first and I got an error 32 > (NO_SUCH_OBJECT) when it tried to modify the memberOf of the temp_user object > (This does not exist in the readslave yet). > > 4. The temp_user object was replicated next, and as you see, querying it does > show a memberOf attribute, proving that this field was replicated. (Note that > I have run OpenLDAP with debug as -1 and verified that the replicated data has > the memberOf field in it. I can provide this too if needed.) I see. The current code drops the memberOf attribute if it was not explicitly requested in the search. However, by default the consumer requests "+" which means "all operational attributes" and so slapd considers memberOf to have been requested. We need to reconsider this aspect of the design. > > 5. The more serious problem occurs when the sequence is reversed and the group > has been deleted as a last operation - The user is replicated first, but since > the group is deleted, it is never replicated and a stale memberOf entry stays > with the user. -- -- 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, 11 months

1
0
0 / 0

Re: (ITS#7400) Memberof and Syncrepl incompatibility

by arunkumar_1123＠yahoo.com

---872237384-2137566121-1349092304=:39209 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0AYes, I am able to reproduce the issue with 2.4.32=0A=0A=0AMaking sens= e of the logs for the exact reproduction is hard since it needs a lot of op= erations in a short time. But this will probably help:=0A=0A1. At the start= of the test, the group temp_group existed.=0A=0A2. I created a user temp_u= ser and added temp_user to temp_group.=0A=0A3. During replication, the grou= p was replicated first and I got an error 32 (NO_SUCH_OBJECT) when it tried= to modify the memberOf of the temp_user object (This does not exist in the= readslave yet).=0A=0A4. The temp_user object was replicated next, and as y= ou see, querying it does show a memberOf attribute, proving that this field= was replicated. (Note that I have run OpenLDAP with debug as -1 and verifi= ed that the replicated data has the memberOf field in it. I can provide thi= s too if needed.)=0A=0A5. The more serious problem occurs when the sequence= is reversed and the group has been deleted as a last operation - The user = is replicated first, but since the group is deleted, it is never replicated= and a stale memberOf entry stays with the user.=0A=0A=0ALOGS:=0A=0A5069157= c syncrepl_message_to_entry: rid=3D179 DN: ou=3Dtemp_group,ou=3Dgroup,dc=3D= example,dc=3Dcom, UUID: 31090ab1-f8a7-4363-83c2-c0ac0d3918d4=0A5069157c syn= crepl_entry: rid=3D179 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)=0A5069157c sync= repl_entry: rid=3D179 inserted UUID 31090ab1-f8a7-4363-83c2-c0ac0d3918d4=0A= 5069157c syncrepl_entry: rid=3D179 be_search (0)=0A5069157c syncrepl_entry:= rid=3D179 ou=3Dtemp_group,ou=3Dgroup,dc=3Dexample,dc=3Dcom=0A5069157c slap= _queue_csn: queing 0x4270c730 20121001040100.779862Z#000000#000#000000=0A50= 69157c slap_graduate_commit_csn: removing 0xfa035c0 20121001040100.779862Z#= 000000#000#000000=0A5069157c conn=3D-1 op=3D0: memberof_value_modify DN=3D"= uid=3Dtemp_user,dc=3Dexample,dc=3Dcom" add memberOf=3D"ou=3Dtemp_group,ou= =3Dgroup,dc=3Dexample,dc=3Dcom" failed err=3D32=0A5069157c syncrepl_entry: = rid=3D179 be_modify ou=3Dtemp_group,ou=3Dgroup,dc=3Dexample,dc=3Dcom (0)=0A= 5069157c syncrepl_message_to_entry: rid=3D179 DN: uid=3Dtemp_user,dc=3Dexam= ple,dc=3Dcom, UUID: 748bd1a9-6be3-450b-809c-5ea692aa073c=0A5069157c syncrep= l_entry: rid=3D179 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)=0A5069157c syncrepl= _entry: rid=3D179 inserted UUID 748bd1a9-6be3-450b-809c-5ea692aa073c=0A5069= 157c syncrepl_entry: rid=3D179 be_search (0)=0A5069157c syncrepl_entry: rid= =3D179 uid=3Dtemp_user,dc=3Dexample,dc=3Dcom=0A5069157c syncrepl_entry: rid= =3D179 be_add uid=3Dtemp_user,dc=3Dexample,dc=3Dcom (0)=0A=0AThe object tem= p_user:=0A=0Adn: uid=3Dtemp_user,dc=3Dexample,dc=3Dcom=0AmemberOf: ou=3Dtem= p_group,ou=3Dgroup,dc=3Dexample,dc=3Dcom=0A=0A=0AWhat is interesting is tha= t in this case, the memberOf field being replicated actually protects the s= lave from incorrect data as the temp_user entry was not present at the time= the group got replicated (The user entry was the second entry in the repli= cation order). On the other hand, a reversed path during replication causes= the mentioned bug.=0A=0AThanks=0A=0A=0A=0A________________________________= =0A From: Howard Chu <hyc(a)symas.com>=0ATo: arunkumar_1123(a)yahoo.com =0ACc: = openldap-its(a)openldap.org =0ASent: Sunday, 30 September 2012 8:51 PM=0ASubj= ect: Re: (ITS#7400) Memberof and Syncrepl incompatibility=0A =0Aarunkumar_1= 123(a)yahoo.com wrote:=0A> Full_Name: Arunkumar shanmugam=0A> Version: 2.4.29= =0A> OS: rhel5=0A> URL: ftp://ftp.openldap.org/incoming/=0A> Submission fro= m: (NULL) (203.83.248.32)=0A>=0A>=0A> Hi,=0A>=0A> I'm currently using Openl= dap 2.4.29 to model an Authorization platform. I=0A> noticed some inconsist= ent behavior with syncrepl and memberof overlays.=0A=0ADoes this issue occu= r with the current release, 2.4.32?=0A>=0A> The issue happens as follows:= =0A>=0A> If I Create groups with a large number of members and delete them = in quick=0A> succession on the writemaster, the data replicated to the read= slave is=0A> incorrect, in particular, the memberof fields of the User obje= cts.=0A>=0A> This seems to happen because the memberof field is getting rep= licated to the=0A> slave nodes, although the documentation states that it s= houldn't.=0A=0AIndeed. Do you have debug logs showing the replication traff= ic, and showing =0Athat the memberof attribute got replicated?=0A=0A> While= =0A> replicating, the User object is replicated inclusive of the memberof f= ields, but=0A> by the time the syncrepl search comes to the group object, i= t has already been=0A> deleted, and hence not replicated. This leaves a dan= gling memberof field in the=0A> read slave instance.=0A>=0A> I was wonderin= g if anyone has faced this issues (I did not see any ITS related=0A> to thi= s), and has a workaround.=0A>=0A> Thanks,=0A> Arunkumar=0A>=0A>=0A=0A=0A-- = =0A=A0 -- Howard Chu=0A=A0 CTO, Symas Corp.=A0 =A0 =A0 =A0 =A0 http://www= .symas.com=0A=A0 Director, Highland Sun=A0 =A0 http://highlandsun.com/hyc/= =0A=A0 Chief Architect, OpenLDAP=A0 http://www.openldap.org/project/ ---872237384-2137566121-1349092304=:39209 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:ti= mes new roman, new york, times, serif;font-size:12pt"><div>Hi,</div><div style=3D"colo= r: rgb(69, 69, 69); font-size: 13px; font-family: arial, helvetica, sans-se= rif; background-color: transparent; font-style: normal; ">=09Yes, I am able to reproduce the issue with = 2.4.32 </div><div style=3D"color: rgb(69, 69, 69); font-size: 13p= x; font-family: arial, helvetica, sans-serif; background-color: transparent= ; font-style: normal; "> Making = sense of the logs for the exact reproduction is hard since it needs a lot o= f operations in a short time. But this will probably help: 1. At the = start of the test, the group temp_group existed. 2. I created a user t= emp_user and added temp_user to temp_group. 3. During replication, the group= was replicated first and I got an error 32 (NO_SUCH_OBJECT) when it tried = to modify the memberOf of the temp_user object (This does not exist in the = readslave yet). <span= style=3D"color: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif= ; font-size: 13px; ">4. The temp_user object was replicated next, and as yo= u see, querying it does show a memberOf attribute, proving that this field = was replicated. (Note that I have run OpenLDAP with debug as -1 and verifie= d that the replicated data has the memberOf field in it. I can provide this = too if needed.) <span= style=3D"color: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif= ; font-size: 13px; ">5. The more serious problem occurs when the sequence i= s reversed and the group has been deleted as a last operation - The user is= replicated first, but since the group is deleted, it is never replicated a= nd a stale memberOf entry stays with the user. LOG= S: 5069157c syncrepl_message_to_entry: rid=3D179 DN: ou=3Dtemp_group,o= u=3Dgroup,dc=3Dexample,dc=3Dcom, UUID: 31090ab1-f8a7-4363-83c2-c0ac0d3918d4= 5069157c syncrepl_= entry: rid=3D179 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) 5069157c syncrepl_entry: rid=3D179 inserted UUID 31090a= b1-f8a7-4363-83c2-c0ac0d3918d4 5069157c syncrepl_entry: rid=3D179 be_search (0) 5069157c syncrepl_entry: rid=3D17= 9 ou=3Dtemp_group,ou=3Dgroup,dc=3Dexample,dc=3Dcom 5069157c slap_queue_csn: queing 0x4270c730 = 20121001040100.779862Z#000000#000#000000 5069157c slap_graduate_commit_csn: removing 0xfa035c0 20121001040100.77986= 2Z#000000#000#000000 5069157c conn=3D-1 op=3D0: memberof_value_modify DN=3D"uid=3Dtemp_user,dc= =3Dexample,dc=3Dcom" add memberOf=3D"ou=3Dtemp_group,ou=3Dgroup,dc=3Dexampl= e,dc=3Dcom" failed err=3D32 5069157c syncrepl_entry: rid=3D179 be_modify ou=3Dtemp_group,ou=3D= group,dc=3Dexample,dc=3Dcom (0) 5069157c syncrepl= _message_to_entry: rid=3D179 DN: uid=3Dtemp_user,dc=3Dexample,dc=3Dcom, UUI= D: 748bd1a9-6be3-450b-809c-5ea692aa073c <span= style=3D"color: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif= ; font-size: 13px; ">5069157c syncrepl_entry: rid=3D179 LDAP_RES_SEARCH_ENT= RY(LDAP_SYNC_ADD) 5= 069157c syncrepl_entry: rid=3D179 inserted UUID 748bd1a9-6be3-450b-809c-5ea= 692aa073c 5069157c syncrepl_entry: = rid=3D179 be_search (0) 5069157c syncrepl_entry: rid=3D179 uid=3Dtemp_user,dc=3Dexample,dc=3Dc= om 5069157c syncrep= l_entry: rid=3D179 be_add uid=3Dtemp_user,dc=3Dexample,dc=3Dcom (0)<= br style=3D"color: rgb(69, 69, 69); font-family: arial, helvetica, sans-ser= if; font-size: 13px; "> Th= e object temp_user: dn: uid=3Dtemp_user,dc=3Dexample,dc=3Dcom memberOf: ou=3Dtemp_group,ou=3Dgro= up,dc=3Dexample,dc=3Dcom What is interesting is that in this case, t= he memberOf field being replicated actually protects the slave from incorre= ct data as the temp_user entry was not present at the time the group got re= plicated (The user entry was the second entry in the replication order). On= the other hand, a reversed path during replication causes the mentioned bu= g. Thanks</div><div> </div> <div style=3D"font-famil= y: 'times new roman', 'new york', times, serif; font-size: 12pt; "> <div st= yle=3D"font-family: 'times new roman', 'new york', times, serif; font-size:= 12pt; "> <div dir=3D"ltr"> <hr size=3D"1"= > From: Howard Chu <hyc(a)symas.com&= gt; To: arunkumar_1123= @yahoo.com Cc: openlda= p-its(a)openldap.org Sent:<= /b> Sunday, 30 September 2012 8:51 PM Subject: Re: (ITS#7400) Memberof and Syncrepl incompatibili= ty </div> <a ymailto=3D"mailto:arunkumar_1123@yahoo.com" hr= ef=3D"mailto:arunkumar_1123@yahoo.com">arunkumar_1123(a)yahoo.com</a> wrote:<= br>> Full_Name: Arunkumar shanmugam > Version: 2.4.29 > OS: = rhel5 > URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_= blank">ftp://ftp.openldap.org/incoming/</a> > 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 thi= s issue occur with the current release, 2.4.32? > > The issue h= appens as follows: > > If I Create groups with a large number o= f members and delete them in quick > succession on the writemaster, t= he data replicated to the readslave is > incorrect, in particular, th= e memberof fields of the User objects. > > This seems to happen= because the memberof field is getting replicated to the > slave node= s, although the documentation states that it shouldn't. Indeed. Do y= ou have debug logs showing the replication traffic, and showing that th= e memberof attribute got replicated? > While > replicating,= the User object is replicated inclusive of the memberof fields, but &gt= ; 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. > &gt= ; I was wondering if anyone has faced this issues (I did not see any ITS re= lated > to this), and has a workaround. > > Thanks, &g= t; Arunkumar > > --   -- Howard Chu &nb= sp; CTO, Symas Corp.          <a href=3D"http://= www.symas.com/" target=3D"_blank">http://www.symas.com</a>   Direc= tor, Highland Sun    <a href=3D"http://highlandsun.com/hyc/" tar= get=3D"_blank">http://highlandsun.com/hyc/</a>   Chief Architect, = OpenLDAP  <a href=3D"http://www.openldap.org/project/" target=3D"_blan= k">http://www.openldap.org/project/</a> </div> </div> </div></= body></html> ---872237384-2137566121-1349092304=:39209--

10 years, 11 months

1
0
0 / 0

Re: (ITS#7406) Search with scope for newer entries don't work

by a.stefanello＠mclink.eu

Thanks, my 2 mirror (Master-Master) server say : ebuild U ] net-nds/openldap-2.4.30::gentoo [2.4.23-r1::MC-link-NOC] upgrading to 2.4.30 doesn't cause problems , its correct ? Can i upgrade quietly or i have to do some pre-operations ? Thanks Il giorno 28/set/2012, alle ore 18:57, Quanah Gibson-Mount ha scritto: > --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, 11 months

1
0
0 / 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2012