I could not ssh in to one of my AWS instances last evening and it wasn’t serving any pages either. AWS management console said it was up, though. Rebooting did not help. The second reboot did not help either. Shutdown and start did not help. I was running out of tricks here!

For some reason, the instance had been running on 100% CPU utilization for days:

(I better do some monitoring in future!)

Even though the CPU usage had dropped after the restarting, the instance would not accept any connections. The only thing I could think of was to either ping the AWS forum, or to get the running volume on some new instance as the instance was an EBS based one. I decided to go with the new volume if the database would not mind too much. Steps I needed to do were:

1. Snapshot the running volume
2. Create a new volume out of the snapshot on the same availability zone
3. Start a new instance with the Launch more like this
4. Shutdown the new instance
5. Detach the volume on the new instance
6. Attach the volume which was created from the snapshot to new instance (need to have the correct  attachment information, like /dev/sda1)
7. Start the new instance
8. Disassociate the Elastic IP from the old instance
9. Associate the correct Elastic IP on the new instance
10. Test and wish for the best

This actually worked and did not even take too much time. Actually, really cool when thinking about this and imagining I would have had a physical server instead…

I, as well as many others, received today an email from Amazon about the need to reboot one of my instances. Actually, Twitter was already aware of this and was a bit upset of the need. For me, this was the second time since 2009 when Amazon has asked to reboot one of my instances. Once the HW was degraded and now this. I would say it’s quite a decent score since I have averaged something like five instances running all the time.

I am not upset, on the contrary I am happy AWS keeping the infrastructure up to date, be the reason for the reboot what ever. Besides, the systems should be designed so, that rebooting an instance should not take the service down, if you don’t accept it (like I do).

The actual process how AWS did inform the customers did feel ok. At first it was of course just rumours, but then I received an email stating the need which gave an acceptable time to react. When I logged in to the AWS Dashboard, I saw this kind of a message:

Which had a link to further information:

And even more information:

There was an option to do the reboot right now if I wanted, so I did it. At first after the reboot, I was looking at the instance in the dashboard, but the notification icon was still there. I would have thought it would disappear. Then I had a look of the details of the event and it actually had [Completed] written infront of the event:

Which now probably means it’s ok and I am done with this.

I just realized AWS has a feature called the CloudFormation which allows users to script their technology stack in a convenient and easily understood JSON formatted text files which can then be used to deploy the stack over and over again, always the same way. Fantastic! This eases a the burden of managing a bunch of customized AMIs or other ways of having some custom features introduced to the AMIs. I wonder how I did not notice this feature before. It even has a tab in the AWS Management Console. There are also some sample templates which for example install Drupal or a basic Ruby Hello World example.

As a test, I ran the Drupal installation script and I have to say this was by far the easiest Drupal installation I have ever done. From start to finish in 5 minutes where most of it was just waiting for the deploy to finish. Absolutely great! Minor thing might be to remember that the security keys are not available in all the Regions, at least not in US East (Virginia) my keys were not available which caused the stack deployment to fail without any good reason except key was not found… I was of course first thinking of a typo in the key name. The other thing is that the user must know the instance type name, such as t1.micro while a drop down menu would be great.

There is also a possibility to modify an existing stack which is actually a relatively new feature. This makes it even more usable. It would be interesting to see if I could do a stack for a simple Aegir installation as lately that’s the platform I have been installing the most and doing the manual installation has become kind of boring. CloudFormation would help lot with that!

In case you ever need to migrate a site from some other Aegir installation to a different one, you can follow the instructions here. If you are like me, who has little time between day time job, looking after a kid and sleeping, you tend to skip to the section where it has the code you need to copy-paste-edit. Well, if you get something like this when executing your pasted code:

PHP Fatal error: Allowed memory size of 201326592 bytes exhausted (tried to allocate 20 bytes) in /var/aegir/.drush/provision/provision.context.inc on line 31

Fatal error: Allowed memory size of 201326592 bytes exhausted (tried to allocate 20 bytes) in /var/aegir/.drush/provision/provision.context.inc on line 31
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Allowed memory size of 201326592 bytes exhausted (tried to
allocate 20 bytes) in /var/aegir/.drush/provision/provision.context.inc,
line 31


You had the platform name wrong because you thought it would be the same as the one you gave it when you created it. It’s not. Do this:

drush sa | grep platform

To find the real name of the platform and rerun your command and it should work.

Today’s breaking news have been Bloomberg’s story about the Sony PSN attack been conducted by using Amazon Web Services. I read the story and feel confused, like how on earth can the source of the servers be any kind of relevancy if they’ve been using a public cloud provider? Come on, Amazon can’t and really should not, follow what their customers do with their servers. This whole thing Bloomberg is writing about is like saying the bank was robbed by a Smith&Wesson and it was Smith&Wesson’s fault.

Of course, there will be a subpoena for getting all the information of the account used in managing the account and I guess they had to use some stolen credit card as well which is interesting. Also, the statement in the Bloomberg’s article about anyone anonymously going and getting an account in AWS is kind of not totally true. Maybe it can be managed somehow if using a stolen credit card, but it’s not an anonymous service as such. And how are you going to prevent that “flaw” in the system of the possibility using stolen cards and false identities? Scan your id and send that as well or visit them at AWS personally? Huh?

In the end of the article, there is a thought-provoking paragraph of “Rethinking the Cloud” because a cloud can be used also for malicious purposes. Yep. I’ll do think about this for a while…

Thinking…

Thinking…

…and it should not matter for the most parts. Say, the whole AWS would be used only for attacks and the service level would degrade and my IPs would be black listed, then I probably would switch to some other provider, but, right now, I am not worried the least bit. I have my application and the service level I need in a good and healthy balance.

Summer is almost here and it was really the time to clean up my blog a bit. Now there is a much more readable theme and all the CityDeal hamburger campaigns are gone. Hopefully nobody will be missing those?

I’ve been writing already about deploying applications instead of virtual machines and how I would like to move away from the machine instance and to a some kind of a service where you could select a system and the service would deploy and manage the needed computing resources. It now seems like this is starting to become a reality as there are providers like DotCloud and PHP Fog who take care of the infra while the customer just deploys the code.

I requested a beta invite to DotCloud which in contrary to PHP Fog is somewhat more multipurpose with other services than the PHP only. Actually, currently they have java, mysql, nodejs, perl, php, php-worker, postgresql, python, python-worker, rabbitmq, redis, ruby, ruby-worker, smtp, static as the deployment options. They also have some nice tutorials about how to use the system. The system is operated mostly locally from CLI and the code is pushed to dotcloud which seems like a nice way to do it as it is analogous to for example editing files locally and then using FTP to transfer the files to a web server.

As a test run, I went with installing WordPress as there is a good tutorial for that and only a few minutes later I had a running blog in DotCloud. I’m really liking this!

Quora is down, Reddit is in emergency read only mode. Quite severe this is then!

According to the first investigation (from the AWS health dashboard) the reason for outage was a networking event which caused a large number of EBS volumes being re-mirrored. This caused capacity problems in the affected region. Also there were problems with one control plane which made it difficult to create new EBS volumes and instances. Control plane is a piece of router architecture which is responsible of drawing the network map, if you did not know it… I certainly did not know before.

Of course, there are plenty of other services impacted by the outage and I guess this is a great time to see how different services have been designed to sustain a degradation of some underlying components. Quora is totally dead (well, there is the notification to users) and Reddit is in read only mode. I give my points to Reddit as they have managed to fail gracefully to a cached read only mode.

Funny thing, just today I was reading a text by James Hamilton which is spot on this situation. I need to say I am surprised Quora did not have a fail over to a different location as the other location in US seems to be ok.

I wanted to get a fi-domain as I am building a site for our housing company. It’s very much a pro bono work, but interesting nevertheless. To be honest, this is the first time I have to register a fi-domain and man, it’s not as easy as getting a com or similar domain with DynDNS etc. You need to be a Finnish citizen to be allowed to get one for starters and made sure you are not violating any possible trademarks or even more, some real people with your domain name.

I would perhaps been ok if a DynDNS type of service would exists (well, now as I write this it probably does) in Finland, but the ones I came across were mostly just taking orders and not like dynamically updating their resources… but can’t of course be totally sure. Anyway, I decided to give Amazon Route 53 a go as it is new and I do appreciate the possibility to update the records on command line. Or well, I perhaps did not investigate really too much before signing up.

First I had to though register the fi-domain with Ficora and that took around a day to get the credentials on paper. Yes. On paper. The next step was to register the name and give them two (at this point fictious) name servers. Then I was on my way to Route 53. The first look at the Getting Started Guide is not very encouraging. Need to create some files which contain the access keys and the actual requests. Need to run a perl script to actually create the records. Good thing I bought my first Mac just a few months ago as with Windows this would have sucked.

So the first thing was to create the .aws-secret file which contains your AWS Secret Access Keys it looks something like this:

%awsSecretAccessKeys = (
“my-keys” => {
id => “JISEGIOJDFGSLSDKFG”,
key => “KSLDFSDFGSDFGSasdfsdASFDSDF”,
},
);

And it really needs to be named .aws-secret and have only read permissions as the dnscurl.pl checks this.

Then create the zone you have registered:

<CreateHostedZoneRequest xmlns=”https://route53.amazonaws.com/doc/2010-10-01/”>
<Name>YOURDOMAIN.fi.</Name>
<CallerReference>SOMETHINGRANDOMHERE</CallerReference>
<HostedZoneConfig>
<Comment>Creating first zone</Comment>
</HostedZoneConfig>
</CreateHostedZoneRequest>

Then download dnscurl.pl from the AWS developer tools and run it with these parameters:

