On 07/08/2010 09:20 PM, Simo Sorce wrote:
On Wed, 07 Jul 2010 16:31:44 +0400
Eugene Indenbom<eindenbom(a)gmail.com> wrote:
>> This is an interesting idea, but it also occurred to me that there
>> is a potential risk as well: if we fail over to another LDAP
>> server, there is no guarantee that it is perfectly in sync with the
>> primary server in the failover chain. The result could be that we
>> would get some data from one server or the other that doesn't align.
>>
>> With this in mind, I think our current approach is a bit safer
>> (even if it might be slower in a failover situation). With this
>> approach, we at least guarantee consistency within a single LDAP
>> server.
>>
>> What are your thoughts, Eugene?
>>
>>
> We have already had this discussion with Simo. My opinion is very
> similar to yours. For multi-stage operations we should use the same
> LDAP server for all stages. I know just too well what tricks
> multi-master replication could play in some setups. The risk to get
> inconsistent data from different servers is substantial. That's why I
> think it's better to have a separate tear for multi-stage operation.
>
The point is that you never have any guarantee of consistency even
against a single server when the connection does not drop, between
different operations
We are not the only user of the server so between any 2 operations
stuff can and do change.
This is a fact of life we should better keep well in mind.
We just have to deal with that.
This is also why I don't think that worries about "inconsistent" state
make much sense.
> From my point of view we should go even further and not to store
> intermediate stage results to sysdb until all data is received from
> LDAP server. Otherwise we could use inconsistent data in OFFLINE mode.
>
We will always risk suffering this no matter what you do, "consistency"
is quite a loose concept in ldap when you get down to the operation
level, because ldap has no transactions. Keeping all in memory would
just waste a lot of memory without any real gain.
Please think again about this point, it is not as simple as you make
it, and the assumptions you both are making are not valid.
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.
Eugene