jwilleke Trusted Contributor.
Trusted Contributor.
685 views

Re: Bulk user's photos import to eDirectory 8.8 SP5

I am having the same issue.

Can not find a method to import a jpeg to the photo attribute.

file is like:

dn: cn=fseese,ou=People,ou=Users,o=willeke
changetype: modify
add: photo
photo:< file:///root/tmp/01690296.jpg

ldapmodify -h "iam-prodidm03" -D "cn=joe,ou=services,o=willeke" -w
nothere -f "/root/tmp/fseese.ldif"
modifying entry "cn=fseese,ou=People,ou=Users,o=willeke"
ldap_modify: Unknown error
additional info: NDS error: insufficient buffer (-649)


Any ideas?
--

Thank You for your help!

-jim
Jim Willeke

Labels (1)
0 Likes
7 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Bulk user's photos import to eDirectory 8.8 SP5

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Does the rest of the thread apply with regard to the file size? How big
is this file?

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJO1TW6AAoJEF+XTK08PnB5frEP/0YADFTeEV5P9wbwxG0DlKtm
kvPkwClBibh+07UXpy20RqEkJksdbztaR0lMZZqScOo75phsD9UOFjux2gsmqxXZ
XkFmK5CK820Ht7Uaf53ktMegXW9NMGoQVxoTc8JWnXlIWJTsIdOrXr+FNDy0Pks8
dUH5bzJiTG+U02K9hiRER8FgxTdIfXYDIQnTwjjRQW9qqEp4/9He+RSs0gCv9nk4
dnA539TDaRQKxr4XGEo11T9C+rmW5IKxc0++HjBRsctdINVgk5E0L5d04zd7mQze
7mgu31MbX7/y3OHI1leKlTNi2SdFKynK+DGrA+McRatVZ89mdsvs6oeI24oMyQn4
ESMp4G2kbxQ+uI3tC2krRjU8ZMeZhIEXp+cRgkDQcua5E/CjW/M56YqV9GTShHho
BZg4SqZNo5FtQhWLC225TGIGELC1BTBv4ilGNhJ1i2KjA9Nkmqjw/VY1SjHwO2N1
burCme+Mn0sregCJME/+J/vKlxRZ11aMcHtwNzcJuGweSHZKEtCM+6OY8llfV7sO
vAp7HF8j5ahBKA73RaLShXxGhLUpLTXD6dzZEkW54cO/N1PG01jz0ea1yv1T6ySx
gpl/EUOHgJb1GKPSR3sYbjeo1bHr5FQ06TxwmvXqXnc2m6p5OpkTS5sBoFGyrpxh
gAYZoVYeG//9TyNAUA5R
=HgO8
-----END PGP SIGNATURE-----
0 Likes
peterkuo Absent Member.
Absent Member.

Re: Bulk user's photos import to eDirectory 8.8 SP5


There is a finite file sized limit ...


--
peterkuo
------------------------------------------------------------------------
peterkuo's Profile: http://forums.novell.com/member.php?userid=88
View this thread: http://forums.novell.com/showthread.php?t=435379


-- eDirectory Rules! Peter www.DreamLAN.com
0 Likes
jwilleke Trusted Contributor.
Trusted Contributor.

Re: Bulk user's photos import to eDirectory 8.8 SP5

On 2011-11-29 22:26:01 +0000, peterkuo said:

> There is a finite file sized limit ...


Not according to the schema.

( 0.9.2342.19200300.100.1.7 NAME 'ldapPhoto' SYNTAX
1.3.6.1.4.1.1466.115.121.1.40{64512} )

Shows sized at 65k.

--

Thank You for your help!

-jim
Jim Willeke

0 Likes
peterkuo Absent Member.
Absent Member.

Re: Bulk user's photos import to eDirectory 8.8 SP5


jwilleke;2158923 Wrote:
> On 2011-11-29 22:26:01 +0000, peterkuo said:
>
> > There is a finite file sized limit ...

>
> Not according to the schema.
>
> ( 0.9.2342.19200300.100.1.7 NAME 'ldapPhoto' SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.40{64512} )
>
> Shows sized at 65k.
>
> --
>
> Thank You for your help!
>
> -jim
> Jim Willeke



Perhaps I misunderstood you, but isn't "Sized at 65K" a 'finite' file
size limit? <g>


--
peterkuo
------------------------------------------------------------------------
peterkuo's Profile: http://forums.novell.com/member.php?userid=88
View this thread: http://forums.novell.com/showthread.php?t=435379


-- eDirectory Rules! Peter www.DreamLAN.com
0 Likes
jwilleke Trusted Contributor.
Trusted Contributor.