dnscurl.pl –keyname my-keys — -X POST -H “Content-Type: text/xml; charset=UTF-8″ –upload-file MyCreateRequest.xml https://route53.amazonaws.com/2010-10-01/hostedzone

You should get something like this in return:

<CreateHostedZoneResponse xmlns=”https://route53.amazonaws.com/doc/2010-10-01/”><HostedZone><Id>/hostedzone/34LJSKFSJGSDFKJ</Id><Name>YOURDOMAIN.fi.</Name><CallerReference>JIjasdmfasfw4af3233</CallerReference><Config><Comment>Creating first zone</Comment></Config></HostedZone><ChangeInfo><Id>/change/23ILKSFJDLSK</Id><Status>PENDING</Status><SubmittedAt>2011-01-24T20:48:47.715Z</SubmittedAt></ChangeInfo><DelegationSet><NameServers><NameServer>ns-1778.awsdns-30.co.uk</NameServer><NameServer>ns-372.awsdns-44.com</NameServer><NameServer>ns-1621.awsdns-38.org</NameServer><NameServer>ns-534.awsdns-04.net</NameServer></NameServers></DelegationSet></CreateHostedZoneResponse>

Here are the real name servers which I had to give to Ficora and it happily said them being ok, so fi-domain is well supported by AWS! Yey!

Then you can start adding records to your zone. First need to create the MyRecordsRequest.xml for the records which could look like this:

<?xml version=”1.0″ encoding=”UTF-8″?>
<ChangeResourceRecordSetsRequest xmlns=”https://route53.amazonaws.com/doc/2010-10-01/”>
<ChangeBatch>
<Comment>
Create A-record
</Comment>
<Changes>
<Change>
<Action>CREATE</Action>
<ResourceRecordSet>
<Name>www.yourdomain.fi.</Name>
<Type>A</Type>
<TTL>14400</TTL>
<ResourceRecords>
<ResourceRecord>
<Value>192.0.0.111</Value>
</ResourceRecord>
</ResourceRecords>
</ResourceRecordSet>
</Change>
</Changes>
</ChangeBatch>
</ChangeResourceRecordSetsRequest>

dnscurl.pl –keyname my-keys — -H “Content-Type: text/xml; charset=UTF-8″ -X POST –upload-file ./MyRecordsRequest.xml https://route53.amazonaws.com/2010-10-01/hostedzone/34LJSKFSJGSDFKJ/rrset

And you should get a response like this:
0.0%
<?xml version=”1.0″?>
<ChangeResourceRecordSetsResponse xmlns=”https://route53.amazonaws.com/doc/2010-10-01/”><ChangeInfo><Id>/change/C3FMNWCVL1YW40</Id><Status>PENDING</Status><SubmittedAt>2011-01-25T19:16:24.181Z</SubmittedAt></ChangeInfo></ChangeResourceRecordSetsResponse>

I got a few problems with “root is not authorized to perform: route53:ChangeResourceRecordSets on resource” because I did not have ./ in front of the MyRecordsRequest.xml, so remember to have it there.

I’ve been working with Aegir recently to get some ideas how to host multiple Drupal sites in a somewhat automated and scalable way. To my surprise the performance was actually a lot better with the t1.micro instance which runs the Aegir platform than what I get from the small instance. A video below has a demo when running the identical sites on both servers:

The pageload was around 2.6 seconds with the standard Drupal installation and around a second faster with the Aegir platform. The site on Aegir was dump from the other site taken a few days ago with no significant differences. Have to say I really really like Aegir!

These are more like notes for myself, but I am happy to share if someone else would be interested. No warranties though, if you can’t get Aegir running with these notes :)

Get the packages:

yum install httpd php php-mysql php-gd mysql-server postfix sudo rsync git-core unzip alpine screen

Set the PHP.ini memory limits, 192M works ok

Fix your DNS and how your host resolves:

edit /etc/hosts

x.x.x.x FQDN hostname

hostname FQDN

Install MTA (I run Postfix, so just copypaste from other server)

upload posfix configuration to /etc/postfix

Edit the /etc/postfix/canonical

This will rewrite the name which Drupal uses to send emails to what you need

create canonical db

postmap /etc/postfix/canonical
service postfix start

Create a group for the Aegir user and which Apache uses as well:

groupadd www-data

edit /etc/httpd/conf/httpd.conf to run as www-data

The Aegir user home folder needs to have 755 as the permissions (at least this works)

adduser -r –groups www-data –home-dir /var/home/aegiruser aegiruser

Edit the httpd.conf to have the Aegir confs included

Include /var/home/providus/config/apache.conf

Edit sudoers file

aegiruser ALL=NOPASSWD: /usr/sbin/apachectl

start mysqld

/usr/bin/mysqladmin -u root password ‘password’

wget -O /tmp/install.sh ‘http://git.aegirproject.org/?p=provision.git;a=blob_plain;f=install.sh.txt;hb=provision-0.4-beta2′

./drush/drush.php dl drupal