Bug fixes:

• Shell scripts are more compatible with Cygwin

New toolkit functionality:

• Added support for the new Reduced Redundancy Storage (RRS) class for objects
• CloudFrontService: Support for HTTPS-only distributions and logging of streaming distributions
• Added support for buckets located in the Asia Pacific (Singapore) location “ap-southeast-1″
• Improved compatibility with Eucalyptus/Walrus

Cockpit application updates:

• Reduced Redundancy Storage class
• Buckets located in the Asia Pacific (Singapore) location
• HTTPS-only CloudFront distributions

Synchronize application updates:

• Allow synchronization with third-party buckets that are not owned by the user

Other notes:

• CloudFrontService API changes may break backwards-compatibility
• SOAPService is deprecated and will soon be removed from the toolkit

Visit the JetS3t web site to download the latest release and view the latest code samples and API Javadoc. The latest version should also be available from the official Maven2 repository by now.

Read about the complete list of changes in the release notes, and visit the development site to submit bug reports or help out with the project.

Accept a little more risk, save some bucks. For many S3 customers this will be an attractive option.

See Amazon’s RRS blog post for more information.

Below is a brief overview of how you can use the feature in JetS3t once you have downloaded and built the latest code.

Cockpit

The Cockpit application has support for the new storage class in a few places:

• In the preferences you can choose the default storage class to apply when uploading objects
• the Copy or Move Objects dialog allows you to choose the storage class for destination objects. This makes it easy to apply the cheaper storage option to many objects, you simply copy the objects in-place after selected the REDUCED_REDUNDANCY storage class
• each object’s current storage class is now shown in the Object Attributes dialog.

API

In the API you set the storage class of an object prior to uploading it:

To apply the new storage class to existing objects you call the normal RestS3Service copyObject or moveObject methods after setting the storage class attribute of each destination object.

To check the storage class an object is stored under you perform a bucket listing then call the S3Object’s getStorageClass method:

The latest JetS3t code provides basic API support for enabling and managing these access logs, in much the same way as you do for non-streaming distributions. See the recent changes to the CloudFrontSamples.java file for example usage.

Note that this new feature has not yet been widely tested so file a bug report to let me know if you have problems.

Turns out a bunch of douches have given the book one-star reviews because the book is not yet available on the Kindle.

Not only are they submitting low reviews because they cannot yet buy the book in their preferred form — a decision that is most likely made by the publisher not the author — but they are doing so without even reading the book. This is a whiny and pathetic form of “protest” that does nothing but pollute the digital commons. Grow up folks!

This release includes:

• support for new S3 features Bucket Versioning and Multi-Factor Authentication for delete
• updates to the CloudFront service to support the 2010-03-01 API with private streaming buckets.
• bug fixes

Visit the JetS3t web site to download the latest release and view the latest code samples and API Javadoc. The official Maven2 repository should be updated in the next day or so.

Read about the complete list of changes in the release notes, and visit the development site to submit bug reports or contribute to the project.

Versioning For All

To begin with, the new S3 beta versioning feature is now available in all regions. This means that you can retain past versions of all your S3 objects regardless of where your bucket is located.

The latest JetS3t code has full support for versioning that makes it very easy to use. You can enable versioning for a bucket like so:

Then should you ever need to recover some data — such as after accidentally deleting an object or overwriting data with a corrupted file — you can find and retrieve the prior versions:

The Second Factor

As well as rolling out broader availability of the versioning feature Amazon has (somewhat quietly) added another interesting feature: the first API-level support for multi-factor authentication. Multi-factor authentication (MFA) adds an extra level of security to systems by requiring users to prove ownership of a token or device of some kind in addition to their normal login credentials. This means that even if someone steals or guesses your credentials they will be unable to perform actions on your account because they do not possess the device.

In Amazon’s case, like PayPal and some banks before them, the additional factor comprises a small electronic device that generates code numbers. Once you have purchased one of these devices and enabled it in your AWS account you will be required to provide an extra code number when performing certain tasks.

Previously the additional MFA device code was only required when you logged in to the AWS Console but as of today you can turn on MFA for your S3 buckets in tandem with versioning. When versioning with MFA is enabled not only will the bucket’s owner be the only user who can permanently delete object versions, but this user will be required to provide a time-limited MFA code to do so.

