One of the things that is really lovely about cloud computing is the ability to test relatively quickly and easily test something new, before diving in and breaking a "real" server. In this case, an upgrade from Debian Lenny to Debian Squeeze. With about two years between the average Debian release, there is much opportunity for something to break when trying to jump such a large computing chasm.
Unfortunately, Debian is not so well, and definitely not formally, supported in the Amazon AWS environment. Here is how I went about it....
There are actually a handful (3?) of Debian Lenny EBS images in AWS us-east region at the moment. I had a look at them all and, as I recall, selected public ami-9a6b9af3 for my test. It has a 10G EBS root file system, and a very basic Debian install onboard. (Note that using an informal public AMI like this is a security risk, as there is no way to be sure nothing malicious has been installed in the image.)
To kick off a instance and have a look at it:
ec2-run-instances -k clayton -t t1.micro ami-9a6b9af3Login to the instance and make any desired modifications. (apt-get upgrade, install software, etc....) Then stop the instance:
Snapshot it's volume and create a new private image (you can get the volume name from ec2-describe-instances):
SNAPSHOT snap-fa4ce59a vol-ac46eac6 pending
Now register a new, private Debian Lenny AMI to work with going forward:
ec2-register -a x86_64 -b '/dev/sda1=snap-fa4ce59a:10:false' -n 'Lenny_64_Lenny_kernel' -d '64 bit Lenny with Lenny kernel' --kernel="aki-68bb5901" --ramdisk="ari-6cbb5905"
Now start up a new instance to make sure the image we made actually works:
ec2-run-instances -k clayton -t t1.micro ami-db13d3b2
INSTANCE i-35acaf54 ami-db13d3b2 pending
# uname -a Linux ip-10-244-177-141.ec2.internal 2.6.24-10-xen #1 SMP Tue Sep 8 18:30:05 UTC 2009 x86_64 GNU/Linux
I went ahead at this point and verified that the above Lenny kernel WOULD NOT work for an upgrade to Squeeze (because of the new udev in Squeeze).
So now create a new image based upon the previous image, this time with a Squeeze kernel which I will borrow from ami-80e915e9: aki-427d952b
ec2-stop-instances i-35acaf54 INSTANCE i-35acaf54 running stopping ec2-create-snapshot vol-4ab61e20 SNAPSHOT snap-5e17be3e vol-4ab61e20 pending ec2-register -a x86_64 -b '/dev/sda1=snap-5e17be3e:10:false' -n 'Lenny_64_Squeeze_kernel' -d '64 bit Lenny with Squeeze kernel' --kernel="aki-427d952b" IMAGE ami-ab13d3c2 ec2-run-instances -k clayton -t t1.micro ami-ab13d3c2 INSTANCE i-45b9ba24 ami-ab13d3c2 pending # uname -a Linux ip-10-244-177-141.ec2.internal 2.6.26-2-xen-amd64 #1 SMP Mon Jun 13 18:44:16 UTC 2011 x86_64 GNU/Linux
And it worked: kernel aki-427d952b is compatible with both Lenny and Squeeze.
You can re-use existing SSH connections by adding this to ~/.ssh/config file:
Thereafter, after you login and open a connection to an SSH server, if you open another connection from another terminal, it will re-use the first connection. No need to login again, no need to wait for the connection to be re-negotiated. Over a slow, long-distance SSH connection, this can slow the wait time from tens of seconds to two seconds. This applies to SCP transfers as well. Much saved time.
If you have a long list of servers you log into regularly, particularly on non-standard ports, these connections can also be aliased in the ~/.ssh/config file:
Thereafter, "ssh my-chosen-alias" will connect to email@example.com on port 10122. Unfortunately SCP does not seem to respect these aliases, or at least I have not found out how to make that work. But this is a way, for instance, to transparently get backuppc to connect to a backup client using a non-standard port.Host my-chosen-alias Hostname server.com IdentityFile /path/to/id_rsa User root Port 10122