Head in the Clouds

On my recent trip to Japan, I discovered during a CloudStack presentation that one of the Japan CloudStack User Group members, Takuma Nakajima, had written an auto installation script.
This script does more than just 'yum install cloud*' it actually handles the configuration of the host. Sadly all of the directions were in Japanese, and when I first tweeted about the existence, I quickly received a request for documentation in English, and during LinuxCon Japan, Satoshi Shimazaki and Takuma Nakajima translated the README

This really is a quick and simple way to get started with CloudStack - simply pass in the arguments for what you wish to have setup, and let it do all of the hard work.

 

 

 

The Apache Software Foundation has been accepted has a mentoring organization for the 2013 Google Summer of Code. If you are interested to work on CloudStack for GSoC. Check out the slides below, follow the links and apply.

A new version of the knife-cloudstack plugin has appeared (v0.0.14), and seems pretty much on time - averaging about 6 months now between releases.

This release, Sander Botman from Schuberg Philis really stepped up and lead the way in the 15 newly added capabilities, along with handling tons of pull requests for bugfixes and updating functionality. You can check out the complete list of new awesomeness here.

If you are a chef user, you should really check out knife-cloudstack, you can download the source from:
https://github.com/CloudStack-extras/knife-cloudstack

Or just install it with:

gem install knife-cloudstack

Today was a great milestone for Apache CloudStack. If you haven't seen the news (but yet somehow have come across this blog post???) the Apache Software Foundation announced that CloudStack had graduated from the Incubator as a top-level project. While in many ways it marks the end of a number of personal and project goals, it's also just another milepost along the journey. I've been working on CloudStack since most folks knew it as 'Cloud.com', and it's amazing to see the difference over the space of a couple of years.
I've been involved with several open source projects for a number of years, and I knew of the ASF by reputation, but had no personal experience. I spent weeks reading the documentation on the website when we first began discussing the potential for a move to the ASF, and I rapidly became both impressed and afraid. Impressed, because I saw codified in front of me the most transparent and open expectations of anything I'd been involved in. I suddenly appreciated why the ASF had the reputation it did. Afraid because the magnitude of change was incredible. The transformation hasn't been perfectly smooth, I even questioned if the dramatic change would be so much as to be overly disruptive. Many folks have written of how dramatic it is to open source a project - but to take a project that was open source but still heavily commercially governed and move that to the Apache Software Foundation, is both extremes of the open source spectrum.
Many people will write about the tremendous growth in community numbers, the more interesting story to me is the tremendous growth of community responsibility, over 50% of the Project Management Committee don't work for Citrix. Of course committers and PMC members are expected to behave as individuals, and in the best of interest of the project, but that amount of diversity in a short time is impressive. I also find it fascinating just how many folks who are participating are CloudStack users; they have truly taken ownership and responsibility for their IaaS platform.
What does graduation mean from my perspective? A number of different things, but most poignantly, it means that we have met the expectations of our mentors, the Incubator, and the Apache Software Foundation.
I am excited about the future. I have no delusions that for many, or even most of our users, our graduation has little or no immediate impact. It does have an impact for the project, as we shift our focus forward, and I think that will tremendously benefit our users. I think that you'll continue to see impressive things from Apache CloudStack, we're really only getting started.

A couple of words of thanks to folks

I can't express how wonderful our mentors were. They understood the process, they saw the challenges, they stepped in where appropriate and let us find the solution when we needed to. I've walked away thoroughly impressed at both the individuals as well as the incubation process in general, I am sure it can be improved, but struggle to think of anyone doing it better.
The folks at Apache Infrastructure - they are doing an incredible and impossible job - supporting well over 100 top level projects including such behemoths as Hadoop, Maven, and now CloudStack; dealing with plenty of inbound incubator projects, some of which, like CloudStack, have years of history, and thus plenty of baggage to bring with them. Thanks for the immense amount of help you folks have provided.

So I am working on writing an SELinux policy for the CloudStack KVM agent so that SELinux can be left enabled. Why you ask? Well I really dislike advocating for people to turn off a security mechanism to get software to work. Additionally I really want some of the advantages of sVirt. But here is where I'd like to solicit some help. If you are running KVM with CloudStack you naturally have SELinux set to disabled or permissive. If you have it set to permissive, and would consider installing my current policy definition - it would be greatly appreciated. What's the impact of you testing my policy? Well nothing right now - you're in permissive mode, and we won't change that during testing, so all you'd be doing is hopefully cutting down on AVC denials in /var/log/messages or in /var/log/audit/audit.log

So how do you help:

First install the new policy:

You can get the current version here: cloudstack-agent.pp once you have that on the hypervisor - run:

semodule -i cloudstack-agent.pp

Make sure you have auditd installed:

rpm -q audit

The above should show you whether or not you have audit installed. If not you can install and start auditd with the following commands:

yum -y install audit service auditd start chkconfig auditd on

The audit package ensures that all AVCs are logged to a dedicated file (/var/log/audit/audit.log) rather than /var/log/messages.

If you already had auditd up and running, lets rotate the logs

This will make it much easier to diagnose any missing policy items:

service auditd stop mv /var/log/audit/audit.log /var/log/audit/oldaudit.log service auditd start

Now go about your business, deploy machines, destroy machines, do weird and wacky things, we are essentially looking for new entries in audit.log to see what we have missed. If your audit log shows up with items in your audit log, please upload them to this bug: CLOUDSTACK-337

You have questions??

Do they match these below? If not ask on the list.

Wait, are you testing this yourself?

Of course I am - I've long since (by which I mean I applied it while writing this) applied this to all of my KVM nodes, however, I have only a small percentage of potential configuration options. Specifically, I am running CloudStack 4.0.1, with KVM on EL6.3, with NFS and local storage and VLANs for isolation.

Wait - are you making my KVM hypervisor less secure?

Probably not. I mean to begin with you are currently running with SELinux in permissive mode. This is an effort to allow us to turn on SELinux, use sVirt, and have a more secure hypervisor. Still not assuaged? Want to see the source? It's here.