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

Petr Spacek pspacek at redhat.com
Fri Apr 10 07:00:59 UTC 2015


On 10.4.2015 05:25, Fraser Tweedale wrote:
> On Thu, Apr 09, 2015 at 10:58:35PM -0400, Simo Sorce wrote:
>> > 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.

I can see slight misunderstanding here:
Rob and Petr^1 were talking about defaults, not about any enforcement.

My understanding is that ipa-replica-install should have options --dns and
--ca which would override default values inherited from the master used to run
ipa-replica-prepare.

It seems very reasonable to me, I support Rob's proposal.

These 'defaults' can be easily combined with scary warning if CA/DNS is
running on single replica.

-- 
Petr^2 Spacek




More information about the Freeipa-devel mailing list