When we consolidated all CentOS Distro builders in a new centralized setup, covering all arches (so basically x86_64, i386, ppc64le, ppc64, aarch64 and armhfp those days), we wanted also to add redundancy where it was possible to.

The interesting "SecureBoot" corner case came on the table and we had to find a different way to build the following packages:

  •  shim (both signed and unsigned
  • grub2
  • fwupdate
  • kernel

The other reason why we considered rebuilding it is that the cert we were using has expired :

curl --location --silent https://github.com/CentOS/sig-core-SecureBoot/raw/master/CentOS_7/kernel/SOURCES/centos.cer | openssl x509 -inform der -text -noout|grep -A2 Validity

While technically it doesn't really matter for Secureboot itself, it was better to get a new key/cert rolled-in and use the new one for new builds.

That's where it's interesting as because shim embeds the certs in the Machine Owner Key (MOK), and that each other component used in the boot chain is validated against that (so grub2 first, then kernel and kernel modules) that means that once deployed , the new shim would not be able to boot previous grub2/kernel.

But there is a solution for that : instead of "embedding" only the new cert, we can have both the old one and new one, permitting us to still boot older kernels but also the new ones we'll build/push soon (built on the new build system), and that's what we used for that new shim package.

That's where we'd like you (SecureBoot users) to give us feedback about that new shim pkg. It was already validated on some hardware nodes, passed some QA tests, but we'd prefer to have more feedback.

Worth noting that such rebuild has also a patch that should fix an issue we had with shim not allowing to import key in MOK through mokutil (see https://bugs.centos.org/view.php?id=14050)

How can you test ?

If you're using UEFI with SecureBoot enabled , we have signed/pushed those pkgs to the CR repository (see https://wiki.centos.org/AdditionalResources/Repositories/CR)

That repo is by default disabled, but following command would let you update shim :

yum update shim --enablerepo=cr

Then reboot and it should work like before, so validating the boot chain (while still using grub2/kernel packages signed with previous key)

We'd appreciate feedback on this list, or #centos-devel on irc.freenode.net

I'd like to thank Patrick Uiterwijk and Peter Jones for their help for
the patch and validation for that shim

This Thursday we held our first Dojo at DevConf.us in Boston. We had about 40 people in attendance, and had 9 presenters on a variety of topics.

I want to particularly draw attention to our keynote, by Brendan Conoboy, who discussed the relationship - past and future - between Fedora, CentOS, and RHEL, which is more complicated than many people understand. But we're working on simplifying those relationships, and Brendan does a great job of explaining where we're headed, and why.

The details of this event are in the CentOS Wiki and are being updated with slides and videos as they become available. All of the videos are in the event playlist on Youtube - check back over the coming week as we upload the remainder of the talks.

Our next event will be held at CERN in Meyrin, Switzerland, in October. Details are available at cern.ch/centos and we expect to post the schedule in the coming week.

The CentOS Atomic SIG has released an updated version of CentOS Atomic Host (7.1807), 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:

  • atomic-1.22.1-22.git5a342e3.el7.x86_64
  • cloud-init-0.7.9-24.el7.centos.1.x86_64
  • docker-1.13.1-68.gitdded712.el7.centos.x86_64
  • etcd-3.2.22-1.el7.x86_64
  • flannel-0.7.1-4.el7.x86_64
  • kernel-3.10.0-862.11.6.el7.x86_64
  • ostree-2018.5-1.el7.x86_64
  • rpm-ostree-client-2018.5-1.atomic.el7.x86_64

Download CentOS Atomic Host

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:

# atomic host upgrade

Release Cycle

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.

Getting Involved

CentOS Atomic Host is produced by the CentOS Atomic SIG, based on upstream work from Project Atomic. If you’d like to work on testing images, help with packaging, documentation – join us!

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.

Getting Help

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.

Save the date! February 1 in Brussels!

As we do each year, we are once again planning to host a CentOS Dojo in Brussels on Friday, February 1st, the day before FOSDEM 2019. Details about this event are on the CentOS wiki, and more details are being added all the time.

The Call for Presentations for this event is now open, and will be open until October 15th, 2018.

CentOS Dojos are one-day (or, occasionally, two-day) events that bring together people from the CentOS community to talk about systems administration, best practices, and emerging technologies, and bring the community closer together.

It's time for another community newsletter. As always, we have lots of
information about upcoming events, recent releases, and what our SIGs
(Special Interest Groups) are working on.

You can read the newsletter at https://wiki.centos.org/Newsletter/1803

Past editions of the newsletter, as well as information about how you
can contribute, is available at http://wiki.centos.org/Newsletter

In the coming months, we'd like to feature articles from you, the users
of CentOS, about what you're doing on top of this great platform.

Talk to you next month!

Rich, for the CentOS Newsletter team

Join us this weekend (August 4th - 5th) in Bengaluru for DevConf.in, the second annual Developers' Conference.

We want to draw particular attention to two talks.

Bama charan Kundu will be talking about the CentOS Container Pipeline project:

Various container build services offer developers to build their image with a git push and scan the container for known CVEs (as a paid service). What they don't provide is Dockerfile linting; scanners that would scan for available package updates (rpm, pip, npm, gem); a build process that rebuilds an image not only on git push but also when there's RPM update in its enabled repo or when its base image is updated.

Welcome to CentOS Container Pipeline project. It provides all these and more, out of the box, free of cost, on CentOS infra, and with a focus on open source developers. All it needs is the link to git repo containing the Dockerfile.

And Karanbir Singh will be delivering the closing keynote:

Open Source won! In this session, I would like to explore the effects this has on culture and impact beyond just the software development process; focusing on how we run and operate software today and into the future. As an existing or potential contributor to future services, as either a developer, an operator or manager, I will aim to give you the focus points helping you make good choices in the right directions. And most importantly, asking the right questions.

Additionally, CentOS will have a booth in the expo hall, so drop by for your CentOS stickers and swag! See you in Bengaluru!

We're just three weeks away from our upcoming Dojo at DevConf.us. We've recently added a new keynote to kick the day off, and an awesome evening event. Further event details are available on the CentOS Events Wiki, but here's the highlights:

The day starts at 9am with a keynote from Brendan Conoboy, who will be discussing the relationship between Fedora, CentOS, and Red Hat Enterprise Linux (RHEL) in his talk "RHEL, Fedora and CentOS: Solving The Penrose Triangle".

The day continues with technical presentations about Kubernetes, various CentOS SIGs, HPC, Ceph, and other topics.

And we'll wrap up the day by walking over to Cheeky Monkey Brewing for light refreshments.

So, join us at 9am, Thursday August 16th, at the George Sherman Union building at Boston University. Register by clicking the link on the event page, so that we know you're coming and can plan accordingly. (Registration is free, but we need to know how many people are coming.)

With the release of CentOS 7.5.1804, the CentOS Project has taken the next big step in improving software delivery security by signing all repository metadata for CentOS 6 and CentOS 7 for all architectures, including the repositories for CentOS Special Interest Groups (SIGs) produced by the CentOS Community Build System (CBS).

Wait, what do you mean signed repository metadata?

As most users of Linux distributions know, software is delivered in the form of “packages” to users through repositories. Packages are installed by their package manager (such as YUM or DNF) by fetching information about the repository to identify what it can get to do a particular user action (install new package, upgrade existing ones, and so on).

But how do you validate that the software you are getting is the software you are supposed to get? Most Linux distributions do this by digitally signing the packages using a signature that uniquely identifies the distributor via GPG. The advantage of this is that no matter what mechanism you receive the package (via repository, direct download, or on a flash drive), you can validate the signature and be assured it is a package from the distribution.

But there is a gap here: how are you assured that the repository hasn’t been tampered with? This is a specific type of vulnerability that applies only to package repositories, because they provide files that contain an index of the software in the repository, and how to fetch them. The way to close this hole is to provide a means of verifying the repository metadata is good, too. This allows the package manager to verify that the metadata is what it should be and is from the distribution before starting to process the metadata. This can help with avoiding certain types of attacks due to malformed metadata files.

We started doing this in 2015 for the main CentOS core repositories, and now we’re offering this for all repositories published by the CentOS Project.

Sounds great! How do I use it?

At the time of this writing, we do not automatically validate the repository metadata. If you want to do this, simply add the following line to the YUM repository configuration file (They are *.repo files in /etc/yum.repos.d):


If you want to enforce this globally, you can set this in /etc/yum.conf instead, though be warned that repositories like Fedora EPEL will not work since Fedora Infrastructure is currently working on signing repository metadata.

I’m a SIG maintainer and I’d like to have this by default, what do I do?

Great question! If you’re a SIG maintainer and manage the repository configuration package (i.e. centos-release-* packages), then you can choose to make this the new default for repository configuration.

To do so, just simply add “repo_gpgcheck=1” to the .repo files in your package, and it will enable it. On next update, if the user hasn’t touched/modified the *.repo files, it’ll switch on. New installations will get it as well, too.

Again, though, if you use Fedora EPEL in your repo configuration, you must not add the setting to the EPEL section in your configuration.

We are pleased to announce the immediate availability of CentOS Linux
6.10 and install media for i386 and x86_64 Architectures. Release Notes
for 6.10 are available at:


CentOS Linux 6.10 is derived from source code released by Red Hat, Inc.
for Red Hat Enterprise Linux 6.10. All upstream variants have been placed
into one combined repository to make it easier for end users.
Workstation, server, and minimal installs can all be done from our
combined repository. All of our testing is only done against this
combined distribution.

There are various changes in this release, compared with the
past CentOS Linux 6 releases, and we highly recommend everyone study the
upstream Release Notes as well as the upstream Technical Notes about the
changes and how they might impact your installation. (See the 'Further
Reading' section if the CentOS release notes link above).

All updates since the upstream 6.10 release are also on the CentOS
mirrors as zero day updates. When installing CentOS-6.10 (or any other
version) from any of our media, you should always run 'yum update' after
the install to apply these.

Users consuming our CentOS-CR repositories will already be running most
of the packages that make up CentOS-6.10, and all updates released since.
They will notice only the a few updates today when moving to CentOS
Linux 6.10. For more
information on the CR repository for future updates, see this link:

Release Announcements for all updated packages are available here:

Upgrading From Prior Major CentOS Versions:

We recommend everyone perform a fresh reinstall rather than attempt an
in-place upgrade from other major CentOS versions (CentOS-2.1,
CentOS-3.x, CentOS-4.x, CentOS-5.x).

Upgrading from CentOS-6.0 / 6.1 / 6.2 / 6.3 / 6.4 / 6.5 / 6.6 / 6.7 /
6.8 / 6.9

CentOS Linux is designed to automatically upgrade between releases
within a major version (in this case, CentOS-6). Unless you have edited
your yum default configuration, a 'yum update' should move your machines
seamlessly from any previous CentOS Linux 6.x release to 6.10. We also
test this in our QA cycles and have noticed no problems, any issues
would be mentioned in the Release Notes.

Downloading CentOS Linux 6.10 for new installs:

When possible, consider using torrents to obtain our ISOs. Usually it is
also the fastest means to download the distro.

The install media is split into various formats. We have made efforts to
ensure that most install types and roles can be done from DVD-1 itself,
and the minimal install ISO is only tested to deliver a minimal install
set, when used as an ISO format ( either on cd or usb ). While other
forms of installs ( eg. pxe delivered ) might work from the minimal ISO,
they are neither tested not supported. The only format where we support
the entire set of install options and delivery mechanisms is via the
complete CentOS Linux 6.10 tree, which can also be created by
consolidating all content from DVD1 and DVD2.

We no longer produce CD size images for the entire CentOS Linux 6
distribution, however the minimal install and netinstall iso images are
small enough to fit on all CD grade media.

Torrent files for the DVD's are available at :



If you download an ISO via torrent, leave it up for a couple hours to
share with other users who are downloading.

You can also use a mirror close to you to get any of our ISOs:

If you need to update a local mirror, you can choose from our mirror
network ( http://www.centos.org/download/mirrors/ ). Most mirrors will
allow downloads over http, ftp and rsync.

Note: The x86_64 ISOs (minimal, netinstall, DVD1) should install on UEFI
machines. Secure Boot must be disabled to install CentOS 6. The Live
ISOs and i386 ISOs will not boot with UEFI.

sha256sum for the CentOS-6.10 ISOS:











Cloud Images:

Images for various on-premise and off-premise Cloud environments are
currently under development for CentOS Linux 6.10 and will be released in
the coming days. Everyone looking to join and help with the CentOS Cloud
efforts is encouraged to join the CentOS-devel list where such issues
are discussed ( http://lists.centos.org/mailman/listinfo/centos-devel ).

Getting Help:

The best place to start when looking for help with CentOS is at the wiki
( http://wiki.centos.org/GettingHelp ) which lists various options and
communities who might be able to help. If you think there is a bug in
the system, do report it at http://bugs.centos.org/ - but keep in mind
that the bugs system is *not* a support mechanism. If you need supported
software with Support Level Agreements, people to call and response
times then we recommend Red Hat Enterprise Linux.

If you have questions you would like to field at us in real time, come
join the office hours on Wed or Thu of every week. You can find details
on these at http://wiki.centos.org/OfficeHours

Meet-ups and Events:

If you would like to get involved in helping organize, run, present or
sponsor a CentOS Dojo or even just want more details then join the
CentOS Promo list:
http://lists.centos.org/mailman/listinfo/centos-promo and drop an email
introducing yourself. We are very keen to find help to run events around
the world, and also to find people who can represent CentOS at various
community events around the world. (Current Events List:
https://wiki.centos.org/Events )

Contributing and joining the project:

We are always looking for people to join and help with various things in
the project. If you are keen to help out a good place to start is the
wiki page at http://wiki.centos.org/Contribute . If you have questions
or a specific area you would like to contribute towards that is not
covered on that page, feel free to drop in on #centos-devel at
irc.freenode.net for a chat or email the centos-devel list

Thanks to everyone who contributed towards making CentOS Linux 6.10,
especially the effort put in, as always, by the QA
(http://wiki.centos.org/QaGroup) and Build teams.

A special shout out to all the donors who have contributed hardware,
network connectivity, hosting and resources over the years. The CentOS
project now has a fairly well setup resource pool, solely thanks to the


Last week at the ISC-HPC event in Frankfurt, I had the opportunity to speak briefly with the amazing student teams in the SCC - Student Cluster Competition. These students use commodity hardware to build supercomputers, with a limit of 3KW power consumption, and compete on a variety of benchmarks.

These teams are overwhelmingly powered by CentOS, which has the latest HPC tools and libraries, and is the defacto standard when it comes to spinning up a new supercomputing cluster.

12 teams competed, and I got to speak with four of them this year.

University of Parana, Brazil

University of Warsaw, Poland

University of Heidelberg, Germany

University of Kesetsart, Thailand