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

Provider-Consumer replication 2.4 OLC (second attempt)

Greets - (first post, second time. Don't know if it's being moderated or dropped, will keep trying).

I have been using OpenLdap for some time - in master-slave (provider/consumer) situations prior 2.3 (thus using slapd.conf) and post 2.3 only as standalones (which I've found always easy).

This is my first foray into a 2.4 replication, and it's just not working out for me. Admittedly, I KNOW I have missed an important step somewhere (like turning on an index or similar) - there are far too many "I'm leaving a personal step out" tutorials on the great web, or ones that show some really good paths, but conflict - so it is entirely possible that my mashing together of search results has been the cause of the problem.

I am starting on bare metal, real machines, (not VM's, not wild hosting, etc) on a very isolated sandbox environment. Debian Jessie, and no extra fun added in to complicate matters. (Thus a bare metal install with ssh-server, slapd, ldap-utils from packages). Only the default schemas are needed for my purposes.

Servers and are my instances (examples), where 0.1 is the "master/provider" and 0.2 is a "slave/consumer". The intent is to have multiple consumer servers that reference the provider; all changes/additions are to be referred back to the provider 0.1, and although there should be good network connectivity between all hosts, the purpose of this install is to have local servers (the slave/consumers) acting for each local installation for all local requests, not for speed, but for failover. IF there is a loss of sync for a while, it is not a huge concern, as the changes will be infrequent, and we're dealing with perhaps a record set of 100-200 accounts, mirrored to all sites.

After installation, I have two functioning standalone servers. During my research, I found two conflicting pieces of information. I prefer to perform "refreshOnly" instead of "refreshAndPersist", so some sources say ONLY the consumers need configuration, a couple said both sides need configuration AND a number of additional indices. This is likely where my problems arise.

Here's what I popped into "sync.ldif" and loaded ONLY TO THE CONSUMER via ldapadd:

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl: rid=100
  retry="5 5 300 +"
add: olcUpdateRef
olcUpdateRef: ldap://

{end of sync.ldif-this line not included in file.}

It loads into the consumer ( without error,  and change referrals DO get forwarded to the provider (0.1). I am using the back-mdb, and the replication user is functional as a write-write security object on 0.1 (for simplicity, at the moment it is a copy of admin, with all rights and privs).

At no time did the consumer's db populate with the replication information. There was no indication that the consumer even tried. (finding log information however was sketchy at best). There was no indication from the provider that a consumer was calling in and was attempting to replicate. Again, connectivity is fine, as referrals work as expected.

If I were to backup the provider db (slapcat) and restore it to the consumer, that db does restore, and the consumer instance starts handling local auth requests (I intentionally disconnected 0.1 to prove that) - and I can still add an account to the provider, (direct or referred) but even after multiple restarts, (the retry directive says every 5 seconds 5 times, then every 300 sec to poll), no consumer updates occurred.

Moving forward to finding an obscure note about having to install the syncrepl module on ONLY the provider, not the consumer (?) but related to refreshAndPersist, I tried it anyway:
{provider syncsetup.ldif:}
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov

however still no change to things. I have not tried this on the consumer (yet) as I've found no example that says to do so. (don't know why you'd load syncprov on a consumer anyway).
I am quite familiar with the 2.4admin guide - particularly in how sparse the documentation examples are for using OLC directives - rather frustrating that even though the version is pushing OLC (cn=config), it still holds tight to slapd.conf examples. I do not want a slapd.conf solution attempt.

Any thoughts?


Avast logo

This email has been checked for viruses by Avast antivirus software.