CentOS for Production (CentOS 6.0 Vs 6.1 Vs 6.2)

[nk oorda]

Hi

We are currently using CentOS 5.3 for production systems.

The application/software/package we are using mainly:
- Apache
- Tomcat
- SOLR
- Mysql

We are in process to upgrade the CentOS.

What would be the best CentOS candidate for upgrade (CentOS 6.0 Vs 6.1 Vs
6.2)

We are using both physical and virtual system.

Best Regards
NK

[Martin A. Brooks]

Post by nk oorda
What would be the best CentOS candidate for upgrade (CentOS 6.0 Vs 6.1 Vs
6.2)

I personally despair of the use of CentOS in production. It's all of
Redhat's ancient versions of software, and not much of it, with none of
the support.

Invariably people head off to lolrpms.cx to download the latest version of
$foo.

--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

[Tethys]

Post by Martin A. Brooks
I personally despair of the use of CentOS in production. It's all of
Redhat's ancient versions of software, and not much of it, with none of
the support.

Presumably you feel exactly the same way about Debian Stable and
Ubuntu LTS? They all exist because for many people, recent releases
are less important than having something that Just Works and can be
left running in production without the need for forced upgrades.

You can't exactly claim is has none of the support, either. True, you
don't get support in the sense that Red Hat won't look into individual
problems for you like they do for RHEL customers. But you know that your
packages are going to receive general bug fixes and security updates
for the next 7 years or more. That seems pretty reasonable to me, and
certainly better than using the latest Debian/Ubuntu/Fedora/whatever.
Different people have different requirements, and it won't be right
for everyone. But I'd say CentOS makes a better server OS for most
than the alternatives.

Post by Martin A. Brooks
Invariably people head off to lolrpms.cx to download the latest version of
$foo.

I've never met anyone that's needed to do that. Sometimes EPEL can
provide missing packages, but to be honest, I haven't found a need
to resort to that for more than a very small percentage of the CentOS
servers I've managed.

Tet
--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

[Martin A. Brooks]

Post by Tethys
Presumably you feel exactly the same way about Debian Stable and
Ubuntu LTS?

No. Mainly because just about every single useful piece of software for
Linux is already packaged for Debian. If you want something a bit newer
than is shipped with stable then that's what the backports and volatile
trees are for.



--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

[Robert]

Post by Martin A. Brooks

Post by Tethys
Presumably you feel exactly the same way about Debian Stable and
Ubuntu LTS?

No. Mainly because just about every single useful piece of software for
Linux is already packaged for Debian. If you want something a bit newer
than is shipped with stable then that's what the backports and volatile
trees are for.
--
http://lists.gllug.org.uk/mailman/listinfo/gllug

And of course by name, and by nature, "Volatile Tree" is not something
you'd use on a stable production system.
Debian Stable is far from cutting edge, but it is one of the more stable
systems and for this reason is why so many off-springs derive from it.

Horses for courses gentlemen, unless you have a real business need to
upgrade your production system, I'd keep it running as is. Identify the
benefits before upgrading, and if it doesn't bring anything significant,
don't do it!

Robert.
--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

[Martin A. Brooks]

Post by Robert
And of course by name, and by nature, "Volatile Tree" is not something
you'd use on a stable production system.

Perhaps you're confusing volatile with testing or unstable?

volatile contains things that, by their nature, need to be updated more
frequently than stable releases allow. ClamAV being an example of this.



--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

[Tethys]

Post by nk oorda
We are in process to upgrade the CentOS.
What would be the best CentOS candidate for upgrade (CentOS 6.0 Vs
6.1 Vs 6.2)

Why are you upgrading? Unless you're looking for a specific package
in 6.x (in which case, you'd presumably know which one had what you
needed), then why not just stick with 5.3? Upgrading for the sake of
it seems somewhat foolish. But FWIW, go for the latest (6.2).

Tet
--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

[nk oorda]

Thanks for the reply Tet,

we do have a application installed that needs the latest PHP, and we have a
policy not to compile the software. just installed by via yum or rpm. So i
guess CentOS 6.2 is the best bet.


Thanks
Best Regards
nk

Post by Tethys

Post by nk oorda
We are in process to upgrade the CentOS.
What would be the best CentOS candidate for upgrade (CentOS 6.0 Vs
6.1 Vs 6.2)

Why are you upgrading? Unless you're looking for a specific package
in 6.x (in which case, you'd presumably know which one had what you
needed), then why not just stick with 5.3? Upgrading for the sake of
it seems somewhat foolish. But FWIW, go for the latest (6.2).
Tet
--
http://lists.gllug.org.uk/mailman/listinfo/gllug

[Jonathan Casiot]

Post by nk oorda
Thanks for the reply Tet,
we do have a application installed that needs the latest PHP, and we
have a policy not to compile the software. just installed by via yum or
rpm. So i guess CentOS 6.2 is the best bet.
Thanks
Best Regards
nk

'Latest' PHP for CentOS 6.2 is currently 5.3.3-3.el6_2.6. Hopefully this
is sufficiently up to date for your application.

[Andy Millar]

Post by nk oorda
we do have a application installed that needs the latest PHP, and we
have a policy not to compile the software. just installed by via yum
or rpm. So i guess CentOS 6.2 is the best bet.

That policy sounds very sensible.

Does your policy allow for creating your own RPMs?

Andy
--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug

[nk oorda]

No Andy, it does not allow creating the RPM.

--NK

Post by Andy Millar

Post by nk oorda
we do have a application installed that needs the latest PHP, and we
have a policy not to compile the software. just installed by via yum
or rpm. So i guess CentOS 6.2 is the best bet.

That policy sounds very sensible.
Does your policy allow for creating your own RPMs?
Andy
--
http://lists.gllug.org.uk/mailman/listinfo/gllug

[nk oorda]

Post by Jonathan Casiot

Post by nk oorda
Thanks for the reply Tet,
we do have a application installed that needs the latest PHP, and we
have a policy not to compile the software. just installed by via yum or
rpm. So i guess CentOS 6.2 is the best bet.
Thanks
Best Regards
nk

'Latest' PHP for CentOS 6.2 is currently 5.3.3-3.el6_2.6. Hopefully this
is sufficiently up to date for your application.
--
Jonathan
--
http://lists.gllug.org.uk/**mailman/listinfo/gllug<http://lists.gllug.org.uk/mailman/listinfo/gllug>

Thanks Johathan,

It will work.

Best Regards
NK

[Stephen Ford]

Post by nk oorda
What would be the best CentOS candidate for upgrade (CentOS 6.0 Vs 6.1 Vs
6.2)
We are using both physical and virtual system.

Go for the latest version possible, it makes no difference as a base
os version once you start patching. There is no true 6.2, it is
simply 6.0 with all patches applied up to a certain date, tested and
released. If you were to install 6.0 and fully patch it, it would end
up 6.2 plus a bit anyway.

RH do not define what minor versions really are, the only way to
determine it is via /etc/redhate-release (which doesnt mean much) or
by looking at all the packages on the iso and using those versions to
collectively define the minor version. Assuming this and for example
if you were to install 6.1, as soon as you patched just one package,
you are no longer 6.1.

This the common problem with commercial applications which require a
specific minor version of rhel/centos and offer no support to slightly
newer versions. You end up getting trapped and not being able to
patch (even security updates) without breaking your support contract
with the silly supplier of the software.
--
Gllug mailing list - ***@gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug