Slicehost

This post is an effort to summarize and clarify information about the changes to Slicehost. We will update it with new information as it becomes available. Links to threads with more detailed information are listed at the end.

There will be two major changes for Slicehost customers.

1. Rackspace will move Slices currently in the STL datacenters to a Rackspace-owned datacenter where they will enjoy newer hardware and better connectivity.

2. For most customers this this will be an automated process. The experience will be very similar to a slice resize operation. The new server will be the same flavor as the original slice and will be located in a new datacenter.

3. Servers in STL-A in the IP address range 208.75.84.0 - 208.75.87.255 will get a new public IP address and will need to update DNS records as part of the migration. All other slices will keep their public IP addresses.

4. Slices will become Cloud Servers. As the underlying platform for Slicehost and Cloud Servers is essentially the same, this is primarily a billing change.

5. The transition will be automated and will happen in the first half of 2012. There is no downtime involved.

6. After the change servers will be managed with the Cloud Servers control panel (not the SliceManager).

7. Pricing will change. After the conversion prices will be calculated using the Cloud Servers utility pricing model, resulting in a reduction in overall cost for most customers.

More details on those points follow.

1. DATACENTER MIGRATION

How the conversion affects your slice will depend on its datacenter.

You can see your slice's datacenter by going into the SliceManager, clicking on the slice for more details, and then checking the "Datacenter" entry at the end of the detail list.

If the datacenter does not begin with "STL" your slice will not be migrated anywhere and the conversion will involve no downtime.Slices in DFW and ORD are already in a Rackspace datacenter. Your slice will remain where it is and the only change that will affect you is the billing conversion (detailed further along in this post).

If the datacenter does begin with STL then your slice will be migrated to our ORD (Chicago) datacenter.You will receive more details in an email when we are ready to schedule migrations. We are working to make the migration process as easy as possible, and in many cases the migration will be a push-button process. The new datacenter in Chicago (ORD) has newer hardware and a faster network.

Some STL-A IP addresses will change. All slices in STL-B will keep their public IP addresses but not their private addresses. If your slice is in STL-A, it will keep its public IP address if it is in the range:

• 67.207.144.0 - 67.207.159.255
• 208.78.96.0 - 208.78.103.255

Your slice will not keep its public IP address if its current address is in the range:

• 208.75.84.0 - 208.75.87.255

We are still looking into options for customers who are losing their public IP addresses.

As with STL-B, all private addresses will change.

If your slice needs to be migrated you will control when the migration will start. Slices will be migrated in groups. When your slice is ready to be migrated you will receive an email two weeks in advance. Nothing will happen until you push a "migrate me" button that will become available in the SliceManager. That way you can choose a time for the migration that works best for you.

The migration will be very much like a slice resize. Your server will be active while its image is copied to a new Cloud Server in ORD. The slice will then be taken down for a final sync of any data that changed during the first copy (typically five or ten minutes). Once your server is operational again you will get an email letting you know the process is complete.

You will receive more information as we get closer to the opening of the migration window. Please note that due to the upcoming holiday season, the STL migrations will not begin in October as previously planned. We want to avoid any unnecessary disruptions during this time and now expect migrations to start in January of 2012.

2. BILLING AND CONTROL PANEL CHANGE TO RACKSPACE CLOUD SERVERS

This applies to all Slicehost customers and is planned for the first half of 2012. Slices will become Cloud Servers. This means you will start using the Cloud Servers control panel and your pricing will be based on the Cloud Servers utility model.

Owing to the similarities between the two services, in most cases the change should be transparent and won't require additional work to complete. Cloud Servers offer additional features not available on Slicehost and will continue to be enhanced over time.

Bandwidth usage will be the primary determinant in working out how the change will affect what you pay for your service each month. Slicehost bills on a monthly basis for packages that include a set amount of memory, disk space, and bandwidth. Rackspace Cloud Servers bills hourly for the base instance (memory and disk space) but bills bandwidth on a pay-as-you-go usage basis.

You can calculate your expected monthly charges with the Rackspace Cloud Servers price calculator. The change will result in a decrease in monthly costs for most customers based on historical bandwidth usage.

Any Slicehost account balance will be transferred to your new Cloud Server account. If you already have a Cloud Server account your accounts will be merged in the transition process.

This thread will be locked to discussion, but if you have any questions please either create a thread in the migration forum or post to one of the existing threads. Our techs are also available via email or live chat to answer any questions and concerns.

To compare pricing and see how much you would be charged based on expected bandwidth usage, we have a price calculator here: Cloud Servers Pricing

We have collected more information about the conversion in other threads in our forums.

