The warning message printed by the first ssh attempt indicates that you have no cloudman_key_pair.pem in the directory you executed the ssh command from. Find this file (or create a new one) and you'll be able to ssh.
Good luck, and please keep threads on the list instead of emailing directly. Thanks!
-Dannon
On Mon, Jul 22, 2013 at 1:36 PM, denizere@gmail.com wrote:
Hi- the share string appears to be loading, but I am unable to ssh into my instance using the provided command, or anything like it. Instead I get the following:
denizerezyilmaz$ ssh -i cloudman_key_pair.pem ubuntu@ec2-54-242-61-164.compute-1.amazonaws.com Warning: Identity file cloudman_key_pair.pem not accessible: No such file or directory.
OR:
denizerezyilmaz$ ssh ec2-54-242-61-164.compute-1.amazonaws.com Permission denied (publickey).
What am I missing? Thank you, Deniz
Hi- while I was able to solve the share string problem, the share string has stopped working again. In addition, I am unable to increase disk size either through the CloudMan console or a dialog box that appears before the cloudman console. Below are the cluster status logs. The Disk status remains at 0/0 (0%) no matter what I do. So far I've waited half an hour for the string to load. Has the workaround been taken apart?
- 15:14:12 - Master starting - 15:14:14 - Completed initial cluster configuration. This seems to be a new cluster; waiting to configure the type - 15:14:18 - SGE prerequisites OK; starting the service - 15:14:22 - Configuring SGE... - 15:14:30 - Successfully setup SGE; configuring SGE - 15:14:38 - Saved file 'persistent_data.yaml' to bucket 'cm-c8e9b0bd6c2cb077aa1640d64187f582' - 15:14:39 - Saved file 'cm_boot.py' to bucket 'cm-c8e9b0bd6c2cb077aa1640d64187f582' - 15:14:40 - Saved file 'cm.tar.gz' to bucket 'cm-c8e9b0bd6c2cb077aa1640d64187f582' - 15:14:40 - Saved file 'Kenchoice.clusterName' to bucket 'cm-c8e9b0bd6c2cb077aa1640d64187f582' - 15:17:05 - Initializing a 'Galaxy' cluster. - 15:17:06 - Retrieved file 'snaps.yaml' from bucket 'gxy-workshop' to 'cm_snaps.yaml'. - 15:17:09 - Saved file 'persistent_data.yaml' to bucket 'cm-c8e9b0bd6c2cb077aa1640d64187f582'
On Mon, Jul 22, 2013 at 5:04 PM, Dannon Baker dannon.baker@gmail.comwrote:
The warning message printed by the first ssh attempt indicates that you have no cloudman_key_pair.pem in the directory you executed the ssh command from. Find this file (or create a new one) and you'll be able to ssh.
Good luck, and please keep threads on the list instead of emailing directly. Thanks!
-Dannon
On Mon, Jul 22, 2013 at 1:36 PM, denizere@gmail.com wrote:
Hi- the share string appears to be loading, but I am unable to ssh into my instance using the provided command, or anything like it. Instead I get the following:
denizerezyilmaz$ ssh -i cloudman_key_pair.pem ubuntu@ec2-54-242-61-164.compute-1.amazonaws.com Warning: Identity file cloudman_key_pair.pem not accessible: No such file or directory.
OR:
denizerezyilmaz$ ssh ec2-54-242-61-164.compute-1.amazonaws.com Permission denied (publickey).
What am I missing? Thank you, Deniz
Hi- there is a new problem: started 07/24/2013 21:16:27 ./test_dependencies.sh All required executables found in PATH All required R packages are installed Required module not found: /mnt/galaxyData/custom/bin/python_libs/lib/python/pysam-0.6-py2.7-linux-x86_64.egg/csamtools.so: undefined symbol: PyCapsule_New Error in ./test_dependencies.sh: 256 at msg/Utils.pm line 25.
On Mon, Jul 22, 2013 at 5:04 PM, Dannon Baker dannon.baker@gmail.comwrote:
The warning message printed by the first ssh attempt indicates that you have no cloudman_key_pair.pem in the directory you executed the ssh command from. Find this file (or create a new one) and you'll be able to ssh.
Good luck, and please keep threads on the list instead of emailing directly. Thanks!
-Dannon
On Mon, Jul 22, 2013 at 1:36 PM, denizere@gmail.com wrote:
Hi- the share string appears to be loading, but I am unable to ssh into my instance using the provided command, or anything like it. Instead I get the following:
denizerezyilmaz$ ssh -i cloudman_key_pair.pem ubuntu@ec2-54-242-61-164.compute-1.amazonaws.com Warning: Identity file cloudman_key_pair.pem not accessible: No such file or directory.
OR:
denizerezyilmaz$ ssh ec2-54-242-61-164.compute-1.amazonaws.com Permission denied (publickey).
What am I missing? Thank you, Deniz
Hi- I'm wondering if the share string problem will be fixed this week. The workaround doesn't seem to work and I have needed to analyze my data for almost a month. When I try to start the run:
ubuntu@ip-10-218-95-180:/mnt/galaxyData/custom/MY_MSG_RUN$ perl msg/msgCluster.pl
I get:
started 07/24/2013 21:16:27 ./test_dependencies.sh All required executables found in PATH All required R packages are installed Required module not found: /mnt/galaxyData/custom/bin/python_libs/lib/python/pysam-0.6-py2.7-linux-x86_64.egg/csamtools.so: undefined symbol: PyCapsule_New Error in ./test_dependencies.sh: 256 at msg/Utils.pm line 25.
I am guessing that the workaround is missing something python.
Thanks, Deniz
On Mon, Jul 22, 2013 at 5:04 PM, Dannon Baker dannon.baker@gmail.comwrote:
The warning message printed by the first ssh attempt indicates that you have no cloudman_key_pair.pem in the directory you executed the ssh command from. Find this file (or create a new one) and you'll be able to ssh.
Good luck, and please keep threads on the list instead of emailing directly. Thanks!
-Dannon
On Mon, Jul 22, 2013 at 1:36 PM, denizere@gmail.com wrote:
Hi- the share string appears to be loading, but I am unable to ssh into my instance using the provided command, or anything like it. Instead I get the following:
denizerezyilmaz$ ssh -i cloudman_key_pair.pem ubuntu@ec2-54-242-61-164.compute-1.amazonaws.com Warning: Identity file cloudman_key_pair.pem not accessible: No such file or directory.
OR:
denizerezyilmaz$ ssh ec2-54-242-61-164.compute-1.amazonaws.com Permission denied (publickey).
What am I missing? Thank you, Deniz
On Thu, Jul 25, 2013 at 4:47 PM, Deniz Erezyilmaz denizere@gmail.comwrote:
The workaround doesn't seem to work
Can you tell me what happens when you launch with the workaround mentioned previously ( https://main.g2.bx.psu.edu/cloudlaunch?ami=ami-da58aab3&bucket_default=g...
This should launch the pre-migration AMI and Cloudman and shouldn't have any issues at all unless your cluster was already wonky.
-Dannon
Dannon- the problems that I saw were with the workaround (see last post). The instance launches, but the program stops when it can't find something (module/dependencies).
There were also some different steps in setting up the instance. I had to create my own key pair, whereas in the past I never had to do that. I guess that simply using the share string that Greg at Janelia created made this step automatic.
The cluster was working well at the end of June. The problem arose suddenly Saturday June 29, when the share string would not load. Thanks again, Deniz
On Thu, Jul 25, 2013 at 5:19 PM, Dannon Baker dannon.baker@gmail.comwrote:
On Thu, Jul 25, 2013 at 4:47 PM, Deniz Erezyilmaz denizere@gmail.comwrote:
The workaround doesn't seem to work
Can you tell me what happens when you launch with the workaround mentioned previously ( https://main.g2.bx.psu.edu/cloudlaunch?ami=ami-da58aab3&bucket_default=g...
This should launch the pre-migration AMI and Cloudman and shouldn't have any issues at all unless your cluster was already wonky.
-Dannon
Ahh, ok, I misunderstood and thought you were saying there was a different error for the workaround. Are you able to send me the share string (directly if you want, feel free to drop the list) so that I might take a look? There should be no change at all in your instances from before the new release when using the workaround.
On Fri, Jul 26, 2013 at 8:17 AM, Deniz Erezyilmaz denizere@gmail.comwrote:
Dannon- the problems that I saw were with the workaround (see last post). The instance launches, but the program stops when it can't find something (module/dependencies).
There were also some different steps in setting up the instance. I had to create my own key pair, whereas in the past I never had to do that. I guess that simply using the share string that Greg at Janelia created made this step automatic.
The cluster was working well at the end of June. The problem arose suddenly Saturday June 29, when the share string would not load. Thanks again, Deniz
On Thu, Jul 25, 2013 at 5:19 PM, Dannon Baker dannon.baker@gmail.comwrote:
On Thu, Jul 25, 2013 at 4:47 PM, Deniz Erezyilmaz denizere@gmail.comwrote:
The workaround doesn't seem to work
Can you tell me what happens when you launch with the workaround mentioned previously ( https://main.g2.bx.psu.edu/cloudlaunch?ami=ami-da58aab3&bucket_default=g...
This should launch the pre-migration AMI and Cloudman and shouldn't have any issues at all unless your cluster was already wonky.
-Dannon
HI - did you find anything with the share string? Thanks, Deniz
On Fri, Jul 26, 2013 at 3:32 PM, Dannon Baker dannon.baker@gmail.comwrote:
Ahh, ok, I misunderstood and thought you were saying there was a different error for the workaround. Are you able to send me the share string (directly if you want, feel free to drop the list) so that I might take a look? There should be no change at all in your instances from before the new release when using the workaround.
On Fri, Jul 26, 2013 at 8:17 AM, Deniz Erezyilmaz denizere@gmail.comwrote:
Dannon- the problems that I saw were with the workaround (see last post). The instance launches, but the program stops when it can't find something (module/dependencies).
There were also some different steps in setting up the instance. I had to create my own key pair, whereas in the past I never had to do that. I guess that simply using the share string that Greg at Janelia created made this step automatic.
The cluster was working well at the end of June. The problem arose suddenly Saturday June 29, when the share string would not load. Thanks again, Deniz
On Thu, Jul 25, 2013 at 5:19 PM, Dannon Baker dannon.baker@gmail.comwrote:
On Thu, Jul 25, 2013 at 4:47 PM, Deniz Erezyilmaz denizere@gmail.comwrote:
The workaround doesn't seem to work
Can you tell me what happens when you launch with the workaround mentioned previously ( https://main.g2.bx.psu.edu/cloudlaunch?ami=ami-da58aab3&bucket_default=g...
This should launch the pre-migration AMI and Cloudman and shouldn't have any issues at all unless your cluster was already wonky.
-Dannon
Yes, I tried it and everything appeared to load fine using the url indicated above. The data volume was mounted correctly, and it appears the custom installation is in place though I would have no idea what it is or does.
Did you install all the custom stuff originally? If not, it may be useful to talk to the person that did to find out if they're able to poke at it. That file that's indicated as missing (csamtools.so) is actually there if you take a look, and I'd expect it should all work if initialized correctly.
On Tue, Jul 30, 2013 at 10:10 AM, Deniz Erezyilmaz denizere@gmail.comwrote:
HI - did you find anything with the share string? Thanks, Deniz
On Fri, Jul 26, 2013 at 3:32 PM, Dannon Baker dannon.baker@gmail.comwrote:
Ahh, ok, I misunderstood and thought you were saying there was a different error for the workaround. Are you able to send me the share string (directly if you want, feel free to drop the list) so that I might take a look? There should be no change at all in your instances from before the new release when using the workaround.
On Fri, Jul 26, 2013 at 8:17 AM, Deniz Erezyilmaz denizere@gmail.comwrote:
Dannon- the problems that I saw were with the workaround (see last post). The instance launches, but the program stops when it can't find something (module/dependencies).
There were also some different steps in setting up the instance. I had to create my own key pair, whereas in the past I never had to do that. I guess that simply using the share string that Greg at Janelia created made this step automatic.
The cluster was working well at the end of June. The problem arose suddenly Saturday June 29, when the share string would not load. Thanks again, Deniz
On Thu, Jul 25, 2013 at 5:19 PM, Dannon Baker dannon.baker@gmail.comwrote:
On Thu, Jul 25, 2013 at 4:47 PM, Deniz Erezyilmaz denizere@gmail.comwrote:
The workaround doesn't seem to work
Can you tell me what happens when you launch with the workaround mentioned previously ( https://main.g2.bx.psu.edu/cloudlaunch?ami=ami-da58aab3&bucket_default=g...
This should launch the pre-migration AMI and Cloudman and shouldn't have any issues at all unless your cluster was already wonky.
-Dannon
Yes- I know that it loads in the workaround that you created, but it doesn't run. The non-workaround version running fine until the last Saturday of June. I know that Greg, who installed it, hasn't touched it in months. Could this be related to the update that was recently completed? That was supposed to be fixed last week. Is there any news? Thanks, Deniz
On Tue, Jul 30, 2013 at 11:35 AM, Dannon Baker dannon.baker@gmail.comwrote:
Yes, I tried it and everything appeared to load fine using the url indicated above. The data volume was mounted correctly, and it appears the custom installation is in place though I would have no idea what it is or does.
Did you install all the custom stuff originally? If not, it may be useful to talk to the person that did to find out if they're able to poke at it. That file that's indicated as missing (csamtools.so) is actually there if you take a look, and I'd expect it should all work if initialized correctly.
On Tue, Jul 30, 2013 at 10:10 AM, Deniz Erezyilmaz denizere@gmail.comwrote:
HI - did you find anything with the share string? Thanks, Deniz
On Fri, Jul 26, 2013 at 3:32 PM, Dannon Baker dannon.baker@gmail.comwrote:
Ahh, ok, I misunderstood and thought you were saying there was a different error for the workaround. Are you able to send me the share string (directly if you want, feel free to drop the list) so that I might take a look? There should be no change at all in your instances from before the new release when using the workaround.
On Fri, Jul 26, 2013 at 8:17 AM, Deniz Erezyilmaz denizere@gmail.comwrote:
Dannon- the problems that I saw were with the workaround (see last post). The instance launches, but the program stops when it can't find something (module/dependencies).
There were also some different steps in setting up the instance. I had to create my own key pair, whereas in the past I never had to do that. I guess that simply using the share string that Greg at Janelia created made this step automatic.
The cluster was working well at the end of June. The problem arose suddenly Saturday June 29, when the share string would not load. Thanks again, Deniz
On Thu, Jul 25, 2013 at 5:19 PM, Dannon Baker dannon.baker@gmail.comwrote:
On Thu, Jul 25, 2013 at 4:47 PM, Deniz Erezyilmaz denizere@gmail.comwrote:
The workaround doesn't seem to work
Can you tell me what happens when you launch with the workaround mentioned previously ( https://main.g2.bx.psu.edu/cloudlaunch?ami=ami-da58aab3&bucket_default=g...
This should launch the pre-migration AMI and Cloudman and shouldn't have any issues at all unless your cluster was already wonky.
-Dannon
galaxy-dev@lists.galaxyproject.org
-
Dannon Baker -
Deniz Erezyilmaz