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 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@sys-net.it ---------------------------------------
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
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@sys-net.it ---------------------------------------
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
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@sys-net.it ---------------------------------------
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.
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.
openldap-software@openldap.org
-
Dmitri Priimak -
Howard Chu -
Marcum, Bob -
Pierangelo Masarati