[Freeipa-devel] Understanding FreeIPA replica internals

[Simo Sorce]

On Fri, 2014-05-23 at 21:26 -0400, James wrote:
> 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 :)

No, but those need to be accessible to the user, I think you can create
a meta-package that contains those password when you create the first
master, encrypted in a gpg file with private keys only stored in the
freeipa servers.

Then you can move them around w/o puppet knowing what they contain,
although puppet will have to transfer at least public keys around.

Simo.

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