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.

rob

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to