Project News

As Project Atomic continues to lift off, a lot of attention has been focused on the container aspects of Atomic, and our consumption of the popular Docker container technology. Atomic, however, is not just about container technology, nor is it solely about the GearD container management that will also be a part of Project Atomic host. Nor just about about Cockpit. It’s about all of those technologies and more.

But what makes Atomic atomic? I’ve had some people come up to me and ask if we are making a word-play on the container/size thing and using the label Atomic to describe container technology. In actuality, the atomic in Atomic describes the one bit of technology that makes Project Atomic very unique: rpm-ostree.

Read More »

With DockerCon wrapping up earlier this week, it’s little surprise that containers are getting a lot of attention in the Web-o-sphere these days.

One of the better articles I have seen in a while that covers container technology is Rami Rosen’s piece on Linux Journal. This is a great primer that gets into the guts of containers, explaining not only how they work but why they are beneficial:

Due to the fact that containers are more lightweight than VMs, you can achieve higher densities with containers than with VMs on the same host (practically speaking, you can deploy more instances of containers than of VMs on the same host)… Another advantage of containers over VMs is that starting and shutting down a container is much faster than starting and shutting down a VM.

It is easy to see the focus on containers as some sort of threat to virtual machines. Application-centric containers, after all sound like a much easier technology to manage than a whole VM. In some respects, that’s some truth to that. Developers, after all, would love nothing more than not having to deal with OS updates changing libraries out from under their applications.

The Place For Virtualization

But don’t count VMs out yet; just like operating systems, VMs will still have a place in IT. Running Project Atomic hosts can be done on bare metal to be sure, but running the Atomic hosts as VMs that can be orchestrated and managed on the virtualization level can give admins a huge amount of flexibility.

It’s not just applications that can benefit from containers, mind you, cloud infrastructure itself can be transformed by containers. There is a real push to package OpenStack services as containers, either on bare metal or atop multi-service KVM machines. Ideally, this would reduce the complexity found in OpenStack usage and packaging. It’s pretty cool to imagine some of the many scenarios: Atomic Host virtual machines running containers with RDO OpenStack services to deploy your applications in true cloud fashion. Manage those Host VMs with a data center manager like oVirt, and you’ve got superior flexibility for your IT configuration.

The day is coming, sooner than you can imagine.

Yesterday at DockerCon, the Docker folks announced the 1.0 release along with a number of other interesting announcements. To make sure that the Atomic community has the latest and greatest tools to work with, we’ve rolled up a new image based on Fedora 20 with Docker 1.0 and a number of other updates.

Note that some of the packages in this image come from updates-testing or Copr builds. A big thanks to Jason Brooks for managing the builds and the Copr packages!

What’s New

In addition to Docker 1.0 (see the official Docker post on that), the latest release of the Atomic proof-of-concept image includes:

• Cockpit 0.9
  • Cockpit no longer needs SELinux disabled
  • Cockpit runs mostly unprivileged now
  • Cockpit listens on port 1001
• Updated GearD
• Additional packages to make working with the image easier (e.g. GNU Screen)

See also Stef Walter’s post on Cockpit. A number of other packages have also been updated. If you’re already testing Atomic, you can update to the latest with rpm-ostree upgrade and then systemctl reboot.

If you haven’t tried it yet, you can grab the newest images for KVM 20140609.qcow2.xz or VirtualBox 20140609.vdi.bz2. Be sure to check out the Get Started with Atomic page as well.

Have questions? Come find us on Freenode in the #atomic channel, or ask questions on Ask.ProjectAtomic.io.

Cockpit 0.9 has been released and includes some major milestones for the project. With Cockpit 0.8, we’d moved beyond the prototype stage, and have closed a bunch of security and stability issues.

With Cockpit 0.9 we added continuous integration tests for running on SELinux. We want to be the first to know if Cockpit breaks due to SELinux and not find out about it because someone ran into a problem somewhere. At least that’s the goal!

One of the most notable changes is that Cockpit now respects the system access privileges and won’t provide a way to escalate privileges without going through the usual channels like polkit or sudo.

Because of this some features that used to work for accounts in the wheel group, now only work as root. We’re working on fixing this regression by fixing system default policies in the various services (like NetworkManager) that we access.

Still Evolving, Be Careful

Soon to come down the pipe are Docker image pull support in 0.10, and soon a redone Networking configuration page.

Cockpit has changed a bit in the jump to 0.8, and a lot of it runs unprivileged now. We’ve built our own quite restrictive SELinux policy, and will be running test suites against this policy and updating it to make changes.

Our goal is that having Cockpit 0.8 or later installed should pose no security risk. That said, Cockpit is still in rapid development, and you should still be careful when using it to manage your system.

Want to take a look at Cockpit, or provide feedback? Check it out on GitHub, and open an issue if you find any problems.

We hope to have a new Atomic Fedora 20-based image up soon that will include the latest Docker, Cockpit, and other updates.

A strange thing is going on in IT these days, an unintentional fake out that on the surface could lead people to wonder if operating systems are becoming more and more irrelevant–when actually the opposite is going on.

In 2011, I addressed this topic from the perspective of the desktop, arguing that while the software as a service (SaaS) way of doing things would seem to suggest that applications that run in the browser don’t really need to care about the desktop operating system, the then-rising app-store model of application deployment made the choice of operating system all the more important. Native apps installed on operating systems kept the notion of operating systems alive (even if those apps were merely tricked-up portals to the same web services to which a browser could link).

Read More »