Again, this is relatively straight-forward to use in JetS3t:

The addition of MFA support at the API level in S3 is particularly interesting because this is the first time Amazon has done so, and because it raises some interesting challenges for developers who are accustomed to building fully-automated systems. To take advantage of the protection the MFA provides a system will need to prompt the user for her MFA code every 30 seconds or so when she wishes to permanently delete data. I am keen to see how — and if — developers actually build this feature into their applications.

Hello BitBucket

Finally, repeating the news I posted recently on the JetS3t discussion forums, I have decided to move the JetS3t codebase from it’s old home at java.net over to the BitBucket service: http://bitbucket.org/jmurty/jets3t/

BitBucket has the advantage of being a more modern, easy-to-navigate site, and has seamless support for Mercurial which is my favorite source code management tool. So it’s farewell to java.net and CVS, you served us well but it’s time for some new blood.

Try out the latest code and let me know what you think. Head over to the JetS3t BitBucket repository and grab the latest code via a pull (if you’re familiar with Mercurial) or simply download it via the “get source” link.

Once you enable versioning for one of your S3 buckets, any time you change an object in that bucket a version of the prior object will be stored in addition to the latest one. You can then perform operations on prior object versions such as retrieving older data, restoring “deleted” objects, and generally maintaining a fail-safe history of everything that happens in the bucket.

This will be a boon to anyone who is worried about their S3 data being accidentally deleted or corrupted by user/computer error.

The feature is currently in early beta form and is available for testing with buckets located in the “us-west-1″ location. You can read about the current functionality here: Versioning Beta Design.

Better still, you can grab the latest JetS3t code from CVS and try it out for yourself! The code samples file CodeSamples.java now includes a section called “Bucket Versioning (Beta)” to get you started.

Both the versioning feature itself and JetS3t’s support for it are in an early stage so watch out for warts.

This release includes some bug fixes, more sophisticated configuration options for the “filecomparer” component that manages file synchronizations, and supports the two major new CloudFront API features: private distributions and streaming distributions.

Visit the JetS3t web site to download the latest release and view the latest documentation such as code samples and the API Javadoc.

You can read about the complete list of changes in the release notes. And for the Maven-ites among you the official Maven2 repository has also been updated.

This feature allows you to control access to S3 objects you distribute through CloudFront by making them available only through specific distributions, or by requiring the use of signed URLs that you generate and provide to privileged users.

As of this evening the latest JetS3t codebase (available from the CVS repository) has full support for the new features, including the ability to:

• create and update private distributions
• manage Origin Access Identifiers, which are required for private distributions
• generate canned and custom-policy signed URLs for private distributions that require request signing.

These new features are not yet available in a stable packaged release but I plan to provide the next stable version before the end of November.

The Cloud Servers product allows you to rent computing resources and is a competitor to Amazon’s Elastic Compute Cloud (EC2) service. Rackspace has a comparison page that describes, from their perspective, the advantages of their offering over EC2.

Some key differences from EC2 include:

• Cloud Servers has a wider range of server sizes available at the low end, with a minimum size of 256MB RAM that has a price of only $10.95 per month.
• Public IP addresses can be shared among multiple servers.
• The service supports dynamic resizing (vertical scaling) of servers to a degree. Unlike EC2, you can increase or decrease the computing power available to a single server without the need to manually start a new instance and redeploy your application to the new instance. However this scaling, while easy, isn’t instantaneous — behind the scenes Rackspace’s service actually starts a new server and copies everything across for you, so there is likely to be some downtime.
• A simpler RESTful API with support for JSON messages in addition to XML.

I am not yet familiar enough with Cloud Servers to give a detailed comparison with EC2, but it seems to be a full-featured service that is aiming to address some of the difficulties people face when using Amazon’s offering. If Rackspace can learn from Amazon’s missteps they should be able to provide a compelling cloud computing platform.

It has taken some time for a strong, low-level “Infrastructure as a Service” competitor to EC2 to arrive, but we may finally have it in Cloud Servers. I hope so, because the more active competition we have in this space the more quickly the products and technology will improve, and the better off we cloud computing users will be.