[Freeipa-devel] Proposal: reverse stance on installing CA on new masters

[Simo Sorce]

On Fri, 2015-04-10 at 10:44 +1000, Fraser Tweedale wrote:
> On Thu, Apr 09, 2015 at 05:06:31PM -0400, Simo Sorce wrote:
> > On Thu, 2015-04-09 at 16:52 -0400, Rob Crittenden wrote:
> > > Simo Sorce wrote:
> > > > On Thu, 2015-04-09 at 15:42 -0400, Rob Crittenden wrote:
> > > >> Petr Vobornik wrote:
> > > >>> On 04/09/2015 04:05 PM, Rob Crittenden wrote:
> > > >>>> Right now when a new master is installed it is not configured with a CA
> > > >>>> unless one passes in --setup-ca (or afterward runs ipa-ca-install).
> > > >>>>
> > > >>>> Over and over we've seen people who have multiple masters and a single
> > > >>>> CA, in some cases that CA machine is gone, leaving the realm with no CA
> > > >>>> at all.
> > > >>>>
> > > >>>> I think this is due to the fact that CA replicas are not created by
> > > >>>> default and the users are not aware of the implications of a single
> > > >>>> point-of-failure since things otherwise seem to be working.
> > > >>>>
> > > >>>> So perhaps the default should be to install a CA unless the user
> > > >>>> requests one not be installed. A related task may be to create an
> > > >>>> uninstaller for just the CA.
> > > >>>>
> > > >>>> rob
> > > >>>>
> > > >>>
> > > >>> From a general perspective:
> > > >>>
> > > >>> When I hear "replica" it evokes a "clone", something equal/identical.
> > > >>>
> > > >>> Based on this, the expected behavior for me would be that:
> > > >>>
> > > >>> - if master has DNS and CA, then the new replica would also have DNS and
> > > >>> CA (without any configuration option needed).
> > > >>> - if an optional service is missing then replica wouldn't have it as
> > > >>> well by default
> > > >>>
> > > >>> This would required reverse options like: --no-dns.
> > > >>
> > > >> Pretty much exactly what I was thinking.
> > > >>
> > > >> For the option I think we should go with a more generic --ca, --dns,
> > > >> with the default value matching what the remote master has configured.
> > > >>
> > > >> But that's bike shedding.
> > > >>
> > > >> The real question is, what do others think? Is this worth filing a
> > > >> ticket for? It would be a subtle but significant change. This might tie
> > > >> in nicely with planned topology management too.
> > > > 
> > > > I think I would like to see questions in interactive mode, but not force
> > > > CA and DNS to be installed just because the other replica has them.
> > > > 
> > > > The replica originating machines has more to do with topology (what
> > > > master you want to replicate off) then features.
> > > > 
> > > > So if you are doing an interactive install and the remote replica has CA
> > > > and DNS features, it may be nice to ask: do you want to setup CA too ?
> > > > Do you want to setup DNS too ?
> > > > But not do it by default w/o positive confirmation.
> > > > Esp for DNS it makes little sense as you need a change in DHCP/other
> > > > infra for it to be of any use and all data is in LDAP anyway
> > > > The CA case is a little bit more critical as you noted, but I think
> > > > nagging in interactive is probably good enough.
> > > 
> > > That's why I suggested this be tied to the topology plugin, so the user
> > > has a chance to massage things afterward in an easy manner.
> > > 
> > > A less obtrusive suggestion would be to be to try to count the number of
> > > CAs and spit out a scary warning if it is just one.
> > >
> "Nagging in interactive", "scary warning if < 2 CAs" are probably
> good enough to avoid the horror stories, but is it good enough UX
> to require user intervention to avoid the loss of CA on losing a
> single replica?

I think it is better than the current situation.
 
> > Maybe force CA on if there is only one CA ? (Ie first 2 servers get to
> > be CAs) then a new CA is force installed only if one of the 2 is
> > killed ?
> > 
> > Simo.
> > 
> We would only need this special case if there is a problem with
> having a CA clone for each replica, right?  Is there a problem?

Private CA key exposed on additional servers.
Added replication load.
Added CPU/Memory load (dogtag is not exactly lightweight).

Simo.

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