Tim Quinn wrote on 07/08/2010 05:11 AM:
>
> On Jul 7, 2010, at 10:23 PM, Bill Shannon wrote:
>
>> I'm not sure I followed the discussion below...
>>
>> start-instance is a remote command. It's a way for an administrator to
>> (from anywhere) ask the DAS to please start a particular instance. The
>> DAS uses SSH or (eventually) contacts the node agent on the machine
>> where the instance will run to start the instance. Obviously the user
>> needs to authenticate with the DAS.
>>
>> start-local-instance is a local command. No authentication is required
>> beyond the operating system permissions to access the files necessary to
>> start the server.
>>
>> create-local-instance saves all the authentication information necessary
>> for start-local-instance to authenticate itself with the DAS based only
>> on the contents of local files, without requiring the user to provide
>> additional authentication information. Or at least it should, I don't
>> know if it currently does.
>>
>> Did you think it should work differently?
>
> What I think is that whatever command saves authentication information
> locally so start-local-instance can work without end-user auth. should
> itself require end-user auth. In your description, that's
> create-local-instance. I was not clear whether this would happen during
> create-local-instance or start-local-instance.
In general, I think we want create-local-instance to contact the DAS
and verify the authentication and set everything up. I don't remember
whether we also intended to support doing create-local-instance "offline",
assuming a create-instance would be done separately and then everything
would be set up by the time the instance was started. Maybe that's not
an important use case.
> One part of setting up the locally-saved info will be receiving from the
> DAS the self-signed cert that the DAS proposes to use for future SSL
> mutual auth. If the end-user accepts the DAS cert then the command
> saves it in the instance's truststore.
It will also be in the DAS's truststore, right?
> Another part of the local file initialization will be generating a
> self-signed cert that the instance will use in future SSL mutual auth
> with the DAS. The command will present that cert to the DAS (the DAS
> will save the instance cert in its truststore) and the command will save
> the generated private key in the instance's local keystore.
How will the private key survive full synchronization of the instance?
Will it also be stored in the keystore on the DAS? Will it be stored
in a keystore that is not part of synchronization?
> Because the instance's self-signed cert is how the DAS will trust this
> instance in the future, and because create-local-instance seems like the
> command that will generate that cert, I think create-local-instance
> should do end-user authentication. Saving a cert in the DAS truststore
> is just as much a change in the domain configuration as anything that's
> stored in domain.xml, and we require end-user auth before allowing those
> sorts of changes.
So in addition to the _register-instance call that create-local-instance
will make, does there need to be another call or calls to handle the
cert exchange?
> IIRC I've heard create-local-instance described as a local command not
> requiring the end-user to authenticate to the DAS. I would have thought
> that adding an instance to the domain would be considered a config
> change and would involve authenticating the end-user to the DAS. But
> apart from that, if create-local-instance will be the command that sets
> up the instance's local files with trusted authentication information,
> then shouldn't we require end-user auth for that?
Yes.