Dmitri Pal wrote:
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.
It is just as easy to catch this at install time, which we do now, and
provide the user with the info they need to proceed.
Eventually we are going to do this entirely on-line so there will be no
prepare step. It may be nice to take an enrolled client and promote it
into being a replica too.
I was just wondering if I was being overly paranoid in requiring that a
host be removed from IPA (therefore removing any existing certs and
services it may have) before allowing it to become a replica.
rob
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
