The CentOS Atomic SIG has released an updated version of CentOS Atomic Host (7.1708), a lean operating system designed to run Docker containers, built from standard CentOS 7 RPMs, and tracking the component versions included in Red Hat Enterprise Linux Atomic Host.

This release, which is based on the RHEL 7.4 source code, includes an updated kernel that supports overlayfs container storage, among other enhancements.

CentOS Atomic Host includes these core component versions:

  • atomic-1.18.1-3.1.git0705b1b.el7.x86_64
  • cloud-init-0.7.9-9.el7.centos.2.x86_64
  • docker-1.12.6-48.git0fdc778.el7.centos.x86_64
  • etcd-3.1.9-2.el7.x86_64
  • flannel-0.7.1-2.el7.x86_64
  • kernel-3.10.0-693.2.2.el7.x86_64
  • kubernetes-node-1.5.2-0.7.git269f928.el7.x86_64
  • ostree-2017.7-1.el7.x86_64
  • rpm-ostree-client-2017.6-6.atomic.el7.x86_64

OverlayFS Storage

In previous releases of CentOS Atomic Host, SELinux had to be in permissive or disabled mode for OverlayFS storage to work. Now you can run the OverlayFS file system with SELinux in enforcing mode. CentOS Atomic Host still defaults to devicemapper storage, but you can switch to OverlayFS using the following commands:

$ systemctl stop docker
$ atomic storage reset
  # Reallocate space to the root VG - tweak how much to your liking
$ lvm lvextend -r -l +50%FREE atomicos/root
$ atomic storage modify --driver overlay2
$ systemctl start docker

For more information on storage management options, see the upstream RHEL documentation.

Containerized Master

CentOS Atomic Host ships without the kubernetes-master package built into the image. For information on how to run these kubernetes components as system containers, consult the CentOS wiki.

If you prefer to run Kubernetes from installed rpms, you can layer the master components onto your Atomic Host image using rpm-ostree package layering with the command: atomic host install kubernetes-master -r.

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.

Upgrading

If you're running a previous version of CentOS Atomic Host, you can upgrade to the current image by running the following command:

$ sudo 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!

The SIG meets every two weeks on Tuesday at 04:00 UTC in #centos-devel, and on the alternating weeks, meets as part of the Project Atomic community meeting at 16:00 UTC on Monday in the #atomic channel. 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.

We are pleased to announce new official Vagrant images of CentOS Linux 6.9 and CentOS Linux 7.4.1708 for x86_64 (based on the sources of RHEL 7.4). All included packages have been updated to 12 September 2017.

Known Issues

  1. The VirtualBox Guest Additions are not preinstalled; if you need them for shared folders, please install the vagrant-vbguest plugin and add the following line to your Vagrantfile:
    config.vm.synced_folder ".", "/vagrant", type: "virtualbox"

    We recommend using NFS instead of VirtualBox shared folders if possible; you can also use the vagrant-sshfs plugin, which, unlike NFS, works on all operating systems.

  2. Since the Guest Additions are missing, our images are preconfigured to use rsync for synced folders. Windows users can either use SMB for synced folders, or disable the sync directory by adding the line
    config.vm.synced_folder ".", "/vagrant", disabled: true

    to their Vagrantfile, to prevent errors on "vagrant up".

  3. Vagrant 1.8.5 is unable to create new CentOS Linux boxes due to Vagrant bug #7610
  4. Vagrant 1.8.7 is unable to download or update boxes due to Vagrant bug #7969.
  5. Vagrant 1.9.1 broke private networking, see Vagrant bug #8166
  6. Vagrant 1.9.3 doesn't work with SMB sync due to Vagrant bug #8404
  7. The vagrant-libvirt plugin is only compatible with Vagrant 1.5 to 1.8
  8. Installing open-vm-tools is not enough for enabling shared folders with Vagrant’s VMware provider. Please follow the detailed instructions in https://github.com/mvermaes/centos-vmware-tools (updated for this release).

Recommended Setup on the Host

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.

We also performed additional manual testing with Vagrant 2.0.0 on OS X 10.11.6, with VirtualBox 5.1.26.

