On 7 Dec 2015 23:43, "J Martin Rushton" <martinrushton56 at btinternet.com> wrote:> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/12/15 22:37, Warren Young wrote: > > On Dec 7, 2015, at 1:52 PM, Greg Lindahl <lindahl at pbm.com> wrote: > >> > >> On Mon, Dec 07, 2015 at 08:57:01PM +0100, Zdenek Sedlak wrote: > >> > >>> AFAIK, the 7(1503) format is used only on the websites, and > >>> internally CentOS uses 7.1.1503. Do you see this as an issue? > >> > >> Yes. It confuses humans. There have been a bunch of examples > >> given of how it confuses humans. A simple fix for this human > >> issue is to use 7.1.1503 on the website, here on the mailing > >> list, etc. > > > > And then we?re right back in the same old boat: With every new > > release, the same old thread will pop up, ?How do I make my servers > > stay on CentOS 7.1?? > > > > Give up on the point release idea. It?s CentOS 7; there is no > > CentOS 7.1. The only reason there?s a YYMM part is that it?s a > > media respin. Best ignore that wherever practical. > > So if we are to give up on the point release does that mean I don't > have to update my machines until CentOS 8 comes along? ;-) > > Seriously though, since I have to build my own repos (air gap) and > build the images for the diskless machines the point releases are > important in tracking roughly which version particular nodes are on. > Running yum update on a regular basis is just not an option.You should be updating during the lifecycle to each milestone though... To not do so is to leave yourself open to numerous bugs and attacks. As it is, as pointed out, you can still check the installed files from the centos-release package for the upstream it's based on and the YYMM respin date... Common configuration management systems (you should be using one of these given you say you have many systems) will also report the relevant details correctly. On top of this if you are maintaining your own internal air gapped repo you should be paying attention to announcements which will inform you at these milestone points... Given the workflow you state nothing has changed for you with the EL7.X releases...
Phelps, Matthew
2015-Dec-08 13:45 UTC
[CentOS] Version numbering vis a vis CentOS and RHEL
On Tue, Dec 8, 2015 at 2:42 AM, James Hogarth <james.hogarth at gmail.com> wrote:> On 7 Dec 2015 23:43, "J Martin Rushton" <martinrushton56 at btinternet.com> > wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 07/12/15 22:37, Warren Young wrote: > > > On Dec 7, 2015, at 1:52 PM, Greg Lindahl <lindahl at pbm.com> wrote: > > >> > > >> On Mon, Dec 07, 2015 at 08:57:01PM +0100, Zdenek Sedlak wrote: > > >> > > >>> AFAIK, the 7(1503) format is used only on the websites, and > > >>> internally CentOS uses 7.1.1503. Do you see this as an issue? > > >> > > >> Yes. It confuses humans. There have been a bunch of examples > > >> given of how it confuses humans. A simple fix for this human > > >> issue is to use 7.1.1503 on the website, here on the mailing > > >> list, etc. > > > > > > And then we?re right back in the same old boat: With every new > > > release, the same old thread will pop up, ?How do I make my servers > > > stay on CentOS 7.1?? > > > > > > Give up on the point release idea. It?s CentOS 7; there is no > > > CentOS 7.1. The only reason there?s a YYMM part is that it?s a > > > media respin. Best ignore that wherever practical. > > > > So if we are to give up on the point release does that mean I don't > > have to update my machines until CentOS 8 comes along? ;-) > > > > Seriously though, since I have to build my own repos (air gap) and > > build the images for the diskless machines the point releases are > > important in tracking roughly which version particular nodes are on. > > Running yum update on a regular basis is just not an option. > > You should be updating during the lifecycle to each milestone though... To > not do so is to leave yourself open to numerous bugs and attacks. > > As it is, as pointed out, you can still check the installed files from the > centos-release package for the upstream it's based on and the YYMM respin > date... > > Common configuration management systems (you should be using one of these > given you say you have many systems) will also report the relevant details > correctly. > > On top of this if you are maintaining your own internal air gapped repo you > should be paying attention to announcements which will inform you at these > milestone points... > > Given the workflow you state nothing has changed for you with the EL7.X > releases... > >What I want to know is, why is CentOS doing things differently than RedHat? Who made this decision, and was there any consideration given to making such a highly visible departure? When did CentOS decide to fork away from RHEL? It doesn't matter if this is truly the case, or not. Perception is reality here; CentOS is now no longer "the same" as RHEL and this turns it into a whole different, new, distro of Linux. That affects things like software certification, hardware support, security certification, etc. etc. It is now a stupendous burden on those of us who chose to implement it because it was "the same" as RHEL. Was this an edict resulting from the RedHat acquisition of CentOS? I can hear people saying, "Well, why don't you just use RedHat then?" I probably will have to now. But, we chose CentOS because it *was* RHEL, but it gave us more control (the ease of air-gapped repositories is a good example). I just think this whole thing was a highly unnecessary, and bad idea. And it has a lot of really serious repercussions that nobody seems to have thought of before plowing ahead. And, obviously, that angers me. I am asking for more than just consistency between the web site and /etc/centos-release, I am asking that, starting with RHEL 7.3, that CentOS stop using YYMM in its version numbers completely. -- Matt Phelps System Administrator, Computation Facility Harvard - Smithsonian Center for Astrophysics mphelps at cfa.harvard.edu, http://www.cfa.harvard.edu
Jonathan Billings
2015-Dec-08 16:11 UTC
[CentOS] Version numbering vis a vis CentOS and RHEL
On Tue, Dec 08, 2015 at 08:45:10AM -0500, Phelps, Matthew wrote:> What I want to know is, why is CentOS doing things differently than RedHat? > Who made this decision, and was there any consideration given to making > such a highly visible departure? When did CentOS decide to fork away from > RHEL? It doesn't matter if this is truly the case, or not. Perception is > reality here; CentOS is now no longer "the same" as RHEL and this turns it > into a whole different, new, distro of Linux. That affects things like > software certification, hardware support, security certification, etc. etc. > It is now a stupendous burden on those of us who chose to implement it > because it was "the same" as RHEL.CentOS has always been different than Red Hat Enterprise Linux, because Red Hat is willing to support older point releases of RHEL (for a price), while CentOS only supports the latest release. You might be running RHEL 7.1 Extended Update Support for another year or so, while the rest of the world has updated to RHEL 7.2. (see https://access.redhat.com/support/policy/updates/errata) I believe (although I was not involved with the choice) the new naming scheme reflects a need to advertise to the end user that there is only one supported release of each major version of CentOS, with a regular release of installation medium that coincides with the feature updates that come out with each RHEL point release. So often, I see people come on mailing lists and the IRC channels saying "I'm running CentOS 6.1 and I can't get PHP to work" and we have to ask why they aren't running a supported release of CentOS 6. A lot of people seem genuinely surprised that you can't just keep running some point release of CentOS and expect any kind of support. I'll admit, the use of 7.2.1511 is *helpful* because then I know what upstream version of RHEL it is based on, however, I'm also using RHEL7 along side CentOS7. But in terms of naming the install medium, it makes sense to just put a monotonically increasing number that reflects a timestamp. This is just my opinion, as both someone who tries to be helpful to CentOS users, as well as a sysadmin in a large institution. -- Jonathan Billings <billings at negate.org>