i made the test
look's good
thank's
Regard's=20
Olivier
________________________________________
De : Howard Chu [hyc(a)symas.com]
Date d'envoi : dimanche 15 novembre 2009 19:16
=C0 : CHIROSSEL Olivier
Cc : openldap-its(a)openldap.org
Objet : Re: RE : (ITS#6367) syncprov ... changed by peer, ignored
CHIROSSEL Olivier wrote:
> sorry for this
>
> the url is ok now
Thanks. This is now fixed in HEAD.
>
> Cdt,
>
> Olivier
> ________________________________________
> De : Howard Chu [hyc(a)symas.com]
> Date d'envoi : vendredi 13 novembre 2009 23:33
> =C0 : CHIROSSEL Olivier
> Cc : openldap-its(a)openldap.org
> Objet : Re: (ITS#6367) syncprov ... changed by peer, ignored
>
> olivier.chirossel(a)sfr.com wrote:
>> Full_Name: olivier chirossel
>> Version: 2.4.17 and 2.4.19
>> OS: linux
>> URL: http://86.64.145.174:8080/
>> Submission from: (NULL) (62.39.9.251)
>>
>>
>> in refreshend persist mode, the replication is incorrect for an entry wh=
ich be
>> delete/add after master restart and before the reconnection of the slave=
.
>
>> 2) master set up
>>
>> on /etc/openldap tar xvf slapd_master.tar (get on the url )
>
> The URL you provided always times out for me, so I've been unable to set =
up
> this test.
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Yeah, the example should have used groupOfURLs instead of groupOfNames. Notice
that "member" is not a valid attribute in the groupOfURLs class: it can not be
used to store static members, only dynamic references.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
mike(a)flyn.org wrote:
> Followup 4 states that slapd did not initially crash when using "threads
> 1" and no indexes. In this case, slapd did eventually crash as before.
I have removed the two asserts you previously reported; please try the current
code in CVS HEAD.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Jan Zelený wrote:
> Dne čtvrtek 24 září 2009 22:19:40 Howard Chu napsal(a):
>> jzeleny(a)redhat.com wrote:
>>> Full_Name: Jan Zeleny
>>> Version: 2.4.18
>>> OS: Fedora 11
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (62.40.79.66)
>>>
>> I'm unable to reproduce this using slapd on a debian x86-64 system, whether
>> on the local LAN or from 13 hops away. I've also used the tcp-buffer
>> option to set a minimum sized socket buffer and still could not duplicate
>> the problem. You will need to provide more explicit information on how to
>> reproduce this issue. Perhaps providing a set of CA/server certs will also
>> be necessary.
> I'm not sure I have much more explicit information for you. I'm sending
> certificate in attachment. It's a self signed testing certificate I generated on
> my system. I'm also sending you slapd.conf with relevant information and CA
> bundle file. If you need anything else, just let me know.
>
> Just for complete information:
> I tried slapd on Fedora 12 and RHEL 5.3 (x86_64) and on Ubuntu 9.04 (i386). On
> each system I used different self signed certificate. In both cases attached
> slapd.conf file was used. To reproduce error, I just started the slapd service
> (slapd -h 'ldaps:///' -u ldap) with given config file and connected to it. When
> I tried to connect with openssl s_client -connect fedora12-64, I received this
> output (and then freeze):
>
> CONNECTED(00000003)
> depth=0 /C=CZ/ST=Moravia/L=Brno/O=Red Hat Czech
> s.r.o./OU=Engineering/CN=fedora12-64/emailAddress=jzeleny(a)redhat.com
> verify error:num=18:self signed certificate
> verify return:1
> depth=0 /C=CZ/ST=Moravia/L=Brno/O=Red Hat Czech
> s.r.o./OU=Engineering/CN=fedora12-64/emailAddress=jzeleny(a)redhat.com
> verify return:1
>
>
>> Please note that the bug report you reference (509230) gives inconsistent
>> information; it says that no hang occurs with -d2, but that hangs occur
>> with no diagnostics, even with -d -1. Obviously -d -1 includes -d 2, so:
>> does it hang, or not, with -d -1?
>
> I believe what is stated there is that hangs don't occur with -d2, but they do
> with -d1 (not -d -1). I can also confirm this behaviour, that with -d1 hangs
> occur, but with -d2 they don't. (or at least I didn't encounter them during my
> testing).
>
> Hopefully I provided some useful information.
Thanks, that helped, a fix is now in CVS HEAD.
I should point out that the configuration used to reproduce this problem is
quite a poor one. As the OpenLDAP Admin Guide clearly states, your server
should only be configured with the CA certs for which it will accept client
certs. Your ca-bundle.crt file is 670KB and loaded with a lot of CAs that are
irrelevant; it's when slapd sends the client its list of acceptable CAs that
the connection was getting jammed.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
hyc(a)symas.com wrote:
> hyc(a)symas.com wrote:
>> michael(a)stroeder.com wrote:
>>> Download testrun/ here:
>>>
>>> http://www.stroeder.com/temp/openldap/its6325-test054-testrun.tar.gz
>> It's certainly a mystery. The *.flt shows that an entry is missing on the
>> slave. The slapd.1.log shows that the provider sent the entry. The slapd.4.log
>> shows that the consumer received the entry and ignored it. (See slapd.4.log
>> line 3307-3313. Compare with the previously received entry, lines 3161-3169.)
>>
>> The most puzzling part is that every code path in the consumer that rejects an
>> entry logs an error message, and there is no error message in the log file.
>> Without any means to reproduce this there's not much we can do. Setting a
>> higher debug level might be useful, but any error messages in this path should
>> have shown up regardless.
>
> The same problem is in your ITS#6126 logs. The entry was received on the
> consumer but skipped without any error message.
>
> I see now, the entry was skipped because its CSN was too old. (And that CSN
> too old message is only logged with SYNC debug is enabled.) This should be
> fixed by the patch for ITS#6346.
>
> It was also suggested that we should only reject mods if their CSN is actually
> older than the target entry's CSN. That's still a possibility if the current
> patch is insufficient.
These ITS were filed based on failed test runs on my old Pentium III Mobile
1,8 GHz laptop (now broken). I always suspected that it might be something
others won't see because their hardware is faster. Maybe it would be good to
run the test suite on really slow systems from time to time.
Ciao, Michael.
hyc(a)symas.com wrote:
> michael(a)stroeder.com wrote:
>> Download testrun/ here:
>>
>> http://www.stroeder.com/temp/openldap/its6325-test054-testrun.tar.gz
>
> It's certainly a mystery. The *.flt shows that an entry is missing on the
> slave. The slapd.1.log shows that the provider sent the entry. The slapd.4.log
> shows that the consumer received the entry and ignored it. (See slapd.4.log
> line 3307-3313. Compare with the previously received entry, lines 3161-3169.)
>
> The most puzzling part is that every code path in the consumer that rejects an
> entry logs an error message, and there is no error message in the log file.
> Without any means to reproduce this there's not much we can do. Setting a
> higher debug level might be useful, but any error messages in this path should
> have shown up regardless.
The same problem is in your ITS#6126 logs. The entry was received on the
consumer but skipped without any error message.
I see now, the entry was skipped because its CSN was too old. (And that CSN
too old message is only logged with SYNC debug is enabled.) This should be
fixed by the patch for ITS#6346.
It was also suggested that we should only reject mods if their CSN is actually
older than the target entry's CSN. That's still a possibility if the current
patch is insufficient.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
joacim.breiler(a)hgo.se wrote:
> Thanks for your fast replies! The 'make install STRIP=""' did the trick.
>
> I ran the server for about a week with no segfaults, then I decided that
> I couldn't wait for it any longer. So I connected to the server using an
> LDAP browser, and then after about ten minutes it segfaulted. So to
> reproduce I need one connection that is reading/updating/creating
> entries. And one connection that does an occasional read, otherwise the
> server will keep on running.
>
> The traceback from gdb gives:
This trace looks like the problem fixed in ITS#6335. The fix is in CVS HEAD
and RE24 (2.4.20 pre-release).
>
> 0x00007f96c3fc00ad in syncprov_op_mod (op=0x7f9688000ac0, rs=0x44688c80)
> at syncprov.c:1970
> 1970 for ( m2 = mt->mt_mods; m2->mi_next != mi;
> (gdb) where
> #0 0x00007f96c3fc00ad in syncprov_op_mod (op=0x7f9688000ac0,
> rs=0x44688c80) at syncprov.c:1970
> #1 0x00000000004c438a in overlay_op_walk (op=0x7f9688000ac0,
> rs=0x44688c80, which=op_modify, oi=0x12293c0, on=0x12295a0) at
> backover.c:659
> #2 0x00000000004c4667 in over_op_func (op=0x7f9688000ac0,
> rs=0x44688c80, which=op_modify) at backover.c:721
> #3 0x00000000004c47ac in over_op_modify (op=0x7f9688000ac0,
> rs=0x44688c80) at backover.c:760
> #4 0x000000000045bb21 in fe_op_modify (op=0x7f9688000ac0,
> rs=0x44688c80) at modify.c:301
> #5 0x000000000045b430 in do_modify (op=0x7f9688000ac0, rs=0x44688c80)
> at modify.c:175
> #6 0x000000000043c3ec in connection_operation (ctx=0x44688de0,
> arg_v=0x7f9688000ac0) at connection.c:1123
> #7 0x000000000043c975 in connection_read_thread (ctx=0x44688de0,
> argv=0x17) at connection.c:1259
> #8 0x0000000000525193 in ldap_int_thread_pool_wrapper (xpool=0x1190290)
> at tpool.c:685
> #9 0x00007f96c49613ea in start_thread () from /lib/libpthread.so.0
> #10 0x00007f96c44b9cbd in clone () from /lib/libc.so.6
> #11 0x0000000000000000 in ?? ()
>
> /J
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/