>> > Well, it would appear that openldap might be throwing error=20 a >> > little too liberally: > >> No, SLAMD is generating an invalid ASN.1 encoding of the entry here. >> Note that X.500 defines an "entry" to be a SET of attributes; >> mathematically, in sets, elements are unique - can only appear once. >> This is explicitly stated in X.501 "All attributes in an entry shall be >> of distinct attribute types." The ASN.1 definition for the Add operation >> (RFC2251) says: >> >> AddRequest ::= [APPLICATION 8] SEQUENCE { >> entry LDAPDN, >> attributes AttributeList } >> >> AttributeList ::= SEQUENCE OF SEQUENCE { >> type AttributeDescription, >> vals SET OF AttributeValue } >> >> The proper way to encode a single attribute with multiple values is to >> include the "type" once, followed by all of the multiple values. SLAMD >> is sending the type multiple times, with one value each time, which is >> clearly an invalid encoding. >> > >> >> Hi Matt, >> >> This is actually a bug with SLAMD, and not OpenLDAP. Symas has been >> aware of it for some time, and will be submitting a fix back to Neil. >> >> Regards, >> Quanah >> > > He actually sent me a fix about ten minutes ago. His fix is for 2.0 > branch of slamd, and I'm testing it on 1.8 (it's not working yet), but > let's see if we can get him involved in this thread and we can figure > it out. I'm cc-ing him, and pasting in initial replies. (he already > has my initial posts)I'm already following up to Neil, since I'm on the slamd-discuss list. And I already have a fix for the 1.8.2 release. ;)
Everyone, thanks. I have just completed two successful add and delete tests.
