USGIN Amazon Virtual Server Development
This blog will serve as preliminary documentation for the development of the AZGS Amazon EC2 Instance. The purpose of the machine is to:
1) Provide a production environment for USGIN CSW, WMS and WFS services through GeoNetwork and GeoServer by the Arizona Geological Survey.
2) Provide a model (and AMIs) for other organizations to use in order to build their own Amazon EC2 instances to provide USGIN services.
Git Setup: Public Repositories, Secure Commits
I did this primarily based on blog postings at http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way, and also http://book.git-scm.com/4_setting_up_a_public_repository.html. See these posts to see what I did pretty much verbatim.
The big configuration difference is that I wanted the git repositories to reside on the elastic-block store, but be accessible in the usual way. So, after installing git and gitosis and adjusting my gitosis-admin repository, I moved all the repostories from /home/git/repositories to /mnt/ebs/git/repositories. A symlink in the /home/git/ directory links to the repositories on the elastic block store, which makes them accessible to the git user as they need to be.
Installation and use of Yourkit Java Profiler
- On the virtual machine, create a folder for, and download the Java Profiler, unzip it:
mkdir yourkit (this makes the folder in the root user's home directory) cd yourkit wget http://www.yourkit.com/download/yjp-8.0.19.zip unzip yjp-8.0.19.zip
- Generate a script that allows you to use the Yourkit tool from a remote location
java -jar /root/yourkit/yjp-8.0.19/lib/yjp.jar -integrate
Installing GeoNetwork 2.4.2 under Tomcat with a MySQL Backend
Setup the MySQL Database for Geonetwork to Use
- From the command prompt on the instance, type the following commands:
mysqladmin create geonetwork -u root -p
You will be prompted for the password for the root MySQL user.
Common Procedures on the EC2 Instance
"Restarting" the Virtual Machine
You can't actually restart it, instead you essentially delete it and roll-back to a prior machine image.
Connecting to PostgreSQL via SSH Tunneling
In the event that you don't want to open port 5432 to any traffic, or you don't want to configure PostgreSQL to listen to any remote traffic, or if you simply can't make it work right (that's where I am right now...) you can use SSH Tunneling to make a remote connection to the PostgreSQL instance. Here's how:
