[389-devel] Please review: [Bug 531642] EntryUSN: RFE: a configuration option to make entryusn "global"

2010-08-26 Thread Noriko Hosoi



https://bugzilla.redhat.com/show_bug.cgi?id=531642

https://bugzilla.redhat.com/attachment.cgi?id=441366&action=diff
https://bugzilla.redhat.com/attachment.cgi?id=441366&action=edit

Fix description:
1. Introduced a config parameter nsslapd-entryusn-global: on|off to
   enable | disable the global mode.  By default, off.
   In the global mode, search on root dse returns "lastusn:"
   without the backend subtype (e.g., "lastusn;userroot:")
2. Added slapi_get_next_suffix_ext to mapping_tree.c, which visits
   children as well as siblings in the mapping tree.
   (Note: slapi_get_next_suffix does just siblings.)
3. import (ldif2db) adds "entryusn: 0" to every entry unless the
   entry already contains the entryusn attribute.
4. ldbm_back_delete, ldbm_back_modify, ldbm_back_modrdn: set
   ldap_result_code to pblock so that bepost plugin could see if
   the operation was successful or not.

See also http://directory.fedoraproject.org/wiki/Entry_USN#Global_mode

Thanks,
--noriko




smime.p7s
Description: S/MIME Cryptographic Signature
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: [389-devel] [389-users] Incremental Replication over SSL ( and startTLS) with simple bind crashes the latest version

2010-08-26 Thread Andrey Ivanov
2010/8/25 Rich Megginson 

> Andrey Ivanov wrote:
>
>>
>>
>> 2010/8/25 Rich Megginson mailto:rmegg...@redhat.com
>> >>
>>
>>
>>Andrey Ivanov wrote:
>>
>>I wanted to configure the replication over SSL (both with SSL
>>mechanism which was available in previous versions) and by TLS
>>using
>>simple bind (both in multimaster or single master-dedicated
>>consumer models).
>>
>>I've tried to configure it with command line and with the
>>console. The
>>configuration and the initial initialisation are ok/
>>
>>But  when i continue and try to make a change on a master the
>>consumer
>>server  crashes.  So the total replica initialisation is ok
>>but even a
>>single  incremental  update  crashes the consumer server. And
>>there is
>>nothing  helpful  in logs. I haven't tried the 1.2.6.rc7
>>version, i've
>>tried  the latest code version (as of today). Don't know if it
>>matters
>>(there  seem  to  be  a  lot  of coverity defects that have
>>been fixed
>>between rc7 and a1).
>>
>>Can you get a core file and a stack trace?
>>
>>  Rich, just as i thought, this crash happens only with today's snapshot of
>> 1.2.7.a1 version only. I've compiled 1.2.6.rc7 and the replication works
>> smoothly and without any problem. I didn't have a lot of time to generate a
>> stack trace because i was migrating our production servers. I thought the
>> latest build should be stable but it seems that the changes between 6rc7 and
>> 7a1 introduce some problems with incremental replication as well as with
>> apostrophs in DN (my second mail). So for now i will migrate to 1.2.6.rc7.
>> I'll test the a1 version later when i will have time...
>>
> Thanks for the confirmation.  Yeah, the 1.2.7 (master) is unstable right
> now.  There have been a lot of changes going in that haven't been fully
> tested with our test suite (we're also having to update the test suite).
>

I wanted to make a  debug build of the server to test the incremental
replication crash i've seen yesterday and used the following commands :
export CFLAGS="-g"
export CXXFLAGS="-g"
export USE_64=1
./configure --prefix=/Local/dirsrv --enable-debug --enable-autobind

Are these parameters correct? Is there any other way to generate the debug
info?

However the debug build i've obtained (from the stable 1.2.6.rc7) in this
way crashes during its startup if i activate USN plugin  with ldapmodify
just after setup-ds-admin, then stop-start:

dn: cn=USN,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on


Non-debug build does not crash, by the way... I think it's because of the
assertion being executed only in debug builds?


Here is the stack trace :

[r...@ldap-model Admin]#  gdb /Local/dirsrv/sbin/ns-slapd
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5_5.2)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /Local/dirsrv/sbin/ns-slapd...done.
(gdb) set follow-fork-mode child
(gdb) set arg -D /Local/dirsrv/etc/dirsrv/slapd-dmz -i
/Local/dirsrv/var/run/dirsrv/slapd-dmz.pid -w
/Local/dirsrv/var/run/dirsrv/slapd-dmz.startpid
(gdb) run
Starting program: /Local/dirsrv/sbin/ns-slapd -D
/Local/dirsrv/etc/dirsrv/slapd-dmz -i
/Local/dirsrv/var/run/dirsrv/slapd-dmz.pid -w
/Local/dirsrv/var/run/dirsrv/slapd-dmz.startpid
[Thread debugging using libthread_db enabled]
[New process 32401]
[Thread debugging using libthread_db enabled]
[New Thread 0x40a00940 (LWP 32402)]
[New Thread 0x41401940 (LWP 32403)]
[New Thread 0x41e02940 (LWP 32404)]
[New Thread 0x42803940 (LWP 32405)]
[New Thread 0x43204940 (LWP 32406)]
[New Thread 0x43c05940 (LWP 32407)]
[New Thread 0x44606940 (LWP 32408)]
[New Thread 0x45007940 (LWP 32409)]
[New Thread 0x45a08940 (LWP 32410)]

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x2bee5e00 (LWP 32401)]
0x00389d430265 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00389d430265 in raise () from /lib64/libc.so.6
#1  0x00389d431d10 in abort () from /lib64/libc.so.6
#2  0x2b21d61c in PR_Assert () from /usr/lib64/libnspr4.so
#3  0x2ab33655 in slapi_mods_add_one_element (smods=0x7fff9ee0)
at ldap/servers/slapd/modutil.c:178
#4  0x2ab336de in slapi_mods_insert_at (smods=0x7fff9ee0,
mod=0xacc100, pos=3) at ldap/servers/slapd/modutil.c:196
#5  0x2ab33974 in slapi_mods_add_ldapmod (smods=0x7fff9ee0,
mod=0xacc100) at ldap/servers/slapd/modutil.c:270
#6  0x2ab33aa2 in slapi_mods