Yesterday we held our first - hopefully of many - dojo at CERN. We had around 70 people in attendance, representing many organizations and nations. And we had presentations from many different projects within the CentOS ecosystem.

If you're not familiar with CentOS Dojos, you can read more about them here: https://wiki.centos.org/Events/Dojo/

And if you're not familiar with CERN, you can read about it on Wikipedia, or on CERN's own website.

The dojo was in two parts.

On Thursday, a small group of CentOS SIG leaders and board members gathered to discuss plans for tackling some of the challenges in the CentOS project. You can read more about what was discussed on the centos-devel mailing list.

On Friday, we had the main event, with presentations from the CentOS board, SIG leaders, and organizations using CentOS. This included a presentation from CERN on their use of CentOS, Ceph, and OpenStack to process the data from the LHC - The Large Hadron Collider - as they analyze the nature of subatomic particles, and of the world.

We were very pleased with the day, and intend to do more event in the future, both at CERN, and at other organizations. If you're interested in hosting a dojo at your organization, get in touch with Rich Bowen to get started. Also, watch this site for a blog post about what's involved in running a dojo.

For more about what happened at the dojo, see Rich's blog posts. Also, watch this space for video and slides from the event.

 

Next week, we're holding a Dojo at CERN, in Meyrin, Switzerland. This will feature content from various of our Special Interest Groups (SIGs), and an overview of how CERN is using CentOS in their work to unravel the secrets of the universe.

We still have a little space, if you are interested in coming. You can find out more details about the event, and register, at http://cern.ch/centos

In the weeks following the event, video of the presentations, will be appearing here. Follow us on Twitter (@CentOSProject) to find out when they're posted.

Meanwhile, we're also planning a Dojo in Brussels, on the Friday before FOSDEM, as we've been doing this for a number of years now. The CFP is now open, if you're interested in presenting. We're looking for any talks about work that you're doing on CentOS, or anything that you're doing using CentOS. The CFP closes October 30th.

The goal of CentOS Container Pipeline project is to let any open-source project build container images on the CentOS Linux and additionally provide them with:

  • Dockerfile lint report
  • Container scanner reports that:
    • Scan the image for RPM updates
    • Scan the image’s RUN label for capabilities that resulting container might have when started
    • Scan the image to verify installed RPM packages
    • Scan the image for possible updates to third party packages installed via npm, pip or gem
  • Cause of build whenever an image is built/rebuilt.

In this article we’d like to summarize the features provided by the Pipeline and current state of the project. To get an idea of container images already available via registry.centos.org, please check the wiki page of Container Pipeline.

How does the CentOS Container Pipeline work?

Let’s say you have an open-source project that you’d like to containerize on CentOS platform. The source code is hosted on one of the various web-based Git version control repositories like GitHub, Bitbucket, GitLab, etc accessible over the Internet. You have a Dockerfile that uses CentOS base image to build the container (we can help you here if your existing Dockerfile is based on Alpine, Debian, Ubuntu, etc.)

Now all you need to do is create cccp.yml file in the repo at same location as your Dockerfile and open a pull request on CentOS/container-index repository to get started (more on the yaml file and how to open PR later in the post.) The generated container image can then be pulled via:

$ docker pull registry.centos.org/<app-id>/<job-id>:<desired_tag>

The cccp.yml or cccp.yaml, that’s required in your Git repository, must contain value for job-id at the very least. This is generally the name of the image like httpd for an Apache web server image or nginx for an NGINX image, so on and so forth.

 

For the pull request to be opened on CentOS/container-index, you’ll need to:

  • Fork the repository under your GitHub username
  • Clone it onto your system
  • Add a yml entry under `index.d` directory. Name of this yml file is recommended to be same as appid that you want in the aforementioned `docker pull` command.
  • Contents of this yaml file should be like the example below:
    Projects
        - id: 1
          app-id: centos
          job-id: centos
          git-url: https://github.com/CentOS/sig-cloud-instance-images
          git-branch: CentOS-7
          git-path: docker
          target-file: Dockerfile
          desired-tag: latest
          notify-email: you@example.com
          depends-on: null

    id should be an integer and shouldn’t repeat in the yml file.
    app-id is the namespace of your container images. This should be same as filename
    job-id is the name you want for your container image
    git-url is the complete URL to your Git repo
    git-branch is the branch within your repo. Default is `master`
    target-file is the name of Dockerfile to be used to build container image
    desired-tag is the tag you’d like to apply to resulting container image
    notify-email is the email address you’d like to be notified upon
    depends-on is the container image that your resulting image is dependent on. Generally the one used in FROM statement in Dockerfile. Image mentioned here must exist in the container-index.

    For more info on the yml file, we recommend you refer its dedicated section in README. For more examples on writing the yml file, we recommend you refer the index.d directory which contains yml files for various open-source projects as well as individual users.

Once the pull request is merged, Container Pipeline Service hosted on CentOS infrastructure picks it up and lints the Dockerfile, builds the container image, tests it, scans it using various atomic scanners and sends the result of these processes to email address you mentioned as `notify-email`. If it detects any issue at any of the above stages, it’ll stop right there and send you an email along with logs.

Once the image is built for the first time, every time you push a change to the Git repository’s (`git-url` variable) branch being tracked via the container-index (`git-branch` variable), a new image is built and lint-build-test-scan processes are re-executed. This provides the developer with a feedback on the changes (s)he pushed.

Weekly image scanning, RPM tracking and parent image update

Besides the one-time image scanning that happens when the image is built for the first time, CentOS Container Pipeline service does a weekly scanning and sends the results to the developer. This email only contains the information generated by the atomic scanners, albeit from a fresh run.

The Pipeline service also tracks the RPM repositories enabled in the container image. It checks these repositories once everyday to find if there’s any update available from any of the repos. If it finds an update, the container images which have those repositories enabled, will be re-built and re-scanned.

If the parent image of the project (`depends-on` variable) is updated, the child image automatically gets re-built and re-scanned.

Work in Progress features

Besides the features mentioned above, we are working on providing the ability to build images for aarch64 architecture.

We are also working on saving data-points that will store state of the Pipeline to database and help us churn useful metrics out of it. One thing where we'll be able to use it is to generate a real-time view of the build process.

Feature to let user know what is the current status of their build.

We are working on providing a brief summary of errors/warnings that scanners found in the container image.

Known issues

There are a few issues we’re working on right now and hope to get them fixed soon

  • Monitoring the overall service is in its nascent stages and we need to improve it to know of an issue before the users point them towards it. We use Sentry for monitoring the Pipeline service
  • Although we have a UI for the registry at https://registry.centos.org/, we need to tweak it to be more useful for the end-user to:
    • Have a quick look at the Dockerfile used to build the image
    • Access the logs for historic builds
  • RPM tracking issues wherein a project removed/updated from CentOS/container-index doesn’t get deleted/modified in the underlying database and hence triggers rebuild for incorrect image when it finds any of the various enabled repositories updated.

Have questions or suggestions?

We are always looking forward to community participation and community feedback. The project is open-source from day one. If you have any queries around how to get started or, why certain things works in certain way or, you would like to see a feature or, anything else, feel free to ping us on #centos-devel IRC channel on Freenode network.

Dharmit Shah ( dharmit on irc )

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.