openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

(ITS#6992) ldapsync.c empty initializer
by tim＠multitalents.net 07 Jul '11

07 Jul '11

Full_Name: Tim Rice Version: 2.4.26 OS: Solaris 10 & UnixWare 7.1.4 URL: Submission from: (NULL) (173.164.249.129) The solaris native compilers complain about empty initializer in servers/slapd/ldapsync.c ........... cc -fast -xtarget=ultra -xcode=pic32 -g -I../../include -I/opt/src/networking/openldap-2.4.26/servers/slapd -I/opt/src/networking/openldap-2.4.26/servers/slapd/slapi -I. -I/opt/src/networking/openldap-2.4.26/include -I/opt/include -I/usr/sfw/include -c -o ldapsync.o /opt/src/networking/openldap-2.4.26/servers/slapd/ldapsync.c "/opt/src/networking/openldap-2.4.26/servers/slapd/ldapsync.c", line 172: warning: syntax error: empty initializer "/opt/src/networking/openldap-2.4.26/servers/slapd/ldapsync.c", line 174: warning: syntax error: empty initializer "/opt/src/networking/openldap-2.4.26/servers/slapd/ldapsync.c", line 175: warning: syntax error: empty initializer "/opt/src/networking/openldap-2.4.26/servers/slapd/ldapsync.c", line 180: warning: syntax error: empty initializer ........... It does compile on Solaris, but on UnixWare it is an error so fails to compile. ........... cc -g -Kpthread -I../../include -I. -I./slapi -I. -I../../include -c -o ldapsync.o ldapsync.c UX:acomp: ERROR: "ldapsync.c", line 172: Syntax error before or at: } UX:acomp: ERROR: "ldapsync.c", line 178: syntax error, probably missing ",", ";" or "=" UX:acomp: WARNING: "ldapsync.c", line 178: parameter mismatch: 6 declared, 3 defined UX:acomp: WARNING: "ldapsync.c", line 178: syntax error: empty declaration UX:acomp: ERROR: "ldapsync.c", line 179: cannot recover from previous errors gmake[2]: *** [ldapsync.o] Error 1 ...........

1 0

