aws

Today we noticed a weird error where our CMS software was unable to write files to the server. Upon investigating, it appears the /tmp directory filled up the hard drive, which prevented file writes to the server. We rebooted the server and it took 20-30 minutes to reboot. The AWS boot logs were saying: "A start job is running for Create Volatile files and directories" As it turns out, the /tmp directory is only cleared on reboot.

Not sure what happened with GlusterFS tonight. Around 19:07 EST, the AWS alarm sounded. After rebooting the GlusterFS servers and the web servers, nothing was bringing the sites back online. There was a terrible lag when accessing the GlusterFS file systems and there weren't any glaring errors in the log files. In an effort to get the sites loading again, I began making an archive all of the files from the GlusterFS server mount point and was planning to copy them onto the main web server (web1).

Today I was trying to setup a site behind an Elastic Load Balancer (ELB) on Amazon's EC2. I was able to set the configuration array to on in settings.php:

$conf['reverse_proxy'] = TRUE;

However, ELB's within AWS are setup to auto scale, which in turn can make their IP addresses change.

While using Amazon's AWS system, we needed to give access to one S3 bucket. Todo so, we ended up using Amazon's IAM.

In a related note to the backup restore that I performed yesterday, I decided to run the upgrade.sh script provided by community.aegir.com. First, I downloaded the script to my restored EC2 instance wget -O upgrade.sh 'http://drupalcode.org/project/provision.git/blob_plain/refs/tags/6.x-1.6:/upgrade.sh.txt' Next I logged in as the Aegir user and ran the uprade.sh script per the instructions: su -s /bin/sh aegir -c "sh upgrade.sh" The status message displayed ment

Today I had the unfortunate need to get a restored database from an Amazon EBS snapshot. To do this I logged into the Amazon AWS management console and determined which snapshot I needed to restore from. Once I highlighted the correct snapshot, I clicked the 'Create Volume' button. Next, I chose which availability zone the snapshot should reside in and click 'Create' Next, I spun up a new instance of the production server, using the same AMI (ami-294aa340).