On Jun 22, 2010, at 3:00 PM, Kedar Mhaswade wrote:
>
>
> On Tue, Jun 22, 2010 at 11:02 AM, Tim Quinn <tim.quinn_at_oracle.com>
> wrote:
> Thanks, Carla.
>
> So far things should work OK if the administrator has chosen to
> secure the admin traffic. (The admin will have set up Grizzly to
> redirect http://myhost:4848 to https://myhost:4849 and our asadmin
> client will know how to deal with that.)
>
> If the administrator has set up an admin username and password, how
> are those values sent given that we don't support
>
> --password
>
> on asadmin commands? Is there a preceding step which securely
> transfers a password file to be specified using
>
> --passwordfile
>
> AFAIK, we use HTTP Basic Auth. So, there is no password file
> transferred.
We were talking about the use case Joe explained in a later follow-up,
in which ssh is driving local command execution on remote systems. I
was trying to confirm that indeed only local commands will be run this
way; one of the examples cited in the one pager was start-local-
instance which, AFAIK, syncs with the DAS and therefore could require
authentication.
> Asadmin adds the appropriate header encoded in Base-64 by reading
> the client-side passwordfile (property named AS_ADMIN_PASSWORD) or
> accepting the password on prompt. If it gets redirect, well, it
> sends the same header again, this time to secure URL.
>
> To be absolutely sure, admins should use --secure to begin with
> which should result in no redirection and password is put on secure
> channel only.
>
> (This is how it was in GlassFish v3).
Well, that's true for 3.0.1!
For 3.1 we are tightening things up a bit. No credentials will be
sent in the clear. Watch for a one-pager about this within a month.
- Tim
>
> -Kedar
>
>
> (Apologies if this is all covered in a one-pager somewhere. If so,
> pointer appreciated.)
>
> - Tim
>
> On Jun 22, 2010, at 12:44 PM, Carla Mott wrote:
>
>> I run the 'local' version of a command on the instance host and
>> that command requires the host and port info to connect back to the
>> DAS machine.
>> That was my 25(+/-)-word-or-less-description. A more wordy example
>> would be:
>> The user runs the following on the DAS machine to create an
>> instance on the instance host:
>>
>> asadmin create-instance --node=n1 instance1
>>
>> what that does (if n1 is pointing to a machine that is not the DAS)
>> is actually build a command using the 'local' version and run that
>> command on the instance host. So using ssh, I will run the
>> following on the instance machine:
>>
>> asadmin create-local-instance --host=myhost --port=4848 instance1
>>
>> which is the same thing the user can do from the command line if he
>> is running on the instance machine.
>> Tim Quinn wrote:
>>> Right now there is no second admin listener for secure admin
>>> traffic, but there will be soon enough.
>>>
>>> I imagine RemoteInstanceCommandHelper can be augmented with a
>>> method to return the secure admin port.
>>> Carla, what I don't know is whether the ssh work you are doing
>>> need to be aware of a secure admin port once it's available. Can
>>> you give the 25-words-or-less description of how the admin port
>>> you are sending via ssh ends up being used?
>>>
>>> Thanks.
>>>
>>> - Tim
>>>
>>> On Jun 21, 2010, at 12:41 PM, Byron Nevins wrote:
>>>
>>>> RemoteInstanceCommandHelper has exactly what you want.
>>>>
>>>>
>>>> On 6/21/2010 6:48 AM, Vijay Ramachandran wrote:
>>>>> The correct way it to get the value set in the <network-
>>>>> listener> element. Currently the token ASADMIN_PORT is not
>>>>> getting replaced by the appropriate value.
>>>>>
>>>>> Jennifer / Byron are working on fixing that - till then, you
>>>>> have to use the system props to get the admin port number
>>>>>
>>>>> Vijay
>>>>>
>>>>> On 6/21/10 12:10 AM, Carla Mott wrote:
>>>>>> Hi
>>>>>>
>>>>>> What's the easiest way for code in the DAS to get the admin
>>>>>> port number? I see that I can get the hostname from a system
>>>>>> property but what about the port? I need to pass these values
>>>>>> to some commands when running over ssh.
>>>>>>
>>>>>> Thanks,
>>>>>> Carla
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: admin-
>>>>>> unsubscribe_at_glassfish.dev.java.net <mailto:admin-unsubscribe_at_glassfish.dev.java.net
>>>>>> >
>>>>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>>>>> <mailto:admin-help_at_glassfish.dev.java.net>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>>>> <mailto:admin-unsubscribe_at_glassfish.dev.java.net>
>>>>> For additional commands, e-mail: admin-
>>>>> help_at_glassfish.dev.java.net <mailto:admin-help_at_glassfish.dev.java.net
>>>>> >
>>>>>
>>>>
>>>> --
>>>> Byron Nevins - Oracle Corporation
>>>> Home: 650-359-1290
>>>> Cell: 650-784-4123
>>>> Sierra: 209-295-2188
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net <mailto:admin-unsubscribe_at_glassfish.dev.java.net
>>>> >
>>>> For additional commands, e-mail: admin-
>>>> help_at_glassfish.dev.java.net <mailto:admin-help_at_glassfish.dev.java.net
>>>> >
>>>>
>>>
>>>
>>>
>>> Oracle <http://www.oracle.com>
>>> Tim Quinn | Principal Member of Technical Staff | +1.847.604.9475
>>> Oracle GlassFish Engineering
>>> Lake Forest, IL
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>
>
>
>
>
> Tim Quinn | Principal Member of Technical Staff | +1.847.604.9475
> Oracle GlassFish Engineering
> Lake Forest, IL
>
>
Tim Quinn | Principal Member of Technical Staff | +1.847.604.9475
Oracle GlassFish Engineering
Lake Forest, IL