• The category in the forum dedicated to migration discussion can be found here: Migration to Rackspace Cloud

• There is a forum thread covering more general questions about the conversion here: Migration to Rackspace Cloud: Q&A with Mark Interrante and Rackspace

• This forum thread discusses the change and its impact on customers: What's New, What Changes, What's better in the transition to Cloud Servers

• This thread talks about the details of the STL migrations: The move to Rackspace Cloud Servers

• This thread discusses planned improvements to the Rackspace Cloud Control Panel: A new Rackspace control panel is coming

As part of Rackspace, we at Slicehost are excited to introduce a new category of hosting at the Rackspace Cloud called Managed Service on the Cloud. This service offering is a complete 24x7 managed service level, allowing you to spend less time worrying about infrastructure and instead more time to focus on your core business.

If you would like to learn more about Cloud Servers with a managed service level, please review this recent blog post on our Rackspace Cloud website.

In addition, we will hold a live webinar to help you learn more about Cloud Servers with a managed service level and answer any questions you may have. Presenting at the webinar will be Lew Moorman, Chief Strategy Officer of Rackspace, Frederick Mendler, VP of Sales & Marketing, and Paul Salisbury, Program Manager for our Managed Service Level on The Rackspace Cloud. Register now.

Because sometimes Gentoo and Arch users need a little help too, a few articles have been added to the repository just for those distributions.

For starters, there's now a section in the repository for Arch. There wasn't before. And now there is.

Arch articles section

We adapted our setup articles for new slices to the images we have up for both distributions. They start here:

Arch 2010.05 setup - part 1

Gentoo 10.1 setup - part 1

Furthermore, several apache articles have been adapted to Gentoo and Arch. Those include the more recent tutorial on installing apache and PHP, instructions for a barebones apache installation, and enabling mod_status to track apache's performance.

Installing apache overview

Barebones apache install overview

Enabling and using apache's mod_status Overview

That's all for now but we'll always be working on more.

As ever, if you have any issues, be it with these articles or anything else regarding your slice, our support people are available 24/7. They can be found lurking in SliceChat or answering emails sent to .

This week we've added articles on Linux timekeeping with NTP and a couple monitoring tools that can help track down I/O and swap use.

NTP is the "Network Time Protocol", and it can be used to set your server's clock. Slices running newer kernels will benefit from this since the switch to pvops kernels means that those slices no longer get their time from the hardware clock.

Using NTP to sync time

The first monitoring tool we look at is "iotop". You use iotop in the same way you'd use top, but instead of checking CPU and memory use you're looking at swap activity and disk input/ouput (I/O). You run iotop, you watch the numbers change, and you see which processes are using more swap or causing more disk activity. Easy.

Using iotop to check I/O and swap

The other monitoring tool we examine is "dstat". Like iotop dstat can be used to look at swap use and disk I/O, reporting the process using the most of each, but it can also report a lot of other system stuff. And it does it in the order you choose, with pretty colors to boot. Think of it as a really beefy vmstat.

Using dstat to check I/O and swap

Using dstat with scripts and external modules

For CentOS and Red Hat users we recommend using dstat because of the version of python currently installed with those distributions. It's possible to run iotop on those distributions, but only if you install a separate (newer) python instance just for iotop.

If you have any questions or concerns regarding these or other topics, visit us in SliceChat or contact us via email at support@slicehost.com. Our team is available 24 hours a day, 7 days a week.

We are pleased to announce added support for Fedora 14 (Laughlin) 32-bit and 64-bit images. These images are now available in the SliceManager and can used when adding a new slice to your account as well as rebuilding an existing one.

If you choose to rebuild your slice, please keep in mind that any existing data will be permanently erased.

We also have some setup articles for Fedora 14 to help you get started with the initial configuration your slice.

Fedora 14 (Laughlin) Setup Part 1

Fedora 14 (Laughlin) Setup Part 2

On Thursday, December 2nd, Fedora 12 will no longer officially be supported and will be removed as an available option from within the SliceManager. If you wish to continue utilizing this image, you will want to take a backup of an existing slice before this date.

If you have any questions or concerns, please come visit with us in SliceChat or via email at support@slicehost.com. Our team is available 24 hours a day, 7 days a week.

We're very happy to announce the ability to run your own kernel on your Slices. Until now, there was a choice of kernels from which to boot but it was controlled via the SliceManager. Running your own kernel allows you fine-grained control over the features you specifically need as well as greater compatibility with your chosen distribution.

For those that want the simplicity of not worrying about which kernel to choose or how to configure it we will, of course, keep offering our own kernels via the SliceManager.

