public AMI that enables rapid evaluation of XTF

At the upcoming LITA National Forum, I will be presenting on my work in blending the California Digital Library's XTF platform and EC2 cloud services. I'm using XTF and Amazon Web Services in support of the Naval Reactors History Database service, an online resource that I started building last year.

As part of my presentation, I've created a public Amazon Machine Image (AMI), ami-51f93b38 (or, just search the AMI catalog for 'xtf'). This is a US East region AMI. I created this image using the Amazon Linux 32-bit AMI as a base, then downloaded and configured the XTF 3.0 release, along with the XTF sample files that show XTF's use with a range of formats, including EAD, TEI, PDF, and HTML.

There is a README file in the ec2-user directory with more information on how to use the instance to test XTF. This info is also available at URL https://s3.amazonaws.com/ami-xtf/xtfAmiInformation.rtf.

In summary, this AMI will enable an institution or individual to quickly get XTF online and to review its features, starting from the release version of XTF and the samples that the CDL has made available.

Additional note: This is the first time that I've worked with the Amazon Linux AMI and I found it to be both easy to use and intuitive. I intend to use this OS option in the future.

more on community / Naval Reactors History Database

I've continued with efforts to build community around the Naval Reactors History Database. As I think about this project, it has three major components: data, infrastructure, and community. I focused heavily on the infrastructure piece in the last nine months. I summarized my work with XTF and Amazon Web Services EC2 in a Code4Lib Northwest presentation this spring. But, in summary, the open source XTF digital content platform and AWS EC2 have enabled me to create a durable online presence at a low cost.

I've focused a lot on the community component in the last two months, with some positive results. This weekend, I've gotten Facebook commenting online, which was more challenging than I expected. The comments box appears in the footer section, along with the Facebook Like button. It was only in late June that I even thought about adding the Like button to the site, after hearing Eric Hellman's presentation at ALA Annual. I added the Like button to the site in late July and I've already been able to use it, along with some targeted display ads, to drive traffic to the NRHDB site and to learn more about the resource's users. I'm hopeful that the commenting will add another important dimension - enabling a public user dialogue within the site. As I've worked to build community, it's clear to me how important it is, and how difficult it is. I'm still thinking this through, but I do want to seriously engage other users in the Naval Reactors History Database. This may require me to modify the XTF interface to enable end users add comments relevant to specific database objects - images and documents. To start, there will be a unified comment stream for the site as a whole.

Also, I switched from the default Twitter widget to a Twitter Widget created through the vendor WidgetBox, for one narrow reason: an ability to customize to better customize the widget's look-and-feel. I am not a designer and, for that reason, I am using the XTF 3.0 look-and-feel with minimal customizations. The WidgetBox Twitter widget supports squared corners, which are part of the XTF default interface.

The final leg of the project's components, data, is going well; I will comment on this in more detail in a separate post.

starting point - to build NRHDB community

This month, I've made some changes to the Naval Reactors History Database, hoping to build a foundation for linking with the small community of users who have committed time to creating Wikipedia entries and other info in social network spaces:

• An NRHDB Twitter account, in which I post database-related info; Twitter users can indicate interest in the database by following this user

• An embedded Twitter widget that displays the current NRHDB Twitter post
• A Like button and the addition of microdata for the NRHDB site, consistent with Facebook's Open Graph Protocol
• A link to Wikipedia's list of United States naval reactors (from the Wikipedia icon)
• Links from Wikipedia entries to the Naval Reactors History Database, where there is significant database coverage to justify the link (example at URL http://en.wikipedia.org/wiki/S1W_reactor, see "External Links" section); Ann Lally described this content linking method in a 2007 D-Lib Magazine article

It will take some time for these changes to have an impact. The Facebook development work really opens up a lot of options for communication - as Eric Hellman of Gluejar pointed out in his ALA Annual presentation, the Like button is the most popular Semantic Web application. Its use establishes a number of methods for me to communicate with other Facebook users who have interest in the NRHDB, including messages and even ads.

integrating text into the Naval Reactors History Database

With my XTF presentation at Code4Lib Northwest completed, I've begun to do some more significant modifications of the XTF instance that supports the Naval Reactors History Database service. One need was prompted by the inclusion of text content, in the form of documents that describe NR's work in Project Prometheus.

Previously, the database was composed solely of image files, many of which containing internal text metadata that is indexed by XTF. Now, I'm adding textual content, in PDF format, to the index. This change introduced a problem: In a displayed record, the Matches field displays text snippets from the image metadata and text files. These two types (image and text) need to be differentiated, so the display is more comprehensible.

Solution: Modify file resultFormatter.xsl so that the Matches display is contextually customized. Two xsl:if elements are added, with the differentiation based upon the data in the XML metadata's Dublin Core Type field:

I'm continuing to look at XTF programming possibilities, including those described in Rowan Brownlee's XTF guide.

Also, I have to say that in coding this change, I took the NRHDB site down for several seconds or even minutes. For that reason, I'll be testing changes in a test instance, running parallel to the production site, in order to eliminate downtime. I can do this using EC2 micro instances that I terminate upon completion of testing. It's at this point that the open source/cloud blend is most advantageous - instead of licensing commercial digital collections software to support production and test and running both servers locally, I can run the production instance 24/7/365 using an Amazon Web Services EC2 Reserved Instance and spin up an EC2 micro instance on demand for several hours to customize and extend XTF as needed. And since XTF and its supporting components are all open source, there's no software costs for this work.

gaaa....Powell Technical Books is closed

In yet another sign of the times, Powell's Technical Bookstore is now closed. This happened last fall, I believe, but I just came across it when attending Code4Lib Northwest in Portland earlier this week.

There is a much-smaller (relative to the previous Technical Books) Powell's 2 location, with computer and science books. This store is on the same block as the large Powell's store.

I'm learning to love reading on my Kindle, but I'll miss the bricks-and-mortar stores, no doubt.

customizing stop words in XTF

I've been immersing myself in the inner workings of the California Digital Library's XTF platform. I expect to make a number of changes to my XTF-based Naval Reactors History Database service in the next few months, in preparation for a fall LITA Forum presentation. The change described in this post is actually pretty trivial - adding a customized stop words list for an XTF instance - but it illustrates the kind of back-end customizations that are possible.

I decided to use the stop words list provided on the SEO Tools website.

To employ the index in XTF, I copied the file to xtf/conf/stopwords directory, replacing the existing stopwords.txt file that was included in the release version of XTF with the one that I obtained from the SEO Tools site.

I then stopped Apache Tomcat and rebuilt the XTF index. A clean build is recommended, as described in this XTF users group post. (I received the error described in the message before restoring to a clean build.) Upon restarting Tomcat, the new stop words list is in use.

using Amazon Web Services features to improve EC2 and EBS resource durability

I run the Naval Reactors History Database, a hobby project, on Amazon Web Services resources. This includes a Linux server, persistent storage, and an IP address. I run them out of the AWS East region, which was the region at the center of the recent and significant AWS outage. While my online resource never had an outage, to the best of my knowledge, it's clear that it could have been impacted because of the EBS control plane that supports availability zones across the region. Also, Amazon announced that a small amount of EBS volume data had been lost in the affected Availability Zone.

So, this weekend I spent some time thinking about preserving the work that I've done with my Naval Reactors project. This is in the context of an online database that I'm slowly building, with objects being added and updated as I find the time on weekends and evenings. In short, it's a fairly static resource. In his book on Amazon Web Services, Jeff Barr notes the importance of creating lists. That's what I hope to have out of my own work - a set of lists that I create and can use in order to recover from AWS outages like the one that occurred last month.

So, to begin. First scenario: I am running an m1.small Linux instance in the us-east-1d Availability Zone (AZ). It's possible for me to launch and test a copy of my current server in another East availability zone. All of this work is done in the Amazon Web Services console, so it's quite quick and easy:

1. From Instances: Create an AMI from the running instance (what I'll call the production instance). There is a short (estimate 1-2 minutes) of server downtime as the AMI is generated.

2. From AMIs: Choose to launch an instance from the newly-created AMI. When going through the creation steps, I change the default selection for the AZ and choose to run the new instance in us-east-1b. I choose to keep the same Key Pair Name and Security Group as I have for the production instance.

After launching the instance, I have an EBS-backed Linux instance running in us-east-1d (production) and an instance running in us-east-1b (backup). The AZs have independent power and network connectivity. While the incident report describes how problems in one AZ can potentially impact others in the region, having this server running in another AZ provides a resource backup and a method for bringing my online database back online in the event of an outage.

3. Using the public DNS address, I test access to the Tomcat-based Naval Reactors History Database on the backup server - with success.

Note: I didn't generate an Elastic IP address for this instance. First, it wouldn't make sense in the context of my use - I would use the Elastic IP address currently mapped to the production server and would map this address to the backup server in the event of an outage. But second, you should be aware that you will be charged for an unused Elastic IP address that you've allocated to your account.

4. Stop the EBS-backed backup server instance.

Result: production server running in AZ us-east-1d; backup server stopped, but ready to start and serve resources, in AZ us-east-1b.

I performed all of these steps successfully today.

---

This is one method of providing redundancy. But I want to come up with something a little more sophisticated - in part because I am interested in moving to a new server OS and more robust EC2 platform in the future. Here's a second scenario, in which I build a new instance to host the collection and attach a volume with the needed data to it - all in a different AZ than the production server is running in.

Steps 1-5 and 8-9 below are performed in the AWS Management Console - including step 5, which I'll comment on later.

1. From Volumes: Create a snapshot from the production server's EBS volume.

2. From Snapshots: Create a volume from the EBS snapshot. Again, since the production server is running in us-east-1d, I create the new volume in us-east-1b.

3. From AMIs: Find the right AMI for the future production server. In my case, I'm looking for a Linux OS AMI that I'm comfortable with, preferably with Apache Tomcat preloaded.

4. From AMIs: Launch an instance using the AMI found in step 3. I'll be mounting the volume created in step 2, so I will manually set the instance's AZ to us-east-1b.

5. From Volumes: Here, I will attach the volume created in step 2 to the instance launched in step 4.

6. In the new server's Linux OS, Create the mount point location and mount the attached volume:

mkdir /mnt/prodata

mount /dev/sdf /mnt/prodata

7. Copy the XTF and Naval Reactors History Database files from the just-mounted volume to the Tomcat location on the new production server.

8. After testing, use this server as the new production server and map the Elastic IP address to the server.

9. Stop, and terminate when comfortable doing so, the previous production server.

I had initially planned to perform step 5 using the EC2 command line tools, but it's vastly easier to use the AWS Management Console.

---

My conclusions: The second method provides an important foundation for ensuring the durability of my EC2-hosted online collection. Amazon's detailed report on last month's outage includes this statement: "For example, when running inside a Region, users have the ability to take EBS snapshots which can be restored in any Availability Zone...."

I'm still exploring how to best automate the process of creating snapshots and restoring a volume in an AZ that's different than the production server is running in. What I have, as a primary protection at this point: From the second procedure, my production service running in one AZ and an EBS volume containing my application and online collection data has been restored and is available for use in a second AZ.

Also, I plan to do more reading on AWS best practices. I'm sure that I can improve upon the above procedures, but this is what I came up with based upon my current knowledge.