On 7/8/2010 11:51 PM, Bill Shannon wrote:
> 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?
yes _create-instance-filesystem creates das.properties file if it doesn'
t exist.
>
>> 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.)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>