[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Debian-Med on Amazon's EC2 : works

Dear all,

I was probably one of the first to have registered with the EC2, but never got around
actually testing it. I just made myself the present to dedicate some time into prepared a
Debian-Med Amazon Machine Image (AMI) and then running it ... it works.

$ ec2-describe-images
IMAGE   ami-4859bd21    linux-debian-med-sid/debian-med-ami.manifest.xml
166691755018    available       private         i386  machine
$ ec2-run-instances ami-4859bd21
RESERVATION     r-bd12bdd4      166691755018    default
INSTANCE        i-e561da8c      ami-4859bd21                    pending         0
      m1.small        2008-12-25T19:29:34+0000       us-east-1b
$ ec2-describe-instances i-e561da8c
RESERVATION     r-bd12bdd4      166691755018    default
INSTANCE        i-e561da8c      ami-4859bd21                    pending         0
      m1.small        2008-12-25T19:29:34+0000       us-east-1b
# waiting some 180 seconds
$ ec2-describe-instances
RESERVATION     r-bd12bdd4      166691755018    default
INSTANCE        i-e561da8c      ami-4859bd21    ec2-67-202-7-129.compute-1.amazonaws.com
      domU-12-31-39-03-00-21.compute-1.internal      running         0
m1.small        2008-12-25T19:29:34+0000        us-east-1b
$ ssh root@ec2-67-202-7-129.compute-1.amazonaws.com
# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1              3023760   1093384   1776776  39% /
tmpfs                   870472         0    870472   0% /lib/init/rw
tmpfs                   870472         4    870468   1% /dev/shm
# cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 65
model name      : Dual-Core AMD Opteron(tm) Processor 2218 HE
stepping        : 3
cpu MHz         : 2599.998
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush mmx fxsr sse
sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm
cr8legacy ts fid vid ttp tm stc
bogomips        : 5202.22

# exit

$ ec2-terminate-instances i-e561da8c
INSTANCE        i-e561da8c      running shutting-down

Seems like I gave it a bit too much disk estate. But that thing was always very responsive
and the specs seem rather nice. I added the boinc packages, with >300K/second from
ftp.de.debian.org, although having the server in the US :)  But I failed to get X
forwarded to my machine through ssh.  I would use it for distributed computing

Amazon started offering a series of biological or chemical public databases. I wrote to
them that they should please consider assist us in adapting Debian-Med to help accessing
these resources. I mean, we basically have everything, Amazon would only need to also
provide the indices for the data they offer. And Debian-Med needs to learn about how to
add these to their instances.

I made the image accessible to you all

$ ec2-modify-image-attribute ami-4859bd21  --launch-permission -a all
launchPermission        ami-4859bd21    ADD     group   all
$ ec2-describe-image-attribute ami-4859bd21 -l
launchPermission        ami-4859bd21    group   all

but have set a root password, still, so the image is not worth much for you. Please
contact me for it.

I am still reading through
http://docs.amazonwebservices.com/AWSEC2/2008-12-01/GettingStartedGuide/ and the
accompanying developers guide.
Some more reading should allow me in some overseeable time to come up with another version
that can be shared more easily between us and the rest of the world, which should then
also appear on the Amazon resources list.

While I was googling along, I also came across this fine work on http://alestic.com/. It
basically put into a script what was described in the Amazon docs or on
. I should rerun my effort with that script.

>From my current perspective, anyone who is interested only in running only on very few
instances something remotely, one can probably just use any of the minimal Debian/Ubuntu
AMIs and install the lacking packages for every instance that is started. However, when
running on several hundreds of instances, one may prefer to fall back on more complex
ones.  However, the main challenge from my perspective now is to ease the dealing with
those instances to allow them to substitute a local CPU farm. This needs some more thought.



Reply to: