I have checked in a minor revision that restores the ability to do *-
ssh commands from the DAS with secure admin disabled.
It also preserves the more user-friendly response to attempted remote
asadmin requests ("forbidden" instead of "unauthorized").
- Tim
On Dec 8, 2010, at 9:39 PM, Tim Quinn wrote:
> Sigh...
>
> What we wanted to happen in this case was that the DAS would provide
> a limited-use authentication token to the commands it submitted over
> ssh. When those commands ran on the remote instance they would use
> the token which the DAS would accept.
>
> In response to a recent request, I added logic to the AdminAdapter
> to reject with Forbidden status any remote request to be more user-
> friendly. This, obviously, short-circuits the token-based
> authentication.
>
> Let me see if I can get this working again.
>
> - Tim
>
> On Dec 8, 2010, at 6:45 PM, Joe Di Pol wrote:
>
>>
>> If I have secure admin disabled I am able to create a remote
>> instance using create-instance and start it:
>>
>> $ ./asadmin create-instance --node node1 instance1
>> Command _create-instance-filesystem executed successfully.
>> Port Assignments for server instance instance1:
>> JMX_SYSTEM_CONNECTOR_PORT=28686
>> . . .
>> IIOP_SSL_MUTUALAUTH_PORT=23920
>> The instance, instance1, was created on host adc2101159.us.oracle.com
>> Command create-instance executed successfully.
>>
>> $ ./asadmin start-instance instance1
>> Warning: Synchronization with DAS failed, continuing startup...
>> Waiting for instance1 to start .....
>> . . .
>> Command start-local-instance executed successfully.
>> The instance, instance1, was started on host adc2101159.us.oracle.com
>> Command start-instance executed successfully.
>>
>> But from that point on things don't work so good. For example list-
>> instances reports the instance state as "not running", even though
>> the instance is running:
>>
>> $ ./asadmin list-instances --long
>> NAME HOST PORT PID CLUSTER STATE
>> instance1 adc2101159.us.oracle.com 24848 -1 --- not
>> running
>> Command list-instances executed successfully.
>>
>> I imagine command replication won't work, or anything that uses the
>> admin protocol from the DAS to the remote instance, right?
>>
>> So it seems like letting users create and start remote instances
>> when secure admin is off will just cause confusion since things
>> only half work. Should we change this so that create-instance does
>> not allow the creation of remote instances if secure admin is
>> disabled?
>>
>> Note that you can't create a remote instance in this case with
>> create-local-instance since it is unable to connect to the DAS --
>> you can only do it via create-instance.
>>
>> Joe
>>
>