On 18.08.2010 17:16, Rein Tollevik wrote:

On 08/18/2010 04:28 PM, Elmar Marschke wrote:

...

Here's the logfile of MASTER: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ===_BEGIN_CHANGES_WHILE_BOTH_UP_=== Aug 18 15:30:04 ldapmaster slapd[8017]: slap_queue_csn: queing 0x7f00f317b580 20100818133004.663851Z#000000#000#000000

Your ServerID setting is incorrect, and you are using the default ServerID=0 on both systems. The ServerID is included in the csn value, the second to last number (#000# here). Ensure that the ServerID URL is the exact hostname of the systems it runs on, or that slapd is able to select the correct sid based on its -h listener argument.

Start slapd with -d config and verify that both logs lines with differing SID= values.

Rein

Hi all,

thanks to your hints i think i got it working now :)

Several details had to be changed. Perhaps someone has similar problems, so in the following i give a detailed description what had to be done in my case. Everything was executed on two freshly out-of-the-box installed openSuSE 11.3 x86_64 with SuSE-shipped openldap 2.4.21.

First; according the inaccurate time on my testmachines: i deleted the openSuSE ntp.conf and additionally now i use other ntp servers as timesync source. Complete ntp.conf on ldapmaster and ldapslave now is: ----------------------------------------------------- server ptbtime1.ptb.de prefer server ptbtime2.ptb.de tinker panic 0 driftfile /var/lib/ntp/drift/ntp.drift

This results in less different offset values: --------------------------------------------- ldapmaster:/etc/openldap # ntpq -p; ssh ldapslave ntpq -p remote refid offset ======================================== *ptbtime1.ptb.de .PTB. -1.218 +ptbtime2.ptb.de .PTB. -1.305 remote refid offset ========================================== *ptbtime1.ptb.de .PTB. -0.381 +ptbtime2.ptb.de .PTB. 0.203 ldapmaster:/etc/openldap #

Second problem: the missing or wrong serverID in the csn values. To make clear what obviously helped i will describe how i create(d) my slapd.d/ online configuration. (My original slapd.conf was taken from the "openldap 2.4" book by Oliver Liebel & John Martin Ungar -- thanks Oliver :)! ------------------------------------------------------------ ldapmaster:/etc/openldap # slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/ hdb_db_open: database "dc=local,dc=site": db_open(/var/lib/ldap//id2entry.bdb) failed: No such file or directory (2). backend_startup_one (type=hdb, suffix="dc=local,dc=site"): bi_db_open failed! (2) slap_startup failed (test would succeed using the -u switch) ------------------------------------------------------------

The following rcldap start every time resulted in: -------------------------------------------------- ldapmaster:/etc/openldap # rcldap start Starting ldap-serverstartproc: exit status of parent of /usr/lib/openldap/slapd: 1

failed -------------------------------------

and in /var/log/messages was written: -------------------------------------- Aug 26 15:47:22 ldapmaster slapd[7805]: @(#) $OpenLDAP: slapd 2.4.21 (Jul 5 2010 13:35:22) $#012#011abuild@build16:/usr/src/packages/BUILD/openldap-2.4.21/servers/slapd Aug 26 15:47:22 ldapmaster slapd[7805]: olcSyncrepl: value #0: <olcSyncrepl> invalid URL Aug 26 15:47:22 ldapmaster slapd[7805]: config error processing olcDatabase={0}config,cn=config: <olcSyncrepl> invalid URL Aug 26 15:47:22 ldapmaster slapd[7805]: slapd stopped. Aug 26 15:47:22 ldapmaster slapd[7805]: connections_destroy: nothing to destroy.

I greped for "olcSyncrepl" in slapd.d: --------------------------------------- ldapmaster:/etc/openldap # grep -r olcSyncrepl slapd.d/ slapd.d/cn=config/cn=schema.ldif:olcAttributeTypes: ( OLcfgDbAt:0.11 NAME 'olcSyncrepl' EQUALITY caseIgnoreMatc slapd.d/cn=config/cn=schema.ldif: olcSizeLimit $ olcSyncUseSubentry $ olcSyncrepl $ olcTimeLimit $ olcUpdateDN slapd.d/cn=config/olcDatabase={0}config.ldif:olcSyncrepl: rid=003 provider=ldap://ldapmaster.local.site uri="" bindmethod=s slapd.d/cn=config/olcDatabase={0}config.ldif:olcSyncrepl: rid=004 provider=ldap://ldapslave.local.site uri="" bindmethod=si slapd.d/cn=config/olcDatabase={1}hdb.ldif:olcSyncrepl: rid=001 provider=ldap://ldapmaster.local.site uri="" bindmethod=s slapd.d/cn=config/olcDatabase={1}hdb.ldif:olcSyncrepl: rid=002 provider=ldap://ldapslave.local.site uri="" bindmethod=si ldapmaster:/etc/openldap #

Some internet research told me, that the empty uri="" should be the problem, and that it would help to remove it. BEFORE i always removed it; and right; starting of openldap worked then. BUT apparently this also leads to the missing serverID in my csn values (respectively that they all had default "000"). NOW i changed those config.ldif and hdb.ldif files from slapd.d (in which grep found the string "olcSyncrepl"), to give uri an appropriate value.

Open each file, search for "uri". It's found two times in every file. Before each occurence there's a variable "provider", which is set to something. For example in slapd.d/cn=config/olcDatabase={0}config.ldif : provider=ldap://ldapmaster.local.site uri="" and provider=ldap://ldapslave.local.site uri=""

The value of provider ALSO has to be put into uri, that afterwards it looks like: provider=ldap://ldapmaster.local.site uri="ldap://ldapmaster.local.site" and provider=ldap://ldapslave.local.site uri="ldap://ldapslave.local.site"

I did it on every machine (no file copy from one to another). After that; "rcldap start" (also) works without problems.

But that still was not enough... Third thing to do: additionally on each machine make slapd start with "-h" parameter correctly set; like Rein and Jonathan wrote. According to the SuSE-way of configuration (like it or not, but in this case i don't have a choice ;)) this can be done in /etc/sysconfig/openldap: set OPENLDAP_SLAPD_PARAMS correctly on every machine; e.g. on master:

OPENLDAP_SLAPD_PARAMS="-h ldap://ldapmaster.local.site"

And, by the way, to make sure that ONLY online configuration style (slapd.d) is used; one can set OPENLDAP_CONFIG_BACKEND from "" to: OPENLDAP_CONFIG_BACKEND="ldap"

This all together seems to solve the problem. Now LDAP-Objects can be altered, removed and added on one of both machines while the other one is down; and all changes are replicated as soon as the "downed" machine comes back up again. (At least in my tests until now ;))!

Thanks for your time, and best regards.. elmar