We are also beginning limited trials of large IPv6 allocations routed to Linodes. If you’d like to take part in the trial please open a ticket and we’ll do our best to accommodate your needs.

Enjoy!

IPv4 was released in 1981 as a 32-bit range that provided roughly 4.3 billion IP addresses. Unfortunately, in just a few years, the protocol was identified to have scalability problems under the Classful Network architecture it employed at the time. As a result, the IETF was formed in 1991 and replaced the previous addressing architecture with Classless Inter-Domain Routing (CIDR) with the goal of slowing the growth of routing tables across the Internet and ultimately the depletion of IPv4 addresses.

With IPv4 address exhaustion inevitable, in 1998 the IETF announced a new protocol known as IPv6. This new protocol uses 128 bit addresses capable of supporting 340 undecillion addresses.  To put that into context it amounts to: the existing Internet times the Internet times the Internet times the Internet worth of addresses.

Obviously this allows for many more devices on the network and while also eliminating the need for Network Address Translation (NAT).

However, adoption of IPv6 has been pitifully slow. In fact, according to a recent study by Arbor Networks, IPv6 represents less than 1% of all IP traffic seen on the Internet and very few cloud hosting providers have stepped up to help make this necessary transition possible for their subscribers.

The essence of the problem comes down to this: service providers don’t want IPv6 because there is no subscriber demand, subscribers don’t want it due to lack of content, and the content providers don’t want it unless there are subscribers. Nevertheless, the tipping point for the transition is around the corner and it is better to begin testing and migrating now rather than being left out in the game of IPv4 musical chairs.  We don’t want to be part of the problem.

Linode – part of the solution

While this industry-wide problem has been challenging, Linode has accelerated its efforts towards IPv6 adoption. Subsequently, Linode is proud to announce today native IPv6 support.  This will be a phased roll-out across the facilities, starting with immediate availability in Fremont, Newark in a week or so, followed by Dallas.  For current IPv6 availability please see the Linode IPv6 Status and Frequently Asked Questions page which will be maintained here: http://www.linode.com/IPv6/.

Enjoy!

UPDATE 2011-05-05 – Newark online and IPv6 Pools available

UPDATE 2011-05-26 – Dallas is now IPv6 enabled!

UPDATE 2011-05-31 – There’s now an ‘Enable IPv6′ link on your Linode’s Remote Access subtab.

UPDATE 2011-12-20 – London and Atlanta IPv6 Enabled – blog post.

Given how critical backups are, our goal for the Linode Backup Service was ambitious: to create a completely managed, reliable and highly available system, that’s easy to use (set-it-and-forget-it), affordable, and “just works”.

One click is all it takes to enroll your Linode in the backup service and to start protecting your data. We manage the entire system, from making sure our backup boxes are healthy, to monitoring for failures. We’ve done the hard work so you don’t have to. What’s your data worth?

For pricing and additional details: Linode Backup Service.

StackScripts™ provide a flexible way to customize our distribution templates. They’re very easy to use — find a StackScript, answer its questions, and click deploy. When the deployment is first booted, the script is executed and does its thing. You can even watch its progress by viewing the console.

StackScripts can be private to your account, shared to the Linode community, or chosen from our library of open source StackScripts. The Linode Manager Users and Grants permission system enables you to restrict who can use or edit your private StackScripts. The Linode API can even handle StackScripts, so management can be rolled into your existing workflow.

You can browse the repository of public StackScripts.  You’ll also notice a new link off the deploy page for deploying from a StackScript, and on the main Linodes tab a link to the StackScript editor.

This Month’s Network Transfer Pool
400GB Quota, 125GB Used, 275GB Remaining

This also does the right thing when adding or removing Linodes or Network Transfer Extras mid-month, eliminating any confusion as to how the network transfer pro-rating is done.

libcloud is a standardization effort undertaken by the founders of Cloudkick to cope with standardizing cloud providers’ APIs. It has been my honor to work with Alex Polvi and libcloud’s contributors on integrating the Linode API into libcloud; today marks success for everyone involved.

Using libcloud (written in Python), a simple recipe to reboot all of your Linodes would look like this:

from libcloud.providers import linode
driver = linode.LinodeNodeDriver("api_key")
for node in driver.list_nodes():
    node.reboot()

Much of libcloud’s feature set is very abstract; very little of the customization offered by the full Linode API is implementable using it. Many assumptions are made in the code, and much of the Linode API is adapted to libcloud instead of vice versa — only very basic functionality is offered, as libcloud is designed to be a high-level abstraction layer, not a full solution.

For most projects, you will want to consider the full Linode API.

Here is a rough mapping of libcloud’s six features to the equivalent Linode API calls.

libcloud is currently available only via git. See its GitHub project page for more information. My personal libcloud tree is on GitHub as well, which is where I will be doing Linode development.

It is my hope that libcloud will make life easier for many of you. I encourage active testing and bug reports (I need them!) as I cannot test every possible scenario. Enjoy!

You choose the plan, your account is invoiced (or credited) based on the difference in cost and the number of days left on your billing cycle, and then your Linode is migrated to its new host server.  Simple.

Resizes are supported in the API via the new linode.resize() method.

