(ITS#7015) slapd.ldif example file not installed
by andrew.findlay@skills-1st.co.uk
Full_Name: Andrew Findlay
Version: 2.4.26
OS: OpenSuSE 11.4
URL:
Submission from: (NULL) (2a01:348:28c:1:222:68ff:fe15:3346)
slapdconf2.sdf says:
The distribution contains an example configuration file that will
be installed in the {{F: /usr/local/etc/openldap}} directory.
There is an example file in the source: servers/slapd/slapd.ldif
but it is not installed anywhere. The corresponding slapd.conf example
does get installed, so this one should probably go alongside it.
12 years, 3 months
Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by masarati@aero.polimi.it
> Sounds like this may be related to ITS#6817. Please try adding a dummy
> binddn
> to your idassert-bind directive and re-test.
First of all, I believe the real problem is that pr should not be used by
the client in the first place.
However, the cause of the issue might be something slightly different:
back-ldap uses a pool of connections for special identities, including
anonymous and rootdn; the latter is the case when identity assertion is
used. So it seems plausible that although the client uses the same
connection for repeated paged results requests, the proxy is using
different ones.
We already discussed the possibility to specially handle pr in proxies, in
order to decouple its use by the client and the remote server. If slapd
handles pr in the frontend, a proxy does not need to propagate pr requests
to the remote server. Similarly, if a remote server *needs* pr, the
client must not necessarily know about it.
Something like this has already been implemented in back-meta(5), which
can be instructed to silently continue unsolicited pr responses without
informing the client about them (I should have ported this to back-ldap(5)
as well).
If this is the case (need to investigate in detail, yet), a quick fix
could be to detect the presence of pr on a request, and bind the cookie to
a specific connection until that cookie is gone. One thing that could be
tried is to use slapo-sssvlv(5) on top of back-ldap and let it deal with
the pr request.
p.
12 years, 3 months
Re: (ITS#7009) TIMEOUT with unexpected results
by masarati@aero.polimi.it
> libldap's ldap_result() sets ld_errno to LDAP_TIMEOUT but returns 0, so
> ldapsearch (and all tools) are fooled by not actually checking ld_errno
> (actually, ldap_get_option(LDAP_OPT_RESULT_CODE)).
Fixed in master. Also fixed timelimit (apparently, it was not honored).
p.
12 years, 3 months
Re: (ITS#7009) TIMEOUT with unexpected results
by masarati@aero.polimi.it
> Full_Name: Bjoern Jacke
> Version: 2.4.23
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (193.159.216.39)
>
>
> When TIMEOUT is set and happend to occur there is nothing that shows that
> we
> timed out. For example if you do a large/slow LDAP search using ldapsearch
> and
> then stop the conversation between slapd and ldapsearch by "killall -STOP
> slapd"
> then ldapsearch will terminate after TIMEOUT seconds and it will return
> the
> number of records that it got so far and exit with return code 0 and not
> error
> message. I'd expect that after TIMEOUT occuring that we get a warning and
> a
> return code != 0
libldap's ldap_result() sets ld_errno to LDAP_TIMEOUT but returns 0, so
ldapsearch (and all tools) are fooled by not actually checking ld_errno
(actually, ldap_get_option(LDAP_OPT_RESULT_CODE)).
p.
12 years, 3 months
Re: (ITS#7012) Getting a core dump when TLSCertificateFile does not have an argument
by masarati@aero.polimi.it
> I don't remember any particular reason why the argument count was omitted
> here. Looking back over release 2.2 I don't see any special provision for
> multiple arguments. I.e., it doesn't look like we need to accomodate
> longer
> argument lists here. And I don't see why we would want to NULL out any
> existing settings. Sounds like we should just require argc == 2.
Fixed in master, passes all tests for me. BTW, the original poster's
address no longer exists, so I do not expect feedback.
p.
12 years, 3 months
Re: (ITS#7012) Getting a core dump when TLSCertificateFile does not have an argument
by hyc@symas.com
masarati(a)aero.polimi.it wrote:
>> No, thanks. The problem is that these specific statements do not
>> prescribe a fixed number of arguments. Moreover, the function that uses
>> the value resets the field when passed a NULL argument. If this behavior
>> needs to be preserved, I have the right fix handy. Otherwise it might
>> need more work.
>
> To be more specific: slapd's TLS configuration is registered without
> enforcing a specific number of arguments. This check is delegated to the
> underlying calls to ldap_pvt_tls_set_option() performed by
> config_tls_option(). This poses two problems:
>
> - since the argument of these parameters is ARG_STRING, if no arg is
> passed then ch_strdup() fails
>
> - fixing this (by skipping ch_strdup() if argc == 1, for example) results
> in calling ldap_pvt_tls_set_option with a NULL value, which is a perfectly
> legitimate value (it means: clear any existing value), but it may not be
> appropriate in this context.
>
> Please advise whether the right fix is skip ch_strdup(), or enforcing a
> requirement for argc == 2 for TLS-related fields.
I don't remember any particular reason why the argument count was omitted
here. Looking back over release 2.2 I don't see any special provision for
multiple arguments. I.e., it doesn't look like we need to accomodate longer
argument lists here. And I don't see why we would want to NULL out any
existing settings. Sounds like we should just require argc == 2.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 3 months
Re: (ITS#7012) Getting a core dump when TLSCertificateFile does not have an argument
by masarati@aero.polimi.it
> No, thanks. The problem is that these specific statements do not
> prescribe a fixed number of arguments. Moreover, the function that uses
> the value resets the field when passed a NULL argument. If this behavior
> needs to be preserved, I have the right fix handy. Otherwise it might
> need more work.
To be more specific: slapd's TLS configuration is registered without
enforcing a specific number of arguments. This check is delegated to the
underlying calls to ldap_pvt_tls_set_option() performed by
config_tls_option(). This poses two problems:
- since the argument of these parameters is ARG_STRING, if no arg is
passed then ch_strdup() fails
- fixing this (by skipping ch_strdup() if argc == 1, for example) results
in calling ldap_pvt_tls_set_option with a NULL value, which is a perfectly
legitimate value (it means: clear any existing value), but it may not be
appropriate in this context.
Please advise whether the right fix is skip ch_strdup(), or enforcing a
requirement for argc == 2 for TLS-related fields.
p.
12 years, 3 months
Re: (ITS#6339) ldapsearch -V doesn't exist after version info
by matheus.morais@gmail.com
--00163683235cdfe3c004aa1933e0
Content-Type: text/plain; charset=ISO-8859-1
This seems to be a little old but I had attached the patch to close this
issue and now I realize that I should provide it in a Uniform Resource
Locator (URL) just as http://www.openldap.org/devel/contributing.html
explains.
So here it goes:
http://xsun.eti.br/openldap/ldapsearch1_man_page.patch
Sorry for this mistake.
Thanks.
Matheus Morais
On Tue, Aug 31, 2010 at 1:44 AM, Matheus Morais <matheus.morais(a)gmail.com>wrote:
> Hi there,
>
> <quote> That's... bizarre. Even slapd doesn't behave that way. Nor any
> other program comes immediately to mind. </quote>
>
> Even sounds like an strange behave, as Quanah said, this information should
> be included on ldapsearch man page IMHO.
>
> I believe that the following patch could close this BUG:
>
> --- openldap/doc/man/man1/ldapsearch.1.orig 2010-08-31
> 01:25:23.000000000 -0300
> +++ openldap/doc/man/man1/ldapsearch.1 2010-08-31 01:37:50.000000000
> -0300
> @@ -7,6 +7,8 @@
> .SH SYNOPSIS
> .B ldapsearch
> [\c
> +.BR \-V [ V ]]
> +[\c
> .BR \-n ]
> [\c
> .BR \-c ]
> @@ -107,6 +109,11 @@
> Option \fI\-L\fP controls the format of the output.
> .SH OPTIONS
> .TP
> +.BR \-V [ V ]
> +Prints the ldapsearch version and proceeds with the search.
> +.B \-VV
> +Prints the ldapsearch version and quit.
> +.TP
> .B \-n
> Show what would be done, but don't actually perform the search. Useful
> for
> debugging in conjunction with \fB\-v\fP.
>
> Please review it.
>
> Thanks,
>
> Matheus Morais
>
--00163683235cdfe3c004aa1933e0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
This seems to be a little old but I had attached the patch to close this is=
sue and now I realize that I should provide it in a Uniform Resource Locato=
r (URL) just as=A0<meta http-equiv=3D"content-type" content=3D"text/html; c=
harset=3Dutf-8"><a href=3D"http://www.openldap.org/devel/contributing.html"=
>http://www.openldap.org/devel/contributing.html</a>=A0explains.<div>
<br></div><div>So here it goes:</div><div><br></div><div><a href=3D"http://=
xsun.eti.br/openldap/ldapsearch1_man_page.patch">http://xsun.eti.br/openlda=
p/ldapsearch1_man_page.patch</a></div><div><br></div><div>Sorry for this mi=
stake.</div>
<div><br></div><div>Thanks.</div><div>Matheus Morais</div><div><br><div cla=
ss=3D"gmail_quote">On Tue, Aug 31, 2010 at 1:44 AM, Matheus Morais <span di=
r=3D"ltr"><<a href=3D"mailto:matheus.morais@gmail.com">matheus.morais@gm=
ail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">Hi there,<br><br><quote> That's..=
. bizarre. Even slapd doesn't behave that way. Nor any other program =
comes immediately to mind. </quote><br>
<br>Even sounds like an strange behave, as Quanah said, this information sh=
ould be included on ldapsearch man page IMHO.<br>
<br>I believe that the following patch could close this BUG:<br><br>--- ope=
nldap/doc/man/man1/ldapsearch.1.orig=A0=A0=A0 2010-08-31 01:25:23.000000000=
-0300<br>+++ openldap/doc/man/man1/ldapsearch.1=A0=A0=A0 2010-08-31 01:37:=
50.000000000 -0300<br>
@@ -7,6 +7,8 @@<br>=A0.SH SYNOPSIS<br>=A0.B ldapsearch<br>=A0[\c<br>+.BR \-=
V [ V ]]<br>+[\c<br>=A0.BR \-n ]<br>=A0[\c<br>=A0.BR \-c ]<br>@@ -107,6 +10=
9,11 @@<br>=A0Option \fI\-L\fP controls the format of the output.<br>=A0.SH=
OPTIONS<br>
=A0.TP<br>+.BR \-V [ V ]<br>+Prints the ldapsearch version and proceeds wit=
h the search.<br>+.B \-VV<br>+Prints the ldapsearch version and quit.<br>+.=
TP<br>=A0.B \-n<br>=A0Show what would be done, but don't actually perfo=
rm the search.=A0 Useful for<br>
=A0debugging in conjunction with \fB\-v\fP.<br><br>Please review it.<br><br=
>Thanks,<br><font color=3D"#888888"><br>Matheus Morais<br>
</font></blockquote></div><br></div>
--00163683235cdfe3c004aa1933e0--
12 years, 3 months
Re: (ITS#7012) Getting a core dump when TLSCertificateFile does not have an argument
by masarati@aero.polimi.it
> Full_Name: Ashish Gawarikar
> Version: 2.4.23
> OS: Redhat 5.6
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (66.253.98.197)
>
>
> In my slapd.conf file:
> ...
> TLSCertificateFile
> TLSCertificateKeyFile
> ...
>
> If I have the above, I get a core dump, with the error:
> slapd: ch_malloc.c:123: ch_strdup: Assertion `0' failed.
>
>
> Let me know if you need the core file.
No, thanks. The problem is that these specific statements do not
prescribe a fixed number of arguments. Moreover, the function that uses
the value resets the field when passed a NULL argument. If this behavior
needs to be preserved, I have the right fix handy. Otherwise it might
need more work.
p.
12 years, 3 months