Joe Di Pol wrote on 07/08/2010 02:33 PM:
> Bill Shannon wrote:
>> Tim Quinn wrote on 07/08/2010 05:11 AM:
>>> 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.
>
> Today create-instance calls _register_instance to create the instance
> in domain.xml and the local command _create-instance-filesystem on the
> instance system (via SSH if remote) to initialize the files for the
> instance.
> So in that sense _create-instance-filesystem is "offline" and requires
> no admin authentication.
Does _create-instance-filesystem also create the das.properties file,
if necessary?
> Currently there is no way for create-instance to perform admin
> authentication
> to any local command it executes on the instance system because the DAS
> does not have access to the admin password in the clear.
>
> I suppose if the keys were available at create-instance time then maybe
> it could handle installing those keys on the instance. This would require
> the master password for the instance, right? Does the DAS have that
> available
> in the clear?
Yes.
Seems like create-instance is going to have to get some sort of authentication
information to the instance so that the later, potentially unattended,
start-local-instance will succeed.
In v2, with node agents, the node agent had its own copy of the keystore
that could have the keys necessary to authenticate to the DAS to
synchronize and start the server. We could do something similar here,
but then we need a mechanism to update that keystore if it changes.
_create-instance-filesystem could put the admin password in das.properties,
along with the admin username, assuming it can get both.
Or we could "push" the keystore file to the instance's config directory.
create-local-instance would need to be able to "pull" it.
Also, I noticed that, unlike create-domain, create-instance doesn't (in v2)
have a --savemasterpassword option, so if you're using a master password
you might always have to use create-local-instance, or configure the master
password manually. (We *never* send the master password over the wire.)