Please be aware that this feature is currently in beta and is available for slices located in our STL-B, DFW, and ORD data centers at this time. It has been fully tested to work on the following distributions.

• Ubuntu 10.10 (Maverick)
• Ubuntu 10.04 (Lucid) LTS
• Ubuntu 9.10 (Karmic)
• Debian 5.0 (Lenny)
• Centos 5.5
• Fedora 13
• Arch 2010.05
• Red Hat EL 5.4
• Gentoo 10.1

Please Note

You will need to make some minor changes to your Slice configuration to enable your chosen kernel to boot properly. For those familiar with running their own kernels, the changes are minimal but I would stress they are essential. Files such as menu.lst will need to be changed.

We have, of course, a great set of articles ready taking you through any and all changes you need to make. The articles are specific to each distribution, so please ensure that you are using the correct one when configuring your Slice (it's easy to make a mistake which may mean your Slice won't boot).

Using pv-grub to run custom kernels overview

While pv-grub is in beta we ask that you contact support, via the Slicemanager, so we can enable your Slice to run your kernel - you will need to configure your Slice before we switch it for you. We will be happy to assist you through the process.

As soon as it comes out of beta, you will be able to select the pv-grub option from the kernel menu inside of the Slicemanager.

If you have any questions or concerns our support team is always available in SliceChat or via email at support@slicehost.com.

UPDATE 10/28: Added Gentoo 10.1 to the list of supported distributions.

We are pleased to announce that 32-bit and 64-bit Ubuntu 10.10 (Maverick Meerkat) images are now available in the SliceManager.

In order to take advantage of these images you can add a new slice to your account or rebuild an existing slice in the SliceManager. Please keep in mind that the rebuild process will erase any existing data on the slice.

We've added a couple articles to help with the initial setup and lockdown of an Ubuntu Maverick slice:

Ubuntu Maverick Setup Part 1

Ubuntu Maverick Setup Part 2

The version-specific categories were kind of piling up on the articles site so we've put Maverick together with Lucid in an "Ubuntu 10" category. The articles there have been tested with both versions, so check there for help with other topics on Maverick like web servers and logrotate.

If you have any questions or run into any issues our support staff is available in SliceChat 24 hours a day, seven days a week. We can also be reached via email at support@slicehost.com

We want to make you aware that beginning in September, due to a change in our underlying subscription arrangements with Red Hat, we can no longer offer a daily pro-rated billing option for RHEL instances. Slicehost customers will be billed for RHEL instances on a monthly rather than pro-rated daily basis.

However, the total cost of service for most RHEL customers will likely go down under the monthly billing model.

Both Rackspace Cloud and Slicehost will begin charging RHEL customers a monthly $20 licensing fee. This license fee won’t be prorated, so every Slice you spin up with RHEL will be subject to a full month’s license fee.

What this means for Slice customers:

• Instead of being billed for your RHEL license on a pro-rated daily basis, customers using Red Hat will be billed on a monthly basis (normal monthly billing cycle).

• The Slice itself will continue to be billed on a pro-rated basis - this only affects the RHEL license.

• The new fee for RHEL has been reduced to $20 per month per Slice.

• Every Slice you spin up with RHEL will be subject to a full month’s license fee, no matter how long you use it. If a Slice with RHEL is running for any portion of a month, then you will be billed for that month’s license fee.

Thank you for your understanding as we shift to monthly billing for RHEL users. If you would like help understanding how this might affect your personal usage please feel free to submit a ticket via the SliceManager, email us (support@slicehost.com) or pop into chat 24/7.

A new kernel, 2.6.35.1, is now available in the SliceManager for all slices located in our STL-B, DFW, and ORD data centers. Additionally, it is now set as the default kernel when rebuilding an existing slice or for any new slices that you may add to your account.

If you would like to upgrade the kernel on your pre-existing slice, you can do so by following the steps described in this blog post. Please keep in mind that this process will require a reboot of your slice in order to fully complete.

If you have any questions or run into any issues, we are available 24/7 in SliceChat. We can also be reached by submitting a ticket through the SliceManager or emailing us directly at support@slicehost.com.

