- openldap-bugs - openldap.org

Re: (ITS#6999) retry: counter not reaching zero, continuing on
by hyc＠symas.com 29 Jul '11

29 Jul '11

ml+openldap(a)esmtp.org wrote: > On Fri, Jul 29, 2011, Howard Chu wrote: > >> The ITS mailer only supports plaintext, no attachments. > > Sorry about that. Here's the log inline (5 attempts by syncrepl): I was able to reproduce this behavior. The culprit is the ldap_result() call in do_syncrep2() returning 0 due to a timeout. The actual sequence of events is that do_syncrep1() successfully binds to the master and sends a syncsearch request, then do_syncrep2() reads the search response. The first message is a Present UUID list which it parses successfully. It then loops back to look for the next message from the provider, but due to whatever timing vagaries, that message is not available yet. But anyway, do_syncrep2() returns with rc=0 and this resets the retry counter, as I said before. At the moment I don't have any good ideas how this could be fixed in the code. Timeouts of this sort are normal behavior for refreshAndPersist. I guess we need to keep using the NULL timeout while the connection is actually in its Refresh phase, before it enters its Persist phase. I think you could workaround it by using delta-syncrepl, which doesn't use a Present UUID list. This will require some more thought. -- -- 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#6999) retry: counter not reaching zero, continuing on
by ml+openldap＠esmtp.org 29 Jul '11

29 Jul '11

On Fri, Jul 29, 2011, Howard Chu wrote: > The ITS mailer only supports plaintext, no attachments. Sorry about that. Here's the log inline (5 attempts by syncrepl): Jul 22 13:12:25 vmca02 slapd[23778]: slapd starting Jul 22 13:12:26 vmca02 slapd[23778]: conn=1000 fd=16 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:12:26 vmca02 slapd[23778]: conn=1000 op=0 BIND dn="cn=manager" method=128 Jul 22 13:12:26 vmca02 slapd[23778]: conn=1000 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 Jul 22 13:12:26 vmca02 slapd[23778]: conn=1000 op=0 RESULT tag=97 err=0 text= Jul 22 13:12:26 vmca02 slapd[23778]: conn=1000 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" Jul 22 13:12:26 vmca02 slapd[23778]: conn=1000 op=1 SRCH attr=* + Jul 22 13:12:26 vmca02 slapd[23778]: do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 fd=17 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 op=0 BIND dn="cn=Manager" method=128 Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 op=0 BIND dn="cn=Manager" mech=SIMPLE ssf=0 Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 op=0 RESULT tag=97 err=0 text= Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 op=1 ADD dn="uid=user68,ou=People,dc=example,dc=com" Jul 22 13:12:33 vmca02 slapd[23778]: slap_queue_csn: queing 0x43403110 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:33 vmca02 slapd[23778]: syncprov_sendresp: cookie=rid=001,sid=001,csn=20110722201233.471069Z#000000#001#000000 Jul 22 13:12:33 vmca02 slapd[23778]: do_syncrep2: rid=001 cookie=rid=001,sid=001,csn=20110722201233.471069Z#000000#001#000000 Jul 22 13:12:33 vmca02 slapd[23778]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 op=2 UNBIND Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 op=1 RESULT tag=105 err=0 text= Jul 22 13:12:33 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_search (0) Jul 22 13:12:33 vmca02 slapd[23778]: syncrepl_entry: rid=001 uid=user68,ou=People,dc=example,dc=com Jul 22 13:12:33 vmca02 slapd[23778]: slap_queue_csn: queing 0x2c51b20 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:33 vmca02 slapd[23778]: slap_graduate_commit_csn: removing 0x2c49060 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:33 vmca02 slapd[23778]: conn=1001 fd=17 closed Jul 22 13:12:33 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user68,ou=People,dc=example,dc=com (0) Jul 22 13:12:33 vmca02 slapd[23778]: slap_queue_csn: queing 0x2c51b20 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 fd=17 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 op=0 BIND dn="cn=Manager" method=128 Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 op=0 BIND dn="cn=Manager" mech=SIMPLE ssf=0 Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 op=0 RESULT tag=97 err=0 text= Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 op=1 ADD dn="uid=user69,ou=People,dc=example,dc=com" Jul 22 13:12:52 vmca02 slapd[23778]: slap_queue_csn: queing 0x44405110 20110722201252.820971Z#000000#001#000000 Jul 22 13:12:52 vmca02 slapd[23778]: slap_graduate_commit_csn: removing 0x2b40df0 20110722201252.820971Z#000000#001#000000 Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 op=1 RESULT tag=105 err=0 text= Jul 22 13:12:52 vmca02 slapd[23778]: syncprov_sendresp: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 Jul 22 13:12:52 vmca02 slapd[23778]: do_syncrep2: rid=001 cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 Jul 22 13:12:52 vmca02 slapd[23778]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 op=2 UNBIND Jul 22 13:12:52 vmca02 slapd[23778]: conn=1002 fd=17 closed Jul 22 13:12:52 vmca02 slapd[23778]: conn=-1 op=0 ldap_back_retry: retrying URI="ldap://vmca01" DN="cn=monitor" Jul 22 13:12:52 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_search (52) Jul 22 13:12:52 vmca02 slapd[23778]: syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com Jul 22 13:12:52 vmca02 slapd[23778]: slap_queue_csn: queing 0x2c518d0 20110722201252.820971Z#000000#001#000000 Jul 22 13:12:52 vmca02 slapd[23778]: null_callback : error code 0x34 Jul 22 13:12:52 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) Jul 22 13:12:52 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) Jul 22 13:12:52 vmca02 slapd[23778]: conn=1000 op=2 UNBIND Jul 22 13:12:52 vmca02 slapd[23778]: conn=1000 fd=16 closed Jul 22 13:12:52 vmca02 slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 op=0 BIND dn="cn=manager" method=128 Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 op=0 RESULT tag=97 err=0 text= Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 op=1 SRCH attr=* + Jul 22 13:12:57 vmca02 slapd[23778]: srs csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:57 vmca02 slapd[23778]: log csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:57 vmca02 slapd[23778]: cmp 0, too old Jul 22 13:12:57 vmca02 slapd[23778]: log csn 20110722201252.820971Z#000000#001#000000 Jul 22 13:12:57 vmca02 slapd[23778]: Entry uid=user68,ou=People,dc=example,dc=com CSN 20110722201233.471069Z#000000#001#000000 older or equal to ctx 20110722201233.471069Z#000000#001#000000 Jul 22 13:12:57 vmca02 slapd[23778]: syncprov_search_response: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 Jul 22 13:12:57 vmca02 slapd[23778]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 22 13:12:57 vmca02 slapd[23778]: syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 Jul 22 13:12:57 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_search (52) Jul 22 13:12:57 vmca02 slapd[23778]: syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com Jul 22 13:12:57 vmca02 slapd[23778]: null_callback : error code 0x34 Jul 22 13:12:57 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) Jul 22 13:12:57 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 op=2 UNBIND Jul 22 13:12:57 vmca02 slapd[23778]: conn=1003 fd=15 closed Jul 22 13:12:57 vmca02 slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (3 retries left) Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 op=0 BIND dn="cn=manager" method=128 Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 op=0 RESULT tag=97 err=0 text= Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 op=1 SRCH attr=* + Jul 22 13:13:02 vmca02 slapd[23778]: srs csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:02 vmca02 slapd[23778]: log csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:02 vmca02 slapd[23778]: cmp 0, too old Jul 22 13:13:02 vmca02 slapd[23778]: log csn 20110722201252.820971Z#000000#001#000000 Jul 22 13:13:02 vmca02 slapd[23778]: Entry uid=user68,ou=People,dc=example,dc=com CSN 20110722201233.471069Z#000000#001#000000 older or equal to ctx 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:02 vmca02 slapd[23778]: syncprov_search_response: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 Jul 22 13:13:02 vmca02 slapd[23778]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 22 13:13:02 vmca02 slapd[23778]: syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:13:02 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_search (52) Jul 22 13:13:02 vmca02 slapd[23778]: syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com Jul 22 13:13:02 vmca02 slapd[23778]: null_callback : error code 0x34 Jul 22 13:13:02 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) Jul 22 13:13:02 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) Jul 22 13:13:02 vmca02 slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 op=2 UNBIND Jul 22 13:13:02 vmca02 slapd[23778]: conn=1004 fd=15 closed Jul 22 13:13:02 vmca02 slapd[23778]: connection_read(15): no connection! Jul 22 13:13:02 vmca02 slapd[23778]: connection_read(15): no connection! Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 op=0 BIND dn="cn=manager" method=128 Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 op=0 RESULT tag=97 err=0 text= Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 op=1 SRCH attr=* + Jul 22 13:13:07 vmca02 slapd[23778]: srs csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:07 vmca02 slapd[23778]: log csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:07 vmca02 slapd[23778]: cmp 0, too old Jul 22 13:13:07 vmca02 slapd[23778]: log csn 20110722201252.820971Z#000000#001#000000 Jul 22 13:13:07 vmca02 slapd[23778]: Entry uid=user68,ou=People,dc=example,dc=com CSN 20110722201233.471069Z#000000#001#000000 older or equal to ctx 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:07 vmca02 slapd[23778]: syncprov_search_response: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 Jul 22 13:13:07 vmca02 slapd[23778]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 22 13:13:07 vmca02 slapd[23778]: syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 Jul 22 13:13:07 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_search (52) Jul 22 13:13:07 vmca02 slapd[23778]: syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com Jul 22 13:13:07 vmca02 slapd[23778]: null_callback : error code 0x34 Jul 22 13:13:07 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) Jul 22 13:13:07 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 op=2 UNBIND Jul 22 13:13:07 vmca02 slapd[23778]: conn=1005 fd=15 closed Jul 22 13:13:07 vmca02 slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (3 retries left) Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 op=0 BIND dn="cn=manager" method=128 Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 op=0 RESULT tag=97 err=0 text= Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 op=1 SRCH attr=* + Jul 22 13:13:12 vmca02 slapd[23778]: srs csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:12 vmca02 slapd[23778]: log csn 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:12 vmca02 slapd[23778]: cmp 0, too old Jul 22 13:13:12 vmca02 slapd[23778]: log csn 20110722201252.820971Z#000000#001#000000 Jul 22 13:13:12 vmca02 slapd[23778]: Entry uid=user68,ou=People,dc=example,dc=com CSN 20110722201233.471069Z#000000#001#000000 older or equal to ctx 20110722201233.471069Z#000000#001#000000 Jul 22 13:13:12 vmca02 slapd[23778]: syncprov_search_response: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 Jul 22 13:13:12 vmca02 slapd[23778]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 22 13:13:12 vmca02 slapd[23778]: syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 Jul 22 13:13:12 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_search (52) Jul 22 13:13:12 vmca02 slapd[23778]: syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com Jul 22 13:13:12 vmca02 slapd[23778]: null_callback : error code 0x34 Jul 22 13:13:12 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) Jul 22 13:13:12 vmca02 slapd[23778]: syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) Jul 22 13:13:12 vmca02 slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 op=2 UNBIND Jul 22 13:13:12 vmca02 slapd[23778]: conn=1006 fd=15 closed Jul 22 13:13:12 vmca02 slapd[23778]: connection_read(15): no connection! Jul 22 13:13:12 vmca02 slapd[23778]: connection_read(15): no connection!

1 0

Re: (ITS#6999) retry: counter not reaching zero, continuing on
by hyc＠symas.com 29 Jul '11

29 Jul '11

ml+openldap(a)esmtp.org wrote: > --UugvWAfsgieZRqgk > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Thu, Jul 28, 2011, Howard Chu wrote: > >> I think we need to see more of the log than this. The only reason >> for your observed behavior to occur is that somewhere along the >> line, a step in the replication actually returned LDAP_SUCCESS, >> which resets the retry counter. So we need to see the complete log >> for at least one full cycle of "(4 retries left)", "(3 retries >> left)", "(4 retries left)". > > I've attached the full log of the test (from start to stop); it's > rather small in .gz format. I hope that will go through, otherwise > I can extract the requested full cycle and send that inline. The ITS mailer only supports plaintext, no attachments. -- -- 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#6999) retry: counter not reaching zero, continuing on
by ml+openldap＠esmtp.org 29 Jul '11

29 Jul '11

--UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jul 28, 2011, Howard Chu wrote: > I think we need to see more of the log than this. The only reason > for your observed behavior to occur is that somewhere along the > line, a step in the replication actually returned LDAP_SUCCESS, > which resets the retry counter. So we need to see the complete log > for at least one full cycle of "(4 retries left)", "(3 retries > left)", "(4 retries left)". I've attached the full log of the test (from start to stop); it's rather small in .gz format. I hope that will go through, otherwise I can extract the requested full cycle and send that inline. --UugvWAfsgieZRqgk Content-Type: text/plain; charset=unknown-8bit Content-Disposition: attachment; filename="ldap.2.gz" Content-Transfer-Encoding: quoted-printable =1F=8B=08=08=D2=D72N=02=03ldap.2=00=D5=9DOs=1C=C7=91=C5=EF=FB)=C6=DC=0B=E9= =15=C1=AE?=3D=DD=8D=08=1C=B8$=1C=A2Cb(H=EA=E0=DD=D8@=0Cf=86=12V =86=1A=80= =B2=FC=ED=DDC=D22ATU=BF=AC=CAW=1D=F0=C1$aO=E6+LU=E5=FBe=02=D3=7F=FDp=B9=B0v= a=DC=B1=B1=C7=B6]=FC=F6n=BDj=EC=E2=FAr=F5~=F3=BF=D6u]=FF=7F=C7=9F=FE=B5=B8= =BEY=EDo.=AE~=FA=8F=BF=DEz=CD2=FC=9A=F5=EE=EA=EA=C44M=B3x=BB91=CB=C5=D3g=CF= N=7Fx=B3x=BB=DF=BD[=FC=F0=F4=CD=B7'O~[=ED=9F=EC?\=3D=B9=DC=AC=DE_,=1E=06=BE= =F8H=9Aj=F7=FE=A4Y=FC=F7=8B=97=CF=17=9B=AB=93=07=EB=AB=93w=AB=AB=D5O=DB=FD= =83=C5=BB=ED=CD=CF=BBQ=88=ED5c=AE=7F>y=FD=E2=FB=1F=BE;]\_=BF=3Di=B2B=BF:}= =FD=E3wo=167=AB=9FN=86n=B1=DD=EF=C7=AF=DDl=7F=BF9=C9=88f=16=AF_=3D=FBvq=BE= =BA=DE=9E<x=B0=B8^=EF=DEoO=ECb=B3=DDoGy=8B=B7=17=977=DB=FD=C9=83=87=BB=F3= =FF=DF=AEo=9E]=AE=AE=AFO=FE=FC=E8A~=A6=D5=CD=CD=FE=E4=CF=8B=FF=C2"lvg=D7=FF= =B8Z=EF=B7=EF=ED=F1b=7F=B19i=1A=B3=F8=EE=F9=D3=1F=CE=C6o=C2=D9=8B=97oN_}=7F= =FA=FC=C5=D37=A7=8B=C7=E3=F7=E5/=E3W=BF=3D{~=FA=DD=E9=9B=D3=DB =9CKK4=1F7]= =A7=B1=E9=A6S=DD=D9 =DFOm=BA=B2=98=C9M=07=86=067=1D=14=CD,=9E>=FF=A4=F3=C3= =F8=96~=B8=DE=EE=97=FD7=BB=0F'?lw=EF/=B7=DFl=D6'=DB=DFW=EF>=FFu=BD{=F7=00= =CBq=F8=D7=D9=AF=1F=B6=1F=B6g=EB=EB=AB=E3=C5=F8=D7=F1=F2Y4=BF{=E7=1BgL=B3= =B0=CD=F8=DF=9D=B5=E3=9F=D6=B9#=DF=99f9=FC=CF=7F6=1F=FF3=FEa>=FF=15=CC7=EE= =CC=F7=FB=DDog=D7=DB=AB=CD~{=FD=FE=B0=CC=DD/=17=DB=93=CF;=F5=9B=EB=CF=7F=8E= rNts=07=0FF=B5=EC=9FS_=9Em=AFn=F6=FF=08=9C=CC=D7=A7O=C7=C3~v=FA=F2=CD=AB=BF= =3D=FC=F8=D5=D7=7F{=F9=ECl|=DBs=0E=8B]=FC=F8=F2=B0=B5=B3=B6=DA=17=1B=D74=AD= |=E7=C6=D6z=BE=1D=DF=F7=D5~=FD=F3=E2a=F3=A8,=14v =0F=81]=B7=E6=DC=AA=9F=81C=BA=9F=F6=AB=CD=87=D5=CD=98q=F7=EE=DD=C5=CD=A7=C4= =FB=ED=BB=DDo=FFJ=ED=87f=A9=9D=FA=EB=AB{}=B9=BB=DEn=8A=DF=D4=D5f=03=BE!=827= =9E=F3=A6=B46=FD=9D=B1zEm:=95=BC=A8=95=C5L=16504X=D4=A0h=81=A26=08=8AZ,G=BC= =A8y=DF=B4_=17=B5=D6=1E=F5=B6=19:=93=BDw=B0=03}=EE=9B=CD[=ED=D4_};=D1=8B;= =BA=92=EC=F2\=BE=94=92=F2=AC=F0=1E=AA=95g=E8=AD =97g=F4r ]=DB=C9=D7>=FE=ECH=0F=D7=D4=D9=F9j=FD=CB=D9~=FBi=99=87?=0E=1B=F4=C7W/N=1E= =1C=FE=E7=E3'O>=C61=0F=16=CF_~B=B1=DD=D5=C5=CDn=FF=A0=EC=1B=F9E=EDo=ED=A3= =B2X=D8mQxY=1C=EAL=BF=D1>=B0W=1F./=CF=D6=AB=CB=CB=C3=BB=B08>=1C=D1=DD~|=936= =DB1=A5=F3=C5=DF=E3[=A5xH=97=E2=E2=F7A=96=EF=ED=EA=E2r=BB=11=A4=BD=C5=C2y'= =E6_=8D=11=C9=89=F9=F7Et=F9=EF=A5=EE=D7=8B=F1=FF=FF=C7qy=E8?=FE=FDb{=BD=B8= =DC=BE=BD=F9zA]Z=95=CB=E8=A1=94=C5LW~,4Z=F9'=A3=1D=DE=92V=C5a!=C2U=DA5=92L= =E1vM,=C2=F5=FEz1^<=B9v6=12=F5r=F7=13!=EA=FA=DD=FBE=F3=CD=E2f=B7[=EC.7=F9J= =04=D7h$=EA=E9=E1"B=99=E3=D9=EB=97=F07=E2=B0=B0=ED~1=DE=C9=DB_?=AC.=C7=B5.= =D67=BF+=7F=1F=BF=B0Y=87=8AxvpZ=BB=AB=EB-=C3mut=BF#=CCp1.t=7F3=16=82=1F=7F|= =F1|1=B4=E7=BD=EBW=F6=B1?o=DB=F1=BF=D6=EB=C7=FDy=D3<>=DF:;=9C=1B=D7o=CE=0BW= =944=1E]=05=E3=D1i8=81=AE=B2=13=E8=E6q=02=C85=1Bq=02`=D9 :=81=AE=C0 =B8=B8= =13p=C7=CD=84?=F1b'P=1A3=E1=04=E0=D0=90=13=00=A3)=94gY=A6Py=8EG()=CF=F1=A8%= =E59=B1=DAhy=96)A=ABK<=EA}(=CF=89=F7=BCVyNK=D0(=CF=F2=0Ce=E5=199=8AJ=F6_=BE= =B4=B8=13=90=C7=92;=81x=0E=81=13=C8Zt=81=13`=E7=8B8=81x=DAR8=07kE=C8c=E0{= =FB=AE=C7H=BFv,l=17=BB=AB=F1=9EYm=1E=9A=F6=D1=B8#v_|=FDO=AC@=13=8E=A9U<=A9= =93=A92lPQ=CC=B4=0D=C2B=A36=08=89=A6c=83=04=99"6=A8=A3=D8=A0=8Eb=83=BA=0C= =1B=D4QlPw=AFmP7=BF=0D=EA=E86=A8=ABl=83:Eo=D2U=F0&=9D=867=E9*{=93n=1Eo=82\= =B3=11=07=01=D6=DC=A0=83=A0u)=CC=84=AFY=EA9=81=E9Tr'P=163=E9=04=C0=D0=A0=13= =80=A2=A98=01I=A6=B0=130=94=86=88=A14DLFC=C4P=1A"=E6^7D=CC=FC=0D=11Co=88=98= =CA=0D=11=A3=D8=A50=15=BA=14F=A3Ka*w)=CC<] C=EBR@=17x=D8c=A0=D5<=E41=8CVsA/=D0=84c=EA=14=BD=C9d=AA=0CoR=143=EDM=B0=D0= =A87A=A2=E9x=13A=A6=887=A1t)=0C=A5Ka2=BA=14=86=D2=A50=F7=BAKa=E6=EFR=18z=97= =C2T=EER=18=C5.=85=A9=D0=A50=1A] S=B9Ka=E6=E9R=98=8E=E6M=90=0B<=E2M=C0j=1E=F4&]=05K! d'=9CV=AF=E7M=A6S=C9=BDIY=CC=A47=01C=83=DE=04=8A=A6=E2M$=99=C2=DE=C4R=FA&= =96=D27=B1=19}=13K=E9=9B=D8{=DD7=B1=F3=F7M,=BDob+=F7M=ACb=DF=C4V=E8=9BX=8D= =BE=89=AD=DC7=B1=F3=F4M,=ADo=02]=E0ao=82V=F3=907=B1=B6=82=A5=90=05=EA=D3=AB= =19=14=BD=C9d=AA=0CoR=143=EDM=B0=D0=A87A=A2=E9x=13A=A6=887=E9)=DE=A4=A7x=93= >=C3=9B=F4=14o=D2=DFko=D2=CF=EFMz=BA7=E9+{=93^=D1=9B=F4=15=BCI=AF=E1M=FA=CA= =DE=A4=9F=C7=9B=F44o=82\=E0=11o=02V=F3=A07=E9+X Q=A0=89=8F'1=8D=9E7=99N%=F7&e1=93=DE=04=0C=0Dz=13(=9A=8A7=91d {=93=E8=E7=C0=14y=93X=D42o=12]m=C2=9BH=94=E0=A55=16=F5~x=13=E0S=C2=D8=DE=84= =FDq]=F2=0C=A5=DE=A4=E0C=B9=EE=D4=C2=ECO=E5=12x=93X=0E=917)=FD=D0*=A97=E1= =E6=8Bz=13=E8=9A=0D;=08=B4=E6=86=1C=C4=F4'=EA=E5Z"=97=F65=C6(:=81=C9T=19N= =A0(f=DA `=A1Q'=80D=D3q=02=82L=11'@=E9R8J=97=C2et)=1C=A5K=E1=EEu=97=C2=CD= =DF=A5p=F4.=85=AB=DC=A5p=8A] W=A1K=E14=BA=14=AEr=97=C2=CD=D3=A5=80=AE=D9=88=13=00kn=D0 =D0=9A#~=C2=9FX= =3D'0=9DJ=EE=04=CAb&=9D=00=18=1At=02P4=15' =C9=14v=02=9E=D2=13=F0=94=9E=80= =CF=E8 xJO=C0=DF=EB=9E=80=9F=BF'=E0=E9=3D=01_=B9'=E0=15{=02=BEBO=C0k=F4=04|= =E5=9E=80=9F=A7'=E0=DD|%9=EA1=D0j=1E=F2=18=A9=D7=8A=C6=0Cz=81&=1C=93S=F4&= =93=A92=BCIQ=CC=B47=C1B=A3=DE=04=89=A6=E3M=04=99"=DE=84=D2=A5=F0=94.=85=CF= =E8RxJ=97=C2=DF=EB.=85=9F=BFK=E1=E9] _=B9K=E1=15=BB=14=BEB=97=C2kt)|=E5.=85=9F=A7K=E1y=ED=02=E4=02=8Fx=13=B0=9A= =07=BDI_=C1R=88=02=B5=13NK=F1=F3=F6=A6S=C9=BDIY=CC=A47=01C=83=DE=04=8A=A6= =E2M$=99=C2=DE=A4=A5=F4MZJ=DF=A4=CD=E8=9B=B4=94=BEI{=AF=FB&=ED=FC}=93=96=DE= 7i+=F7MZ=C5=BEI[=A1o=D2j=F4M=DA=CA}=93v=9E=BEIK=EB=9B@=17x=D8=9B=A0=D5<=E4M= ZW=C1R=C8=02M8-=C5O=18=9DN=95=E1M=8Ab=A6=BD =16=1A=F5&H4=1Do"=C8=14=F1&=94= =BEIK=E9=9B=B4=19}=93=96=D27i=EFu=DF=A4=9D=BFo=D2=D2=FB&m=E5=BEI=AB=D87i+= =F4MZ=8D=BEI[=B9o=D2=CE=D37ii}=13=E8=02=8Fx=13=B0=9A=07=BDI_=C1R=08=02=F9= =E3f=C2i=A9}=E6)=92J=EAMJc&=BC =1C=1A=F2&`4=05o"=CB=14=F2&=F1=08%=DE$=1E=B5= =C4=9B$V=1B=F5&2%hi=8DG=BD=0F=DE$=F1=9E=D7=F2&i =1A=DED=9E=A1=CC=9B=C8=F3E= =1F=0C/=0F%=B7&Yr%=AE=02]R=F0 =C8=7F=BC=D9/^=BE9}=F5=FD=E9=F3=17O=DF=9C.=1E= =8F=D7=EF_=C6=AF~{=F6=FC=F4=BB=D37=A7=05 =EAm=E7=F8=93v}=DB=9Eg<i=B7=3D=B6= =FD=B1[=A6=AF=FDN=E5=89=EE`*=D1=13=DD=15b=C6 =B9$=F4t!=C7=A3=DD}=A2{=D7`OtO=E6=88?=D1=DD8w=FB=89=EE=D6=F6ny44=CD=B2=05= =F6N_=F2D=F7u=EBM=AF=9E:=EF=11=EC*=B9=B3=EF=07=B5=95=17=97=BBd=86[[=F5=0E= =E4=E0/5_=9E=19=D3=B4=89C=D3c=97=D3W=CC4=FDZ=DD'=BAg=BD/=E1=A2=9D=15 =BB,=04g7=F2@w=DB=9Fg=9F=D7=A1=C8#=A4W=16=F8=0E=0E=F5V=E7=C6=8Cmz=9F=F6JE= =14J%,=A2=C51=E3E=14=0F=8D=14Q4=9AY=8C=A6.=B3=88&r=C4=8B=A8]7=B6=F5_=EE=1D= =D7=DA=F6=C8t=FD=B2k=B2=F7Nn%=D3=C8=9D_=C9=B4V=9ES=C9>y=F9GY[=E6VE=CA=D8=81= =98=E59=F7=8DYgo=94%=B0=92@Y=86^=1A=A9=A3=89=D7J=EBZF(q]K=E5=88=DE=FC+=D7= =B9=FC7E=FE=E9=D4=9B=ED=E5=F6f=9BW=DAR=19 =0B=F4=CBcg=D2[gP*mP*ai+=8E=19/mx= h=A4=B4=A1=D1JJ["G=9A=0Fo=976=BFt=E6=A8].]=EB=14=F6N=EC=EEuV=F2=3DBy=D3l=B9= K \=BE=82=13t=E7=F2=3D=BC6]=BDl=A3x=FA&Se=9C=BE=A2=98=E9=D3=87=85FO=1F=12= =ED=EE=E9K=B7.=1F`9=E2=A7o=BC=B5=FD=9D=D3=D7=1E-=9B~=D9=0C=D3[=B6=C8=AA=1C= =9A=8Ao=D5SgzZ=8D=DC=F9=9EVk=E5:=9E=16=DF=AD=90=A7E=C3E=EE6=F0~ =DEmJ=C62#=94p=CA=91=CE=91=EA=CB=DB=FC=D3=BB,5=96=82=B9=CA,=0BL=F7=F6=ACQ,m= =93=A92J[Q=CCti=C3B=A3=A5=0D=89=16(m=BD=A4=B4=F5=E5=3D=93q=EF=F4G=B6=ED=EC= =D0g=EF=9D=82=FAR=9C=BB=A8=BE=A8=AC\=AF=BE`[=06=AE/=BD=B6m/=FEv=DDZI=A4=B4= =81=F7S=B0=B4=F5z=A5-=F7g=0B{Ai=13=CF=02=CE=BD=DD=AC=19=A7=17,m=BD=B0=B4=D5= ]=E0=B8]=93[=C7=EA=95=B6=E9T=F2=D2V=163Y=DA=C0=D0`i=83=A2=05J['(m=B1=1C2j= =F3=CD=D1=D2vm=DBd=EF=9D=FC=D2V=9E=BB=A4=B4=E9=AC\=AD=B4=81[=06-m=C9=DD=810= =F6=B9=FAF=B9=B5=92piC=EF=A7Pi=93=BEK=89=D2&=0D=85=9D=DF=C2=E3{xS=D6=E7=8C= =D3=0B=96=B6NV=DAj/0=FDS=C2=D6)=96=B6=C9T=19=A5=AD(f=BA=B4a=A1=D1=D2=86D=0B= =94=B6=A5=A4=B49=0Dj=F3=EE=A8i=BCm=87=EC=BDSP=DA=8As=17=956=95=95=EB=956l= =CB=C0=A5=CD=95Q=9B=DD=AC=B47=CA=AD=95DJ=1Bx?=05K=9B=D3+m=B9?v=BD=14=946=97= =015[=C38=BD`i[ K[=E5=05=A6=1F=AEl=BDbi=9BL=95Q=DA=8Ab=A6K=1B=16=1A-mH=B4@ik%=A5=ADS=A1=B6= =EE=C8v=B6-=D8;=05=A5=AD8wQiSY=B9^i=C3=B6=0C\=DA=BA=92=D2=B6r]=EB=B47=CA=AD= =95DJ=1Bx?=05K[=A7W=DA=BA=CC=D2=D6 J['=FF=F1=DD=A6w=8C=D3=0B=96=B6VX=DA*/pHo=9DV=B1=B4M=A6=CA(mE1=D3=A5=0D=0B= =8D=966$Zii=1BT=A8m8j=9Dm;=8D=BD#=FB!=AE=A4~=84+V-u)=91=CB=17<A=A1=CBw=E2S= =89=ECR=EF=F4M=A7=92=9F=BE=B2=98=C9=D3=07=86=06O=1F=14-p=FA=BC=E0=F4=B5N=C3= X=B6=EEh|a3L=F7=DBZ=F5=9EIy=EE=12c=A9=B3r5c n=19=D4X=B6=AEp=1C=E0Z=ED=8Drk%= =E1=BB=0D=BD=9F$w[=86=B1=CC=FE=84?=8F=1B=CB6=E7=97=AB=BDa=9C^=D0Xz=99=B1=AC= =BD=C0=89=9F=FF=EB=14K=DBd=AA=8C=D2V=143]=DA=B0=D0hiC=A2=05J=9B=93=94=B6V= =E3=B7=03=DA=C3=0F=00=FA=AE=B3=D9{=A7=A0=B4=15=E7.*m*+=D7+m=D8=96=81K[=AB]= =DA=8A=BF]=B7V=12)m=E0=FD=14,m=AD^ik3K=9B=13=94=B66=E3=F7=C2<=E5=F4=82=A5= =CD K[=E5=05N=B4=DBz=C5=D26=99*=A3=B4=15=C5L=976,4Z=DA=90h=81=D2f%=A5Me=1C= =D0vG}k;=B3T=D8;=B2=9EI[=D8=B0^v=96=BA=94=C8=E5=0B=9E=A0=BB=97ow=DC=A4=7Fi= =CE=AA=FD=DA)=92Jz=FAJc&N=1F=1C=1A:}`=B4=C0=E93=F0=E9=8B=E7=10=19=CB=AE1G= =B6=F7=C3=E4=EFj&=F2=E5=1AK=85=DC=05=C6Ri=E5J=C6=12=DE2=98=B1=9C=D8=1D=C80= =CE=F5=DA=1B=E5=D6JBw=1B~?I=EE6=B1=B1=94=87=C2=CEo=E1=F1=FD=D8RX3N/h,=8D=C4= X=D6_=A0On=1D=D7(=96=B6=C9T=19=A5=AD(f=BA=B4a=A1=D1=D2=86D=0B=94=B6FR=DA=BC= =B4=B4=8D(a)r=B7=B4=F9#=D7=BAe?d=EF=9D=82=D2V=9C=BB=A8=B4=A9=AC\=AF=B4a[=06.m= ^w=D4=A9=F0=ED=BA=B5=92Hi=03=EF=A7`i=F3z=A5=CDg=96=B6FP=DA=BC=C6=CDO=DB=C3= =81=D2=D6=08K[=DD=05N|=C6=BD3z=A5m:=95=BC=B4=95=C5L=96604X=DA=A0hw?LVT=DA= =DA=BE=FC=C3d}=D7=F6G=ED=D29=93=BFw=F2K[y=EE=92=D2=A6=B3r=85Ot=C5=F7=0B=F4= =B1=ACS[c=B2=AE=BDm=97=CBA{=97=DCZI=B8=AE=A1=97S=A8=AE=B55?L6cKD=9EN=93=15+= =A7=90=8A/=0B=D7l=CE=BB-e=17T|;=D0=87=EF=E4=BE=A7=B7>&=BF=C1=1F=BES!_=E8=E1= ;=C813=CB=EC=13=FA=C7Ce$'=B4=E8=99?c=E4~=EA=C1(=CE=AA<=EA=06L%z=D4=8DB=CC= =84=A9=81CC=A6=06=8CV=FA=A8=1Bq=A6;=8F=BAIF=B8=F3=A8=1B=81}=EE=F5=1Fu=93^= =ED=BB=F7=8B=C7=E6=EE=B3n=C4R=C0=87M=D0=A5=E0=1F=D9=CD=97=82=7F=C4*] =FE=A1\5=A4=80=1F=A2RA =FAK=EF5=A4=80=BF=A4XC =F8K%=15=A4=A0?=86XC =F8c#|)=F0=A0=A1=86=94=E2=CA=16y=DC=9AX =8A=0E=3D=E9=81ej=124x=BF/|`=D9fXu= =AD}=BBy=BCZ=9F=BB=C7~=BD2=8FW=E7=C6?=EE=97=E7=FD=CA=0D}o=D6=DB=B2|q\=ED=F3= =9FX=06=E3j<=87=80=E7=FA=E2=C7=9E=C9x=8E=9D/=C2s=A0Y=0E=F1=1CNNwy=AE=07=1E= =C2=96=E09=97=E4=B9=89>=90S=E4=B9=C9T=19<W=143=CDsXh=94=E7=90h:<'=C8=14=E1= =B9=9E=C2s=3D=85=E7=FA=9C=B2=DESx=8E*E=C6s\)"=9E=E3J=11=F1=1C] =CEsl)=02=9E=A3K=C1y=8E.=05=E79=B6=14=01=CF=D1=A5=E0<G=96"=E19=BA=94=E2=CA= =96=E4=B9=9E=C2s=FD=FC<=D7=D3y=AE=AF=CCs=BD"=CF=F5=15x=AE=D7=E0=B9=BE2=CF= =F5=F3=F0=1Cb=96#<=07=92S=90=E7h=F393A=99^=8F=E7=A6S=C9y=AE,f=92=E7=C0=D0 = =CFA=D1TxN=92)=CCs=862=9F3=94=F9=9C=C9i=D3=1A=CA|=8E+E=C4sd)=12=9E#K=91=F0= =1C_ =CCst)8=CF=F1=A5=C0<=C7=97=02=F3=1C] =CEs|)0=CF=B1=A5=08x=8E/=A5=B8=B2=A5x=CEP=E6sf=FE=F9=9C=A1=CF=E7L=E5=F9=9CQ= =9C=CF=99 =F39=A31=9F3=95=E7sf=9E=F9=1Cd=96=C3<=87=92S=88=E7=8C=A3=F1=DC=04e=B6=8A<7= =99*=83=E7=8Ab=A6y=0E=0B=8D=F2=1C=12M=87=E7=04=99"<G=99=CF=19=CA|=CE=E4=B4i= =0De>=C7=95"=E39=AE=14=11=CFq=A5=88x=8E.=05=E79=B6=14=01=CF=D1=A5=E0<G=97= =82=F3=1C[=8A=80=E7=E8Rp=9E#K=91=F0=1C]JqeK=F2=1Ce>g=E6=9F=CF=19=FA|=CET=9E= =CF=19=C5=F9=9C=A90=9F3=1A=F39Sy>g=E6=99=CFAf9=C2s 9=05y=8E6=9F=B3=13=94=B9= =D4=E3=B9=E9Tr=9E+=8B=99=E4904=C8sP4=15=9E=93d =F3=9C=A5=CC=E7,e>gs=DA=B4=962=9F=E3J=11=F1=1CY=8A=84=E7=C8R$<=C7=97=02=F3= =1C] =CEs|)0=CF=F1=A5=C0<G=97=82=F3=1C_ =CCsl)=02=9E=E3K)=AEl)=9E=B3=94=F9=9C=9D=7F>g=E9=F39[y>g=15=E7s=B6=C2|=CEj= =CC=E7l=E5=F9=9C=9Dg>g=DD|`=15%E=94=C9B=A4=98z=ED=C8=0C=17=BB=AB=F1=F0=AF6= =0FM=FBh=DC=11=BB/=BE=FE'V=A0 =EE=ED=14 s2U=06a=16=C5L=13&=16=1A%L$=9A=0Ea 2E=08=9321=B4=94=89=A1=CDi=1C[=CA=C4=90+EF=98\)"=C2=E4J=11=11&] N=98l)=02=C2=A4K=C1 =93.=05'L=B6=14=01a=D2=A5=E0=84I=96"!L=BA=94=E2=CA=96$L= =CA=C4=D0=CE?1=B4=F4=89=A1=AD<1=B4=8A=13C[abh5&=86=B6=F2=C4=D0=CE31=B4=BC= =D1=1Db=C3#=84 2Y=900=FB `( =E4&x=B9=D7#=CC=E9Tr=C2,=8B=99$L04H=98P4=15=C2=94d =13=A6=A3=CC0=1De=86=E9rZ=D9=8E2=C3=E4J=11=11&Y=8A=840=C9R$=84=C9=97=02=13&] N=98|)0a=F2=A5=C0=84I=97=82=13&_ L=98l)=02=C2=E4K)=AEl)=C2t=94=19=A6=9B=7F=86=E9=E83LWy=86=E9=14g=98=AE=C2= =0C=D3i=CC0]=E5=19=A6=9Bg=86=E9h3L=C8=86=87 =13e=B2=10a:W=01=0Ce=81&xyP$=CC= =C9T=19=84Y=143M=98Xh=940=91h:=84)=C8=14!L=CA=0C=D3Qf=98.=A7=95=ED(3L=AE=14= =19ar=A5=88=08=93+ED=98t)8a=B2=A5=08=08=93.=05'L=BA=14=9C0=D9R=04=84I=97=82= =13&Y=8A=840=E9R=8A+[=920)3L7=FF=0C=D3=D1g=98=AE=F2=0C=D3)=CE0]=85=19=A6=D3= =98a=BA=CA3L7=CF=0C=D3=F5=AC=C7=3D@6<B=98 =93=05 =B3=AF=00=86=A2@>=CD=CB=BE= =D1#=CC=E9Tr=C2,=8B=99$L04H=98P4=15=C2=94d =13=A6=A7=CC0=3De=86=E9sZ=D9=9E2=C3=E4J=11=11&Y=8A=840=C9R$=84=C9=97=02=13&] N=98|)0a=F2=A5=C0=84I=97=82=13&_ L=98l)=02=C2=E4K)=AEl)=C2=F4=94=19=A6=9F=7F=86=E9=E93L_y=86=E9=15g=98=BE=C2= =0C=D3k=CC0}=E5=19=A6=9Fg=86=E9i3L=C8=86=87 =13e=B2=10azW=01=0Ce=81=D2=BC= =EC=8D"aN=A6=CA =CC=A2=98i=C2=C4B=A3=84=89D=D3!LA=A6=08aRf=98=9E2=C3=F49=AD= lO=99ar=A5=C8=08=93+ED=98\)"=C2=A4K=C1 =93-E@=98t)8a=D2=A5=E0=84=C9=96" L= =BA=14=9C0=C9R$=84I=97R\=D9=92=84I=99a=FA=F9g=98=9E>=C3=F4=95g=98^q=86=E9+= =CC0=BD=C6=0C=D3W=9Ea=FAyf=98=90Y=8Ep HNA=0E=A4=FD=FAg=EB=D3=AA=AC=1E=CFM= =A7=92=F3\Y=CC$=CF=81=A1A=9E=83=A2=A9=F0=9C$S=98=E7b=11=CAx.=16=B5=8C=E7=A2= =ABM=95u=89=14=9C=E7=B8RD<G=96"=E19=B2=14 =CF=F1=A5=C0<G=97=82=F3=1C_ =CCs|)0=CF=D1=A5=E0<=C7=97=02=F3=1C[=8A=80=E7=F8R=8A+[=8A=E7$Jp=98=8AV=EEz<= =97=92=A0=C3s=D2=0C=A5<'=CD=97=E29i=AC=1C=9E=8B=E5=10=F1\=C6=A2=8Bx=8E=9B/= =CAs=90Y=0E=F3=1CJN!=9E=8B=BDV=81=E7=86=B4*=A7=C8s=93=A92x=AE(f=9A=E7=B0=D0= (=CF!=D1txN=90)=C2s=03=85=E7=06 =CF=0D9e}=A0=F0=1CU=8A=8C=E7=B8RD<=C7=95"=E29=BA=14=9C=E7=D8R=04<G=97=82=F3= =1C] =CEsl)=02=9E=A3K=C1y=8E,E=C2st)=C5=95-=C9s=03=85=E7=86=F9yn=A0=F3=DCP=99=E7= =06E=9E=1B*=F0=DC=A0=C1sCe=9E=1B=E6=E19=C4,Gx=0E$=A7 =CF=0D=1C=9E=1B=8E=9B = =CA=F4Z<=87=A4=92=F2\i=CC=04=CF=C1=A1!=9E=03=A3)=F0=9C,S=88=E7=E2=11Jx.=1E= =B5=84=E7=12=AB=8D=97u=99=14=94=E7=D8R=04<G=97=82=F3=1C] =CEs5=A4=80<WA =CAs5=A4=80<WC =C8s=15=A4=A0<WC =C8s|)0=CF=D5=90R\=D9=E2<'S=82=C2T=A2r=D7=E2=B9=B4=04=0D=9E=93g(=E39y=BE8= =CF=C9c=C9y.=9EC=C0sY=8B.=E09v=BE=08=CF=81f9=C4s89=DD=E5=B9=F8k=15xn=822[E= =9E=9BL=95=C1sE1=D3<=87=85Fy=0E=89=A6=C3s=82L=11=9E=1B(<7Pxn=C8)=EB=03=85= =E7=A8Rd<=C7=95"=E29=AE=14=11=CF=D1=A5=E0<=C7=96"=E09=BA=14=9C=E7=E8Rp=9EcK= =11=F0=1C] =CEsd)=12=9E=A3K)=AElI=9E=1B(<7=CC=CFs=03=9D=E7=86=CA<7(=F2=DCP=81=E7=06=0D= =9E=1B*=F3=DC0=0F=CF=0D=F3=81U=9C=14A&=0B=92=E2=A0=F2=C1*=8A=81=CC=04=F7.= =F5=08s:=95=9C0=CBb& =13=0C=0D=12&=14M=850%=99=C2=84i(=13CC=99=18=9A=9C=C6= =B1=A1L=0C=B9RD=84I=96"!L=B2=14 a=F2=A5=C0=84I=97=82=13&_ L=98|)0a=D2=A5=E0=84=C9=97=02=13&[=8A=800=F9R=8A+[=8A0=0Debh=E6=9F=18=1A=FA= =C4=D0T=9E=18=1A=C5=89=A1=A9014=1A=13CSybh=E6=99=18=1A=DA=E8=0E=B2=E1a=C2D= =99,D=98=A9=D7=AA=81=A1,=D0=04/w=8A=849=99*=830=8Bb=A6 =13=0B=8D=12&=12M=87= 0=05=99"=84I=99a=1A=CA=0C=D3=E4=B4=B2=0De=86=C9=95"#L=AE=14=11ar=A5=88=08= =93.=05'L=B6=14=01a=D2=A5=E0=84I=97=82=13&[=8A=800=E9Rp=C2$K=91=10&]JqeK=12= &e=86i=E6=9Fa=1A=FA=0C=D3T=9Ea=1A=C5=19=A6=A90=C34=1A3LSy=86i=E6=99a=1A=DA= =0C=13=B2=E1=11=C2=04=99,H=98C=050=14=05=B2=13=BC=DC=EB=11=E6t*9a=96=C5L=12= &=18=1A$L(=9A aJ2=85 =D3Rf=98=962=C3=B49=ADlK=99ar=A5=88=08=93,EB=98d)=12=C2=E4K=81 =93.= =05'L=BE=14=980=F9R`=C2=A4K=C1 =93/=05&L=B6=14=01a=F2=A5=14W=B6=14aZ=CA=0C= =D3=CE?=C3=B4=F4=19=A6=AD<=C3=B4=8A3L[a=86i5f=98=B6=F2=0C=D3=CE3=C3=B4=B4= =19&d=C3=C3=84=892Y=880=AD=AF=00=86=B2@=13=BC<(=12=E6d=AA=0C=C2,=8A=99&L,4J= =98H4=1D=C2=14d=8A=10&e=86i)3L=9B=D3=CA=B6=94=19&W=8A=8C0=B9RD=84=C9=95""L= =BA=14=9C0=D9R=04=84I=97=82=13&] N=98l)=02=C2=A4K=C1 =93,EB=98t)=C5=95-I=98=94=19=A6=9D=7F=86i=E93L[y=86i=15= g=98=B6=C2=0C=D3j=CC0m=E5=19=A6=9Dg=86ii3L=C8=86G=08=13d=B2 a=0E=15=C0P=14= =C8=A5y=B9m=F4=08s:=95=9C0=CBb& =13=0C=0D=12&=14M=850%=99=C2=84=E9(3LG=99a= =BA=9CV=B6=A3=CC0=B9RD=84I=96"!L=B2=14 a=F2=A5=C0=84I=97=82=13&_ L=98|)0a=D2=A5=E0=84=C9=97=02=13&[=8A=800=F9R=8A+[=8A0=1De=86=E9=E6=9Fa:=FA= =0C=D3U=9Ea:=C5=19=A6=AB0=C3t=1A3LWy=86=E9=E6=99a:=DA=0C=13=B2=E1a=C2D=99,D= =98=CEW=00CY=A04/=B7F=910'Se=10fQ=CC4ab=A1Q=C2D=A2=E9=10=A6 S=840)3LG=99a= =BA=9CV=B6=A3=CC0=B9Rd=84=C9=95""L=AE=14=11a=D2=A5=E0=84=C9=96" L=BA=14=9C0= =E9Rp=C2dK=11=10&] N=98d)=12=C2=A4K)=AElI=C2=A4=CC0=DD=FC3LG=9Fa=BA=CA3L=A78=C3t=15f=98Nc=86= =E9*=CF0=DD<3L=C8,G8=10$=A7 =07=D2F=A7~=82N=AD=1E=CFM=A7=92=F3\Y=CC$=CF=81= =A1A=9E=83=A2=A9=F0=9C$S=98=E7<eb=E8)=13C=9F=D38=F6=94=89!W=8A=88=E7=C8R$<G= =96"=E19=BE=14=98=E7=E8Rp=9E=E3K=81y=8E/=05=E69=BA=14=9C=E7=F8R`=9EcK=11=F0= =1C_JqeK=F1=9C=A7L=0C=FD=FC=13CO=9F=18=FA=CA=13C=AF81=F4=15&=86^cb=E8+O=0C= =FD<=13C=C8,=87y=0E%=A7=10=CFy_=9B=E76=AB=ED=BB=DD=D5=F8=FD=FC=F9=C3=CDf=F7= =F7=AB1=C6=AF=1F=B6=D7=87c=B1=BA=DA=8Cg=E4=E2=E6b5=FE=EB=E8=ABp]=E4m9=FC=EB= =8F`=C7=8B=BF=AF=C6=D7=8F=E2=DE=8E;=EA0=0B=DD=EEW=87=E1=E1=F5=93=9B=D5=F5/= =D7=E3=158=C2=CB=D5=C5=F5=CF_E=1F=92=D1ov=EF=DF=1F=14=FD=13=11bZ$=A9=0F=02= =00=A5=C0<=C7=96"=E09=BE=94=EC=CA=16=E39O=99=18=FA=E9'=86=9E>1=F4=85'=86^qb= =E8=0BL=0C=BD=C6=C4=D0=17=9E=18=FAi&=86=90Y=1E=E69=94=9C=86x=CE=FB=D2<=B7^n= =AE=B77=FD=F7=F3=C7=BB=DB=F5=F6=D7=9B>=C6=CFw=9B=FD=E1X,o=D6=FD=19=B9=BC=BD= \=F6=7F=9B=7F=12=AE =BC-=87=BF=FD=11=ECd=F6=EB=B2=7F}/=EEM=BF=A3=0E=B3=D0= =CDny=18=1E=EE=8Fo=97=FB=9F=F6=FD=15=D8=C3=CB=CD=E5=FE=C7O=A2w=D1=E8=B7=DB= =B7o=0F=8A=FE=1F=FA=AF=82=96=7F=10=02=00 --UugvWAfsgieZRqgk--

1 0

Re: (ITS#6999) retry: counter not reaching zero, continuing on
by hyc＠symas.com 28 Jul '11

28 Jul '11

ml+openldap(a)esmtp.org wrote: > The full log for one failed retry is: I think we need to see more of the log than this. The only reason for your observed behavior to occur is that somewhere along the line, a step in the replication actually returned LDAP_SUCCESS, which resets the retry counter. So we need to see the complete log for at least one full cycle of "(4 retries left)", "(3 retries left)", "(4 retries left)". > conn=1004 op=0 BIND dn="cn=manager" method=128 > conn=1004 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 > conn=1004 op=0 RESULT tag=97 err=0 text= > conn=1004 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" > conn=1004 op=1 SRCH attr=* + > srs csn 20110722201233.471069Z#000000#001#000000 > log csn 20110722201233.471069Z#000000#001#000000 > cmp 0, too old > log csn 20110722201252.820971Z#000000#001#000000 > Entry uid=user68,ou=People,dc=example,dc=com CSN > 20110722201233.471069Z#000000#001#000000 > older or equal to ctx 20110722201233.471069Z#000000#001#000000 > syncprov_search_response: > cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 > syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) > syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 > conn=1004 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) > syncrepl_entry: rid=001 be_search (52) > syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com > null_callback : error code 0x34 > syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) > syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed > (52) > do_syncrepl: rid=001 rc 52 retrying (4 retries left) > conn=1004 op=2 UNBIND > conn=1004 fd=15 closed > connection_read(15): no connection! > connection_read(15): no connection! > > -- -- 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#7002) Patch - Mozilla NSS - if client cert is bad, VerifyCert allow should warn and try should fail
by hyc＠symas.com 28 Jul '11

28 Jul '11

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.26 (tip of git OPENLDAP_REL_ENG_2_4) > OS: RHEL6 > URL: ftp://ftp.openldap.org/incoming/0001-Patch-Mozilla-NSS-if-client-cert-is-ba… > Submission from: (NULL) (76.113.106.30) > > > If the olcTLSVerifyClient is set to a value other than "never", the server > should request that the client send a client certificate for possible use with > client cert auth (e.g. SASL/EXTERNAL). > If set to "allow", if the client sends a cert, and there are problems with it, > the server will warn about problems, but will allow the SSL session to proceed > without a client cert. > If set to "try", if the client sends a cert, and there are problems with it, the > server will warn about those problems, and shutdown the SSL session. > If set to "demand" or "hard", the client must send a cert, and the server will > shutdown the SSL session if there are problems. > I added a new member of the tlsm context structure - tc_warn_only - if this is > set, tlsm_verify_cert will only warn about errors, and only if TRACE level debug > is set. This allows the server to warn but allow bad certs if "allow" is set, > and warn and fail if "try" is set. > > Note: The patch applies on top of ITS#7001 - you cannot apply this patch first, > then the patch to 7001 This patch does not apply cleanly to git master. Please remember the devel guidelines - all submissions must be relative to git master. I've cleaned up the rejected parts of this patch so you don't need to resubmit this one. -- -- 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#6996) Bad cn=config quotes in Admin Guide
by hyc＠symas.com 28 Jul '11

28 Jul '11

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: master, 2.4.26 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > http://www.openldap.org/doc/admin24/slapdconf2.html > contains a number of examples with quoted DNs in cn=config attributes: > olcSuffix, olcRootDN. This is wrong, likely a cut&paste from slapd.conf. There's nothing wrong here, the config parser accepts quotes for these attributes. -- -- 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#7004) ppolicy pwdCheckQuality constraint prevents from changing userPassword, even if pwdPolicySubentry is removed in the same modify operation
by masarati＠aero.polimi.it 27 Jul '11

27 Jul '11

> Full_Name: Clément OUDOT > Version: 2.4.26 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (90.9.0.93) > > > I have a piece of code that does this singel modify operation on OpenLDAP: > * remove pwdPolicySubentry value > * replace userPassword value > > My password policy has pwdCheckQuality set to 2 (strict checking). My new > userPassword value is {SASL}bob(a)example.com. But the modify operation > failed > with: > > conn=1058 op=100 RESULT tag=103 err=19 text=Password fails quality > checking > policy > > > I was thinking than removing the pwdPolicySubentry was sufficient to > disable all > ppolicy constraint on the userPassword replacement in the same modify > operation. > Am I wrong or do I face a ppolicy overlay bug? I think this question should be directed to openldap-technical, as it is a usage question. In detail, I think the behavior of slapd and slapo-ppolicy(5) is correct, because pwdPolicySubentry was present when the operation initiated, and thus the behavior of slapo-ppolicy(5) needs to be based on the entry's content when the operation was initiated. I also think this may represent a possible field of application of the "relax" control, although neither draft-zeilenga-ldap-relax nor draft-behera-ldap-password-policy document it. Something like the relax control would allow to change a password despite the password policy, as soon as the final result complies with the protocol, including extensions. This would mean that slapo-ppolicy(5) constraints would eventually be evaluated for the entry as it results from the operation. But I think I've gone too far in discussing a usage question on the ITS. p.

1 0

(ITS#7004) ppolicy pwdCheckQuality constraint prevents from changing userPassword, even if pwdPolicySubentry is removed in the same modify operation
by clem.oudot＠gmail.com 27 Jul '11

27 Jul '11

Full_Name: Clément OUDOT Version: 2.4.26 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (90.9.0.93) I have a piece of code that does this singel modify operation on OpenLDAP: * remove pwdPolicySubentry value * replace userPassword value My password policy has pwdCheckQuality set to 2 (strict checking). My new userPassword value is {SASL}bob(a)example.com. But the modify operation failed with: conn=1058 op=100 RESULT tag=103 err=19 text=Password fails quality checking policy I was thinking than removing the pwdPolicySubentry was sufficient to disable all ppolicy constraint on the userPassword replacement in the same modify operation. Am I wrong or do I face a ppolicy overlay bug?

1 0

(ITS#7003) Document typo
by xianhua.zhou＠gmail.com 26 Jul '11

26 Jul '11

Full_Name: Zhou Xianhua Version: 2.4 OS: Ubuntu11.04 URL: Submission from: (NULL) (116.231.39.45) page: http://www.openldap.org/doc/admin24/slapdconfig.html section: "6.2.2.1. backend <type>" There is a table's title called "Table 5.2: Database Backends", it should be "Table 6.2: Database Backends".

1 0

Re: (ITS#6994) Syncrepl with MozNSS inherits TLS context form main configuration breaking some syncrepl setups
by richm＠stanfordalumni.org 25 Jul '11

25 Jul '11

On 07/11/2011 10:44 AM, thibault.lemeur(a)supelec.fr wrote: > Full_Name: Thibault Le Meur > Version: 2.4.23-15 > OS: RHEL6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (160.228.28.55) > > > Previously on my FC13 installation (openldap-servers-2.4.21-11) the main slapd > process used an X509 "server" while my syncrepl processes were using the > /etc/openldap/ldap.conf client configuration file in order to connect to my > LDAPs Syncrepl providers. > > In my new RHEL6 setup (openldap-servers-2.4.23-15.el6.x86_64) is linked to > MozNSS and Syncrepl can't connect to my LDAPs providers anymore because it > complains about the TLS context not beeing intitialized correctly (the server's > certificate isn't accepted as a client certificate). > > Here is the lightly obfuscated log: > > ---------------------------------------------------------- > ldap_connect_to_host: Trying 10.10.10.10:636 > ldap_pvt_connect: fd: 21 tm: -1 async: 0 > TLS: loaded CA certificate file /etc/ssl/cacerts/cacert.pem. > TLS: certificate [CN=myldap.mydom.fr,OU=myou,O=myorg,L=myloc,ST=myst,C=FR] is > not valid - error -8101:Unknown code ___f 91. > TLS: error: unable to set up client certificate authentication for certificate > named PEM Token #0:myldap.mydom.fr-cert.pem - 0 > TLS: error: unable to set up client certificate authentication using PEM Token > #0:myldap.mydom.fr-cert.pem - 0 > TLS: error: could not initialize moznss security context - error -8101:Unknown > code ___f 91 > TLS: can't create ssl handle. > slap_client_connect: URI=ldaps://otherldap.mydom.fr > DN="cn=myreplicationAccount,dc=mydom,dc=fr" ldap_sasl_bind_s failed (-1) > do_syncrepl: rid=125 rc -1 retrying (9 retries left) > ---------------------------------------------------------- > > Here is my syncrepl setup: > --------------------------------------------------------- > syncrepl rid=125 > provider=ldaps://otherldap.mydom.fr > type=refreshOnly > interval=00:00:03:00 > retry="60 10 300 +" > searchbase="dc=subranch,dc=mydom,dc=fr" > filter="(objectClass=*)" > scope=sub > schemachecking=off > bindmethod=simple > binddn="cn=myreplicationAccount,dc=mydom,dc=fr" > credentials="MyVerySecretPassword" > --------------------------------------------------------- > > My setup related to TLS: > --------------------------------------------------------- > TLSCipherSuite HIGH > TLSCertificateFile /etc/ssl/certs/myldap.mydom.fr-cert.pem > TLSCertificateKeyFile /etc/ssl/keys/myldap.mydom.fr-key.pem > TLSCACertificateFile /etc/ssl/cacerts/cacert.pem > --------------------------------------------------------- > > And my /etc/openldap/ldap.conf: > --------------------------------------------------------- > TLS_CACERT /etc/ssl/cacerts/cacert.pem > --------------------------------------------------------- > > Here is the obfuscated certificate: > --------------------------------------------------------- > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 221 (0xdd) > Signature Algorithm: sha1WithRSAEncryption > Issuer: C=FR, ST=myst, L=myloc, O=myorg, OU=myou, > CN=myCA/emailAddress=myemail(a)mydom.fr > Validity > Not Before: Oct 2 16:42:15 2007 GMT > Not After : Dec 14 16:42:15 2012 GMT > Subject: C=FR, ST=myst, L=myloc, O=myorg, OU=myou, CN=myldap.mydom.fr > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (2048 bit) > Modulus: > ... > Exponent: 65537 (0x10001) > X509v3 extensions: > X509v3 Basic Constraints: > CA:FALSE > Netscape Cert Type: > SSL Server > Netscape Comment: > TinyCA Generated Certificate > X509v3 Subject Key Identifier: > ... > X509v3 Authority Key Identifier: > keyid:... > DirName:/C=FR/ST=myst/L=myloc/O=myorg/OU=myou/CN=myCA/emailAddress=thibault.lemeur@supelec.fr > serial:00 > > X509v3 Issuer Alternative Name: > <EMPTY> > > Netscape SSL Server Name: > myldap.mydom.fr > X509v3 Subject Alternative Name: > DNS:ldap, DNS:ldapalias1, DNS:ldapalias2, > DNS:ldapalias1.mydom.fr, DNS:ldapalias2.mydom.fr, DNS:ldap.mydom.fr, DNS:myldap, > DNS:myldap.mydom.fr > X509v3 Extended Key Usage: critical > TLS Web Server Authentication, Code Signing > Signature Algorithm: sha1WithRSAEncryption > ... > --------------------------------------------------------- I think this ITS is superseded by http://www.openldap.org/its/index.cgi?findid=7001 and http://www.openldap.org/its/index.cgi?findid=7002 Note that even with openldap built with openssl (ol 2.4.latest and openssl 1.0.x), the syncrepl tls context is inherited from the main server context, and the server cert is sent as the client cert. If the server sets TLSVerifyClient to never or allow, syncrepl will work, because the server will ignore the problems with the client cert. But if TLSVerifyClient is set to "try", "demand", or "hard", syncrepl will fail because the server always sends the server cert as the client cert, and since the server cert cannot also be used as a client cert, the server will correctly reject it.

1 0

(ITS#7002) Patch - Mozilla NSS - if client cert is bad, VerifyCert allow should warn and try should fail
by rmeggins＠redhat.com 25 Jul '11

25 Jul '11

Full_Name: Rich Megginson Version: 2.4.26 (tip of git OPENLDAP_REL_ENG_2_4) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/0001-Patch-Mozilla-NSS-if-client-cert-is-ba… Submission from: (NULL) (76.113.106.30) If the olcTLSVerifyClient is set to a value other than "never", the server should request that the client send a client certificate for possible use with client cert auth (e.g. SASL/EXTERNAL). If set to "allow", if the client sends a cert, and there are problems with it, the server will warn about problems, but will allow the SSL session to proceed without a client cert. If set to "try", if the client sends a cert, and there are problems with it, the server will warn about those problems, and shutdown the SSL session. If set to "demand" or "hard", the client must send a cert, and the server will shutdown the SSL session if there are problems. I added a new member of the tlsm context structure - tc_warn_only - if this is set, tlsm_verify_cert will only warn about errors, and only if TRACE level debug is set. This allows the server to warn but allow bad certs if "allow" is set, and warn and fail if "try" is set. Note: The patch applies on top of ITS#7001 - you cannot apply this patch first, then the patch to 7001

1 0

(ITS#7001) Patch - Mozilla NSS - memleak - free the return of tlsm_find_and_verify_cert_key
by rmeggins＠redhat.com 25 Jul '11

25 Jul '11

Full_Name: Rich Megginson Version: 2.4.26 (tip of git OPENLDAP_REL_ENG_2_4) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/0001-Patch-Mozilla-NSS-memleak-free-the-ret… Submission from: (NULL) (76.113.106.30) If tlsm_find_and_verify_cert_key finds the cert and/or key, and it fails to verify them, it will leave them allocated for the caller to dispose of. There were a couple of places that were not disposing of the cert and key upon error. These patch files are 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, Rich Megginson 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.

1 0

(ITS#7000) Slapd crashed during modrdn in syncrepl
by tedcheng＠symas.com 25 Jul '11

25 Jul '11

Full_Name: Ted C. Cheng Version: trunk OS: RHEL 5 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.194.135.105) 2655 static int 2656 syncrepl_entry( 2657 syncinfo_t* si, . 3082 retry_modrdn:; 3083 rs_reinit( &rs_modify, REP_RESULT ); 3084 rc = op->o_bd->be_modrdn( op, &rs_modify ); 3085 3086 /* NOTE: noSuchObject should result because the new superior 3087 * has not been added yet (ITS#6472) */ #ifdef SLAPD_CRASHED_MODRDN_SYNCREPL 3088 if ( rc == LDAP_NO_SUCH_OBJECT && !BER_BVISNULL( op->orr_nnewSup )) { #else /* fix */ 3088 if ( rc == LDAP_NO_SUCH_OBJECT && (op->orr_nnewSup != NULL ) && !BER_BVISNULL( op->orr_nnewSup )) { #endif /* SLAPD_CRASHED_MODRDN_SYNCREPL */ 3089 Operation op2 = *op;

1 0

(ITS#6999) retry: counter not reaching zero, continuing on
by ml+openldap＠esmtp.org 25 Jul '11

25 Jul '11

Full_Name: Claus Assmann Version: 2.4.23 OS: Red Hat Enterprise Linux Server release 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.211.143.38) While trying to determine how syncrepl behaves in various error conditions, I encountered an unexpected behaviour in which the retry specification doesn't seem to work. A MASTER is set up to use push replication to a REPLICA as follows: database ldap hidden on suffix "" rootdn "cn=slapd-ldap" uri ldap://REPLICA/ lastmod on restrict all sync_use_subentry true acl-bind bindmethod=simple binddn="cn=Monitor" credentials=password syncrepl rid=001 provider=ldapi://%2Fvar%2Frun%2Fldapi binddn="cn=Manager" bindmethod=simple credentials=passwd searchbase="" type=refreshAndPersist retry="5 5 60 +" When I stop the REPLICA and add an entry on the MASTER, then the MASTER is retrying every 5s and claims that 4 (sometimes 3) retries are left: Jul 22 13:12:52 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:12:57 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (3 retries left) Jul 22 13:13:02 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:07 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (3 retries left) Jul 22 13:13:12 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:17 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:22 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:28 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:33 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:38 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:43 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:48 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:53 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:58 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) When I start REPLICA again, syncrepl succeeds. Do I have to set some other option such that the retry specification is actually used? That is, try every 5s for 5 times, then try every 60s. Or is the retry logic dependent on the error syncrepl encounters? The full log for one failed retry is: conn=1004 op=0 BIND dn="cn=manager" method=128 conn=1004 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 conn=1004 op=0 RESULT tag=97 err=0 text= conn=1004 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" conn=1004 op=1 SRCH attr=* + srs csn 20110722201233.471069Z#000000#001#000000 log csn 20110722201233.471069Z#000000#001#000000 cmp 0, too old log csn 20110722201252.820971Z#000000#001#000000 Entry uid=user68,ou=People,dc=example,dc=com CSN 20110722201233.471069Z#000000#001#000000 older or equal to ctx 20110722201233.471069Z#000000#001#000000 syncprov_search_response: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 conn=1004 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) syncrepl_entry: rid=001 be_search (52) syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com null_callback : error code 0x34 syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) do_syncrepl: rid=001 rc 52 retrying (4 retries left) conn=1004 op=2 UNBIND conn=1004 fd=15 closed connection_read(15): no connection! connection_read(15): no connection!

1 0

(ITS#6998) MozNSS: when server certificate is not required, ignore expired issuer errors
by jvcelak＠redhat.com 20 Jul '11

20 Jul '11

Full_Name: Jan Vcelak Version: 2.4.26 OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-nss-ignore-issuer-expiration-110720… Submission from: (NULL) (209.132.186.34) Hello. When the server certificate validity is not required in a TLS session (e.g. TLS_REQCERT is set to 'never'), expired certificate of the issuer of the server certificate causes the connection to be terminated. Uploaded patch fixes this by adding SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE error to the list of ignored errors, when the certificate is not being checked. The patch is created against OPENLDAP_REL_ENG_2_4 branch. Jan

1 0

Re: (ITS#6770) Proxy authorization fails with SASL-GSSAPI
by c.waeschenfelder＠websale.de 20 Jul '11

20 Jul '11

> Something in this area should have been fixed in master code; some fixes > may have been released in 2.4.26. Can you indicate what version you're > using? In case you're using the latest, can you test with master code? > > p. The problem seems already solved in 2.4.26. The authorization seems to work reliable now, I couldn't recognize any authorization errors after upgrading to 2.4.26.

1 0

Re: (ITS#6770) Proxy authorization fails with SASL-GSSAPI
by masarati＠aero.polimi.it 20 Jul '11

20 Jul '11

Please keep replies in cc with the ITS. On 07/20/2011 10:28 AM, Christian Wäschenfelder wrote: > >> Something in this area should have been fixed in master code; some fixes >> may have been released in 2.4.26. Can you indicate what version you're >> using? In case you're using the latest, can you test with master code? >> >> p. >> > > At the moment I'm using 2.4.23-7 on debian squeeze. > I'll try it with 2.4.26 and master code. > > Ahhm... were can I get the master code, just download via git? yes. p.

1 0

Re: (ITS#6770) Proxy authorization fails with SASL-GSSAPI
by masarati＠aero.polimi.it 19 Jul '11

19 Jul '11

> Same problem here: > > If I use the cn=config style, proxy authorization works directly after > configuring it. > If I reboot the slave server the authorization fails to work and the > bindmethod switches from SASL/GSSAPI to SIMPLE. > > If I delete the configuration directory /etc/ldap/slapd.d and use a > simple /etc/ldap/slapd.conf and make the same configuration the old way > everything keeps working after reboots. > > So I think there is a Problem while loading the cn=config configuration. Something in this area should have been fixed in master code; some fixes may have been released in 2.4.26. Can you indicate what version you're using? In case you're using the latest, can you test with master code? p.

1 0

(ITS#6997) Segmentation fault when using slapo-rwm and slapo-chain
by mgaupp＠googlemail.com 19 Jul '11

19 Jul '11

Full_Name: Manuel Gaupp Version: 2.4.26 OS: Linux 2.6.18 (CentOS 5.6 x86_64) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.208.112.253) Under the following circumstances OpenLDAP crashes when a chained search does not return with result code 0: - "rwm" overlay used in a global context - "chain" overlay used in a database specifix context (gdb) bt #0 0x0000000400040004 in ?? () #1 0x000000000042e5c7 in slap_cleanup_play (op=0x197834b0, rs=0x42a07ca0) at result.c:539 #2 0x000000000042ef9b in send_ldap_response (op=0x197834b0, rs=0x42a07ca0) at result.c:724 #3 0x000000000042fcf9 in slap_send_ldap_result (op=0x197834b0, rs=0x42a07ca0) at result.c:851 #4 0x00000000004d982a in ldap_chain_response (op=0x197834b0, rs=0x42a07ca0) at chain.c:1165 #5 0x00000000004820ca in over_back_response (op=0x197834b0, rs=0x42a07ca0) at backover.c:237 #6 0x000000000042e535 in slap_response_play (op=0x197834b0, rs=0x42a07ca0) at result.c:505 #7 0x000000000042ef78 in send_ldap_response (op=0x197834b0, rs=0x42a07ca0) at result.c:579 #8 0x000000000042fcf9 in slap_send_ldap_result (op=0x197834b0, rs=0x42a07ca0) at result.c:851 #9 0x00000000004928f0 in bdb_search (op=0x197834b0, rs=0x42a07ca0) at search.c:499 #10 0x0000000000482352 in overlay_op_walk (op=0x197834b0, rs=0x42a07ca0, which=op_search, oi=0x196f3bb0, on=0x0) at backover.c:671 #11 0x00000000004828b7 in over_op_func (op=0x197834b0, rs=0x42a07ca0, which=op_search) at backover.c:723 #12 0x0000000000421cf9 in fe_op_search (op=0x197834b0, rs=0x42a07ca0) at search.c:402 #13 0x0000000000482352 in overlay_op_walk (op=0x197834b0, rs=0x42a07ca0, which=op_search, oi=0x1970fd30, on=0x0) at backover.c:671 #14 0x00000000004828b7 in over_op_func (op=0x197834b0, rs=0x42a07ca0, which=op_search) at backover.c:723 #15 0x0000000000422505 in do_search (op=0x197834b0, rs=0x42a07ca0) at search.c:247 #16 0x000000000041fa95 in connection_operation (ctx=0x42a07d70, arg_v=<value optimized out>) at connection.c:1138 #17 0x0000000000503d5c in ldap_int_thread_pool_wrapper (xpool=0x196beee0) at tpool.c:685 #18 0x000000316820673d in start_thread () from /lib64/libpthread.so.0 #19 0x0000003167ad44bd in clone () from /lib64/libc.so.6 OpenLDAP 2.4.26 was built using: ./configure --enable-rewrite --enable-ldap --enable-rwm --enable-bdb This issue can be reproduced using the following configuration (referred as 'slapd.conf.proxy') ------------------------------------------ overlay rwm # There might be some rewrite directives database bdb suffix "o=example" rootdn "cn=admin,o=example" rootpw secret directory /root/db.proxy overlay chain chain-return-error true chain-uri "ldap://localhost:38977" ------------------------------------------ The process is started on port 389 with plain ldap /usr/local/libexec/slapd -f slapd.conf.proxy -h "ldap://localhost:389" Create the following entry in this server: dn: cn=ldap,o=example objectclass: extensibleObject objectclass: referral ref: ldap://localhost:38977/cn=real,o=example To reproduce the error there has to be another server where the referral points to. It contains the following minimal configuration: (referred as 'slapd.conf.server') ------------------------------------------ database bdb suffix "cn=real,o=example" rootdn "cn=admin,cn=real,o=example" rootpw secret directory /root/db.server ------------------------------------------ The process is started on port 38977 with plain ldap /usr/local/libexec/slapd -f slapd.conf.server -h "ldap://localhost:38977" Using the following ldapsearch, slapd crashes: ldapsearch -h localhost -p 389 -D "cn=admin,o=example" -w secret \ -x -b "ou=abc,cn=ldap,o=example" 1.1 Whereas the following ldapsearch returns with "success" ldapsearch -h localhost -p 389 -D "cn=admin,o=example" -w secret \ -x -b "cn=ldap,o=example" 1.1 Deactivating the "rwm" overlay prevents from this issue. So I think the problem can be found somewhere in the rwm sources. -- Manuel

1 0

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

18 Jul '11

> ctcard(a)hotmail.com wrote: > > 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. > > Now fixed in git master. > Thanks, I've tried that fix and it works (and is simpler than my suggestion). Chris

1 0

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

18 Jul '11

> > > >>>>>> 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. > >> > >> Not true; since cmp is initialized to -1, it will return -1 when the function > >> is entered with root == NULL. There is no bug in this part.It depends how you read the comment. > > I wrote the code and the comment; it does what I intended it to do. There is > no "depends" about it. The comment is ambiguous, but in any case the code as it stands doesn't work with the way tavl_find3() is called in sssvlv.c.For example:if cmp > 0 when the while loop terminates, the sssvlv code treats that as if the search failed, whereas the search oughtto return the closest node > search node. My suggested patch does work with the way tavl_find3() is called in sssvlv.c, but I'd be happy with adding a new function, tavl_find4() say, to implement this functionality. In that case I'd suggest it look like this: Avlnode *tavl_find4( Avlnode *root, const void *data, AVL_CMP fcmp){ int cmp, dir; Avlnode *prev = root; Avlnode *prev_gt = 0; while ( root != 0 && (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { prev = root; dir = cmp > 0; prev_gt = (dir ? prev_gt : root); root = avl_child( root, dir ); } return (root ? root : (prev_gt ? prev_gt : prev));} tavl_find4() always returns the first node >= the search node, unless the search node is > all the nodes in the tree, in which case the last node is returned (or null if the tree is empty). Then replace cur_node = tavl_find3( so->so_tree, sn, node_cmp, &j ); /* didn't find >= match */ if ( j > 0 ) cur_node = NULL;by cur_node = tavl_find4( so->so_tree, sn, node_cmp); in sssvlv.c. Chris

1 0

Re: (ITS#6985) sssvlv / greaterThanOrEqual problem
by hyc＠symas.com 18 Jul '11

18 Jul '11

ctcard(a)hotmail.com wrote: > 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. Now fixed in git 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#6985) sssvlv / greaterThanOrEqual problem
by hyc＠symas.com 18 Jul '11

18 Jul '11

Chris Card wrote: > >>>>>> 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. >> >> Not true; since cmp is initialized to -1, it will return -1 when the function >> is entered with root == NULL. There is no bug in this part.It depends how you read the comment. I wrote the code and the comment; it does what I intended it to do. There is no "depends" about it. -- -- 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#6985) sssvlv / greaterThanOrEqual problem
by ctcard＠hotmail.com 18 Jul '11

18 Jul '11

> >>>> 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. > > Not true; since cmp is initialized to -1, it will return -1 when the function > is entered with root == NULL. There is no bug in this part.It depends how you read the comment. If the function is *entered* with root == NULL, then I agree that -1 is returned, but if the while loop exits with root == NULL then the last comparison result is returned, which causes problems to the call in sssvlv.c.> > >>> 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). > > This fix is also not correct. Possibly tavl_find3() has been misused in the > sssvlv code, but this function works as designed. >Possibly. But with the patch as suggested, the sssvlv code works correctly and gets the correct node.If you think these changes might break other uses of tavl_find3() (of which there didn't seem to be many), perhapstavl_find4() could be added. > >>> 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. > > OK, looks like you have a good patch for this. > > >> 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. > >> > > > > I've uploaded a patch to ftp.openldap.org, incoming/Chris-Card-110708.ITS-6985-fix.patch

1 0

Re: (ITS#6985) sssvlv / greaterThanOrEqual problem
by hyc＠symas.com 18 Jul '11

18 Jul '11

ctcard(a)hotmail.com wrote: >>>> 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. Not true; since cmp is initialized to -1, it will return -1 when the function is entered with root == NULL. There is no bug in this part. >>> 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). This fix is also not correct. Possibly tavl_find3() has been misused in the sssvlv code, but this function works as designed. >>> 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. OK, looks like you have a good patch for this. >> 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. >> > > I've uploaded a patch to ftp.openldap.org, incoming/Chris-Card-110708.ITS-6985-fix.patch > > Chris -- -- 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#6985) sssvlv / greaterThanOrEqual problem
by ctcard＠hotmail.com 16 Jul '11

16 Jul '11

[And this time in plain text ...][I thought I'd send this to the ITS list, but I only sent it to myself :-( ] > > > > > > > > > > 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. > I've uploaded a patch to ftp.openldap.org, incoming/Chris-Card-110708.ITS-6985-fix.patch Chris

1 0

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

16 Jul '11

--_3d71bf45-bf8f-4026-9c30-d39291bf9f56_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [I thought I'd send this to the ITS list=2C but I only sent it to myself :-= ( ] > > > > > > > > > > I am running slapd built from HEAD on June 30th 2011=2C with back= -sql > > > > > > > > Can you confirm this issue with another backend=2C e.g. back-bdb? B= ugs > > > > specific to back-sql or to interaction with it could receive only m= arginal > > > > attention. > > > > > > > > p. > > > > > > > > > > I've imported my data into a server with a bdb backend=2C and I see t= he same problem. > > > > > > Looking at the code in sssvlv.c=2C it uses tavl_find3() to search the= values=2C 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=2C const void *data=2C AVL_CMP fcmp=2C int = *ret ) > > > { > > > int cmp =3D -1=2C dir=3B > > > Avlnode *prev =3D root=3B > > > > > > while ( root !=3D 0 && (cmp =3D (*fcmp)( data=2C root->avl_data )) != =3D 0 ) { > > > prev =3D root=3B > > > dir =3D cmp > 0=3B > > > root =3D avl_child( root=2C dir )=3B > > > } > > > *ret =3D cmp=3B > > > return root ? root : prev=3B > > > } > > > > > > 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=2C there's a comment before tavl_find3() saying > > /* > > * tavl_find2 - returns Avlnode instead of data pointer. > > * tavl_find3 - as above=2C but returns Avlnode even if no match is foun= d. > > * also set *ret =3D last comparison result=2C or -1 if root =3D=3D NULL= . > > */ > > > > but the "or -1 if root =3D=3D NULL" is not done. > > > > Secondly=2C if no exact match is found=2C prev is returned which may po= int to a node which is less than the search > > node=2C depending on what the tree looks like=2C but we really want a p= ointer to the last node which was greater than > > the search node to be returned. > > > > Once these fixes are done=2C 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=2C at lines 535-544: > > > > if ( i > 0 ) { > > tmp_node =3D tavl_end(so->so_tree=2C TAVL_DIR_RIGHT)=3B > > dir =3D TAVL_DIR_LEFT=3B > > } else { > > tmp_node =3D tavl_end(so->so_tree=2C TAVL_DIR_LEFT)=3B > > dir =3D TAVL_DIR_RIGHT=3B > > } > > for (i=3D0=3B tmp_node !=3D cur_node=3B > > tmp_node =3D tavl_next( tmp_node=2C dir )=2C i++)=3B > > so->so_vlv_target =3D i=3B > > This code is ok if the cur_node is in the left hand side of the tree=2C= but if it is in the rhs of the tree so_vlv_target is set > > to an offset from the end of the list=2C 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 resp= onse has range 0..maxInt. > > However=2C my interpretation of the spec is that offset and targetPositio= n represent the same thing=2C i.e. the position of the target entry in the = list=2C with the first entry having offset/targetPosition =3D 1. > > If that interpretation is correct=2C the assignment of so_vlv_target in t= he code above is off by one=2C since i will be zero if cur_node is at the b= eginning of the list. > I've uploaded a patch to ftp.openldap.org=2C incoming/Chris-Card-110708.ITS= -6985-fix.patch Chris = --_3d71bf45-bf8f-4026-9c30-d39291bf9f56_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style></style> </head> <body class=3D'hmmessage'><div dir=3D'ltr'> [I thought I'd send this to the ITS list=2C but I only sent it to myself :-= ( ] <div> &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt= =3B &gt=3B &gt=3B I am running slapd built from HEAD on June 30th 2011=2C w= ith back-sql &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B = Can you confirm this issue with another backend=2C e.g. back-bdb? Bugs &= gt=3B &gt=3B &gt=3B &gt=3B specific to back-sql or to interaction with it c= ould receive only marginal &gt=3B &gt=3B &gt=3B &gt=3B attention. &gt= =3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B p. &gt=3B &gt=3B= &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B I've importe= d my data into a server with a bdb backend=2C and I see the same problem.<b= r>&gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B Looking at the code in sssvl= v.c=2C it uses tavl_find3() to search the values=2C but the &gt=3B &gt= =3B &gt=3B code in tavl_find3() looks to me that it only works properly wit= h an exact match &gt=3B &gt=3B &gt=3B type of matching rule: &gt=3B &= gt=3B &gt=3B &gt=3B &gt=3B &gt=3B Avlnode * &gt=3B &gt=3B &gt=3B tavl= _find3( Avlnode *root=2C const void *data=2C AVL_CMP fcmp=2C int *ret ) = &gt=3B &gt=3B &gt=3B { &gt=3B &gt=3B &gt=3B int cmp =3D -1=2C dir=3B = &gt=3B &gt=3B &gt=3B Avlnode *prev =3D root=3B &gt=3B &gt=3B &gt=3B &= gt=3B &gt=3B &gt=3B while ( root !=3D 0 &amp=3B&amp=3B (cmp =3D (*fcmp)( da= ta=2C root-&gt=3Bavl_data )) !=3D 0 ) { &gt=3B &gt=3B &gt=3B prev =3D ro= ot=3B &gt=3B &gt=3B &gt=3B dir =3D cmp &gt=3B 0=3B &gt=3B &gt=3B &gt= =3B root =3D avl_child( root=2C dir )=3B &gt=3B &gt=3B &gt=3B } &gt= =3B &gt=3B &gt=3B *ret =3D cmp=3B &gt=3B &gt=3B &gt=3B return root ? roo= t : prev=3B &gt=3B &gt=3B &gt=3B } &gt=3B &gt=3B &gt=3B &gt=3B &gt= =3B &gt=3B since the while loop terminates when the fcmp function returns 0= (i.e. exact match). &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt= =3B I think I've worked out where the problem is. &gt=3B &gt=3B Firstly= =2C there's a comment before tavl_find3() saying &gt=3B &gt=3B /* &gt= =3B &gt=3B * tavl_find2 - returns Avlnode instead of data pointer. &gt= =3B &gt=3B * tavl_find3 - as above=2C but returns Avlnode even if no match = is found. &gt=3B &gt=3B * also set *ret =3D last comparison result=2C or= -1 if root =3D=3D NULL. &gt=3B &gt=3B */ &gt=3B &gt=3B &gt=3B &gt= =3B but the "or -1 if root =3D=3D NULL" is not done. &gt=3B &gt=3B &g= t=3B &gt=3B Secondly=2C if no exact match is found=2C prev is returned whic= h may point to a node which is less than the search &gt=3B &gt=3B node= =2C depending on what the tree looks like=2C but we really want a pointer t= o the last node which was greater than &gt=3B &gt=3B the search node to = be returned. &gt=3B &gt=3B &gt=3B &gt=3B Once these fixes are done=2C= the correct node is returned by tavl_find3 to the call in send_list() in s= ssvlv.c (line 523). &gt=3B &gt=3B &gt=3B &gt=3B There is another bug = in send_list() in sssvlv.c=2C at lines 535-544: &gt=3B &gt=3B &gt=3B = &gt=3B if ( i &gt=3B 0 ) { &gt=3B &gt=3B tmp_node =3D tavl_end(so-&gt=3B= so_tree=2C TAVL_DIR_RIGHT)=3B &gt=3B &gt=3B dir =3D TAVL_DIR_LEFT=3B = &gt=3B &gt=3B } else { &gt=3B &gt=3B tmp_node =3D tavl_end(so-&gt=3Bso_t= ree=2C TAVL_DIR_LEFT)=3B &gt=3B &gt=3B dir =3D TAVL_DIR_RIGHT=3B &gt= =3B &gt=3B } &gt=3B &gt=3B for (i=3D0=3B tmp_node !=3D cur_node=3B &g= t=3B &gt=3B tmp_node =3D tavl_next( tmp_node=2C dir )=2C i++)=3B &gt=3B = &gt=3B so-&gt=3Bso_vlv_target =3D i=3B &gt=3B &gt=3B This code is ok if = the cur_node is in the left hand side of the tree=2C but if it is in the rh= s of the tree so_vlv_target is set &gt=3B &gt=3B to an offset from the e= nd of the list=2C rather than the beginning. &gt=3B &gt=3B &gt=3B = &gt=3B One more issue: the most recent draft spec for vlv (http://tools.iet= f.org/html/draft-ietf-ldapext-ldapv3-vlv-09) states that the offset field i= n the vlv request has range 1..maxInt whereas the targetPosition in the vlv= response has range 0..maxInt. &gt=3B &gt=3B However=2C my interpreta= tion of the spec is that offset and targetPosition represent the same thing= =2C i.e. the position of the target entry in the list=2C with the first ent= ry having offset/targetPosition =3D 1. &gt=3B &gt=3B If that interpre= tation is correct=2C the assignment of so_vlv_target in the code above is o= ff by one=2C since i will be zero if cur_node is at the beginning of the li= st. &gt=3B I've uploaded a patch to ftp.openldap.org=2C incoming/= Chris-Card-110708.ITS-6985-fix.patch </div><div>Chris </div> = </div></body> </html>= --_3d71bf45-bf8f-4026-9c30-d39291bf9f56_--

1 0

(ITS#6996) Bad cn=config quotes in Admin Guide
by h.b.furuseth＠usit.uio.no 15 Jul '11

15 Jul '11

Full_Name: Hallvard B Furuseth Version: master, 2.4.26 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard http://www.openldap.org/doc/admin24/slapdconf2.html contains a number of examples with quoted DNs in cn=config attributes: olcSuffix, olcRootDN. This is wrong, likely a cut&paste from slapd.conf.

1 0

Re: (ITS#6770) Proxy authorization fails with SASL-GSSAPI
by c.waeschenfelder＠websale.de 15 Jul '11

15 Jul '11

Same problem here: If I use the cn=config style, proxy authorization works directly after configuring it. If I reboot the slave server the authorization fails to work and the bindmethod switches from SASL/GSSAPI to SIMPLE. If I delete the configuration directory /etc/ldap/slapd.d and use a simple /etc/ldap/slapd.conf and make the same configuration the old way everything keeps working after reboots. So I think there is a Problem while loading the cn=config configuration.

1 0

(ITS#6995) Request for Contribution of Identity Access Management Software to OpenLDAP Project
by shawn.mckinney＠jtstools.com 14 Jul '11

14 Jul '11

Full_Name: Shawn McKinney Version: All OS: All URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (99.34.198.251) Hello, We have created a new Identity and Access Management SDK, called Fortress, that uses Java and OpenLDAP to provide authentication, RBAC, ARBAC, password policies, auditing and more. It has taken us 2.5 years of steady work to get it ready for this 1.0 release. This SDK has approximately 50K lines of Java code of which approximately 25K are dedicated to testing using JUnit automated tests to ensure it works correctly. There are in excess of 100 public APIs available for use. There is also a Java EE container plug-in that provides authentication and authorization services to Websphere, Tomcat and JBoss app servers in a declarative fashion. This product has not been published and we would like to release it as one of the products under OpenLDAP family of products. The product will be released under New BSD open source license (license information is contained in the source archives on ftp server). I have uploaded seven packages to our FTP server that contain the source, documentation and other items for you to look at. host: jtstools.com user: jtsguest1 pw: OpenLd@p1 The packages are as follows: Fortress Core SDK 1. source - fortressSrc-1.0.0-rc1.zip - 352K bytes 2. source - fortressTestSrc-1.0.0-rc1.zip - 159K bytes 3. tutorial/doc - fortressSamples-1.0.0-rc1.zip - 766K bytes 4. javadoc - fortressDoc-1.0.0-rc1.zip - 1.4M bytes 5. ldap (folder) - Fortress schema and OpenLDAP slapd.conf Fortress Realm (Java EE Container plug-ins) 6. source - fortressRealmSrc-1.0.0-rc1.zip - 45K bytes 7. javadoc - fortressRealmDoc-1.0.0-rc1.zip - 76K bytes Package 4 contains complete javadoc for the APIs. In package 4, this link, ./fortressDoc-1.0.0-rc1/index.html, contains the overall summary of the SDK. this link, ./oamCore/trunk/dist/docs/api/index.html, contains package descriptions along with detailed documentation describing the contents of the SDK. What we are requesting from the OpenLDAP foundation: 1. Source code repository to host the SDK and Realm packages. 2. Bug tracking. 3. Developer and User forums. 4. Wiki (this is a nice to have) Our goal is to run the open source project with your organization and cultivate a healthy developer and user community. We have high hopes for this product (and OpenLDAP) and consider the 2 products together as an open source alternative for IAM products that will compete with the commercial vendor offerings. Once 1.0 is released, we will begin working on 2.0 which will include UI's to control Fortress and OpenLDAP along with a policy server to wrap the Fortress Java APIs with HTTP/REST Web APIs to make it available to all platforms. Thanks in advance for your consideration. Shawn McKinney JoshuaTree Software shawn.mckinney(a)jtstools.com

1 0

(ITS#6994) Syncrepl with MozNSS inherits TLS context form main configuration breaking some syncrepl setups
by thibault.lemeur＠supelec.fr 11 Jul '11

11 Jul '11

Full_Name: Thibault Le Meur Version: 2.4.23-15 OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (160.228.28.55) Previously on my FC13 installation (openldap-servers-2.4.21-11) the main slapd process used an X509 "server" while my syncrepl processes were using the /etc/openldap/ldap.conf client configuration file in order to connect to my LDAPs Syncrepl providers. In my new RHEL6 setup (openldap-servers-2.4.23-15.el6.x86_64) is linked to MozNSS and Syncrepl can't connect to my LDAPs providers anymore because it complains about the TLS context not beeing intitialized correctly (the server's certificate isn't accepted as a client certificate). Here is the lightly obfuscated log: ---------------------------------------------------------- ldap_connect_to_host: Trying 10.10.10.10:636 ldap_pvt_connect: fd: 21 tm: -1 async: 0 TLS: loaded CA certificate file /etc/ssl/cacerts/cacert.pem. TLS: certificate [CN=myldap.mydom.fr,OU=myou,O=myorg,L=myloc,ST=myst,C=FR] is not valid - error -8101:Unknown code ___f 91. TLS: error: unable to set up client certificate authentication for certificate named PEM Token #0:myldap.mydom.fr-cert.pem - 0 TLS: error: unable to set up client certificate authentication using PEM Token #0:myldap.mydom.fr-cert.pem - 0 TLS: error: could not initialize moznss security context - error -8101:Unknown code ___f 91 TLS: can't create ssl handle. slap_client_connect: URI=ldaps://otherldap.mydom.fr DN="cn=myreplicationAccount,dc=mydom,dc=fr" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=125 rc -1 retrying (9 retries left) ---------------------------------------------------------- Here is my syncrepl setup: --------------------------------------------------------- syncrepl rid=125 provider=ldaps://otherldap.mydom.fr type=refreshOnly interval=00:00:03:00 retry="60 10 300 +" searchbase="dc=subranch,dc=mydom,dc=fr" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=simple binddn="cn=myreplicationAccount,dc=mydom,dc=fr" credentials="MyVerySecretPassword" --------------------------------------------------------- My setup related to TLS: --------------------------------------------------------- TLSCipherSuite HIGH TLSCertificateFile /etc/ssl/certs/myldap.mydom.fr-cert.pem TLSCertificateKeyFile /etc/ssl/keys/myldap.mydom.fr-key.pem TLSCACertificateFile /etc/ssl/cacerts/cacert.pem --------------------------------------------------------- And my /etc/openldap/ldap.conf: --------------------------------------------------------- TLS_CACERT /etc/ssl/cacerts/cacert.pem --------------------------------------------------------- Here is the obfuscated certificate: --------------------------------------------------------- Certificate: Data: Version: 3 (0x2) Serial Number: 221 (0xdd) Signature Algorithm: sha1WithRSAEncryption Issuer: C=FR, ST=myst, L=myloc, O=myorg, OU=myou, CN=myCA/emailAddress=myemail(a)mydom.fr Validity Not Before: Oct 2 16:42:15 2007 GMT Not After : Dec 14 16:42:15 2012 GMT Subject: C=FR, ST=myst, L=myloc, O=myorg, OU=myou, CN=myldap.mydom.fr Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: ... Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server Netscape Comment: TinyCA Generated Certificate X509v3 Subject Key Identifier: ... X509v3 Authority Key Identifier: keyid:... DirName:/C=FR/ST=myst/L=myloc/O=myorg/OU=myou/CN=myCA/emailAddress=thibault.lemeur@supelec.fr serial:00 X509v3 Issuer Alternative Name: <EMPTY> Netscape SSL Server Name: myldap.mydom.fr X509v3 Subject Alternative Name: DNS:ldap, DNS:ldapalias1, DNS:ldapalias2, DNS:ldapalias1.mydom.fr, DNS:ldapalias2.mydom.fr, DNS:ldap.mydom.fr, DNS:myldap, DNS:myldap.mydom.fr X509v3 Extended Key Usage: critical TLS Web Server Authentication, Code Signing Signature Algorithm: sha1WithRSAEncryption ... ---------------------------------------------------------

1 0

(ITS#6993) Backend Connection problem
by yann.carre＠alcatel-lucent.com 11 Jul '11

11 Jul '11

Full_Name: Yann Carre Version: 2.4.26 OS: red hat 5 (64 bits) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.208.49.20) I work on a specific Backend I have provided in my back end a function to the bi_connection_init pointer. This function adds a context needed in the operation backend function (search, ...) When several connections start up, my LDAP server crashes. The crash arrives because the context is not created before the call to do_searh. The connection is provided to the application Backend before my Back end connection_init. I have checked it with the debugger and see that the thread with initialize the connection is suspend before the backend connection_init. In another thread, the search function is executed without any context attached to the connection. This problem seems to be bring because the connection mutex is freed before the calling of the Back end connection_init in the function connection_init (connection.c). I have moved this mutex after the backend connection_init and it seems to work. Would you confirm this analysis and take the correction in account? Thanks Regards Yann

1 0

Syncrepl using can't start ssl session because of refused certificate
by Thibault Le Meur 10 Jul '11

10 Jul '11

Hello, I'm trying to upgrade an openLdap server from FC9 (openldap-servers-2.4.10-2.fc9.i386) to Redhat Enterprise 6 (openldap-servers-2.4.23-15.el6.x86_64). In this new setup, my local database works but the Syncrepl replication process fails to establish the "ldaps://" session to my syncrepl-providers because the TLS layer fails. Indeed, the TLS layer complains that my _server's certificate_ isn't a valid _client certificate_ (with error 8101 - SEC_ERROR_INADEQUATE_CERT_TYPE): but I don't want client-side authentication! In the past syncrepl didn't try to use the server certificate as a client certificate, and I haven't seen any reference to this in the documentation. I first thought it could have been related to ITS#6791 but I don't think so anymore because it only affects Syncrepl. Don' hesitate to redirect me to the openldap-users list if I've missed something simple. Thanks in advance, Thibault Here is an excerpt of slapd in debug-mode: ---------------------------------------------------------- ldap_connect_to_host: Trying 10.10.10.10:636 ldap_pvt_connect: fd: 21 tm: -1 async: 0 TLS: loaded CA certificate file /etc/ssl/cacerts/cacert.pem. TLS: certificate [CN=myldap.mydom.fr,OU=myou,O=myorg,L=myloc,ST=myst,C=FR] is not valid - error -8101:Unknown code ___f 91. TLS: error: unable to set up client certificate authentication for certificate named PEM Token #0:myldap.mydom.fr-cert.pem - 0 TLS: error: unable to set up client certificate authentication using PEM Token #0:myldap.mydom.fr-cert.pem - 0 TLS: error: could not initialize moznss security context - error -8101:Unknown code ___f 91 TLS: can't create ssl handle. slap_client_connect: URI=ldaps://otherldap.mydom.fr DN="cn=myreplicationAccount,dc=mydom,dc=fr" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=125 rc -1 retrying (9 retries left) ---------------------------------------------------------- Here is my syncrepl setup: --------------------------------------------------------- syncrepl rid=125 provider=ldaps://otherldap.mydom.fr type=refreshOnly interval=00:00:03:00 retry="60 10 300 +" searchbase="dc=subranch,dc=mydom,dc=fr" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=simple binddn="cn=myreplicationAccount,dc=mydom,dc=fr" credentials="MyVerySecretPassword" --------------------------------------------------------- And eventually my /etc/openldap/ldap.conf: --------------------------------------------------------- TLS_CACERT /etc/ssl/cacerts/cacert.pem ---------------------------------------------------------

2 1

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

(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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs