July 9th, 2012 - Today the CentOS Project has released CentOS-6.3. This release came 18 days after the upstream release of EL 6.3. The major issues that we had with getting this release out were getting the i386 distribution to boot properly and adjusting the content of DVD-1 and DVD-2 of each architecture to allow for the most common install groups to come from DVD1 and not require DVD2.
Some of the major changes for this release include a move from OpenOffice 3.2.1 to LibreOffice 3.4.5 and the addition of Virtual to Virtual and Physical to Virtual (virt-v2v and virt-p2v) server migration tools to KVM Virtual Machines. Please see the CentOS-6.3 release notes for more information on these and other features. The Open H Website has a very good article on what's new in EL6.
We were pretty much ready to release the distribution by Friday, July 6th, but we had to then copy our trees to the several dozen internal mirror servers in the CentOS Project's infrastructure and then open those mirrors up to the more than 500 external mirrors that serve CentOS in more than 75 countries world wide. While the CentOS Project is doing a point release, you can see what is happen by visiting our QA Development website and looking at the blog entries on the dashboard,
We hope you enjoy CentOS-6.3 !
Monday, July 9, 2012
Thursday, June 7, 2012
CentOS Project Release Times
One of the issues we have had in the CentOS Project is that at point release time, we were lagging behind a bit on getting the releases out. Recently, the CentOS Project has addressed this issue in 3 major ways:
1. We created the CR repository where we can, if there are delays, push out multiple updates that work together while we take a care of problems with packages that don't build, if we have issues getting the ISOs to properly build, etc. during the point release process. This gives us an avenue to release pieces of the point release without having to release the whole thing. We have actually not had to use the CR repository on the last 2 release cycles (CentOS-5.8 and CentOS-6.2) as we got each of them out within 10 days... however, this is an option that we have if we need to get out pieces of the release (like critical updates) if there is any kind of delay in the main process.
2. We now have corporate sponsors who sponsor 2 CentOS Developers to work on the CentOS Project full time. That means that we now have 80 paid hours per week of CentOS Project time where we get do nothing but CentOS Project related work. The sponsors do not ask for anything in return, just faster CentOS updates by the current CentOS developers who get to make the CentOS Project their daily work priority. This should be huge in preventing future delays.
3. We have given better tools to the CentOS QA team. They now see the packages that we are building in the QA IRC channel, the status of the builds on the QA mailing list and we have a scratch build area setup where they can do test builds to help us develop patches for issues, etc. We have also been using trello for collaboration during point release time to get updates out faster.
The end result of all of these efforts have shown that we can get packages out in a timely manner. Since January 2012, there have been no updates (outside of point releases) that have taken more than 3 days to push. In fact, only one package during the entire time has taken more than one day to get released. As I mentioned before, the last two point releases were also completed very quickly. Here is some press on that:
5.8 Release
6.2 Release
The bottom line is that the CentOS Project has expended great effort to ensure that point releases of current products will be released in a timely fashion. With the changes we have put in place and with the ability to do CentOS as our main daily work focus the future looks quite good for timely CentOS updates.
1. We created the CR repository where we can, if there are delays, push out multiple updates that work together while we take a care of problems with packages that don't build, if we have issues getting the ISOs to properly build, etc. during the point release process. This gives us an avenue to release pieces of the point release without having to release the whole thing. We have actually not had to use the CR repository on the last 2 release cycles (CentOS-5.8 and CentOS-6.2) as we got each of them out within 10 days... however, this is an option that we have if we need to get out pieces of the release (like critical updates) if there is any kind of delay in the main process.
2. We now have corporate sponsors who sponsor 2 CentOS Developers to work on the CentOS Project full time. That means that we now have 80 paid hours per week of CentOS Project time where we get do nothing but CentOS Project related work. The sponsors do not ask for anything in return, just faster CentOS updates by the current CentOS developers who get to make the CentOS Project their daily work priority. This should be huge in preventing future delays.
3. We have given better tools to the CentOS QA team. They now see the packages that we are building in the QA IRC channel, the status of the builds on the QA mailing list and we have a scratch build area setup where they can do test builds to help us develop patches for issues, etc. We have also been using trello for collaboration during point release time to get updates out faster.
The end result of all of these efforts have shown that we can get packages out in a timely manner. Since January 2012, there have been no updates (outside of point releases) that have taken more than 3 days to push. In fact, only one package during the entire time has taken more than one day to get released. As I mentioned before, the last two point releases were also completed very quickly. Here is some press on that:
5.8 Release
6.2 Release
The bottom line is that the CentOS Project has expended great effort to ensure that point releases of current products will be released in a timely fashion. With the changes we have put in place and with the ability to do CentOS as our main daily work focus the future looks quite good for timely CentOS updates.
Monday, January 30, 2012
DRBD 8.3.12 for CentOS-5 in testing
The ELRepo Project has DRBD packages for CentOS-5 and CentOS-6, named drbd83-utils or drbd84-utils. The CentOS Project does not want to maintain extra packages that exist in other places unless we need to change them ... so we are not going to create DRBD packages for CentOS-6.
Since CentOS-4 is being EOL'ed in less than a month, we are also not going to publish updates for the DRBD in CentOS-4.
This leaves the DRBD for CentOS-5 that are part of CentOS Extras. Since these have been released for CentOS-5, we will continue to maintain the DRBD version 8.3.x tree (drbd83) in CentOS Extras.
A new version of DRBD 8.3 (drbd83-8.3.12) has been released to the testing repository for CentOS-5. You can see the details here:
DRBD 8.3.12 for CentOS-5
If you want to use DRBD 8.4.x for CentOS-5, rather than releasing it separately, the CentOS Project recommends that you use drbd84-utils from ELRepo (linked above).
For users who want to use the drbd83-8.3.12 version ... please test the version that is currently in CentOS Testing and provide feedback. With enough feedback I will move the packages from testing to CentOS Extras.
NOTE: These packages have now been moved to CentOS Extras and can be installed normally with yum.
Since CentOS-4 is being EOL'ed in less than a month, we are also not going to publish updates for the DRBD in CentOS-4.
This leaves the DRBD for CentOS-5 that are part of CentOS Extras. Since these have been released for CentOS-5, we will continue to maintain the DRBD version 8.3.x tree (drbd83) in CentOS Extras.
A new version of DRBD 8.3 (drbd83-8.3.12) has been released to the testing repository for CentOS-5. You can see the details here:
DRBD 8.3.12 for CentOS-5
If you want to use DRBD 8.4.x for CentOS-5, rather than releasing it separately, the CentOS Project recommends that you use drbd84-utils from ELRepo (linked above).
For users who want to use the drbd83-8.3.12 version ... please test the version that is currently in CentOS Testing and provide feedback. With enough feedback I will move the packages from testing to CentOS Extras.
NOTE: These packages have now been moved to CentOS Extras and can be installed normally with yum.
Tuesday, January 3, 2012
CentOS in 2012
The first thing I want to do is congratulate Karanbir and Tasha on the birth of their new baby girl Millie. She is the quite cute ... hello Millie :)
The CentOS Project has spent much time and effort into getting a new build system in place for CentOS 6 that can generate good and timely builds, as well as inform us of newly released upstream SRPMS and keep the CentOS QA team informed when we build any new packages.
The release of CentOS-6.2 on 12/20/2011, in less than 2 weeks and at the same time as Oracle's OEL as noted on Distrowatch, is where we would like to have all our future releases be. I think that we should see the standard 2-4 week time frame for point releases and within 24 hours for updates now that we have this new build system in place.
We have also put a Continuous Release (CR) repository in place for both CentOS 5 and CentOS 6. This repository can be installed via the simple command:
yum install centos-release-cr
The purpose of the CR repository is to allow the CentOS Project to push some of the security updates if we are having issues with a point release build (like we did with both CentOS-6.0 and CentOS-6.1). If we are not going to meet the 2-4 week goal for our point release, we will push out the packages we have gotten to build properly while continuing to work on the problem packages. This repository is totally optional and was not needed with CentOS-6.2, but we recommend it be installed if you want to get your security updates as fast as possible.
Karanbir gets the credit for the new build system, called reimzul. It uses beanstalkd work queues and allows adding new builders to process the work as required.
The build system has the flexibility to allow us to import SRPMS into a git repo for packages we want to change, generate a new SRPM after edits for those packages, and submit those modified SRPMS into the work queues. It also allows for the submission of non-modified SRPMS directly without the need to import them into git. It automates several things that we have done in the past by hand (automatically knowing which packages are not built by CentOS (for example the RHN packages that deal with upstream subscriptions) and automatically copies multilib 32bit packages into the 64 bit tree. The system also reliably produces the Yum-Presto DeltaRPMS and metadata for minimizing download times for updates.
We do need to announce that CentOS-4 will be reaching the End Of Life at the end of February 2012. That means that there will be no more CentOS-4 updates after March 1st, 2012. If you are still using CentOS-4, you need to upgrade to CentOS-5 or CentOS-6 or switch to Red Hat's paid Extended Update Support for EL4 to continue to get updates. Please see the CentOS-4 EOL announcement for more details.
So, news on the CentOS front for 2012 is very promising and we are looking forward to great things in the new year.
The CentOS Project has spent much time and effort into getting a new build system in place for CentOS 6 that can generate good and timely builds, as well as inform us of newly released upstream SRPMS and keep the CentOS QA team informed when we build any new packages.
The release of CentOS-6.2 on 12/20/2011, in less than 2 weeks and at the same time as Oracle's OEL as noted on Distrowatch, is where we would like to have all our future releases be. I think that we should see the standard 2-4 week time frame for point releases and within 24 hours for updates now that we have this new build system in place.
We have also put a Continuous Release (CR) repository in place for both CentOS 5 and CentOS 6. This repository can be installed via the simple command:
yum install centos-release-cr
The purpose of the CR repository is to allow the CentOS Project to push some of the security updates if we are having issues with a point release build (like we did with both CentOS-6.0 and CentOS-6.1). If we are not going to meet the 2-4 week goal for our point release, we will push out the packages we have gotten to build properly while continuing to work on the problem packages. This repository is totally optional and was not needed with CentOS-6.2, but we recommend it be installed if you want to get your security updates as fast as possible.
Karanbir gets the credit for the new build system, called reimzul. It uses beanstalkd work queues and allows adding new builders to process the work as required.
The build system has the flexibility to allow us to import SRPMS into a git repo for packages we want to change, generate a new SRPM after edits for those packages, and submit those modified SRPMS into the work queues. It also allows for the submission of non-modified SRPMS directly without the need to import them into git. It automates several things that we have done in the past by hand (automatically knowing which packages are not built by CentOS (for example the RHN packages that deal with upstream subscriptions) and automatically copies multilib 32bit packages into the 64 bit tree. The system also reliably produces the Yum-Presto DeltaRPMS and metadata for minimizing download times for updates.
We do need to announce that CentOS-4 will be reaching the End Of Life at the end of February 2012. That means that there will be no more CentOS-4 updates after March 1st, 2012. If you are still using CentOS-4, you need to upgrade to CentOS-5 or CentOS-6 or switch to Red Hat's paid Extended Update Support for EL4 to continue to get updates. Please see the CentOS-4 EOL announcement for more details.
So, news on the CentOS front for 2012 is very promising and we are looking forward to great things in the new year.
Tuesday, March 8, 2011
How the new Kernel SRPM distribution impacts CentOS
There seem to be many different articles concerning how Red Hat has chosen to distribute its Kernel Source Code (SRPM) in Red Hat Enterprise Linux. Here are a just a few of them:
Red Hat Fights Back
Why RHEL 6 Keeps Its Patches Under Its Hat
Is Red Hat violating the GPL?
Red Hat's "obfuscated" kernel source
Red Hat has also responded in a couple of places, here are a few of those:
Commitment to Open
Red Hat: 'Yes, we undercut Oracle with hidden Linux patches
The first thing I want to make perfectly clear is that this blog post is MY OPINION and it is not an official statement of or by the CentOS Project.
Now that we have that out of the way, the first issue I want to address is the suggestion by ITWire that Red Hat is somehow violating the GPL by distributing their source package with the patches already rolled in. They are not, most companies distribute their source packages as tarballs with all the patches already rolled in. Some companies (but not all) also provide all the Software Change Management (SCM) commits in a public place (like a SVN, GIT or CVS repository). This is not required. What is required is what Red Hat is doing, providing the source code to their customers.
The other thing the ITWire article does is that they have a link to a Red Hat "Terms of Service" for their websites and portals along with the claim that the this is a restriction on the Red Hat customers ability to distribute software. The only problem is, the link ITWire pointed to says that software is controlled by a different agreement altogether. The above link is for Use of Content, while Red Hat Enterprise Linux software is actually governed by the EULA link here. If you look at that EULA, you can distribute the software per the license of each package as long as you meet the trademark and logo requirements. Nothing new to see here, software distributing same as before, no GPL violations, no problems.
The other question that people seem to have is will the new method of the kernel delivery somehow impact CentOS and its ability to get the releases out. It should have no impact on the main CentOS distribution at all. We have built the EL6 kernels for testing and there is no impact. Where there will be a slight impact is the CentOS Plus kernel (which is something CentOS provides as added functionality). The CentOS plus kernel sometimes adds patches to fix problems that are delayed in upstream engineering or things they choose not to fix in architectures that they do not support. These kind of changes will be harder to make because some of these patches normally need to be done in a specific order to get them to apply in the most efficient manner. Or we might want to back out a specific patch and replace it with a different one. These kind of things will now be much harder. Instead of backing out the patch, we will need to modify the patch to fit OVER the already rolled in source code from Red Hat. It will take longer, or we may not even offer this service for CentOS-6.
I certainly understand why Red Hat is taking the action they are taking, it is fully GPL compatible, and it should have minimal impact on the main CentOS distribution. The CentOS Project wants (and needs) Red Hat to continue to be the premiere paid Enterprise Linux distribution for the United States and the rest of the world. I personally would rather Red Hat did not deliver their kernel this way, but it does not seem to be a major issue to me. Which is why it seemed to take 4 months before many people even noticed.
Red Hat Fights Back
Why RHEL 6 Keeps Its Patches Under Its Hat
Is Red Hat violating the GPL?
Red Hat's "obfuscated" kernel source
Red Hat has also responded in a couple of places, here are a few of those:
Commitment to Open
Red Hat: 'Yes, we undercut Oracle with hidden Linux patches
The first thing I want to make perfectly clear is that this blog post is MY OPINION and it is not an official statement of or by the CentOS Project.
Now that we have that out of the way, the first issue I want to address is the suggestion by ITWire that Red Hat is somehow violating the GPL by distributing their source package with the patches already rolled in. They are not, most companies distribute their source packages as tarballs with all the patches already rolled in. Some companies (but not all) also provide all the Software Change Management (SCM) commits in a public place (like a SVN, GIT or CVS repository). This is not required. What is required is what Red Hat is doing, providing the source code to their customers.
The other thing the ITWire article does is that they have a link to a Red Hat "Terms of Service" for their websites and portals along with the claim that the this is a restriction on the Red Hat customers ability to distribute software. The only problem is, the link ITWire pointed to says that software is controlled by a different agreement altogether. The above link is for Use of Content, while Red Hat Enterprise Linux software is actually governed by the EULA link here. If you look at that EULA, you can distribute the software per the license of each package as long as you meet the trademark and logo requirements. Nothing new to see here, software distributing same as before, no GPL violations, no problems.
The other question that people seem to have is will the new method of the kernel delivery somehow impact CentOS and its ability to get the releases out. It should have no impact on the main CentOS distribution at all. We have built the EL6 kernels for testing and there is no impact. Where there will be a slight impact is the CentOS Plus kernel (which is something CentOS provides as added functionality). The CentOS plus kernel sometimes adds patches to fix problems that are delayed in upstream engineering or things they choose not to fix in architectures that they do not support. These kind of changes will be harder to make because some of these patches normally need to be done in a specific order to get them to apply in the most efficient manner. Or we might want to back out a specific patch and replace it with a different one. These kind of things will now be much harder. Instead of backing out the patch, we will need to modify the patch to fit OVER the already rolled in source code from Red Hat. It will take longer, or we may not even offer this service for CentOS-6.
I certainly understand why Red Hat is taking the action they are taking, it is fully GPL compatible, and it should have minimal impact on the main CentOS distribution. The CentOS Project wants (and needs) Red Hat to continue to be the premiere paid Enterprise Linux distribution for the United States and the rest of the world. I personally would rather Red Hat did not deliver their kernel this way, but it does not seem to be a major issue to me. Which is why it seemed to take 4 months before many people even noticed.
Friday, October 2, 2009
CPanel Conference 09
Looks like I might be able to work out all the last minute details and make it to the CPanel Conference 09 in Houston, Texas next week (5th, 6th and 7th of October, 2009).
Karanbir and his wife are flying over from London to make the event. We are also possibly going to have some kind of CentOS social event or meeting on the October 8th, so if you are in Houston and might like to do something like that then contact me or Karanbir on IRC (freenode, #centos-social) or e-mail.
I am really looking forward to seeing Karanbir in person for the first time and meeting his wife. I am also looking forward to meeting Garry Dale, who is helping at the event and pretty much put most of this together.
Heck, I might even get a haircut and trim up the beard for this :D
Wednesday, September 2, 2009
i586 installs for CentOS 4.8
The CentOS 4.8 i386 install media has an option for the older i586 processors, as well as the normal i686 installer. The only problem is that the i586 kernels are broken on the released install media for CentOS 4.8.
If you need i586 install media, you can download them from here.
Since the upstream product on which CentOS is based does not support i586, we decided to fix the issues and release an i586 installer separately so as not to impact the already released products. One of the main reasons we do not want to change the OS directory to be different than the released ISOs is that we know some people use jigdo (and probably other things) to create installable media from the mirror trees instead of downloading both the trees and the DVD, etc.
Because of the need to keep the OS directory for 4.8 the same as the original install media, if you want to use the new i586 media to do a network install, you will need to create your own tree and publish it (you can mount and publish the i586 install DVD for this), or you can install from:
http://i586.centos.org/centos/4/os/i386/
If you need i586 install media, you can download them from here.
Since the upstream product on which CentOS is based does not support i586, we decided to fix the issues and release an i586 installer separately so as not to impact the already released products. One of the main reasons we do not want to change the OS directory to be different than the released ISOs is that we know some people use jigdo (and probably other things) to create installable media from the mirror trees instead of downloading both the trees and the DVD, etc.
Because of the need to keep the OS directory for 4.8 the same as the original install media, if you want to use the new i586 media to do a network install, you will need to create your own tree and publish it (you can mount and publish the i586 install DVD for this), or you can install from:
http://i586.centos.org/centos/4/os/i386/
Subscribe to:
Posts (Atom)