- openldap-bugs - openldap.org

connection init crash
by Yann Carre 10 Jul '11

10 Jul '11

Hello I have encountered a crash with OPENLDAP 2.4.22 I have provided in my back end a function to the bi_connection_init pointer. This function sets some parameter needed in the operation backend function (search, ...) My server crashes because my backend connection init function is not called before the operation backend function. It seems that the connection is provided to the application before the end of all backend connection init May be in the function connection_init (connection.c), the connection mutex should be unlock when all the backend connection init should be done? Thanks Regards Yann

2 1

Re: (ITS#6992) ldapsync.c empty initializer
by masarati＠aero.polimi.it 08 Jul '11

08 Jul '11

On 07/08/2011 07:45 AM, tim(a)multitalents.net wrote: > 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 A fix is in git master, please test and report. p.

1 0

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

08 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 07 Jul '11

07 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 07 Jul '11

07 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 07 Jul '11

07 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

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

05 Jul '11

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= 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.

1 0

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

05 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). Chris

1 0

Re: (ITS#6985) sssvlv / greaterThanOrEqual problem
by masarati＠aero.polimi.it 05 Jul '11

05 Jul '11

> Full_Name: Chris Card > Version: HEAD (on 30 June 2011) > OS: Centos 5.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (91.194.158.133) > > > 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. > backend, and > pcache and sssvlv overlays. > > I am submitting a search request with vlv and sort controls. > > In the sort control I am specifying attributeType cn and orderingRule > caseIgnoreOrderingMatch. > > If I specify 'd' as the greaterThanOrEqual value of the vlv control, > beforeCount > 0 and afterCount 4, I get 5 entries with the following cns returned: > > Dave Smith > Fiona Smith > Glynis Smith > Jane Smith > Jennifer Smith > > If I specify 'g' in greaterThanOrEqual I get: > > Glynis Smith > Jane Smith > Jennifer Smith > Jim Smith > Mark Smith > > But if I specify 'f' I get no entries returned. > >

1 0

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

05 Jul '11

Full_Name: Chris Card Version: HEAD (on 30 June 2011) OS: Centos 5.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.194.158.133) I am running slapd built from HEAD on June 30th 2011, with back-sql backend, and pcache and sssvlv overlays. I am submitting a search request with vlv and sort controls. In the sort control I am specifying attributeType cn and orderingRule caseIgnoreOrderingMatch. If I specify 'd' as the greaterThanOrEqual value of the vlv control, beforeCount 0 and afterCount 4, I get 5 entries with the following cns returned: Dave Smith Fiona Smith Glynis Smith Jane Smith Jennifer Smith If I specify 'g' in greaterThanOrEqual I get: Glynis Smith Jane Smith Jennifer Smith Jim Smith Mark Smith But if I specify 'f' I get no entries returned.

1 0

