Today the CentOS-Project announced the immediate availability of CentOS-7 (1503), the second release of CentOS-7.
Find out more about the release announcement here: http://lists.centos.org/pipermail/centos-announce/2015-March/021006.html.
Also don’t forget to read the release notes at the wiki: http://wiki.centos.org/Manuals/ReleaseNotes/CentOS7.
Waiting for the new package set in the next CentOS-7 release ? A majority of them are now available on every CentOS-7 machine by running the following commands :
yum --enablerepo=cr list updates
Its important you run a ‘yum update’ first, since the cr repo definitions are only available in the newer centos-release rpms. Once you are happy with the new content that is going to come via the CR repos, you can apply them with :
yum --enablerepo=cr update
For more information on whats been pushed to these CR Repos, look at the announcement email at : http://lists.centos.org/pipermail/centos-announce/2015-March/020980.html
You can get more information on the CR process, the repository and the content inside it at : http://wiki.centos.org/AdditionalResources/Repositories/CR
Red Hat Enterprise Linux 7.1 was released a few days back, You can go read the release notes now. Its a great way to find out the big changes and enhancements in this release.
On the CentOS side of things, we have been working through last week on getting the sources organised and the builds started up. We are pretty close to finishing the first cycle of builds. The next step would be to get the content into QA repos so people can start poking it. From there on, content will make its way into the CR/ repos, and we will goto work on the distribution media ( ie. the ISOS, Cloud Images, containers, live media etc ). Once that is done, we have another couple of days for QA around those bits, followed by the wider release.
This release for CentOS-7 is going to be tagged 1503 to indicate month of upstream release.
In terms of a timeline, this is where things stand : We hope to start moving content into the CR repos by the 13th/14th of March. This should set us up for releasing the distro around the end of the following week 18th to 20th of March. Ofcourse, this is a projected date and might change depending on how much time and work the QA cycles take up and any challenges we hit in the distro media building stages.
Note that the CR repos contain packages that have not been through as much QA as the content at release time, so while they do give people a path to early-access to next-release rpms and content, they come with the added risk.
Some of the special interest groups in CentOS are keen to get started with the new content, and we are trying to find a way to make that work – but at this time there is no mechanism that bridges the two buildsystems ( the CentOS Distro one, and the Community Build System used by the SIGs ). So for the time being the SIGs will just need to wait a few more days before they can start their trials and builds. For the future, its something we will try and find a solution for, so in the next release SIGs can start doing their builds and testing as the distro packages are being built.
As I’d mentioned previously, the fine folks of Applied Micro were kind enough to give us an X-C1 development box to see if it was feasible to build and run CentOS Linux 7. My first attempt through, I realized I hadn’t been taking decent notes, so I scrapped most of the package work and started over. This time I took a few more notes, and hopefully I’ve documented some things that will help everyone. If you’re interested in discussing or joining the ARMv8 process, feel free to join our ARM development mailing list, or find me on Freenode’s irc network in #centos-devel (nick: Evolution ).
The official Linux architecture name for ARMv8 is aarch64. However both terms seem to be in circulation and we use them to imply the same thing.
My plan for the X-C1 box was to install Fedora, and use mock to get a decent buildroot in order. Because the X-C1 box came with a uboot based image by default, I had to replace it with uefi first. The directions for doing that can be found on Fedora’s aarch64 wiki page. Once uboot was successfully replaced with UEFI, I installed Fedora 21 and mock. I chose F21 largely because there I couldn’t find a Fedora 19 image to work from, but there are Fedora 19 packages available to help bootstrap a C7 mock chroot, which is really what I was after. I copied this repository to a local system both to not hammer the remote machine, and to reduce the latency.
While I worked on getting the roughly 150 packages needed for a basic mock buildroot built, I kept running into a recurring problem with failed tests for elfutils. Part of the elfutils test suite tests coredumps and it seems that the buildhost’s systemd-coredump utility was stealing them. After some time digging around with this, I ended up with the following commands:
# echo "kernel.core_pattern=core" > /etc/sysctl.d/50-coredump.conf
# sysctl --system
Once that was done, the elfutils build tests passed without issue.
Initially I attempted to work out a build order that would allow me to build from the ground up, but I quickly realized this was foolish. When starting from the bottom like this, everything has a build dependency on something else. Instead I chose to work toward a clean
mock init first, and then work up from that point. Since I only have one board to build against, I’m currently abusing bash and cycling things through mock directly. The idea of using koji or plague seemed a bit overkill with just one build host doing the work. Once everything has been built (or thrown out of the build) against the F19 repository, it will be time to do the build again against itself to ensure that everything is properly linked and self-hosting.
It’s worth noting that some of the packages in the F19 repository are actually tagged as F20 and are newer than what exists in CentOS Linux 7. I found it necessary to exclude these newer versions, and often to exclude other packages as the build has progressed. While not an exhaustive list, examples are:
I mentioned that a few packages have been ejected from the build outright. Some of these are because the build dependencies either aren’t, or can’t be met. The prime example of this is ADA support, which requires the same cross-compiled (or otherwise bootstrapped) ADA version to build (yay for circular dependencies). Since nothing appears to explicitly depend on the ADA packages like libgnat, for now I’ve removed them. Down the road, if I’m able to properly add support I will certainly revisit this decision.
There are a few packages from CentOS Linux 7 that I just won’t be able to use. The primary issue is the kernel. The 3.10 kernel just doesn’t have the support for aarch64 that’s needed, so my current plan is to target 3.19 as the kernel to ship for aarch64. This is still speculation, as I’ve been procrastinating on actually building it. I imagine that will happen for the next blog post update
The other problematic package is anaconda. I’m unsure if I can patch the version in 7 to support aarch64, or if I’ll need to ‘forward-port’ and use a more recent version from fedora to handle the installation. If anyone from the community has insights or suggestions for this, please speak up.
I’ll continue posting updates as the build progresses, or as I find interesting things worth mentioning.
With the growing list of easily accessible ARM hardware like the RaspBerry Pi 2 and the ODROID-C1, several community efforts have sprouted, working out the details for getting CentOS-7 built and available for the new boards. One of our UK based community members has made the most progress so far, posting his build process on the CentOS arm development list. As he progresses, he’s also been keeping some fairly detailed notes about what changes he’s had to make. Once he’s been able to produce an installable (or extractable) image, we’ll see about incorporating and maintaining his changes as branches in git. With a bit more work, we should be able to start rolling out a fully community built and supported 32bit arm build of CentOS-7.
Far from stopping there, work is underway on the 64bit ARM front as well. The fine folks at Applied Micro were kind enough to lend us two of their X-C1 ARMv8 development kits. After a bit of work to replace the default uboot with UEFI, and a few early missteps, the work on an aarch64 port of CentOS-7 is progressing along rather nicely as well. I’ll work on documenting the build system, steps to duplicate for anyone who has the hardware and wants to participate, and potential changes required.
The FreeIPA community is looking for your help and feedback!
The FreeIPA development team is excited to share with you a new version of the FreeIPA server 4.1.2 running in a container on top of CentOS. It is the first time a FreeIPA upstream release is available in the CentOS docker index. It is a preview of the features that will eventually make their way in the main CentOS distribution. This version of FreeIPA showcases multiple new major features as well as improvements to existing components above what is currently available in CentOS 7.0
In order to use this docker container, please run
docker pull centos/freeipa
Then follow the guide/documentation available at https://registry.hub.docker.com/u/centos/freeipa/
These features include:
– Backup and Restore
Ability to backup server data and restore an instance in the case of disaster
– CA Certificate Management Utility
A tool to change IPA chaining or rotate the CA certificate on already installed server
– ID Views
Ability to store POSIX data and SSH keys in IPA for users belonging to a trusted Active Directory domain. Alternative POSIX data and SSH keys can also be stored for regular IPA users making it possible to serve different POSIX data to different clients (requires SSSD 1.12.3 or later). This is useful in migration scenarios where consolidation of multiple identity stores (local files, NIS domains, legacy LDAP servers, ..) with duplicated identities and inconsistent POSIX attributes needs to be retained for some clients.
Note: The solution requires the latest SSSD bits availble the Copr REPO. https://copr.fedoraproject.org/coprs/mkosek/freeipa/
With this version we are introducing for the first time the ability to manage DNSSEC signatures on DNS data. This feature will be available in the community version only and would not be included into CentOS 7.1.
There are also significant improvements in UI, permissions, keytab management, automatic membership and SUDO rules handling.
More information can be found here:
The biggest and the most interesting feature of FreeIPA 4.1.2 is support for the two factor authentication using HOTP/TOTP compatible software tokens like FreeOTP (open source compatible alternative to Google Authenticator) and hardware tokens like Yubikeys. This feature allows Kerberos and LDAP clients of a FreeIPA server to authenticate using the normal account password as the first factor and an OTP
token as a second factor. For those environments where a 2FA solution is already in place, FreeIPA can act as a proxy via RADIUS. More about this feature can be read here.
If you want to see this feature in CentOS 7.1 proper we need your help!
Please give it a try and provide feedback. We really, really need it!
Please use email@example.com if you have any questions.
If you notice any issues or want to file an RFE you can do it here:
https://fedorahosted.org/freeipa/ (requires a Fedora account).
You can also find us on irc.freenode.net on #freeipa.
The CentOS Project is pleased to announce four new Docker images in the CentOS Container Set, providing popular, ready to use containerized applications and services. Today you can grab containers with MariaDB, Nginx, FreeIPA, and the Apache HTTP Server straight from the Docker Hub.
The new containers are based on CentOS 7, and are tailored to provide just the right set of packages to provide MariaDB, Nginx, FreeIPA, or The Apache HTTP Server right out of the box.
The first set of applications and services provide two of the world’s most popular Web servers, MariaDB for your database needs, and FreeIPA to provide an integrated security information management solution.
The CentOS Container Set is an effort to leverage the CentOS Project to give developers and admins the building blocks to easily set up containerized services in their environment. Keep an eye on the CentOS blog for further releases, or help us as we continue to develop more!
To get started with one of the images, use: `docker pull centos/<app>` where <app> is the name of the container (*e.g.* `docker pull centos/mariadb`). You can find some quick “getting started” info on the Docker Hub page for each application.
Jason Brooks has written up a longer howto for FreeIPA that details how to build the container (which is already done here, but you can rebuild the images if you like using the Dockerfiles on GitHub), and how to set it up to use FreeIPA with an application.
We have a larger set of Dockerfiles (derived initially from the Fedora Dockerfiles) set that we’re working on to develop pre-made CentOS Docker containers for easy use. Join the centos-devel mailing list to ask questions about the containers, or to provide feedback on their use. We also accept pull requests if you have any fixes or new Dockerfiles to contribute!
We will have speakers in the morning, starting at 10:00 am local time and a hackfest beginning at 1:00pm.
EDIT (Monday July 28, 2014 – 2010 UTC):
We now have what we think is going to be the final version of this upgrade tool. Please see the following link to test:
We now have some Beta Testing RPMs available to test upgrades from CentOS-6 to CentOS-7. These tests were announced on the CentOS-Devel mailing list here:
Since the release of the test RPMs, we have had several patches created by Manuel Mausz. Manuel’s patches have done a lot to make the Preupgrade Assistant work for upgrades. We now need to get some tests of the patched RPMs.
The new RPMs are available from the Testing Repo here:
The upstream documentation for performing upgrades, as it currently exists, is here:
The CentOS team would like to very much thank Manuel for his testing work and patches for Preupgrade Assistant. This is an example of how we are now doing things in the “New” CentOS Project … where the community is now involved in all aspects of what we do except the actual building of the upstream sources for the actual distro.
Other things we need from the community for this process:
The SRPMs for these packages are here:
The sources are also available from git.centos.org:
And the specific packages are:
Please test and document these packages and the process, and submit any required code changes to the CentOS-Devel mailing list. If you need wiki.centos.org edit capability to create/update docs for the process, ask on the CentOS-Docs mailing list.
Note: The state of this software is to be considered Beta at best … do NOT try to use it on ANYTHING even slightly important.
EDIT: New packages are now pushed based on the changes from this mail:
Please run preupg with "-s CentOS6_7".
The Linux kernel before 3.15.4 on Intel processors does not properly restrict use of a non-canonical value for the saved RIP address in the case of a system call that does not use IRET, which allows local users to leverage a race condition and gain privileges, or cause a denial of service (double fault), via a crafted application that makes ptrace and fork system calls.
This issue affects CentOS-6 and -7 kernels. An updtream fix has now been applied to the CenOSPlus kernels.