Before continuing with a development environment setup, a set of security credentials were first created using the Amazon AWS Console. From the user menu in the toolbar, select the Security Credentials option.
There are options for generating various types of identity credentials:
Not really knowing what I will need first (and ignoring the basic security tenet of only generating what you need when you need it), I generated credentials in all three categories, and saved them off to a safe place. Finally, I used the PUTTYGEN tool to convert the Key Pair into something that will work with the PUTTY suite of tools. Its a fairly simple matter to import the *.pem file you created and
convert it to a PUTTY-friendly *.ppk file (also saved off to a safe
place).
Now equipped with an account and a plethora of security credentials, I think I have the bare minimum requirements in place for moving forward.
My hobby notebook, infrequently used. This is primarily to clean off my desktop, but if someone else can make use of any of it, all the better...
Tuesday, April 30, 2013
Monday, April 29, 2013
Creating a new Amazon AWS Account
Continuing along with my journey into the cloud, I spent 10 minutes creating a new Amazon AWS account. I started with a link for Try Cloud Computing Free and pressed the easy button:
If you've ever created an account, well anywhere, this process should be fairly old hat. Even though you are signing up for a free trial account, you do need to provide a credit card (in case you go over the free limits). There was one additional step which was unusual: confirming your phone number. Amazon generates a one-time PIN and calls your number from an automated system to verify you - after punching in the PIN, you continue on your merry way:
A few minutes later I received the "all done" email:
and my account setup was complete. A quick trip to Amazon AWS and I logged in to the account console without issue:
Now that I have an account and EC2 tools installed locally, my next steps will be getting a local build environment up and running. To be continued...
If you've ever created an account, well anywhere, this process should be fairly old hat. Even though you are signing up for a free trial account, you do need to provide a credit card (in case you go over the free limits). There was one additional step which was unusual: confirming your phone number. Amazon generates a one-time PIN and calls your number from an automated system to verify you - after punching in the PIN, you continue on your merry way:
A few minutes later I received the "all done" email:
and my account setup was complete. A quick trip to Amazon AWS and I logged in to the account console without issue:
Now that I have an account and EC2 tools installed locally, my next steps will be getting a local build environment up and running. To be continued...
Sunday, April 28, 2013
Downloading the Amazon EC2 Tools
We at Spare Time Notebook have been sleeping on this cloud thing for far too long; not ignoring it per se, just, well, not really needing it. With the cost of hardware dropping through the floor as of late, its hard to let go of old habits (just buy another box) and embrace the new world.
Those lazy habits end today, as I delve into Amazon's EC2 offering. I'll be documenting my progress/lessons learned as I go, and since time is tight, will be posting my education in pieces.
Today's effort is about as basic as possible - getting the tools loaded on my development workstation (who knows, maybe someday the math will work and my local workstation will be retired, and instead live in the cloud, only to be spawned when needed). After a query to the friendly neighborhood google, I had an official link for Setting Up the Amazon EC2 Command Line Interface Tools. This set of directions had a link to the latest download distribution (currently 1.6.7.2):
The download is fairly small (14meg), and was unzipped into my tools directory like any other java distribution:
I'll spend some time researching the task of building an appropriate command line environment and establishing proper credentials to the Amazon infrastructure and post again after I know what I should be doing.
Those lazy habits end today, as I delve into Amazon's EC2 offering. I'll be documenting my progress/lessons learned as I go, and since time is tight, will be posting my education in pieces.
Today's effort is about as basic as possible - getting the tools loaded on my development workstation (who knows, maybe someday the math will work and my local workstation will be retired, and instead live in the cloud, only to be spawned when needed). After a query to the friendly neighborhood google, I had an official link for Setting Up the Amazon EC2 Command Line Interface Tools. This set of directions had a link to the latest download distribution (currently 1.6.7.2):
The download is fairly small (14meg), and was unzipped into my tools directory like any other java distribution:
I'll spend some time researching the task of building an appropriate command line environment and establishing proper credentials to the Amazon infrastructure and post again after I know what I should be doing.
Saturday, April 20, 2013
How to modify MAX_ALLOWED_PACKET in MySQL
While working with BLOB/CLOB fields in MySQL, it won't take long to encounter the following issue during a DML statement:
Packets larger than max_allowed_packet are not allowed.
Using the following command:
You can see that the networking parameter MAX_ALLOWED_PACKET defaults to 1048576 (1MB). Since a 1MB BLOB file is fairly paltry, the parameter must be updated to a more reasonable value. Logged in as root (or similarly admin'ed user), issue the following command to modify the parameter:
GLOBAL refers to the sessions which are effected by the call; meaning that all sessions will now honor the new 16MB limit. However, there is a catch. At this point, the change is not persistent (see notes that this is not a bug). A recycle of the service will reset the value back to the original 1MB setting.
To permanently change the value, the my.ini configuration file must be altered; mileage may vary on the location of said file (install location, OS, etc., etc.), but in my case, the file lives in C:\Users\chris\Development\mysql\my.ini. Find the mysqld section, and add a line for the setting:
Save the file and restart the MySQL service. The value should now be permanent.
Packets larger than max_allowed_packet are not allowed.
Using the following command:
SHOW VARIABLES LIKE ‘max_allowed_packet’;
You can see that the networking parameter MAX_ALLOWED_PACKET defaults to 1048576 (1MB). Since a 1MB BLOB file is fairly paltry, the parameter must be updated to a more reasonable value. Logged in as root (or similarly admin'ed user), issue the following command to modify the parameter:
SET GLOBAL max_allowed_packet = 16 * 1024 * 1024;
GLOBAL refers to the sessions which are effected by the call; meaning that all sessions will now honor the new 16MB limit. However, there is a catch. At this point, the change is not persistent (see notes that this is not a bug). A recycle of the service will reset the value back to the original 1MB setting.
To permanently change the value, the my.ini configuration file must be altered; mileage may vary on the location of said file (install location, OS, etc., etc.), but in my case, the file lives in C:\Users\chris\Development\mysql\my.ini. Find the mysqld section, and add a line for the setting:
[mysqld]
# ADDED BY CHRIS ON 20 APRIL 2013
max_allowed_packet=16M
Save the file and restart the MySQL service. The value should now be permanent.
Subscribe to:
Posts (Atom)