Re: (ITS#6984) Enable draft-wahl-ldap-session in RE24
by masarati＠aero.polimi.it 04 Jul '11

04 Jul '11

> Full_Name: Michael Ströder > Version: 2.4.x > OS: > URL: > Submission from: (NULL) (84.128.228.27) > > > It seems there is support for draft-wahl-ldap-session in OpenLDAP's source > since > 2007 but it seems not to be enabled in a default build. It's hidden behind > ifdef-statements and one has to use -DLDAP_DEVEL when compiling which is > not > supposed to work with RE24. > > I've tested it with HEAD and I'd be glad this could be enabled for > standard > builds in 2.4 series. As far as I understand, support is complete and conforms to draft as of the time it was implemented. Since the draft expired, it has never been released. Moreover, I sent the author some comments about how the draft could be improved, IMHO, but received no answer (I don't recall whether the discussion was in ldapext or personal, though). If it can be useful, I surely favour its release, provided this complies with the project's policy towards support for expired drafts. p.

1 0

(ITS#6984) Enable draft-wahl-ldap-session in RE24
by michael＠stroeder.com 04 Jul '11

04 Jul '11

Full_Name: Michael Ströder Version: 2.4.x OS: URL: Submission from: (NULL) (84.128.228.27) It seems there is support for draft-wahl-ldap-session in OpenLDAP's source since 2007 but it seems not to be enabled in a default build. It's hidden behind ifdef-statements and one has to use -DLDAP_DEVEL when compiling which is not supposed to work with RE24. I've tested it with HEAD and I'd be glad this could be enabled for standard builds in 2.4 series. Ciao, Michael.

1 0

(ITS#6983) modrdn operations on hdb databases create duplicate return results
by quanah＠zimbra.com 03 Jul '11

03 Jul '11

Full_Name: Quanah Gibson-Mount Version: 2.4.25 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) When a modrdn operation is done on a subtree (I.e., subtree rename), the result is that back-hdb will return certain entries in that subtree multiple times. Stopping and restarting slapd fixes the behavior. Example: ldapsearch -x -v -H 'ldap://HOST ' -w PASSWORD -D 'uid=zimbra,cn=admins,cn=zimbra' -b "dc=NEWDOMAIN,dc=COM" ldap_initialize( ldap://HOST:389/??base ) filter: (objectclass=*) requesting: All userApplication attributes # extended LDIF # # LDAPv3 # base <dc=NEWDOMAIN,dc=COM> with scope subtree # filter: (objectclass=*) # requesting: ALL # # d-fashion.be dn: dc=NEWDOMAIN,dc=COM o: NEWDOMAIN.com domain zimbraDomainName: NEWDOMAIN.COM zimbraDomainStatus: active zimbraPublicServiceHostname: mail.domain.com zimbraId: affb06b8-79bc-430a-adf7-411cc45e8f00 zimbraMailStatus: enabled objectClass: dcObject objectClass: organization objectClass: zimbraDomain zimbraDomainType: local dc: NEWDOMAIN zimbraPreAuthKey: PRIVATE # people, NEWDOMAIN.COM dn: ou=people,dc=NEWDOMAIN,dc=COM ou: people objectClass: organizationalRole cn: people # people, NEWDOMAIN.COM dn: ou=people,dc=NEWDOMAIN,dc=COM ou: people objectClass: organizationalRole cn: people

1 0

Re: ITS#6873
by masarati＠aero.polimi.it 02 Jul '11

02 Jul '11

> masarati(a)aero.polimi.it wrote: >> Fixed in master, please test. > > Sorry, last message went to wrong ITS. > > But also seems to work now...thanks... :-) > > $ ldapmodify -x -H ldap://localhost:2071 -D > "uid=diradm,ou=schulung,dc=stroeder,dc=local" -e relax -w testsecret -f > authtime_mod.ldif > modifying entry "cn=test1,ou=schulung,dc=stroeder,dc=local" > > -------------------------- authtime_mod.ldif -------------------------- > dn: cn=test1,ou=schulung,dc=stroeder,dc=local > changetype: modify > replace: authTimestamp > authTimestamp: 20110701165029Z Good, I only tested this one. Those were easy fixes, sorry I overlooked them for such a long time. p.

1 0

Re: (ITS#6830) slapo-ppolicy.5 has incorrect schema fragments
by michael＠stroeder.com 01 Jul '11

01 Jul '11

hyc(a)symas.com wrote: > Andrew Findlay wrote: >> On Thu, Jun 09, 2011 at 01:45:17AM -0700, Howard Chu wrote: >> >>> I note that in ppolicy.c we have: >>> >>> { "( 1.3.6.1.4.1.42.2.27.8.1.17 " >>> "NAME ( 'pwdAccountLockedTime' ) " >>> "DESC 'The time an user account was locked' " >>> "EQUALITY generalizedTimeMatch " >>> "ORDERING generalizedTimeOrderingMatch " >>> "SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 " >>> "SINGLE-VALUE " >>> #if 0 >>> /* Not until Relax control is released */ >>> "NO-USER-MODIFICATION " >>> #endif >>> "USAGE directoryOperation )", >>> >>> We have in fact released support for the Relax control, so it's >>> probably time to unifdef these bits and go back to the documented >>> behavior. >> >> That seems reasonable in the long term, though it will break many sites' >> existing password management procedures. The change will have to be >> mentioned in the updated manpage, noting the version at which it takes >> effect. >> >> Should I produce an updated version of the manpage patch? > > Well since you raise the question, what do you think is the more sensible > approach to all of this? I was the one who argued in ldapext that these > attributes should be no-user-modification but perhaps that makes them too > inconvenient to administer. Given the fact that the Relax Rules control still has .666 OID it cannot be used (see my related messages to openldap-devel and ietf-ldapext). At least what's always being said about .666 OIDs... Ciao, Michael.

1 0

Re: ITS#6873
by michael＠stroeder.com 01 Jul '11

01 Jul '11

masarati(a)aero.polimi.it wrote: > Fixed in master, please test. Sorry, last message went to wrong ITS. But also seems to work now...thanks... :-) $ ldapmodify -x -H ldap://localhost:2071 -D "uid=diradm,ou=schulung,dc=stroeder,dc=local" -e relax -w testsecret -f authtime_mod.ldif modifying entry "cn=test1,ou=schulung,dc=stroeder,dc=local" -------------------------- authtime_mod.ldif -------------------------- dn: cn=test1,ou=schulung,dc=stroeder,dc=local changetype: modify replace: authTimestamp authTimestamp: 20110701165029Z

1 0

ITS#6886
by michael＠stroeder.com 01 Jul '11

01 Jul '11

masarati(a)aero.polimi.it wrote: > Fixed in master, please test. Seems to work now...thanks... :-) *** ldap://localhost:2071 - SimpleLDAPObject.extop (('1.3.6.1.4.1.1466.101.119.1', '0/\x80)cn=test1,ou=schulung,dc=stroeder,dc=local\x81\x02\x1c ', None, None),{}) => result: 2 *** ldap://localhost:2071 - SimpleLDAPObject.result4 ((2, 1, -1, 1, 1, 1),{}) => result: (120, [], 2, [], '1.3.6.1.4.1.1466.101.119.1', '0\x04\x81\x02\x1c ') Response TTL: 7200

1 0

Re: ITS#6873
by michael＠stroeder.com 01 Jul '11

01 Jul '11

masarati(a)aero.polimi.it wrote: > Fixed in master, please test. Seems to work now...thanks... :-) *** ldap://localhost:2071 - SimpleLDAPObject.extop (('1.3.6.1.4.1.1466.101.119.1', '0/\x80)cn=test1,ou=schulung,dc=stroeder,dc=local\x81\x02\x1c ', None, None),{}) => result: 2 *** ldap://localhost:2071 - SimpleLDAPObject.result4 ((2, 1, -1, 1, 1, 1),{}) => result: (120, [], 2, [], '1.3.6.1.4.1.1466.101.119.1', '0\x04\x81\x02\x1c ') Response TTL: 7200

1 0

(ITS#6982) libutil md5 incorrect sizeof
by quanah＠OpenLDAP.org 01 Jul '11

01 Jul '11

Full_Name: Quanah Gibson-Mount Version: 2.4.25 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) Line 188 in liblutil/md5.c is wrong. It has: memset(ctx, '\0', sizeof(ctx)); /* In case it's sensitive */ It should be: memset(ctx, '\0', sizeof(*ctx)); /* In case it's sensitive */

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs