Check this presentation:
http://www.oscon.com/oscon2011/public/schedule/detail/19214
The ZooKeeper service should be easy to understand.
Cheers,
-- Andrei Savu / andreisavu.ro
On Thu, Aug 25, 2011 at 12:41 AM, Joris Poort <gpo...@gmail.com> wrote:
> Does anyone know a good simple whirr service code to use as a base to
> learn to write your own? Kind of new to this so would really
> appreciate it.
>
> Cheers,
>
> Joris
>
> On Thu, Aug 25, 2011 at 12:16 AM, Joris Poort <gpo...@gmail.com> wrote:
>> 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
>>>>>
>>>>
>>>
>>
>