Downloads

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

Verifying the integrity of the images

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

If the check passed, you can use the corresponding checksum when downloading the image with Vagrant:

$ vagrant box add --checksum-type sha256 --checksum aabcfe77a08b72bacbd6f05e5f26b67983b29314ee0039d0db4c9b28b4909fcd --provider libvirt --box-version 1705.01 centos/7

Unfortunately, vagrant box update doesn't accept a --checksum argument. Since there's no binary diffing involved in updating (the download size is the same, whether you have a previous version of the box or not), you can first issue vagrant box remove centos/7 and then download the box as described above.

Feedback

If you encounter any unexpected issues with the Vagrant images, feel free to ask on the centos-devel mailing list, or via IRC, in #centos on Freenode.

Ackowledgements

We would like to warmly thank 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.

We would also like to thank the following people (listed alphabetically):

  • Graham Mainwaring, for helping with tests and validations
  • Michael Vermaes, for testing our official images, as well as for writing the detailed guide to using them with VMware Fusion Pro and VMware Workstation Pro.

In an earlier article on CentOS Linux 7 (1708), I explained the the basic release process and about things like the Continuous Release (CR) repository.  I am not going to go into detail about those two topics here, just update you on the process.

The packages that make up what will be our CentOS Linux 7 (1708), minus the distribution installer and the new release files, are now in our CR repository.  Package release announcements.  The release notes are here for the release.

The CentOS team rolled in a bugfix to iptables to prevent the service from not restarting on any systems that do not use firewalld but have ip6tables and iptables on.  We used this patch in the fix.  We do not normally do that (normally only fix bugs when the source RPM is released upstream), but in this case we decided to because of the impact of no firewall on a huge number of internet facing machines that use CentOS.  The new package versioning (iptables-*1.4.21-18.0.el7*) is such that when a replacement is released by Red Hat for RHEL and after we build it, it will replace our version in this release.

Some things of note about this release

We had a record number of missing build requirements (that is, things required to build the release that are not actually in the distribution to run the released packages).  These packages are not part of RHEL proper and each one has to be researched and an appropriate package found (usually from EPEL or the Fedora Archives) to build the packages.  In the 1708 release, we had 11 of those source packages to find.  In the previous four CentOS release cycles there were a total of 5.

There are a larger number of services that have been rebased to newer versions in this release than in the past.  This seems to be a trend by the RHEL engineers to give the releases newer software, especially in the desktop/GUI areas, while still backporting most of the server related packages to maintain ABI/API compatibility.   The release notes talk about specific libraries that were rebased.  I like rebases, they give us newer stuff and who doesn't like that 🙂 .. but, they also mean newer shared libraries and that makes finding the correct build order for packages even more important.  This lead to a larger number of packages requiring rebuilding more than one time during the process because they had older shared library links initially.

Who should not install the CR (and wait for the full release)

The CR repository is not on by default and it is an opt-in process.  It usually takes 2-3 weeks after the CR release for the final release (to get the installer working, compile the full tree from older releases and the newer updates, generate install media, cloud images, vagrant boxes, container images, etc.).

Everyone wants to upgrade immediately (me too 🙂 ), but you may need to hold off for some of the following reasons.

  1.  If you use lots of third party repositories (EPEL, Nux!, CentOS Plus, etc.) then some of those packages could be outdated and the developers may need to link against newer libraries.  Your upgrade might work fine, it might not.  The CR is how we make our packages available to these devs, so it make take some amout of time before everything in 3rd party repos (and even CentOS Plus and CentOS Extras) work completely.
  2. Special Interest Group content also may need to be rebuilt against the newer shared libraries before they work.  I don't track each and every SIG, but I am involved in the Virt SIG and I maintain several of the xen packages there.  The xen repository needs a newer libvirt and seabios and then to have the xen packages rebuilt against that (as an example).  CR is how we make the new packages available for the Devs to be able to do that.

Each install is unique and should be tested before upgrading.  Many of the libraries have compatibility versions in the release an some things will work from the above, others will not.  yum should tell you any errors if it can not upgrade.

How to enable CR

You can enable CR with the command:  yum-config-manager --enable cr

After that you can upgrade with the command:  yum update

Notes:

  1. A change to rdma-core package from a nonarch to an arch version might want to bring in i686 packages due to the way 'obsoletes' work in yum.  This is a known upstream issue: bug   and is in the release notes .. so if you don't want the extra couple i686 packages do this for the update:  yum update rdma-core  After that completes, run yum update for the rest of the updated packages.
  2. The version of libgpod that was in EPEL before this update set was newer than the one released.  If you have that installed, you must first do yum downgrade libgpod , then do yum update

Enjoy!

Last week, the CentOS Atomic SIG released an updated version of CentOS Atomic Host (7.1707), a lean operating system designed to run Docker containers, built from standard CentOS 7 RPMs, and tracking the component versions included in Red Hat Enterprise Linux Atomic Host.

The release, which came as part of the monthly CentOS release stream, was a modest one, including only a single glibc bugfix update. The next Atomic Host release will be based on the RHEL 7.4 source code and will include support for overlayfs container storage, among other enhancements.

Outside of the Atomic Host itself, the SIG has updated its Kubernetes container images to be usable as system containers. What's more, in addition to the Kubernetes 1.5.x-based containers that derive from RHEL, the Atomic SIG is now producing packages and containers that provide the current 1.7.x version of Kubernetes.

Containerized Master

The downstream release of CentOS Atomic Host ships without the kubernetes-master package built into the image. You can install the master kubernetes components (apiserver, scheduler, and controller-manager) as system containers, using the following commands:

# atomic install --system --system-package=no --name kube-apiserver registry.centos.org/centos/kubernetes-apiserver:latest

# atomic install --system --system-package=no --name kube-scheduler registry.centos.org/centos/kubernetes-scheduler:latest

# atomic install --system --system-package=no --name kube-controller-manager registry.centos.org/centos/kubernetes-controller-manager:latest

Kubernetes 1.7.x

The CentOS Virt SIG is now producing Kubernetes 1.7.x rpms, available through this yum repo. The Atomic SIG is maintaining system containers based on these rpms that can be installed as as follows:

on your master

# atomic install --system --system-package=no --name kube-apiserver registry.centos.org/centos/kubernetes-sig-apiserver:latest

# atomic install --system --system-package=no --name kube-scheduler registry.centos.org/centos/kubernetes-sig-scheduler:latest

# atomic install --system --system-package=no --name kube-controller-manager registry.centos.org/centos/kubernetes-sig-controller-manager:latest

on your node(s)

# atomic install --system --system-package=no --name kubelet registry.centos.org/centos/kubernetes-sig-kubelet:latest

# atomic install --system --system-package=no --name kube-proxy registry.centos.org/centos/kubernetes-sig-proxy:latest

Both the 1.5.x and 1.7.x sets of containers have been tested with the kubernetes ansible scripts provided in the upstream contrib repository, and function as drop-in replacements for the installed rpms. If you prefer to run Kubernetes from installed rpms, you can layer the master components onto your Atomic Host image using rpm-ostree package layering with the command: atomic host install kubernetes-master.

The containers referenced in these systemd service files are built in and hosted from the CentOS Community Container Pipeline, based on Dockerfiles from the CentOS-Dockerfiles repository.

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.

Upgrading

If you're running a previous version of CentOS Atomic Host, you can upgrade to the current image by running the following command:

$ sudo 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!

The SIG meets every two weeks on Tuesday at 04:00 UTC in #centos-devel, and on the alternating weeks, meets as part of the Project Atomic community meeting at 16:00 UTC on Monday in the #atomic channel. 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.

Red Hat released Red Hat Enterprise Linux 7.4 on August 1st, 2017 (Info).  In the CentOS world, we call this type of release a 'Point Release', meaning that the major version of a distribution (in this case Red Hat Enterprise Linux 7) is getting a new point in time update set (in this case '.4').  In this specific case, there were about 700 Source packages that were updated.  On this release date, the CentOS Project team began building a point release of CentOS Linux 7, CentOS Linux 7 (1708), with this new source code from Red Hat.  Here is how we do it.

When there is a new release of RHEL 7 source code, the public release of this source code happens on the CentOS git server (git.centos.org).  We then use a published set of tools (tools) to build Source RPMs (info) from the released git source code and immediately start building the updated version of CentOS Linux.  We use a program called mock to build Binary RPM packages from the SRPMs.

At the time of this article (5:00am CDT on August 4th, 2017), we have completed building 574 of the approximately 700 SRPMs needed for our point release.  Note that this is the largest number of packages in an EL7 point release so far.

What's Next

Continuous Release Repository

Once we complete the building of the 700 SRPMs in the point release, they will start our QA process.  Once the packages have gone through enough of the QA process to ensure they are built correctly, do the normal things, and link against the proper libraries (tutorial; linking), the first set of updates that we will we release will be from our Continuous Release repository.  These binary packages will be the same packages that we will use in the next full tree and they will be available as updates in the current CR repo in the current release.  If you have opted into CR repo (explained in the above link), then after we populate and announce the release of those packages, then a normal 'yum update' will upgrade you to the new packages.

Normally the only packages that we don't release into the CR repo are the new centos-release package and the new anaconda package, and any packages associated specifically with them.  Anaconda is the installer used to create the new ISOs for install and the centos-release package has information on the new full release.  These packages, excluded from CR, will be in the new installer tree and on the new install media of the full release.

Historically, the CR repo is released between 7 and 14 days after Red Hat source code release, so we would expect CR availability between the 8th and 15th of August, 2017 for this release.

Final Release and New Install Media, CentOS Linux 7 (1708)

After the CR Repo release, the CentOS team and the QA team will continue QA testing and we will create a compilation of the newly built and released CR packages and packages still relevant from the last release into a new repository for CentOS Linux 7 (1708). Once we have a new repo, we will create and test install media. The repository and install media will then be made available on mirror.centos.org.  It will be in a directory labeled 7.4.1708.

Historically, the final release becomes available 3 to 6 weeks after the release of the source code by Red Hat.  So, we would expect our full release to happen sometime between August 22nd and  September 12th, 2017.

As I mentioned earlier, this is the largest point release yet in terms of number of packages released in the EL7 cycle to date, so it may take a few days longer for each above cycle.  Also for building this set of packages we also need something new .. the Developer Tool Set (version 6) compiler .. for some packages.  This should not be a major issue as the Software Collections Special Interest Group (SCL SIG) has a working version of that tool set already released.  A big think you to that SIG, as they have saved me a huge amount of work and time for this release.

We are pleased to announce new official Vagrant images of CentOS Linux 6.9 and CentOS Linux 7.3.1611 for x86_64, featuring updated packages to 31 July 2017 and the following changes:

  • we are again using the same kickstarts for Hyper-V and the other hypervisors
  • you can now login on the serial console (useful if networking is broken)

Known Issues

  1. The VirtualBox Guest Additions are not preinstalled; if you need them for shared folders, please install the vagrant-vbguest plugin and add the following line to your Vagrantfile:
    config.vm.synced_folder ".", "/vagrant", type: "virtualbox"

    We recommend using NFS instead of VirtualBox shared folders if possible; you can also use the vagrant-sshfs plugin, which, unlike NFS, works on all operating systems.

  2. Since the Guest Additions are missing, our images are preconfigured to use rsync for synced folders. Windows users can either use SMB for synced folders, or disable the sync directory by adding the line
    config.vm.synced_folder ".", "/vagrant", disabled: true

    to their Vagrantfile, to prevent errors on "vagrant up".

  3. Vagrant 1.8.5 is unable to create new CentOS Linux boxes due to Vagrant bug #7610
  4. Vagrant 1.8.7 is unable to download or update boxes due to Vagrant bug #7969.
  5. Vagrant 1.9.1 broke private networking, see Vagrant bug #8166
  6. Vagrant 1.9.3 doesn't work with SMB sync due to Vagrant bug #8404
  7. The vagrant-libvirt plugin is only compatible with Vagrant 1.5 to 1.8
  8. Installing open-vm-tools is not enough for enabling shared folders with Vagrant’s VMware provider. Please follow the detailed instructions in https://github.com/mvermaes/centos-vmware-tools (updated for this release).

Recommended Setup on the Host

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.

We also performed additional manual testing with Vagrant 1.9.6 on OS X 10.11.6, with VirtualBox 5.1.22.

Downloads

The official images can be downloaded from Hashicorp’s Atlas. We provide images for 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

Verifying the integrity of the images

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

If the check passed, you can use the corresponding checksum when downloading the image with Vagrant:

$ vagrant box add --checksum-type sha256 --checksum aabcfe77a08b72bacbd6f05e5f26b67983b29314ee0039d0db4c9b28b4909fcd --provider libvirt --box-version 1705.01 centos/7

Unfortunately, vagrant box update doesn't accept a --checksum argument. Since there's no binary diffing involved in updating (the download size is the same, whether you have a previous version of the box or not), you can first issue vagrant box remove centos/7 and then download the box as described above.

Feedback

If you encounter any unexpected issues with the Vagrant images, feel free to ask on the centos-devel mailing list, or via IRC, in #centos on Freenode.

Ackowledgements

We would like to warmly thank 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.

We would also like to thank the following people (listed alphabetically):

  • Graham Mainwaring, for helping with tests and validations
  • Michael Vermaes, for testing our official images, as well as for writing the detailed guide to using them with VMware Fusion Pro and VMware Workstation Pro.

One of the daily activities of the CentOS Community Lead is searching the Internet looking for new and interesting content about CentOS that we can share on the @CentOSProject Twitter account, or Facebook, Google +, or Reddit. There's quite a bit of content out there, too, since CentOS is very popular.

Unfortunately, some of the content gets unshared, based on one simple text search:

"SELinux AND disable"

That setting is indicative of one thing: the author is advocating the deactivation of SELinux, one of the most important security tools any Linux user can have. When that step is outlined, we have to pass sharing it and even recommend readers ignore such advice completely.

What is SELinux?

But why do articles feel the need to outright deactivate SELinux rather than help readers work through any problems they might have? Is SELinux that hard?

Actually, it's really not.

According to Thomas Cameron, Chief Architect for Red Hat, SELinux is a form of mandatory access control. In the past, UNIX and Linux systems have used discretionary access control, where a user will own a file, the user's group will own the file, and everyone else is considered to be other. Users have the discretion to set permissions on their own files, and Linux will not stop them, even if the new permissions might be less than secure, such as setting chmod 777 to your home directory.

"[Linux] will absolutely give you a gun, and you know where your foot is," Cameron said back in 2015 at Red Hat Summit. The situation gets even more dangerous when a user has root permissions, but that is the nature of discretionary access control.

With a mandatory access control system like SELinux in place, policies can be set and implemented by administrators that can typically prevent even the most reckless user from giving away the keys to the store. These policies are also fixed so not even root access can change it. In the example above, if a user had implemented chmod 777 on their home directory, there should be a policy in place within SELinux to prevent other users or processes from accessing that home directory.

Policies can be super fine-grained, setting access rules for anything from users, files, memory, sockets, and ports.

In distros like CentOS, there are typically two kinds of policies.

  • Targeted. Targeted processes are protected by SELinux, and everything else is unconfined.
  • MLS. Multi-level/multi-category security policies that are complex and often overkill for most organizations.

Targeted SELinux is the operational level most SELinux users are going to work with. There are two important concepts to keep in mind when working with SELinux, Cameron emphasized.

The first is labeling, where files, processes, ports, etc. are all labeled with an SELinux context. For files and directories, these labels are handled as extended attributes within the filesystem itself. For processes, ports, and the rest, labels are managed by the Linux kernel.

Within the SELinux label is a type category (along with SELinux user, role, and level categories). Those latter aspects of the label are really only useful for complex MLS policies. But for targeted policies, type enforcement is key. A process that is running a given context -- say, httpd_t --should be allowed to interact with a file that has an httpd_config_t label, for example.

Together, labeling and type enforcement form the core functionality of SELinux. This simplification of SELinux, and the wealth of useful tools in the SELinux ecosystem have made SELinux a lot more easy to manage than the old days.

