Hello,
in our custom schema we have used several attributes with the syntax: 1.3.6.1.4.1.1466.115.121.1.5 attributetype ( myAttributeType:106 NAME ( 'casFileContent' ) DESC 'Contains the file' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE )
We defined this schema before this syntax was dropped.
Everything worked for a long time. Now with OpenLDAP Version 2.4.39 and newer a slapcat does no longer export this attributes as MimeContent, but as plain text. So the ldif can't be used for importing. So I started a research why and found that this syntax was dropped. But for downward compatibility shouldn't it still export this syntax as mime content, shouldt it? This would be important, since in inetorgperson.schema the 2 attributes userSMIMECertificate and userPKCS12 still use it.
What syntax should I use for files stored in LDAP? And even more important, how can I change the syntax of a attribute. Is there a migration strategy to change the syntax of a attribute?
Regards, Frank
--On Monday, May 04, 2015 3:08 PM +0200 Frank Offermanns Frank.Offermanns@caseris.de wrote:
Hello,
in our custom schema we have used several attributes with the syntax: 1.3.6.1.4.1.1466.115.121.1.5 attributetype ( myAttributeType:106 NAME ( 'casFileContent' ) DESC 'Contains the file' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE )
We defined this schema before this syntax was dropped.
Everything worked for a long time. Now with OpenLDAP Version 2.4.39 and newer a slapcat does no longer export this attributes as MimeContent, but as plain text. So the ldif can't be used for importing. So I started a research why and found that this syntax was dropped. But for downward compatibility shouldn't it still export this syntax as mime content, shouldt it? This would be important, since in inetorgperson.schema the 2 attributes userSMIMECertificate and userPKCS12 still use it.
What syntax should I use for files stored in LDAP? And even more important, how can I change the syntax of a attribute. Is there a migration strategy to change the syntax of a attribute?
Hi Frank,
A couple of things:
a) I don't see any ITS filed for this issue. Generally that means if this is a real bug, nothing will/can be fixed, since it hasn't been reported as a problem.
b) I still see that this syntax is part of inetorgperson.schema and in schema_init.c
static slap_syntax_defs_rec syntax_defs[] = { {"( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' " X_NOT_H_R ")", SLAP_SYNTAX_BER, NULL, berValidate, NULL},
so it appears to me that it still exists as a valid syntax, using SLAP_SYNTAX_BER?
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Hello Quanah,
indeed there is no ITS for this issue so far. I was not sure, if I should make an ITS, because this SYNTAX shouldn't be used any longer (see http://www.openldap.org/lists/openldap-devel/200902/msg00067.html) , but as I stated before for downward campatibility I am also of the opinion that this is a bug.
And if you also think this is a bug (and it will be fixed), every other question is obsolete, since then there is no need for me to migrate the attributes.
Regards, Frank
Von: Quanah Gibson-Mount quanah@zimbra.com An: Frank Offermanns Frank.Offermanns@caseris.de, openldap-technical@openldap.org Datum: 04.05.2015 20:04 Betreff: Re: Need migrationhelp for 1.3.6.1.4.1.1466.115.121.1.5 because of bug in slapcat Gesendet von: "openldap-technical" openldap-technical-bounces@openldap.org
--On Monday, May 04, 2015 3:08 PM +0200 Frank Offermanns Frank.Offermanns@caseris.de wrote:
Hello,
in our custom schema we have used several attributes with the syntax: 1.3.6.1.4.1.1466.115.121.1.5 attributetype ( myAttributeType:106 NAME ( 'casFileContent' ) DESC 'Contains the file' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE )
We defined this schema before this syntax was dropped.
Everything worked for a long time. Now with OpenLDAP Version 2.4.39 and newer a slapcat does no longer export this attributes as MimeContent, but as plain text. So the ldif can't be used for importing. So I started a research why and found that this syntax was dropped. But for downward compatibility shouldn't it still export this syntax as mime content, shouldt it? This would be important, since in inetorgperson.schema the 2 attributes userSMIMECertificate and userPKCS12 still use it.
What syntax should I use for files stored in LDAP? And even more important, how can I change the syntax of a attribute. Is there a migration strategy to change the syntax of a attribute?
Hi Frank,
A couple of things:
a) I don't see any ITS filed for this issue. Generally that means if this
is a real bug, nothing will/can be fixed, since it hasn't been reported as
a problem.
b) I still see that this syntax is part of inetorgperson.schema and in schema_init.c
static slap_syntax_defs_rec syntax_defs[] = { {"( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' " X_NOT_H_R ")", SLAP_SYNTAX_BER, NULL, berValidate, NULL},
so it appears to me that it still exists as a valid syntax, using SLAP_SYNTAX_BER?
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Frank Offermanns wrote:
Hello,
in our custom schema we have used several attributes with the syntax: 1.3.6.1.4.1.1466.115.121.1.5 attributetype ( myAttributeType:106 NAME ( 'casFileContent' ) DESC 'Contains the file' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE )
We defined this schema before this syntax was dropped.
Everything worked for a long time. Now with OpenLDAP Version 2.4.39 and newer a slapcat does no longer export this attributes as MimeContent, but as plain text.
I have to admit that this text rather confuses me. What is "MimeContent" in this context? Are you familiar with the correct use of base64 when generating/parsing LDIF (see RFC 2849)?
So the ldif can't be used for importing.
Could you please give LDIF examples what is currently exported and what you expect to be correct?
Ciao, Michael.
I am sorry that I confused you. I hope this samples make thinks clear:
New Ldif Content: "dn: cn=hghg,cn=InitialUser,ou=Users,o=caesar cn: hghg FileContent: This is the content of my file. As you can see it is not encoded. Therefor I can not be imported since ; : blanks,
carriage return etc are not masked ..."
Ldif Content of older OpenLDAP version: "dn: cn=Announcement_Name,cn=testuser,ou=Users,ou=DE,ou=mydom DE,ou=myComp ,ou=Users,o=caesar cn: Announcement_Name FileContent:: qquqq6ur5+6KAYuAiGmhrD58cnL8I2VrYGphL6I6f3R9/DMv4+vn6+EqovJydvSv4+Eg4Ozn4rn2dnf9
O74/NLGg4+wsvfRwf3d8eHh7dnj48/v+/vswsbW+ruNjjgGIgoRv7uQ7cX38peNrYmZsYe+r9Hd+f
ze6oi7l5mXqKDk5PDe2NDCr6GJq67T88vj3+nv0vORma6P9//57cXKXdnh8cH5+enn/+PG+OzqyJu
xmj4INjIiHZe4o8HRw9aTubGhkbGfot/54cn/w+zmr6mJj5ScjKb8yLug9+bW9N6o6+zu2PzrjKbW
++nn/9nh+fHF/d3qdcHx0c/k9Pr++MSXoYoGGCguLgohs6TRze/K0puJoaWFmbK84/fZweHnyv+5g
aGpuaGZmI3tw+nf6enO45OmlIS6vPHdzfnnyfnB8cHt5eXl3d318evT59iXmboSKCAIDjI6Gb6z0f H//vrIib2Vvbmcmr7T ..."
I hope this makes things clearer. Tell me if I should make an ITS.
Regards, Frank
--On Tuesday, May 05, 2015 9:39 AM +0200 Frank Offermanns Frank.Offermanns@caseris.de wrote:
I hope this makes things clearer. Tell me if I should make an ITS.
That's called "Base64 encoding". Go decode your encoded value, I think you'll be happy.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
I hope this makes things clearer. Tell me if I should make an ITS.
That's called "Base64 encoding". Go decode your encoded value, I think you'll be happy.
The current ldif exports are not encoded, so what should I decode? The old was, as it should be.
To be more clear:
With OpenLDAP 2.3.35 I could make a slapcat and then a slapadd and had no problems because the ldif generated of slapcat was Base64 encoded for attributes of syntax 1.3.6.1.4.1.1466.115.121.1.5, so slapadd was able to import it.
With OpenLDAP 2.3.39, 40 and 41 the slapcat generates a "bad" ldif, where binary content of the syntax 1.3.6.1.4.1.1466.115.121.1.5 is not Base64 encoded. So slapadd is not able to import it.
Regards, Frank
Frank Offermanns wrote:
I am sorry that I confused you. I hope this samples make thinks clear:
New Ldif Content: "dn: cn=hghg,cn=InitialUser,ou=Users,o=caesar cn: hghg FileContent: This is the content of my file. As you can see it is not encoded. Therefor I can not be imported since ; : blanks,
carriage return etc are not masked ..."
Ldif Content of older OpenLDAP version: "dn: cn=Announcement_Name,cn=testuser,ou=Users,ou=DE,ou=mydom DE,ou=myComp ,ou=Users,o=caesar cn: Announcement_Name FileContent:: qquqq6ur5+6KAYuAiGmhrD58cnL8I2VrYGphL6I6f3R9/DMv4+vn6+EqovJydvSv4+Eg4Ozn4rn2dnf9
: indicated no base64-encoding, :: indicates base64-encoding used.
This all looks correct. You simply have to correctly parse the LDIF output. Note that this has nothing to do with MIME even if it looks similar to you.
See RFC 2849 for the details. And use a decent LDIF parser for your favourite scripting language and not some home-grown bash/sed/awk/whatever scripts which fail for such a simple thing.
Ciao, Michael.
This all looks correct. You simply have to correctly parse the LDIF
output.
See RFC 2849 for the details. And use a decent LDIF parser for your
favourite
scripting language and not some home-grown bash/sed/awk/whatever scripts which fail for such a simple thing.
I am not quite sure, if I understand it correctly. I made the ldif using slapcat. Slapcat used to Base64 encode the 1.3.6.1.4.1.1466.115.121.1.5 syntax. Now it doesn't do that anymore. But due to this change slapadd is not able to import this file. So I simply use slapcat and slapadd, but now slapadd fails. I am not using any other tools, only OpenLDAP tools. And if I only use OpenLDAP tools everything should work correctly, shouldn't it? That's why I think there is a bug in slapcat. But if you think slapcat works correctly I could also say: There is a bug in slapadd, because it can't import the ldif generated by slapcat.
Regards, Frank
Frank Offermanns wrote:
I hope this makes things clearer. Tell me if I should make an ITS.
That's called "Base64 encoding". Go decode your encoded value, I think you'll be happy.
The current ldif exports are not encoded, so what should I decode? The old was, as it should be.
To be more clear:
With OpenLDAP 2.3.35 I could make a slapcat and then a slapadd and had no problems because the ldif generated of slapcat was Base64 encoded for attributes of syntax 1.3.6.1.4.1.1466.115.121.1.5, so slapadd was able to import it.
With OpenLDAP 2.3.39, 40 and 41 the slapcat generates a "bad" ldif, where binary content of the syntax 1.3.6.1.4.1.1466.115.121.1.5 is not Base64 encoded. So slapadd is not able to import it.
OpenLDAP 2.3.41 is over 7 years old. Why are you using such an old release?
Frank Offermanns wrote:
This all looks correct. You simply have to correctly parse the LDIF output.
See RFC 2849 for the details. And use a decent LDIF parser for your favourite scripting language and not some home-grown bash/sed/awk/whatever scripts which fail for such a simple thing.
I am not quite sure, if I understand it correctly. I made the ldif using slapcat. Slapcat used to Base64 encode the 1.3.6.1.4.1.1466.115.121.1.5 syntax. Now it doesn't do that anymore. But due to this change slapadd is not able to import this file. So I simply use slapcat and slapadd, but now slapadd fails. I am not using any other tools, only OpenLDAP tools. And if I only use OpenLDAP tools everything should work correctly, shouldn't it? That's why I think there is a bug in slapcat. But if you think slapcat works correctly I could also say: There is a bug in slapadd, because it can't import the ldif generated by slapcat.
Can't reproduce the problem here.
### violino:~/OD/hobj/tests> cat file.ldif dn: cn=Jennifer Smith,ou=Alumni Association,ou=People,dc=example,dc=com changetype: modify replace: userSMIMEcertificate userSMIMEcertificate:< file:file.ldif violino:~/OD/hobj/tests> ../clients/tools/ldapmodify -x -H ldap://:9011 -D cn=manager,dc=example,dc=com -w secret -f file.ldif violino:~/OD/hobj/tests> ../servers/slapd/slapd -Tc -f testrun/slapd.1.conf
... dn: cn=Jennifer Smith,ou=Alumni Association,ou=People,dc=example,dc=com objectClass: OpenLDAPperson cn: Jennifer Smith cn: Jen Smith sn: Smith uid: jen postalAddress: Alumni Association $ 111 Maple St $ Anytown, MI 48109 seeAlso: cn=All Staff,ou=Groups,dc=example,dc=com drink: Sam Adams homePostalAddress: 1000 Maple #44 $ Anytown, MI 48103 title: Telemarketer, UM Alumni Association mail: jen@mail.alumni.example.com homePhone: +1 313 555 2333 pager: +1 313 555 6442 facsimileTelephoneNumber: +1 313 555 2756 telephoneNumber: +1 313 555 8232 structuralObjectClass: OpenLDAPperson entryUUID: 36d5bdb8-d6b8-49c3-a2f3-225ea3b5aee1 creatorsName: cn=Manager,dc=example,dc=com createTimestamp: 20150324065632Z userSMIMECertificate:: ZG46IGNuPUplbm5pZmVyIFNtaXRoLG91PUFsdW1uaSBBc3NvY2lhd GlvbixvdT1QZW9wbGUsZGM9ZXhhbXBsZSxkYz1jb20KY2hhbmdldHlwZTogbW9kaWZ5CnJlcGxh Y2U6IHVzZXJTTUlNRWNlcnRpZmljYXRlCnVzZXJTTUlNRWNlcnRpZmljYXRlOjwgZmlsZTpmaWx lLmxkaWYK entryCSN: 20150505100709.913100Z#000000#000#000000 modifiersName: cn=manager,dc=example,dc=com modifyTimestamp: 20150505100709Z
...
openldap-technical@openldap.org
-
Frank Offermanns -
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount