Full_Name: Michael Str�der Version: 2.4.25 OS: URL: Submission from: (NULL) (84.163.53.138) The very same client code was successfully tested with OpenDJ 2.4.1 but does not work with OpenLDAP 2.4.25. See analysis by pyasn1 developer on the pyasn1 mailing list: --------------------------------- snip --------------------------------- It looks to me that your BER data does not fully match ASN.1 specification for the SearchResultEntry object. According to RFC2251, the grammar is as follows: SearchResultEntry ::= [APPLICATION 4] SEQUENCE { objectName LDAPDN, attributes PartialAttributeList } ... Notice the [implicitly] tagged outer SEQUENCE. In your BER data, that additional tag seems to be missing and default tag for SEQUENCE type is used instead. If you modify the original pyasn1 grammar for SearchResultEntry object to match your BER data (but not the standard!), pyasn1 decoder succeeds. >>> from pyasn1_modules.rfc2251 import SearchResultEntry >>> from pyasn1.type.univ import Sequence >>> from pyasn1.codec.ber import decoder >>> ber = '0c\x043cn=Samba Unix UID Pool,ou=Testing,dc=stroeder,dc=de0,0\x14\x04\tuidNumber1\x07\x04\x05100050\x14\x04\tgidNumber1\x07\x04\x0510005' >>> SearchResultEntry.tagSet TagSet(Tag(tagClass=64, tagFormat=32, tagId=4)) # the following statement will invalidate SearchResultEntry grammar! >>> SearchResultEntry.tagSet = univ.Sequence.tagSet >>> SearchResultEntry.tagSet TagSet(Tag(tagClass=0, tagFormat=32, tagId=16)) >>> searchResultEntry, _ = decoder.decode(ber,asn1Spec=SearchResultEntry()) >>> print searchResultEntry.prettyPrint() SearchResultEntry: objectName='cn=Samba Unix UID Pool,ou=Testing,dc=stroeder,dc=de' attributes=PartialAttributeList: Sequence: type='uidNumber' vals=SetOf: '10005' Sequence: type='gidNumber' vals=SetOf: '10005' >>> Therefore my impression is that OpenLDAP yields incorrect BER data for SearchResultEntry object. What do you think? Cheers, Ilya > I'd like to decode a LDAPv3 control value returned by OpenLDAP 2.4.25 when > Pre-Read-Control was sent along with a LDAP modify request. But decoding it > does not work. > > Short example: > >>>> from pyasn1_modules.rfc2251 import SearchResultEntry >>>> from pyasn1.codec.ber import decoder >>>> ber = '0c\x043cn=Samba Unix UID > Pool,ou=Testing,dc=stroeder,dc=de0,0\x14\x04\tuidNumber1\x07\x04\x05100050\x14\x04\tgidNumber1\x07\x04\x0510005' >>>> decoder.decode(ber,asn1Spec=SearchResultEntry()) > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File > "/usr/local/lib/python2.6/site-packages/pyasn1-0.0.13a-py2.6.egg/pyasn1/codec/ber/decoder.py", > line 663, in __call__ > '%s not in asn1Spec: %s' % (tagSet, repr(asn1Spec)) > pyasn1.error.PyAsn1Error: TagSet(Tag(tagClass=0, tagFormat=32, tagId=16)) not > in asn1Spec: SearchResultEntry() >>>>
Any chance this will be fixed? It would be very handy for sync processes to get back the entryUUID generated by OpenLDAP of a new entry in an AddResponse without having to read the new entry once more.
On 06/07/2011 12:58 PM, michael@stroeder.com wrote: > Any chance this will be fixed? > > It would be very handy for sync processes to get back the entryUUID generated > by OpenLDAP of a new entry in an AddResponse without having to read the new > entry once more. If I get things right, what seems to be missing is a LDAP_RES_SEARCH_ENTRY tag right before encoding the search entry, something like diff --git a/servers/slapd/result.c b/servers/slapd/result.c index 0803f7f..3a21fb5 100644 --- a/servers/slapd/result.c +++ b/servers/slapd/result.c @@ -1042,7 +1042,8 @@ slap_send_search_entry( Operation *op, SlapReply *rs ) #endif if ( op->o_res_ber ) { /* read back control */ - rc = ber_printf( ber, "{O{" /*}}*/, &rs->sr_entry->e_name ); + rc = ber_printf( ber, "t{O{" /*}}*/, + LDAP_RES_SEARCH_ENTRY, &rs->sr_entry->e_name ); } else { rc = ber_printf( ber, "{it{O{" /*}}}*/, op->o_msgid, LDAP_RES_SEARCH_ENTRY, &rs->sr_entry->e_name ); but I'd like to have some feedback. p.
Pierangelo Masarati wrote: > On 06/07/2011 12:58 PM, michael@stroeder.com wrote: >> Any chance this will be fixed? >> >> It would be very handy for sync processes to get back the entryUUID generated >> by OpenLDAP of a new entry in an AddResponse without having to read the new >> entry once more. > > If I get things right, what seems to be missing is a LDAP_RES_SEARCH_ENTRY tag > right before encoding the search entry, something like > [..patch snipped..] Thanks! With your patch the response control is now decoded correctly and it behaves as expected for all operations except Modify DN Operation: It returns empty value lists for all attributes no matter how deleteoldrdn is set. The DN returned is correct. Here's the trace log from the Python script: ----------------------------- snip ----------------------------- *** ldap://localhost:2071/ - SimpleLDAPObject.rename (('uid=ablume,ou=Users,ou=schulung,dc=stroeder,dc=local', 'uid=ablume2', None, 0, [('1.3.6.1.1.13.2', True, '0\x06\x04\x01*\x04\x01+')], None),{}) => result: 5 *** ldap://localhost:2071/ - SimpleLDAPObject.result4 ((5, 1, -1, 0, 0, 0),{}) => result: (109, [], 5, [('1.3.6.1.1.13.2', 0, 'd\x82\x01N\x045uid=ablume2,ou=Users,ou=schulung,dc=stroeder,dc=local0\x82\x01\x130\x07\x04\x03uid1\x000\x0f\x04\x0bobjectClass1\x000\r\x04\tuidNumber1\x000\r\x04\tgidNumber1\x000\x11\x04\rhomeDirectory1\x000\x06\x04\x02cn1\x000\x19\x04\x15structuralObjectClass1\x000\r\x04\tentryUUID1\x000\x10\x04\x0ccreatorsName1\x000\x13\x04\x0fcreateTimestamp1\x000\x0c\x04\x08entryCSN1\x000\x11\x04\rmodifiersName1\x000\x13\x04\x0fmodifyTimestamp1\x000\x0b\x04\x07entryDN1\x000\x15\x04\x11subschemaSubentry1\x000\x13\x04\x0fhasSubordinates1\x00')]) resp_ctrls[0].dn: uid=ablume2,ou=Users,ou=schulung,dc=stroeder,dc=local resp_ctrls[0].entry: {'cn': [], 'createTimestamp': [], 'creatorsName': [], 'entryCSN': [], 'entryDN': [], 'entryUUID': [], 'gidNumber': [], 'hasSubordinates': [], 'homeDirectory': [], 'modifiersName': [], 'modifyTimestamp': [], 'objectClass': [], 'structuralObjectClass': [], 'subschemaSubentry': [], 'uid': [], 'uidNumber': []} ----------------------------- snip ----------------------------- Ciao, Michael.
> Pierangelo Masarati wrote: >> On 06/07/2011 12:58 PM, michael@stroeder.com wrote: >>> Any chance this will be fixed? >>> >>> It would be very handy for sync processes to get back the entryUUID >>> generated >>> by OpenLDAP of a new entry in an AddResponse without having to read the >>> new >>> entry once more. >> >> If I get things right, what seems to be missing is a >> LDAP_RES_SEARCH_ENTRY tag >> right before encoding the search entry, something like > > [..patch snipped..] > > Thanks! > > With your patch the response control is now decoded correctly and it > behaves > as expected for all operations except Modify DN Operation: > It returns empty value lists for all attributes no matter how deleteoldrdn > is > set. The DN returned is correct. > > Here's the trace log from the Python script: > > ----------------------------- snip ----------------------------- > *** ldap://localhost:2071/ - SimpleLDAPObject.rename > (('uid=ablume,ou=Users,ou=schulung,dc=stroeder,dc=local', 'uid=ablume2', > None, > 0, [('1.3.6.1.1.13.2', True, '0\x06\x04\x01*\x04\x01+')], None),{}) > => result: 5 > *** ldap://localhost:2071/ - SimpleLDAPObject.result4 ((5, 1, -1, 0, 0, > 0),{}) > => result: (109, [], 5, [('1.3.6.1.1.13.2', 0, > 'd\x82\x01N\x045uid=ablume2,ou=Users,ou=schulung,dc=stroeder,dc=local0\x82\x01\x130\x07\x04\x03uid1\x000\x0f\x04\x0bobjectClass1\x000\r\x04\tuidNumber1\x000\r\x04\tgidNumber1\x000\x11\x04\rhomeDirectory1\x000\x06\x04\x02cn1\x000\x19\x04\x15structuralObjectClass1\x000\r\x04\tentryUUID1\x000\x10\x04\x0ccreatorsName1\x000\x13\x04\x0fcreateTimestamp1\x000\x0c\x04\x08entryCSN1\x000\x11\x04\rmodifiersName1\x000\x13\x04\x0fmodifyTimestamp1\x000\x0b\x04\x07entryDN1\x000\x15\x04\x11subschemaSubentry1\x000\x13\x04\x0fhasSubordinates1\x00')]) > resp_ctrls[0].dn: uid=ablume2,ou=Users,ou=schulung,dc=stroeder,dc=local > resp_ctrls[0].entry: > {'cn': [], > 'createTimestamp': [], > 'creatorsName': [], > 'entryCSN': [], > 'entryDN': [], > 'entryUUID': [], > 'gidNumber': [], > 'hasSubordinates': [], > 'homeDirectory': [], > 'modifiersName': [], > 'modifyTimestamp': [], > 'objectClass': [], > 'structuralObjectClass': [], > 'subschemaSubentry': [], > 'uid': [], > 'uidNumber': []} > ----------------------------- snip ----------------------------- I suspect ors_attrsonly is set by mistake. Please try this: --- a/servers/slapd/result.c +++ b/servers/slapd/result.c @@ -1042,7 +1042,8 @@ slap_send_search_entry( Operation *op, SlapReply *rs ) #endif if ( op->o_res_ber ) { /* read back control */ - rc = ber_printf( ber, "{O{" /*}}*/, &rs->sr_entry->e_name ); + rc = ber_printf( ber, "t{O{" /*}}*/, + LDAP_RES_SEARCH_ENTRY, &rs->sr_entry->e_name ); } else { rc = ber_printf( ber, "{it{O{" /*}}}*/, op->o_msgid, LDAP_RES_SEARCH_ENTRY, &rs->sr_entry->e_name ); @@ -1744,6 +1745,7 @@ int slap_read_controls( myop.o_res_ber = ber; myop.o_callback = NULL; myop.ors_slimit = 1; + myop.ors_attrsonly = 0; rc = slap_send_search_entry( &myop, rs ); if( rc ) return rc;
masarati@aero.polimi.it wrote: >> With your patch the response control is now decoded correctly and it >> behaves >> as expected for all operations except Modify DN Operation: >> It returns empty value lists for all attributes no matter how deleteoldrdn >> is >> set. The DN returned is correct. > > I suspect ors_attrsonly is set by mistake. Please try this: > > + myop.ors_attrsonly = 0; With your last patch everything works as expected now. Thanks a lot. Ciao, Michael.
> masarati@aero.polimi.it wrote: >>> With your patch the response control is now decoded correctly and it >>> behaves >>> as expected for all operations except Modify DN Operation: >>> It returns empty value lists for all attributes no matter how >>> deleteoldrdn >>> is >>> set. The DN returned is correct. >> >> I suspect ors_attrsonly is set by mistake. Please try this: >> >> + myop.ors_attrsonly = 0; > > With your last patch everything works as expected now. Thanks a lot. Great. I've committed it. Thanks, p.
changed notes changed state Open to Test moved from Incoming to Software Bugs
changed notes changed state Test to Release
changed notes changed state Release to Closed
fixed in HEAD Fixed in RE24