So why is that when SELinux throws an error, so many tutorials and recommendations simply tell you to turn off SELinux enforcement? For Cameron, that's analogous to turning your car's radio up really loud when you hear it making a weird noise.

Instead of turning SELinux off and thus leaving your CentOS system vulnerable to any number of problems, try checking the common problems that come up when working with SELinux. These problems typically include:

  •  Mislabeling. This is the most common type of SELinux error, where something has the wrong label and it needs fixed.
  • Policy Modification. If SELinux has set a certain policy by default, based on use cases over time, you may have a specific need to change that policy slightly.
  • Policy Bugs. An outright mistake in the policy.
  • An Actual Attack. If this is the case, 'setenforce=0' would seem a very bad idea.

Don't Turn It Off!

If someone tells you not to run SELinux, this is not based on any reason other than supposed convenience or misinformation about SELinux.

The "convenience" argument would seem to be moot, given that a little investigation of SELinux errors using tools like `sealert` reveal verbose and detailed messages on what the problem is and exactly what commands are needed to get the problem solved.

Indeed, Cameron recommends that instead turning off SELinux altogether, run the process with SELinux in permissive mode temporarily and when policy violations (known as AVC denials) show up in the SELinux logs, you can either fix the boolean settings within existing policies to allow the new process to run without error. Or, if needed, build new policy modules on a test machine, move them to production machines and use `semodule - i` to install them, and set booleans based on what is learned on the test machines.

This is not 2010 anymore; SELinux on CentOS is not difficult to untangle and does not have to be pushed aside in favor of convenience anymore.

You can read more about SELinux in the CentOS wiki. Or see the SELinux coloring book, for a gentler introduction to what it is and how it works.

An updated version of CentOS Atomic Host (tree version 7.1706), is now available. CentOS Atomic Host is a lean operating system designed to run Docker containers, built from standard CentOS 7 RPMs, and tracking the component versions included in Red Hat Enterprise Linux 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. These images are available for download at cloud.centos.org. The backing ostree repo is published to mirror.centos.org.

CentOS Atomic Host includes these core component versions:

  • atomic-1.17.2-9.git2760e30.el7.x86_64
  • cloud-init-0.7.5-10.el7.centos.1.x86_64
  • docker-1.12.6-32.git88a4867.el7.centos.x86_64
  • etcd-3.1.9-1.el7.x86_64
  • flannel-0.7.1-1.el7.x86_64
  • kernel-3.10.0-514.26.2.el7.x86_64
  • kubernetes-node-1.5.2-0.7.git269f928.el7.x86_64
  • ostree-2017.5-3.el7.x86_64
  • rpm-ostree-client-2017.5-1.atomic.el7.x86_64

Containerized kubernetes-master

The downstream release of CentOS Atomic Host ships without the kubernetes-master package built into the image. Instead, you can run the master kubernetes components (apiserver, scheduler, and controller-manager) in containers, managed via systemd, using the service files and instructions on the CentOS wiki. The containers referenced in these systemd service files are built in and hosted from the CentOS Community Container Pipeline, based on Dockerfiles from the CentOS-Dockerfiles repository.

These containers have been tested with the kubernetes ansible scripts provided in the upstream contrib repository, and they work as expected, provided you first copy the service files onto your master.

Alternatively, you can install the kubernetes-master components using rpm-ostree package layering using the command: atomic host install kubernetes-master.

Upgrading

If you're running a previous version of CentOS Atomic Host, you can upgrade to the current image by running the following command:

$ sudo atomic host upgrade

Images

Vagrant

CentOS-Atomic-Host-7-Vagrant-Libvirt.box and CentOS-Atomic-Host-7-Vagrant-Virtualbox.box are Vagrant boxes for Libvirt and Virtualbox providers.

