It seems like for your custom ami the user scripts are not executed as expected.
How about adding your own software later as Whirr services or using
bash scripts and start from a vanilla Ubuntu ami?
-- Andrei Savu / andreisavu.ro
On Wed, Aug 24, 2011 at 11:41 PM, Joris Poort <gpo...@gmail.com> wrote:
> Thanks for offering your help Guillaume. Unfortunately I tried that
> and still have the same issues.
>
> On Wed, Aug 24, 2011 at 11:34 PM, tog <guillaume.all...@gmail.com> wrote:
>> I don't know if this can help but here are the 2 lines that I added to
>> my cluster property file in order to be able to log on the cluster:
>> whirr.private-key-file=${sys:user.home}/.ssh/id_rsa
>> whirr.public-key-file=${sys:user.home}/.ssh/id_rsa.pub
>>
>> then I was able to connect my local userid and not ubuntu.
>>
>> HTH
>> Guillaume
>>
>>
>> On Thu, Aug 25, 2011 at 11:34 AM, Joris Poort <gpo...@gmail.com> wrote:
>>> I also tried to regenerate the ssh keys, but still no luck...
>>>
>>> On Wed, Aug 24, 2011 at 10:13 PM, Joris Poort <gpo...@gmail.com> wrote:
>>>> Interestingly, as mentioned before I can ssh in using my keypair used
>>>> to create the custom AMI. So I'm thinking that it still has to do
>>>> with whirr not being able to get the right keypair access with the
>>>> local id_rsa.
>>>>
>>>> Thanks again for any help,
>>>>
>>>> Joris
>>>>
>>>> On Wed, Aug 24, 2011 at 10:11 PM, Joris Poort <gpo...@gmail.com> wrote:
>>>>> Thanks guys. I guess I was using "ubuntu" as user incorrectly, now
>>>>> adjusted to local-user "gpoort" I'm still not getting through. See
>>>>> output below from -vv (sorry about the long email).
>>>>>
>>>>> gpoort@jvb:~$ ssh -vv -i .ssh/id_rsa
>>>>> ubu...@ec2-184-72-86-108.compute-1.amazonaws.com
>>>>> OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010
>>>>> debug1: Reading configuration data /etc/ssh/ssh_config
>>>>> debug1: Applying options for *
>>>>> debug2: ssh_connect: needpriv 0
>>>>> debug1: Connecting to ec2-184-72-86-108.compute-1.amazonaws.com
>>>>> [184.72.86.108] port 22.
>>>>> debug1: Connection established.
>>>>> debug2: key_type_from_name: unknown key type '-----BEGIN'
>>>>> debug2: key_type_from_name: unknown key type '-----END'
>>>>> debug1: identity file .ssh/id_rsa type 1
>>>>> debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
>>>>> debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
>>>>> debug1: identity file .ssh/id_rsa-cert type -1
>>>>> debug1: Remote protocol version 2.0, remote software version
>>>>> OpenSSH_5.3p1 Debian-3ubuntu7
>>>>> debug1: match: OpenSSH_5.3p1 Debian-3ubuntu7 pat OpenSSH*
>>>>> debug1: Enabling compatibility mode for protocol 2.0
>>>>> debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3
>>>>> debug2: fd 3 setting O_NONBLOCK
>>>>> debug1: SSH2_MSG_KEXINIT sent
>>>>> debug1: SSH2_MSG_KEXINIT received
>>>>> debug2: kex_parse_kexinit:
>>>>> ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
>>>>> debug2: kex_parse_kexinit:
>>>>> ssh-rsa-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
>>>>> debug2: kex_parse_kexinit:
>>>>> aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
>>>>> debug2: kex_parse_kexinit:
>>>>> aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
>>>>> debug2: kex_parse_kexinit:
>>>>> hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
>>>>> debug2: kex_parse_kexinit:
>>>>> hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
>>>>> debug2: kex_parse_kexinit: none,z...@openssh.com,zlib
>>>>> debug2: kex_parse_kexinit: none,z...@openssh.com,zlib
>>>>> debug2: kex_parse_kexinit:
>>>>> debug2: kex_parse_kexinit:
>>>>> debug2: kex_parse_kexinit: first_kex_follows 0
>>>>> debug2: kex_parse_kexinit: reserved 0
>>>>> debug2: kex_parse_kexinit:
>>>>> diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
>>>>> debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
>>>>> debug2: kex_parse_kexinit:
>>>>> aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
>>>>> debug2: kex_parse_kexinit:
>>>>> aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
>>>>> debug2: kex_parse_kexinit:
>>>>> hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
>>>>> debug2: kex_parse_kexinit:
>>>>> hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
>>>>> debug2: kex_parse_kexinit: none,z...@openssh.com
>>>>> debug2: kex_parse_kexinit: none,z...@openssh.com
>>>>> debug2: kex_parse_kexinit:
>>>>> debug2: kex_parse_kexinit:
>>>>> debug2: kex_parse_kexinit: first_kex_follows 0
>>>>> debug2: kex_parse_kexinit: reserved 0
>>>>> debug2: mac_setup: found hmac-md5
>>>>> debug1: kex: server->client aes128-ctr hmac-md5 none
>>>>> debug2: mac_setup: found hmac-md5
>>>>> debug1: kex: client->server aes128-ctr hmac-md5 none
>>>>> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
>>>>> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
>>>>> debug2: dh_gen_key: priv key bits set: 138/256
>>>>> debug2: bits set: 502/1024
>>>>> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
>>>>> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
>>>>> debug1: Server host key: RSA
>>>>> 77:b6:b5:95:c6:0d:3d:82:94:91:d5:7d:70:8f:b8:1b
>>>>> debug1: Host 'ec2-184-72-86-108.compute-1.amazonaws.com' is known and
>>>>> matches the RSA host key.
>>>>> debug1: Found key in /home/gpoort/.ssh/known_hosts:7
>>>>> debug2: bits set: 497/1024
>>>>> debug1: ssh_rsa_verify: signature correct
>>>>> debug2: kex_derive_keys
>>>>> debug2: set_newkeys: mode 1
>>>>> debug1: SSH2_MSG_NEWKEYS sent
>>>>> debug1: expecting SSH2_MSG_NEWKEYS
>>>>> debug2: set_newkeys: mode 0
>>>>> debug1: SSH2_MSG_NEWKEYS received
>>>>> debug1: Roaming not allowed by server
>>>>> debug1: SSH2_MSG_SERVICE_REQUEST sent
>>>>> debug2: service_accept: ssh-userauth
>>>>> debug1: SSH2_MSG_SERVICE_ACCEPT received
>>>>> debug2: key: .ssh/id_rsa (0x7f4ea3913cd0)
>>>>> debug1: Authentications that can continue: publickey
>>>>> debug1: Next authentication method: publickey
>>>>> debug1: Offering RSA public key: .ssh/id_rsa
>>>>> debug2: we sent a publickey packet, wait for reply
>>>>> debug1: Authentications that can continue: publickey
>>>>> debug2: we did not send a packet, disable method
>>>>> debug1: No more authentication methods to try.
>>>>> Permission denied (publickey).
>>>>> gpoort@jvb:~$ ssh -vv -i .ssh/id_rsa
>>>>> gpo...@ec2-184-72-86-108.compute-1.amazonaws.com
>>>>> OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010
>>>>> debug1: Reading configuration data /etc/ssh/ssh_config
>>>>> debug1: Applying options for *
>>>>> debug2: ssh_connect: needpriv 0
>>>>> debug1: Connecting to ec2-184-72-86-108.compute-1.amazonaws.com
>>>>> [184.72.86.108] port 22.
>>>>> debug1: Connection established.
>>>>> debug2: key_type_from_name: unknown key type '-----BEGIN'
>>>>> debug2: key_type_from_name: unknown key type '-----END'
>>>>> debug1: identity file .ssh/id_rsa type 1
>>>>> debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
>>>>> debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
>>>>> debug1: identity file .ssh/id_rsa-cert type -1
>>>>> debug1: Remote protocol version 2.0, remote software version
>>>>> OpenSSH_5.3p1 Debian-3ubuntu7
>>>>> debug1: match: OpenSSH_5.3p1 Debian-3ubuntu7 pat OpenSSH*
>>>>> debug1: Enabling compatibility mode for protocol 2.0
>>>>> debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3
>>>>> debug2: fd 3 setting O_NONBLOCK
>>>>> debug1: SSH2_MSG_KEXINIT sent
>>>>> debug1: SSH2_MSG_KEXINIT received
>>>>> debug2: kex_parse_kexinit:
>>>>> ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
>>>>> debug2: kex_parse_kexinit:
>>>>> ssh-rsa-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
>>>>> debug2: kex_parse_kexinit:
>>>>> aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
>>>>> debug2: kex_parse_kexinit:
>>>>> aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
>>>>> debug2: kex_parse_kexinit:
>>>>> hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
>>>>> debug2: kex_parse_kexinit:
>>>>> hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
>>>>> debug2: kex_parse_kexinit: none,z...@openssh.com,zlib
>>>>> debug2: kex_parse_kexinit: none,z...@openssh.com,zlib
>>>>> debug2: kex_parse_kexinit:
>>>>> debug2: kex_parse_kexinit:
>>>>> debug2: kex_parse_kexinit: first_kex_follows 0
>>>>> debug2: kex_parse_kexinit: reserved 0
>>>>> debug2: kex_parse_kexinit:
>>>>> diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
>>>>> debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
>>>>> debug2: kex_parse_kexinit:
>>>>> aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
>>>>> debug2: kex_parse_kexinit:
>>>>> aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
>>>>> debug2: kex_parse_kexinit:
>>>>> hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
>>>>> debug2: kex_parse_kexinit:
>>>>> hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
>>>>> debug2: kex_parse_kexinit: none,z...@openssh.com
>>>>> debug2: kex_parse_kexinit: none,z...@openssh.com
>>>>> debug2: kex_parse_kexinit:
>>>>> debug2: kex_parse_kexinit:
>>>>> debug2: kex_parse_kexinit: first_kex_follows 0
>>>>> debug2: kex_parse_kexinit: reserved 0
>>>>> debug2: mac_setup: found hmac-md5
>>>>> debug1: kex: server->client aes128-ctr hmac-md5 none
>>>>> debug2: mac_setup: found hmac-md5
>>>>> debug1: kex: client->server aes128-ctr hmac-md5 none
>>>>> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
>>>>> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
>>>>> debug2: dh_gen_key: priv key bits set: 145/256
>>>>> debug2: bits set: 505/1024
>>>>> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
>>>>> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
>>>>> debug1: Server host key: RSA
>>>>> 77:b6:b5:95:c6:0d:3d:82:94:91:d5:7d:70:8f:b8:1b
>>>>> debug1: Host 'ec2-184-72-86-108.compute-1.amazonaws.com' is known and
>>>>> matches the RSA host key.
>>>>> debug1: Found key in /home/gpoort/.ssh/known_hosts:7
>>>>> debug2: bits set: 495/1024
>>>>> debug1: ssh_rsa_verify: signature correct
>>>>> debug2: kex_derive_keys
>>>>> debug2: set_newkeys: mode 1
>>>>> debug1: SSH2_MSG_NEWKEYS sent
>>>>> debug1: expecting SSH2_MSG_NEWKEYS
>>>>> debug2: set_newkeys: mode 0
>>>>> debug1: SSH2_MSG_NEWKEYS received
>>>>> debug1: Roaming not allowed by server
>>>>> debug1: SSH2_MSG_SERVICE_REQUEST sent
>>>>> debug2: service_accept: ssh-userauth
>>>>> debug1: SSH2_MSG_SERVICE_ACCEPT received
>>>>> debug2: key: .ssh/id_rsa (0x7fc32b462cd0)
>>>>> debug1: Authentications that can continue: publickey
>>>>> debug1: Next authentication method: publickey
>>>>> debug1: Offering RSA public key: .ssh/id_rsa
>>>>> debug2: we sent a publickey packet, wait for reply
>>>>> debug1: Authentications that can continue: publickey
>>>>> debug2: we did not send a packet, disable method
>>>>> debug1: No more authentication methods to try.
>>>>> Permission denied (publickey).
>>>>>
>>>>> On Wed, Aug 24, 2011 at 9:48 PM, Andrei Savu <savu.and...@gmail.com>
>>>>> wrote:
>>>>>> You should be able to login user the same user that is running Whirr.
>>>>>>
>>>>>> ssh -i ~/.ssh/id_rsa local-user@server
>>>>>>
>>>>>> Permission denied most of the time means invalid key, user pair.
>>>>>>
>>>>>> It should be ok to use the keys generate by default.
>>>>>>
>>>>>> -- Andrei Savu / andreisavu.ro
>>>>>>
>>>>>> On Wed, Aug 24, 2011 at 9:01 PM, Joris Poort <gpo...@gmail.com> wrote:
>>>>>>> I'm just using the defaults. But you may be onto the problem here,
>>>>>>> when I try to ssh into the node using:
>>>>>>> ssh -i ~/.ssh/id_rsa ubuntu@<public dns>
>>>>>>>
>>>>>>> I get a permission denied.
>>>>>>>
>>>>>>> Any idea how to fix this? Should I create my own set of SSH key pairs?
>>>>>>>
>>>>>>> Thanks again,
>>>>>>>
>>>>>>> Joris
>>>>>>>
>>>>>>> On Wed, Aug 24, 2011 at 8:42 PM, Andrei Savu <savu.and...@gmail.com>
>>>>>>> wrote:
>>>>>>>> Are you specifying a new set of SSH key pairs in the Whirr properties
>>>>>>>> file?
>>>>>>>>
>>>>>>>> If not by default Whirr will use the keys found in ~/.ssh - id_rsa &
>>>>>>>> id_rsa.pub.
>>>>>>>>
>>>>>>>> -- Andrei Savu / andreisavu.ro
>>>>>>>>
>>>>>>>> On Wed, Aug 24, 2011 at 8:02 PM, Joris Poort <gpo...@gmail.com> wrote:
>>>>>>>>> I think you're probably right its an auth issue - although I was
>>>>>>>>> expecting a more direct/clear error message if the keypair wasn't
>>>>>>>>> working.
>>>>>>>>>
>>>>>>>>> I created the AMI by taking an EBS snapshot then converting to
>>>>>>>>> instance-store. I've tried both the ebs back ami and instance-store
>>>>>>>>> with the same results. My understanding is that the keypair used to
>>>>>>>>> create the AMI is generally one of the accepted keys in addition to
>>>>>>>>> the key pair used to launch the instance created by jclouds. I'm not
>>>>>>>>> sure how to confirm this for sure - is the jclouds keypair stored
>>>>>>>>> anywhere that can be used to test this?
>>>>>>>>>
>>>>>>>>> Thanks again for your help,
>>>>>>>>>
>>>>>>>>> Joris
>>>>>>>>>
>>>>>>>>> On Wed, Aug 24, 2011 at 7:49 PM, Andrei Savu <savu.and...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>> I'm not sure but it looks like an auth issue to me. Whirr creates
>>>>>>>>>> it's
>>>>>>>>>> own key pair using the local SSH keys as specified in the properties
>>>>>>>>>> file.
>>>>>>>>>>
>>>>>>>>>> You've created the custom ami by taking an EBS snapshot? Can you use
>>>>>>>>>> that custom ami with a different key pair?
>>>>>>>>>>
>>>>>>>>>> -- Andrei Savu / andreisavu.ro
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Aug 24, 2011 at 7:31 PM, Joris Poort <gpo...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> Andrei - thanks for the response!
>>>>>>>>>>>
>>>>>>>>>>> I logged into the custom AMI using ssh and a key pair on my local
>>>>>>>>>>> machine (I'm executing whirr via ubuntu virtual machine). I've
>>>>>>>>>>> tried
>>>>>>>>>>> both spot instances and regular instances and am getting the same
>>>>>>>>>>> behavior.
>>>>>>>>>>>
>>>>>>>>>>> Full output on terminal looks like (lines between "Starting 1 node"
>>>>>>>>>>> and "Dying because" are not always there):
>>>>>>>>>>> Starting 1 node(s) with roles [hadoop-datanode, hadoop-tasktracker]
>>>>>>>>>>> Starting 1 node(s) with roles [hadoop-namenode, hadoop-jobtracker]
>>>>>>>>>>> Dying because - net.schmizz.sshj.transport.TransportException:
>>>>>>>>>>> Broken
>>>>>>>>>>> transport; encountered EOF
>>>>>>>>>>> Dying because - net.schmizz.sshj.transport.TransportException:
>>>>>>>>>>> Broken
>>>>>>>>>>> transport; encountered EOF
>>>>>>>>>>> <<kex done>> woke to: net.schmizz.sshj.transport.TransportException:
>>>>>>>>>>> Broken transport; encountered EOF
>>>>>>>>>>> << (root@174.129.128.120:22) error acquiring
>>>>>>>>>>> SSHClient(root@174.129.128.120:22): Broken transport; encountered
>>>>>>>>>>> EOF
>>>>>>>>>>> net.schmizz.sshj.transport.TransportException: Broken transport;
>>>>>>>>>>> encountered EOF
>>>>>>>>>>> at net.schmizz.sshj.transport.Reader.run(Reader.java:70)
>>>>>>>>>>> Dying because - java.net.SocketTimeoutException: Read timed out
>>>>>>>>>>> Dying because - java.net.SocketTimeoutException: Read timed out
>>>>>>>>>>> Dying because - java.net.SocketTimeoutException: Read timed out
>>>>>>>>>>> Dying because - java.net.SocketTimeoutException: Read timed out
>>>>>>>>>>>
>>>>>>>>>>> Last few entries on whirr.log:
>>>>>>>>>>> 2011-08-24 19:20:05,428 DEBUG [jclouds.compute] (pool-3-thread-2) >>
>>>>>>>>>>> requesting 1 spot instances region(us-east-1) price(0.250000)
>>>>>>>>>>> spec([instanceType=m1.large, imageId=ami-d1e525b8, kernelId=null,
>>>>>>>>>>> ramdiskId=null, availabilityZone=null,
>>>>>>>>>>> keyName=jclouds#hadoop_custom_spot_1#us-east-1#45,
>>>>>>>>>>> securityGroupIdToNames={}, blockDeviceMappings=[],
>>>>>>>>>>> securityGroupIds=[],
>>>>>>>>>>> securityGroupNames=[jclouds#hadoop_custom_spot_1#us-east-1],
>>>>>>>>>>> monitoringEnabled=null, userData=null]) options([formParameters={}])
>>>>>>>>>>> 2011-08-24 19:20:05,642 DEBUG [jclouds.compute] (pool-3-thread-4) <<
>>>>>>>>>>> started instances([region=us-east-1, name=sir-4f589c11])
>>>>>>>>>>> 2011-08-24 19:20:05,682 DEBUG [jclouds.compute] (pool-3-thread-2) <<
>>>>>>>>>>> started instances([region=us-east-1, name=sir-59cec612])
>>>>>>>>>>> 2011-08-24 19:20:05,864 DEBUG [jclouds.compute] (pool-3-thread-4) <<
>>>>>>>>>>> present instances([region=us-east-1, name=sir-4f589c11])
>>>>>>>>>>> 2011-08-24 19:20:05,917 DEBUG [jclouds.compute] (pool-3-thread-2) <<
>>>>>>>>>>> present instances([region=us-east-1, name=sir-59cec612])
>>>>>>>>>>> 2011-08-24 19:27:18,150 DEBUG [jclouds.compute] (user thread 8) >>
>>>>>>>>>>> blocking on socket [address=50.17.135.8, port=22] for 600000 seconds
>>>>>>>>>>> 2011-08-24 19:27:21,132 DEBUG [jclouds.compute] (user thread 7) >>
>>>>>>>>>>> blocking on socket [address=174.129.128.120, port=22] for 600000
>>>>>>>>>>> seconds
>>>>>>>>>>> 2011-08-24 19:27:24,222 DEBUG [jclouds.compute] (user thread 7) <<
>>>>>>>>>>> socket [address=174.129.128.120, port=22] opened
>>>>>>>>>>> 2011-08-24 19:27:32,255 DEBUG [jclouds.compute] (user thread 8) <<
>>>>>>>>>>> socket [address=50.17.135.8, port=22] opened
>>>>>>>>>>>
>>>>>>>>>>> After ssh onto node, didn't find any logs in /tmp.
>>>>>>>>>>>
>>>>>>>>>>> Thanks again for any help on this!
>>>>>>>>>>>
>>>>>>>>>>> Joris
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Aug 24, 2011 at 7:12 PM, Andrei Savu
>>>>>>>>>>> <savu.and...@gmail.com> wrote:
>>>>>>>>>>>> I suspect this is an authentication issue. How do you login to the
>>>>>>>>>>>> custom AMI?
>>>>>>>>>>>>
>>>>>>>>>>>> Also check whirr.log for more details and on the remote machines
>>>>>>>>>>>> look
>>>>>>>>>>>> in /tmp for jclouds script execution logs.
>>>>>>>>>>>>
>>>>>>>>>>>> I know from IRC that you are using spot instances. Are you seeing
>>>>>>>>>>>> the
>>>>>>>>>>>> same behavior with regular ones?
>>>>>>>>>>>>
>>>>>>>>>>>> -- Andrei Savu / andreisavu.ro
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Aug 24, 2011 at 7:07 PM, Joris Poort <gpo...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm new to whirr and I'm running custom AMI configuration
>>>>>>>>>>>>> (application
>>>>>>>>>>>>> installed on working canonical image). Executing with whirr 0.6.0
>>>>>>>>>>>>> everything executes fine until I get the following error:
>>>>>>>>>>>>> "Dying because - java.net.SocketTimeoutException: Read timed out"
>>>>>>>>>>>>>
>>>>>>>>>>>>> The instances are running fine, I can ssh into them, but the whirr
>>>>>>>>>>>>> code stalls and I get the above error (2x number of instances), no
>>>>>>>>>>>>> proxy shell is created. If I run the exact same code with vanilla
>>>>>>>>>>>>> canonical images I don't have any issues.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Anyone have any ideas on things to test, debug or work around
>>>>>>>>>>>>> this?
>>>>>>>>>>>>> Would really appreciate it!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Joris
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> PGP KeyID: 2048R/EA31CFC9 subkeys.pgp.net
>>
>