This new version allows for complete Linode life-cycle management.  Now you can add and remove Linodes under your account, manage their disk images and configuration profiles, list IPs, issue boot and shutdown jobs, and query the status of host jobs.

The API is governed by the existing Users and Permissions system, so you’re able to create users under your Linode.com account, generate their API key, and allow them access to only the objects you’ve specified.

As always, Linodes added through Linode.com (and now the API) are invoiced through the pay-period you’ve selected.  Removing a Linode issues a credit back to your account for the remaining unused portion, effectively providing instance-day billing.

• Linode API 2.0 Reference – Reference Documentation
• Python Bindings – by TJ Fontaine, Ryan Tucker, and others
• PHP Bindings – by Kerem Durmus
• Perl Bindings (v1)

The automation provided by the Linode API allows your applications and tools to directly control your Linodes in our Cloud.  We’re excited about the possibilities and really look forward to seeing the creative projects that will undoubtedly grow alongside our continued development of the API.

Login IP Whitelisting and Notification Feature
You’ll receive a notification via email if someone attempts to log into the Linode Manager as your username from an IP not on your whitelist. The email contains instructions for adding that IP to your whitelist. IPs not on your whitelist are denied access.

Passwords are required to be more complex
Passwords must contain characters from three out of four sets: lower case, upper case, numbers, and punctuation, in addition to the old requirement of being a minimum of 6 characters long.

DNS Manager zone AXFR control
You can now specify whether a zone can be AXFRed from our nameservers. Right now it’s an on/off thing, but we’ll soon be adding support for specifying ranges and/or specific IPs that can transfer the zone.

We’ve also laid the groundwork for passwords with an expiration date (we’re now keeping track of when a password was set). Some other ideas are still on the table, like only allowing a few failed log in attempts within a short time span, to reduce the possibility of brute forcing accounts that may not have the IP whitelisting feature enabled…

Security can be a pain, but it’s a necessary evil. It’s a compromise between security and convenience, and we hope we’ve struck a fair balance.

I’m pleased to announce that we’ve started the beta program for our new service: Managed Backups.  You can learn more about the progress of the beta program here:

Linode Backup Service Beta Forum

Linode Backup Service

We want you to have backups. Hell, I want backups. But they’re tedious to configure and monitor. We’ve all heard the stories (and possibly experienced them) when you need a backup long after configuring them you realize they haven’t been running successfully for months. So, our goal for the Linode Backup Service was ambitious: create a reliable, redundant and highly available system, that’s easy to use (set-it-and-forget-it), affordable, and Just Works.

Description
The Linode Backup System is designed to be an easy to use, reliable and redundant on-site backup solution for your Linode. It performs backups without causing any interruption of your running system, and is seamlessly integrated into the Linode Manager.

Backing Up
There are four backup slots: Three of the slots are executed and rotated automatically: a daily backup, a 2-7 day old backup, and an 8-14 day old backup. The fourth backup slot is a user-initiated snapshot and remains in place until another user-initiated snapshot is taken.

You can configure the time upon which the automatic backups are initiated from a list of 2 hour windows — you’ll want to perform any database dumps before this window. You can also configure which day of the week to consider for the weeklies.

Restoring
You can restore a backup to any of the Linodes attached to your account, even if it does not have backups enabled. Currently only a full restore is possible.

Redundancy
We built a custom distributed and scalable storage engine which will replicate your files across at least two storage nodes. Even your backups are backed up!

Features and Limitations
The backup system must be able to mount your disk images on the host. If you’ve used fdisk on your images to create partitions, or created encrypted volumes, or done anything other than use our deployment or disk image creation tools, we won’t be able to back up the data. The backup system operates on files, not at the block level.

A failed backup will never rotate out a good one. If a backup fails on the day of a weekly backup, the next oldest backup will be used for that weekly slot.

Files that have been modified, but are the same length and without any metadata changes (like mtime) will not be considered “changed” during a subsequent incremental backup.

Currently, only ext2/3 volumes can be backed up. This limitation will be removed in an upcoming release.

ACLs are correctly backed up and restored.

Pricing Structure (tentative)
Linode 360: $5.00/mo
Linode 540: $7.50/mo
Linode 720: $10.00/mo
Linode 1080: $15.00/mo
Linode 1440: $20.00/mo
Linode 2880: $40.00/mo

Backup Service Beta

How do I participate in the Backup Service Beta?
Participating in the beta is free of charge.

We’ve only deployed the storage hardware in the Newark, NJ facility. So, for now, you must have a Linode in Newark to participate in the Backup Service Beta. Open a ticket under that Linode and request that we enable backups.

What happens at the end of the beta?
The backup service will be scheduled to be turned off automatically. However, we’ll give everyone the chance to retain their backup service and will start charging for it.

What kind of risk is there? Is this thing going to work?
There’s little risk to your existing data. However, I wouldn’t rely on our backup service as your only form of backup just yet. During the beta period, backups may be inconsistent or incomplete, or we may need to wipe all of the backup data and start fresh. In other words, keep your own backups and don’t rely on this thing working. You’ve been warned!

What about the other facilities?
Atlanta and Dallas sometime later this month, and Fremont early May.

Want to learn more?  Following along in the Backup Beta Forum