Re: Bulk user's photos import to eDirectory 8.8 SP5

The value {64512} indicates the maximum size of the attribute and is an
optional setting.
In LDAPv3, the len value is a "suggested upper minimum bound", not a
maximum length restriction. From last paragraph of RFC 2252, 4.3.2.

"A suggested minimum upper bound on the number of characters in value
with a string-based syntax, or the number of bytes in a value for all
other syntaxes, may be indicated by appending this bound count inside
of curly braces following the syntax name's OBJECT IDENTIFIER in an
Attribute Type Description. This bound is not part of the syntax
name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that
server implementations should allow a string to be 64 characters
long, although they may allow longer strings. Note that a single
character of the Directory String syntax may be encoded in more than
one byte since UTF-8 is a variable-length encoding."

According to Novell's document schema
http://developer.novell.com/documentation/ndslib/index.html?page=/ndk/doc/ndslib/schm_enu/data/h4q1mn1i.html


"The picture file cannot exceed 64K."

Form a "pure" LDAP perspective, the LDAP attribute with the OID
0.9.2342.19200300.100.1.60 is jpegPhoto which maps to the NDS attribute
photo. (Or the other way around, depending ont he pserspective).

Acording to the Informational RFC http://www.ietf.org/rfc/rfc2798.txt,
jpegPhoto is NOT sized.

-jim


On 2011-12-07 06:46:01 +0000, peterkuo said:

> jwilleke;2158923 Wrote:
>> On 2011-11-29 22:26:01 +0000, peterkuo said:
>>
>>> There is a finite file sized limit ...

>>
>> Not according to the schema.
>>
>> ( 0.9.2342.19200300.100.1.7 NAME 'ldapPhoto' SYNTAX
>> 1.3.6.1.4.1.1466.115.121.1.40{64512} )
>>
>> Shows sized at 65k.
>>
>> --
>>
>> Thank You for your help!
>>
>> -jim
>> Jim Willeke

>
>
> Perhaps I misunderstood you, but isn't "Sized at 65K" a 'finite' file
> size limit? <g>



--

Thank You for your help!

-jim
Jim Willeke

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Bulk user's photos import to eDirectory 8.8 SP5

Interesting and strange phrases in that RFC: "suggested upper minimum
bound" ... "may allow longer strings"

Imagine such rules for road speed limit signs.

It is my understanding that eDirectory strictly enforces these upper and
lower limits. So I assume, even if eDir "may allow longer strings"
without violating the RFC, it just doesn't.


DS_SIZED_ATTR

Indicates that the attribute has an upper and lower boundary. This can
be the length for strings or the value for integers.The first number
indicates the lower boundary and the second, the upper boundary.

Wolfgang


On 08.12.2011 16:28, Jim Willeke wrote:
> The value {64512} indicates the maximum size of the attribute and is an
> optional setting.
> In LDAPv3, the len value is a "suggested upper minimum bound", not a
> maximum length restriction. From last paragraph of RFC 2252, 4.3.2.
>
> "A suggested minimum upper bound on the number of characters in value
> with a string-based syntax, or the number of bytes in a value for all
> other syntaxes, may be indicated by appending this bound count inside
> of curly braces following the syntax name's OBJECT IDENTIFIER in an
> Attribute Type Description. This bound is not part of the syntax
> name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that
> server implementations should allow a string to be 64 characters
> long, although they may allow longer strings. Note that a single
> character of the Directory String syntax may be encoded in more than
> one byte since UTF-8 is a variable-length encoding."
>
> According to Novell's document schema
> http://developer.novell.com/documentation/ndslib/index.html?page=/ndk/doc/ndslib/schm_enu/data/h4q1mn1i.html
>
>
> "The picture file cannot exceed 64K."
>
> Form a "pure" LDAP perspective, the LDAP attribute with the OID
> 0.9.2342.19200300.100.1.60 is jpegPhoto which maps to the NDS attribute
> photo. (Or the other way around, depending ont he pserspective).
>
> Acording to the Informational RFC http://www.ietf.org/rfc/rfc2798.txt,
> jpegPhoto is NOT sized.
>
> -jim
>
>
> On 2011-12-07 06:46:01 +0000, peterkuo said:
>
>> jwilleke;2158923 Wrote:
>>> On 2011-11-29 22:26:01 +0000, peterkuo said:
>>>
>>>> There is a finite file sized limit ...
>>>
>>> Not according to the schema.
>>>
>>> ( 0.9.2342.19200300.100.1.7 NAME 'ldapPhoto' SYNTAX
>>> 1.3.6.1.4.1.1466.115.121.1.40{64512} )
>>>
>>> Shows sized at 65k.
>>>
>>> --
>>>
>>> Thank You for your help!
>>>
>>> -jim
>>> Jim Willeke

