Kevin Graham wrote: > I am having a very unusual error on FDS version 1.0.3. > > > When we use ldapsearch to search for certain attributes we are getting > results back scrambled. > > Upon further investigation we found that the 'scrambled' entries were > the intended entries just base64 encoded. Normally we'd expect the > results back in ascii of course. > > The strange thing is that no matter how many times, and with any client > application, trying to fix the attribute results in no change. > > Deleting the attribute will delete it, but when we re-add the attribute, > (checked for things like trailing spaces.), the entry will reappear as > the base64 entry (with a trailing space when translated back.) > > It just appears 'stuck' and will not change to the intended text. > > Any help or pointers on this would be appreciated. > > > Could you double check your data to be added? This might be happening. http://www.faqs.org/rfcs/rfc2849.html RFC 2849 - The LDAP Data Interchange Format (LDIF) 8) Values or distinguished names that end with SPACE SHOULD be base-64 encoded. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20080501/66929db3/attachment.bin