Ditching the Ubuntu Unity UI

It seems to be the decade of the bad OS UI; between Windows 8 and Unity, I'm about ready to swear off UIs and stick to command prompts.  Here are some quick notes on how to get the Unity monstrosity off your Ubuntu desktop.  First open a terminal window, and run

sudo apt-get install gnome-session-fallback


After restarting the machine, click the Ubuntu logo from the login screen (on the upper right):

and you'll be greeted with another menu:

Select GNOME Classic, followed by OK.  After logging in, Ubuntu will be "back to normal".

Automating Tomcat 7 Installation on EC2, Part II

Finalizing the work started in Automating Tomcat 7 Installation on EC2 the user data script was enhanced to modify the following two files:

• /etc/tomcat7/server.xml
• change instances of 8080 to 80
• change instances of 8443 to 443
• /etc/default/tomcat7
• change #AUTHBIND no to AUTHBIND yes

And then start the tomcat7 service.  The final user data script is as follows:

#!/bin/bash
export DEBIAN_FRONTEND=noninteractive
sudo apt-get update -q -y
sudo apt-get install tomcat7 tomcat7-docs tomcat7-examples -q -y
sudo sed -i 's/port="8080"/port="80"/' /etc/tomcat7/server.xml
sudo sed -i 's/redirectPort="8443"/redirectPort="443"/' /etc/tomcat7/server.xml
sudo sed -i 's/#AUTHBIND=no/AUTHBIND=yes/' /etc/default/tomcat7
sudo service tomcat7 stop
sudo service tomcat7 start

After starting a new micro Ubuntu 12 instance while providing the script above (as well as using a security configuration which allows/opens port 80 for http traffic), the web server came online and started serving up pages without any further interaction (ie - turnkey tomcat server).

The script could be enhanced further by downloading/deploying a Java webapp (exploded folder or .war file) as needed.

Automating Tomcat 7 Installation on EC2

Extending work performed in the earlier post Running Tomcat 7 on EC2, I began the process to automate the creation of a Tomcat 7 application server.  The magic is performed on the "Advanced Instance Options" page (which also has an equivalent in the EC2 API world):

The "User Data" area allows for the creation of a "one time script" which will be run immediately after the server is provisioned and started for the first time.  For this case, the following was dumped into a text file and included on the configuration wizard page:

 #!/bin/bash
export DEBIAN_FRONTEND=noninteractive
sudo apt-get update -q -y
sudo apt-get install tomcat7 -q -y
sudo apt-get install tomcat7-docs -q -y
sudo apt-get install tomcat7-examples -q -y

Note that the "as file" option was used as opposed to "as text".  There really is no technical reason for doing things this way;  However, this implementation does provide for a script file which could be placed under configuration management control (svn/git/etc) outside of this process.

After completing the instance wizard and waiting for provisioning, an Ubuntu 12 server was successfully created with Tomcat 7 and associated docs and examples already installed.  All that remained was the port configuration steps and service startup:

sudo nano /etc/tomcat7/server.xml
change instances of 8080 to 80, and save file
sudo nano /etc/default/tomcat7
change #AUTHBIND no to AUTHBIND yes, and save file
sudo service tomcat7 stop
sudo service tomcat7 start

In a future post, I'll attempt to integrate these remaining items into the user data script.

Terminating Protected EC2 Instances

I'm not sure I remember selecting a protection option during creation (perhaps its a default), but while trying to terminate an old micro test box, I encountered the following:

As it turns out, this was fairly easy to resolve.  From the EC2 console window, right-click the offending instance, and choose "Change Termination Protection":

After that, just right-click the EC2 instance and select "Terminate", and it cleans up without issue.

Running Tomcat 7 on EC2

Installing Apache Tomcat 7 on a virtual machine within the Amazon EC2 cloud turned out to be a fairly trivial task. Using the micro instance created in a previous post, I issued the following commands on the Ubuntu command line to install the service:

sudo apt-get install update
sudo apt-get install tomcat7
sudo apt-get install tomcat7-docs
sudo apt-get install tomcat7-examples

In order to bind tomcat to listen on privileged port 80, the following steps were taken:

sudo nano /etc/tomcat7/server.xml
change instances of 8080 to 80, and save file
sudo nano /etc/default/tomcat7
change #AUTHBIND no to #AUTHBIND yes, and save file
sudo service tomcat7 stop
sudo service tomcat7 start