Another article series is up, this time concerning using cron to schedule tasks in Linux. If you need to run a script regularly (like calling Drupal's "cron.php" page nightly, or backing up a frequently-changing file every hour), then cron will serve the purpose nicely.

This is one of those topics that can be as simple or complex as you want it to be. The first article covers the simple part, so start there. If you're looking to read someone else's cron schedule in cron.d or a crontab, however, you'll want to continue to the other two articles. It can't be helped, sometimes life is complicated.

Basic Linux task scheduling with cron

Fine-grained task scheduling with cron.d

Multi-user task scheduling with crontab

Hopefully the explanations will de-mystify cron a bit and make it easier to automate some of your application maintenance.

As ever, pass your comments along if you like them, don't like them, or think they need changing. And if they baffle and confuse you, our techs are in support chat 24 hours a day, 7 days a week, ready to help you recover.

Thanks for reading!

We have added support in the SliceManager for a new kernel, version 2.6.34.1. The kernel is now available in our ORD, DFW, and STL-B data centers as of this blog post. We recommend that you upgrade your slice to this version as it does include quite a few bug fixes and security updates over the previously offered kernels.

I won't go into details in this post as it is rather lengthy, but if you wish to review all of the updates included in this kernel, the full changelog can be found here

Kernel 2.6.34.1 is now set as the default for all new slice builds. However, if you are running an older kernel on a pre-existing slice and would like to upgrade, you can do so by following the steps described in this blog post.

Please be aware that upgrading the kernel on your slice will require a reboot in order to complete.

If you experience any issues or if there is anything we can assist you with, please come visit with us in chat. We are available 24 hours a day and can also be contacted by submitting a ticket through the SliceManager or via email at support@slicehost.com.

Imagine a world where code used by the biggest clouds is freely available to any developer, anywhere. A world where that code was a standard used to build private clouds as well as a variety of new service offers. In this world, workloads could be moved around these clouds easily - you could fire your cloud provider for bad service or lack of features, but not have to rewrite the software to do it. Imagine an open source cloud operating system that lifts IT to the next level of innovation, just as Linux drove the web to new heights.  

Today, we at Rackspace launched an ambitious project called OpenStack that aims to make this new world a reality.

I want to lay out the thinking that got us here and why we think this moment will change computing forever.  

"The cloud" at its most fundamental level is all about a massive supply increase in computing power. The PC era was all about putting a computer on every desk. The cloud era goes a step further, putting the power of supercomputing at the literal fingertips of every individual at anytime.  Whether it's enabling a youth soccer coach to schedule practice across the online calendars of 18 families, or helping a scientist fold proteins to design new cancer drugs, or encouraging a frontline employee to instantly and cheaply test a new marketing campaign, the exponential growth in computing power and applications is changing every corner of our economy and society. And, this era is truly just beginning. We have seen only a tiny fraction of the potential gains that arise from cheap, ubiquitous computing power.  

As this landscape has evolved, some have dismissed cloud computing as just a return to the mainframe era. This view is fundamentally wrong.  Mainframes were available to only the smartest employees at the richest companies. The cloud is accessible to all, and usable by anyone, at low cost. Its ubiquity is the source of its power.

However, there is one area where mainframe concepts are intruding into the cloud - the vertically integrated technology stack. As hardware and software merge into services, the danger of locked down proprietary software stacks are emerging in the cloud space. The cloud world changes everything, and that is not good to many entrenched interests of the old guard. Core technologies from operating systems to hypervisors to databases are being used to tie cloud customers into an integrated view of the world.  

If the web has taught us anything, it is that open systems, portability, and choice drive innovation. The open Linux system brought us a mountain of software and tools to help accomplish almost any task. And, each component, whether a database or a widget could be moved in and out freely based on the job getting done.  

We at Rackspace have long talked about an "open" cloud. And as a service provider built on our Fanatical Support difference, we have never had an interest in creating technical walls around our service. But, given that no standards tools have emerged to build massively scalable clouds, we too have had to build custom software that creates some level of wall around our cloud offerings. For months we have debated how to drive greater standards and increase the velocity of cloud technologies in general. We finally converged on the obvious answer:  open source our cloud technology.

Today, we announced a new open source project that includes those core technologies: OpenStack.  And, we are not alone.  As we looked at all the projects that already existed to drive standards we saw that other efforts were underway that complemented what we have done. We saw a ton of promise in the Nebula computing project built by NASA and are making it a core part of the project.  Taking the contributions of Rackspace and NASA as a starting point, OpenStack forms a powerful foundation of technologies including, a scalable compute provisioning engine - OpenStack Compute - and a fully distributed storage engine - OpenStack Object Storage.  

The community, which we plan to actively support and drive, is live today at openstack.org with code available for download.  

Last week we assembled a strong group of cloud community leaders and developers to meet and review the architecture, engage on technology direction and contribute code. The effort attracted more than 100 participants from 25 companies including hosting companies, telecom providers, hardware manufacturers, cloud ecosystem companies and beyond. This enthusiasm and collaboration around OpenStack has laid the foundation for a vibrant and innovative approach to building the core software to power the future cloud world. 

What do we expect OpenStack to mean for the cloud community? Some pretty major things. One, anyone will be able to run this cloud and do it anywhere. Enterprises and governments will be able to build private clouds. Service providers will have the same technology used by Rackspace and NASA to build new offers. Choice and portability are inevitable in this world. Two, the whole tech ecosystem can build around this foundation. With wide adoption, there will be a market for new services all around this core engine. From storage systems to monitoring tools to management systems, there is no end to what can be attached to the core project. Three, the cloud will advance faster than ever. Between just NASA and Rackspace, an army of developers are committed to the continued advancement of OpenStack.  With our emerging supporters in the project, we expect to dramatically expand that army. Finally, a core set of standards will be freely available and totally open. New technologies can be attached. Better solutions will be driven into the product. And, the use of this powerful technology will not tie you to the use of any other technologies.

For our customers, we think there are many benefits that flow from these community gains. Not only will this help our offers develop faster and more transparently, but our customers can run private editions of our core systems in house or in our managed hosting operation.  

We could not be more excited about the launch of this project and the enthusiasm around it. As a company that has invested a great deal in the development of cloud technologies, we did not take the decision to open source lightly. We think this decision will serve our interests and those of our customers. While we at Rackspace hire top developers and engineers to make sure our technology is second to none, seeking a technology advantage has never been our approach.   We have our own vision about how to deploy this technology and serve customers - by giving them seamless access to scalable computing with the trusting partnership that comes through Fanatical Support. But, there will be many approaches and winning formulas. We think by welcoming those approaches and driving standards and more rapid innovation we will all win.  

We hope you join us in this cause. We know there are many parties who might want to join us in the effort, please reach out to us.  

We look forward to updating you as we make progress.

Author: Lew Moorman - President, Cloud and Chief Strategy Officer

More articles, that is. This time about a subject both esoteric and essential: File permissions.

Yes, Linux file permissions can be pretty scary, especially when you see your first "chmod 755" or "chown root:www-data". A lot of times explanations don't even help that much, and you only really start to understand permissions through trial and error.

But we've taken a shot at the explanation thing, covering aspects of file permissions ranging from what it means to own a file, to changing permissions with chmod, to setting the umask, to discovering that at least half of what you find on the Internet about the "sticky bit" is wrong (seriously, it turns out most of us were actually thinking of setgid).

In short, the articles range from beginner topics to advanced. They may not convey instant and complete understanding of file permissions (though I hope they do), but they should at least give you a head start that can make the trial-and-error stuff a lot easier.

The articles, in order, with links:

Linux file permission concepts

Checking Linux file permissions with ls

Using chmod, part 1 - symbolic mode

Using chmod, part 2 - octal mode

Umask and unusual file permissions

If you run into problems, post about them in the comments, email us, or hit SliceChat to get help from our tech support staff 24 hours a day, seven days a week.

Thanks for reading!

We have a new article series up on using the logrotate service to, well, rotate logs. I recommend it to anyone with a slice, especially if they've never heard the term "log rotation" before (or did, but thought it had something to do with lumberjacks).

Understanding logrotate

It's a two-parter, with the first part discussing the basics of logrotate and why you'd want to use it, while the second part describes how to set up log rotation for virtual hosts and gives some troubleshooting tips.

Quite often when a customer comes to us with a disk space problem, or are concerned because their slice resize is taking a long long time, the culprit is a giant log or two. That's especially the case for virtual host logs, but it can also happen with custom applications that write to their own logs. Once logrotate is set up it will take care of those logs for you, making sure they don't get too bloated.

In the "worth mentioning" department, earlier this month Matiu posted the steps he used to upgrade PHP on an Ubuntu Hardy slice. Plenty of people are still using Hardy, so the instructions may prove useful to others.

Upgrading PHP on Ubuntu Hardy

As always, we have people sitting in slicechat and monitoring requests sent via email to support@slicehost.com. If you have questions, concerns, or an aching need for human contact, we're around 24/7.

Thanks for reading!

Earlier this week, we introduced a new kernel, 2.6.33.5, in the SliceManager. This kernel is currently available for all slices located in our STL-B, DFW, and ORD data centers and is now set as the default when creating any new slices.

In order to upgrade your pre-existing slice to the latest kernel available, we recommend that you follow the steps discussed in this previous blog post.

As always, please remember that this process does require a reboot of your slice.

Additionally, for those who wish to delve into the advanced practice of building kernel headers or compiling a module on their slice, we are pleased to be able to provide you with the following articles that we hope prove useful:

Downloading and using kernel source code

If you have questions or run into any issues, our friendly and knowledgeable support staff is available in SliceChat 24 hours a day. As well, please feel free to email us at support@slicehost.com if there if there is anything we can assist you with.