>>
>>
>> Perhaps I misunderstood you, but isn't "Sized at 65K" a 'finite' file
>> size limit? <g>

>
>

0 Likes
jwilleke Trusted Contributor.
Trusted Contributor.

Re: Bulk user's photos import to eDirectory 8.8 SP5

That is what I see from reading and what I have done to experimint.

And I just could not let this one die.

When I look at the LDAP schema, I see the following:
( 0.9.2342.19200300.100.1.7 NAME 'photo' SYNTAX
1.3.6.1.4.1.1466.115.121.1.40{64512} )
( 0.9.2342.19200300.100.1.7 NAME 'ldapPhoto' SYNTAX
1.3.6.1.4.1.1466.115.121.1.40{64512} )

Now, it may not look bad at first glance, but we have the SAME OID for
two different attributes.

Clearly a failure in LDAP RFC compliance.

No mappings on the LDAP Group entry for these, they are really two
different attributes.

Photo, described here:
http://developer.novell.com/documentation/ndslib/schm_enu/index.html?page=/documentation/ndslib/schm_enu/data/a8fgntj.html


ldapPhoto descibed here:
http://developer.novell.com/documentation/ndslib/schm_enu/index.html?page=/documentation/ndslib/schm_enu/data/a3op8zp.html


So this is definitly broken.


On 2011-12-08 21:01:48 +0000, Wolfgang Schreiber said:

> Interesting and strange phrases in that RFC: "suggested upper minimum
> bound" ... "may allow longer strings"
>
> Imagine such rules for road speed limit signs.
>
> It is my understanding that eDirectory strictly enforces these upper
> and lower limits. So I assume, even if eDir "may allow longer strings"
> without violating the RFC, it just doesn't.
>
>
> DS_SIZED_ATTR
>
> Indicates that the attribute has an upper and lower boundary. This can
> be the length for strings or the value for integers.The first number
> indicates the lower boundary and the second, the upper boundary.
>
> Wolfgang
>
>
> On 08.12.2011 16:28, Jim Willeke wrote:
>> The value {64512} indicates the maximum size of the attribute and is an
>> optional setting.
>> In LDAPv3, the len value is a "suggested upper minimum bound", not a
>> maximum length restriction. From last paragraph of RFC 2252, 4.3.2.
>>
>> "A suggested minimum upper bound on the number of characters in value
>> with a string-based syntax, or the number of bytes in a value for all
>> other syntaxes, may be indicated by appending this bound count inside
>> of curly braces following the syntax name's OBJECT IDENTIFIER in an
>> Attribute Type Description. This bound is not part of the syntax
>> name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that
>> server implementations should allow a string to be 64 characters
>> long, although they may allow longer strings. Note that a single
>> character of the Directory String syntax may be encoded in more than
>> one byte since UTF-8 is a variable-length encoding."
>>
>> According to Novell's document schema
>> http://developer.novell.com/documentation/ndslib/index.html?page=/ndk/doc/ndslib/schm_enu/data/h4q1mn1i.html
>>
>>
>>
>> "The picture file cannot exceed 64K."
>>
>> Form a "pure" LDAP perspective, the LDAP attribute with the OID
>> 0.9.2342.19200300.100.1.60 is jpegPhoto which maps to the NDS attribute
>> photo. (Or the other way around, depending ont he pserspective).
>>
>> Acording to the Informational RFC http://www.ietf.org/rfc/rfc2798.txt,
>> jpegPhoto is NOT sized.
>>
>> -jim
>>
>>
>> On 2011-12-07 06:46:01 +0000, peterkuo said:
>>
>>> jwilleke;2158923 Wrote:
>>>> On 2011-11-29 22:26:01 +0000, peterkuo said:
>>>>
>>>>> There is a finite file sized limit ...
>>>>
>>>> Not according to the schema.
>>>>
>>>> ( 0.9.2342.19200300.100.1.7 NAME 'ldapPhoto' SYNTAX
>>>> 1.3.6.1.4.1.1466.115.121.1.40{64512} )
>>>>
>>>> Shows sized at 65k.
>>>>
>>>> --
>>>>
>>>> Thank You for your help!
>>>>
>>>> -jim
>>>> Jim Willeke
>>>
>>>
>>> Perhaps I misunderstood you, but isn't "Sized at 65K" a 'finite' file
>>> size limit? <g>



--

Thank You for your help!

-jim
Jim Willeke

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.