[Fedora-directory-users] FDS: Error in encoding and attribute deletion

[Kevin Graham]

Okay, I don't understand.

Here is the listing of the entry in question, using ldapsearch

uniqueMember: uid=user2,ou=People,dc=thisdomain,dc=net
uniqueMember:: dWlkPW1xxxxxxxG8sb3U9UGVvcGxlLGRjPWFkdmFuY2XXXXXXXdUs==

(i've changed it a little, because it's sensitive)

that appears when I search for cn=tech,ou=Groups,dc=thisdomain,dc=net

why would the one entry be returned as base64 encoded, when the others
aren't?  I don't want it to be stored that way.

When I use a tool, like ldapvi, or ldapmodify, and delete, then re-add
the entry:

'uniqueMember: uid=userX,ou=People,dc=thisdomain,dc=net' (no trailing
space,one colon)

then do a search for userX, nothing appears.  The strange thing is when
I look at the entry in say ADs, or jxplorer, it appears as uid=userX...
but with a trailing space.  I have made sure anytime I've re-added the
entry that there is never a '::' or a trailing space.  I've even used
ADs, and phpldapadmin, and jxplorer to do the delete->add->check cycle 
and always end up with the same result.

I know the letters/numbers are the base64 encoded string I want returned
(with a space after it.) I just can't get that one entry to behave like
the other attributes.  I add it the same exact way I do the other
entries in the same group.

Why would the directory server think that I want a uniqueMember
attribute encoded/stored as a base64 string when I don't tell it to do
that, or return the entry as one.  I just want the directory server to
return the entry as uniqueMember:
uid=userX,ou=People,dc=thisdomain,dc=net
so when I search for it, it is there.

Maybe it was added as a base64 originally, and I just can't update,
remove the record?  I really think it might be something with the
backend?  Is there a way to check that?

Thank You for your help/.


On Thu, 2008-05-01 at 22:19 +0200, Michael Ströder wrote:
> Kevin Graham wrote:
> > 
> > The problem we're having is when we try to correct the entry using any
> > client.
> 
> It's simply valid LDIF like Noriko already told you. A double colon 
> after attribute type name indicates that you have to base64-decode the 
> attribute value. If you want to process LDIF then use a decent LDIF 
> parser. This has not necessarily to do with the attribute values. It 
> would also be valid data encoded in valid LDIF if all attributes are 
> base64-encoded in lines attrType:: attrValue.
> 
> > It's a uniqueMember attribute so it's supposed to be ascii.
> 
> No, it's not supposed to be ASCII at least since it contains DNs which 
> can be UTF-8. Maybe in your case it's supposed to be ASCII but not in 
> general.
> 
> Ciao, Michael.
-- 
Kevin Graham
System Administrator
Advance Internet