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 172.18.0.1 and 172.18.0.2 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:
{end of sync.ldif-this line not included in file.}
It loads into the consumer (172.18.0.2) 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?
Thanks,
Ted.
This email has been checked for viruses by Avast antivirus software.
www.avast.com
