apacheds-tools dump command does NOT generate the correct base 64 output for binary attributes in LDIF dump

• Key: DIRSERVER-612
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Critical
• Assignee: Alex Karasulu
• Reporter: Alex Karasulu
• Component/s: tools
• Affects Version/s: 1.0-RC2
• Fix Version/s: 1.5.0, 1.0-RC4

Description

The dump command which produces LDIF dumps of partitions is not generating the base64 encoded values for binary attributes. It seems to be printing just the byte[] which shows the id of the object in the jvm instead of the base64 encoded value.

Comments

[Pierre-Arnaud Marcelot]

Here is a patch for this issue.

Dump now generates base64 encoded for binary attributes and also text attributes that need to be base64 encoded (because they contain special characters, such as accent for example).

The part comes in two parts :
- One for apache/server-tools
- One for shared/ldap
(I couldn't managed to generate a global patch, 'svn diff' at root directory didn't give any difference... Strange...)

This post contains the first part. It must be patched for /apacheds

[Pierre-Arnaud Marcelot]

Here is the second part.

It must be patched from /shared.

I added a new class LdifUtils containing a method verifying that a String is LDIF safe.
I also implemented a TestCase for this new class and method.

I use this method to check if encoded is needed for text attributes in the Dump Command.

[Pierre-Arnaud Marcelot]

Last file...

Here is a patch for the current trunks for v1.1.0.

It must be applied from the root directory.

[Alex Karasulu]

Anybody apply your patches yet? Looks like it's up for grabs. I'll take care of this one.

[Alex Karasulu]

I applied your patches 432490, 432491 for 1.0 and 432492 for the trunks for 1.1.

THere is however a *big* problem. I noticed this after I applied the patches. I can roll back but instead I can take corrective patches from you. Here's what a dump now looks like:

#---------------------
# Entry: 23
#---------------------

dn: uid=user.22,dc=example,dc=com
pager: Attribute id : 'pager', Values : ['515-711-8297']
employeenumber: Attribute id : 'employeenumber', Values : ['22']
objectclass: Attribute id : 'objectclass', Values : ['person', 'organizationalPerson', 'inetOrgPerson']
mobile: Attribute id : 'mobile', Values : ['338-209-4979']
telephonenumber: Attribute id : 'telephonenumber', Values : ['619-921-3217']
street: Attribute id : 'street', Values : ['76697 Ash Street']
userpassword: Attribute id : 'userpassword', Values : ['cGFzc3dvcmQ=']
uid: Attribute id : 'uid', Values : ['user.22']
postalcode: Attribute id : 'postalcode', Values : ['09762']
givenname: Attribute id : 'givenname', Values : ['Abigael']
mail: Attribute id : 'mail', Values : ['[e-mail]']
l: Attribute id : 'l', Values : ['Dothan']
sn: Attribute id : 'sn', Values : ['Abel']
cn: Attribute id : 'cn', Values : ['Abigael Abel']
postaladdress: Attribute id : 'postaladdress', Values : ['Abigael Abel$76697 Ash Street$Dothan, CO 09762']
description: Attribute id : 'description', Values : ['This is the description for Abigael Abel.']
initials: Attribute id : 'initials', Values : ['AA']
homephone: Attribute id : 'homephone', Values : ['490-458-8467']
st: Attribute id : 'st', Values : ['CO']

Seems like we're using toString() on an attribute object instead of on it's value. The good news is the base64 issue is gone.

Can you supply a patch to fix this problem?

Thanks!

[Alex Karasulu]

It's pretty important that we make sure this dump tool works right before the next release. I'm raisint this to critical.

[Pierre-Arnaud Marcelot]

No problem Alex.

I'm now working on that.

It seems that the toString method I used has been changed in the merge of the optimization branch. This method doesn't print LDIF anymore.

I send the patch as soon as possible.

[Pierre-Arnaud Marcelot]

Here's the patch for Trunks.

The output is now ok.

I also corrected a possible bug. The DN is now encoded to Base64 if it needs to. It was printed as is before.
---
#---------------------
# Entry: 138
#---------------------

dn: Y249TMOpY2hhcm55LCBkYz1leGFtcGxlLGRjPWNvbQ==
cn:: TMOpY2hhcm55
objectclass: person
objectclass: top
---


Moreover, lines are now folded every 80 characters.
---
#---------------------
# Entry: 92
#---------------------

dn: cn=newperson, dc=example,dc=com
jpegphoto:: /9j/4AAQSkZJRgABAQEASABIAAD//gAoRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rv
 vc2hvcKggNC4wAA3/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIx
 wcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyM
 jIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAMABAADASIAAhEBAxEB/8QAHwAAAQUB
 AQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE
[...]
---

[Pierre-Arnaud Marcelot]

Just a small update to the patch since I noticed that if I forgot to add the additionnal : (Colon) next to the dn definition when the value is Base64 encoded. In my sample output above, "dn: Y249TMOpY2hhcm55LCBkYz1leGFtcGxlLGRjPWNvbQ==" should be "dn:: Y249TMOpY2hhcm55LCBkYz1leGFtcGxlLGRjPWNvbQ==".

Sorry about that.

[Pierre-Arnaud Marcelot]

The next two patches are for 1.0-RC4.

This one has to be applied from /apacheds.

[Pierre-Arnaud Marcelot]

And this one has to be applied from /shared.

[Alex Karasulu]

Applied second set of patches on 1.0 in versions 432590 and 432593 and for 1.1 trunks on version 432597.

NOTE: I applied the SecondEdition patch instead of the first one for the 1.1 trunks. I guessed these patches were not additive.

[Alex Karasulu]

reopen to edit fields

[Alex Karasulu]

fixed in 1.1 as well

[Alex Karasulu]

closed now.