There is an upgrade tool that allows for in-place upgrades from CentOS Linux 6 to CentOS Linux 7.  This tool is Community Maintained, and information is available on the CentOS Wiki and on the CentOS Mailing List.

We currently do not have anyone from the Community maintaining the package, and in its current state it no longer works.

We really need someone from the CentOS Community to step up and maintain this Upgrade Tool, or we are going to have to remove it from the downloads area, since in it current state it can break people's machines if they try to use it.

If anyone would like to maintain the Upgrade Tool, please reply to the thread on the general CentOS Mailing List. (or you can contact me directly at johnny AT centos DOT org

 

The CentOS Atomic SIG has released an updated version of CentOS Atomic Host (7.1710), a lean 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.

This release includes an updated version of rpm-ostree that allows for more flexibility when using rpm-ostree's package layering features.

CentOS Atomic Host includes these core component versions:

  • atomic-1.19.1-5.git48c224b.el7.centos.x86_64
  • cloud-init-0.7.9-9.el7.centos.2.x86_64
  • docker-1.12.6-61.git85d7426.el7.centos.x86_64
  • etcd-3.2.7-1.el7.x86_64
  • flannel-0.7.1-2.el7.x86_64
  • kernel-3.10.0-693.5.2.el7.x86_64
  • kubernetes-node-1.5.2-0.7.git269f928.el7.x86_64
  • ostree-2017.11-1.el7.x86_64
  • rpm-ostree-client-2017.9-1.atomic.el7.x86_64

Package Layering with rpm-ostree

Using rpm-ostree package layering, it is possible to dynamically add more packages onto the system that are not part of the commit composed on the server. These additional "layered" packages are persistent across upgrades, rebases, and deploys. If a package you wish to layer conflicts with a package already in the atomic host image, a set of recently-added "override" commands can help resolve the conflict.

For instance, the "origin-clients" package can be used to quickly stand up an OpenShift Origin install using the command oc cluster up, but this package conflicts with the "kubernetes-client" package that comes baked into the CentOS Atomic Host image. You can use package layering to configure the repository containing the "origin-clients" rpm, to remove the conflicting kubernetes packages, and to install "origin-clients."

# rpm-ostree install centos-release-openshift-origin36
# rpm-ostree ex livefs
# rpm-ostree ex override remove kubernetes-client kubernetes-node
# rpm-ostree install origin-clients -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:

# 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 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.

I am pleased to announce that YUM 4, based on DNF technology, is available for testing on CentOS Linux 7/x86_64. Our limited testing indicates no major problems, but I would love to find out how it fits into your existing YUM 3 workflows. So please consider filling out the short survey - your feedback helps us all get better.

YUM 4 provides significant improvements such as fast dependency resolution and a stable, documented API. See the references below for detailed improvements. We have made every effort to preserve the existing end-user experience that is available with YUM 3. This is the primary reason for making YUM 4 available for testing now.

“So, what all has changed?”

The documentation does a great job explaining the differences in great detail. In short, your existing experience using yum to install, remove, and update are identical. However, there are changes such as some of the plugins and yum utilities are now consolidated into `dnf-plugins-core`. Some of the yum CLI options changed and are either converted for you automatically or silently ignored when that behavior is automatically included. Existing custom plugins written for YUM 3 will not work with YUM 4. Please reference the DNF API Reference and Changes in DNF hook API compared to YUM 3 links for further information.

“I found a bug, what should I do?”

Please report any found bugs on Red Hat Bugzilla against Fedora/dnf component (make sure to mention versions and that you use package from CentOS).

And remember to submit feedback in the short survey.

“Three step install, get started right away”

  1. # yum install centos-release-yum4
  2. # yum --enablerepo=centos-yum4-testing install yum4
  3. # yum4 --enablerepo=centos-yum4-testing install dnf-plugins-core

“I used DNF from EPEL, how do I move from it?”

Similar to clean installation: enable repository and update. YUM 4 is based on a newer version of DNF and should update properly.

  1. # yum install centos-release-yum4
  2. # yum --enablerepo=centos-yum4-testing update

NOTE: packages in testing repositories are not signed.

Many thanks to the CentOS Project team for their assistance in making this happen!

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 28 October 2017 and the centos/7 images no longer include the package documentation installed by default, reducing the image size by around 70MB (you can reinstall the packages whose documentation you need).

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.30.

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 1710.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.

Once again we'll be holding our annual CentOS Dojo in Brussels, the day before FOSDEM. The event will be held at the same venue as last year - at the Marriott Grand Place - and will run from 9am until 5pm. After 5, we'll join the traditional FOSDEM party at Delirium.

The CFP for this event is now open. Please submit proposals on any topic related to CentOS development or community. We particularly request talks on the following topics:

  • Progress of a particular CentOS SIG
  • Case study: Your infrastructure, powered by CentOS
  • CentOS on altarch
  • Cloud computing on CentOS
  • CentOS DevOps
  • CentOS Containers

You can also look at last year's schedule for inspiration.

We've extended the CFP deadline to December 1st in order to give you time to get your proposals in.

More details about the event will be posted in the wiki as they become available. Please contact Rich, or ask on the centos-devel mailing list, if you have any questions.

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.