openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by hyc＠symas.com 10 Oct '13

10 Oct '13

michael(a)stroeder.com wrote: > With current master and re24 which have the fix for this ITS I now see seg > faults in test023-refint test057-memberof-refint. Fixed now 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#7694) cldap fails with IPv6 due to wrong size sockaddr
by hyc＠symas.com 10 Oct '13

10 Oct '13

stefw(a)redhat.com wrote: > Full_Name: Stef Walter > Version: 2.4.35 > OS: Fedora 19 > URL: ftp://ftp.openldap.org/incoming/stef-walter-130912.patch > Submission from: (NULL) (46.5.2.70) > > > Connectionless LDAP (ie: cldap enabled with -DLDAP_CONNECTIONLESS) is broken for > IPv6 for current versions of openldap. Tested with version 2.4.35 > > It's not clear if this ever worked properly. No, clearly not, the code was written and deprecated before IPv6 existed. Nobody should be using this code today. Even if it were to be used, the patch would break slapd; your getnameinfo patch changes the format of the peername string. The format of this string is not arbitrary, it's used in ACLs and the format is documented in slapd.access(5). In the future, write patches that fix one single issue. Don't make gratuitous changes, particularly if you haven't researched what you're changing. > Connections immediately fail with: > > ldap_search_ext: Can't contact LDAP server (-1) > > The reason for this is that the LDAP_CONNECTIONLESS buffers include a prefix > containing an address in a "struct sockaddr". However, struct sockaddr, is not a > concrete type. In particular struct sockaddr_in6 is longer than struct > sockaddr. > > Noted here: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/… > > So this leads to failures when using IPv6 as the code assumes that the address > length is equal to sizeof (struct sockaddr). Seen here: > > http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/… > > Example command: > > $ ldapsearch -d -1 -LL -H 'cldap://[2620:52:0:2223::1:1]' -b '' -s base > '(&(DnsDomain=ad.baseos.qe)(NtVer=\06\00\00\00))' NetLogon > > Output will contain this: > > ldap_write: want=96 error=Invalid argument > > Which is the EINVAL resulting from bad value passed to sendto(). > > -- -- 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#7694) cldap fails with IPv6 due to wrong size sockaddr
by hyc＠symas.com 10 Oct '13

10 Oct '13

quanah(a)zimbra.com wrote: > --On Thursday, September 12, 2013 4:04 PM +0000 stefw(a)redhat.com wrote: > >>> 2.4.35 is not the current version of OpenLDAP, 2.4.36 is. There were >>> fixes to CLDAP made in 2.4.36. Please test against 2.4.36 and report >>> back, thanks. >> >> This patch is against master. >> >> However master cldap support is broken in additional ways, and I'll be >> filing further bugs/patches. > > Hi Stef, > > Thanks! In the future then, if it is an issue with the current 2.4 release > series still, you can just put RE24 as the version. ;) Then I won't spend > time trying to see if it's a known issue already fixed via the changes log. The CLDAP code is a remnant from pre-LDAPv3, there was no such thing as IPv6 when it was written, so no, this has never worked with IPv6. Who still uses CLDAP today? This code has no valid reason to exist any more. -- -- 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#7710) contextCSN values not updated by internal non-replicated ops
by michael＠stroeder.com 10 Oct '13

10 Oct '13

With current master and re24 which have the fix for this ITS I now see seg faults in test023-refint test057-memberof-refint.

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by michael＠stroeder.com 09 Oct '13

09 Oct '13

michael(a)stroeder.com wrote: > On Wed, 09 Oct 2013 08:13:24 -0700 Howard Chu <hyc(a)symas.com> wrote >> slapd already strips DSA-specific attributes before sending a syncrepl entry. >> memberOf is not marked in the schema as DSA-specific. This is working as >> designed. > > IIRC attribute 'memberOf' was replicated in former releases. So it was not > DSA-specific back then. > > Then the behaviour was changed in a more recent OpenLDAP release. Nowadays each > replica has to be configured with slapo-memberof performing *local* operations. > Therefore I'd argue that 'memberOf' should be marked DSA-specific now since the > *local* configuration is significant for its content. > Note that there is no formal specification for attribute 'memberOf' at all. > > I have deployments where most users are member of more than 10 groups, > sometimes more than 20. So not sending 'memberOf' could save quite a lot of > network traffic. > > What are your objections against marking 'memberOf' as DSA-specific? > > (I vaguely remember this being discussed before without result though.) Additionally consider partial replication where only a subset of group entries is present on a certain consumer. One would not want to have 'memberOf' point to group entries not really existing on that consumer. => 'memberOf' is definitely DSA-specific. Ciao, Michael.

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by michael＠stroeder.com 09 Oct '13

09 Oct '13

