[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: delta-syncrepl and mirrormode problem (2.4.29 and 2.4.30)/ slapadd Usage
Hello,
now mirrormode with delta-syncrepl seems to work with windows.
The problem was that I added the initial database with slapadd without the
-w option. (slapadd on master 1 and empty master 2)
Is this a bug or does it work as designed?
If it works as designed maybe the manualpage for slapadd should be more
clearly that when you work with replication you always have to use the -w
option.
Wouldn't it be helpfull if slapadd internally always use the -w option or
are there cases in which this option could be harmfull?
What happens if i use -w and have no replication configured?
Regards,
Frank
openldap-technical-bounces@OpenLDAP.org schrieb am 02.03.2012 10:47:50:
> Von: frank.offermanns@caseris.de
> An: Howard Chu <hyc@symas.com>
> Kopie: openldap-technical@openldap.org
> Datum: 02.03.2012 11:01
> Betreff: Re: delta-syncrepl and mirrormode problem (2.4.29 and 2.4.30)
> Gesendet von: openldap-technical-bounces@OpenLDAP.org
>
> > Sounds like it's having problems with MSYS's fake pathnames, or your
> MSYS is
> > not mounting filesystems correctly. If you can't fix that, you may be
> able to
> > workaround this by overriding the test directory using e.g.
> > export USER_TESTDIR=C:/msys/1.0/openldap-2.4.30/tests/testrun
>
> Thanks this works.
>
> > In the tests directory:
> > ./run test063
>
> Doing this I get the following:
> "offermanns@CAS-WS091201 /openldap-2.4.30/tests
> $ env SLAPD_DEBUG=1 ./run test063
> Cleaning up test run directory leftover from previous run.
> Running ./scripts/test063-delta-multimaster for hdb...
> running defines.sh
> Initializing server configurations...
> ./scripts/test063-delta-multimaster: line 116: test: =: unary operator
> expected
> Starting server 1 on TCP/IP port 9011...
> Using ldapsearch to check that server 1 is running...
> Using ldapadd for context on server 1...
> ldapadd failed for server 1 database (34)!"
>
> In line 116 @ if test $INDEXDB = indexdb ; then
> when I echo $INDEXDB it is empty.
>
> Here a extract from test.out, I even changed $ABS_SCHEMADIR in the
> 063.script to a permanent path, but this does not seem to be the problem
>
> <Original>
> "ldif_read_record: include
> file:///openldap-2.4.30/tests/./schema/core.ldif failed"
>
> <Replaced>
> "ldif_write_entry: wrote entry "cn=schema,cn=config"
> ldif_read_record: include
> c:/msys/1.0/openldap-2.4.30/tests/schema/core.ldif failed
> slapadd shutdown: initiated
> slapadd destroy: freeing system resources.
> ldap_bind: Invalid DN syntax (34)
> additional info: invalid DN"
>
>
> And here is a extract of the slapd.log
> "backend_startup_one: starting "cn=config"
> config_back_db_open
> slapd starting
> slap_listener_activate(2):
> >>> slap_listener(ldap://localhost:9011/)
> connection_get(3): got connid=1000
> connection_read(3): checking for input on id=1000
> ber_get_next
> ber_get_next: tag 0x30 len 12 contents:
> op tag 0x60, time 1330680554
> ber_get_next
> conn=1000 op=0 do_bind
> ber_scanf fmt ({imt) ber:
> ber_scanf fmt (m}) ber:
> >>> dnPrettyNormal: <>
> <<< dnPrettyNormal: <>, <>
> do_bind: version=3 dn="" method=128
> send_ldap_result: conn=1000 op=0 p=3
> send_ldap_response: msgid=1 tag=97 err=0
> ber_flush2: 14 bytes to sd 1768
> do_bind: v3 anonymous bind
> connection_get(3): got connid=1000
> connection_read(3): checking for input on id=1000
> ber_get_next
> ber_get_next: tag 0x30 len 37 contents:
> op tag 0x63, time 1330680554
> ber_get_next
> conn=1000 op=1 do_search
> ber_scanf fmt ({miiiib) ber:
> >>> dnPrettyNormal: <>
> <<< dnPrettyNormal: <>, <>
> ber_scanf fmt (m) ber:
> ber_scanf fmt ({M}}) ber:
> => send_search_entry: conn 1000 dn=""
> ber_flush2: 50 bytes to sd 1768
> <= send_search_entry: conn 1000 exit.
> send_ldap_result: conn=1000 op=1 p=3
> send_ldap_response: msgid=2 tag=101 err=0
> ber_flush2: 14 bytes to sd 1768
> connection_get(3): got connid=1000
> connection_read(3): checking for input on id=1000
> ber_get_next
> ber_get_next: tag 0x30 len 5 contents:
> op tag 0x42, time 1330680554
> ber_get_next
> ber_get_next on fd 3 failed errno=0 (unknown WSA error)
> conn=1000 op=2 do_unbind
> connection_close: conn=1000 sd=3
> slap_listener_activate(2):
> >>> slap_listener(ldap://localhost:9011/)
> connection_get(3): got connid=1001
> connection_read(3): checking for input on id=1001
> ber_get_next
> ber_get_next: tag 0x30 len 46 contents:
> op tag 0x60, time 1330680554
> ber_get_next
> conn=1001 op=0 do_bind
> ber_scanf fmt ({imt) ber:
> ber_scanf fmt (m}) ber:
> >>> dnPrettyNormal: <cn=Manager,dc=example,dc=com>
> conn=1001 op=0 do_bind: invalid dn (cn=Manager,dc=example,dc=com)"
> send_ldap_result: conn=1001 op=0 p=3
> send_ldap_response: msgid=1 tag=97 err=34
> ber_flush2: 24 bytes to sd 1768
> connection_get(3): got connid=1001
> connection_read(3): checking for input on id=1001
> ber_get_next
>
> So is there a problem with cn=Manager,dc=example,dc=com?
>
>