[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Corrupt LDAP DB ... ans 2.3.11 syncrepl

Hiya,

I thought the syncprov overlay was enabled on the default configure options:

    --enable-syncprov     Syncrepl Provider overlay no|yes|mod [yes]

When slapd configured overlays it looks like it should bork if you try to configure an overlay when it
does not exist.

Anyways, I re-configured with --enable-modules and --enable- overlays=mod and added the module directive
which now all works, 2.3.11 is syncreplicating and all is well:-)

However, the configure does seem to indicate that the syncrepl overlay is enabled by default. I tried configuring it
with --enable-overlays=mod but without --enable-modules and although it configured OK and built OK the modules
did not appear - perhaps a warning would be good or a implicit -- enable-modules when you set a overlay to be built
as a module would be good.

I currently syncrepl every 20 seconds, is this OK or will it break? Whap happens is a syncrepl takes longer than 20 seconds
to complete, will it block the next syncrepl until it completes?

Thanks folks,
Leigh Porter


On 27 Oct 2005, at 19:33, Buchan Milne wrote:

On Thursday 27 October 2005 20:02, Leigh Porter wrote:

Hiya,

Thanks for the input Buchan, here is the slapd.conf for the 2.3.11
syncrepl provider:

#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include         /usr/local/etc/openldap/schema/core.schema
include         /usr/local/etc/openldap/schema/cosine.schema
include         /usr/local/etc/openldap/schema/nis.schema
include         /usr/local/etc/openldap/schema/inetorgperson.schema
include         /usr/local/etc/openldap/schema/qmail.schema
include         /usr/local/etc/openldap/schema/openldap.schema

pidfile         /usr/local/var/run/slapd.pid
argsfile        /usr/local/var/run/slapd.args

access to * by * write

threads 10
loglevel 5
conn_max_pending 100


You don't load the syncprov plugin, so I'm assuming you compiled it in.



##################################################################### ##
# BDB database definitions
##################################################################### ##
database bdb
suffix "dc=ukbboss,dc=co,dc=uk"
rootdn "cn=Manager,dc=ukbboss,dc=co,dc=uk"
rootpw cheesetesting
directory /database/openldap/openldap-data

index   objectClass     eq
index mailMessageStore sub,eq,pres
index mailServices sub,eq,pres
index mailUsername sub,eq,pres
index mail sub,eq,pres
index cn,uid eq
index uidNumber eq
index gidNumber eq
index entryCSN eq
index entryUUID eq

sizelimit unlimited
cachesize   10000000


You have enough ram to cache 10 million entries?



overlay glue

#
# We are a sync provider
#
        overlay syncprov
        syncprov-checkpoint 1 1


That's probably checkpointing too often (but I haven't done too much testing
of these settings).


        syncprov-sessionlog 5000


Also note that slapd is quite sensitive to whitespace in slapd.conf. I would
remove any preceeding white space on the above 4 lines.



database        monitor
#
# THE END
# ver 4.5.6 27/10/2005 18:45 edited by leigh@ark.cheese.local

When I start the slave the debugging looks like it connects OK but does
not see anything to sync:


=>do_syncrep2
ldap_result ld 0x8222948 msgid -1
ldap_chkResponseList ld 0x8222948 msgid -1 all 0
ldap_chkResponseList returns ld 0x8222948 NULL
wait4msg ld 0x8222948 msgid -1 (infinite timeout)
wait4msg continue ld 0x8222948 msgid -1 all 0
** ld 0x8222948 Connections:
* host: 10.100.100.30  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Thu Oct 27 18:09:43 2005

** ld 0x8222948 Outstanding Requests:
 * msgid 2,  origid 2, status InProgress
   outstanding referrals 0, parent count 0
** ld 0x8222948 Response Queue:
   Empty
ldap_chkResponseList ld 0x8222948 msgid -1 all 0
ldap_chkResponseList returns ld 0x8222948 NULL
ldap_int_select
read1msg: ld 0x8222948 msgid -1 all 0
ber_get_next
ber_get_next: tag 0x30 len 591 contents:
read1msg: ld 0x8222948 msgid 2 message type search-entry
ber_scanf fmt ({xx) ber:
do_syncrep2: got search entry without control


I'm not sure (I haven't had to debug to this level), but it looks like
sync-repl isn't available (not sure if it should currently be advertised
though ..).


ldap_msgfree
ldap_free_request (origid 2, msgid 2)
ldap_free_connection 1 1
ldap_send_unbind
ber_flush: 7 bytes to sd 11
ldap_free_connection: actually freed

I posted the slave slapd.conf earlier,. but it all looks OK. Nothing odd
or errorish on the master debug output.
I'll try 2.3.9 and see what happens..


I would check that the suffix has a contextCSN:

$ ldapsearch -LLL -x -b dc=ukbboss,dc=co,dc=uk contextCSN

It should be newer than any entryCSN in your directory. If it isn't, the
consumer will think it is up-to-date.

Also, you may want to search as your syncrepl binddn just to be sure you're
getting what the syncrepl binddn should ...

2.3.11 does sync for me ... but not necessarily if I don't restart the slapd
after some additions (though I may have ommitted the -w to slapadd on the
initial add of some glue entries for my glue-together subordinate
backends ...).

Regards,
Buchan

--
Buchan Milne
ISP Systems Specialist
B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)