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
http://www.linuxconfig.org/Howto_CREATE_BUNDLE_UPLOAD_and_ACCESS_custom_Debian_AMI_using_ubuntu
. 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.
Best,
Steffen
Reply to: