Can anyone shed any light on :
slapadd: could not parse entry (line=234) str2entry: attributeType userCertificate #0: needs ';binary' transfer as per syntax 1.3.6.1.4.1.1466.115.121.1.8
This is ocurring when running 2.4.x slapadd on a certificate containing a binary attribute, which was a slapcat from a 2.3.X openldap server.
The attribute in question is already a binary attribute, there is a double colon after the certificate name, so i gather it just wants userCertificate;binary:: as the attribute name in the LDIF dump when loading ? Cant simply search and replace, because that will increase the line length, which will stop it from parsing.
Alternatively, anybody know of any tool which can re-justify line lengths in an ldif, if i search and replace the attribute name ?
It might be nice to have some sort of non-default legacy flag, for loading a previous release's ldif (or at least be more forgiving than the present parser)
Cheers Brett
Brett @Google wrote:
Can anyone shed any light on :
slapadd: could not parse entry (line=234) str2entry: attributeType userCertificate #0: needs ';binary' transfer as per syntax 1.3.6.1.4.1.1466.115.121.1.8
This is ocurring when running 2.4.x slapadd on a certificate containing a binary attribute, which was a slapcat from a 2.3.X openldap server.
The attribute in question is already a binary attribute, there is a double colon after the certificate name, so i gather it just wants userCertificate;binary:: as the attribute name in the LDIF dump when loading ? Cant simply search and replace, because that will increase the line length, which will stop it from parsing.
No, it won't: lines can be as long as you like.
Alternatively, anybody know of any tool which can re-justify line lengths in an ldif, if i search and replace the attribute name ?
It might be nice to have some sort of non-default legacy flag, for loading a previous release's ldif (or at least be more forgiving than the present parser)
Probably, yes. In this specific case, given its exceptionality, probably sed s/userCertificate::/userCertificate;binary::/ suffices.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Probably, yes. In this specific case, given its exceptionality, probably sed s/userCertificate::/userCertificate;binary::/ suffices.
I think i tried that at the time (it was a while ago), if i recall that pushed the line length above what was parsable, but if i manually would have re-justified each line length the lines would have parsed ok, but it was a large file and i was just giving it a quick test.
Does slapadd enforce a strict maximum line length ?
Cheers Brett
openldap-software@openldap.org
-
Brett ＠Google -
Pierangelo Masarati