On Wed, 09 Oct 2013 08:13:24 -0700 Howard Chu <hyc(a)symas.com> wrote > slapd already strips DSA-specific attributes before sending a syncrepl entry. > memberOf is not marked in the schema as DSA-specific. This is working as > designed. IIRC attribute 'memberOf' was replicated in former releases. So it was not DSA-specific back then. Then the behaviour was changed in a more recent OpenLDAP release. Nowadays each replica has to be configured with slapo-memberof performing *local* operations. Therefore I'd argue that 'memberOf' should be marked DSA-specific now since the *local* configuration is significant for its content. Note that there is no formal specification for attribute 'memberOf' at all. I have deployments where most users are member of more than 10 groups, sometimes more than 20. So not sending 'memberOf' could save quite a lot of network traffic. What are your objections against marking 'memberOf' as DSA-specific? (I vaguely remember this being discussed before without result though.) Ciao, Michael.

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by hyc＠symas.com 09 Oct '13

09 Oct '13

Michael Ströder wrote: > On Wed, 9 Oct 2013 14:05:52 GMT hyc(a)symas.com wrote >> Howard Chu wrote: >>> Michael Ströder wrote: >>>> But now I see this during initial refresh phase of second server: >>>> >>>> send_ldap_result: err=20 matched="" text="modify/add: memberOf: value #0 >>>> already exists" >>>> >>>> Is that expected? >>> >>> Not seeing that with your testcase. >>> >> Ah, I see it now. Yes, it's normal; memberOf on the provider already added >> the relevant values. The consumer receives a group entry and performs the >> same set of memberof updates, which are redundant at that point. It's >> harmless. > > Hmm, wouldn't it be reasonable to strip those attributes marked as > non-replication attrs when generating syncrepl search results at the provider? > (Even if consumer asks for attrs=*,+) slapd already strips DSA-specific attributes before sending a syncrepl entry. memberOf is not marked in the schema as DSA-specific. This is working as designed. -- -- 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#7710) contextCSN values not updated by internal non-replicated ops
by michael＠stroeder.com 09 Oct '13

09 Oct '13

On Wed, 9 Oct 2013 14:05:52 GMT hyc(a)symas.com wrote > Howard Chu wrote: > > Michael Ströder wrote: > >> But now I see this during initial refresh phase of second server: > >> > >> send_ldap_result: err=20 matched="" text="modify/add: memberOf: value #0 > >> already exists" > >> > >> Is that expected? > > > > Not seeing that with your testcase. > > > Ah, I see it now. Yes, it's normal; memberOf on the provider already added > the relevant values. The consumer receives a group entry and performs the > same set of memberof updates, which are redundant at that point. It's > harmless. Hmm, wouldn't it be reasonable to strip those attributes marked as non-replication attrs when generating syncrepl search results at the provider? (Even if consumer asks for attrs=*,+) Ciao, Michael.

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by hyc＠symas.com 09 Oct '13

09 Oct '13

Howard Chu wrote: > Michael Ströder wrote: >> On Wed, 09 Oct 2013 05:01:40 -0700 Howard Chu <hyc(a)symas.com> wrote >> >>> michael(a)stroeder.com wrote: >>>> I've updated the test data with LDIF files and a README describing the LDAP >>>> operations to perform: >>>> >>>> http://www.stroeder.com/temp/openldap-testbed-its7710.tar.bz2 >>>> >>>> I consider this to be a serious issue which could be the cause for other >>>> replication issues including dead-locks we're experiencing. (Maybe there >>>> are similar issues in slapo-refint since dead-locks in our deployment >>>> arised when moving entries into different subtree.) >>> >>> Thanks, fixed now in master. Looks like refint may have run into the same >>> issue, also patched in master. >> >> contextCSN values are correct now. >> >> But now I see this during initial refresh phase of second server: >> >> send_ldap_result: err=20 matched="" text="modify/add: memberOf: value #0 >> already exists" >> >> Is that expected? > > Not seeing that with your testcase. > Ah, I see it now. Yes, it's normal; memberOf on the provider already added the relevant values. The consumer receives a group entry and performs the same set of memberof updates, which are redundant at that point. It's harmless. -- -- 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#7710) contextCSN values not updated by internal non-replicated ops
by hyc＠symas.com 09 Oct '13

09 Oct '13

Michael Ströder wrote: > On Wed, 09 Oct 2013 05:01:40 -0700 Howard Chu <hyc(a)symas.com> wrote > >> michael(a)stroeder.com wrote: >>> I've updated the test data with LDIF files and a README describing the LDAP >>> operations to perform: >>> >>> http://www.stroeder.com/temp/openldap-testbed-its7710.tar.bz2 >>> >>> I consider this to be a serious issue which could be the cause for other >>> replication issues including dead-locks we're experiencing. (Maybe there >>> are similar issues in slapo-refint since dead-locks in our deployment >>> arised when moving entries into different subtree.) >> >> Thanks, fixed now in master. Looks like refint may have run into the same >> issue, also patched in master. > > contextCSN values are correct now. > > But now I see this during initial refresh phase of second server: > > send_ldap_result: err=20 matched="" text="modify/add: memberOf: value #0 > already exists" > > Is that expected? Not seeing that with your testcase. -- -- 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