The CentOS Atomic SIG has released an updated version of CentOS Atomic Host (7.1902), an operating system designed to run Linux containers, built from standard CentOS 7 RPMs, and tracking the component versions included in Red Hat Enterprise Linux Atomic Host.
CentOS Atomic Host includes these core component versions:
CentOS Atomic Host is available as a VirtualBox or libvirt-formatted Vagrant box, or as an installable ISO, qcow2 or Amazon Machine image. For links to media, see the CentOS wiki.
If you’re running a previous version of CentOS Atomic Host, you can upgrade to the current image by running the following command:
The CentOS Atomic Host image follows the upstream Red Hat Enterprise Linux Atomic Host cadence. After sources are released, they’re rebuilt and included in new images. After the images are tested by the SIG and deemed ready, we announce them.
You’ll often find us in #atomic and/or #centos-devel if you have questions. You can also join the atomic-devel mailing list if you’d like to discuss the direction of Project Atomic, its components, or have other questions.
If you run into any problems with the images or components, feel free to ask on the centos-devel mailing list.
Have questions about using Atomic? See the atomic mailing list or find us in the #atomic channel on Freenode.
A substantial number of released/updates were announced on Tuesday, March 19th, and are listed below. For timely announcements of these updates, subscribe to the centos-announce mailing list, at https://lists.centos.org/mailman/listinfo/centos-announce .
We issued the following CEEA (CentOS Errata and Enhancements Advisories) during March:
We issued the following CESA (CentOS Errata and Security Advisories) during March:
We issued the following CEBA (CentOS Errata and Bugfix Advisories) during March:
We are pleased to announce new official Vagrant images of CentOS Linux 6.10 and CentOS Linux 7.6.1810 for x86_64. All included packages have been updated to February 28th, 2019.
config.vm.synced_folder ".", "/vagrant", type: "virtualbox"
config.vm.synced_folder ".", "/vagrant", disabled: true
to their Vagrantfile, to prevent errors on "vagrant up".
vb.customize ["modifyvm", :id, "--natdnshostresolver1", "off"]
Our automatic testing is running on a CentOS Linux 7 host, using Vagrant 1.9.4 with vagrant-libvirt and VirtualBox 5.1.20 (without the Guest Additions) as providers. We strongly recommend using the libvirt provider when stability is required.
The official images can be downloaded from Vagrant Cloud. We provide images for HyperV, libvirt-kvm, VirtualBox and VMware.
If you never used our images before:
vagrant box add centos/6 # for CentOS Linux 6, or... vagrant box add centos/7 # for CentOS Linux 7
Existing users can upgrade their images:
vagrant box update --box centos/6 vagrant box update --box centos/7
The SHA256 checksums of the images are signed with the CentOS 7 Official Signing Key. First, download and verify the checksum file:
$ curl http://cloud.centos.org/centos/7/vagrant/x86_64/images/sha256sum.txt.asc -o sha256sum.txt.asc $ gpg --verify sha256sum.txt.asc
Once you are sure that the checksums are properly signed by the CentOS Project, you have to include them in your Vagrantfile (Vagrant unfortunately ignores the checksum provided from the command line). Here's the relevant snippet from my own Vagrantfile, using v1803.01 and VirtualBox:
Vagrant.configure(2) do |config| config.vm.box = "centos/7" config.vm.provider :virtualbox do |virtualbox, override| virtualbox.memory = 1024 override.vm.box_download_checksum_type = "sha256" override.vm.box_download_checksum = "b24c912b136d2aa9b7b94fc2689b2001c8d04280cf25983123e45b6a52693fb3" override.vm.box_url = "https://cloud.centos.org/centos/7/vagrant/x86_64/images/CentOS-7-x86_64-Vagrant-1803_01.VirtualBox.box" end end
If you encounter any unexpected issues with the Vagrant images, feel free to ask on the centos-devel mailing list, or in #centos on Freenode IRC.
I would like to warmly thank Brian Stinson, Fabian Arrotin and Thomas Oulevey for their work on the build infrastructure, as well as Patrick Lang from Microsoft for testing and feedback on the Hyper-V images. I would also like to thank the CentOS Project Lead, Karanbir Singh, without whose years of continuous support we wouldn't have had the Vagrant images in their present form.
I would also like to thank the following people (in alphabetical order):
As I’ve mentioned, as we approach our 15th anniversary, I’ve been talking with some of the people who were around in those early days, to get more of the backstory. (See our YouTube channel for the full interview.)
Last week, I spoke with Greg Kurtzer, who founded the Caos Linux project, which turned into the CentOS Project in 2002. I got an eye-opening story of how it all started.
In October of 2000, Greg, who was already an avid Debian GNU/Linux fan, joined an organization (LBNL) that was a Red Hat shop. (This was before Red Hat Enterprise Linux.) And, while generating packages for work, he decided that what was really needed was a community-managed distribution of RPM-based Linux, much like Debian existed for the dpkg crowd.
Now, in the early days of open source and free software, we had communities that were more defined by personalities than by technologies. Granted, that situation still exists today, but if you didn’t endure the flame wars of the late 90’s and early 2000’s, it can be a little hard to imagine just how bad it sometimes got.
With Caos Linux, Greg had an opportunity to set a new tone for the project as more welcoming, beginner friendly, and encouraging than was the norm at the time.
When Red Hat Linux became Red Hat Enterprise Linux, and the project could no longer use Red Hat Linux as the build system, they began to work with Rocky McGough who was already doing a rebuild of RHEL for his employer. (There were a number of these projects at the time.) He was changing roles professionally, and wanted the project to continue, and so agreed to merge with the work that Greg was doing. Rocky was, effectively, the first technical lead of CentOS. The name itself was coined by a participant in the UK, who will be mentioned again later.
The process was started by Greg to create a 501c3 non-profit entity - the Caos Foundation - which would host the CentOS Project. There was a framework being created to cover governance, funding, and organizing volunteer effort. Unfortunately, the individual who came up with the name ‘CentOS’ also owned the domain name, and declined to release it to the foundation as promised.
Meanwhile, when a RHEL-rebuild project called White Box Linux was discontinued, it became clear that what the community wanted was a free alternative to Red Hat Enterprise Linux. CentOS moved into that space, based on the work that White Box had done.
As CentOS was starting to gain popularity, word came to the project that Rocky had committed suicide. In addition to being very tragic, this presented certain technical difficulties to the project, since he was the technical lead at the time. In hindsight, it is a shame he didn’t get to see what the project would become in time, as the foresight may have prevented this tragedy.
Greg passed on the technical lead position to the individual in the UK who held the domain name, while Greg continued to manage the project, community, and governance side of things. Donations to the project started to come in to support the infrastructure and other needs of the project. And third-party vendors making a business around the project also began to appear and prosper. The project was growing rapidly, and donations to the project were growing rapidly.
From there, due to a number of situations not really germane to this article, Greg moved on, and the CentOS project, through a number of events, came to where it is today. We’ll explore some of these other transitions in upcoming interviews and articles.
Of particular interest to me during my interview with Greg, were his remarks about setting the tone in a project. Being welcoming, kind, and patient takes so little time, but creates a community that people want to participate in, are proud to be part of and which is sustainable for a long time, due to the ability of new participants to enter and feel ownership. I’ve published a separate, much shorter, video with just those remarks, which I’d encourage you take two minutes to watch, too.
CentOS Opstools SIG Quarterly Report
Dec 01, 2018 - Feb 28, 2019
Provide tools and, documentation, recommendations and best practices for operators of large infrastructure.
We need to be honest to see that contributions decreased over the time. Members moved on, and at the same time, we failed to attract new contributors.
CentOS opstools packages are being consumed by OpenStack Kolla, and at the same time, for example also by oVirt.
During FOSDEM, we got in touch with collectd upstream. collectd is also integral part of the OPNFV Barometer project. While Barometer provides containers to test the project, the same can be achieved by using packages from CentOS-Opstools.
Architectual-wise, we are shifting from using sensu and fluentd. If anyone is interested in keeping them, it's the right time to step up.
The replacements will be using rsyslog and Prometheus. Currently, we are not building Prometheus under the opstools SIG; interested
persons are encouraged to step up here!
None at this point, but we should keep an eye on contributors.
Happy birthday, CentOS!
15 years ago, the CentOS project started up in order to fill a gap left by a change in the way that Red Hat decided to market their product.
Many of the people that were involved in those early days are still involved today, although in different capacities than they were then. Over they years, their involvement has changed, due to their own changing job responsibilities, as well as the shifting technological landscape.
Over the next few months, as part of our celebration of our 15 year anniversary, I'm going to be talking with some of these people that were involved in the early days, as well as some that have joined later on, to talk about how and why people get involved in this project.
If you would like to tell your story, please get in touch with me at firstname.lastname@example.org and we'll schedule an interview.
Packaging and maintaining different FOSS based virtualization applications that one can install and run natively on CentOS.
We are always looking for new members.
Tomasz Baranski and Yuval Turgeman joined the SIG for oVirt project.
oVirt 4.2 reached end of life with the upstream release of oVirt 4.3. Upstream is planning 4.3.1 to be shipped live on February 26th, the SIG will rebase on that.
On Xen side, Xen 4.8 has been updated to 4.8.5-1
The Virtualization SIG remains fairly healthy. All the projects within the SIG are updating regularly on biweekly meetings.
oVirt had a conference in Milan on November 16th 2018 and is planning a new conference in Rome this spring.
oVirt was also present at Devconf.cz and Fosdem.
Xen 4.10.2 is also available, and the dom0-enabled Linux kernel is at 4.9.127. Release candidate builds of Xen 4.12 are also available.
oVirt pushed a patch for having a CentOS appliance including oVirt Guest Agent in https://github.com/CentOS/sig-cloud-instance-build/pull/127
We've updated centos-release-xen to default to Xen 4.8 in the CBS repos.
In this post, we're going to talk about how to use
buildah to build container images on CentOS.
buildah is a command line tool that facilitates building OCI compliant images. There's a plethora of information available around what
buildah is on its GitHub landing page so we won't dive more into what it is. However, it's worth mentioning that
buildah helps you build container images without having to run any daemon in the background, unlike the
docker CLI tool which requires the Docker daemon to be running in the background.
buildah is already available in the CentOS repos. All we need to do is:
$ yum install -y buildah $ buildah -v buildah version 1.5-dev (image-spec 1.0.0, runtime-spec 1.0.0)
buildah offers a number of features and options. To know about these, simply execute
buildah on the command line or refer to its manual page (
buildah can build a container image by referring the same Dockerfile that
docker build refers to. Let's consider this simple Dockerfile for example. All it does is install the
$ cat Dockerfile FROM registry.centos.org/centos/centos RUN yum install -y wget && yum clean all
Now, build the container image named
$ buildah bud -t wget . $ buildah images IMAGE ID IMAGE NAME CREATED AT SIZE 2f254a4fff8d registry.centos.org/centos/centos:latest Dec 17, 2018 05:07 210 MB 9b6563cfaff2 localhost/wget:latest Jan 16, 2019 11:01 234 MB
You can use this container image with
podman by doing:
$ podman run -it --rm wget bash
podman is a tool for managing pods, containers, and container images. Its website contains extensive detail about its capabilities and uses.
buildah also makes it possible to use the image thus built via the local Docker daemon. It's as simple as doing a
$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE $ buildah images IMAGE ID IMAGE NAME CREATED AT SIZE 2f254a4fff8d registry.centos.org/centos/centos:latest Dec 17, 2018 05:07 210 MB 9b6563cfaff2 localhost/wget:latest Jan 16, 2019 11:01 234 MB $ buildah push wget:latest docker-daemon:registry.centos.org/centos/wget:latest Getting image source signatures Copying blob sha256:b05580fca2f9aabb2d8fa975b29146c9147c8418e559f197c54a4fac04babb95 200.47 MiB / 200.47 MiB [==================================================] 4s Copying blob sha256:fa5e7b9f8f4d8f07f7af27cd06269ba16ba0f06cbacacc7c7e96a616da885cab 22.82 MiB / 22.82 MiB [====================================================] 0s Copying config sha256:9b6563cfaff28baa1075e86b60c502f85fc31b56bdb641d314a7c61d2e91fae8 1.33 KiB / 1.33 KiB [======================================================] 0s Writing manifest to image destination Storing signatures Successfully pushed registry.centos.org/centos/wget:latest@sha256:66f4c1c8378c7d9e22a0d3c9a0943739082dfeae3344e5f2b069e9c9ddf08271 $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE registry.centos.org/centos/wget latest 9b6563cfaff2 6 minutes ago 226 MB
Initially, the local Docker daemon storage had no container images. We did
buildah push wget:latest docker-daemon:registry.centos.org/wget:latest to push the image to local Docker daemon's storage. Now doing
docker images shows the image and can then be used with
In this blog, we saw simple steps that need to be performed to install and use
buildah to build OCI images which can then be pushed to local Docker daemon's storage.
buildah can also push container images to the remote registry. It is highly recommended to read the documentation to know about more features and capabilities of
In a future blog, we will share how the CentOS Container Pipeline team managed to build container images on OpenShift using
Just a quick update - the schedule from the recent CentOS Dojo at FOSDEM has been updated to include the videos from each presentation.
Note: Three of the talks are missing video due to equipment failure.