Today we announced a collaborative support and engineering agreement with Dell.  As part of this agreement Canonical will add Dell 11G & 12G PowerEdge models to the Ubuntu Server 12.04 LTS Certification List and Dell will add Ubuntu Server to its Linux OS Support Matrix.

In May 2012, Dell launched the OpenStack Cloud Reference Architecture using Ubuntu 12.04 LTS on select PowerEdge-C series servers. Today’s announcement expands upon that offering by combining the benefits of Ubuntu Server Certification, Ubuntu Advantage enterprise support, and Dell Hardware ProSupport across the PowerEdge line.

Dell customers can now deploy with confidence when purchasing Dell PowerEdge servers with Dell Hardware ProSupport and Ubuntu Advantage.  When these customers call into Dell, their service tag numbers will be entitled with ProSupport and Ubuntu Advantage, which will create a seamless support experience via the collaborative Dell and Canonical support and engineering relationship.

In preparation for this announcement, Canonical engineers worked with Dell to enable and validate Ubuntu Server running on Dell PowerEdge Servers.  This work resulted in improved Ubuntu Server on Dell PowerEdge support for PCIe SSD (solid state drives), 4K-block drives, EFI booting, Web Services Management, consistent network device naming, and PERC (PowerEdge RAID Controllers).

Dell hardware systems management can be done out-of-band via ipmi, iDRAC, and the Lifecycle Controller.  Dell OMSA Ubuntu packages are also available but it is recommended to use the supported out-of-band systems management tools.  Dell TechCenter is a good resource for additional technical information about running Ubuntu Server on Dell PowerEdge servers.

If you are interested in purchasing Ubuntu Advantage for your Dell PowerEdge servers, please contact the Dell Solutions team at Canonical.  If your business is already using or thinking about using a supported Ubuntu Server infrastructure in your data-center then be sure to fill out the annual Ubuntu Server and Cloud Survey to provide additional feedback.

Read more

So, I've been around the Ubuntu community for a while. I installed 4.10 (Warty Warthog) as soon as it came out, I was fighting to keep my Debian installation usable at the time. I instantly fell in love and dove into the community, I wanted to do whatever I could to make the project succeed. It was exactly what I was looking for. At the time, Canonical was also shipping CDs to anyone who wanted them, which gave the project a much more professional feel to it.
And, the focus Mark set for the project turned out to be the right one, it very quickly converted thousands of open source enthusiasts to it and a solid, technically capable community started to be built around it. Soon enough, with the focus laser-sharp on making Ubuntu as usable as possible, non-technical folks started to show up, people who were Windows users but were tired of it and looking for something better. These people gave our project an awesome foundation for support (once they figured out how to make certain things work, they'd immediately help the next person who came along with this problem). Translations grew, since it was a great way for a non-technical person to help. documentation grew, advocacy grew, communication, marketing, you name it, it was growing.
As things moved forward, there were some tough decisions to be made. I remember when Compiz came around, it was very immature and almost guaranteed it would break your system, just have a quick read through the Slashdot comments! You could very easily replace the word "compiz" for "unity" when it was first introduced and you'd have most of the same comments that went on when that first happened.
But, it was the right choice. The hard and unpopular choice. We, the community at large, mostly wanted a stable system. Mark, Canonical, were pushing to mature the technology so be able to build awesome things on top of it. It was the same story for Pulseaudio, the same for binary drivers, we've been here before, over and over.Change is very hard, and a lot of it feels wasteful. Nobody wants to waste their free time, you want to make it count.

As for where we stand today, I first want to be clear that my initial reaction to the flood of changes being proposed upset me as well. A lot. I laid low for a while so I could clear my head and understand what was going on before reacting. When the Rolling Releases proposal came out, I read the email on ubuntu-devel (which, btw, is where I read about it, there was no internal Canonical "announcement") and I was frustrated with how it was being presented. It felt like Canonical imposing whatever they wanted, bulldozing over the community. How could Rick do something like that? He's a smart and well-intentioned person, this isn't the smart thing to do. I started writing up an angry email to the Community Council, and as I did, I stopped to re-read the original email to rant with specific references. When I did, I couldn't believe my eyes. The email was clearly stated as a proposal, open to discussion with quite of bit of work done beforehand, ending the email with:

"Such a change needs to be discussed in the Ubuntu community. Therefore, I asked my team to put together a strawman proposal for how such moving to a monthly cadence with rolling release might work."

Go ahead, read it yourself. As a long-time member, my gut feeling is that in the past this would of been presented to the Technical Board first to be discussed, and then a wider conversation would be had. But the reverse makes more sense to me actually, have a wider conversation first, then bring it to the Technical Board.
So, now I deleted my email and started all over again. I explained how I was feeling rather than rant about things that apparently didn't happen as I imagined them, and just admitted that I no longer knew where we were as a project and needed to talk it out a bit.
So we did. We talked, vented, ranted, looked at the positive side of things, the negative, remembered the past, imagined the future.

The way I see things now is that the project has changed. But this was the path all along, it should of been more obvious. First we won the Linux distro user base, gained support, a community, a clearer focus on what less technical people wanted and it felt great. People were moving to Ubuntu left and right, first on the desktop, then the server migrations came along with it. But that was not the goal. The goal was (and I quote from bug #1) "Our work is driven by a belief that software should be free and accessible to all.". The "all" part of that is the key. That's why we made the desktop slow and buggy for a while to introduce compiz, even though it didn't really fill any need for technical users. Same with Unity, same with Pulseaudio, same with the Ubuntu font, same with shipping free CDs to anywhere in the world.
So as we progressed in our goal, technical users felt a bit more and more distant from what was changing, because they were no longer the primary user. It makes the "scratch your own itch" part of free software a bit harder. In exchange, I started to meet taxi drivers who were Ubuntu users, musicians, graphic designers, writers. I'd see Ubuntu out in the while in the strangest places.

And now, the world has changed. It no longer seems like the way to make computing available as free software to everyone can be accomplished with just a great desktop. Mobile phones and tablets is where most of people's time seems to be shifting to. It's a multi-device world and it's here to stay. If we want to fix bug #1, we now need to change tactics and tackle the full story. There seems to be a window of opportunity for us as a project right now, I don't think we'll get many more of these. It feels like a now-or-never kind of moment, and I can't imagine having invested most of my energy in the last 8 years fading away into a niche market. That's not what I set out to help do.
It's going to be a bumpy ride for a while, we need to move fast, and speed is not one of the easiest things to do when you need to find consensus across many different people, timezones, interests, goals, agendas and languages. I don't see what other choice we have than to rise up to the challenge and find a way to make it work.

Speaking purely from a personal point of view, I think Canonical will need to push harder for changes in processes, tools, libraries and focuses. I also happen to think Canonical has done poorly at presenting and driving these changes. Not due to a lack of trying to do the right thing, it's just really hard to do. Stress, pressure, deadlines, partners, confidentiality agreements, private negotiations, business deals to ship Ubuntu on millions of devices, it all sets you up to rush and get things done as quickly as possible. That's how the market works. But when you're not immersed in all of that, from the outside, it just looks slightly evil and a bit like bullying.
I think Canonical can and will do better, it has to, I feel the survival of the company partially depends on it.

One thing to remember though, is that free software is very much like evolution, survival of the fittest. This means trying out many different things, and the best ones overall survive and thrive. Competition is essential. The fact that Canonical is putting out there more free software projects is the best thing that can happen to the movement, no matter how many times you yell out that you know for a fact that if that same effort was spent on an existing project it would all be better. If that were true, there would be one Linux distro, period.
As long as it's free software, and Canonical is shoveling code into it, that's what counts at the end of the day. Working, maintained code. Don't forget that. If Canonical is wrong about, let's say, that investing in Mir is a better bet than investing in Wayland, ultimately, it's Canonical's money. If it's done in a way that developers are drawn to help, it'll be cheaper and happen faster. It's a win-win. The fact that they are betting on free software no matter what is what counts.

So I think it's time. In many ways this feels like the last big battle. We fought and won a lot to get here, it's now time to win or loose the war.

Read more

Recently there has been some fire flowing about Canonical in the community. These concerns started off as sporadic at first and then we saw a small blog avalanche (blogalanche, if you will) as a number of folks piled onto the ride.

I feel somewhat trapped in the middle of all of this. On one hand I work at Canonical and I believe Canonical are acting in the honorable interests of Ubuntu in helping to build a competitive and forward-looking Free Software platform, but I also feel a sense of personal responsibility when I see unhappy members of our community who are concerned with different aspects of how Canonical engages. Essentially, I sympathize with both sides of this debate; both have the best interests at heart for Ubuntu.

From my perspective there is a balance that needs to be struck. Our community needs to be transparent and open, but also nimble to react to opportunities (such as the convergence story), but also Canonical play an important role in helping us to drive Ubuntu to the masses. We need to be able to work in a way that maintains our Ubuntu values but also gives Canonical the opportunity to get our platform out to the market effectively to reach these users.

I believe one cannot exist without the other; Canonical cannot deliver this vision without our community and Ubuntu would be significantly debilitated if there was no Canonical providing staff, resources, and other investment into Ubuntu. Canonical is not evil, and the community is not entitled; we all just need to step back and find some common ground and remember that we are all in the circle of friends.

This symbol is as potent to me as it was back in 2004.

When I got interested in Linux back in 1998 and wanted to make it my career, my primary motivation was to bring freedom of technology to everyone. This is what attracted me to Ubuntu and ultimately working at Canonical. I don’t want to be rude to other distros who are quite happy within their remit of making a great OS for Linux enthusiasts, but I frankly don’t want to settle for that. I want Ubuntu to be the choice for Linux enthusiasts, but for us to not stop there and also bring Free Software to people who have not yet been blessed by it, and who may be new to technology and the opportunities it provides.

Achieving that goal is not just as simple as making the source code available for the platform and setting up a bunch of mailing lists. It means delivering simple and elegant user experiences built for the needs of our users, consistent and beautiful design, professional-grade quality, strong hardware and software partner relationships, certification across a range of hardware profiles, training, responsive security, diverse marketing and advocacy campaigns, and many other areas. Both Canonical and the community contribute extensively to provide these things that we need to get over that chasm, and importantly, each provides things that the other cannot.

It turns out that building this simple, ubiquitous Free Software experience for everyone is hard. We can’t just settle for the tried and tested approach of pulling the latest upstream software and integrating it into a single Operating System. That is tough, intensive and grueling work in itself, but to achieve the goals I mentioned above we need to be constantly challenging ourselves to innovate and go faster in how we deliver this innovation to our users. We need to always challenge the status quo…not for the sake of being different, but for the sake of not restricting ourselves to tradition and instead helping us to be better at what we do, and ultimately achieve our goals of getting Ubuntu into the hands of more people.

We saw this challenge with Unity: that was a tough, but necessary decision. While we suffered over the firestorm around Unity, I think it ultimately put us in a better position, and now we have a single convergent user interface that spans across multiple devices and we will soon have a single convergent Unity code-base across these devices too. In an era where desktop shipments are down due to the impact of phones and tablets, we are no longer trapped in a form factor that has had a decreasing scope of opportunity for us; the desktop is just one part of our wider convergence vision. This opens up the market for Ubuntu and the Free Software and Open Source values we encompass. While some people in some comment boxes will still bring the hate about Unity, I think that overall it has put us in a position to get Free Software in the hands of more people than if we didn’t make that difficult decision, and the sheer level of interest in Ubuntu for the phone, tablet, TV, and desktop is testament to that.

Put it in my pocket, on my lap, on my desktop, and hang it on my wall.

While making tough decisions is important, it is also important that we maintain our Ubuntu values too. One core value is that our platform and community are open for discussion and participation, so everyone is welcome to help put their brick in the wall. Our archive has long been open and there are many ways to contribute, and while some of these projects were secret before-hand, now everything is out in the open and available for participation. Some may disagree with the rationale of keeping things private, but particularly in the case of Phone and Tablet, the “big-reveal” helped us to have a big splash and generate more press interest and partner inquiries, and thus help us along to our vision.

Importantly though, we made the source and community on-ramp available as soon as we feasibly could. The code for Unity, Ubuntu Touch, and Mir is publicly available, and we are eager to invite people to join and shape those projects. This week we also ran our very first online UDS, with the goal of making the Ubuntu planning process as open and accessible to all as possible, not just those who could travel, and on a more regular cadence. All of the videos, notes and blueprints from that event are archived here. I am confident for the next event we will have an even smoother, better-run UDS, with even more participation.

We are now in a position with a clearly articulated vision around convergence and cloud orchestration, full source availability, daily builds of images, and public mailing lists and IRC channels to have those conversations. Everything is available in public blueprints and tracked at status.ubuntu.com, and we have many outreach campaigns to help our community participate in this vision, such as the core apps project, port-o-thon, regular cadance testing, charm quality improvements, SDK participation, and other areas. Our community should expect our projects to be open, accessible and collaborative, and if they are not, please raise your concerns with the Canonical engineering managers, or talk to me either publicly on my weekly Q&A video hangout at 7pm UTC every Wednesday on Ubuntu On Air, or privately at jono@ubuntu.com, or by contacting me on Freenode IRC – my nick is jono. My door is always open.

Things are never perfect in a community, and I am not suggesting we are perfect either, but I believe we are at the cusp of an incredible opportunity to get Free Software and open technology into the hands of the masses, not just by wishing it to be true, but because there is genuine market opportunity for it to be true.

Read more

I ran across an article last week about the fear of cloud lock-in being a “key concern of companies considering a cloud move“.  The article was spot on in pointing out that dependence upon some of the higher level public cloud service features hinders a user’s ability to migrate to another cloud.  There is a real risk in being locked into a public cloud service, not only due to dependence on the vendor’s services, but also the complexity and costs of trying to move your data out.  The article concludes by stating that there “aren’t easy answers to this problem“, which I think is true…but I also think by simply keeping two things in mind, a user can do a lot to mitigate the lock-in risk.

1. Choose an Independently Produced Operating System

Whatever solutions you decide to deploy, it’s absolutely critical that you choose an operating system not produced by the public cloud provider.  This recent fad of public cloud providers creating their own specific OS is just history repeating itself, where HP-UX, IRIX, Solaris, and AIX are being replaced with the likes of GCEL and Amazon Linux.  Sure, the latter are Linux-based, but just like the proprietary UNIX operating systems of the past, they are developed internally, only support the infrastructure they’re designed for, and are only serviceable by the company that produces them.  Of course the attraction to using these operating systems is understandable, because the provider can offer them for “free” to users desiring a supported OS in the cloud.  They can even price services lower to customers who use their OS as an incentive and “benefit”, with the claim it allows them to provide better and faster support.   It’s a perfect solution….at first.  However, once you’ve deployed your solution to a public cloud vendor-specific OS, you have made a huge first step towards lock-in.  Sure, the provider can say their OS is based on an independently produce operating system, but that means nothing once the two have diverged due to security updates and fixes, not to mention release schedules and added features.  There’s no way the public cloud vendor OS can keep up, and they really have no incentive to, because they’ve already got you….the longer you stay on their OS, the more you will depend on their application and library versions, thus the deeper you get.  A year or two down the road, another public cloud provider pops up with better service and/or prices, but you can’t move without the risk of extended downtimes and/or loss of data, in addition to the costs of paying your IT team the overtime it will take to architect such a migration.  We’ve all been here before with proprietary UNIX and luckily Linux arrived on the scene just in time to save us.

2. Choose an Operating System with Service Orchestration Support

Most of the lock-in features provided by public clouds are simply “Services as a Service”, be it a database service,  big data/mapreduce service, or a development platform service like rails or node.  All of these services are just applications easily deployed, scaled, and connectable to existing solutions.  Of course it’s easy to understand the attraction to using these public cloud provider services, because it means no setup, no maintenance, and someone else to blame if s**t goes sideways with the given service.  However, again by accepting these services, you are also accepting a level of lock in.  By creating/adapting your solution(s) to use the load balancing, monitoring, and/or database service, you are making them less portable and thus harder/costlier for you to migrate.  I can’t blame the providers for doing this, because it makes *perfect* sense from a business perspective:

I’m providing a service that is commoditized…I can only play price wars for so long….so how can I keep my customers once that happens….services!  And what’s more, I don’t want them to easily use another cloud, so I’ll make sure my services require you to utilize my API….possibly even provide a better experience on my own OS.

Now I’m not saying you shouldn’t use these services, but you should be careful of how much of them you consume and depend on.  If you ever intend or need to migrate, you will want a solution that covers the scenario of the next cloud provider not having the same service…or the service priced at a higher rate than you can afford…or the service quality/performance not being as good.  This is where having a good service orchestration solution becomes critical, and if you don’t want to believe me…just ask folks at IBM or OASIS.  And for the record, service orchestration is not configuration management….and you can’t get their by placing a configuration management tool in the cloud.  Trying to get configuration management tools to do service orchestration is like trying to teach a child to drive a car.  Sure, it can be done pretty well in a controlled empty parking lot…on a clear day.  However, once you add unpredictable weather, pedestrians, and traffic, it gets real bad, real quick.  Why?  Because just like your typical configuration management tool, a child lacks the intelligence to react and adapt to the changing conditions in the environment.

Choose Ubuntu Server

Obviously I’m going to encourage the use of Ubuntu Server, but not just because I work for Canonical or am an Ubuntu community member, but because I actually believe it’s currently the best option around.  Canonical and Ubuntu Server community members have put countless hours and effort into ensuring Ubuntu Server runs well in the cloud, and Canonical is working extremely hard with public cloud providers to ensure our users can depend on our images and public cloud infrastructure to get the fastest, cheapest, and most efficient cloud experience possible.   There’s much more to running well in the cloud than just putting up an image and saying “go!”.   Just to name a few examples: there’s insuring all instance sizes are supported, adding in-cloud mirrors across regions and zones to ensure faster/cheaper updates, natively packaging API tools and hosting them in the archives, updating images with SRUs to avoid costly time spent updating at first boot, daily development images made available, and ensuring Juju works within the cloud to allow for service orchestration and migration to other supported public clouds.

Speaking of Juju, we’ve also invested years (not months….YEARS) into our service orchestration project, and I can promise you that no one else, right now, has anything that can come close to what it can do.  Sure, there are plenty of people talking about service orchestration…writing about service orchestration….and some might even have a prototype or beta of a service orchestration tool, but no one comes close to what we have in Juju…no one has the community engagement behind their toolset…that’s growing everyday.  I’m not saying Juju is perfect by any means, but it’s the best you’re going to find if you are really serious about doing service orchestration in the cloud or even on the metal.

Over the next 12 months, you will see Ubuntu continue to push the limits of what users can expect from their operating system when it comes to scale-out computing.  You have already seen what the power of the Ubuntu community can do with a phone and tablet….just watch what we do for the cloud.

Read more

It all sounds good in theory… Not too long ago, Mark communicated the vision for Ubuntu and Unity for 2013 as “[...] Unity in 2013 will be all about mobile – bringing Ubuntu to phones and tablets [...]” and my team is responsible for taking Unity to these hardware platforms. What you should expect to [...]

Read more

Apport-valgrind 2.9 picks up support for unpackaged [1] executables (thanks Martin Pitt for working with me to land my changes in trunk).

Digging deeper into how it works

Flow for packaged EXE

Quality of the unpackaged stack traces?

coreutils: /bin/ls

Read more

Some of you may have seen the news about us transitioning to an online Ubuntu Developer Summit and running the event every three months. If you didn’t see the news, you can read it here. I just wanted to share my personal perspective on this change.

For a long time now I have been attending Ubuntu Developer Summits as part of my work, but for the last event in Copenhagen my wife was about to give birth and so I attended the event remotely. As someone who has been heavily involved in the planning and execution of UDS for the last 10 or so events, I was intimately aware of the remote participation features of the event, but I had never actually utilized them myself. I was excited to dive into the sessions remotely and participate.

For the sessions I dialed into I found the remote participation worked well, but not as well as it could. Sometimes it was a little difficult to hear people (despite us alway encouraging speakers to sit near the middle of the fishbowl), and for the sessions I wasn’t able to actively participate in (due to the timezone differences), only some of those sessions had videos available that I could review after the session had ended. As such, this made it something of a challenge at times to get an overall view of the event; it depended on attendees taking good notes (which generally happens), but I missed the specifics of the discussions.

Remote participation has always been a critical part of UDS and I think it worked efficiently as it could, but these issues were primarily due to the challenge of delivering an in-person event to an online audience and the practicalities therein.

Of course, the real challenge is getting you people to eat these things.

The move to an online event effectively solves the majority of these issues: every single session will be recorded and available for viewing after the fact (which is awesome for not only attendees, but also for the press, partners and others), and with everyone in the hangout facing a webcam and a microphone, the quality of the content should be better too.

For those people who can’t join the session hangout video stream, IRC participation is available, and those IRC discussions will be logged too and provided in addition to the video of the session and the Etherpad notes. This provides a great overview of all the content and discussion in the session.

An online event is also going to open up the event to more potential participants. There are many folks who either can’t physically travel or justify the travel expenses or time away from their work and family commitments who can now participate in the event by simply opening their web browser. With the wide focus in Ubuntu across the desktop, devices and the cloud, we need more specialists rather than fewer to guide us on our mission, and the online event will make it easier for those folks to attend. I think that this will result in wider and more diverse discussion, ultimately helping us to do a better job planning UDS.

Some folks have expressed a concern about not having as much face-to-face time as in a physical event. Of course, video-conferencing will never ultimately replace being in the same room as someone, but I think much of that personal connection is still shared via hangouts. As an example, my team at Canonical used to have team meetings on Skype or a Conference Call and ever since we switched to Google+ Hangouts the sense of personal connection and team spirit has skyrocketed. Sure, it doesn’t replace being in the same room, but when we balance out the benefits of an online event for the reasons I mentioned earlier, it seems like a reasonable trade-off to me.

Iterative Improvements

One thing that many folks don’t see from behind the scenes of planning the physical UDSs is that we have always taken an really rigorous approach to improving and refining the event. This not only includes the structure of the event, but we have iterated after every detail to improve room layouts, A/V needs, timing, remote participation requirements, scheduling patterns, and more. Every detail of UDS has been scrutinized after every event, and the survey we send out is reviewed with a fine tooth comb, all with the goal of squeezing out as much efficiency as possible so the time everyone commits to UDS is as worthwhile as possible.

We are still exploring the alleged productivity-enhancing benefits of light ping-pong.

With UDS previously happening every six months this has helped us to build a pretty bullet proof formula for the physical event, and many attendees comment at each UDS about just how efficient it is and how much gets done. This is largely due to this iterative refinement process.

The first online UDS takes place next week and I think we have a pretty good plan for it, but we are going to go through exactly the same process for reviewing how each event goes and buffing off the rough edges so that works better and more efficiently each time. With us now doing a UDS every three months it should not take too long to get us into a winning formula, and our community are an essential part of helping us to refine these different pieces. As I mentioned in the announcement blog, after the second event we are also going to take a general look to see if an online UDS is serving the needs of the project well in terms of how we plan Ubuntu development.

Got Questions?

I am sure many of you will still have questions about the new format of UDS. Tomorrow (Wednesday) at 7pm UTC. I will be doing my usual weekly Q+A videocast on Ubuntu On Air and will dedicate part of the session to covering how the online event will work and answering your questions. Feel free to bring your UDS and any other questions to the session!

Read more

There seems to be quite a bit of buzz around Yahoo! effectively laying off remote workers (making them choose to start going to an office or resign), and I've read different perspectives on the subject, for and against remote working.
Having worked at Canonical for over 4 years, and in open source projects for quite a bit longer than that, my knee-jerk reaction is that the folks crying out that remote working just isn't as productive as working in an office is pretty short-sighted.
Canonical has hundreds of employees working remotely, far more than working in an office, and it seems like we're generally a very productive company. We take on huge competitors who have ten times the amount of people working on any given project, and we put up a pretty good fight. So I can tell you remote working is full of awesome for both the company (productivity, get to choose from a huge pool of talent) and the employee (no commute, less distractions).
I also think that the fact that open source projects are taking over the world at an incredible pace is a pretty huge testament to just how great remote working can be. This is even an extreme case where people aren't even available on a regular schedule with much tighter and clearer shared goals.

 

All that said, there are several ways things can go wrong with remote working.

Thoughtlessly mixing remote and co-located teams. All-remote and all co-located tends to work out easier. Mixing these things without having a clear plan on how communication is going to work is most likely going to end up badly. The co-located team will tend to talk to each other in the hallways and not bring the people who are remote into the loop, mostly because of the extra cost of communication there. If making decisions in person is accepted, and there are no guidelines in place to document and open up the discussion to the full audience, then it's going to fail. Regardless of remote-or-not, documenting these things is good practice, it provides traceability and there's less room for people to go away with different interpretations.

Hiring remote workers that are not generally self-directed. I can't stress this point enough. Remote working isn't for everybody, you have to make sure the people who are working remotely are generally happy making decisions on their own on a daily basis, can push through problems without a lot of hand-holding and are good at flagging problems when they see one. These types of people are great to have on site as well, but in a remote situation this is a non-negotiable skill.

Unclear goals as a team or company. If what people are suppose to be doing isn't crystal clear to everybody involved remote working is going to be very messy. Strongly self-directed people are going to push forward with what they think is the right thing to do (based off of incomplete information), and people less strongly independent are going to be reading a lot of RSS feeds.

 

I also think there are some common sense arguments against remote working that are actually an argument in favor of it.

Slackers will slack harder when at home. So, if you're at home, who's going to know if you spent your morning watching TV or thinking about a really hard problem? When you're at the office, it's much easier to check up on what you're doing with your time. I think that if you have an employee that you need to check up on what he's doing with his time, you have a problem. The answer is not going to be to put him in an office and get him to learn how to alt-tab very quickly to an IDE when you walk by. You should be working with them to make sure their performance is adequate. If it's not, and you can't seem to find a way around it, fire him. Keeping him around and force-feeding work is a huge waste of time and money. Slackers are going to slack harder at home, use that to your advantage to get rid of people who aren't up to task or don't care anymore quicker.

Communication is more expensive. It is. It also forces people to learn how to communicate better, more concisely, and in a way that's generally documented. While you can easily have calls, in the end you need to email a list or some form of communication that reaches everybody. So there's a short-term cost for a long-term benefit. You may need that short-term benefit right now, in which case you bring people together for a week or two, spend some of that money you've saved on infrastructure, and push things forward.

 

So, in general I think having remote workers forces a company to have clearer, well-communicated goals, better documentation on decisions, hiring driven and self-directed people makes you think long and hard about your processes and opens up to hiring from a much larger pool of people (all over the world!). I think those are great things to have pressuring you consistently, and will make you a better company for it.
Like everything else, if you have remote workers and pretend they are the same as co-located it's going to fail.

Read more

A few days ago we announced Ubuntu for Tablets; the next piece on our wider Ubuntu convergence story. The tablet joins the Phone, TV, Ubuntu for Android, and the Desktop. See an excellent hands-on video review of the current developer build from Engadget.

Today the source and images for Ubuntu for Phones and Tablets (collectively known as Ubuntu Touch) was released.

I know there is some anticipation regarding this release and I just wanted to share a few facts to ensure we are all on the same page:

1. Both Phone and Tablet code and images are available – today we are releasing two things for both the phone and the tablet. Firstly, if you simply want to run the software on a spare device, you can install the images on your device without caring about the code. If on the other hand you want to see the code (and contribute to it) we are also making this available too so that you can build, explore, and hack on it.
2. This is unfinished and in-development software – it is important to remember that this is in-development software and as such is not finished yet. You are going to find that some features and applications are missing, and you will likely find bugs. We wanted to release the code and images early so that our community can try the software, provide feedback, and be able to join the development effort. With this goal to get the content out early we just want to ensure everyone fully understands that this is not yet a final product. I strongly recommend you only install the code/images on a spare handset/tablet and not your main phone/tablet due to the fact it is in-development code.
3. A limited set of devices are supported – the images are only available for the Galaxy Nexus, Nexus 4, Nexus 7, and Nexus 10; these are the devices that our development team has been working towards. We appreciate that you may have a different phone or tablet, but unfortunately support for other devices is not currently planned. We will however be kicking off an outreach campaign soon to encourage and support our community in porting the code to other devices. Stay tuned for more!
4. A new SDK is available also – in addition to the release of the code and images we have also released a new version of the SDK which includes a number of new features, most usefully the ability to deploy a QML app to a device so you can run it!
   • Ubuntu SDK application templates and wizard
   • QML2 UI designer
   • Templates for testing framework and internationalization
   • Deploy QML applications on an Ubuntu Phone/Tablet device
   • Basic terminal (ssh, adb) connectivity tools to the device
5. Know where to find help – if you have questions or queries you should post your questions to Ask Ubuntu by clicking here.

I am sure you are now chomping at the bit to grab the images, check out the code, and get the new SDK release! Go and find all the details here.

Read more

Wow…I just realized how long it’s been since I did a blog post, so apologies for that first off.  FWIW, it’s not that I haven’t had any good things to say or write about, it’s just that I haven’t made the time to sit down and type them out….I need a blog thought transfer device or something .  Anyway, with all the talk about Ubuntu doing a rolling release, I’ve been thinking about how that would affect Ubuntu Server releases, and more importantly….could Ubuntu Server roll as well?  In answering this question, I think it comes down to two main points of consideration (beyond what the client flavors would already have to consider).

 

How Would This Affect Ubuntu Server Users?

We have a lot of anecdotal data and some survey evidence that most Ubuntu Server users mainly deploy the LTS.  I doubt this surprises people, given the support life for an LTS Ubuntu Server release is 5 years, versus only 18 months for a non-LTS Ubuntu Server release.  Your average sysadmin is extremely risk adverse (for good reason), and thus wants to minimize any risk to unwanted change in his/her infrastructure.  In fact, most production deployments also don’t even pull packages from the main archives, instead they mirror them internally to allow for control of exactly what and when updates and fixes roll out to internal client and/or server machines.  Using a server operating system that requires you to upgrade every 18 months, to continue getting fixes and security updates, just doesn’t work in environments where the systems are expected to support 100s to 1000s of users for multiple years, often without significant downtime. With that said, I think there are valid uses of non-LTS releases of Ubuntu Server, with most falling into two main categories: Pre-Production Test/Dev or Start-Ups, with the reasons actually being the same.  The non-LTS version is perfect for those looking to roll out products or solutions intended to be production ready in the future.  These releases provide users a mechanism to continually test out what their product/solution will eventually look like in the LTS as the versions of the software they depend upon are updated along the way.  That is, they’re not stuck having to develop against the old LTS and hope things don’t change too much in two years, or use some “feeder” OS, where there’s no guarantee the forked and backported enterprise version will behave the same or contain the same versions of the software they depend on.  In both of these scenarios, the non-LTS is used because it’s fluid, and going to a rolling release only makes this easier…and a little better, I dare say.  For one, if the release is rolling, there’s no huge release-to-release jump during your test/dev cycle, you just continue to accept updates when ready.  In my opinion, this is actually easier in terms of rolling back as well, in that you have less parts moving all at once to roll back if needed.  The second thing is that the process for getting a fix from upstream or a new feature is much less involved because there’s no SRU patch backporting, just the new release with the new stuff.  Now admittedly, this also means the possibility for new bugs and/or regressions, however given these versions (or ones built subsequently) are destined to be in the next LTS anyway, the faster the bugs are found out and sorted, the better for the user in the long term.  If your solution can’t handle the churn, you either don’t upgrade and accept the security risk, or you smoke test your solution with the new package versions in a duplicate environment.  In either case, you’re not running in production, so in theory…a bug or regression shouldn’t be the end of the world.  It’s also worth calling out that from a quality and support perspective, a rolling Ubuntu Server means Ubuntu developers and Canonical engineering staff who normally spend a lot of time doing SRUs on non-LTS Ubuntu Server releases, can now focus efforts on the Ubuntu Server LTS release….where we have a majority of users and deployments.

 

How Would This Affect Juju Users?

In terms of Juju, a move to a rolling release tremendously simplifies some things and mildly complicates others.  From the point of view of a charm author, this makes life much easier.  Instead of writing a charm to use a package in one release, then continuously duplicating and updating it to work with subsequent releases that have newer packages, you only maintain two charms…maximum of three if you want to include options for running code from upstream.  The idea is that every charm in the collection would default to using packages from the latest Ubuntu Server LTS, with options to use the packages in the rolling release, and possibly an extra option to pull and deploy direct from upstream.  We already do some of this now, but it varies from charm to charm…a rolling server policy would demand we make this mandatory for all accepted charms.  The only place where the rules would be slighlty different, are in the Ubuntu Cloud Archives, where the packages don’t roll, instead new archive pockets are created for each OpenStack release.  From a users perspective, a rolling release is good, yet is also complicated unless we help…and we will.  In terms of the good, users will know every charmed service works and only have to decide between LTS and rolling as the deployment OS, where as now, they have to choose a release, then hope the charm has been updated to support that release.  The reduction in charm-to-release complexity also allows us to do better testing of charms because we don’t have to test every charm against oneiric, precise, raring, “s”, etc, just precise and the rolling release….giving us more time to improve and deepen our test suites.

With all that said, a move to a rolling Ubuntu Server release for non-LTS also adds the danger of inconsistent package versions for a single service in a deployment.  For example, you could deploy a solution with 5 instances of wordpress 3.5.1 running, we update the archive to wordpress 3.6, then you decide to add 3 more units, thus giving you a wordpress service of mixed versions….this is bad.  So how do we solve this?  It’s actually not that hard.  First, we would need to ensure that Juju never automatically adds units to an existing service if there’s a mismatch in the version of binaries between the currently deployed instances and the new ones about to be deployed.  If Juju detected the binary inconsistency, it would need to return an error, optionally asking the user if he/she wanted it to upgrade the currently running instances to match the new binary versions.  We could also add some sort of –I-know-what-I-am-doing option to give the freedom to those users who don’t care about having version mismatches.  Secondly, we should ensure an existing deployment can always grow itself without requiring a service upgrade.   My current thinking around this is that we’d create a package caching charm, that can be deployed against any existing Juju deployment.  The idea is much like squid-deb-proxy (accept the cache never expires or renews), where the caching instance acts as the archive mirror for the other instances in the deployment, providing the same cached packages deployed in that given solution.  The package cache should be ran in a separate instance with persistent storage, so that even if the service completely goes down, it can be restored with the same packages in the cache.

 

So…Can Ubuntu Server Roll?

I honestly think we can and should consider it, but I’d also like to hear the concerns of folks who think we shouldn’t.

Read more

We are exhibiting at this year’s CeBIT event on March 5-9th, 2013 in Hannover Germany, in conjunction with our partner in the region, Teuto.net and we’re giving away number of free tickets to selected customers and partners. If you are interested in one of these tickets, please contact me at anthony.beckley@canonical.com for more information.

The Canonical/Teuto.net stand will be in the Open Source Arena (Hall 6, Stand F16, (030) and we will be showcasing two enterprise technology areas:

• The Ubuntu Cloud Stack – demonstrating end user access to applications via an OpenStack cloud, powered by Ubuntu,
• Ubuntu Landscape Systems Management – demonstrating ease of management of desktop, server and cloud nodes.

We will be running hourly demonstrations on our stand and attendees have the chance to win a Google Nexus 7 tablet! Simply come to out stand and watch a short demo or your chance to win If you would like to pre-register for a demonstration, email me at anthony.beckley@canonical.com

We look forward to seeing you at the show!

CeBIT draws a live audience of more than 3,000 people from over 100 different countries. In just five days the show delivers a panoramic view of the digital world’s mainstay markets: ICT and Telecommunications, Digital Media also Consumer Electronics.
To learn more about CeBIT click here.

Read more

Last time I discussed AppArmor, gave some background and some information on how it can be used. This time I’d like to discuss how AppArmor is used within Ubuntu. The information in this part applies to Ubuntu 12.10 and later, and unless otherwise noted, Ubuntu 12.04 LTS (and because we also push our changes into Debian, much of this will apply to Debian as well).

/etc/apparmor.d

• Ubuntu follows the upstream policy layout and naming conventions and uses the abstractions extensively. A few abstractions are Ubuntu-specific and they are prefixed with ‘ubuntu’. Eg /etc/apparmor.d/abstractions/ubuntu-browsers.
• Ubuntu encourages the use of the include files in /etc/apparmor.d/local in any shipped profiles. This allows administrators to make profile additions and apply overrides without having to change the shipped profile (will need to reload the profile with apparmor_parser, see /etc/apparmor.d/local/README for more information)
• All profiles in Ubuntu use ‘#include <tunables/global>’, which pulls in a number of tunables: ‘@{PROC}’ from ‘tunables/proc’, ‘@{HOME}’ and ‘@{HOMEDIRS}’ from ‘tunables/home’ and @{multiarch} from ‘tunables/multiarch’
• In addition to ‘tunables/home’, Ubuntu utilizes the ‘tunables/home.d/ubuntu’ file so that ‘@{HOMEDIRS}’ is preseedable at installation time, or adjustable via ‘sudo dpkg-reconfigure apparmor’
• Binary caches in /etc/apparmor.d/cache are used to speed up boot time.
• Ubuntu uses the /etc/apparmor.d/disable and /etc/apparmor.d/force-complain directories. Touching (or symlinking) a file with the same name as the profile in one of these directories will cause AppArmor to either skip policy load (eg disable/usr.sbin.rsyslogd) or load in complain mode (force-complain/usr.bin.firefox)

Boot

Policy load happens in 2 stages during boot:

1. within the job of a package with an Upstart job file
2. via the SysV initscript (/etc/init.d/apparmor)

For packages with an Upstart job and an AppArmor profile (eg, cups), the job file must load the AppArmor policy prior to execution of the confined binary. As a convenience, the /lib/init/apparmor-profile-load helper is provided to simplify Upstart integration. For packages that ship policy but do not have a job file (eg, evince), policy must be loaded sometime before application launch, which is why stage 2 is needed. Stage 2 will (re)load all policy. Binary caches are used in both stages unless it is determined that policy must be recompiled (eg, booting a new kernel).

dhclient is a corner case because it needs to have its policy loaded very early in the boot process (ie, before any interfaces are brought up). To accommodate this, the /etc/init/network-interface-security.conf upstart job file is used.

For more information on why this implementation is used, please see the upstart mailing list.

Packaging

AppArmor profiles are shipped as Debian conffiles (ie, the package manager treats them specially during upgrades). AppArmor profiles in Ubuntu should use an include directive to include a file from /etc/apparmor.d/local so that local site changes can be made without modifying the shipped profile. When a package ships an AppArmor profile, it is added to /etc/apparmor.d then individually loaded into the kernel (with caching enabled). On package removal, any symlinks/files in /etc/apparmor.d/disable, /etc/apparmor.d/force-complain and /etc/apparmor.d are cleaned up. Developers can use dh_apparmor to aid in shipping profiles with their packages.

Profiles and applications

Ubuntu ships a number of AppArmor profiles. The philosophy behind AppArmor profiles on Ubuntu is that the profile should add a meaningful security benefit while at the same time not introduce regressions in default or common functionality. Because it is all too easy for a security mechanism to be turned off completely in order to get work done, Ubuntu won’t ship overly restrictive profiles. If we can provide a meaningful security benefit with an AppArmor profile in the default install while still maintaining functionality for the vast majority of users, we may ship an enforcing profile. Unfortunately, because applications are not designed to run under confinement or are designed to do many things, it can be difficult to confine these applications while still maintaining usability. Sometimes we will ship disabled-by-default profiles so that people can opt into them if desired. Usually profiles are shipped in the package that provides the confined binary (eg, tcpdump ships its own AppArmor profile). Some in progress profiles are also offered in the apparmor-profiles package and are in complain mode by default. When filing AppArmor bugs in Ubuntu, it is best to file the bug against the application that ships the profile.

In addition to shipped profiles, some applications have AppArmor integration built in or have AppArmor confinement applied in a non-standard way.

Libvirt

An AppArmor sVirt driver is provided and enabled by default for libvirt managed QEMU virtual machines. This provides strong guest isolation and userspace host protection for virtual machines. AppArmor profiles are dynamically generated in /etc/apparmor.d/libvirt and usually you won’t have to worry about AppArmor confinement. If needed, profiles for the individual machines can be adjusted in /etc/apparmor.d/libvirt/libvirt-<uuid> or in all virtual machines in /etc/apparmor.d/abstractions/libvirt-qemu. See /usr/share/doc/libvirt-bin/README.Debian.gz for details.

LXC

LXC in Ubuntu uses AppArmor to help make sure files in the container cannot access security-sensitive files on the host. lxc-start is confined by its own restricted profile which allows mounting in the container’s tree and, just before executing the container’s init, transitioning to the container’s own profile. See LXC in precise and beyond for details. Note, currently the libvirt-lxc sVirt driver does not have AppArmor support (confusingly, libvirt-lxc is a different project than LXC, but there are longer term plans to integrate the two and/or add AppArmor support to libvirt-lxc).

Firefox

Ubuntu ships a disabled-by-default profile for Firefox. While it is known to work well in the default Ubuntu installation, Firefox, like all browsers, is a very complex piece of software that can do much more than simply surf web pages so enabling the profile in the default install could affect the overall usability of Firefox in Ubuntu. The goals of the profile are to provide a good usability experience with strong additional protection. The profile allows for the use of plugins and extensions, various helper applications, and access to files in the user’s HOME directory, removable media and network filesystems. The profile prevents execution of arbitrary code, malware, reading and writing to sensitive files such as ssh and gpg keys, and writing to files in the user’s default PATH. It also prevents reading of system and kernel files. All of this provides a level of protection exceeding that of normal UNIX permissions. Additionally, the profile’s use of includes allows for great flexibility for tightly confining firefox. /etc/apparmor.d/usr.bin.firefox is a very restricted profile, but includes both /etc/apparmor.d/local/usr.bin.firefox and /etc/apparmor.d/abstractions/ubuntu-browsers.d/firefox. /etc/apparmor.d/abstractions/ubuntu-browsers.d/firefox contains other include files for tasks such as multimedia, productivity, etc and the file can be manipulated via the aa-update-browser command to add or remove functionality as needed.

Chromium

A complain-mode profile for chromium-browser is available in the apparmor-profiles package. It uses the same methodology as the Firefox profile (see above) with a strict base profile including /etc/apparmor.d/abstractions/ubuntu-browsers.d/chromium-browser whichcan then include any number of additional abstractions (also configurable via aa-update-browser).

Lightdm guest session

The guest session in Ubuntu is protected via AppArmor. When selecting the guest session, Lightdm will transition to a restrictive profile that disallows access to others’ files.

libapache2-mod-apparmor

The libapache2-mod-apparmor package ships a disabled-by-default profile in /etc/apparmor.d/usr.lib.apache2.mpm-prefork.apache2. This profile provides a permissive profile for Apache itself but allows the administrator to add confinement policy for individual web applications as desired via AppArmor’s change_hat() mechanism (note, apache2-mpm-prefork must be used) and an example profile for phpsysinfo is provided in the apparmor-profiles package. For more information on how to use AppArmor with Apache, please see /etc/apparmor.d/usr.lib.apache2.mpm-prefork.apache2 as well as the upstream documentation.

PAM

AppArmor also has a PAM module which allows great flexibility in setting up policies for different users. The idea behind pam_apparmor is simple: when someone uses a confined binary (such as login, su, sshd, etc), that binary will transition to an AppArmor role via PAM. Eg, if ‘su’ is configured for use with pam_apparmor, when a user invokes ‘su’, PAM is consulted and when the PAM session is started, pam_apparmor will change_hat() to a hat that matches the username, the primary group, or the DEFAULT hat (configurable). These hats (typically) provide rudimentary policy which declares the transition to a role profile when the user’s shell is started. The upstream documentation has an example of how to put this all together for ‘su’, unconfined admin users, a tightly confined user, and somewhat confined default users.

aa-notify

aa-notify is a very simple program that can alert you when there are denials on the system. aa-notify will report any new AppArmor denials by consulting /var/log/kern.log (or /var/log/audit/audit.log if auditd is installed). For desktop users who install apparmor-notify, aa-notify is started on session start via /etc/X11/Xsession.d/90apparmor-notify and will watch the logs for any new denials and report them via notify-osd. Server users can add something like ‘/usr/bin/aa-notify -s 1 -v’ to their shell startup files (eg, ~/.profile) to show any AppArmor denials within the last day whenever they login. See ‘man 8 aa-notify’ for details.

Current limitations

For all AppArmor can currently do and all the places it is used in Ubuntu, there are limitations in AppArmor 2.8 and lower (ie, what is in Ubuntu and other distributions). Right now, it is great for servers, network daemons and tools/utilities that process untrusted input. While it can provide a security benefit to client applications, there are currently a number of gaps in this area:

• Access to the DBus system bus is on/off and there is no mediation of the session bus or any other buses that rely on Unix abstract sockets, such as the accessibility bus
• AppArmor does not provide environment filtering beyond having the ability to clear the very limited set of glibc secure-exec variables
• Display management mediation is not present (eg, it doesn’t protect against X snooping)
• Networking mediation is too coarse-grained (eg you can allow ‘tcp’ but cannot restrict the binding port, integrate with a firewall or utilize secmark)
• LXC/containers support is functional, but not complete (eg, it doesn’t allow different host and container policy for the same binary at the same time)
• AppArmor doesn’t currently integrate with other client technologies that might be useful (eg gnome-keyring, signon/gnome-online-accounts and gsettings) and there is no facility to dynamically update a profile via a user prompt like a file/open dialog

Next time I’ll discuss ongoing and future work to address these limitations.

Filed under: canonical, security, ubuntu

Read more

Will the real debug package please stand up

While mucking around with stack traces, valgrind, and apport-valgrind, I stumbled across two types of debug symbol [1] packages:
Being rather new to this area, I was not sure which to use. But, I wanted to valgrind empathy, so I looked further.

The package Description fields [2] shed no light on which to use:

empathy-dbg:

Description-en: GNOME multi-protocol chat and call client (debug symbols) Instant messaging program supporting text, voice, video, file transfers and inter-application communication over many different protocols, including: AIM, MSN, Google Talk (Jabber/XMPP), Facebook, Yahoo!, Salut, Gadu-Gadu, Groupwise, ICQ and QQ. This package contains the Empathy IM application and account manager.

empathy-dbgsym:

Description: debug symbols for package empathy Instant messaging program supporting text, voice, video, file transfers and inter-application communication over many different protocols, including: AIM, MSN, Google Talk (Jabber/XMPP), Facebook, Yahoo!, Salut, Gadu-Gadu, Groupwise, ICQ and QQ. This package contains the Empathy IM application and account manager.

Turning to the internet, I found many others had asked the same question, and they usually got answers like this:

You can use either the -dbg or the -dbgsym packages, but you can't use both.

Still, no guidance as to which to use. And anyway, I wanted to understand what was going on at a deeper level. Investigating further, I found that dbg packages are hosted in the standard archive (archive.ubuntu.com), whereas dbgsym packages are hosted in a special archive: ddebs.ubuntu.com.

It also turns out that the dbgsym packages on ddebs.ubuntu.com com do not appear to be strictly normal debian packages:

• Normal debian packages end in ".deb" (for example: empathy-dbg_3.6.0.3-0ubuntu1_amd64.deb)
• The packages on ddebs.ubuntu.com end in ".ddeb" (empathy-dbgsym_3.6.3-0ubuntu2_amd64.ddeb)

This ".ddeb" extension reminded me of ".udeb" packages, which I have encountered in the context of live-build installations. Are these dbgsym/ddeb packages also intended for some narrowly defined use case?

This warranted further poking around. Here are my findings.

dbg packages

dbg packages are the traditional debian method for providing debug symbols separately from the normally installed binary packages.

dbg packages are created by upstream packagers and flow naturally into the standard Ubuntu archives. They are normal debian packages (that end in ".deb").

There is usually only one binary dbg package per source package. That is, there are usually not separate dbg packages for individual binary packages, there's just one named after the source package, like empathy-dbg.

They are pretty easy to make these days. The normal way is described here.

So, thanks to a lot of upstream work, the Ubuntu standard archive already has lots of these dbg packages. You can see a list of them with something like this:

$ apt-cache search dbg | less

These dbg packages work as expected: if you install, for example, empathy-dbg, and then generate an empathy stack trace (with valgrind or gdb, for example):

• The symbols it contains should be converted to useful function names (instead of being question marks)
• The source file names should be displayed (instead of paths to shared object (.so) and other binary files)

So let's take a moment to appreciate the work upstream maintainers have done!


But, not every package in Ubuntu has a dbg package. And, even those that do may have created them in different ways, and possibly with different naming conventions, which makes them difficult (or impossible) to find mechanistically.

This is where dbgsym packages come in.

dbgsym packages

Consider the Ubuntu archive: thousands of binary packages (more than 7000 in the Ubuntu 12.10 Quantal main archive component alone).

That's a lot of different people in teams maintaining a lot of packages.

Inevitably, some packages that arguably should provide binary debug symbol packages do not. Or they do, but in a slightly different way, for example, the package name may not follow the standard pattern.

This wonderful diversity adds up to a concrete problem: the complete set of debug symbols required for debugging and creating useful stack traces of any arbitrary packaged C executable (ELF file) are not reliably present in standard Ubuntu archives.

Suppose I need to check something for memory leaks using apport-valgrind or debug it with gdb and I hit one of these missing bits?

Automation \o/

Fortunately, there is a systematic (and automatic) solution (which is almost fully working).

The idea is to automate the generation of debug symbols at package build time (whether or not the package maintainers took steps to create dbg packages). For each binary package that installs an executable for which symbols may be helpful, automatically create a new BINARYPACKAGE-dbgysm package, and let it install the appropriate set of debug symbol binaries. Make it conflict with the dbg package to avoid file collisions. Then, publish them in ddebs.ubuntu.com.

That's two steps:

1. Creating the dbgsym binary packages (this part seems to be fully implemented)
2. Publishing them to ddebs.ubuntu.com (this part may not be fully implemented)

Binary package oriented

The dbgsym approach has a finer granularity than the usual dbg approach: it is binary package oriented. That is, a dbgysm package is created for each appropriate binary package (each that installs an ELF), whereas with the traditional, manual dbg approach, there is usually one dbg package created for all binary packages.

So there are often many dbgsym packages per source package with this approach, which results in many more dbgsym packages than dbg packages, a good thing: you only need to download and install the parts you want.

Conflicts - a closer look

These automatically generated binary dbgsym packages install some of the same files [3] as the corresponding dbg package, by design. But, without additional packaging steps, this would amount to a packaging error (since no single file may be installed by two binary packages without special steps to resolve this collision).

This is automatically handled by setting the dbgsym package to conflict with the dbg package(s). (Conflicting packages cannot both be fully installed at the same time.) This explains why I found so many statements saying that "dbg and dbgsym packages cannot both be installed at the same time." It is literally not possible due to these intentional conflicts settings.

How dbgsym packages are created

dbgsym packages are automatically created during a normal source package binary build by the pkg-create-dbgsym package, if it is installed. That is, if you install pkg-create-dbgsym, whenever a debian source package is built (for example with debuild in the source tree), pkg-create-dbgsym scripts create the dbgysm binary packages and set them to conflict as appropriate. (Thanks to Martin Pitt and other debian developers.) These steps are in addition to the normal activities of a build, so you also generate non-debug binary packages.

For example, after installing pkg-create-dbgsym, I built the empathy source package, and here are the binary packages that were created [4]. Lots of dbgsym ddebs!

ddeb: Huh? What?

These dbgsym binary package files end in ".ddeb", not ".deb", so what's up with that?

As far as I can tell, this is merely a convenience for archive maintenance. That is: a .ddeb is exactly the same as a .deb, except that its extension is different. This serves the purpose of allowing archive management tools to find ddeb binary packages and treat them differently, in this case:

• Posting them on ddebs.ubuntu.com 
• Not posting them on archive.ubuntu.com

Enough already: which to use?

So, after this exploration, I vote for dbgsym packages over dbg packages for the following reasons

• The trend is towards automatic generation of dbgsym packages and automatic posting of them to separate ddebs archive like http://ddebs.ubuntu.com
• Such ddeb archives should contain more debug symbol packages than the traditional dbg packages because they are automatically created for all appropriate packages (instead of relying on maintainers to add a dbg package) so you get more
• Such ddeb archives certainly should contain equivalents for the existing dbg packages as well, so you lose nothing
• If you want, you can just get the debug symbols you need, since dbgsym packages are more granular 

This all means that if you use dbgsym packages, your stack traces and debugging experiences are more likely to provide you the data you need to get your work done, with less bloat.

Also, manually created dbg packages may disappear over time. Why? No need for package maintainers to think about debug packages. And the normal archives get smaller as debug symbol packages disappear.

Using dbgsym

As noted, the dbgsym packages are published on ddebs.ubuntu.com. Ubuntu systems do not know this archive by default.

You can easily add it to your "software sources". For example, the following line adds ddebs.ubuntu.com for Quantal, main to your /etc/apt/sources.list file:

deb http://ddebs.ubuntu.com quantal main

Then run sudo apt-get update, and you should be all set to go.

For example, check whether empathy-dbgsym is available for installation:

$ apt-cache policy empathy-dbgsym
empathy-dbgsym:
  Installed: 3.6.0.3-0ubuntu1
  Candidate: 3.6.0.3-0ubuntu1
  Version table:
 *** 3.6.0.3-0ubuntu1 0
        500 http://ddebs.ubuntu.com/ quantal/main amd64 Packages
        500 http://ddebs.ubuntu.com/ quantal/main amd64 Packages
        100 /var/lib/dpkg/status

There it is! (I happen to have this one installed.)

How about the dbgsym version of empathy's binary package account-plugin-aim?

$ apt-cache policy account-plugin-aim-dbgsym
account-plugin-aim-dbgsym:
  Installed: (none)
  Candidate: 3.6.0.3-0ubuntu1
  Version table:
     3.6.0.3-0ubuntu1 0
        500 http://ddebs.ubuntu.com/ quantal/main amd64 Packages

There it is!

A caveat

It appears that not all dbgsym binary packages that one might expect are actually present on ddebs.ubuntu.com.

For example, when I built empathy on a Quantal amd64 system with pgk-create-dbgsym installed, the expected dbgsym binary packages were created, including, for example, one for the account-plugin-irc binary package, and here it is:

account-plugin-irc-dbgsym_3.6.0.3-0ubuntu1_amd64.ddeb

But, I don't see a dbgsym package for account-plugin-irc published in the Ubuntu ddebs quantal main archive. The same is true for some (but by no means all) other binary packages deriving from empathy, like account-plugin-icq-dbgsym

This would seem to be a hiccup in the publishing part of the automation, not the dbgsym generation part.

Footnotes

[1] Debug symbols fill in stack traces to make them more human readable by substituting C function names and C source code file name for question marks and library file names. See apport-valgrind for details.

[2] You can display a package Description for any package your system's apt knows about with apt-cache show PACKAGE, and look for the Description field.

[3] Conflicting with the dbg package(s), an example using account-plugin-aim as an example:

The empathy source package has the accounts-plugin-aim binary package. It installs the following file: /usr/lib/libaccount-plugin-1.0/providers/libaim.so (as shown by dpkg -S  /usr/lib/libaccount-plugin-1.0/providers/libaim.so).

The empathy-dbg package installs a debug symbol version of this file in a debug directory: /usr/lib/debug/usr/lib/libaccount-plugin-1.0/providers/libaim.so. There is no conflict yet, since the paths are different.

The automatically generated dbgsym packages for empathy include account-plugin-aim-dbgsym. This package installs the same debug .so file as we saw for the empathy-dbg package:  /usr/lib/debug/usr/lib/libaccount-plugin-1.0/providers/libaim.so.

That's a conflict. Two packages (empathy-dbg and account-plugin-aim-dbgsym) install the same file.

This is expected and handled by making the dbgysm binary packages conflict with the dbg package (if any), which it does:

$ apt-cache show account-plugin-aim-dbgsym | grep Conflicts
Conflicts: empathy-dbg 

[4] With pkg-create-dbgsym installed, building empathy creates all these debs and dbgsym/ddebs:

account-plugin-zephyr_3.6.0.3-0ubuntu1_amd64.deb
account-plugin-yahoojp_3.6.0.3-0ubuntu1_amd64.deb
account-plugin-yahoo_3.6.0.3-0ubuntu1_amd64.deb
account-plugin-sip_3.6.0.3-0ubuntu1_amd64.deb
account-plugin-sametime_3.6.0.3-0ubuntu1_amd64.deb
account-plugin-salut_3.6.0.3-0ubuntu1_amd64.deb
account-plugin-myspace_3.6.0.3-0ubuntu1_amd64.deb
account-plugin-mxit_3.6.0.3-0ubuntu1_amd64.deb
account-plugin-jabber_3.6.0.3-0ubuntu1_amd64.deb
account-plugin-irc_3.6.0.3-0ubuntu1_amd64.deb
account-plugin-icq_3.6.0.3-0ubuntu1_amd64.deb
account-plugin-groupwise_3.6.0.3-0ubuntu1_amd64.deb
account-plugin-gadugadu_3.6.0.3-0ubuntu1_amd64.deb
account-plugin-aim_3.6.0.3-0ubuntu1_amd64.deb
mcp-account-manager-uoa_3.6.0.3-0ubuntu1_amd64.deb
mcp-account-manager-goa_3.6.0.3-0ubuntu1_amd64.deb
nautilus-sendto-empathy_3.6.0.3-0ubuntu1_amd64.deb
empathy-dbg_3.6.0.3-0ubuntu1_amd64.deb
empathy_3.6.0.3-0ubuntu1_amd64.deb
account-plugin-zephyr-dbgsym_3.6.0.3-0ubuntu1_amd64.ddeb
account-plugin-yahoojp-dbgsym_3.6.0.3-0ubuntu1_amd64.ddeb
account-plugin-yahoo-dbgsym_3.6.0.3-0ubuntu1_amd64.ddeb
account-plugin-sip-dbgsym_3.6.0.3-0ubuntu1_amd64.ddeb
account-plugin-sametime-dbgsym_3.6.0.3-0ubuntu1_amd64.ddeb
account-plugin-salut-dbgsym_3.6.0.3-0ubuntu1_amd64.ddeb
account-plugin-myspace-dbgsym_3.6.0.3-0ubuntu1_amd64.ddeb
account-plugin-mxit-dbgsym_3.6.0.3-0ubuntu1_amd64.ddeb
account-plugin-jabber-dbgsym_3.6.0.3-0ubuntu1_amd64.ddeb
account-plugin-irc-dbgsym_3.6.0.3-0ubuntu1_amd64.ddeb
account-plugin-icq-dbgsym_3.6.0.3-0ubuntu1_amd64.ddeb
account-plugin-groupwise-dbgsym_3.6.0.3-0ubuntu1_amd64.ddeb
account-plugin-gadugadu-dbgsym_3.6.0.3-0ubuntu1_amd64.ddeb
account-plugin-aim-dbgsym_3.6.0.3-0ubuntu1_amd64.ddeb
mcp-account-manager-uoa-dbgsym_3.6.0.3-0ubuntu1_amd64.ddeb
mcp-account-manager-goa-dbgsym_3.6.0.3-0ubuntu1_amd64.ddeb
nautilus-sendto-empathy-dbgsym_3.6.0.3-0ubuntu1_amd64.ddeb
empathy-dbgsym_3.6.0.3-0ubuntu1_amd64.ddeb
empathy-common_3.6.0.3-0ubuntu1_all.deb

Read more

Earlier we announced[1] that Canonical had worked this cycle to enable more frequent releases to the Ubuntu Cloud Images stable and long term releases. As of today, we are pleased to announce that Ubuntu Server 10.04 LTS, 11.10, 12.04 LTS and 12.10 are now fully enabled to follow the kernel SRU schedule with automated update releases. This means that within 24 hours of most SRU kernel releases, a new Ubuntu Cloud Image will be published.

Please note: with this change, the release notes have been moved the http://cloud-images.ubuntu.com/releases website. You can find them under <SUITE>/release/unpacked/release-notes.txt. Effective today, all emails announcing these new updates are discontinued. 

However, at this time, 12.04 LTS and 12.10 Cloud Images are not yet being promoted automatically to Windows Azure. We expect that as Windows Azure moves closer to General Availability (i.e. moves out of preview status) that automatic promotion will be enabled.

Please use either Cloud-Images[2], the AMI Finder[3], the RSS feed[4], or "ubuntu-cloudimg-query" from the Cloud-Utils packages to find the latest released images.

[1] http://blog.utlemming.org/2013/01/ubuntu-cloud-images-automated-release.html
     https://lists.ubuntu.com/archives/ubuntu-cloud-announce/2013-January/000045.html
     https://lists.ubuntu.com/archives/ubuntu-cloud/2013-January/000879.html
     https://groups.google.com/forum/?fromgroups=#!topic/ec2ubuntu/Mg-qpfguE10
[2] http://cloud-images.ubuntu.com/releases
[3] http://cloud-images.ubuntu.com/locator/ec2/
[4] http://cloud-images.ubuntu.com/rss/

Read more

Who doesn't love a good fruit salad?

• Find the tree of packages that nm-applet needs to run (that is, the package that owns nm-applet and that package's direct and indirect dependencies)
• Find the available debug symbol packages for them and make their debug symbol files available in a temporary directory (in /tmp, unless you specify otherwise) called the 'sandbox'
• The debug symbols packages are not installed, but extracted into the sandbox directory
• The sandbox directory is deleted after use (again, unless you specified your own sandbox directory) 

Apport and valgrind: two peas in a pod

Read more

Appy polly loggies for the super long delay between episodes, but I finally carved out some time for our exciting dénouement in the memory leak detection series. Past episodes included detection and analysis.

As a gentle reminder, during analysis, we saw the following block of code:

 874                 GSList *dupes = NULL;
 875                 const char *path;
 876 
 877                 dupes = g_object_get_data (G_OBJECT (dup_data.found), "dupes");
 878                 path = nm_object_get_path (NM_OBJECT (ap));
 879                 dupes = g_slist_prepend (dupes, g_strdup (path));
 880 #endif
 881                 return NULL;

And we concluded with:

Is it safe to just return NULL without doing anything to dupes? maybe that’s our leak?
We can definitively say that it is not safe to return NULL without doing anything to dupes. We definitely allocated memory, stuck it into dupes, and then threw dupes away. This is our smoking gun.

But there’s a twist! Eagle-eyed reader Dave Jackson (a former colleague of mine from HP, natch) spotted a second leak! It turns out that line 879 was exceptionally leaky during its inception. As Dave points out, the call to g_slist_prepend() passes g_strdup() as an argument. And as the documentation says:

Duplicates a string. If str is NULL it returns NULL. The returned string should be freed with g_free() when no longer needed.

In memory-managed languages like python, the above idiom of passing a function as an argument to another function is quite common. However, one needs to be more careful about doing so in C and C++, taking great care to observe if your function-as-argument allocates memory and returns it. There is no mechanism in the language itself to automatically free memory in the above situation, and thus the call to g_strdup() seems like it also leaks memory. Yowza!

So, what to do about it?

The basic goal here is that we don’t want to throw dupes away. We need to actually do something with it. Here again are the 3 most pertinent lines.

 877                 dupes = g_object_get_data (G_OBJECT (dup_data.found), "dupes");
 878                 path = nm_object_get_path (NM_OBJECT (ap));
 879                 dupes = g_slist_prepend (dupes, g_strdup (path));
 881                 return NULL;

Let’s break these lines down.

1. On line 877, we retrieve the dupes list from the dup_data.found object
2. Line 878 gets a path to the duplicate wifi access point
3. Finally, line 879 adds the duplicate access point to the old dupes list
4. Line 881 throws it all away!

To me, the obvious thing to do is to change the code between lines 879 and 881, so that after we modify the duplicates list, we save it back into the dup_data object. That way, the next time around, the list stored inside of dup_data will have our updated list. Makes sense, right?

As long as you agree with me conceptually (and I hope you do), I’m going to take a quick shortcut and show you the end result of how to store the new list back into the dup_data object. The reason for the shortcut is that we are now deep in the details of how to program using the glib API, and like many powerful APIs, the key is to know which functions are necessary to accomplish your goal. Since this is a memory leak tutorial and not a glib API tutorial, just trust me that the patch hunk will properly store the dupes list back into the dup_data object. And if it’s confusing, as always, read the documentation for g_object_steal_data and g_object_set_data_full.

@@ -706,14 +706,15 @@
 +		GSList *dupes = NULL;
 +		const char *path;
 +
-+		dupes = g_object_get_data (G_OBJECT (dup_data.found), "dupes");
++		dupes = g_object_steal_data (G_OBJECT (dup_data.found), "dupes");
 +		path = nm_object_get_path (NM_OBJECT (ap));
 +		dupes = g_slist_prepend (dupes, g_strdup (path));
++		g_object_set_data_full (G_OBJECT (dup_data.found), "dupes", (gpointer) dupes, (GDestroyNotify) clear_dupes_list);
 +#endif
  		return NULL;
  	}

If the above patch format looks funny to you, it’s because we are changing a patch.

-+		dupes = g_object_get_data (G_OBJECT (dup_data.found), "dupes");
++		dupes = g_object_steal_data (G_OBJECT (dup_data.found), "dupes");

This means the old patch had the line calling g_object_get_data() and the refreshed patch now calls g_object_steal_data() instead. Likewise…

++		g_object_set_data_full (G_OBJECT (dup_data.found), "dupes", (gpointer) dupes, (GDestroyNotify) clear_dupes_list);

The above call to g_object_set_data_full is a brand new line in the new and improved patch.

Totally clear, right? Don’t worry, the more sitting and contemplating of the above you do, the fuller and more awesomer your neckbeard grows. Don’t forget to check it every once in a while for small woodland creatures who may have taken up residence there.

And thus concludes our series on how to detect, analyze, and fix memory leaks. All good? Good.

waiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiit!!!!!!!11!

I can hear the observant readers out there already frantically scratching their necks and getting ready to point out the mistake I made. After all, our newly refreshed patch still contains this line:

 +		dupes = g_slist_prepend (dupes, g_strdup (path));

And as we determined earlier, that’s our incepted memory leak, right? RIGHT!??

Not so fast. Take a look at the new line in our updated patch:

++		g_object_set_data_full (G_OBJECT (dup_data.found), "dupes", (gpointer) dupes, (GDestroyNotify) clear_dupes_list);

See that? The last argument to g_object_set_data_full() looks quite interesting indeed. It is in fact, a cleanup function named clear_dupes_list(), which according to the documentation, will be called

when the association is destroyed, either by setting it to a different value or when the object is destroyed.

In other words, when we are ready to get rid of the dup_data.found object, as part of cleaning up that object, we’ll call the clear_dupes_list() function. And what does clear_dupes_list() do, praytell? Why, let me show you!

static void
clear_dupes_list (GSList *list)
{
	g_slist_foreach (list, (GFunc) g_free, NULL);
	g_slist_free (list);
}

Trés interesante! You can see that we iterate across the dupes list, and call g_free on each of the strings we did a g_strdup() on before. So there wasn’t an inception leak after all. Tricky tricky.

A quick digression is warranted here. Contrary to popular belief, it is possible to write object oriented code in plain old C, with inheritance, method overrides, and even some level of “automatic” memory management. You don’t need to use C++ or python or whatever the web programmers are using these days. It’s just that in C, you build the OO features you want yourself, using primitives such as structs and function pointers and smart interface design.

Notice above we have specified that whenever the dup_data object is destroyed, it will free the memory that was stuffed into it. Yes, we had to specify the cleanup function manually, but we are thinking of our data structures in terms of objects.

In fact, the fancy features of many dynamic languages are implemented just this way, with the language keeping track of your objects for you, allocating them when you need, and freeing them when you’re done with them.

Because at the end of the day, it is decidedly not turtles all the way down to the CPU. When you touch memory in in python or ruby or javascript, I guarantee that something is doing the bookkeeping on your memory, and since CPUs only understand assembly language, and C is really just pretty assembly, you now have a decent idea of how those fancy languages actually manage memory on your behalf.

And finally now that you’ve seen just how tedious and verbose it is to track all this memory, it should no longer be a surprise to you that most fancy languages are slower than C. Paperwork. It’s always paperwork.

And here we come to the upshot, which is, tracking down memory leaks can be slow and time consuming and trickier than first imagined (sorry for the early head fake). But with the judicious application of science and taking good field notes, it’s ultimately just like putting a delicious pork butt in the slow cooker for 24 hours. Worth the wait, worth the effort, and it has a delicious smoky sweet payoff.

Happy hunting!

Read more

I’ve been playing around with LXC over the past few weeks and one of the things I tried out was limiting the memory that the container is allowed to use. I didn’t plan on explaining all the ins-and-outs of LXC here, but a short description is that LXC provides a virtualizedish environment that is more than a chroot gives you, but less than a full-blown virtual machine. If you want more details, please check out stgraber’s blog post about LXC in 12.04.

Kernel Configuration

The first thing you need to do in order to limit memory usage for LXC is make sure your kernel is properly configured, you need the following flag enabled:

CONFIG_CGROUP_MEM_RES_CTLR=y

If you plan on also limiting swap space usage, you’ll also need:

CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y

These flags are enabled for me in my 12.10 kernel (3.5.0-22) and so presumably you’ll have them in 12.04.

Setting the Cap

First, I’m going to create my container. Following the instructions from stgraber’s blog post, and calling the container “memlimit”:

sudo lxc-create -t ubuntu -n memlimit

Once the container is built, we need to modify the config files. Look at /var/lib/lxc/memlimit/config. We need to add a few lines to that file. I’m going to limit memory to 512M and total usage or memory + swap to 1G. Note the second setting is for overall memory + swap, not just swap usage.

lxc.cgroup.memory.limit_in_bytes = 512M
lxc.cgroup.memory.memsw.limit_in_bytes = 1G

Now let’s start the container and get some debug info out of it to make sure these were set:

sudo lxc-start -n memlimit -l debug -o debug.out

The debug.out file will show up wherever you ran lxc-start from, so let’s see if it picked up our limits:

lxc-start 1359136997.617 DEBUG lxc_conf - cgroup 'memory.limit_in_bytes' set to '512M'
...
lxc-start 1359136997.617 DEBUG lxc_conf - cgroup 'memory.memsw.limit_in_bytes' set to '1G'

Looks good to me!

Note, I tried setting this once to 1.5G and it seems that the fields are only happy with whole numbers, it complained about 1.5G. That error message appeared in the same debug log I used above.

A list of more of the values you can set in here is available here.

Measuring Memory Usage

The view of /proc/meminfo inside the container and outside the container are the same. This means that you cannot rely on tools like top to show how much memory the container is using. In other words, when run inside the container top will correctly only show processes inside the container, it will also show overall memory usage for the entire system. To get valid information, instead we need to examine some files in /sys:

Current memory usage:
/sys/fs/cgroup/memory/lxc/memlimit/memory.usage_in_bytes

Current memory + swap usage:
/sys/fs/cgroup/memory/lxc/memlimit/memory.memsw.usage_in_bytes

Maximum memory usage:
/sys/fs/cgroup/memory/lxc/memlimit/memory.max_usage_in_bytes

Maximum memory + swap usage:
/sys/fs/cgroup/memory/lxc/memlimit/memory.memsw.max_usage_in_bytes

You can use expr to show it as kb or mb which is easier to read for me:

expr `cat memory.max_usage_in_bytes` / 1024
8188

What Happens When the Limit is Reached?

When the cap is reached, the container simply behaves as if the system ran out of memory. Calls to malloc will start failing (returning -1), leading to strange and bad things happening. Dialog boxes may not open, you may not be able to save files, and more than likely where people didn’t bother to check the returned value from malloc (aka, everyone), you’ll get segfaults. You can alleviate the pressure like normal systems do, by enabling swap inside the container, but once that limit is reached, you’ll have the same problem. In this case the host system’s kernel should start firing up the OOM killer and killing stuff inside the container.

Here is my extremely simple test program to drive up memory usage, install gcc in your container and you can try it too:

#include 
#include 

int main(void) {
    int i;
    for (i=0; i<65536; i++) {
        char *q = malloc(65536);
        printf ("Malloced: %ld\n", 65536*i);
    }
    sleep(9999999);
}

You can simply compiled with: gcc -o foo foo.c

I used the following simple shell construct to watch the memory usage. This needs to be run outside the container and I ran it from the /sys directory mentioned above:

while true; do echo -n "Mem Usage (mb): " \&\& expr `cat memory.usage_in_bytes` / 1024 / 1024; echo -n "Mem+swap Usage (mb): " \&\& expr `cat memory.memsw.usage_in_bytes` / 1024 / 1024; sleep 1; done

With the above shell script runnint, I fired up a bunch of copies of foo one bye one. Here’s the memory usage from that script:

Running a few copies:

Mem+swap Usage (mb): 825
Mem Usage (mb): 511
Mem+swap Usage (mb): 859
Mem Usage (mb): 511

A new copy of foo is starting:

Mem+swap Usage (mb): 899
Mem Usage (mb): 511
Mem+swap Usage (mb): 932
Mem Usage (mb): 511
Mem+swap Usage (mb): 1010
Mem Usage (mb): 511

The OOM killer just said “Nope!”

Mem+swap Usage (mb): 814
Mem Usage (mb): 511
Mem+swap Usage (mb): 825
Mem Usage (mb): 511

At the point where the OOM killer fired up, I see this in my container:
[1] Killed ./foo

So the limits are set, and they’re working.

Conclusion

If you are using LXC or considering using LXC, you can use a memory limit to protect the host from a container run amok. You could also use it to test your code in an artificially restricted environment. In either case, try the tools above and let me know how it works for you.

Read more

Traditionally, updates for the stable release and long term stable release Cloud Images have been on an ad-hoc basis; reasons for releasing new images were generally restricted to security, critical bugs, and stale images. This ad-hoc update cycle meant that updated images were only released every three months or so, and for older releases, as often as six months.

While quality has always been a concern and top priority, during this cycle, Canonical has worked to vastly improve the QA infrastructure to support our Cloud Images. For example, when a new kernel is released, the daily build for that image is now put through the complete QA process. This change in process has allowed us to identify and automatically evaluate whether or not an image is a good candidate for update release.


As such, we are pleased to announce in the next few weeks, we will be turning on automated updates for Ubuntu Server 10.04 LTS, 11.10, 12.04 LTS, and 12.10. This means that approximately every three to four weeks, a new, freshened image will be released. The release cadence will follow the kernel SRU process.

The first updated image to be released under this process was 10.04 LTS[1].

There are a variety of ways to find the released Cloud Images. The two easiest ways are to go the AMI Finder[2] or use http://cloud-images.ubuntu.com/releases/<SUITE>/release. For example, http://cloud-images.ubuntu.com/releases/lucid/release would bring you to the last AMI's for Ubuntu Server 10.04 LTS.

Due to this change, we will discontinuing the email notifications of updated images to the various email lists for updated images. At UDS-R in Copenhagen[3], we discussed email notifications and the decision was reached to discontinue them. Replacing email notification is the RSS feed[4] and release notes (example from 10.04 LTS)[5].

As Cloud Image suites are migrated to automated releases, we will follow up on this announcement.

Finally, for 12.04 LTS and later, this change will introduce lock-step update releases with Windows Azure. As Windows Azure moves towards GA, we have been working to have the same releases for the Ubuntu Server Cloud Images on both EC2 and Windows Azure.

As always, your feedback is most appreciated. Please feel free to follow on either this post or to email concerns direct to me.

[1] http://cloud-images.ubuntu.com/releases/lucid/release-20130124/
[2] http://cloud-images.ubuntu.com/locator/ec2/
[3] http://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-cloudtesting
[4] http://cloud-images.ubuntu.com/rss/
[5] http://cloud-images.ubuntu.com/releases/lucid/release-20130124/unpacked/release_notes.txt

Read more

We are pleased to announce the availability of beta Vagrant Cloud Images. These images have been customized to work with the Vagrant development environment, and are based on the Ubuntu Cloud Images. As such, these are vanilla images. They do, however, have the Virtualboxguest additions found in the Universe archive (required for Vagrant integration). 

For those who use Vagrant, your feedback is essential. Please feel free to send feedback via the ubuntu-cloud@lists.ubuntu.com mailing list.

The images are approximately 256M in size, and are configured for 512MB of RAM. They use a custom cloud-init user-data to drive the first boot. And of course, they have the vagrant user with vagrant insecure SSH key pre-installed. During the beta period, we will not be promoting any of the Vagrant boxes with the regular releases of the Ubuntu Cloud Images and will only publish the daily image builds; after the beta period these images will be promoted with the releases.

To kick the tires on the Vagrant images, take a look at http://cloud-images.ubuntu.com/vagrant. I will be working with the fine folks at Vagrant to get the official Ubuntu Vagrant images listed at  http://www.vagrantbox.es/

If you are interested in learning about the Vagrant development environment, head on over to Vagrant for more information.

Read more

After missing my weekly live Ubuntu and Community Management video Q&A last week due to exhibiting at CES, I will be doing this week’s live video Q&A on Monday 14th January 2013 (tomorrow) at 7pm UTC (click here for the time in your location). The day is different this week as I need to join a sprint later this week.

I will be kicking off the session with a summary of Ubuntu at CES and a summary of the response to Ubuntu on phones in general as well next steps. We will then get into the Q&A, and as ever, you are welcome to ask me absolutely anything on the show.

To join, head over to Ubuntu On Air at 7pm UTC on Monday 14th January 2013 and you can ask your questions in the embedded chat box.

Look forward to seeing you all there!

Read more