[Freeipa-devel] Allowing existing IPA hosts to be used for installing a replica

[Dmitri Pal]

On 06/07/2012 09:20 AM, Simo Sorce wrote:
> On Thu, 2012-06-07 at 09:16 -0400, Rob Crittenden wrote:
>> Simo Sorce wrote:
>>> On Wed, 2012-06-06 at 23:08 -0400, Rob Crittenden wrote:
>>>> Scott Poore wrote:
>>>>> Running this by the mailing list to see if I should open an RFE.
>>>>>
>>>>> Should we have the ability to install replicas where the host entries already exist in IPA?
>>>>>
>>>>> So, we could in theory do a host-add before running ipa-replica-install on the soon to be replica.  There may be some useful cases for supporting this.  Could be useful in a location that starts growing for "promoting" a client to a Replica for use in that location.  Maybe as an override flag to the ipa-replica-install command?
>>>>>
>>>>> Thoughts?
>>>> I asked Scott to pose this to the list. I'm a little uneasy about it but
>>>> perhaps I'm just paranoid.
>>>>
>>>> This isn't proposing that an enrolled client be able to become a
>>>> replica, but right now if a host entry exists for a target replica
>>>> server we require it be removed before proceeding.
>>>>
>>>> The reason being we don't know what else is associated with that host
>>>> (well, we do, but it sure seems like a lot of work to fetch it all). The
>>>> host could already have an HTTP server, for example. Or it could have
>>>> other certs or services.
>>>>
>>>> So the question is, is it adequate to require the removal or should we
>>>> go through the trouble to see if there are any conflicting services? We
>>>> don't have a TGT when preparing a replica so this would mean a bit of
>>>> manual LDAP work which could very well be a pain source in the future.
>>> Uhmm why should we care at replica preparation time ?
>>> All the kerberos keys are created at install time, is it for certs ?
>>> In that case I would suggest we defer creation of certs to install time
>>> so it becomes non-issue.
>>> At install time we detect if certs/keys are already available (and
>>> functional) and we just reuse them if so.
>>>
>>> What am I missing ?
>>>
>>> Simo.
>>>
>> The problem isn't at prepare time, it is at install time.
>>
>> In order to generate the certs on the fly we would have to prompt for a 
>> user with permissions to issue certs along with the DM password when 
>> installing. You already got grumpy when we started asking for a user 
>> when doing the conn-check.
> I understand that, maybe we should just defer it, as I said earlier I
> would like us to go and use only the admin user at install time, and the
> admin user would have those privileges.
>
> Simo.
>
IMO when you do replica prepare it should do an extra lookup to see if
the host already exists and been enrolled, i.e. keys or cert have been
provisioned. If it finds the host record it should bail out with a
warning. An override option like --force can be introduced to clean the
system. I assume that replica prepare would also create a host entry for
the replica but not update it until replica is provisioned.
Then when we install replica it should take over the system. It still
leaves room for the user to shoot himself in the foot by creating a
replica package but then installing a client. I do not know if we can
prevent this join operation on the server or not. If the fact that
replica package was created is recorded in LDAP then we probably can. 

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/