ITS#5375
by ecizaguirre＠gmv.com
Hi again Pierangelo and Quanah, I have tested the REL_ENG_2_4 version
with the fix under heavy worload and it seems to be working correctly so
the problem is fixed.
I'm still not able to compile 2.4.7 version with the fix applied.
Thanks for all and for this great software.
Cheers.
Eduardo
______________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
puede contener informacion clasificada por su emisor como confidencial
en el marco de su Sistema de Gestion de Seguridad de la
Informacion siendo para uso exclusivo del destinatario, quedando
prohibida su divulgacion copia o distribucion a terceros sin la
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje
erroneamente, se ruega lo notifique al remitente y proceda a su borrado.
Gracias por su colaboracion.
______________________
This message including any attachments may contain confidential
information, according to our Information Security Management System,
and intended solely for a specific individual to whom they are addressed.
Any unauthorised copy, disclosure or distribution of this message
is strictly forbidden. If you have received this transmission in error,
please notify the sender immediately and delete it.
______________________
15 years, 7 months
Re: (ITS#5383) olc* not present in subschema subentry
by michael＠stroeder.com
Howard Chu wrote:
> 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.
But then back-config SHOULD be hidden by DEVEL as well.
Frankly no-one will ever recognize when you change an OID arc. There
would be no issues with LDAP clients at all.
> Given that things in cn=config have pretty much stabilized, we probably
> ought to have migrated to a non-experimental arc for RE24.
Yes, please. Given that back-config is endorsed to be deployed in
production schema-aware LDAP clients must have the chance to retrieve
required information for processing the data.
> Note that the cn=config schema still relies on an unfinished spec
> (draft-chu-ldap-xordered) and that needs to be finalized still.
Whatever "unfinished" means. From the IETF point-of-view this is simply
a proprietary feature not documented anywhere in the IETF process so
far. From OpenLDAP project point-of-view it is yet another not fully
documented feature. This is not a real issue which should hold back
providing the schema to the client.
But if back-config is activated in normal builds then the interface
definition SHOULD be complete which includes providing the relevant
schema information in subschema subentry.
Ciao, Michael.
15 years, 7 months
(ITS#5385) contextCSN not propagated in cascading syncrepl refreshAndPersist
by bgmilne＠staff.telkomsa.net
Full_Name: Buchan Milne
Version: OPENLDAP_REL_ENG_2_3
OS: Linux 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (196.15.129.131)
One of our environments does cascading replication of one database (the master
for the other databases in this environment is a syncrepl refreshAndPersist
syncrepl client to a database in another environment).
We monitor the replication status of all our slaves by comparing the contextCSN
on each database with the contextCSN of the updateref, and I have noticed that
the contextCSN on the cascaded replicas is not being updated, even though the
entries have been replicated (according to logging at sync level on these
slaves). All other replication (including non-cascaded refreshAndPersist
databases) works fine. All the servers in question are currently on 2.3.40.
It seems that the issue can be reproduced with current REL_ENG_2_3, with a
slight modification to test019 (see patch below) to include the contextCSN in
the comparison, which will then fail as follows:
$ ./run test019
Running ./scripts/test019-syncreplication-cascade...
running defines.sh
Starting master slapd on TCP/IP port 9011...
Using ldapsearch to check that master slapd (pid=23363) is running...
Using ldapadd to create the context prefix entry in the master...
Starting R1 slave slapd on TCP/IP port 9012...
Using ldapsearch to check that R1 slave slapd (pid=23370) is running...
Starting R2 slave slapd on TCP/IP port 9013...
Using ldapsearch to check that R2 slave slapd (pid=23376) is running...
Starting P1 slave slapd on TCP/IP port 9014...
Using ldapsearch to check that P1 slave slapd (pid=23382) is running...
Starting P2 slave slapd on TCP/IP port 9015...
Using ldapsearch to check that P2 slave slapd (pid=23388) is running...
Starting P3 slave slapd on TCP/IP port 9016...
Using ldapsearch to check that P3 slave slapd (pid=23395) is running...
Using ldapadd to populate the master directory...
Waiting 25 seconds for syncrepl to receive changes...
Using ldapmodify to modify master directory...
Waiting 25 seconds for syncrepl to receive changes...
Using ldapsearch to read all the entries from the master...
Using ldapsearch to read all the entries from the R1 slave...
Using ldapsearch to read all the entries from the R2 slave...
Using ldapsearch to read all the entries from the P1 slave...
Using ldapsearch to read all the entries from the P2 slave...
Using ldapsearch to read all the entries from the P3 slave...
Filtering master ldapsearch results...
Filtering R1 slave ldapsearch results...
Filtering R2 slave ldapsearch results...
Filtering P1 slave ldapsearch results...
Filtering P2 slave ldapsearch results...
Filtering P3 slave ldapsearch results...
Comparing retrieved entries from master and R1 slave...
Comparing retrieved entries from master and R2 slave...
Comparing retrieved entries from master and P1 slave...
Comparing retrieved entries from master and P2 slave...
test failed - master and P2 slave databases differ
$ diff -u testrun/server{1,5}.flt
--- testrun/server1.flt 2008-02-18 12:00:52.000000000 +0200
+++ testrun/server5.flt 2008-02-18 12:00:52.000000000 +0200
@@ -108,7 +108,7 @@
postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US
telephoneNumber: +1 313 555 1817
associatedDomain: example.com
-contextCSN: 20080218100027Z#000002#00#000000
+contextCSN: 20080218100027Z#000000#00#000000
dn: cn=Gern Jensen,ou=Information Technology Division,ou=People,dc=example,dc=
com
Index: scripts/test019-syncreplication-cascade
===================================================================
RCS file: /repo/OpenLDAP/pkg/ldap/tests/scripts/test019-syncreplication-cascade,v
retrieving revision 1.13.2.7
diff -u -r1.13.2.7 test019-syncreplication-cascade
--- scripts/test019-syncreplication-cascade 11 Feb 2008 23:24:28 -0000
1.13.2.7
+++ scripts/test019-syncreplication-cascade 18 Feb 2008 10:02:51 -0000
@@ -331,7 +331,7 @@
echo "Using ldapsearch to read all the entries from the master..."
$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT1 \
- 'objectclass=*' > $MASTEROUT 2>&1
+ 'objectclass=*' '*' contextCSN > $MASTEROUT 2>&1
RC=$?
if test $RC != 0 ; then
@@ -342,7 +342,7 @@
echo "Using ldapsearch to read all the entries from the R1 slave..."
$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT2 \
- 'objectclass=*' > $SERVER2OUT 2>&1
+ 'objectclass=*' '*' contextCSN > $SERVER2OUT 2>&1
RC=$?
if test $RC != 0 ; then
@@ -353,7 +353,7 @@
echo "Using ldapsearch to read all the entries from the R2 slave..."
$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT3 \
- 'objectclass=*' > $SERVER3OUT 2>&1
+ 'objectclass=*' '*' contextCSN > $SERVER3OUT 2>&1
RC=$?
if test $RC != 0 ; then
@@ -364,7 +364,7 @@
echo "Using ldapsearch to read all the entries from the P1 slave..."
$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT4 \
- 'objectclass=*' > $SERVER4OUT 2>&1
+ 'objectclass=*' '*' contextCSN > $SERVER4OUT 2>&1
RC=$?
if test $RC != 0 ; then
@@ -375,7 +375,7 @@
echo "Using ldapsearch to read all the entries from the P2 slave..."
$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT5 \
- 'objectclass=*' > $SERVER5OUT 2>&1
+ 'objectclass=*' '*' contextCSN > $SERVER5OUT 2>&1
RC=$?
if test $RC != 0 ; then
@@ -386,7 +386,7 @@
echo "Using ldapsearch to read all the entries from the P3 slave..."
$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT6 \
- 'objectclass=*' > $SERVER6OUT 2>&1
+ 'objectclass=*' '*' contextCSN > $SERVER6OUT 2>&1
RC=$?
if test $RC != 0 ; then
15 years, 7 months
Re: [JunkMail] Re: (ITS#5383) olc* not present in subschema subentry
by hyc＠symas.com
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/
15 years, 7 months
(ITS#5384) access control: "attrs" field handled incorrectly in URI form of sets
by ando＠sys-net.it
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.
15 years, 7 months
Re: (ITS#5383) olc* not present in subschema subentry
by hyc＠symas.com
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/
15 years, 7 months
(ITS#5383) olc* not present in subschema subentry
by michael＠stroeder.com
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...
15 years, 7 months
Re: (ITS#5361) cert verification failures with GnuTLS and DNS subjectAltName
by hyc＠symas.com
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=4cc3c6b6e...
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/
15 years, 7 months
