Tiago Matos’ Nest

After you get acess to your EC2 instance via the default EC2 certificates (which you can via your AWS admin panel) using usually “ubuntu” as login name you might have to grant access to any external guy, like a web designer.

It’s not a good practise to enable password access but SSH-Keys. As this is the second time I have lost 1.5h searching for how to do this, I am detailing it here.

*on your local machine*
$ cd ~/.ssh
$ ssh-keygen -b 1024 -t dsa
Give a suitable name to your new certificate file and a password. This will generate two file, which one of them is a public key (smartly enough is the one ending in .pub).

Copy this file, let’s call it my_public_certificate.pub, to your remote EC2 instance server and append it to authorized_keys file.

*in your remote machine (EC2 instance)*
$cat my_public_certificate.pub >> /home/your_web_designer_directory/.ssh/authorized_keys

Now the *tricky* part: ensure the following directory/file permissions:
$chown 755 your_web_designer:your_web_designer /home/your_web_designer_directory
$chown 700 your_web_designer:your_web_designer /home/your_web_designer_directory/.ssh
$chown 600 your_web_designer:your_web_designer /home/your_web_designer_directory/.ssh/authorized_keys

*back on your local machine*
$ssh your_web_designer@remote_machine_IP -i ~/.ssh/my_private.certificate (not the public, hein!)

Home it saves same hour or two to anyone…

http://blog.taggesell.de/index.php?/archives/73-Managing-Amazon-EC2-SSH-login-and-protecting-your-instances.html
http://developer.amazonwebservices.com/connect/entry.jspa?categoryID=100&externalID=1233
http://www.slackbook.org/html/essential-sysadmin-hardusers.html

Writing about this kind of stuff on my blog is quite selfish, I suppose the only person visiting this posts it’s me, when trying to remember how I have managed to fight away some computer quirk.

Anyway, today I’ve successfully managed to bring a medium-size Magento installation from 1.3 version to to 1.4 to life.

As usual I bumped into some problems along the way. This was the first:

QLSTATE[HY000]: General error: 1005 Can’t create table ‘db_xxx.catalog_product_index_tier_price’ (errno: 150)

it’s conflicting with an existing table. So go to:

/public_html/app/code/core/Mage/Catalog/sql/catalog_setup/mysql4-upgrade-1.4.0.0.19-1.4.0.0.20.php

and remove the following from being executed:

CREATE TABLE IF NOT EXISTS `{$installer->getTable('catalog/product_index_website')}` ( ...
CREATE TABLE IF NOT EXISTS `{$installer->getTable('catalog/product_index_tier_price')}` ( ....

Next, Zend cache was bringing the whole show down:
(sometimes it displays: “There was an error processing your order. Please contact us or try again later.” on order completion)

Invalid mode for clean() method

a simple $rm -rf app/code/core/Zend/Cache/ does the trick.

Now don’t forget to change the base_urls, clean cache and index db.

Cyberduck - FTP
Eclipse - IDE
Smultron - Text Edit
MAMP - PHP/MySQL (now I use native one, though)
Console - Log viewer
Terminal -
iTunes - Cannot work without music
Firefox - Firebug and other goodies (to work)
RazorSQL - DB Client
Chrome - Testing browser (to browse the web)

.. should I change something?

#reminder

ctrl+a moves your cursor to the beginning of the line
ctrl+e moves your cursor to the end of the line

tks to @pharaujo

I remember having to explain why to favour distributed source control at Widetail. We use mercurial. Jilles couldn’t be more right…

Not using git limits you to one branch: trunk. Don’t fool yourself into thinking otherwise. I’ve seen branching in svn a couple of times and it was not pretty.
Not using git forces you to either work in small, non invasive increments or accept pro-longed instability on trunk with lots of disruptive change coming in. Most teams tend to have a release heart beat where trunk is close to useless except when a release is coming.
Not using git limits size of the group of people that can work effectively on the same code base. Having too many people commit on the same code will increase the number conflicting changes.
Not using git exposes you regularly to merge problems and conflicts when you upgrade your work copy from trunk.
Not using git forces a style of working that avoids the above problems: you don’t branch; people get angry when trunk breaks (which it does, often); you avoid making disruptive changes and when you do, you work for prolonged periods of time without committing; when you finally commit, you find that some a**hole introduced conflicting changes on trunk while you weren’t committing; once you have committed other people find that their uncommitted work now conflicts with trunk etc.
Given the above problems, people avoid the type of changes that causes them to run into these problems. This is the real problem. Not refactoring because of potential conflicts is an anti-pattern. Not doing a change because it would take too long to stabilize means that necessary changes get delayed.

via http://www.jillesvangurp.com/2010/04/18/git-so-far-so-good/

This Sunday I have done something diferent for a lazy day like this: hosted an informal presentation about e-commerce at Cooltiva-te at Clube Literário do Porto. It’s a very light presentation browse you from the early days of Ebay and Amazon to the last trends in e-commerce, like Goupon, Facebook and Manpacks. Check it out and share if off.

First of all “textareas” do not have “value” attribute, so the title is a bit erroneous. Nevertheless, let’s get back to the point: updating texarea using jQuery.

I have tried:

$(’#textarea_id’).text(’value_to_update’);
$(’#textarea_id’).html(’value_to_update’);
$(’#textarea_id’).val(’value_to_update’);

and both “text()” and “html()” do the job but none brings you a flawless solution so my advise is to use native Javascript:

document.getElementById('textarea_id').value = 'value_to_update'

Most likely, you’ll do just fine with jQuery but for our translation functionality at Vendder we’re doing some funky stuff on automic updating / reading texareas.

When using serialize() and returning in a JSON format, this doesn’t work:

$.post("test.php",
$("#testform").serialize(),
function(result) {
// do something
}, 'json');

I assume because there are no { braces } around the serialize() function, and specific formatting is only expected after a second set of { braces }. So, this does work:

$.post("test.php",
$("#testform").serialize(),
function(result) {
// do something
}, { }, 'json');
at http://api.jquery.com/jQuery.post/
It looks iffy, and I don’t know if this is how it’s supposed to work, but it does.

OK, you have set up your first Amazon EC2 instance and everything is running just fine. Now it is time to make a backup of the entire thing in case you need to boot all the image at once in case of failure.

Requirements:

• Get yourself a Certificate and Key (X.509 Certificates > New > Download both)
• https://aws-portal.amazon.com/gp/aws/developer/account/index.html?ie=UTF8&action=access-key
• Get Firefox Amazon S3 Extension called S3 Fox

Upload your key and certificate to your EC2 server (I have put them on /widetail/keys)

ec2-bundle-vol -d /mnt -k /widetail/pk-6JBXXXXXXXXXXXXXX4J2.pem --cert /widetail/cert-6JB7XXXXXXXXXXXXXX4J2.pem -u 550000004 -a -e /widetail,/var/lib/mysql/,/var/www/

-a => all directories
-e => exclude directories
-d => volume where to save your image bundle
-u => your AWS id. Check your AWS account.

PS. Be careful with the exclude paths, no spaces are allowed.

Open up S3 Fox and create a new bucket (be carefull about the region you select!). Like widetail-bucket-ami

ec2-upload-bundle -b widetail-bucket-ami -m /mnt/image.manifest.xml -a AKXXXXXXXJYA -s GQPxxxx/xxxxqk5

-m => location of your bundle (same as -d on the last command)
-a => AWS Access Key Id (same you use in S3 Fox)
-s => AWS Secret Access Key (same you use in S3 Fox)
-b => name of the bucket you created in S3 Fox

The image.manifest.xml is automatically created when you perform ec2-bundle-vol no need to worry about it.

Now go to Amazon EC2 Management Console > AMIS > Register new AMI.
Insert the path to your image manifest, on this case widetail-bucket-ami/image.manifest.xml (bucket name / manifest name)

If everything goes well you can now launch another instance of the same EC2 image, if not leave a comment.

==Update==

Now, you need to migrate this Amazon Machine Image (AMI) to a different region. On my case, I need to migrate from EU region to US region (the default us-east-1).

First, go back to S3 Fox and create a bucket in US ( default is us-east-1) like us-widetail-ami.

Execute the following command:

sudo ec2-migrate-image -K /widetail/pk-6JBXXXXXXXXXXXXXX4J2.pem -C /widetail/cert-6JB7XXXXXXXXXXXXXX4J2.pem --manifest image.manifest.xml --bucket widetail-bucket-ami --destination-bucket us-widetail-ami -o AKXXXXXXXJYA -w GQPxxxx/xxxxqk5

-K => your key (same as above)
-C => your certificate (same as above)
–manifest => your manifest image name (same as above)
–bucket => name of the bucket you created in S3 Fox and uploaded your image (same as above)
–destination => name of the new bucket you created in the new region in S3 Fox
-o => AWS Access Key Id (same you use in S3 Fox, used with parameter “-a” above)
-w => AWS Secret Access Key (same you use in S3 Fox, used with parameter “-s” above)

Go to your AWS GUI interface > Select Region (my case US East) > Images > AMIs > Register New AMI and add:

us-widetail-ami/image.manifest.xml

If everything is fine, great, everything is fine and you can use the same Amazon AMI in a different region but if you bounce into:

Invalid or unaccessible kernel id in ami manifest: aki- xxx

it means your image kernel ID is not recognized in the new region and you need to get an equivalent kernel and ramdisk ID. Install ElasticFox, another Firefox extension and browse around to find a similar AMI to the one you used in first place. tip: search for you own AMI id, check the owner ID, change region to your target region, search for that owner ID, find a similar AMI to your original and write down its kernel and ramdisk ID.

Now add them to your command:

sudo ec2-migrate-image -K /widetail/pk-6JBXXXXXXXXXXXXXX4J2.pem -C /widetail/cert-6JB7XXXXXXXXXXXXXX4J2.pem --manifest image.manifest.xml --bucket widetail-bucket-ami --destination-bucket us-widetail-ami -o AKXXXXXXXJYA -w GQPxxxx/xxxxqk5 --kernel aki-540dxxx --ramdisk ari-d5709xxx

=or=

in case you are still doing the bundling (means at your EC2 instance after doing ec2-bundle-vol and still able to access image.manifest.xml) you can migrate only the image manifest. This way you are not migrated a complete bucket from S3 but your bundle image at your current instance.

It’s time for:
sudo ec2-migrate-manifest -m /mnt/image.manifest.xml -c /widetail/cert-6JB7XXXXXXXXXXXXXX4J2.pem -k widetail/pk-6JBXXXXXXXXXXXXXX4J2.pem -a AKXXXXXXXJYA -s GQPxxxx/xxxxqk5 --region us-east-1

this will migrate your manifest image and adjust your ramdisk and kernel IDs to suit your target new region. When done just push it to the new region’s bucket with ec2-upload-bundle.

After hours of searching for ways of accomplished this stuff, this is probably a great help for the guys starting to mess around with EC2 backups.

If you need help setting up your EC2 leave a comment or drop me an email.

#mental note

Imagine if you have a Template with a Child Template aliased details_default and you want to pass a parameter to it before outputing (echoing) it.
On the template do:


$this->getChild('details_default')->setAttribute("var","something_to_pass")->toHtml();?>


and on the Child Template if you need to work with that passed variable do:

$this->getData("var"); ?>