Thanks for the recommendation on whirr services code, I think that
will work - looking into how to do it now.
Thanks again Andrei - really appreciate your help on all this.
Cheers,
Joris
On Wed, Aug 24, 2011 at 11:49 PM, Andrei Savu <savu.and...@gmail.com> wrote:
> 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
>>>
>>
>