The easiest way to consume these images is via the Atlas / Vagrant Cloud setup (see https://atlas.hashicorp.com/centos/boxes/atomic-host). For example, getting the VirtualBox instance up would involve running the following two commands on a machine with vagrant installed:

$ vagrant init centos/atomic-host && vagrant up --provider virtualbox 

ISO

The installer ISO can be used via regular install methods (PXE, CD, USB image, etc.) and uses the Anaconda installer to deliver the CentOS Atomic Host. This image allows users to control the install using kickstarts and to define custom storage, networking and user accounts. This is the recommended option for getting CentOS Atomic Host onto bare metal machines, or for generating your own image sets for custom environments.

QCOW2

The CentOS-Atomic-Host-7-GenericCloud.qcow2 image is suitable for use in on-premise and local virtualized environments. We test this on OpenStack, AWS and local Libvirt installs. If your virtualization platform does not provide its own cloud-init metadata source, you can create your own NoCloud iso image.

Amazon Machine Images

Region Image ID
us-east-1 ami-70e8fd66
ap-south-1 ami-c0c4bdaf
eu-west-2 ami-dba8bebf
eu-west-1 ami-42b6593b
ap-northeast-2 ami-7b5e8015
ap-northeast-1 ami-597a9e3f
sa-east-1 ami-95aedaf9
ca-central-1 ami-473e8123
ap-southeast-1 ami-93b425f0
ap-southeast-2 ami-e1332f82
eu-central-1 ami-e95ffd86
us-east-2 ami-1690b173
us-west-1 ami-189fb178
us-west-2 ami-a52a34dc

SHA Sums

f854d6ea3fd63b887d644b1a5642607450826bbb19a5e5863b673936790fb4a4  CentOS-Atomic-Host-7.1706-GenericCloud.qcow2
9e35d7933f5f36f9615dccdde1469fcbf75d00a77b327bdeee3dbcd9fe2dd7ac  CentOS-Atomic-Host-7.1706-GenericCloud.qcow2.gz
836a27ff7f459089796ccd6cf02fcafd0d205935128acbb8f71fb87f4edb6f6e  CentOS-Atomic-Host-7.1706-GenericCloud.qcow2.xz
e15dded673f21e094ecc13d498bf9d3f8cf8653282cd1c83e5d163ce47bc5c4f  CentOS-Atomic-Host-7.1706-Installer.iso
5266a753fa12c957751b5abba68e6145711c73663905cdb30a81cd82bb906457  CentOS-Atomic-Host-7.1706-Vagrant-Libvirt.box
b85c51420de9099f8e1e93f033572f28efbd88edd9d0823c1b9bafa4216210fd  CentOS-Atomic-Host-7.1706-Vagrant-VirtualBox.box

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!

The SIG meets weekly on Thursdays at 16:00 UTC in the #centos-devel channel, and 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.

2017-07-14: We have release version 1706.02 of centos/6, which fixes a regression introduced by the "stack clash" patch (this made Java crash, just like on centos/7). The packages were all updated to 2017-07-14, and include additional fixes.

2017-07-05: We have released version 1706.02 of centos/7, providing RHBA-2017:1674-1, which fixes a regression introduced by the patch for the "stack clash" vulnerability. Existing boxes don't need to be destroyed and recreated: running sudo yum update inside the box will upgrade the kernel if needed. There is no patch for CentOS Linux 6 at this time, but we plan to provide an updated centos/6 image if such a patch is later released.

We are pleased to announce new official Vagrant images of CentOS Linux 6.9 and CentOS Linux 7.3.1611 for x86_64, featuring updated packages to 2 Juli 2017. This release also includes an updated kernel with important security fixes.

Known Issues

  1. The VirtualBox Guest Additions are not preinstalled; if you need them for shared folders, please install the vagrant-vbguest plugin and add the following line to your Vagrantfile:
    config.vm.synced_folder ".", "/vagrant", type: "virtualbox"

    We recommend using NFS instead of VirtualBox shared folders if possible; you can also use the vagrant-sshfs plugin, which, unlike NFS, works on all operating systems.

  2. Since the Guest Additions are missing, our images are preconfigured to use rsync for synced folders. Windows users can either use SMB for synced folders, or disable the sync directory by adding the line
    config.vm.synced_folder ".", "/vagrant", disabled: true

    to their Vagrantfile, to prevent errors on "vagrant up".

  3. Vagrant 1.8.5 is unable to create new CentOS Linux boxes due to Vagrant bug #7610
  4. Vagrant 1.8.7 is unable to download or update boxes due to Vagrant bug #7969.
  5. Vagrant 1.9.1 broke private networking, see Vagrant bug #8166
  6. Vagrant 1.9.3 doesn't work with SMB sync due to Vagrant bug #8404
  7. The vagrant-libvirt plugin is only compatible with Vagrant 1.5 to 1.8
  8. Installing open-vm-tools is not enough for enabling shared folders with Vagrant’s VMware provider. Please follow the detailed instructions in https://github.com/mvermaes/centos-vmware-tools (updated for this release).

Recommended Setup on the Host

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.

We also performed additional manual testing with Vagrant 1.9.6 on OS X 10.11.6, with VirtualBox 5.1.22.

Downloads

The official images can be downloaded from Hashicorp’s Atlas. We provide images for 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

Verifying the integrity of the images

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

If the check passed, you can use the corresponding checksum when downloading the image with Vagrant:

$ vagrant box add --checksum-type sha256 --checksum aabcfe77a08b72bacbd6f05e5f26b67983b29314ee0039d0db4c9b28b4909fcd --provider libvirt --box-version 1705.01 centos/7

Unfortunately, vagrant box update doesn't accept a --checksum argument. Since there's no binary diffing involved in updating (the download size is the same, whether you have a previous version of the box or not), you can first issue vagrant box remove centos/7 and then download the box as described above.

Feedback

If you encounter any unexpected issues with the Vagrant images, feel free to ask on the centos-devel mailing list, or via IRC, in #centos on Freenode.

Ackowledgements

We would like to warmly thank 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.

We would also like to thank the following people (listed alphabetically):

  • Graham Mainwaring, for helping with tests and validations
  • Michael Vermaes, for testing our official images, as well as for writing the detailed guide to using them with VMware Fusion Pro and VMware Workstation Pro.

Last week, as I mentioned in my earlier post, I was in Frankfurt, Germany, for the ISC High Performance Computing conference. The thing that grabbed my attention, more than anything else, was the Student Cluster Competition.  11 teams from around the world - mostly from Universities - were competing to create the fastest (by a variety of measures) student supercomputer. These students have progressed from earlier regional competitions, and are the world's finest young HPC experts. Just being there was an amazing accomplishment. And these young people were obviously thrilled to be there.

Each team had hardware that had been sponsored by major HPC vendors. I talked with several of the teams about this. The UPC Thunderchip team, from Barcelona Tech, (Winner of the Fan Favorite award!) said that their hardware, for example, had been donated by (among other vendors) CoolIT systems, who had donated the liquid cooling system that sat atop their rack.

(When I was in college, we had a retired 3B2 that someone had dumpster-dived for us, but I'm not bitter.)

Over the course of the week, these teams were given a variety of data challenges. Some of them, they knew ahead of time and had optimized for. Others were surprise challenges, which they had to optimize for on the fly.

While the jobs were running, the students roamed the show floor, talking with vendors, and, I'm sure, making contacts that will be beneficial in their future careers.

Now, granted, I had a bit of a ulterior motive. I was trying to find out the role that CentOS plays in this space. And, as I mentioned in my earlier post, 8 of the 11 teams were running CentOS. (One - University of Hamburg - was running Fedora. Two - NorthEast/Purdue, and Barcelona Tech - were running Ubuntu) And teams that placed first, second, and third in the competition - (First place: Tsinghua University, Beijing. Second place: Centre for High Performance Computing South Africa. Third place: Beihang University, Beijing.) - were also running CentOS. And many of the research organizations I talked to were also running CentOS on their HPC clusters.

I ended up doing interviews with just two of the teams, about their hardware, and what tests that they had to complete on them to win the contest. You can see those on my YouTube channel, HERE and HERE.

At the end, while just three teams walked away with the trophies, all of these students had an amazing opportunity. I was so impressed with their professionalism, as well as their brilliance.

And good luck to the teams who have been invited to the upcoming competition in Denver. I hope I'll be able to observe that one, too!