Re: (ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them
by ondrej.kuznik＠acision.com 07 Jul '11

07 Jul '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/07/2011 11:16 AM, masarati(a)aero.polimi.it wrote: >> When storing cn=config entries whose rdns use different attributes, >> they may be received in a different order during startup. This will >> mess with their "{}" numbering and since a change like that is not >> anticipated in the code, it is never pushed to the underlying >> database either. >> >> This leads to a state when the cn=config database and underlying >> on-disk representation are out of sync, making modification (and >> maybe deletion) of the affected entries impossible. >> >> If needed, I can create a minimal overlay showing these symptoms. > > Please, do. I find this report quite unclear, as I could not understand > what the actual issue is. ftp://ftp.openldap.org/incoming/ondrej-kuznik-20110707.c has an example of such overlay. To try it, initialize the overlay and add these entries: dn: olcTestAttrOne=zero,$OVERLAY_DN objectclass: olcTestOne dn: olcTestAttrTwo=one,$OVERLAY_DN objectclass: olcTestTwo dn: olcTestAttrOne=two,$OVERLAY_DN objectclass: olcTestOne dn: olcTestAttrTwo=three,$OVERLAY_DN objectclass: olcTestTwo After a restart compare the output of slapcat -n0 with the output of ldapsearch -b cn=config, you should see at least one different entry. You might also try to modify the entries before and after the restart. For those that do not match you get "no such object" as the dn is no longer in the ldif database. - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4Vs7IACgkQ9GWxeeH+cXs3rwCeP4DpQv+YNzWSt3sEgTZRVsYK 1ZYAoKiZeHPPWQ/kGirlkLMXitToxYqd =nAEI -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

RE: (ITS#6985) sssvlv / greaterThanOrEqual problem
by ctcard＠hotmail.com 07 Jul '11

07 Jul '11

> > > > > > > > I am running slapd built from HEAD on June 30th 2011, with back-sql > > > > > > Can you confirm this issue with another backend, e.g. back-bdb? Bugs > > > specific to back-sql or to interaction with it could receive only marginal > > > attention. > > > > > > p. > > > > > > > I've imported my data into a server with a bdb backend, and I see the same problem. > > > > Looking at the code in sssvlv.c, it uses tavl_find3() to search the values, but the > > code in tavl_find3() looks to me that it only works properly with an exact match > > type of matching rule: > > > > Avlnode * > > tavl_find3( Avlnode *root, const void *data, AVL_CMP fcmp, int *ret ) > > { > > int cmp = -1, dir; > > Avlnode *prev = root; > > > > while ( root != 0 && (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { > > prev = root; > > dir = cmp > 0; > > root = avl_child( root, dir ); > > } > > *ret = cmp; > > return root ? root : prev; > > } > > > > since the while loop terminates when the fcmp function returns 0 (i.e. exact match). > > > > I think I've worked out where the problem is. > Firstly, there's a comment before tavl_find3() saying > /* > * tavl_find2 - returns Avlnode instead of data pointer. > * tavl_find3 - as above, but returns Avlnode even if no match is found. > * also set *ret = last comparison result, or -1 if root == NULL. > */ > > but the "or -1 if root == NULL" is not done. > > Secondly, if no exact match is found, prev is returned which may point to a node which is less than the search > node, depending on what the tree looks like, but we really want a pointer to the last node which was greater than > the search node to be returned. > > Once these fixes are done, the correct node is returned by tavl_find3 to the call in send_list() in sssvlv.c (line 523). > > There is another bug in send_list() in sssvlv.c, at lines 535-544: > > if ( i > 0 ) { > tmp_node = tavl_end(so->so_tree, TAVL_DIR_RIGHT); > dir = TAVL_DIR_LEFT; > } else { > tmp_node = tavl_end(so->so_tree, TAVL_DIR_LEFT); > dir = TAVL_DIR_RIGHT; > } > for (i=0; tmp_node != cur_node; > tmp_node = tavl_next( tmp_node, dir ), i++); > so->so_vlv_target = i; > This code is ok if the cur_node is in the left hand side of the tree, but if it is in the rhs of the tree so_vlv_target is set > to an offset from the end of the list, rather than the beginning. > One more issue: the most recent draft spec for vlv (http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09) states that the offset field in the vlv request has range 1..maxInt whereas the targetPosition in the vlv response has range 0..maxInt. However, my interpretation of the spec is that offset and targetPosition represent the same thing, i.e. the position of the target entry in the list, with the first entry having offset/targetPosition = 1. If that interpretation is correct, the assignment of so_vlv_target in the code above is off by one, since i will be zero if cur_node is at the beginning of the list. Chris

1 0

RE: (ITS#6985) sssvlv / greaterThanOrEqual problem
by ctcard＠hotmail.com 07 Jul '11

07 Jul '11

> > > > > > > I am running slapd built from HEAD on June 30th 2011, with back-sql > > > > Can you confirm this issue with another backend, e.g. back-bdb? Bugs > > specific to back-sql or to interaction with it could receive only marginal > > attention. > > > > p. > > > > I've imported my data into a server with a bdb backend, and I see the same problem. > > Looking at the code in sssvlv.c, it uses tavl_find3() to search the values, but the > code in tavl_find3() looks to me that it only works properly with an exact match > type of matching rule: > > Avlnode * > tavl_find3( Avlnode *root, const void *data, AVL_CMP fcmp, int *ret ) > { > int cmp = -1, dir; > Avlnode *prev = root; > > while ( root != 0 && (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { > prev = root; > dir = cmp > 0; > root = avl_child( root, dir ); > } > *ret = cmp; > return root ? root : prev; > } > > since the while loop terminates when the fcmp function returns 0 (i.e. exact match). > I think I've worked out where the problem is. Firstly, there's a comment before tavl_find3() saying /* * tavl_find2 - returns Avlnode instead of data pointer. * tavl_find3 - as above, but returns Avlnode even if no match is found. * also set *ret = last comparison result, or -1 if root == NULL. */ but the "or -1 if root == NULL" is not done. Secondly, if no exact match is found, prev is returned which may point to a node which is less than the search node, depending on what the tree looks like, but we really want a pointer to the last node which was greater than the search node to be returned. Once these fixes are done, the correct node is returned by tavl_find3 to the call in send_list() in sssvlv.c (line 523). There is another bug in send_list() in sssvlv.c, at lines 535-544: if ( i > 0 ) { tmp_node = tavl_end(so->so_tree, TAVL_DIR_RIGHT); dir = TAVL_DIR_LEFT; } else { tmp_node = tavl_end(so->so_tree, TAVL_DIR_LEFT); dir = TAVL_DIR_RIGHT; } for (i=0; tmp_node != cur_node; tmp_node = tavl_next( tmp_node, dir ), i++); so->so_vlv_target = i; This code is ok if the cur_node is in the left hand side of the tree, but if it is in the rhs of the tree so_vlv_target is set to an offset from the end of the list, rather than the beginning. Chris

1 0

Re: (ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them
by masarati＠aero.polimi.it 07 Jul '11

07 Jul '11

> Full_Name: Ondrej Kuznik > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (62.168.56.1) > > > When storing cn=config entries whose rdns use different attributes, they > may be > received in a different order during startup. This will mess with their > "{}" > numbering and since a change like that is not anticipated in the code, it > is > never pushed to the underlying database either. > > This leads to a state when the cn=config database and underlying on-disk > representation are out of sync, making modification (and maybe deletion) > of the > affected entries impossible. > > If needed, I can create a minimal overlay showing these symptoms. Please, do. I find this report quite unclear, as I could not understand what the actual issue is. p.

1 0

(ITS#6987) cn=config renumbers indexes on startup without modrdn-ing them
by ondrej.kuznik＠acision.com 07 Jul '11

07 Jul '11

Full_Name: Ondrej Kuznik Version: HEAD OS: Linux URL: Submission from: (NULL) (62.168.56.1) When storing cn=config entries whose rdns use different attributes, they may be received in a different order during startup. This will mess with their "{}" numbering and since a change like that is not anticipated in the code, it is never pushed to the underlying database either. This leads to a state when the cn=config database and underlying on-disk representation are out of sync, making modification (and maybe deletion) of the affected entries impossible. If needed, I can create a minimal overlay showing these symptoms. Not sure what action is appropriate, probably letting back-ldif honor the original ordering fully, but this can break other assumptions already in the configuration code that relied on the "attribute name first, then numbers" ordering. Another thing that comes to my mind is to make the ordering sequences per attribute whatever the value of ce_type. Like this: olcAttr={0}a, olcSomething={0}something, cn=config olcAttr={1}c, olcSomething={0}something, cn=config olcAttr={2}b, olcSomething={0}something, cn=config olcOtherAttr={0}ccc, olcSomething={0}something, cn=config olcOtherAttr={1}csad, olcSomething={0}something, cn=config olcOtherAttr={2}safc, olcSomething={0}something, cn=config olcOtherAttr={3}brt, olcSomething={0}something, cn=config Again, this has other drawbacks (first restart after this is applied changes the cn=config database probably messing with replication?)

1 0

Re: (ITS#6986) conversion to run-time configuration (RTC) for slapo-constraint
by florian.dufner＠uni-ulm.de 07 Jul '11

07 Jul '11

Am 07.07.2011 08:21, schrieb masarati(a)aero.polimi.it: > There are clearly two bugs: "count" misses the number (same for "size") > and the prefix "restrict=" is repeated. Fixed in master, please test and > report. Tested. Problem is gone with the provided patch. Thank you. FloD.

1 0

Re: (ITS#6986) conversion to run-time configuration (RTC) for slapo-constraint
by masarati＠aero.polimi.it 06 Jul '11

06 Jul '11

There are clearly two bugs: "count" misses the number (same for "size") and the prefix "restrict=" is repeated. Fixed in master, please test and report. p. > --On Tuesday, July 05, 2011 9:22 PM +0000 florian.dufner(a)uni-ulm.de wrote: > >> Full_Name: Florian Dufner >> Version: 2.4.26 >> OS: SunOS sun 5.10 i86pc >> URL: >> Submission from: (NULL) (91.16.117.246) >> >> >> Conversion to run-time configuration (RTC) does not work with every >> configuration option of slapo-constraint. >> >> Problem #1: (count constraints) >> constraint_attribute mail count 1 >> is converted to >> olcConstraintAttribute:: bWFpbCBjb3VudCA= > > This is base-64 encoded, not garbage. I suggest you base-64 decode it to > see the actual value. > >> The attribute is garbled after conversion. slapd will not run until this >> is fixed. >> >> Problem #2: (restrict parameter) >> constraint_attribute mail regex ^[[:alnum:].-]+@host$ >> restrict="ldap:///ou=people,dc=host??sub?(objectClass=posixAccount)" >> is converted to >> olcConstraintAttribute: mail regex ^[[:alnum:].-]+@host$ restr >> ict="restrict=ldap:///ou=people,dc=host??sub?(obj >> ectClass=posixAccount)" >> >> The complete restrict parameter from the old configuration format >> (including "restrict=") is appended after a "restrict=". >> slapd will not run until this is fixed. >> > > This sounds valid. > > --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#6986) conversion to run-time configuration (RTC) for slapo-constraint
by florian.dufner＠uni-ulm.de 06 Jul '11

06 Jul '11

Am 07.07.2011 04:12, schrieb Quanah Gibson-Mount: >> Problem #1: (count constraints) >> constraint_attribute mail count 1 >> is converted to >> olcConstraintAttribute:: bWFpbCBjb3VudCA= > > This is base-64 encoded, not garbage. I suggest you base-64 decode it > to see the actual value. Okay, base-64 decoded it is "mail count". But as I wrote: >> The attribute is garbled after conversion. slapd will not run until this >> is fixed. So the problem is that the number after count is not included in conversion. After adding " <number>" slapd will start. Is there a specific mechanism for the decision of what attributes get base64-encoded in conversion? In case of the count type constraint I can't see why it's needed. FloD.

1 0

Re: (ITS#6986) conversion to run-time configuration (RTC) for slapo-constraint
by quanah＠zimbra.com 06 Jul '11

06 Jul '11

--On Tuesday, July 05, 2011 9:22 PM +0000 florian.dufner(a)uni-ulm.de wrote: > Full_Name: Florian Dufner > Version: 2.4.26 > OS: SunOS sun 5.10 i86pc > URL: > Submission from: (NULL) (91.16.117.246) > > > Conversion to run-time configuration (RTC) does not work with every > configuration option of slapo-constraint. > > Problem #1: (count constraints) > constraint_attribute mail count 1 > is converted to > olcConstraintAttribute:: bWFpbCBjb3VudCA= This is base-64 encoded, not garbage. I suggest you base-64 decode it to see the actual value. > The attribute is garbled after conversion. slapd will not run until this > is fixed. > > Problem #2: (restrict parameter) > constraint_attribute mail regex ^[[:alnum:].-]+@host$ > restrict="ldap:///ou=people,dc=host??sub?(objectClass=posixAccount)" > is converted to > olcConstraintAttribute: mail regex ^[[:alnum:].-]+@host$ restr > ict="restrict=ldap:///ou=people,dc=host??sub?(obj > ectClass=posixAccount)" > > The complete restrict parameter from the old configuration format > (including "restrict=") is appended after a "restrict=". > slapd will not run until this is fixed. > This sounds valid. --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

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