[Freeipa-devel] Understanding FreeIPA replica internals

[Simo Sorce]

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.

> 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.
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.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York