5:08 a.m.
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
10:45 a.m.
--On Monday, May 04, 2015 3:08 PM +0200 Frank Offermanns
<Frank.Offermanns(a)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
10:44 p.m.
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(a)zimbra.com>
An: Frank Offermanns <Frank.Offermanns(a)caseris.de>,
openldap-technical(a)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(a)openldap.org>
--On Monday, May 04, 2015 3:08 PM +0200 Frank Offermanns
<Frank.Offermanns(a)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
11:11 p.m.
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.
11:39 p.m.
New subject: Antwort: Re: Need migrationhelp for 1.3.6.1.4.1.1466.115.121.1.5 because of bug in slapcat
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
12:02 a.m.
New subject: Antwort: Re: Need migrationhelp for 1.3.6.1.4.1.1466.115.121.1.5 because of bug in slapcat
--On Tuesday, May 05, 2015 9:39 AM +0200 Frank Offermanns
<Frank.Offermanns(a)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
12:22 a.m.
New subject: Antwort: Re: Antwort: Re: Need migrationhelp for 1.3.6.1.4.1.1466.115.121.1.5 because of bug in slapcat
> 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
12:53 a.m.
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.
2:26 a.m.
New subject: Antwort: Re: Need migrationhelp for 1.3.6.1.4.1.1466.115.121.1.5 because of bug in slapcat
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
2:47 a.m.
New subject: Antwort: Re: Antwort: Re: Need migrationhelp for 1.3.6.1.4.1.1466.115.121.1.5 because of bug in slapcat
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?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
3:12 a.m.
New subject: Antwort: Re: Need migrationhelp for 1.3.6.1.4.1.1466.115.121.1.5 because of bug in slapcat
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(a)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
...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
3072
days inactive
3073
days old
openldap-technical@openldap.org
10 comments
4 participants
participants (4)
-
Frank Offermanns -
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount