[Freeipa-devel] Understanding FreeIPA replica internals

[James]

On Fri, May 23, 2014 at 7:49 PM, Simo Sorce <simo at redhat.com> wrote:
> On Fri, 2014-05-23 at 17:16 -0400, James wrote:
>> On Fri, 2014-05-23 at 15:44 +0200, Martin Kosek wrote:
>> > One cannot easily improve ipa-replica-prepare to work through LDAPI as
>> > we also
>> > need to encypher the replica info package - and we cannot do that
>> > without clear
>> > text DM password.
>> >
>> > The right way seems to be rather the RFE you filed:
>> > https://fedorahosted.org/freeipa/ticket/2888
>> >
>> > Martin
>>
>> Here is the model I am considering:
>>
>> Since each replica in a multi-master cluster is said to be functionally
>> "identical" once they're all setup, I'd actually like to try and match
>> this elegant symmetry that you've provided with an equally symmetrical
>> (or homogeneous, rather) design. That's to say I want the config
>> management parts to "be identical" on each host.
>>
>> What this means:
>> * It should be possible to parallelize a good chunk of the setup, if I
>> were to bring up a cluster of four hosts at the same time.
>>
>> * It's convenient if each individual host follows the same initial
>> ipa-server-install process, but that there is a secondary "join with my
>> peer" process.
>>
>> * In theory, if I set up two identical freeipa servers with the same
>> options (but different hostnames) I would like to be able to introduce
>> them to each other at a later date and join them (even if this means
>> that we pick one as the source of the data and the others data gets
>> overwritten)
>
> What is the point really ?
>
> You get this "symmetrical" install by doing a useless install of all
> fours and then practically redoing the install for 3 of the 4. Might as
> well just install 1 first and then do the other 3 in parallel, less CPU
> gets wasted.
This might actually be a good approach. I'll be trying to prototype
some things this week, and I'll try this out.

>
>> Does this help explain the need? For an example of peering that works
>> this way and is symmetrical with configuration management, my
>> puppet-gluster module does this.
>
> I think this is a case where aesthetics clash with reality.
I think I agree. The exception is that if the hosts are not all the
same, this makes specifying the config management bits significantly
harder. If they're the same, you can use a common pattern for all
hosts. This gives you a sort of "high availability" at the config
management level, meaning that if the host you designated as #1 is
down, you'd still be able to continue.

> Reality requires a serialization due to the need of having a common CA
> that releases certificates and a common KDC database that release
> keytabs for all services before all of them are installed.

Thank you for your input. One of my goals is to satisfy your
requirements on the "security" side. I'm sure you wouldn't approve of
the status quo of storing the dm_password and admin_password in
puppet. Me neither :)