Michael Ströder wrote:
> Howard Chu wrote:
>> In RE24 the config schema are only exposed for DEVEL builds.
>
> Why that? Especially why was it changed compared to RE23?
They were probably exposed in RE23 by mistake. The config schema uses an OID
from the OpenLDAP Experimental arc and the Project's policy is not to publish
experimental OIDs for general use, only for Development.
Given that things in cn=config have pretty much stabilized, we probably ought
to have migrated to a non-experimental arc for RE24. I suppose we can take
this ITS as a reminder to do that. Note that the cn=config schema still relies
on an unfinished spec (draft-chu-ldap-xordered) and that needs to be finalized
still.
--
-- 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/
Full_Name: Pierangelo Masarati
Version: HEAD/re24/re23
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.72.89.40)
Submitted by: ando
There seems to be an error in (optional) attribute handling in URIs used in
sets.
Background: in OpenLDAP 2.3 sets were enhanced by allowing to dereference URIs
by performing the corresponding internal search; the syntax was:
[<uri>]/<attr>
returning the value of <attr> after searching for <uri>; if optional attrs were
specified in the URI, their values could be added to the result set; so
[ldap:///o=suffix?cn,sn?sub]/uid
would have collected the "cn", the "sn" and the "uid" of entries matching the
URI.
Well, this is broken: it seems to only work as expected when no optional attrs
are given. A fix for HEAD is about to come.
p.
Howard Chu wrote:
>
> In RE24 the config schema are only exposed for DEVEL builds.
Why that? Especially why was it changed compared to RE23?
Ciao, Michael.
michael(a)stroeder.com wrote:
> Full_Name: Michael Ströder
> Version: RE24
> OS: OpenSUSE Linux 10.3
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (84.163.120.38)
>
>
> IMO a show-stopper for 2.4.8!
>
> The schema elements for back-config (olc*) are not present/readable in the
> subschema subentry. They are present with the very same config in RE23. Note
> that the schema elements have to be retrieved by schema-aware clients for doing
> the right thing...
In RE24 the config schema are only exposed for DEVEL builds. This is not a
regression from 2.4.7 or any other 2.4 releases, so this is certainly not a
show-stopper.
--
-- 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/
Full_Name: Michael Ströder
Version: RE24
OS: OpenSUSE Linux 10.3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (84.163.120.38)
IMO a show-stopper for 2.4.8!
The schema elements for back-config (olc*) are not present/readable in the
subschema subentry. They are present with the very same config in RE23. Note
that the schema elements have to be retrieved by schema-aware clients for doing
the right thing...
A fix has been committed in the GnuTLS code base.
-------- Original Message --------
Subject: Re: (ITS#5361) cert verification failures with GnuTLS and DNS
subjectAltName
Date: Fri, 15 Feb 2008 23:11:32 +0200
From: Nikos Mavrogiannopoulos <nmav(a)gnutls.org>
To: Howard Chu <hyc(a)symas.com>
CC: Joe Orton <joe(a)manyfish.co.uk>, gnutls-devel(a)gnu.org
References: <200802100917.m1A9HkSb015171(a)boole.openldap.org>
<200802152216.25025.nmav(a)gnutls.org> <47B5F843.8080503(a)symas.com>
On Friday 15 February 2008, Howard Chu wrote:
> > Anyway, does the attached
> > patch solve your problem?
>
> Not really. It still returns a size one byte larger than expected for the
> strings. Even in languages where NUL-terminated strings are the norm, the
> terminating byte is not included in the length.
>
> The point is, we expect this API to return exactly the data that was in the
> certificate. If the caller wants to treat the data as a string, they can
> NUL-terminate it themselves. The manpage only says that the data will be
> returned, it does not say that it will be altered in any way.
Actually you are right. The return value shouldn't be increased (this also
happens in the other similar functions). I've corrected the patch and
commited at:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=4cc3c6b6ed0…
regards,
Nikos
--
-- 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/
A similar bug has been reported in the debian bug tracking system, with
some debugging information and reproducibility steps.
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465915>
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
fabio.ubaldi(a)coritel.it wrote:
> Full_Name: Fabio Ubaldi
> Version: 2.3.27
> OS: Linux kernel 2.6.18
> URL:
> Submission from: (NULL) (194.237.142.11)
> It seems that the error happens only if the two process runs
> simultaneously (I use a dual core PC). Thinking of a race condition
> error , I used the libldap_r library to build process, but the error
> still remains.
Processes are completely separate (unless you happen to be using explicitly
shared memory). It's pretty much impossible for any code in libldap to be
directly responsible for the behavior you're reporting. If you're using a new
socket for each request and not closing them when done, it's likely that
you're running out of free ports in your system.
> The openldap version is 2.3.27 both for slapd servers and the libraries.
>
> Have anyone encountered a similar error ?
>
> Thanks in advance for the reply
There is no indication of a bug in OpenLDAP Software here. This ITS will be
closed. Since it's most likely an issue in how you coded your application, you
can followup to the OpenLDAP-software mailing list if you want to discuss this
further.
--
-- 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/
I note that the patch appears to be incomplete. No gssapi.c included.
-- Kurt
On Feb 14, 2008, at 8:26 PM, kurt(a)openldap.org wrote:
> You've only included one of the two required statements. You need
> also need to include either a copyright + license statement, or a
> public domain release statement. -- Kurt
>
> On Feb 14, 2008, at 9:12 AM, mimir(a)samba.org wrote:
>
>>
>> --OgqxwSJOaUobr8KG
>> Content-Type: text/plain; charset=iso-8859-2
>> Content-Disposition: inline
>> Content-Transfer-Encoding: quoted-printable
>>
>> Kurt,
>>
>> On Mon, Feb 11, 2008 at 09:06:19AM -0800, Kurt Zeilenga wrote:
>>>> Full_Name: Rafal Szczesniak
>>>> Version: HEAD
>>>> OS: GNU/Linux
>>>> URL: http://www.samba.org/~mimir/gssapi-head.diff
>>>
>>> The submitted patch file does not contain (at the top of the file,
>>> not =
>> =20
>>> as part of the diffs) the required notices. Please review=20
>>> http://www.openldap.org/devel/contributing.html and insert
>>> appropriate=20
>>> notices. Also, please don't include in the diffs derived files
>>> (e.g.,=20
>>> configure).
>>
>> I've updated the patch file with necessary changes. Please take a
>> look
>> if it's fine now.
>>
>>
>> cheers,
>> --=20
>> Rafal Szczesniak
>> Samba Team member http://www.samba.org
>> Likewise Software http://www.likewisesoftware.com
>>
>>
>> --OgqxwSJOaUobr8KG
>> Content-Type: application/pgp-signature; name="signature.asc"
>> Content-Description: Digital signature
>> Content-Disposition: inline
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.6 (GNU/Linux)
>>
>> iD8DBQFHtJLCHvdfyv3qiKkRArL0AJ9ZazJE3LUduZb3A8rz21KheW/EYQCfQt8z
>> F7AnIDF5EkJ7ssDwHStryEo=
>> =tIVf
>> -----END PGP SIGNATURE-----
>>
>> --OgqxwSJOaUobr8KG--
>>
>>
>
>