On 02/27/2014 12:25 AM, Les Mikesell wrote: > On Wed, Feb 26, 2014 at 5:05 PM, Alexander Arlt <centos at track5.de> wrote: >>>> >> RHEL and CentOS have a very clear focus on what >> they want to achieve. > > Which currently doesn't involve helping users avoid shooting > themselves in the foot. Yes, that's true. At least Red Hat will only help you if you're willing to throw money at 'em. >> Not in my world. CentOS is accepted as a full blown RHEL-alternative by >> nearly everyone doing audits. You will be able to achieve SOX-compliance >> with almost any auditor I have met so far by using CentOS. Enterprise >> nowadays is far more than just having a hotline to call when things go >> wrong. And - at least in my opinion - CentOS is the only community >> driven Linux today fulfilling enterprise requirements without big time >> hassle. > > Are there restrictions on content from EPEL? Oracle Java? Your own > applications? Where do 3rd party additions become a problem in this > context? 3rd party additions simply are a problem in this context because it will change CentOS into something not totally Red Hatish. CentOS is not the well suited tool for the enterprise purpose it is because it's CentOS - it is because it's an exact replica of Red Hat. Of course there are restrictions on content from EPEL, also on the usage of Oracle Java and of course especially there are restrictions regarding "my" own applications. That's all what it's about using an enterprise OS: The baseline is already certified and proven to fulfill requirements so I only have to hassle with my own apps. And using CentOS is not - at least not in my case - about saving money by avoiding buying licenses. Hell, we throw so much money at Red Hat, it wouldn't matter. CentOS has a clean repository structure, the packages are well sorted out and - most important - I can mirror the repositories and get them easily to any point in the network. This is... harder with RHEL. We're using CentOS because of the quality, not because of the license fees. >>> Adding additional applications doesn't hurt the base. It is just >>> better testing for it. >> >> It depends on the application. You will have the effort of backporting >> patches if you are not able to bring current versions of several >> libraries to the game. Or you will have to update core libraries. > > Or use static linkage - or alternate locations like software > collections. There are ways that don't break the base... Static linkage is basically breaking everything about security. I don't know, how many CVEs regarding the glibc have been in 2013 with a severity of medium+? Too many to manage statically linked software. If you're using statically linked software your basically fooling the concept. Hello, SAP, someone listening? Installing software in non-standard-locations is mostly the same like doing some static linking. >>> I assume the 4 is a typo there. RHEL 4's EOL was 2-29-2012, But >>> that's all kind of irrelevant to what we should be preparing for after >>> a new install of CentOS 7 and what to expect from it. >> >> No, RHEL 4 has Extended Life Phase till 2015. And will probably be even >> longer supported - at least that's what we're all hoping for. And that >> is not irrelevant, because - basically - that's what enterprise is >> about. Getting long term support and that's maybe 10+ years. > > Interesting - I just got the 2012 EOL date from a Red Hat google hit. > But I had some early problems with Centos4 and moved to 5 as soon as > it came out. I think they mostly involved perl module packaging, > though, and might not have affected other uses. https://access.redhat.com/site/support/policy/updates/errata/ I'm not sure if this is still the current state of affairs, since we do have our own agreements and settlements with Red Hat, but I think it breaks down to the above.