How to upgrade from JDK 1.6 to 1.7 on ubuntu?

Its simple... Use the command 

sudo apt-get install openjdk-7-jre

This will install JDK 1.7 on your ubuntu box. But there is a catch.. if you still run java -version, it will tell you that it is still using JDK 1.6. 

So your system has actually been updated with JDK 1.7 but it is still not in use. There is a special script in ubuntu which allows you to check different versions present on the system and let's you choose the correct one you want to activate. 

Here is how you can update that: 

sudo update-alternatives --config java

This command will give you an output similar to below.. and asking you to choose which one you want to use.. 

There are 2 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                                            Priority   Status
------------------------------------------------------------
* 0            /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java   1061      auto mode
  1            /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java   1061      manual mode
  2            /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java   1051      manual mode


Press enter to keep the current choice[*], or type selection number:

Simple.. Isn't it? 

Puppet server hostname does not match certificate - can't authenticate.

err: Could not retrieve catalog from remote server: Server hostname 'puppet' did not match server certificate; expected master

The agent configuration file seems to be communicating with a different server (master) name than that for which the puppet master has the certificate for. The only way to solve this is by re-generating the puppetmaster server certificate with the correct hostname as that defined in the agent configuration file.

To quickly test, another way is to change /etc/hosts file of agent and map the hostname and IP of the puppetmaster server.

Exiting; no certificate found and waitforcert is disabled

When running command:

sudo puppet agent --test

Exiting; no certificate found and waitforcert is disabled

To solve this follow below instructions: 

1.  Login to the puppetmaster. 
2.  Run command "sudo puppet cert --list". It will list down your agent machine who have requested a certificate.
3.  Sign the requests using command "sudo puppet cert --sign "ip-10-134-174-211.ap-southeast-1.compute.internal"" Where the IP-10.... is the hostname of you agent machine. 

This should all be needed to resolve the issue. 

err: Could not request certificate: Connection timed out - connect(2)

When running below command on the agent machine:

sudo puppet agent --test

err: Could not request certificate: Connection timed out - connect(2)

Points to the problem that the Ports used for communication between the agent and master are not Open. Please open port 8140 TCP and check it again. 

Recovering a Locked forgot administrator password for Windows EC2 Instance

Its simple... 

1. Create a new scratch EC2 instance running 2003 server, and log into it.
2. Get a note of volume attached to it and Shut down your lost instance (the one you can't log into) from the AWS console.
3. On the EC2 console, go to Elastic Block Store/Volumes and find the volume you find in step 2 and Detach it.
4. On that same volume, attach it to your new 2k3 EC2 instance. You can see it appear in Disk Manager and you'll get a new  drive letter.
5. Go to NewDriveLetter:\Program Files\Amazon\Ec2ConfigService\Settings\ and edit config.xml with notepad
6. The first setting in the file is for the Ec2SetPassword plugin; change the State field from Disabledto Enabled. Save & close.
7. On the AWS console, Detach the volume from the new instance
8. Attach the volume to your original lost instance, as /dev/sda1 (Root volume)
9. Start the instance. After a few minutes, run the Get Windows Password function which will have the newly generated password.

Now if you have mapped that instance to C-name remember to change the corresponding URL because the ec2-url will change after the restart.

An interesting thing about AWS ELB's

In last couple of days I discovered that ELB's are not designed to handle sudden spikes in traffic. What was most disturbing was that: 

1.  When there is a sudden spike, the ELB breaks down. An returns HTTP 404 messages. 
2.  The ELB gets into a bad state and remains like that for about 90 minutes. 
3.  The solution to this suggested by AWS Support team was to simply move out of ELB and have your own load balancer. 
4.  If it is just a testing spike, AWS can prewarm the ELB to handle that load but just for few weeks. 

HAproxy or Nginx seems to be my obvious choice now if I have to move away from ELB. Doing High availability with HAProxy or even Nginx seems to be a little tricky but that's Okay if we have to move away from ELB.