Finally, the Amazon EC2 security group was modified to allow access to port 80.  After these steps, bringing up a browser and accessing http://amazon-dynamic-server-name/docs successfully brought up the Tomcat 7 documentation.

I'm not sure why I was surprised, but I did discover that restarting an EC2 instance resulted in the instance obtaining a new DNS name and IP address.  The next time I work on a server, I need to remember to assign an Elastic IP address to the micro instance (in order to be able to save a PUTTY connection in my profile).

Creating an Environment Script for EC2 tools

With a basic understanding of Amazon EC2 under my belt, I continued with my workstation build-out by creating an environment script for the EC2 command line tools.  Nothing to Earth shattering here; the majority of time involved was mostly just researching variables that needed to be set.

@echo off
set EC2_HOME=C:\Users\chris\Dev\apps\ec2-api-tools-1-6-7-2
set EC2_PRIVATE_KEY=C:\Users\chris\Dev\bin\identity\pk-xxxx.pem
set EC2_CERT=C:\Users\chris\Dev\bin\identity\cert-xxxx.pem
REM default to avoid using --region parameter everywhere from command line
set EC2_URL=https://ec2.us-east-1.amazonaws.com
set PATH=.\;%EC2_HOME%\bin;%PATH%
echo ** ENVIRONMENT SET FOR AMAZON EC2 1.6.7.2

Java settings are not required because I have those covered in another script.  The script was entered, saved in my local dev\bin directory, and worked without issue.

Launching Amazon EC2 Instances

Before continuing with development, I tested out my new Amazon AWS account by launching both a Linux and Windows micro instance.  From start to finish, each took about 10-15 minutes (including the launch wizard, waiting for the instance to spin up, logging in, and finally termination).  Amazon has instructions posted online, but the wizard is fairly idiot-proof.  The only thought process involved is in connecting to the instance, and even that has been made fairly simple.

The Linux micro instance was the first to get launched.  Starting from the Amazon console, I switched into the EC2 dashboard.  It wasn't until I was over half way through the process that I realized I was defaulting to the US West (Oregon) region; I'll need to make note of that for the future (the instance responsiveness was fine even though I'm sitting on the opposite coast).  The Amazon provided documentation was adequate to get up and running.  I stepped through the New Instance wizard, and selected an Ubuntu distribution:

I accepted the defaults, with the following exceptions:

For this one I did keep the defaults, however, making a note to visit the URL above to figure out what this instance tagging is used/good for.

For the firewall configuration, I created a new rule to allow SSH only (this canned group should be ready for re-use next time).

After completing the wizard, the new Linux server started up in about 5-10 minutes:

I right-clicked the instance and attempted the Connect option.  This worked as well as could be expected for a terminal window run through a browser.  It was functional, but just no substitute for PUTTY.  The only catch to connecting through PUTTY is to remember to populate your security keys (which I had previously converted to *.ppk format) within SSH | Auth.  Once PUTTY connected, I used the username "ubuntu" and logged in without issue (or password, keys are clearly working).

Finally I exited the PUTTY session and terminated the instance.  From the same right-click menu in EC2:

choose terminate and wait until the console reflects the destruction of the instance.  I'm not entirely sure of the full scope of differences between terminate and stop, although did find this documentation that I'll need to go through at a later date.

The Windows 2008R2 micro instance performed just as smoothly.  The official amazon documentation was again comprehensive for a beginner, and the only significant difference in the startup wizard (vice Linux) was specifying 3389/RDP as the firewall configuration setting.

Logging in was indeed different, using Remote Desktop vice PUTTY.  The process begins with right-clicking the instance and retrieving the password:

and then decrypting the password with the *.pem key pair.  With an administrator username and password now in hand, I logged in using the standard Remote Desktop Connection tool which ships with Windows 8.  I completed this test by terminating the Windows instance.

I did not perform a shutdown from within Windows before terminating (because as I understand it, terminating effectively destroys the instance, so who cares if it shuts down cleanly), but will need to revisit that in the future as instances are created that I care about.

As a final step, I used the Amazon console and jumped to the Account Activity report, just to verify that all the compute time was included in the free trial (and I didn't launch the wrong instances).

Overall, things could not have been easier.  Now all I need to do is come up with a sample application to build and deploy, just to exercise the environment a little more thoroughly.