> I want to set up a cluster of ldap servers. In that
cluster, I want:
> - One primary supplier server
> - One hot standby supplier server
> - N read only consumer replicas.
> - a load balancer that directs all writes to the primary
master if it's
> or the standby if it's down.
> However, I want operational attributes like password policy
> to be replicated across the cluster. My understanding is that if I
> set up two suppliers and N consumers, operational attribute changes
> (such as password policy attrs) on the consumers will not replicate
> across the cluster.
Where did you find such information?
There was a post about this about a month ago, talking about this as a
problem and using chaining to solve it, but I'm thinking the chaining
idea didn't solve all the problems...
in order to syhnchronise all user attributes and operational
attributes just use *,+ as attribute list, as lined out in man
My understanding is that if I have a master/slave config with a
typical syncrepl setup, and have password policy turned on in the
consumer, password policy operational attributes are maintained
locally, and are not replicated back to the master/supplier, but
operational attributes on a master/supplier will be replicated to a
consumer. Given that most clients will talk to a consumer server,
that would mean password policy op attrs are not replicated to other
consumers. Is that correct? If they are in fact replicated, how
does the consumer have permission to write back to the master/supplier,
so it can replicate to other consumers?
I want to find a way to preserve the idea of directory consistency by
writing to a single server from an external client POV, while
propogating operational knowledge like password failures across the
I'm thinking there are 2 options (in theory - I don't know if these
actually work - at this point, I'm looking for advice on the best
direction to go for this in my testing. Hoping to brainstorm
possibilities first to limit the number of test cases/situations I
have to try before I get something workable):
Use the chain overlay to forward write operations on a consumer back
to the supplier. I think I would have to have different aci's on the
consumer (only non-write aci's) so that a client could not write to
the consumer and have it chained to the master(?) I.e. to an external
client, I still want this to "appear" as a typical single master (well,
single master with a hot standby which is hidden by a load balancer),
read-only consumers setup. I don't really care if the consumer returns
a referral on a write attempt or an error, since most of my clients
follow referrals anyway. I definitely don't want all my consumers to
allow writes directly (I'd actually prefer to firewall my suppliers off
so only select apps can even get to them to write, while most apps only
have access to a read-only consumer.) But... I think I saw something
previously on the list about these operational attributes being written
directly to the db, so might not follow a chain rule to write it to the
supplier(?) Also, creates a single point of failure (well, not single,
but as many suppliers as you have) in that everything has to be
through the master server(s).
Everything is a master/supplier, but aci's on designated "masters" allow
read/write operations, while designated "consumers" have aci's that only
allow non-write access. I believe this would replicate the operational
attributes in a way that chaining may not(?), eliminates single point
of failure, since every server can pass its op changes on to every other
server(?). Effectively, from an external client, this is a typical one
master, many consumer setup, but internally, operational data is shared
across the entire cluster (assuming it all works like I think it does).
Option 2 has the added benefit that I can promote one of these
"consumers" to be a master in a disaster recovery situation very easily
by just replacing the aci's. Option 1 would require me to undo all the
chaining config, and update all my consumers to point to the "new"
supplier (I suppose DNS tricks could be used to resolve some of that,
but either way it's more complicated).
So.. Am I on the right track? Anything I say completely wrong? Is
another, better option to do what I want?