Hi, we've checked that. The problem we're having is when we try to correct the entry using any client.
We'd delete the entry, then try to re-add it; checking for the trailing space. Then when we go to look at the entry again, the attribute has the trailing space, and in ldapsearch comes back as base64. It's a uniqueMember attribute so it's supposed to be ascii. It's perplexing. On Thu, 2008-05-01 at 09:48 -0700, Noriko Hosoi wrote: > 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. > > -- Kevin Graham System Administrator Advance Internet -- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
