On Fri, 09 Jul 2010 15:50:16 +0400
Eugene Indenbom <eindenbom(a)gmail.com> wrote:
Although your point about consistency and lack of transactions is
completely valid, there is another kind of consistence that is still
obeyed by LDAP - order of writes. Let's consider the following setup:
- there are 2 LDAP master servers
- there is a HBAC rule that allows login (let's call it R)
- there is a host group G to which rule R applies
- there is a remote host B which does not belong to group A and
to which rule R does not apply
In this setup login from host B to A is prohibited.
After that:
- Replication agreement between LDAP masters gets broken for
some reason (communication problems or some other issue)
- On first LDAP server:
- Rule R is reversed, now it denies login
- Host B is added to group G
- login from B to A is still prohibited
- User attempts a login from host B to host A:
- SSSD receives host info about host B from first LDAP
servers and finds out that it belongs to group G
- connection to first LDAP server goes down
- SSSD receives rule R from second LDAP server, but this is
an old rule version
- login from B to A is allowed.
Therefore there is actually a scenario when inconsistency between 2
LDAP masters can lead to more serious implications, then simple lack
of transactions in LDAP.
So think it's better to be on the safe side.
This is a false scenario. Your SSSD daemon may have been connected
from the start to the second server. (Replication assures operations
are replicated in the same order they are received anyway).
If replication is broken and LDAP servers are inconsistent you can
always have issues depending to which server the client connects to.
That's not something you can successfuly deal with at the client level.
Simo.
--
Simo Sorce * Red Hat, Inc * New York