11:16 a.m.
Hi All.
I have a question about ldap_result. I use openldap-2.3.32. It is my
understanding that this function (ldap_result) is
used in a loop until no more results are coming from the servers. Am I
right about it? The problem I have is that the
last time it is calle it hangs there for a while and finally returns
null LDAPMessage and -1 return value. I am talking
here about 10-15 seconds. Is it normal that it takes that long? I would
expect it to be pretty much instantaneous.
--
Dmitri Priimak
7:49 a.m.
Dmitri Priimak wrote:
Hi All.
I have a question about ldap_result. I use openldap-2.3.32. It is my
understanding that this function (ldap_result) is
used in a loop until no more results are coming from the servers. Am I
right about it? The problem I have is that the
last time it is calle it hangs there for a while and finally returns
null LDAPMessage and -1 return value. I am talking
here about 10-15 seconds. Is it normal that it takes that long? I would
expect it to be pretty much instantaneous.
It waits for the server to send a response message that concludes the
operation. If it does not return immediately, it is likely because the
server is not sending any, so it is unlikely the client library is to be
blamed. Feel free to abandon the operation as soon as you know that no
more results are coming, or make sure the server gently ends the
operation by sending the response message.
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
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
11:37 a.m.
Pierangelo Masarati wrote:
Dmitri Priimak wrote:
> Hi All.
>
> I have a question about ldap_result. I use openldap-2.3.32. It is my
> understanding that this function (ldap_result) is
> used in a loop until no more results are coming from the servers. Am I
> right about it? The problem I have is that the
> last time it is calle it hangs there for a while and finally returns
> null LDAPMessage and -1 return value. I am talking
> here about 10-15 seconds. Is it normal that it takes that long? I would
> expect it to be pretty much instantaneous.
>
It waits for the server to send a response message that concludes the
operation. If it does not return immediately, it is likely because the
server is not sending any, so it is unlikely the client library is to be
blamed. Feel free to abandon the operation as soon as you know that no
more results are coming, or make sure the server gently ends the
operation by sending the response message
How would I know that there are no more results coming?
I was thinking that you call ldap_result until it returns
NULL LDAPMessage. Is there some other way? May be the
last non-null LDAPMessage includes something to tell that
it is the last one?
--
Dmitri Priimak
11:43 a.m.
Dmitri Priimak wrote:
How would I know that there are no more results coming?
assuming you know it.
I was thinking that you call ldap_result until it returns
NULL LDAPMessage.
why do you "think" when you can determine the actual behavior by reading
the man page?
Is there some other way? May be the
last non-null LDAPMessage includes something to tell that
it is the last one?
Maybe yes, as indicated in the man page.
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
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
11:51 a.m.
Pierangelo Masarati wrote:
Dmitri Priimak wrote:
> How would I know that there are no more results coming?
>
assuming you know it.
> I was thinking that you call ldap_result until it returns
> NULL LDAPMessage.
>
why do you "think" when you can determine the actual behavior by reading
the man page?
> Is there some other way? May be the
> last non-null LDAPMessage includes something to tell that
> it is the last one?
>
Maybe yes, as indicated in the man page.
p.
I re-read the man page and it is clear to me now, even though it does
not feel right.
What I mean is that if all = 0 and timeout = NULL then it does not seem
possible to
now for sure if one retrieved all results of the search.
In any case, thanks for the help.
--
Dmitri Priimak
12:14 p.m.
Dmitri Priimak wrote:
I re-read the man page and it is clear to me now, even though it
does
not feel right.
What I mean is that if all = 0 and timeout = NULL then it does not seem
possible to
now for sure if one retrieved all results of the search.
Well, to me it looks clear (I'm referring to recent OpenLDAP 2.3 man
pages, there were some modifications recently): in response to a search
operation, the following results are expected:
LDAP_RES_SEARCH_ENTRY (0x64)
LDAP_RES_SEARCH_REFERENCE (0x73)
LDAP_RES_SEARCH_RESULT (0x65)
The latter indicates that the search is terminated. Whether it
terminates successfully or for any other reason, that's contained in the
response code in the LDAP_RES_SEARCH_RESULT message (see
ldap_parse_result(3) for indications about how to safely parse response
messages).
For a detailed description of the exact contents of each message, and of
the rationale of their use, refer to RFC 4511 (specifically, Section
4.5.2.).
Exceptionally, other message types could be returned (e.g.,
LDAP_RES_INTERMEDIATE when the LDAP sync control is used and, in
prospective, whenever a search operation is extended by some means
allowed by the protocol, but that's another business).
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
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
2:38 p.m.
New subject: str2entry: invalid value for attributeType userCertificate #0 (syntax 1.3.6.1.4.1.1466.115.121.1.8) ???
I am attempting to add some records to an ldap using slapadd and an ldif
file.
Here is the ldif entry:
objectclass: inetorgperson
objectclass: person
objectclass: top
dn: uid=12382227,ou=merchant,dc=telecheck,dc=com
ou: merchant
cn: 1238227
sn: 12382227
uid: 12382227
userPassword: xxxxxx
userCertificate: -----BEGIN PUBLIC KEY-----
MIHxMIGoBgcqhkjOOAQBMIGcAkEA/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII
864WF64B81uRpH5t9jQTxeEu0ImbzRMqzVDZkVG9xD7nN1kuFwIVAJYu3cw2nLqO
uyYO5rahJtk0bjjFAkBnhHGyepz0TukaScUUfbGpqvJE8FpDTWSGkx0tFCcbnjUD
C3H9c9oXkGmzLik1Yw4cIGI1TQ2iCmxBblC+eUykA0QAAkEAtySSO449SjAuEKHQ
cJYtD1LQMjxz96soVwXdpwLYbExhxGte4SLfexYXAaN1bdA43xV8AVlujuCr9lNc
ZVB4jQ==
-----END PUBLIC KEY-----
displayName: " "
businessCategory: " "
description: " "
When I execute slapadd I get the error message shown above in the
subject line and the report that "slapadd: could not parse entry
(line=59)", which is the line after the compete entry, that is, after
'description: "" '.
I do not understand what is going on. I have done this before
successfully many times with the very same ldif file (I am sure!) What
is happening?
I have tried several formats for the userCertificate value: 1) using
Unicode representatons of the newlines (that is the one that has worked
in the past) 2) using ascii \n representations of the newlines.
None of these approaches now seem to work. Please help. Thanks!!
-----------------------------------------
The information in this message may be proprietary and/or
confidential, and protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify First Data
immediately by replying to this message and deleting it from your
computer.
4:29 p.m.
New subject: str2entry: invalid value for attributeType userCertificate #0 (syntax 1.3.6.1.4.1.1466.115.121.1.8) ???
Marcum, Bob wrote:
I am attempting to add some records to an ldap using slapadd and an
ldif
file.
Here is the ldif entry:
objectclass: inetorgperson
objectclass: person
objectclass: top
dn: uid=12382227,ou=merchant,dc=telecheck,dc=com
ou: merchant
cn: 1238227
sn: 12382227
uid: 12382227
userPassword: xxxxxx
userCertificate: -----BEGIN PUBLIC KEY-----
MIHxMIGoBgcqhkjOOAQBMIGcAkEA/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII
864WF64B81uRpH5t9jQTxeEu0ImbzRMqzVDZkVG9xD7nN1kuFwIVAJYu3cw2nLqO
uyYO5rahJtk0bjjFAkBnhHGyepz0TukaScUUfbGpqvJE8FpDTWSGkx0tFCcbnjUD
C3H9c9oXkGmzLik1Yw4cIGI1TQ2iCmxBblC+eUykA0QAAkEAtySSO449SjAuEKHQ
cJYtD1LQMjxz96soVwXdpwLYbExhxGte4SLfexYXAaN1bdA43xV8AVlujuCr9lNc
ZVB4jQ==
-----END PUBLIC KEY-----
displayName: " "
businessCategory: " "
description: " "
When I execute slapadd I get the error message shown above in the
subject line and the report that "slapadd: could not parse entry
(line=59)", which is the line after the compete entry, that is, after
'description: "" '.
I do not understand what is going on. I have done this before
successfully many times with the very same ldif file (I am sure!) What
is happening?
That's pretty unlikely. A userCertificate attribute requires its values to be
in raw DER form, not PEM.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5809
days inactive
5810
days old
openldap-software@openldap.org
7 comments
4 participants
participants (4)
-
Dmitri Priimak -
Howard Chu -
Marcum, Bob -
Pierangelo Masarati